Agree on the Number of Sales Before You Argue About Credit

The Argument You Can't Win

Here is a meeting that happens every month, in every marketing team spending real money.

Someone pulls up the dashboards. Google Ads says it drove 300 conversions. Meta says 250. Email says 120. The performance lead argues Google deserves more budget. The brand lead argues Meta is being undercredited. Everyone has a model in mind, and everyone's model happens to favour the channel they own.

The argument runs for forty minutes and resolves nothing, because it was built on a foundation nobody checked. Add those numbers up:

The channels claim 760 conversions for a month that produced 320 orders. Before anyone can argue about who deserves credit, there is a prior question nobody asked: how many conversions were there?

You cannot distribute credit for a number you haven't agreed on. And you haven't agreed on it.

The Counting Problem Comes Before the Credit Problem

There are two separate jobs hiding inside the phrase "marketing attribution," and the industry talks about them as if they were one.

Attribution models (first-touch, last-touch, linear, time-decay, Markov, Shapley) are all crediting tools. Every one of them takes a set of conversions as input and distributes credit across the touchpoints on each journey. None of them decides how many conversions there were. They assume that's already settled.

So when every platform claims credit for the same conversions, reaching for a better model is fixing the wrong layer. A Shapley model applied to double-counted data will carefully, defensibly, mathematically distribute credit for conversions that never happened twice. The sophistication is real. The input is wrong. Garbage in, Shapley out.

The order is not negotiable:

Most teams start at step 3 because that's where the tools and the arguments live. The leverage is at steps 1 and 2.

Why the Count Inflates

Three mechanics push the claimed total above the real one. They are the same mechanics that make platform reports disagree, seen from the counting angle instead of the crediting angle.

1. Overlapping claims

Each platform claims any conversion that falls inside its own attribution window, and those windows overlap. A buyer who touches Google on day 1 and Meta on day 15 before converting on day 20 is claimed by both. Google claims it under its 30-day click window, Meta under its 7-day one. One order, two claims. Neither platform is wrong under its own rules. But you can't sum rules that overlap.

2. View-through and modeled conversions

Platforms don't only count clicks. Meta counts conversions from people who merely saw an ad. Google and Meta both add "modeled" conversions, estimates of activity they couldn't directly observe, filled in by their own algorithms, conveniently on their own side of the ledger. These never appeared in your order table. They're in the claimed count anyway.

3. Fragmented identity

This one inflates the count even inside a single honest system. One buyer researches on their phone, then converts on their laptop. With no shared identity key, that's two visitors with two separate journeys and, depending on your setup, two counted conversions for one person. Cross-device buyers get counted more than once, and their journeys get chopped into fragments that attribution then mis-credits.

The first two make platforms over-claim against each other. The third makes even your own analytics over-count. All three land in the same place: a claimed total that's larger than reality, usually by 40 to 90 percent.

Start From the Transaction, Not the Ad

The fix begins by choosing the right source of truth for the count. There is a clean rule:

Count from the system that owns the money. Credit from the system that sees the journey.

Your Shopify, Stripe, WooCommerce, or CRM order table is the real conversion count. It records actual money changing hands, once per transaction. It has no incentive to inflate, because it isn't selling you ads. That number, 320 orders, is your denominator.

Everything the ad platforms report is a claim about that denominator, not an addition to it. Google didn't create 300 conversions on top of your 320 orders. Google is claiming credit for some subset of those same 320.

Once the denominator is fixed at 320, the argument in the meeting changes shape entirely. It stops being "whose number is bigger" and becomes "how do we split 320", which is a question a model can actually answer.

Resolve Identity, or the Count Stays Broken

Fixing the denominator with a clean order count solves overlapping platform claims. It does not, on its own, solve identity fragmentation. For that you need to stitch events from the same person together.

Identity resolution joins touchpoints on a shared key so one person's journey stays one journey:

The rule of thumb: your attribution quality is capped by your identity quality. If you can only stitch 60 percent of journeys back to a real person, then 40 percent of your conversions arrive as orphaned fragments, and no attribution model can credit a journey it can't see the start of.

This is also where server-side data collection earns its place. Client-side tracking loses 30-40 percent of touchpoints to ad blockers and browser privacy features, and those losses are not random. They skew toward specific audiences. Losing a third of your touchpoints means a third of your journeys start mid-stream, which fragments identity and inflates the count exactly where you can least afford it. Complete data is a precondition for a clean count, not a nice-to-have on top of it. (More on this in server-side vs client-side tracking.)

A Worked Reconciliation

Here's the full sequence on the numbers from the top of this article.

Step 1: establish the real total. Pull the order count from the transaction system.

-- The denominator. From the system that owns the money.
SELECT COUNT(DISTINCT order_id) AS actual_orders
FROM shopify_orders
WHERE order_date >= date_trunc('month', current_date);
-- → 320

Step 2: resolve identity across touchpoints. Join all channel events to a person via a shared key, so one buyer is one journey.

-- One journey per person, not per device or per platform claim.
SELECT
  identity_key,
  array_agg(channel ORDER BY event_time) AS journey,
  MAX(converted) AS did_convert
FROM touchpoints
JOIN identity_map USING (raw_id)   -- hashed email / user_id stitch
GROUP BY identity_key;

Step 3: credit the clean total. Now, and only now, run attribution. The models distribute the 320 real orders across the resolved journeys.

The result is not four numbers that sum to 760. It's one number, split:

Same raw data. The difference is that the count got fixed before the credit got argued.

What This Changes in the Meeting

The reason this matters is not tidiness. It's that the counting problem, left unfixed, silently decides budget.

When the performance lead argues from Google's claimed 300 and the brand lead argues from Meta's claimed 250, they're both arguing from inflated, self-serving numbers, and the louder advocate usually wins. Budget follows the argument, not the evidence. The channel that over-claims most aggressively gets funded most generously, which is exactly backwards, because aggressive claiming is a property of the platform's attribution settings, not the channel's real contribution.

Fix the count and the politics deflate. There is one total. It is not the ad platform's number, so no platform's advocate owns it. The conversation moves from "my dashboard says" to "here is how the 320 splits," and that's a conversation attribution models are built to have.

Summary

The phrase "every platform claims credit for the same conversions" describes a counting problem wearing a crediting costume.

1. There are two jobs, not one. Counting decides how many conversions there were. Crediting splits them across channels. Attribution models only do the second.
2. Summed platform claims always exceed reality, because of overlapping windows, view-through and modeled conversions, and fragmented identity.
3. The count comes from the transaction system, not the ad platforms. Orders are the denominator; platform claims are competing claims on that denominator.
4. Identity resolution sets the ceiling. You can't credit a journey you can't stitch back to a person, and complete server-side data is what keeps the stitch rate high.
5. Only then run the model. A clean total, split by attribution, is defensible. A model run on double-counted data is sophisticated nonsense.

Agree on the number of sales first. The argument about credit gets much shorter once everyone is dividing the same number.

Further Reading

• Why Your GA4, Meta and Google Numbers Don't Match — the crediting-side view of the same mechanics
• Is Your ROAS Real? — what over-claiming does to your return numbers
• Server-Side vs Client-Side Tracking — why data completeness sets the count
• What is Multi-Touch Attribution? — how credit gets distributed once the count is clean

Holly Mehakovic

Co-Founder, mbuzz

Holly Mehakovic is Co-Founder of mbuzz. With 10+ years in marketing including roles at Westpac, Avon, and Forebrite, she's obsessed with making measurement actually useful.

Harvard Extension School Forebrite Westpac Avon