Ecommerce Analytics Data Quality Audit: One-Day Checklist

An ecommerce analytics audit verifies that events describe the real customer journey and reconcile to commercial records under documented definitions. At minimum, test item view, add to cart, begin checkout, purchase, and refund. For purchase, validate a stable transaction ID, amount, currency, item detail, discounts, and deduplication.

The goal is not perfect equality between browser analytics and finance. It is a known, explainable gap that does not change unnoticed after a release.

At a glance

In one focused day, a team can:

1. approve an event dictionary;
2. run marked test scenarios;
3. inspect payloads and reports;
4. match transaction IDs with the OMS;
5. find duplicates, missing events, and tests;
6. validate currency, discounts, and refunds;
7. reconcile a full week;
8. define automated data-quality signals.

Assign systems to questions

Do not make one system pretend to be all of them. Analytics supports behaviour and attribution; the reconciled operations and finance stack supports commercial truth.

Step 1: approve an event dictionary

Define the purchase milestone explicitly. Some teams use order creation; others use confirmed payment. Both can be measured, but a dashboard must not compare unlike events without a label.

Step 2: run marked scenarios

Prepare expected events before execution:

1. standard order without a discount;
2. promotion or coupon;
3. several units of one item;
4. basket with several products;
5. guest checkout;
6. account checkout;
7. cancellation before payment;
8. authorised test payment;
9. partial refund where supported;
10. thank-you page reload or back navigation.

Use distinct test transaction IDs and exclude them from business and advertising reports.

Step 3: inspect four layers

Client layer

• event fires at the defined moment;
• names and data types match the schema;
• numeric value is not a formatted string;
• currency is explicit;
• no prohibited personal data is included;
• consent and blocked-script behaviour follow policy;
• page reload does not create a new purchase.

Tagging or server layer

• two containers do not send the same event;
• schema version is visible;
• retries can be deduplicated;
• rejected or malformed events are observable;
• test traffic is marked;
• client and server events share a deduplication key where both are used.

Analytics report

• event appears after the documented processing delay;
• transaction ID matches;
• item quantity and value are correct;
• discount and shipping follow the approved definition;
• region, channel, and device look plausible.

Commercial record

• the order exists in the OMS;
• its status is known;
• payment and refund IDs are linked;
• the test is excluded from management reporting.

Step 4: reconcile a complete week

Segment by device, browser, region, consent state, payment method, and release version. A tolerable aggregate difference can hide a complete measurement failure in one market.

Explain normal discrepancies

Possible causes include:

• script blocking;
• consent denial;
• page closure before client delivery;
• time-zone boundaries;
• different purchase definitions;
• reporting delay;
• call-centre or offline orders;
• refunds recorded in a later period;
• currency conversion;
• internal and test transactions.

Document normal does not mean ignore. Establish a range and alert when it changes materially.

Automate data-quality signals

Alert or create a ticket when:

• purchases disappear while OMS orders continue;
• transaction IDs become empty or non-unique;
• duplicate purchase events rise;
• currency or value becomes invalid;
• item arrays are unexpectedly empty;
• analytics-to-OMS coverage shifts outside range;
• one funnel step vanishes after a release;
• a scheduled marked order cannot be found.

Separate measurement-health alerts from actual sales-health alerts so responders take the correct action.

Copyable discrepancy card

Common mistakes

• firing purchase on a reloadable page without deduplication;
• using a non-unique transaction ID;
• omitting refunds;
• comparing created orders with paid orders;
• allowing tests into ad optimisation;
• changing schema without a version and release marker;
• sending unnecessary personal data;
• claiming accuracy without order-level reconciliation.

FAQ

Is a difference between GA4 and the OMS acceptable?

Yes. Client analytics may miss events, and definitions can differ. The important controls are documented eligibility, a known range, order-ID sampling, and alerts on material change.

Should purchase be sent client-side or server-side?

It depends on architecture, consent, and attribution requirements. Server delivery can be more durable but needs correct privacy handling, identity, and deduplication. Some implementations use both with one transaction ID.

How often should the audit run?

Run focused checks after checkout, consent, tag-manager, and payment changes. Automate weekly reconciliation and schedule a deeper review periodically.

Sources and further reading

• Google Analytics: measure ecommerce
• Google Analytics: set up a purchase event
• Google Analytics Data API schema

Reviewed: 10 August 2026.

Next: build an ecommerce business continuity plan, use the operations dashboard, and run the post-deployment checklist.

Pingvera complements analytics with an independent check that the journey works; analytics explains how real customers behave inside that journey.

---

Originally published at pingvera.com.