How to build a tracking plan for an e-commerce mobile app
A practical event model from app open to purchase: names, parameters, ownership, server-side purchase and pre-launch validation.
A mobile commerce analytics tracking plan is an agreed contract defining each event, its trigger, required parameters, business question and validation owner. It should exist before SDK implementation. Purchases must be confirmed by the backend rather than inferred only from a success screen.
Start with business questions, then name events
An event list without a decision behind it quickly becomes telemetry clutter. Start with questions: where customers drop off, which searches return no products, which channel attracts buyers, which payment method fails and whether customers return after the first order.
Then map the journey to events. Names should describe completed behaviour, such as view_item, add_to_cart and begin_checkout. Parameters carry context: product, category, price, currency, cart, campaign and app version. This is the foundation of useful e-commerce mobile app analytics.
Minimum viable event taxonomy
Version one does not need one hundred events. It needs a complete purchase journey and a small set of diagnostic signals. Every event needs one trigger definition and a required parameter list.
- app_open and view_item — entry and product interest.
- search and search_no_results — demand and catalogue gaps.
- add_to_cart, view_cart and begin_checkout — purchase intent.
- add_shipping_info and add_payment_info — delivery and payment friction.
- purchase, payment_failed and refund — system-confirmed financial outcomes.
- push_open and loyalty_redeem — customer return and loyalty use.
Purchase and refund must come from the backend
A thank-you screen is not a source of truth: the app can close, the payment callback can arrive later and the customer can return through a deep link. Send purchase after payment confirmation and order persistence, with a unique transaction_id. The same identifier prevents duplicate reporting.
Validate before launch
QA walks the full funnel on iOS and Android, compares parameters with the contract and tests failure paths: offline use, payment retry, provider return, coupon, empty search and refund. Compare revenue reporting with the backend on a controlled order sample.
- Approve taxonomy and owners.
- Implement events through one app layer.
- Confirm purchase and refund server-side.
- Inspect parameters in debug mode.
- Reconcile reports with backend orders.
- Freeze the launch contract version.
Owner, version and change process
A tracking plan does not end at launch. Every new checkout field, shipping option, loyalty flow or experiment can change the data contract. The document therefore needs a version, date, business owner and technical owner. Renaming an existing event requires a migration plan or historical reports stop being comparable.
The simplest process resembles code review: the feature owner defines the question and expected event, analytics checks taxonomy consistency, engineering reviews the source and parameters, and QA adds test cases. Only an approved version reaches the app and dashboards.
Sources and a ready starting point
GA4 ecommerce events: https://developers.google.com/analytics/devguides/collection/ga4/ecommerce
Firebase Analytics: https://firebase.google.com/docs/analytics
Sample tracking plan CSV: https://gmi.software/resources/mobile-commerce-tracking-plan.csv
Frequently asked questions
- How many events should a tracking plan contain?
- Enough to reconstruct the key funnel and decisions. A first commerce release often needs 12–25 well-defined events rather than hundreds with no owner.
- Does GA4 automatically measure app purchases?
- No. E-commerce events and parameters require implementation, and purchase should preferably be confirmed by the backend.
- Who should own the tracking plan?
- A business owner owns questions and decisions, while a technical owner owns the contract, implementation and quality. Leaving the document only to developers or marketing usually creates gaps.
Content updated: August 26, 2026
Google Preferred Sources
See GMI more often in Google
Add gmi.software as a preferred source. Google may highlight our new articles more often in Top Stories and supported AI experiences.