Connecting CRM activity to revenue you can defend
A practical route from campaign metrics to CRM revenue: define incremental lift, agree an attribution rule and report numbers finance will accept.
Most CRM teams can tell you their open rate to one decimal place and cannot tell you what the programme is worth. That gap is why CRM budgets get cut first in a tight quarter.
The problem is rarely a lack of data. It is that three different numbers all get called "CRM revenue", nobody has agreed which one is being discussed, and the finance team has quietly stopped believing any of them.
Fixing this is less about analytics sophistication than about agreement. Pick a definition, write it down, instrument it once, and report the same number every month even when it moves in the wrong direction.
Separate the three numbers people confuse
There are three distinct figures, and mixing them is the root of most CRM reporting arguments.
- Attributed revenue: orders where a CRM touch appears in the customer's path, under some attribution rule.
- Influenced revenue: revenue from customers who received any CRM contact in a period, with no claim of causation.
- Incremental revenue: the difference between what happened and what would have happened without the programme.
Attributed revenue is easy to produce and easy to attack. Influenced revenue is almost always a large number and almost always meaningless. Incremental revenue is the only one that answers the budget question.
Report all three if you must, but label them clearly and tell people which one you are managing towards. We manage towards incremental revenue and use attributed revenue as an operational signal for campaign triage.
Agree an attribution rule before you build the report
An attribution rule is a business decision dressed as a technical one. Agree it with finance and analytics in a single meeting, and record it in writing.
Three choices to settle:
- Window length. Seven days after click is a common starting point for email, shorter for push, longer for considered purchases.
- Touch type. Does an open count, or only a click? Our default is click, because opens have been unreliable since privacy protections became widespread.
- Credit model. Last CRM touch within the window is the simplest defensible rule. Fractional models are fine if everyone understands them.
Then hold the rule still. Changing the window mid-year makes year-on-year comparison impossible and invites the suspicion that the number was tuned.
Use holdouts as the default, not the exception
A holdout group is the cheapest way to make a CRM number credible. Withhold the programme from a random sample, compare revenue per recipient over a fixed period, and the difference is your lift.
We run two layers. A small global holdout, typically one to five per cent of the addressable base, kept out of all marketing contact and refreshed on a fixed schedule. Then per-campaign holdouts on high-volume sends.
Some practical rules we apply:
- Randomise at the customer level, not the send level, or the same people keep getting held out.
- Keep the global holdout stable for at least a full purchase cycle before reading it.
- Exclude transactional and service messages from the holdout. You cannot withhold a delivery notification.
- Measure revenue per eligible customer, not per opened email, so the comparison is fair.
Expect the incremental number to be smaller than the attributed one. That is the point. A programme that shows attributed revenue ten times higher than measured lift is telling you it is largely claiming credit for purchases that would have happened anyway.
Instrument the data once, in the warehouse
Reporting built inside the engagement platform will always be limited to what that platform saw. Orders, returns, margin and customer history live elsewhere.
Land send, delivery, open, click and unsubscribe events in the warehouse alongside order data, and join on a stable customer identifier. Then build the revenue report there, once, and let the platform handle operational metrics only.
This also removes a familiar argument. When the platform and the finance report disagree, you want one join to inspect rather than two black boxes to compare.
If your event data is patchy or your identifiers do not join cleanly, that is an audit job before it is a measurement job. Our CRM audit checklist covers the data checks we run first.
Report in a format finance will accept
Finance cares about three things: what the programme cost, what it returned, and how confident you are. Build the monthly report around those.
Include the cost side honestly. Platform licence, data infrastructure, agency or team cost, and any incentive or discount funded by CRM. Discount cost in particular is often missing, and it is usually the largest variable.
Show confidence intervals or sample sizes on lift figures. A measured lift of four per cent with a wide interval is an honest statement. The same number presented as a point estimate will be treated as a point estimate forever.
Keep the report short. One page with revenue, cost, net contribution, lift, and a two-line commentary on what changed. Detail belongs in an appendix that nobody reads and everyone is glad exists.
Where teams want help building this end to end, that measurement work sits inside our optimisation practice.
What to do this week
- Write one sentence defining your CRM revenue number, including window, touch type and credit model, and send it to finance for agreement.
- Set up a global holdout of one to five per cent, randomised at customer level, and note the date you started it so you know when it can be read.
- Pull last month's attributed revenue and last month's discount cost into the same view, and see whether the net contribution is still positive.
- A CRM audit checklist that changes what you ship next · 12 May 2026