- Google Ads defaults to a 30-day click attribution window; Meta defaults to 7-day click, the same sale can land inside one and outside the other purely on timing.
- Two platforms can both count the same conversion, legitimately, because both touched the customer before it happened.
- Modeled conversions are estimates, not records, and each platform's model is built on its own data, so the models disagree by design.
- View-through and click-through are different events counted under the same word, "conversion."
- Your CRM or order system is the only place a sale is recorded once, which is what makes it the ground truth.
Cross-platform ad reporting never adds up because each platform is built to measure its own performance, on its own clock, under its own rules for who gets credit. It is not built to agree with another platform, and it is definitely not built to agree with your CRM. Google Ads defaults to a 30-day click attribution window. Meta defaults to 7-day click. Both can legitimately claim the same sale. Both fill measurement gaps with statistical models trained on their own data. None of those numbers are wrong. They are answering different questions. The only number worth putting in front of a finance team is the one you build by reconciling all of them against your order system.
Here is the part that trips teams up. Most people assume the gap is an error, a broken tag, a missing UTM, a pixel that fired twice, and go looking for the bug that will make the dashboards line up. There is no such bug. Tagging hygiene removes the noise on top of the gap; it cannot remove the gap, because the gap is what the platforms were designed to produce. Once you stop treating the mismatch as a defect and start treating it as a known property of the system, the problem changes from "make them match" to "build one number you can defend." That second problem is solvable.
Why doesn't the same sale show up the same way in two dashboards?
Start with the attribution window, because it explains more mismatches than anything else and almost nobody checks it before escalating.
An attribution window is a clock. When someone clicks an ad, the platform starts counting. A conversion inside the clock gets claimed; a conversion after it is invisible. Google Ads' default click window is 30 days. Meta's default is 7-day click. That's not a difference in strictness, it's a different question. Google asks "did anyone who clicked in the last month buy?" Meta asks "did anyone who clicked in the last week buy?"
Walk one customer through both clocks. She clicks a Meta ad on the 1st, clicks a Google search ad on the 20th, and buys on the 25th. Google's window is open, so Google claims it. The Meta click is 24 days back, well outside 7 days, so Meta reports zero.
Change one thing. She buys on the 5th instead, four days after the Meta click and before she ever touches Google. Now Meta's window is open and claims the sale, and Google never sees it. Same customer, same purchase, opposite dashboards, decided entirely by a date.
The exception worth naming: these are defaults, not fixed rules. Windows are configurable, and someone may have changed them years ago without documenting it. Before you spend a week reconciling, open the attribution settings on each account and write down what they say today. A surprising share of "the platforms don't match" is really "two people set two different windows and nobody wrote it down."
Second exception: changing a window doesn't only change reporting. It changes how the platform's bidding algorithm learns, since the algorithm optimizes toward whatever it's allowed to count. Aligning windows to clean up reporting is a real intervention on delivery. Do it deliberately, once, and note the date, numbers before and after aren't comparable.
Can two platforms both be right about the same conversion?
Yes, and this is the piece that sounds like double-counting but isn't, at least not from the platform's point of view.
A conversion in Google Ads means "a conversion happened within my window after someone interacted with my ad." Meta's means the same about Meta's ads. Neither is a claim of exclusivity, and neither platform can see the other. If a customer saw a Meta ad on Tuesday, clicked a Google ad on Thursday, and bought on Friday, both platforms are telling the truth about their own involvement, and both put a "1" in the conversion column.
Add those columns together and you've created a sale that never happened. That's not the platforms lying. That's you performing an addition the data doesn't support.
Here's the shape, as an illustrative model, plug in your own numbers, the structure is the point. Say Google Ads reports 100 conversions in a month, Meta reports 60, and your order system shows 120 actual orders. The naive total is 160, which is 40 more orders than exist. That 40 isn't an error bar; it's real orders both platforms touched. A blended CPA built on 160 is understated by a third, blended ROAS is overstated by the same logic, and every budget decision downstream inherits the error.
The number that matters: 30 versus 7. That single difference in default click-attribution windows is enough, on its own, to make two honest platforms report different totals for the same month of the same account, before overlap, modeling, or view-through enter the picture at all.
What this is not: a reason to distrust the platforms at the job they're doing. Google's bidding needs Google's own signal, counted Google's way, to function; feeding it a de-duplicated cross-platform number would make it worse. The platform number is the right input for in-platform optimization and the wrong input for cross-channel allocation. Both are true at once, which is why the answer is a reconciliation layer, not "pick the honest platform."
What is a modeled conversion, and why do two models never agree?
Since iOS 14's tracking prompt and the long grind of third-party cookie deprecation, a meaningful share of conversions can't be observed directly. The click happens, the purchase happens, and the link between them isn't reportable because the identifier that connected them is gone.
Platforms didn't respond by reporting less. They responded by modeling. A modeled conversion is the platform's statistical estimate of what probably happened in the cases it can't observe. Mechanically: it takes the conversions it can still see, learns the relationship between observable signals and outcomes, and applies that relationship to the unobservable population to fill the gap.
That is a defensible thing to do. It is also, by construction, a thing two companies cannot do identically. The training data is different, Google's model learns from Google's observable conversions and signal set, Meta's from Meta's. The assumptions are different, and neither is fully published. The unobservable populations being estimated are different, because each platform's blind spot is its own.
So the models disagree. Not because one is broken, because they are separate estimates of separate slices of missing information, produced by separate systems. Expecting them to converge is expecting two different research teams to arrive at the same decimal.
The practical consequence is that some part of every platform number you look at is an estimate presented in the same font as a measurement. There is no flag in the total saying which rows are modeled. Treat the whole platform figure as directionally useful and precisely unreliable, which is how you should treat any estimate.
The edge case that bites: modeled numbers get restated. A platform can revise a period's conversions upward or downward as its model updates, days after the period closed. If you screenshot a dashboard on the 1st and someone pulls the same report on the 8th, the numbers can differ with nobody having done anything wrong. If your team reports from screenshots, this will eventually cost you credibility in a meeting. Pull from an API on a fixed schedule, stamp the pull date on the report, and say out loud which numbers are final and which are still settling.
Does a view count, or only a click?
"Conversion" is one word covering at least two different events, and the difference drives some of the loudest platform-versus-CRM arguments.
A click-through conversion means someone clicked and then converted inside the window. A view-through conversion means someone was served the ad, did not click, and converted anyway inside a usually much shorter view window. Both can land in a conversion column. They are not the same evidence. Click-through has a causal thread you can argue for. View-through has a far weaker one, because "was served an impression" describes most people who spend time on the internet, some of that credit is real, and some is coincidence dressed as influence.
This is where an honest reporting practice separates itself from a flattering one. If your dashboard blends the two into one "conversions" number without saying so, your ROAS isn't comparable to a CRM figure, to a benchmark, or to last quarter if anyone changed the setting. Here is what the defaults look like side by side. Check yours rather than assuming, settings drift, and platform defaults change over time.
| What's being counted | Google Ads (default) | Meta (default) | Your CRM / order system |
|---|---|---|---|
| Click attribution window | 30-day click | 7-day click | Not applicable, records the order itself |
| View-through credit | Available, separately reportable | Available, shorter window than click | None |
| Modeled / estimated conversions | Yes, blended into reported totals | Yes, blended into reported totals | No, a record, not an estimate |
| Whose activity it measures | Google-touched conversions only | Meta-touched conversions only | All orders, regardless of source |
| Exclusivity of credit | None, Meta may also claim it | None, Google may also claim it | One order, counted once |
| Reporting clock | Account time zone setting | Account time zone setting | Your business/finance time zone |
| Restated after the fact? | Yes, as models update | Yes, as models update | Rarely, and traceably |
Read down the last column and the conclusion writes itself. The order system is the only column where a sale is recorded once, counted once, and not subject to a model. That is not because your CRM is smarter. It is because your CRM is the only system in the room with no incentive to claim credit.
Why does the same week produce different totals depending on when you look?
Two mechanisms, both boring, both responsible for a lot of wasted meeting time.
Time zones. Each ad account has its own reporting time zone, set at creation and rarely revisited. Finance closes the month in the company's time zone. If the account is set to a different one, the boundaries of "Monday" and "September" are literally different moments. Every daily comparison is offset by hours and every month-end by a sliver of a day, which on a high-volume account is a real number of conversions landing in one system's September and the other's October.
Refresh clocks and data lag. Platform reporting is neither instantaneous nor uniformly delayed. Some metrics settle within hours. Conversions, especially modeled ones, settle over days, and cost and conversion data can finalize on different schedules inside the same platform. A dashboard pulled Monday morning for the week just ended is a partial read, and how partial varies by metric.
The practical rule: pick a reporting lag and hold it, including in the good weeks and the week someone wants numbers early for a board deck. The alternative is a team that quietly learns the numbers change depending on who pulled them and when.
The exception: real-time views are still right for operational decisions. Spotting that a campaign spent its daily budget by noon doesn't require settled data. Use the live view to act on the account and the lagged view to report on it, and never let the two swap jobs.
Which number should you actually trust?
There is a hierarchy, and it holds regardless of your stack.
First: your CRM or order system. The only system that records whether a sale happened at all, counted once, in your business's own time. It has no view of which ad caused anything, which is fine, it answers "how many, and for how much," the only question finance is actually asking.
Second: a reconciliation layer. One place where every platform's reported activity is matched against those orders under a consistent rule. This is the number that goes in the report.
Third: platform-reported numbers. Useful in their lane: the right signal for in-platform bidding, the right place to diagnose delivery, the wrong basis for moving budget from Meta to Google.
The mildly contrarian part: most teams invert two and three. They work at making the platform numbers correct and treat the CRM as a sanity check that occasionally causes an argument. Flip it. The order system is the spine. Everything else is a claim about the spine.
What does a reconciliation layer actually do, mechanically?
Not "integrate your data." Four specific jobs, in order.
1. Pull continuously, from everything
Every connected ad platform plus the order system, on a schedule, through APIs, not a weekly CSV export done by hand. Not for convenience: manual exports have no memory. They can't detect that last week's number was restated, because last week's number exists only in a spreadsheet tab nobody will reopen. The real cost of doing this by hand is mostly that, not the hours, but an output that can't be audited afterward.
2. Normalize the windows and the clocks
Restate every platform's reporting onto one time zone and one attribution basis before comparing anything. You're not making the platforms agree, you're removing the purely bookkeeping differences so the ones that remain are real. Record each platform's native setting too, so you can always explain the delta between its dashboard and your report.
3. De-duplicate against ground truth
The core move. Instead of adding platform conversions together, match each platform's claimed conversions to actual orders. An order both Google and Meta claim is one order: it appears once in the total, with the claims held alongside it as claims, not as extra sales. Which credit rule you pick matters less than it being one rule, applied identically every time, written down. An arguable rule applied consistently beats a perfect rule applied by whoever built this month's deck.
4. Attach a verdict to specific changes
A reconciled number tells you what happened, not what caused it. The last job is tying each change made in the account to the reconciled outcome that followed, so "ROAS improved" becomes "this bid change, made on the 3rd, graded against a stated hypothesis: improved / hurt / neutral." That's the step that turns a report into evidence.
What this is not: an attribution model. Reconciliation doesn't decide who deserves credit; it establishes what happened so any model on top has a real denominator. Skipping straight to a sophisticated attribution model on unreconciled data builds a precise answer to an unreliable question.
What can you recover once the signal is lost, and what's gone for good?
Be honest about this, because vendors usually aren't.
Recoverable: order counts and values, always, that's your order system. The fact that a platform claimed an order. Order-level overlap between platforms. Trends and period-over-period comparison, as long as your method is stable. Enough to allocate budget defensibly.
Not recoverable: the individual journey for conversions where the identifier is gone. You cannot rebuild, after the fact, the deterministic path of a customer whose signal was never captured. No tool can. Anyone selling "full-funnel identity resolution" that restores individual-level truth on lost signal is selling you a model and calling it a record.
You don't need person-level truth to make good budget decisions. You need order-level truth, a consistent method, and a record of what you changed. That's achievable; reconstructing the post-signal-loss past at the person level isn't, and chasing it burns quarters.
The edge case: incrementality testing, measuring the difference in orders, doesn't depend on tracking individuals at all. It's slower and costs real money in suppressed spend. It's also the only method that answers "would this have happened anyway," which reconciliation never can. Use it for the big allocation questions, not the weekly ones.
How do you present reconciled numbers to a finance team that's already seen three dashboards?
This is a credibility problem before it's a data problem. If finance has watched marketing produce three different answers, the fourth is not believed just because it's better.
- Lead with the order system. Start from the number finance already trusts, orders and revenue from the system that bills customers, then show ad spend against it. You're on their ground, using their number, which changes the tone before you've explained anything.
- Show the reconciliation, don't hide it. One line: Google claimed X, Meta claimed Y, the sum is X+Y, actual orders were Z, overlap accounts for the difference. A clean number with no trace of how it was produced is what got you here.
- Name the method once and don't change it. State the attribution basis, time zone, and reporting lag at the top of every report, in the same words. When the method changes, say so and show one period both ways.
- Separate the estimate from the record. Anything modeled gets labeled modeled. Finance is comfortable with estimates, they build forecasts for a living. They are not comfortable with an estimate presented as a count.
What if the platforms and the CRM still disagree after reconciliation?
Some gap survives even a well-built reconciliation layer. It usually comes from one of four sources.
- Lag, a settled CRM number compared against a platform number still restating.
- Definitional mismatch, the platform counts a lead form submit, the CRM counts a closed order. Different events; no matching rule makes them equal. Decide which one the report is about.
- Genuinely untracked orders, phone calls, offline sales, an untagged checkout path. Real revenue no platform can see. It belongs in the total, not in any platform's claim.
- Modeled residue, what's left after all of the above. The irreducible part.
Then set a tolerance and write it down. A small, stable, explained gap is a functioning system. A gap that swings widely from month to month is a broken pipeline, and the swing, not the size, is the alarm. Track the gap as its own metric. A tracked gap is a health indicator; an untracked one is a future argument.
Frequently asked questions
Related reading
- Your ROAS Is Lying: Cross-Platform Numbers , what happens to a single blended ROAS figure once overlap and modeled data are inside it.
- See how incrementality testing answers the "would this have happened anyway" question reconciliation cannot.
- Talk to us on the contact page about building a reconciliation layer for your accounts.
Reconciliation is only worth building if something acts on the number at the end of it, a change, a hypothesis, and a graded verdict. Start with a free audit.
Start a free audit