End-to-end Analytics

What end-to-end analytics is

End-to-end analytics is not a report or a tool but a data model. Its job is to connect in one row
what a company keeps in four separate systems:

Ad system → Site / app → CRM → Accounting
  click, spend   session, events   order   payment, return

While those systems live apart, each answers its own question and none answers the main one: how
much money came back per unit spent on a channel. The ad platform knows spend and clicks, web
analytics knows placed orders, the CRM knows confirmed ones, finance knows paid and returned ones.
On real projects the gap between those four numbers easily reaches tens of percent.

End-to-end analytics joins them on shared keys and makes payback computable on money rather than on
an event on the site.

Three levels of maturity

Building the full model at once is rarely worth it. In practice it advances by levels, and each one
unlocks a new class of decision.

At level one decisions are made on conversion, at level two on return on ad spend, at level three on
margin and lifetime value. Skipping a level is technically possible and produces precise arithmetic
over dirty inputs.

The identity stitching problem

The hardest part of end-to-end analytics is not reporting. It is that the customer is a different
object in every system.

One person who viewed a product on a phone, returned on a work laptop, ordered under a partner’s
email and collected it in store on a loyalty card produces four unconnected records. Without
stitching, the first mobile visit is credited to direct traffic and the channel that actually
produced it gets nothing.

That is what an identity resolution layer solves, usually inside a
CDP. It matches anonymous identifiers with known ones at sign-in or checkout and
retroactively attaches earlier anonymous sessions to the profile. The adjacent task is
customer deduplication: one person often exists as two or three
records in a CRM.

What counts as revenue

The most frequent error in end-to-end analytics is treating a placed order as revenue. A placed
order is an intention. Between it and money sits a chain of events, each of which reduces the sum:

Placed 100%
  − unconfirmed / unreachable
  − cancelled before dispatch
  − not collected (for try-before-you-buy delivery)
  − returned after purchase
= paid, non-returned revenue

The practical rules:

• Revenue is recognised on payment, not on placement. For prepaid models the gap is small; for
  fashion with try-ons and post-payment it is decisive.
• Returns are deducted from the channel and the mechanic that produced the purchase, not from
  the current month’s total. Otherwise a channel with heavy returns looks better than it is.
• The return window belongs in the reporting. If returns arrive up to 30 days later, a weekly
  return on ad spend is always provisional.
• Margin beats revenue when channels bring different categories.

Ignoring returns is the cheapest way to systematically overstate return on ad spend across every
channel at once.

Where a personalization platform fits

The boundary is worth stating plainly, because it is often blurred in sales conversations.

A personalization platform is not a web analytics system and does not replace an analytics suite
or a corporate warehouse. Its role in the model is different: it supplies attributed events of its
own — which widgets were shown, which strategy fired, which test variation the visitor was in, and
what revenue is associated with those interactions.

The practical point is that without that feed, the effect of personalization is invisible in the
end-to-end model: the order is credited to the traffic channel and the role of the on-site mechanic
is recorded nowhere. With it, the events can be joined to orders in the warehouse and the
contribution computed on the same rules as a channel’s — on paid revenue.

One caveat: attributing a widget click is weak evidence. It shows association, not causation. The
real contribution is measured by an A/B test or a holdout group, and
end-to-end analytics is what lets the difference between groups be counted in money rather than in
placed orders.

Implementation checklist

1. Traffic tagging. Every paid and campaign link tagged from one reference table. Check that
   redirects and mobile apps do not drop the tags.
2. One event schema. An agreed list of site and app events with identical names and parameters.
3. A shared order key. The same order_id on the site, in the CRM and in accounting. Cheaper
   than any later heuristic matching on amount and timestamp.
4. A customer identifier. Passing the known ID at sign-in and checkout, stitched to anonymous
   sessions, into one profile.
5. Order status history. Not the current status but the history of changes — otherwise
   retroactive recomputation of returns is impossible.
6. A revenue recognition rule. Written down and applied identically in marketing, finance and
   product.
7. Control totals. Monthly: revenue in the model against revenue in the accounts. A gap above
   2–3% is a reason to look for a break rather than to round.
8. A causality check. For on-site tools and changes, an experiment with a control group, not only
   an attribution report.