Amplitude for e-commerce · every vendor claim below is Amplitude's own, source-linked
Amplitude for e-commerce: when the funnel is literally the revenue
E-commerce is the vertical where analytics mistakes have a price tag on them: a double-firing purchase event overstates revenue, a guest checkout that never merges undercounts repeat buyers, and an unattributed order flatters the wrong channel. All three are instrumentation choices.
Where does e-commerce instrumentation go wrong?
At the three seams. Revenue: purchase events fired client-side double-fire on refresh and vanish under ad blockers - the order count in Amplitude drifts from the order count in the shop, and trust dies in the first weekly meeting. Identity: guests check out, then create accounts, then buy on the app - and each becomes a separate 'user' unless the merge is designed. Attribution: the click IDs and UTMs are captured (or stripped by redirects and consent layers) before anyone looks, so channel questions inherit whatever the landing infrastructure did.
Our position (judgment, from running our own Amplitude-instrumented commerce property and enterprise analytics practice): treat 'Order Completed' as a ledger entry, not a pageview - server-side, reconciled, and owned - and let client events describe the behavior around it.
What does Amplitude itself say about e-commerce tracking?
Amplitude's own getting-started guidance includes an ecommerce question-to-chart map - useful because it shows which chart answers which merchandising question (source below):
| Capability | Amplitude’s published position |
|---|---|
| Top referrers / sources | Event Segmentation or Data Table - and Data Tables carry the nine attribution models (first/last touch, linear, U/J-shaped, data-driven) for credit questions |
| Referrer with highest purchase conversion | Funnel Analysis |
| Items viewed per session / most-viewed / most-purchased items | User Sessions and Event Segmentation |
| View-to-order conversion and time-to-order | Funnel Analysis |
| Weekly purchases and total revenue by period | Event Segmentation |
| Customer lifetime value | Revenue LTV chart |
Also documented by Amplitude and load-bearing for shops: automatic capture of all six UTMs, a dozen ad click IDs, and referrer in the Browser SDK; official GTM templates (web + server) for dataLayer-driven stacks; and Targeted Replay Capture, which spends the replay quota on the sessions you define - 'Checkout Started' being the canonical example in their own docs.
What we build - the shop's half of the work
| Deliverable | What it covers |
|---|---|
| Purchase-journey taxonomy | Our standard retail event chain - View Item → Add to Cart → Checkout Started → Payment Entered → Order Completed - with typed properties (product_id, value_usd converted at event time, quantity) and one enforced naming grammar. This chain is our practice standard; Amplitude's starter guidance is deliberately minimal. |
| Server-side revenue | Order Completed and refunds instrumented from the commerce backend (or server GTM) as the authoritative stream; client checkout events for behavior; a scheduled reconciliation of Amplitude order counts against the shop's own - the check that keeps Monday meetings short. |
| Guest-to-account identity | Merge design for the guest checkout → account creation → repeat purchase path, cross-device by internal customer ID - so 'repeat buyer rate' measures buyers, not cookies. |
| Attribution that survives the stack | UTM/click-ID capture verified end-to-end through redirects, consent gating, and checkout domains - then read through funnels and Data Tables attribution models instead of last-click folklore. |
| Checkout replay, targeted | Targeted Replay Capture conditioned on checkout events so the replay quota watches the money path - masked per your privacy posture, consent-gated like everything else. |
We run Amplitude on our own e-commerce demo property, so implementation patterns on this page are ones we operate, not just recommend. Deliberately absent: revenue-lift claims - we publish no outcome numbers without a named, approving client.
Related: the implementation sprint this work rides in, the taxonomy linter that catches PII-shaped event names mechanically, and the identity resolution guide underneath the deletion story.
Sources
- Amplitude docs: What events will you need (ecommerce questions-to-charts map)
- Amplitude docs: Browser SDK 2 (UTM/click-ID/referrer capture)
- Amplitude docs: Data Tables attribution models
- Amplitude docs: Google Tag Manager (web + server templates)
- Amplitude docs: Targeted Replay Capture ('Checkout Started' example)
- Amplitude docs: Revenue LTV chart
Frequently asked questions
Should e-commerce purchase events be client-side or server-side?+
Server-side for the money, client-side for the behavior. A backend-fired Order Completed can't double-fire on a refresh, doesn't vanish under ad blockers, and can carry ledger-true values - while client events cover browsing, cart, and checkout behavior. Amplitude documents both SDK and server ingestion paths plus official GTM templates (web and server containers); the split is an architecture decision the tracking plan makes explicit.
Why don't our Amplitude revenue numbers match the shop backend?+
The usual suspects in order: client-side purchase events double-firing or being blocked, refunds never instrumented, guest orders splitting identity from account orders, and currency conversion at query time instead of event time. Each is diagnosable - the warehouse/backend agreement check is one of the ten dimensions in our free audit.
Can Amplitude measure customer lifetime value?+
Yes - the Revenue LTV chart exists for exactly this, per Amplitude's own docs, and its honesty depends entirely on two implementation inputs: revenue events that reconcile with the ledger, and identity that follows the customer across guest checkouts and devices. Get those two right and LTV becomes a chart; get them wrong and it's fiction with axes.
Start with the audit - regulated instances especially
The free scored audit reads your instance across ten dimensions, including the ones regulators care about: identity behavior, PII exposure in names and properties, access patterns, and warehouse agreement. Read-only access, 48-hour turnaround, NDA on request.
Request the free audit