/Docs
ETEN

Engine revenue vs total revenue

What it is

Total revenue is the sum of all store orders in a period. Engine revenue (attributed revenue) is the sum of the orders where a recommendation touch was found with sufficient evidence (the attribution levels from direct purchase down to view-assisted purchase).

How it is computed

Every order lands in exactly one level, so a euro is never counted twice — engine revenue and control revenue are two slices of the same whole. An attributed order contributes its full amount to engine revenue (not a weighted fraction).

Email revenue (click-based)

The Insights campaign table shows an "Email revenue (7d)" column next to engine revenue. It answers "how much money did this email bring in at all", not just "how much did the recommendations bring":

  • An order counts under an email when the customer clicked any link in that email (not just a recommendation) within 7 days before the order.
  • Every order counts under exactly one email — last click wins.
  • Engine-attributed orders are always included, so engine revenue is always a subset of the email's revenue.

This is the same methodology used by GA/UTM-based "Campaign Revenue" tools (such as Smaily's), but computed from our data. The numbers will NOT match Google Analytics one-to-one, and that is expected:

  • We match by contact, GA matches by session/device. If a customer clicks the email on their phone and buys later on a laptop, GA loses the connection and we do not — our number therefore tends to be higher.
  • GA loses part of the traffic to consent banners and ad blockers. Our click data comes from the Smaily action log, which is unaffected.
  • A guest checkout under a different email address stays unmatched on our side (in GA the UTM may live on in the session) — here we lose some.
  • History starts when data collection started: campaigns older than our click history show "—" in the column.

How to interpret it

  • Engine revenue is a lower bound, not the exact impact. Because of the evidence bar, some real influence (e.g. a customer saw a recommendation and later searched the store for it) ends up on the control side.
  • Email revenue and engine revenue side by side show what share of the money an email brought in came from the personalised recommendations.
  • Do not compare engine revenue directly with other tools' "email revenue" — many count every purchase preceded by any open. We do not. Same logic as excluding the open-based "influenced purchase" from revenue.
  • To prove impact, use incrementality measurement — attribution shows association, the holdout proves causation.

Common misreadings

  • "Engine revenue is small — is the engine not working?" — check three things first: (1) is the store plugin installed and passing recommendation links through, (2) how long the system has been running at all (signal accumulates over weeks), (3) what share of your emails actually contain recommendation blocks.
  • "Can I add total revenue and engine revenue together?" — no, engine revenue is a part of total revenue, not an addition to it.

Technical background

Computation: lib/metrics/compute-daily.ts (ATTRIBUTED_TYPES, total_revenue_attributed, control_revenue); the same list is used by campaign rows (lib/smaily/campaign-rows.ts) and console Insights. Daily rows live in lift_metrics_daily (nightly cron + live computation of today/yesterday from the same code).

Email revenue: lib/smaily/campaign-rows.ts (totalRevenue) — the customer's last click from email_events ≤7 days before the order, unioned with engine attribution at the order level. Engine attribution wins per order because Smaily does not track recommendation-field links the way it tracks regular campaign links — the store plugin's cookie path covers clicks that never reach the action log (see attribution).

Last updated: 2026-07-08