Field notes
Naming purchase events without client-side guesswork
How product teams decide which checkout moments belong on the server when mapping events for connected mobile apps.
When a connected mobile app charges a card or renews a subscription, the moment that matters for revenue reporting almost always lands after the server confirms success. Client taps are useful for funnel diagnosis, but they are not the same as a settled transaction.
Start from the handler, not the button
We ask teams to open the handler that writes the order or entitlement record. That function — not the “Buy” press — is where the authoritative purchase_completed (or your house name) should fire. Properties such as currency, SKU, and promo code should come from the same record the finance team already trusts.
Separate intent from confirmation
Many catalogues collapse “checkout started” and “payment confirmed” into one name. That creates inflated conversion rates whenever a user abandons after the client UI advances but before the backend commits. Map both events, give them distinct names, and document which one feeds the board report.
Document what stays out
If a property only exists on the device — battery level, local A/B flag without server echo — leave it out of the server event. Mixing those fields into server payloads is a common reason analysts later distrust the map.
A practical check
Before you ship a new purchase property, ask: can we reconstruct this value from the database if the analytics warehouse is wiped? If the answer is no, the property probably does not belong on a server-side event for connected mobile apps.