28 January 2026 · Methods
Session replay is not a substitute for an event stream
Replay is a microscope. An event stream is a contract. Teams that try to run finance reporting off heatmaps eventually invent event names in a slide instead of in the binary.
We like replay. Module 01 of Checkout Event Instrumentation starts with recordings, not spreadsheets. You can see the thumb hover on a size selector, the back-navigation from shipping, the WebView that swallows payment. None of that arrives as a typed parameter. None of it can be joined to an order id at month-end.
What replay cannot sign
A parameter contract says: purchase.value is a number in THB, item_id is the catalogue key, coupon is nullable, user_id is omitted for guests. Replay can show that a guest completed COD. It cannot guarantee the payload contained currency. When Android 12 truncates a coupon string, replay looks fine and the warehouse quietly drops the row.
Privacy is the other failure. Replay tools often capture address forms unless someone remembers to mask. That is a PDPA incident waiting on a default setting. Event streams, designed with fences, never receive those fields. Using replay “just until we have events” is how masking tickets linger for a year.
A workable division of labour
Use replay to discover intent changes and skipped screens. Write the event when the intent is stable. Use the stream for funnels, attribution inputs, and ledger matching. If a disagreement appears — replay shows a tap, the stream does not — treat it as an SDK timing bug, not as permission to report from replay.
Vendors will bundle both. That is convenient. It is not a reason to let the microscope become the system of record. The Commerce Floor retainer spends a surprising amount of time deleting “insight” tiles that were never backed by a named event.