Connecting marketing data to actual sales: building the missing data layer

Ask a marketing team how a campaign performed and you will get an answer within minutes: impressions, clicks, cost per lead, platform-reported conversions. Ask what that campaign contributed to revenue and margin, by customer segment, net of returns, and the answer takes a week - if it arrives at all, and usually with a caveat attached.

This is not a competence problem. It is a boundary problem. The systems that record acquisition and the systems that record revenue were built for different purposes, by different vendors, for different departments, and nothing in either of them was designed to make the join.

Where the disconnect actually happens

It helps to be precise about where the chain breaks, because the fix is different at each point.

Advertising platforms report on their own terms. Each platform measures conversions using its own attribution window and its own view of what a conversion is. Those numbers are internally consistent and mutually incompatible. Summing them across platforms produces a total that overstates reality, because several platforms will each claim the same customer.

The CRM holds an identity that does not travel. A lead exists as an email address, perhaps a phone number, perhaps a company name entered by hand. The same person may appear three times with different spellings. When that lead becomes a customer, the CRM record and the transaction record are frequently linked by nothing more durable than a name.

The ERP or POS holds the transaction that matters, and nothing about its origin. This is where the real number lives: what was invoiced, what was discounted, what was returned, what it cost. It is also the system least likely to carry any acquisition context at all.

E-commerce sits in between, and is often assumed to be authoritative. Its order data is closer to the marketing side, but it is rarely the final word on revenue once returns, cancellations, payment failures and post-sale adjustments are applied in finance.

Finance reconciles at the end of the month. By the time the authoritative number exists, the decision it should have informed was made four weeks ago.

Identity is the first real problem

Before anything can be attributed, a customer has to be the same customer across systems. This sounds like a technical exercise and is mostly a definitional one.

A business-to-business company has to decide whether the unit of analysis is the individual contact, the buying entity, or the parent group - and those three answers produce materially different pictures of channel performance. A retailer with both online and physical sales has to decide whether an anonymous in-store purchase can ever be linked to an acquisition event, and what to do with the large share that cannot.

There is no universally correct answer. There is only a documented, agreed answer, applied consistently. The failure mode we see most often is not a wrong rule; it is three different rules applied in three different reports, none of them written down.

Practically, identity resolution means a deliberate matching strategy - deterministic where reliable keys exist, probabilistic where they do not, with match confidence recorded rather than hidden - and an explicit decision about how unmatched revenue is treated. Unattributed revenue should appear in the reporting as its own visible category. When it is silently redistributed, every other number becomes untrustworthy.

Attribution is a business decision, not a model choice

Teams often approach attribution as a selection problem: last touch, first touch, linear, time decay, data-driven. That framing skips the question that matters.

Attribution models answer a question about credit. Before choosing one, the business has to say what the credit will be used for. Budget reallocation between channels, evaluating a new channel, judging an agency, or forecasting next quarter are four different questions, and they do not all want the same model.

Two practical positions are worth holding. First, an attribution model should be explicit and documented, so that when a channel's performance changes, the team can tell whether reality changed or the rule did. Second, the model should be applied to the same underlying joined data regardless of which view is produced - the point of the data layer is that different models become different lenses on one dataset, rather than different datasets.

Sophistication has a ceiling set by data quality. A carefully specified model applied to poorly matched identities produces precise nonsense.

Batch or real time

Real-time data is frequently requested and rarely needed at the frequency requested. The useful question is: what decision would be made differently if this number were an hour old instead of a day old?

For most marketing-to-revenue reporting, a daily refresh is sufficient, because budget and campaign decisions operate on weekly cycles. Spend pacing against in-day performance may justify hourly. Stock availability feeding into whether a campaign should be running at all is one of the few genuine near-real-time cases, and even there the constraint is usually the source system rather than the pipeline.

Frequency has a cost: more complexity, more failure modes, more operational attention. Choosing it per data type rather than as a global setting is one of the more effective ways to keep a data platform affordable.

The more important timing property is predictability. A number that is always available by eight in the morning is more useful than one that is usually available within the hour and occasionally not at all.

Architecture principles that hold up

• Land raw data first, transform afterwards. Keep an unmodified copy of what each source system returned. When a number is challenged six weeks later, the ability to reconstruct how it was derived is what settles the argument.
• One definition per concept, stored once. “Revenue”, “customer”, “channel” and “margin” should be defined in the data layer, not re-derived in each dashboard. Definitions living in individual reports is how two decks disagree in the same meeting.
• Reconcile against finance before publishing anything. If the platform's revenue figure does not tie to the authoritative financial number, the difference must be explained before anyone builds on it. This step is skipped constantly and it is the main reason data platforms lose credibility in their first quarter.
• Make freshness and completeness visible. Every view should show when its data was last updated and whether any source failed. A dashboard that silently displays stale data is worse than one that is down.
• Design for schema change. Source systems change fields without warning. Pipelines should fail loudly on an unexpected structure rather than quietly ingesting nulls.
• Start with one decision. The first deliverable should answer one question the business genuinely cannot answer today, in production. Breadth after credibility.

What management actually gets from this

The visible output is usually a small number of views: revenue and margin by channel and campaign; customer acquisition cost against realised customer value rather than projected; repeat purchase behaviour by acquisition source; and the share of revenue that cannot be attributed at all, stated honestly.

The less visible output matters more. When marketing and commercial teams work from the same joined dataset, the conversation changes from whose number is right to what to do about it. That shift is usually worth more than any individual metric on the dashboard.

Where AI becomes useful - after the join, not before

Once the data layer exists, several things become possible that were not before: modelling which acquisition patterns predict high-value customers, forecasting demand by channel with reasonable confidence, flagging anomalies in spend-to-revenue relationships early, and grouping customers by behaviour rather than by the segments someone defined years ago.

All of these depend on joined, reconciled, reasonably clean historical data. Applying them before the join is the most common way to produce a model that is confidently wrong. The sequence is not a preference; it is a dependency.

Related reading

• Data & Intelligence - how we build this layer in practice
• From AI proof of concept to production