The store shows one number of orders, GA4 another, and the ad platform a third. The difference doesn't automatically mean all the data is wrong. Systems can have different rules and reporting moments. Still, missing events, incorrect values or duplicates can compromise decisions if they aren't investigated.
Verify measurement starting from an identifiable order and from the definitions of each report. Check the events, the transaction ID, the value, the currency and the products sent. Compare periods, time zones and compatible revenue bases. Separate implementation errors from the limits of attribution and consent. GA4 describes measured behaviour; it doesn't replace the commercial record of orders.
Contents
- What GA4 measures
- The event plan
- The test order
- Differences between reports
- Three examples
- Diagnosis and responsibilities
- Practical plan
- FAQ and checklist
What GA4 measures and what stays in the store
GA4 can record interactions and purchases through configured events. A visit, an add-to-cart and a purchase are different actions. The Google ecommerce documentation explains the events and parameters for products and transactions.
The store, however, keeps the operational status of orders: confirmation, payment, delivery, cancellation or return. If these changes aren't sent or reconciled, the revenue in analytics can differ from the final commercial result. Don't assume a purchase event automatically confirms final payment.
Define the metric before you use it
A conversion rate can have sessions or users as its denominator, depending on the report. An event can occur several times in one session. Read the metric's definition and don't rename a metric just to fit a commercial presentation.
For a decision, note the period, the population and the success condition. “Sessions with at least one purchase divided by all sessions analysed” is clearer than “2% conversion” with no explanation. The definition allows comparisons and prevents contradictory interpretations.
The event plan must follow the real journey
A store can track product view, add-to-cart, checkout initiation and purchase. Standard names such as view_item, add_to_cart, begin_checkout and purchase help organisation, but the mere existence of the name doesn't confirm a correct implementation.
For each event, document the moment it fires and the data required. If add_to_cart fires when the user merely selects a size, the report will overstate progress. If purchase fires on the button press before confirmation, you can count failed attempts as orders.
Check who owns the integration
You can have a native integration, a tag manager and an additional app all sending similar data. Take stock of the sources before you add a new one. Several implementations don't automatically mean better measurement and can produce duplicates.
Keep a simple diagram: store, integration, destination, events. Note who can change each component. If the Shopify site is updated, checking measurement must be part of the launch procedure.
How to check a test order
Choose a product and note the variant, quantity, price, discount and relevant costs. Go through the process as a new customer, on mobile, then track the events. DebugView is one of Google's tools for verifying events in debug mode.
Check the transaction ID, the currency and the value. Compare the products and quantities with the order in the store. Repeat for an order with a discount and for a different payment path, if these change the implementation.
Test repetition and returning
Reload the confirmation page and come back from the processor's page, under controlled test conditions. Observe whether the same order generates an additional value. Google explains deduplicating web purchases through the transaction ID; the identifier must be implemented correctly and consistently.
Don't use unnecessary personal data in analytics tools. Check the parameters and addresses sent to avoid exposing information that has no business being there. Test orders must be labelled and excluded from commercial interpretation through a documented process.
Check consent too
Test how the implementation behaves in the relevant consent scenarios. A visible banner doesn't prove that all tags respect it. For Google products, consult the EU consent policy and check the requirements that apply to your setup.
Incomplete data can be a legitimate limit of measurement. Don't try to get a perfect match by bypassing users' choices. Reporting must show what it can observe and what remains uncertain.
Why reports can show different values
Period and time zone
An order near midnight can fall on different days if the systems use different time zones. Check the settings and the moment at which each system reports. Don't compare an incomplete day with a completed one.
There is also processing time. Google documents the freshness of GA4 data. A recent report can be incomplete; the difference must be reassessed after the relevant interval, before a definitive diagnosis.
Attribution
GA4 and the ad platforms can attribute orders differently. An order can be reported by several platforms that took part in the journey. Don't add the totals and don't assume a single tool offers a complete causal explanation.
For Google Ads and Meta Ads, keep a shared commercial record. Explain separately the role of the attribution reports and the role of the order register. They are complementary, not interchangeable.
Value and order status
One system can include shipping or taxes, while another uses net product revenue. Discounts and returns can be treated at different moments. Before you look for an error, write out the formula for each value and try reconciling a few transactions.
If the difference appears only for a certain type of order, investigate that path: currency, discount, payment or variant. Segmenting by probable cause can be more efficient than repeatedly analysing the overall total.
Three hypothetical examples of verification
Hypothetical example 1: the rate of sessions with a purchase
In 30 days you have 4,000 sessions and 100 sessions with at least one purchase. The rate is 100 / 4,000 × 100 = 2.5%. If there are 110 orders in those sessions, the orders/sessions ratio would be 2.75%, but it describes a different metric.
Don't use the two values as if they were the same metric. The choice depends on the commercial question, and the definition must be kept over time.
Hypothetical example 2: a duplicate changes the revenue
The store has ten orders of 300 RON each in the scope analysed, a total of 3,000 RON. If two orders are sent twice without correct deduplication, the report can reach 3,600 RON. With media of 600 RON, the apparent ratio is 6, compared with 5 on the correct basis.
The example shows why a technical error can change the budget decision. Fix the cause and document the affected period. Don't present compromised historical data as comparable without an explanation.
Hypothetical example 3: commercial reconciliation
A report shows 50 purchases. In the store you identify 48 orders in the comparable scope; two events were tests. Of the 48, four are later cancelled, leaving 44. The differences have two distinct causes: testing and commercial status.
With media of 2,200 RON, the cost per retained order is 2,200 / 44 = 50 RON. Using the 50 events would give 44 RON, but it would answer a different question and understate the commercial cost.
Diagnostic matrix for data differences
| Symptom | What to check first | Useful evidence |
|---|---|---|
| Too many purchases | Duplicate sources and tests | IDs and triggers |
| Revenue too high | Value, taxes, currency | Order compared field by field |
| Purchases missing on one payment method | Return and confirmation | Reproducible path |
| Difference only recently | Processing and period | Matured report |
| Channels exceed the total | Attribution overlap | Shared order register |
Each problem must have an owner and a check after the fix. Don't consider the intervention closed just because the tag no longer shows an error. Repeat the path and compare the actual data.
Verification and maintenance plan
In the first week, take stock of the integrations and definitions. In the second, test the representative paths and document the problems. In the third, fix the sources and repeat the tests. In the fourth, reconcile a mature period and set up recurring checks.
After changes to the theme, checkout, apps or processor, repeat the relevant tests. Measurement is not a setup you check once. Keep a version log to explain any breaks in the reports.
For an analysis between the store and the campaigns, contact BlueAds. Prepare examples of transactions and definitions, without sending unnecessary personal data. A well-described difference is easier to investigate than the general claim that Analytics isn't correct.
Frequently asked questions
Must GA4 look exactly like the store?
Not in every report and at every moment. Definitions, processing, consent and attribution can differ. Still, implementation errors must be investigated and separated from these limits.
Does purchase mean the order was paid?
Not automatically. It depends on when it was implemented and on the later status. The commercial record must confirm payment, cancellations and returns.
Why don't I compare clicks and sessions as identical values?
They are different units, collected through different mechanisms. A click doesn't guarantee a measured session, and a session can include several interactions. Use consistent definitions.
Can I fix any error retroactively?
Don't assume so. The possibilities depend on the system and on the data kept. Document the affected period and don't present an incomplete correction as a perfect history.
Does a plugin solve all measurement?
Not automatically. The integration must be configured and tested in the context of the theme, checkout and other sources. Installing it is not the same as validating it.
How often do I check?
After important changes and periodically, depending on operational risk. Prioritise the paths that affect purchasing and values, not just the existence of events.
Which report do I use for budget?
Combine the analysis of behaviour and attribution with retained orders and contribution. No single report replaces all the other perspectives.
Final checklist
- Events match real actions.
- The ID, value and currency are correct.
- Duplicate sources are investigated.
- Consent is verified.
- Periods and definitions are aligned.
- Tests and cancellations are separated.
- There is a log of changes.