Meta and Google Disagree: Reconcile Conversions with AI

Meta and Google disagree about your clinic's conversions because each platform counts only its own ads, under its own attribution window, view-through rules and modeling, so one booking can be claimed by both and dated to different weeks. Reconcile each platform against one first-party ledger, never against each other. Curve is built to be that ledger: conversions land on its US-hosted infrastructure before any ad platform sees them, under a signed BAA on every plan, and Curve MCP lets an AI assistant read the ledger by completed week without taking either platform's number as the truth.

Why Meta and Google will never report the same number

The two numbers are not supposed to match, and no setting makes them match. Meta reports conversions it can tie to Meta ads under Meta's rules. Google "only reports conversions if there are Google Ads interactions (for example, clicks) from the same Google Ads account."

Neither sees the other's ads. The one exception is a Google conversion imported from GA4 with "Paid and organic channels" credit, which can lose a booking to a UTM-tagged Meta click; Google warns that the setting "may impact the conversions you create in Google Ads."

Six mechanics produce almost every gap.

Different attribution windows

Google's default click-through conversion window is 30 days, and it can be set as long as 90 depending on the conversion source. Meta reports each ad set under its own attribution setting, commonly 7-day click and 1-day view. A patient who clicks on day 1 and books on day 12 counts for Google under defaults and falls outside a 7-day click setting on Meta. In long-research specialties, that one setting often decides which column a booking lands in.

View-through and engage-through credit

An ad set with a 1-day view setting counts a booking made within a day of someone seeing an ad they never clicked. Google keeps ordinary view-through conversions out of its main Conversions column; they sit in "View-through conv." and "All conv." instead. There are two exceptions: engaged-view conversions from YouTube, and view-throughs on campaigns opted into view-through optimization.

Since March 2026, a click on Meta means a link click only for website and in-store conversions. Likes, shares, saves, comments and 5-second video views now count under a separate "engage-through" attribution. So Meta can also claim an engage-through conversion: someone liked or shared the ad, or watched 5 seconds of it, then booked through another route, such as a Google search.

Modeled conversions

Both platforms fill measurement gaps with estimates. Google says it plainly: "In the 'Conversions' column, Google reports both modeled and observed conversions," including cross-device conversions. Meta says statistical modeling may account for some results when data is partial or missing. Nobody can trace a modeled conversion to a booking; it is an estimate, reported beside observations.

Different dates for the same booking

Google's standard Conversions column dates a conversion to the ad interaction, not the booking; its "Conversions (by conv. time)" column dates it to the booking. Meta dates website conversions to the day they happen. Since June 10, 2025 its reporting API has ignored the old action_report_time switch and follows Ads Manager, which reports off-Meta actions such as a booking at conversion time. So the mismatch sits on Google's side: a patient who clicked on Saturday and booked on Tuesday lands in different weeks in Google's standard column than in Meta's report or your ledger.

Double credit and split credit

Neither platform sees the other's touches, so each claims any booking its own ads touched inside its window. Google's default data-driven model then "distributes credit for the conversion" across Google ad interactions. Only primary conversion actions report in Conversions, so marking one primary by mistake changes what the column means overnight.

Counting events instead of people

Platforms count conversion events; a ledger counts people. A Google action set to count "Every" conversion records each one after a click, and Meta counts each event it receives. A patient who books, cancels and rebooks can be two conversions to a platform and one to the ledger.

One booking, two claims

• Tuesday evening, a prospective patient scrolls past your Meta ad without clicking.
• Wednesday morning, she searches the clinic's name, clicks your Google brand ad and books a consult.
• Meta counts a conversion (a view inside one day). Google counts one (a click inside 30 days). Your scheduling system shows one consult.

Summed, the platforms report two bookings, both honest by their own rules.

Reconcile against one ledger, not against each other

Comparing Meta to Google directly is a debate with no referee. You need a third record, on your side of the line, that applies one rule to every platform. A usable ledger has three properties:

• It counts people once. One patient who books is one conversion, however many ads she saw.
• It credits with one fixed rule. The same model and lookback for every source, every week, so a change in a platform's claim shows up as a change.
• It ties to the business. Booked or attended appointments come back from the CRM or practice management system.

A last-touch ledger is not the truth about what caused a booking either. It under-credits the Meta video that planted the idea and over-credits the brand search that closed it.

Its value is consistency, not causation. To learn whether Meta spend creates bookings that would not have happened anyway, you need a holdout or lift test. Choosing the ledger's lookback on purpose is covered in attribution windows for healthcare.

How to reconcile Meta and Google against the ledger

Run it on settled, completed weeks in one time zone and log the result; the weekly AI routine covers the cadence.

1. Fix the definition. Note which Google conversion actions are primary, and whether each is a Google Ads tag or Enhanced Conversions action, or a GA4 import. Check each Google action's Count setting: "Every" counts each conversion after a click, "One" counts one per click. Note which Meta event and attribution setting each ad set uses (Ads Manager has an Attribution setting column), and confirm all of them mean what the ledger means: a submitted booking, not a form start.
2. Pull three numbers per campaign per week: the platform's claimed conversions, the ledger's attributed conversions, and spend. For Google, pull the "Conversions (by conv. time)" column so all three sources are dated to the booking (the weekly routine has the query version). For campaigns too small to release weekly, compare 4- or 13-week totals.
3. Compute a claim ratio per platform: claimed divided by ledger. Track the ratio, not the gap. A ratio that holds steady is methodology; a ratio that jumps is news.
4. Check the sum against total bookings. Take the ledger's count of people who booked from any source, paid or not, for the same weeks. If Meta's claim plus Google's claim is larger, the excess cannot be extra patients: it is double claims, modeled estimates or conversions dated to another week. Below that ceiling, overlap is likely but not proven, which is why cross-platform totals never belong in a board report.

When a ratio moves, the cause is usually one of these:

• An ad set's attribution setting changed, or a Google action's conversion window or Count setting did.
• A Google conversion action flipped between primary and secondary.
• A leftover Meta Pixel still sends the same booking the Conversions API sends, without a shared event ID (see Meta CAPI deduplication for clinics).
• The modeled share shifted, usually with no change on your site at all.
• The platform stopped receiving or accepting your events, a pipeline question covered in sent vs accepted conversions.

How Curve keeps the ledger neutral

Curve sits between your website and the ad platforms rather than beside them. Its script replaces the Meta Pixel and Google tag, so each conversion is recorded on US-hosted infrastructure first and only then forwarded server-side to Meta's Conversions API and Google Ads Enhanced Conversions. The record exists before either platform applies its windows or models, which is what makes it neutral.

• Only mapped fields leave. Per-destination field mapping forwards nothing by default, identifiers are SHA-256 hashed, and neutral event aliases keep the service line out of the event name.
• Attribution survives the booking hop. Bridge tokens carry attribution to tools such as IntakeQ, Calendly or Jane App, so a booking made off your domain is not missing from the ledger while a platform still claims it.
• Outcomes come back. Incoming webhooks and offline conversion uploads match booked appointments by email, click ID or bridge token.
• One rule for every platform. Each converting person is credited once, by last touch, whether that touch came from Meta or Google.

What the MCP server returns

Curve MCP reconciles your server-side campaigns for any client that can connect to an MCP server: Claude (desktop, web or Claude Code), ChatGPT, Cursor or another MCP-capable agent. For each campaign it puts spend, clicks and impressions as the platform reported them next to the conversions Curve's server-side tracking recorded, with cost per conversion by completed week. One link opens the full sent, accepted and matched view inside Curve. At the organization level it also returns how many people completed each goal, such as a booking, from any source. It answers over fixed windows (last week, or the last 4, 13 or 52 weeks), with a week-by-week series.

Counts are rounded, and a campaign too small to release is withheld, so a missing row means unknown, not zero. Approve the neutral campaign names you want to reconcile: a hidden label keeps its numbers but reads "(label hidden)" and cannot be matched to the platform's row by name. The reasoning behind both rules is in why Curve MCP answers in weeks.

One boundary to keep straight: the AI assistant is a vendor you choose, and the BAA that covers the ledger does not extend to it.

Having an AI assistant run the comparison

An AI assistant is good at this job for the same reason it is risky at it: it lines up thirteen weeks of numbers in seconds and explains any gap confidently. Hand it two numbers that disagree and it tends to pick one or average them. Your instructions have to forbid both.

Where the numbers come from

Give the assistant two inputs and keep them separate:

• The ledger, read through Curve MCP: campaign-level and booking counts by week, rounded, with small campaigns withheld.
• The platform claims, at campaign level for the same weeks: an export from Ads Manager and Google Ads, or a read-only connection to each platform's own MCP server. Google's official server is read-only by design. Meta's can create campaigns and start spend once a user confirms, so hold it to read-only (see what to allow when connecting Claude).

Never paste lead exports, customer lists, CRM rows or anything carrying a name, email or phone; the math does not need them. A raw platform export does not withhold small numbers either: a campaign with two conversions and a condition-specific name says more than it appears to.

The rules that keep it honest

Give it these rules up front:

1. "Treat the ledger as the reference. Treat Meta and Google figures as claims. Never average, blend or sum them into a patient count."
2. "Label every number with its source, its attribution window and its model."
3. "For each platform and week, report claimed, ledger, and claimed divided by ledger."
4. "Flag any week where a platform's ratio moved outside its recent range."
5. "For each flag, name the likely cause (window, view-through or engage-through, modeling, date convention, double credit, event counting, definition change, pipeline) and the evidence that would confirm it. Mark it unconfirmed until you have that evidence."
6. "Treat a withheld row or a hidden label as unknown, never zero. If any row is withheld, do not add up the released campaigns into a platform total. Switch to the 4- or 13-week window, and do not report a ratio change that rounding alone could explain."

A good answer reads like an analyst's note: labeled numbers, the ratio trend, and each flag paired with its check. If it reads like a verdict on which platform is right, send it back.

Frequently asked questions

Why can Meta claim more conversions than our ledger shows?

View-through and engage-through credit are the usual suspects: Meta can claim a booking after an unclicked impression or after a like, share or 5-second video view, while a last-touch ledger credits the click that came after. Modeled conversions add to it, and so do duplicate pixel and Conversions API events. The first three are methodology; the duplicates are a bug to fix this week.

Can Meta report fewer conversions than our ledger?

Yes. A patient who clicks a Meta ad and books 12 days later with no other ad touch is in a ledger with a longer lookback, credited to Meta, but outside Meta's 7-day click window. In long-research specialties a Meta ratio below 1 is common, and it is methodology rather than lost tracking. A ratio that drops suddenly is different: check the pipeline first.

Why does Google show fractional conversions?

Data-driven attribution splits one conversion across the Google ad interactions that led to it, so a patient who clicked a generic search ad and later a brand ad adds a fraction to each campaign. The ledger credits the whole booking to one last touch, so a single Google campaign's ratio can drift while the account's holds steady.

Should I change Meta's attribution setting to match Google's?

Not to make reports agree. The systems are not symmetrical (Meta ad sets commonly count views, Google keeps most out of its main column), and Meta says the ad set's attribution setting keeps the conversions it measures "the same ones that inform campaign optimisation." Change it and you change delivery. Compare in reporting instead, where Meta can show results under other attribution settings.

Where should Meta's and Google's own conversion counts come from?

From Ads Manager, Google Ads or their read-only connectors. Curve MCP supplies the ledger side, and keeping the two inputs separate stops the reference from quietly absorbing a platform's claim.

Where to start

Take the last 13 completed weeks. Write down the conversion actions, Count settings and attribution settings behind each platform's number, pull Google by conversion time, compute each platform's claim ratio against a first-party ledger and check the sum against total bookings. The steady ratio is your baseline; the moves are your agenda.

If you have no ledger on your side of the line, that is the first fix. Curve records each conversion before any platform sees it, forwards only the fields you map, and includes a signed BAA on every plan. To watch an assistant reconcile Meta and Google against that ledger through Curve MCP, book a demo.

Reviewed September 2026. Platform settings and column definitions checked against Google Ads Help, Google Analytics Help, Meta's Marketing API documentation and Meta's March 2026 click-attribution announcement.