Skip to content

Guide

Closed-Loop Attribution: Tell Google and Meta Which Leads Actually Booked

Anam Jalal

Founder & CEO, MAJ Leads

Updated 19 Sep 2026 · 8 min read

Quick answer

Once a lead reaches a terminal outcome, qualified or booked, MAJ Leads reports it back to the ad platform it came from: to Google Ads as Enhanced Conversions for Leads under two conversion actions, Qualified Lead and Booked, matched on hashed contact details and gclid; to Meta as Lead and Schedule events via the Conversions API, matched on hashed contact details and fbclid. A cron uploads these every 15 minutes with retry, and both paths are verified against a test account before going live on a client's real campaigns.

In plain words, why does this matter to the ad platform's bidding algorithm at all?

A bidding algorithm does not know what a good lead looks like. It only knows what it is told counts as a win, and it spends its budget trying to find more people who look like whoever produced a win last time. If the only event a campaign ever reports is "form submitted," the algorithm optimises for people who are likely to fill in a form, which includes plenty of people who were never going to buy anything, students researching a project, competitors checking pricing, someone who submitted a number that does not connect. Closing the loop means telling the platform, days after the form was submitted, which of those specific people turned into a real customer. The algorithm then adjusts who it shows the ad to next, gradually shifting spend toward the kind of person who actually books, not just the kind of person who clicks.

For the mechanics of how a lead gets into MAJ Leads from a Google Ads lead form or a Meta lead ad in the first place, gclid, fbclid, campaign and ad set captured at intake, see our companion post, Google Ads Lead Forms and Meta Lead Ads: Called in 30 Seconds. This post picks up from there, once a lead has already been called, and covers what happens on the way back to the ad platform.

What exactly gets reported to Google Ads, and how?

Google Ads' Enhanced Conversions for Leads lets an advertiser upload a conversion that happened after the fact, tied back to the original click, rather than only measuring what happens on the page at the moment of the click itself. MAJ Leads configures two separate conversion actions per client: Qualified Lead, fired the moment a lead's outcome is recorded as qualified, and Booked, fired once a calendar booking is confirmed. Keeping these as two distinct actions rather than one blended "conversion" matters, because a client's Google Ads account can then see, and bid toward, the two separate stages rather than one number that hides whether spend is producing qualified conversations or only bookings from a lead that would have booked regardless of the ad.

What exactly gets reported to Meta, and how?

Meta's Conversions API plays the equivalent role on the Meta side, sent server-to-server into the client's own ad dataset rather than relying on browser-side pixels that ad blockers and privacy settings increasingly interfere with. A qualified outcome is sent as a standard Lead event, a booking as a Schedule event, and every event carries an action_source of phone_call, because the qualifying moment genuinely happened on a phone call, not on the website. Reporting the correct action source is not cosmetic, it tells Meta's own modelling where in the real world this conversion actually took place, which affects how the signal is weighted.

How does Google or Meta know which of its ad clicks a given phone call belongs to?

Matching runs on two layers stacked together. The first is deterministic, an exact click identifier: gclid for Google Ads, fbc derived from the stored fbclid for Meta, captured at the moment the lead first landed and stored against that lead's attribution record. When present, this is the strongest possible match, it points at one specific ad interaction. The second layer is contact-based matching on hashed phone number and email, which both platforms support because it lets a conversion still be attributed even when a click identifier was not captured or was lost somewhere in the journey, such as a lead who clicked an ad on one device and was later called on a number given verbally. For a Meta Lead Ad specifically, the original lead_id is also passed through, which is the most direct match of all for that channel because it points straight at the exact lead form submission.

Why is the contact data hashed rather than sent as plain text?

Neither platform accepts, and neither should accept, a phone number or email address in plain text for this kind of upload. MAJ Leads hashes phone and email before they leave the system, which lets Google and Meta perform the match on their side without ever seeing the underlying contact detail in readable form. This is not an optional privacy nicety layered on top, it is the documented format both platforms require for this data, and it is the same practical effect as the honesty guardrail behind the rest of MAJ Leads' product: the lead's raw contact information stays inside the client's own system and CRM, only a one-way hash travels outward for matching purposes.

How quickly does an outcome actually reach the ad platform after it happens?

A scheduled job runs every 15 minutes, picking up any lead that reached a qualified or booked outcome since the last run and uploading it to the relevant platform. Fifteen minutes is frequent enough that the feedback loop stays close to real time from the ad platform's perspective without uploading on every single event individually, which would multiply API calls for no real benefit given how bidding algorithms actually consume this data. If an upload fails, a network hiccup, a temporary rate limit, it retries automatically, and anything that still cannot be delivered after retrying lands in a dead-letter path rather than silently vanishing, so nothing gets lost without someone being able to see it happened.

How is any of this verified before it touches a client's real ad account?

Neither integration is switched on against live spend untested. The Google Ads path is verified first against a Google test account, where an uploaded conversion can be inspected without it affecting any real campaign's bidding. The Meta path is verified using Meta's own test_event_code mechanism, which lets an event be sent and checked in Meta's Events Manager the same way a live event would appear, again without it counting as real data. Only once both sides show the expected event landing correctly, the right action, the right match keys, the right timing, does the integration point at the client's actual ad accounts and conversion actions.

What actually changes for a client once this loop is closed, in practical terms?

Nothing changes about how the ads look or how the lead is called. What changes is what the ad platform learns from every campaign that runs afterward. Over weeks, as enough qualified and booked events accumulate against enough clicks, the algorithm's own targeting and bidding start drifting toward the audiences, placements and creatives that actually produced a booking, not just a form fill. This is also, deliberately, the same underlying attribution record described in our companion post, source, campaign, ad, gclid or fbclid, first-touch timestamp, so a client's dashboard can show which channel is actually producing revenue-worthy leads even before the platform-side optimisation effect has fully taken hold.

Does this replace pushing the lead into the client's CRM?

No, the two are separate and both happen on the same terminal outcome. Reporting Qualified Lead or Booked back to Google and Meta is about teaching the ad platform, CRM push is about handing the deal itself, transcript, outcome and attribution included, to whatever system the client's team already works in day to day. MAJ Leads sits in front of both, it does not replace the CRM and it does not replace the ad accounts, it is the piece that makes sure information travels between the call that happened and the two systems that need to know about it.

What does a client need to set up for this to run on their account?

This is configured once per client under ad accounts in onboarding: linking the client's Google Ads account, usually through MAJ's MCC, and connecting a Meta dataset for the Conversions API. From there, every qualified or booked outcome from any source, website, Google Ads lead form or Meta Lead Ad, feeds the same reporting pipeline automatically. See the fuller picture on the real estate CRM page, where lead-ad attribution tends to matter most, compare AI Mode and Team Mode for how the calling side runs, and see current pricing, Team Mode starts from AED 299 per month, on the pricing page.

Sources

Frequently asked questions

What is the difference between Enhanced Conversions for Leads and a standard Google Ads conversion?
A standard conversion is typically measured at the moment something happens on the website. Enhanced Conversions for Leads is designed for offline events, like a phone call outcome, uploaded after the fact and matched back to the original click using hashed contact details and gclid.
Why report both a Qualified Lead event and a separate Booked event to each platform?
Keeping the two stages separate lets each platform's bidding distinguish between spend that produces a real conversation and spend that produces an actual booking, rather than collapsing both into one undifferentiated conversion signal.
Is any raw phone number or email address ever sent to Google or Meta?
No. Contact details are hashed before upload in both directions. Matching happens on the hash, together with the click identifier, gclid or fbc, where one was captured at intake.
Does this work for leads that arrive from a website form rather than a lead ad?
Yes. Any lead that reaches a qualified or booked outcome is eligible for the same reporting, provided a gclid, fbclid or matching contact detail was captured at some point in its journey.

Anam Jalal

Founder & CEO, MAJ Leads

Anam Jalal is the founder of MAJ Leads, a Dubai-based AI voice agent company deploying TDRA-compliant AI receptionists and callers for UAE clinics, brokerages and SMEs — working hands-on across UAE telephony and CRM integrations, from SIP provisioning to TDRA compliance configuration.

Read more about Anam

Related articles

Explore our services