Ecommerce Analytics Data Quality Audit: One-Day Checklist

August 10, 2026 · 7 min read

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

System	Question it should answer
Web/app analytics	How did a customer reach an action?
Storefront/OMS	Which orders were created?
Payment platform	Which payments succeeded or were refunded?
ERP/finance	Which orders were fulfilled and recognised?
CRM/CDP	How are customers and cohorts identified?
Ad platforms	How does each platform attribute conversion?

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

Event	Trigger	Required fields	Exclusions	Owner
view_item	Item detail is meaningfully shown	item_id, name, price	Bots, admin preview	Analytics
add_to_cart	Item is successfully added	item_id, quantity, price	Failed action	Product
begin_checkout	Checkout journey begins	basket, value, currency	Empty basket	Product
purchase	Approved commercial milestone	transaction_id, value, currency, items	Tests, duplicates	Ecommerce
refund	Approved refund milestone	transaction_id, value/items	Pre-payment cancellation	Finance

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

Control	Calculation
Order coverage	Unique analytics transaction IDs / eligible OMS orders
Duplicate rate	Repeated purchase IDs / all purchase events
Value difference	Analytics value − OMS value for matched IDs
Unknown transactions	Analytics IDs without OMS order
Missing transactions	Eligible OMS orders without analytics purchase
Refund coverage	Analytics refunds / eligible finance refunds

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

Field	Value
Period and time zone
Eligible-order definition
Systems compared
OMS orders
Unique analytics purchases
Duplicates
Missing events
Value difference
Affected segment
Known reason
Fix owner
Next validation

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.

Read next: Product Page Data Quality Audit · Ecommerce Checkout Friction Audit · Ecommerce Peak Sales Readiness Checklist · Shopify Script Tags Deprecation: Store Audit Checklist · Run a free site check.