A GA4 Purchase Tracking Checklist for Online Stores

List the integrations that can send purchase information: a platform connection, a customer event integration, theme code, a tag container or another supported mechanism. Do not assume a visible tag proves that one clean implementation is responsible for every event.

Record the analytics property, data stream and implementation owner. If several teams have changed the setup, ask them to explain the intended event path. The first audit output should be a comprehensible diagram or short description of that path, not an immediate decision to add another tag.

Agree what outcome should produce a purchase event in the particular checkout flow. A cart button click or a payment attempt should not be mistaken for a completed order. Review any separate payment, confirmation or order-status experience that affects when the event can be sent.

Google Analytics provides a recommended ecommerce event model, including purchase events and event-level and item-level information. Use the documented model as the implementation reference while keeping the business definition visible. The event name alone is not enough to confirm the measurement is correct.

Check the transaction identifier, the value being reported and its currency. Document the treatment of shipping, tax and any other relevant amount so the team knows what a comparison with the store report means. Avoid treating differently defined totals as evidence of a defect by themselves.

Inspect item information as well as the order total. Product identifiers, names and quantities should describe the purchased items consistently. If the store sells bundles or multiple variants, include one of those cases in the acceptance plan rather than checking only a single simple item.

Repeated events can come from overlapping integrations or an event being triggered more than once in the customer journey. Missing events may involve an unsuccessful integration, a blocked or unsupported path, a configuration issue or visitor consent behaviour. Investigate the observed case instead of guessing one universal cause.

Use the platform’s supported debugging tools and appropriate browser diagnostics in a controlled review. Record which event arrived, its parameters and the step that triggered it. The goal is to identify the path responsible for an observation before removing or replacing it.

Choose an appropriate controlled test or agreed sample and record the order reference, time and currency. Compare it with the relevant event evidence, allowing for report processing and differing definitions. Keep debugging evidence separate from a broad claim that every historical order has been recovered.

If the store’s recorded sales and an advertising report differ, review attribution settings and the systems being compared as a separate task. A website purchase, a GA4 purchase and an attributed ad conversion answer related but different questions.

Document the event source, fields reviewed, test cases and any limits. Include who may change the implementation and which releases require another check. Checkout updates, new integrations and new markets can all justify a targeted review of the measurement path.

Before signing off, confirm:

• A controlled completed purchase produces the intended event.
• Order and item fields use the agreed definitions.
• Currency is explicit and matches the test case.
• Overlapping integrations have been reviewed.
• The team understands which historical or attribution questions remain separate.

Reliable measurement begins with a shared definition and reproducible evidence. It does not require every dashboard to display the same number, but it does require the team to understand why a number appears.