The recurring meeting where marketing's numbers and sales' numbers disagree is rarely about analytics. It is about the fact that three systems each hold a partial view, nobody has declared which is authoritative for what, and each team is quoting the system that is most convenient to them.
Deciding ownership once, in writing, resolves most of it.
The three systems and what each is actually for
The ad platform
Authoritative for: spend, impressions, clicks, video views, creative-level delivery, audience match rate.
Not authoritative for: anything about accounts, anything about pipeline. Platform-reported conversions are useful for optimisation and should never be quoted as business outcomes — they are attributed on the platform's own model, in the platform's favour, on a window it chose.
The CRM
Authoritative for: accounts, opportunities, amounts, stages, close dates, ownership. If it is money, the CRM wins, and marketing should stop arguing about this permanently.
Not authoritative for: why an opportunity exists. Self-reported source fields and last-touch attribution are directionally interesting and precisely wrong. Nobody's CRM knows that the CFO saw four ads before the referral conversation happened.
The account layer in between
Authoritative for: the join. Which accounts were reached, which functions engaged, what each account saw and when, engagement stage and score, cost per account reached and moved.
This is the layer most stacks are missing, and its absence is why the argument keeps happening. Without it, the only available join between spend and revenue is a session-level one that cannot survive a four-month buying cycle.
Who owns which number
| Number | Authoritative system | Common mistake |
|---|---|---|
| Spend | Ad platform | Reconciling against invoices monthly and treating the difference as an error rather than as billing timing |
| Accounts reached | Account layer | Reading it from platform reach figures, which count people |
| Engagement stage | Account layer | Recomputing it in the CRM with different thresholds |
| Opportunity value | CRM | Marketing keeping a parallel figure |
| Influenced pipeline | Account layer, using CRM values | Computing it with an unstated touch definition |
| Cost per account moved | Account layer | Not computing it at all |
The joins that go wrong
Company name to CRM account
The single most common failure. "Ravensbourne", "Ravensbourne Group" and "Ravensbourne Logistics Holdings Ltd" are three strings and one company. Join on normalised domain wherever possible, keep an alias table, and treat the unresolved list as a work queue rather than as an acceptable residual.
Person to company
Personal email addresses on form fills, consultants, contractors, and people who changed jobs three months ago. Any join that depends on email domain will lose a meaningful share of real contacts and misattribute a few.
Subsidiary to parent
Decide the rule once and apply it in every system. The failure is inconsistency: the ad platform targeting the parent, the CRM holding subsidiaries, and the account layer rolling up differently from both. That produces three defensible numbers that do not match.
A reporting layer that holds up
Four properties, in rough order of importance:
- Account-first. Every metric computed from the target list outward, so unreached accounts are rows rather than absences.
- Definitions visible in the interface. If a reader has to ask what a number means, the definition is in the wrong place. It belongs next to the number, not in a data dictionary nobody opens.
- Queryable by machines. An API, and increasingly an MCP endpoint, so that the reporting layer can be interrogated by your own tooling rather than exported to a spreadsheet that immediately goes stale.
- Historically stable. A number computed for Q1 should return the same value when someone recomputes it in Q3. Models change, and a layer that silently backfills new logic onto old periods destroys trust in every number it has ever produced.
That last one is the least glamorous and the most important. Most reporting credibility is not lost through a wrong number. It is lost when a number that was right in March is different in June and nobody can explain why.