HeadHoncho

Where the spend comes from

To connect Google Ads to CRM data — your jobs, your money — HeadHoncho asks the ad platform for read access and never for the right to spend.

Sources is one card per place spend and leads come from, each carrying its live status, the account it is pointed at, when it last ran, and who connected it. It is also the only board where a widened scope is not merged: a credential belongs to one company, so each client gets its own section.

What connects

Two kinds of source, and they do different jobs. An ad platform brings what you spent. A call tracker brings what it produced. The jobs and the money — what it was worth — are already in this product.

SourceBringsHow it connects
Google AdsCampaigns, ad groups and daily spendSign in with Google, then pick the account
Meta AdsCampaigns and daily spendSign in with Facebook, then pick the ad account
Microsoft AdvertisingCampaigns and daily spendSign in with Microsoft, then pick the account
CallRailTracked calls with their campaign, source and caller numberAn API key, verified before anything is stored
A button that cannot work is never shown

Every provider's own app review runs on its own schedule, and a provider whose registration has not cleared is listed on the panel with the reason and no control — rather than a Connect button that opens somebody else's error page. So the honest answer to “what can I connect today” is what the panel offers you when you open it.

What we ask for, and what we can do with it

To connect Google Ads to CRM records — your jobs, your money — the product asks the platform for access to read your advertising data. Two of the three platforms only publish a single combined permission that covers reading and writing; one of them offers a genuinely read-only grant, and where that exists we take it.

Where it does not, the guarantee is ours to keep rather than the platform's to enforce, so it is enforced in our own code: the ad-platform client is built to read, and the write operation those APIs expose is refused outright at the point the request is formed. It is a fence with a test around it, not a policy in a document.

One platform also has a precondition inside your own account that no API access substitutes for — auto-tagging has to be switched on, or the click identifier never reaches your phone number and nothing further down the chain can work. The product treats that as a blocking setup step and says so on the card, rather than logging a warning nobody reads.

Choosing the account

An ad account is never selected for you, even when the grant returns a list of exactly one. It is presented and confirmed, because choosing the wrong account is the top support ticket across every product in this category, and a silently-picked account produces a month of confident numbers about somebody else's advertising.

The account picker takes its company from the sign-in you started, not from whatever is selected in the app when you come back. By the time you are choosing an account you are three redirects from where you began, and the current selection is not evidence of what you meant.

What gets pulled, and how often

Spend is not a fixed fact. Platforms restate: a conversion attributed today can land against a click from weeks ago, and yesterday's figure is not necessarily yesterday's figure tomorrow. So the sync does not stream forward and append — it re-asks for a window and overwrites.

Because the same day is fetched over and over, every spend row is keyed on its campaign and its date, and a re-sync is a no-op rather than a doubling. That is not a tidiness concern: a doubled spend row halves every return figure on the board, and a halved return is a campaign somebody pauses for no reason.

A card says when it last ran, and Sync now asks immediately.

Sources: connect Google Ads to CRM work, with Meta, Microsoft Advertising and the call tracker beside it. 1
  1. A source whose authorization has lapsed says so in its own card, names what it can no longer do, and offers the one control that fixes it.

What a broken connection looks like

The dangerous state is not a connector that has failed loudly. It is one that stopped returning rows while everything on screen still looks fine — which is why a card carries its status, the platform's own blocker sentence verbatim, and the name of the person who connected it.

Disconnecting keeps the spend. The rows that already landed keep their parent, so history does not vanish because a credential was revoked — and the card becomes a not-connected card that remembers: the sign-in button comes back, the account and the last sync stay in the meta line, and it stops counting itself among your connected sources. Disconnect asks first, because the fear it has to remove is exactly that the spend goes with it.

The call tracker

Connecting the call tracker is a task with a verdict rather than a settings row: you paste an API key, choose the account, name the conversion action, set the currency and the booking window, and the key is verified against the provider before anything is stored. What comes back is shown to you.

What arrives is tracked calls with their campaign, source and caller number — which is the thread that lets a booked job be matched back to the click that produced it. What happens to that thread afterwards is on the Insights board, and the rows themselves are on Raw data.

Connecting on a client's behalf

An agency running seventeen clients holds seventeen separate grants, each into that client's own account. That has three consequences worth knowing before you start clicking:

The client themselves sees their own platform's normal consent screen, naming the access being granted, at the moment they approve it. Nothing about the connection is hidden from the account owner.