What you need before you start
- Google Ads connected in Settings > Integrations, with an ad account linked. The verification checks this for you and, if the connection reaches more than one account, lets you pick which one receives these conversions.
- Leads arriving with their origin: your lead sources mapped (Lead sources) and, if you capture from your site, the pixel installed (MB Suite Pixel) — that's where the Google click ID (gclid) comes from, and its iOS siblings gbraid and wbraid. They're the strongest identifiers Google matches on.
- The customer data settings in order on Google's side: importing this kind of data requires the customer data terms accepted and enhanced conversions for leads turned on in the ad account. Don't hunt for them now — the verification checks both and hands you a direct link if something's missing.
- The role of owner or admin: only they configure and turn sending on. The rest of the team sees everything, read-only.
The six-step verification
Go to CRM > Settings > Conversions and open the Google Ads card with Configure. In Status, press Verify connection and the first five steps run in order; the sixth —the Test event— is a Validate button you press yourself once the rest are green.
- Google Ads connection — the workspace needs Google Ads connected. If it doesn't have it, Connect Google Ads takes you to Settings > Integrations to do it.
- Data Manager permission — importing conversions needs a permission of its own, checked against what your connection really carries. When it's missing you read The Data Manager permission is missing — reconnect Google Ads to grant it, and the step's button is Reconnect Google Ads.
- Operating account — the check resolves the ad accounts your connection reaches and shows the chosen one with its ID. When there's more than one, MB Suite pre-selects the one that spent the most in the last 30 days and a selector appears so you pick which account these conversions belong to — your choice sticks, and later verifications respect it. If there are none, you read The workspace has no linked Google Ads account.
- Customer data terms — Google requires two things in the ad account before it accepts imported customer data: the terms accepted (The customer data terms are not accepted in Google Ads) and enhanced conversions for leads turned on (Turn on enhanced conversions for leads in Google Ads). Both are fixed on Google's side, and the step's button —Open settings in Google Ads— takes you straight there.
- Conversion action — the check lists the import-type conversion actions of the chosen account. If it has none you read This account has no import-type conversion action, and Create conversion action opens the modal described below.
- Test event — with the first five green, Validate becomes available. Google checks the whole path —format, permission, account, action— and answers on the spot: Test passed: Google validated format and access.
The conversion action: Google's version of the event
On Meta you type an event name; on Google the event is a conversion action that lives in your ad account — the same object you manage in Google Ads under Goals → Conversions. MB Suite lists the import-type ones. If the account has none, the verification's Create conversion action button creates one without leaving the page; if it has some but none that fits, the same modal opens from Create conversion action…, at the bottom of the rule's picker, and the new action is left preselected in that rule. Either way, it is created in the connected Google Ads account, ready to receive imported conversions. You give it a Name (it suggests CRM Sales (MB Suite)) and a Category — Purchase / Sale, Converted lead, Qualified lead, Lead form submit, Contact, Book appointment or Request quote. As the modal explains, the category tells Google what this conversion represents in your funnel (affects how it is grouped in reports).
Mapping: which stage sends to which action
A rule reads like a sentence: when this happens, send this event with this value — with Google's twist that the event isn't typed, it's picked. Until you write the first one, the Mapping block greets you with Without rules, nothing is sent.
- Add rule and choose the trigger: Is won, Is lost or Enters a stage.
- Pick the scope: a specific pipeline or All pipelines. If you choose Enters a stage, pick the pipeline first — stages belong to each pipeline.
- Choose the destination from the closed picker (Choose a conversion action…). As the field's help says, in Google, the event is a conversion action in the account. Choose one or create a new one.
- Choose the value: Deal amount, a Fixed value, or No value for signals that aren't a sale.
- Drag to reorder. The first rule that matches a change wins — put the specific ones above the general ones.
If a mapped action stops existing on Google's side —someone removed or paused it in Google Ads— the mapping flags it right on the row: The action "…" no longer exists in Google Ads — choose another or create a new one. It shows up as soon as you run Verify connection again, which is what refreshes that list. It's a signal, not a lock: nothing holds the send back, so the event goes out pointing at that action and it's Google who turns it down — the row lands in the History as Failed, with Google's own message when you hover the status. Point the rule at a live action —or create a new one— and the following sends travel fine; Retry send won't rescue the row that already failed, because every send carries the action it was queued with. It's on the record either way; nothing disappears in silence.
Purchase without an amount is never sent; on LinkedIn, a purchase-type rule can't even be saved with No value. On Google neither happens: the value is optional for every category, so a won deal with no amount still goes out — and Google credits it with the default value defined on the conversion action in Google Ads. Keep your deal amounts loaded and use Deal amount so real numbers travel instead of that default; and don't reach for a token Fixed value either — the mapping rejects a zero (The fixed value must be greater than 0.) and any number you invent becomes the ROAS you read.Turn sending on
Only once your rules are written, go to Health and turn on Send conversions to Google Ads. That block shows the Google Ads account —with a direct Open conversions in Google Ads link—, the Google confirmation (last 30 days) breakdown, the five thirty-day counters —Attempts (30 d), Confirmed, Rejected, Failed and Not sent— and, under Advanced settings (collapsed by default), two controls: the Grace window —the send is queued instead of leaving immediately, so a deal dragged to Won by mistake and pulled back cancels itself; it ships at ten minutes, with Immediate if you'd rather have no delay— and Consent (EEA): how data consent is declared to Google for European Economic Area users, Granted or Unspecified. As its help says, if your forms already collect consent, keep Granted.
Google answers back: the confirmation of each send
Here's what no other platform gives you: Google doesn't stop at taking the event — it reports back what it did with it, upload by upload. Right after sending, the History shows Sent · awaiting Google confirmation; per Google's documentation the result arrives between 30 minutes and 24 hours later, and the row becomes Confirmed by Google —the event was accepted, with its value and matched identifiers— or Rejected by Google, with Google's own reason next to it, the same raw term you'd see in its Diagnostics. If 24 hours pass with no final result, MB Suite stops asking and marks it Sent · no Google confirmation within 24 h — at that point check the conversion action in Google Ads (Goals → Conversions → Diagnostics). In Health, the Google confirmation (last 30 days) bar totals the same story: Confirmed, Processing, Rejected, Unconfirmed — and when there are rejections, Rejection reasons (Google) lists the most frequent codes exactly as Google returns them, ready to look up in its Diagnostics.
Google's window: ninety days
Google accepts events up to 90 days old — the widest window there is, shared with LinkedIn and comfortable for long sales cycles: a deal that closes two months after the click still makes it home. Past that, the history logs it as Not sent — event too old (Google accepts up to 90 days), and there's no retroactive backfill. Also remember the two clocks on Google's side: each upload's confirmation takes up to 24 hours, and a newly created action spends its first 14 days in the trial period — so the effect on bidding is a matter of weeks, not hours.
How do I know it's working?
History, below Health, has the row-by-row detail — each send with its deal, event, value, the identifiers it carried under Match, and its confirmation status. You can filter it, search it and Export CSV — on Google Ads the export includes the confirmation status and Google's reason as their own columns. You also see it from the deal itself: when a conversion goes out, the deal's history records Google Ads received the conversion with the event's name, and a failure is recorded there too. On Google's side, the action and its imports live under Goals → Conversions — the Open conversions in Google Ads link is right in the Health block, and the action's Diagnostics page shows the pings arriving.
Start over: reset the Google Ads configuration
Inside the Google Ads detail, top right, the More actions (⋯) menu —which only owner and admin see— has Reset configuration…, and it only affects Google Ads. The modal spells out what it clears before you confirm: sending is turned off, the mapping rules go, and the selected account, verification and test status. What it doesn't touch: the Google Ads connection, managed in Settings > Integrations, conversion actions already created in Google Ads —they live on the ad account, not here— and the History of conversions already sent. Confirm with Reset and Google Ads goes back to day one.
What data travels to Google, and your responsibility
The email and the phone travel hashed with SHA-256 — Google never receives them in the clear, and MB Suite sends no names at all. Alongside them go the advertising identifiers the lead already arrived with: the Google click ID (gclid) and its iOS variants gbraid and wbraid, which travel as-is because the API needs them untransformed: they're codes Google itself issued when the person clicked the ad and, on their own, don't say who that person is — but Google can tie them to one of its users. Every send also carries the consent declaration you set under Consent (EEA), the deal's value and currency, the date of the milestone and a transaction ID derived from the deal's internal ID (Google uses it to deduplicate; it reveals nothing about the person, but it is a stable identifier for that deal living on Google's side). Of the identifiers, the log stores only the field name —Hashed email, Hashed phone, Google click ID (gclid)—, never its content: that's what the Match column shows you. The row does keep the deal it belongs to (title and amount) so the history stays auditable. And one clarification worth keeping in mind: hashing is not anonymizing. The hash exists precisely so Google can recognize the person, so it remains personal data about them — and the legal framework that applies to you doesn't stop applying because you hashed it.
Still have questions?
Ask MIA, the MB Suite AI assistant: open it with the MB AI button (⌘J) in the top bar. MIA knows the section you're in, so you can ask it about what you see on screen — and it can also answer how-to questions about using MB Suite.