An eCommerce store can show purchases in Google Ads and still be optimising from unreliable data.
A Purchase event can fire twice. Revenue can use the wrong currency. A failed payment can be recorded as a sale. Add to Cart can accidentally become a bidding goal. Two conversion actions can represent the same order. A consent change can stop one part of the measurement setup while another continues behaving differently.
The Google Ads interface still shows conversions.
But the bidding system may be learning from a version of the business that never actually happened.
This matters because conversion tracking is no longer just a reporting tool.
Smart Bidding uses conversion data when making auction-time decisions. Performance Max and other automated campaigns also depend heavily on the goals and values connected to them.
Better automation starts with a reliable definition of what a conversion actually is.
Start with the order, not the advertising platform
Google Ads helps explain which advertising interactions contributed to a purchase.
Google Analytics helps explain behaviour and acquisition across channels.
The commerce platform records whether the order actually exists.
For most eCommerce businesses, the store backend should therefore remain the reference point for:
- Completed orders
- Order value
- Currency
- Products purchased
- Discounts
- Payment status
- Cancellations
- Refunds
That does not make Google Ads or GA4 less useful.
They answer different questions.
| System | Main question |
|---|---|
| Store backend | What did the business actually sell? |
| Google Ads | Which outcomes can be associated with Google advertising and used for campaign optimisation? |
| GA4 | How did users behave across the website and acquisition channels? |
A reliable measurement setup connects those systems.
It does not expect them to show identical numbers.
Purchase should normally represent the business result
Google Ads groups conversion actions into goals and lets advertisers decide which actions should influence bidding.
Primary conversion actions are generally included in the Conversions column and can be used for bidding when the relevant goal is selected.
Secondary actions are generally used for observation in All conversions rather than normal bidding, although custom goals are an important exception.
For a typical eCommerce sales campaign, Purchase will usually be the main conversion action.
Events such as:
- View Item
- Add to Cart
- Begin Checkout
are still useful.
They help us diagnose where customers leave the funnel and understand changes in buying behaviour.
But they do not represent the same commercial outcome as payment.
The campaign should not receive the same optimisation signal for showing purchase intent and completing a purchase unless there is a deliberate reason for that setup.
For most established stores, the long-term bidding signal should be close to the result the business actually wants: a valid completed order with the correct value, currency, and transaction identifier.
There are two common ways to create a Google Ads Purchase conversion
A website purchase can reach Google Ads through more than one measurement path.
Two common approaches are:
- A Google Ads conversion based on a GA4 event
- A native Google Ads website conversion
Neither method is automatically more accurate.
The quality of the underlying Purchase event matters more than the logo on the tag.
Option 1: use a GA4 event as the Google Ads conversion
GA4 can collect the eCommerce Purchase event and use it as a key event.
A Google Ads conversion can then be created from that Analytics event and made available for campaign reporting and bidding.
This is useful when GA4 already acts as the central website measurement system.
Why this setup can work well
The same event definition can support:
- Website analysis
- Cross-channel acquisition reporting
- Google Ads measurement
- Audience analysis
- Funnel reporting
That can reduce the number of slightly different definitions of “Purchase” across the organisation.
If the GA4 event is well implemented, using it in Google Ads can therefore create a clean measurement architecture.
What can go wrong
Google Ads does not repair a bad GA4 event when it creates a conversion from it.
If GA4:
- Fires Purchase twice
- Sends the wrong value
- Uses the wrong currency
- Loses the transaction ID
- Triggers before the order is complete
the Google Ads conversion inherits that problem.
There can also be processing delays before Analytics-based conversion data is fully reflected in Google Ads.
And some Google Ads-specific measurement features, such as view-through conversions, require native Google Ads conversion measurement rather than an Analytics-based conversion.
Option 2: use native Google Ads conversion tracking
The alternative is to create a website conversion directly in Google Ads and send the Purchase through the Google tag, Google Tag Manager, or another supported integration.
This creates a conversion specifically for the advertising account.
Why native tracking can be useful
It provides a dedicated Google Ads measurement path and access to Google Ads-specific conversion features.
For advertisers who want a dedicated purchase signal for Smart Bidding, that can be a strong setup.
It also allows the team to maintain conversion settings specifically around advertising requirements.
The trade-off
If GA4 is also recording purchases, the business now has two tracking paths that need to describe the same order correctly.
The value, currency, and transaction logic should remain consistent.
The biggest risk is not having both measurements.
It is making both of them bidding signals for the same sale without understanding the consequence.
Do not bid towards the same order twice
Imagine one customer places one €200 order.
The store sends:
- One native Google Ads Purchase
- One GA4 Purchase that is also created as a Google Ads conversion
Both measurements may correctly describe the same transaction.
But if both conversion actions are configured as primary goals used by the same campaign, the advertising system can receive two optimisation signals for one real business result.
The answer is not necessarily to delete one.
Keeping a second measurement as an observational or comparison signal can be useful.
But the account should have a clearly defined primary Purchase conversion for bidding.
One order can have several measurements. It should still have one clear optimisation role.
Transaction IDs help prevent duplicate purchases
For eCommerce Purchase events, Google strongly recommends sending a unique transaction ID.
This is normally the unique order or transaction identifier generated by the commerce system.
Suppose a customer completes an order and later reloads the confirmation page.
Without a transaction ID, the Purchase tag may fire again and appear to create another sale.
If both events use the same unique transaction ID within the same conversion action, Google can recognise the second one as a duplicate.
A transaction ID should therefore be:
- Unique to each order
- Generated dynamically
- Stable for the same transaction
- Free of customer-identifying information
Hardcoding an ID creates the opposite problem: different orders can start looking like duplicates and conversions may be undercounted.
Transaction IDs do not solve every duplicate-conversion problem
This is an important distinction.
A transaction ID can help deduplicate repeated reporting within a conversion action.
It does not automatically merge two different primary conversion actions that both represent the same sale.
That still needs to be solved through conversion-goal design.
Which Purchase conversion should you use?
There is no universal answer.
| GA4-based conversion | Native Google Ads conversion |
|---|---|
| Useful when GA4 is already the trusted central event system | Useful when Google Ads needs its own dedicated conversion path |
| Supports a more unified cross-channel measurement model | Supports Google Ads-specific measurement features |
| Depends on the accuracy of the GA4 event | Requires a separate implementation to remain accurate |
| Can have additional processing delay | Native Ads conversion data is generally available sooner |
| Does not provide native Google Ads view-through measurement | Can support view-through conversions where applicable |
The correct choice depends on the existing data architecture.
A clean GA4 implementation is better than a broken native tag.
A reliable native Google Ads conversion is better than importing a Purchase event nobody trusts.
In more advanced measurement setups, both can exist.
They simply need clearly defined roles.
Enhanced Conversions improve matching
Enhanced Conversions add first-party customer information to an existing conversion measurement setup.
When a customer completes a transaction, the business may have information such as an email address, phone number, name, or address.
Eligible user-provided data can be normalised and securely hashed with SHA-256 before it is sent to Google.
Google can then use that information to improve its ability to match the conversion with signed-in Google users who previously interacted with the advertiser's ads.
The result can be more complete conversion measurement.
Enhanced Conversions changed in 2026
Google simplified the feature during 2026.
The older distinction between separate Enhanced Conversions configuration methods has been consolidated into a unified Enhanced Conversions setting.
Google Ads can now accept eligible user-provided data through several routes, including website tags, Data Manager, and API connections.
That means the technical implementation can vary while the underlying purpose remains the same:
improve conversion matching using eligible first-party information.
Enhanced Conversions do not make a bad Purchase event good
This distinction deserves its own section because it is frequently misunderstood.
Enhanced Conversions can improve matching.
They do not validate the transaction.
If the Purchase event contains:
- €500 instead of €50
- The wrong currency
- A failed order
- A duplicated transaction
better matching does not repair those problems.
It may simply help Google associate an inaccurate event with the correct user more effectively.
That is why we separate:
| Measurement question | What it tells us |
|---|---|
| Did the event fire? | Event coverage |
| Did it represent a real order? | Event accuracy |
| Can Google associate it with an eligible user? | Matching quality |
| Can it be connected with an advertising interaction? | Attribution |
| Should bidding optimise towards it? | Conversion-goal design |
Those are related questions, but they are not the same one.
What server-side tracking actually changes
Traditional browser tracking sends measurement requests from the customer's browser to platforms such as Google Ads and Google Analytics.
Server-side tracking introduces another controlled environment into that data flow.
One common implementation is server-side Google Tag Manager.
Instead of every browser tag communicating independently with its final destination, event data can first reach a server container controlled by the business and then be processed before being forwarded.
Google highlights three main potential benefits:
- Improved data quality
- More detailed privacy controls
- Potential page-performance improvements
The exact benefit depends heavily on how the architecture is implemented.
Server-side tracking is not one technology
The phrase can describe several different systems.
An eCommerce business might use:
- Server-side Google Tag Manager
- A direct backend-to-platform integration
- A native commerce integration
- A third-party tracking provider
- Some combination of those approaches
A direct backend integration, for example, can be useful when the commerce system knows that a payment has been confirmed independently of whether the customer's confirmation page loaded correctly.
Server-side Tag Manager serves a different purpose. It creates a controlled tag-processing layer that can receive, transform, and route measurement data.
These architectures should not all be described as if they were the same implementation.
Server-side does not automatically mean more accurate
This is the same lesson we saw with Enhanced Conversions.
A server can send inaccurate events extremely reliably.
If the backend considers every created order a sale even when payment later fails, moving Purchase server-side will not fix the business logic.
Server-side tracking gives the business more control over:
- Which data is forwarded
- Which fields are removed or transformed
- Which destinations receive an event
- How different data sources are connected
That control is valuable only when the rules are correct.
Browser and server measurement often work together
Server-side tracking should not automatically be presented as a complete replacement for browser measurement.
The browser still has access to information about:
- Page views
- Product interactions
- Sessions
- Browser identifiers
- Ad-click information
- Consent state
The backend may know much more about:
- Confirmed transactions
- Order status
- Final value
- Product details
- Refunds
- Customer records
A strong implementation can use each environment for the information it is best positioned to know.
Consent Mode controls how Google tags respond to consent choices
Consent Mode is another layer of the measurement system.
It does not collect consent itself.
The website or Consent Management Platform needs to obtain the user's choice and communicate the relevant consent state.
Google tags then adjust their behaviour according to that state.
Google provides two broad implementation models.
Basic Consent Mode
In basic Consent Mode, Google tags are blocked until the user interacts with the consent mechanism.
If the user does not grant the relevant consent, the Google tags remain blocked and no event data is sent through those tags.
Advanced Consent Mode
In advanced Consent Mode, Google tags can load with consent set to denied by default.
When storage consent is denied, Google can receive limited measurements without advertising or analytics cookies.
Those signals can support modelling where the account meets Google's requirements.
If consent is later granted, tag behaviour changes accordingly.
Consent Mode does not create consent
This is an important practical and legal distinction.
Consent Mode tells Google tags what consent status the website has communicated.
It does not decide whether the business needs consent.
It does not write the privacy policy.
It does not determine whether a Consent Management Platform is correctly configured.
And it should not be presented as automatic compliance with GDPR or another privacy law.
The business still needs to establish the appropriate privacy and legal requirements for its implementation.
The technical measurement setup should follow those decisions.
What are modeled conversions?
When Google cannot directly observe the full path between an ad interaction and a conversion, it may use conversion modelling to estimate part of the missing measurement.
Consent Mode can provide one foundation for this modelling.
Google uses observed conversions and other eligible signals to model conversions that cannot be directly attributed through the normal observed path.
When the account meets Google's eligibility and quality thresholds, modeled conversions can appear directly in standard conversion reporting and can also influence automated bidding.
This means a Google Ads conversion report can contain a combination of:
- Observed conversions
- Modeled conversions
That does not mean Google invents arbitrary purchases.
It means some reported conversions are statistical estimates rather than directly observed user journeys.
Modeling still depends on good observed data
A measurement model needs a useful foundation.
If observed Purchase events contain bad values, duplicates, or incorrect order logic, adding modelling on top does not solve the core measurement problem.
This is another reason to verify the base Purchase implementation first.
Why Google Ads, GA4, and the backend still disagree
Even a strong implementation will not make all three systems identical.
Differences can come from:
- Attribution
- Conversion windows
- Processing delays
- Identity and cross-device measurement
- Modeled conversions
- Counting settings
- Invalid-traffic filtering
- The date used to report a conversion
Google Ads commonly reports conversions according to the advertising interaction that received credit.
GA4 can present conversion activity through different attribution and reporting views.
The store simply knows when an order occurred.
Those are different reporting questions.
Compare comparable dates
When investigating differences, reporting dates matter.
Google Ads provides “by conversion time” columns that can help when comparing against systems reporting activity on the date the conversion actually occurred.
There can also be a processing delay between GA4 and Google Ads, so comparing today's incomplete data immediately can create a discrepancy that disappears later.
The objective is not:
Make every dashboard show the same number.
It is:
Understand why the numbers differ and identify changes that do not have a reasonable explanation.
The tracking errors we look for first
Purchase fires more than once
Confirmation-page reloads, several tags, or multiple conversion actions can create duplicate reporting.
Use reliable triggering logic and unique transaction IDs, then verify the bidding goals themselves.
The order value is wrong
A purchase count may be correct while its conversion value is not.
Check discounts, currency, taxes, shipping, and the store's agreed reporting definition.
This becomes especially important when bidding uses conversion value.
Purchase happens before the business considers the order valid
A checkout button click is not necessarily a sale.
Neither is an order record created before payment confirmation in every commerce system.
Define the event according to the real order lifecycle.
Micro-conversions influence bidding unintentionally
Add to Cart and Begin Checkout can be useful diagnostic signals.
That does not automatically make them appropriate primary bidding goals.
Tracking broke after a release
A conversion setup can be correct for a year and fail after:
- A checkout migration
- A payment-provider change
- A new Consent Management Platform
- A frontend rewrite
- A new currency
- A new commerce integration
Tracking should therefore be included in release testing when the affected code touches the buying journey.
A practical Google Ads conversion audit
We would review the system in this order.
1. Define the real order
At what exact point does the business consider a purchase complete?
2. Test one controlled purchase
Verify the event name, value, currency, transaction ID, and timing.
3. Check conversion goals
Which conversion actions are primary? Which campaigns actually bid towards them?
4. Look for duplicate measurement paths
Is Purchase measured through GA4, native Google Ads, platform integrations, or several routes at once?
5. Reconcile against backend orders
Compare enough transactions to identify patterns rather than relying on one test purchase.
6. Validate Enhanced Conversions
Check Google Ads diagnostics and confirm that eligible user-provided data is being processed as intended.
7. Verify consent behaviour
Test what happens before a choice, after consent is granted, and after it is denied according to the implementation being used.
8. Check after major releases
A passing implementation today does not prove it will remain correct after the checkout changes.
What a strong measurement architecture looks like
There is no requirement to use every Google measurement product.
The right architecture depends on the business.
But the roles should be clear.
| Layer | Job |
|---|---|
| Backend | Confirm actual orders and commercial values |
| GA4 | Analyse website behaviour and cross-channel acquisition |
| Google Ads conversion | Provide a trusted advertising outcome for reporting and bidding |
| Enhanced Conversions | Improve matching using eligible first-party data |
| Server-side tracking | Provide additional control over event processing and data routing |
| Consent Mode | Adjust supported Google tag behaviour based on communicated consent state |
| Conversion modelling | Estimate eligible measurement gaps where direct observation is unavailable |
The architecture becomes problematic when nobody knows which layer owns which job.
Better bidding starts before the bid
Modern Google Ads can make auction decisions faster than any campaign manager.
That makes the quality of the information behind those decisions more important.
Google cannot look into your order-management system and independently decide that an event represents a failed payment.
It cannot know that two primary conversion actions describe the same customer purchase unless the measurement setup gives them the correct roles.
It cannot repair the wrong revenue value simply because Enhanced Conversions are enabled.
And server-side tracking does not turn incorrect business logic into correct data.
People still define what success means.
The tracking system translates that definition into data Google can use.
At Creative Brackets, we therefore treat conversion tracking as part of the complete eCommerce advertising system: backend orders, analytics, consent, campaign goals, bidding, website development, and business reporting.
Because before you optimise the campaign, you need to trust the conversion it is optimising for.
Not sure whether your campaigns are bidding from real orders or tracking noise?
FAQ
1. Should I use GA4 conversions or native Google Ads conversions?
Both can work well. GA4-based conversions are useful when Analytics already acts as the trusted central event system and cross-channel consistency matters. Native Google Ads conversions provide a dedicated advertising measurement path and access to Ads-specific features. The quality of the Purchase implementation matters more than choosing one method by default.
2. Can I keep both GA4 and Google Ads Purchase conversions?
Yes, and that can be useful for comparison. The important part is deciding which action should be used for bidding. Two primary conversions that both represent the same sale can give automated bidding duplicate optimisation signals.
3. What do Enhanced Conversions do?
They supplement existing conversion measurement with eligible first-party customer information that is securely hashed and sent to Google. This can improve Google's ability to match conversions with eligible ad interactions. Enhanced Conversions do not replace the Purchase event or correct an inaccurate transaction.
4. Does server-side tracking replace browser tags?
Not necessarily. Browser and server environments know different things about the customer journey. Many strong setups use them together. The correct architecture depends on the website, backend, privacy requirements, and measurement goals.
5. Does Consent Mode make a website GDPR compliant?
No. Consent Mode changes how supported Google tags behave according to the consent state communicated to them. The business still needs to determine its legal obligations, obtain the appropriate user choices, and configure the wider tracking system accordingly.
6. Why does Google Ads show more conversions than GA4?
Possible reasons include different attribution views, counting settings, conversion windows, view-through measurement, modelling, reporting dates, and processing delays. A difference does not automatically indicate a bug, but large or sudden unexplained changes should be investigated.
7. Should Add to Cart be a primary conversion?
For a typical established eCommerce store optimising for sales, Purchase will usually be the more appropriate primary business outcome. Add to Cart is still useful for analysis. Earlier-funnel actions may occasionally be used deliberately when purchase volume is extremely limited, but this should be a conscious optimisation decision rather than the default.
8. How often should conversion tracking be tested?
Test it when the implementation is created and after meaningful changes to checkout, payments, consent, frontend code, currencies, or commerce integrations. It is also worth investigating whenever campaign conversion data suddenly stops resembling the store's real order data.