Shopify says you made 100 sales. GA4 reports 92 purchases. Google Ads reports 81 conversions. Meta reports 86 purchases.

So which system is wrong?

The common response is to open Google Tag Manager, look for a red error, and check whether the purchase tag fired.

That is not enough.

A conversion can disappear at several points between the customer completing an action and the number appearing in your advertising dashboard.

The real troubleshooting question is not:

“Did my conversion tag fire?”

It is:

“At exactly which step did the conversion, identifier, or attribution signal disappear?”

That distinction matters even more in 2026 as privacy controls, consent requirements, browser restrictions, checkout changes, and server-side architectures make conversion measurement more complicated.

Google itself recommends checking implementation, tag firing, Conversion Linker, reporting latency, and attribution when conversion data is missing. This guide gives you a practical way to investigate the entire journey.

The Conversion Tracking Troubleshooting Chain

Think of your tracking as a pipeline:

A failure anywhere in that chain can create a mismatch. Your job is to find the first point where reality and tracking stop matching.

01Start With the Business Number

Before touching GTM, establish the reference point. For an ecommerce store, begin with the actual order system.

Example:

Now calculate the gap. GA4 is missing 8%. Google Ads is reporting 19 fewer purchases than Shopify. Meta is missing 14%. Those gaps immediately tell you that you need to investigate — not simply reinstall the pixel.

For lead generation, use the CRM as the reference point:

Form submissions → Qualified leads → Opportunities → Closed revenue

A tracking system can accurately count 100 form submissions while telling the ad platform almost nothing about which 20 became valuable customers.

02Verify That the Conversion Actually Happened

This sounds obvious, but it eliminates a surprising number of false debugging sessions.

For an ecommerce purchase, verify:

• Order ID exists
• Payment succeeded
• Order was not cancelled
• Thank-you page actually loaded
• Purchase event was expected
• Revenue value is correct
• Currency is correct

For a lead:

• Form submitted successfully
• CRM received the lead
• Lead received a unique ID
• Thank-you state was actually reached

Do not use a pageview as proof that a conversion happened. A thank-you URL can be refreshed. A purchase trigger based only on page load can therefore create duplicate or false conversions.

03Inspect the dataLayer

Open the browser console and inspect:

dataLayer

Find the actual conversion event. A healthy purchase event should contain the information your implementation expects, such as:

{
  event: "purchase",
  transaction_id: "ORDER-12345",
  value: 149.00,
  currency: "USD"
}

Then ask: Did the event exist? Was it named correctly? Was the transaction ID present? Was the value correct? Were ecommerce items populated?

This matters because a GTM tag can fire successfully while sending incomplete data. Google's own GA4 troubleshooting guidance starts with verifying that the Google tag is installed correctly and that the expected data is being collected.

A common hidden failure

You see:

// GTM Preview says:
Purchase tag: Fired

// But the payload contains:
transaction_id: undefined

The tag fired. The tracking is still broken.

04Check GTM Preview — But Don't Stop There

Open Google Tag Manager Preview and reproduce the conversion. Check:

Trigger

Did the expected event trigger the tag?

Variables

Are your variables returning the correct values?

Tags

Did the conversion tag fire?

Frequency

Did it fire once or twice?

Consent

Was the tag allowed to fire?

“Tag Fired” is not the same as “Conversion Successfully Received.”

GTM tells you what the container attempted to do. You still need to verify what actually left the browser and what the destination received.

05Open DevTools and Check the Network Request

This is one of the most valuable troubleshooting steps.

Open Chrome DevTools → Network, then complete the conversion. Filter for relevant requests. You want to establish: Did the browser actually send the event?

Look at:

• Request URL
• Parameters
• Event name
• Conversion identifier
• Value
• Currency
• Client identifiers
• Response status

A request returning successfully does not automatically prove that the conversion payload is correct. The request can reach the endpoint while missing a critical parameter. That's why you inspect the actual request — not just the GTM interface.

06Test Consent Before Blaming the Tag

Consent can change what tracking is permitted to do. Google's current server-side Consent Mode architecture passes consent information from the web container to the server container, where Google tags can adjust how data is processed.

Check the order of operations:

Consent Initialization
  ↓
Default consent state
  ↓
Google tag
  ↓
CMP update
  ↓
Conversion event

Look specifically at: ad_storage, analytics_storage, ad_user_data, ad_personalization.

A race condition can create a situation where your conversion happens before the expected consent state is available. That means two visitors can perform exactly the same action and produce different tracking behavior.

07Follow the Click ID From Landing Page to Purchase

This is where attribution troubleshooting gets interesting.

For Google traffic, inspect identifiers such as gclid, gbraid, wbraid. For Meta: fbclid, fbc, fbp. For your campaign tracking: utm_source, utm_medium, utm_campaign.

Start with a controlled landing URL:

https://example.com/product?gclid=TEST123

Then move through the customer journey.

Landing page      gclid = TEST123
   ↓
Product page      gclid = TEST123
   ↓
Cart              gclid = TEST123
   ↓
Checkout          gclid = MISSING   // ← attribution leak
   ↓
Purchase          gclid = MISSING

You have found an attribution leak. Google specifically identifies lost GCLIDs through redirects as one possible reason Google Ads data can be missing from Analytics. This is why testing the identifier across the entire journey is more useful than checking one page.

08Test the Checkout Separately

Modern ecommerce tracking often fails around checkout. Test:

Store → Cart → Checkout → Payment → Confirmation

Then identify whether the checkout:

• changes domain
• changes subdomain
• redirects through another provider
• strips parameters
• breaks cookies
• changes the referral source
• starts a new session

If the conversion event happens correctly but the original marketing context disappears before purchase, your problem may be attribution, not conversion collection. That's an important distinction.

09Check for Duplicate Conversions

Now test the opposite problem. Sometimes tracking isn't losing conversions — it's creating too many.

For example:

Shopify integration   *
GTM purchase tag       *
hardcoded GA4 purchase = one order counted three times

Look for multiple implementations of the same event. For Meta, browser and server events also need a consistent deduplication strategy.

A useful test: One order ID → how many purchase events? If the answer is two or three, stop there and fix the duplication before analyzing reporting differences.

10Compare GA4 With the Backend

Never make GA4 the only source of truth for revenue reconciliation. Compare backend orders against GA4 purchases, then investigate each missing order.

Create a simple audit table:

This is much more powerful than comparing only totals. You can locate the missing conversion.

11Troubleshoot Server-Side Tracking as a Separate Layer

With server-side GTM, use this model:

Browser  →  Web GTM  →  sGTM endpoint  →  Server client
         →  Server variables  →  Destination tag  →  Platform

Check each stage independently.

1. Did the browser send the request?
2. Did sGTM receive it?
3. Did the correct client claim it?
4. Were the expected event parameters available?
5. Did the destination tag fire?
6. Did the destination platform accept the event?

This prevents the classic mistake of saying: “Server-side tracking is installed, so it must be working.” An sGTM container can be online while a specific conversion pipeline is still broken.

12Don't Ignore Platform-Specific Diagnostics

Google Ads

Check: conversion action status, Primary vs Secondary, tag implementation, Conversion Linker, Enhanced Conversions, conversion values, attribution/reporting timing.

Google currently recommends using Tag Assistant for test conversions and checking Conversion Linker and conversion-action status when diagnosing missing Google Ads conversions. Also remember that Google Ads and Analytics can legitimately report different numbers because attribution and reporting methodologies differ. Google notes that Ads reporting can include latency and attributes conversions based on the ad interaction rather than necessarily the date the conversion occurred.

GA4

Check: event name, transaction_id, value, currency, ecommerce items, Event DebugView, Realtime, attribution, key event configuration.

Meta

Check: Browser Pixel, Conversions API, event_name, event_id, fbp, fbc, Event Match Quality, deduplication, purchase value, currency.

13Test Different Browsers and Devices

A conversion that works perfectly on Chrome desktop is not enough. Run controlled tests on:

Chrome desktop · Safari desktop · iPhone · Android

Then compare: cookies, URL parameters, consent, browser requests, event firing, identifiers, destination receipt.

The point isn't to claim that every Safari conversion will fail. The point is to determine whether your implementation behaves differently under different browser and consent conditions.

14Check What Happens When an Ad Blocker Is Enabled

Run the same test twice.

Test A: Normal browser. Test B: Ad blocker enabled. Compare the requests.

If your conversion disappears only when client-side scripts are blocked, you've identified a browser-side dependency. This is one of the reasons many businesses evaluate server-side architectures rather than relying entirely on browser-based tracking.

But don't jump straight to “server-side fixes everything.” Server-side tracking still depends on correct event collection, consent handling, identifiers, deduplication, and destination configuration.

15Test JavaScript Errors

Open DevTools → Console. Look for: JavaScript errors, failed scripts, blocked resources, CORS errors, theme/plugin conflicts, checkout script issues.

One unrelated-looking JavaScript error can prevent downstream tracking code from executing. This is especially important after: Shopify theme updates, plugin updates, checkout changes, consent manager changes, analytics migrations.

16Audit the Setup After Website Changes

Tracking is not a one-time implementation. It can break after:

• Theme redesign
• Checkout migration
• Plugin update
• CMP update
• GTM container change
• Shopify implementation change
• New analytics app
• New ad platform integration

The dangerous failures are often silent. The dashboard still opens. The tag still exists. The campaigns still run. But your conversion signal is incomplete.

17Build a Conversion Tracking Health Check

For serious accounts, create a recurring QA process. At minimum, test:

Collection

Does the event happen?

Data quality

Does it contain the required fields?

Delivery

Was it actually sent?

Consent

Was it permitted?

Attribution

Did the marketing identifier survive?

Deduplication

Was it counted once?

Destination

Did the ad/analytics platform receive it?

Revenue

Does it match the backend?

This becomes a real tracking health framework instead of a one-time GTM check.