Why your Google Ads conversion count is probably a lie
Google Tag Manager is supposed to make tracking simpler. For most small business owners it does — right up until one tag silently starts recording every conversion twice, and the entire foundation of your ad spend rots from underneath you without a single warning in your dashboard.
"Google Ads reports no error when a tag fires twice — it just records two conversions and optimises toward both as if they were real."
This is not a hypothetical. It is the default outcome of the most common GTM setup tutorial on YouTube, applied to a WooCommerce store, a Cliniko booking page, or a ServiceM8 job-complete URL. The misconfiguration is quiet. Google never flags it. And by the time most operators notice, they have spent months — and often thousands of dollars — chasing phantom jobs that never existed.
Google Ads sees two conversions and calls them both real
When a conversion tag fires twice on the same page load, Google Ads records two separate conversion events. There is no deduplication by default. There is no alert. The platform has no way to know that both events came from a single user completing a single action — it just increments the counter twice and uses both data points to train its bidding algorithm.
Per Google Ads Help — 'About conversion counting: one vs every', the default counting method for many conversion actions is Every, which means every tag fire is recorded as a unique conversion. If your tag fires twice, you get two conversions logged. There is no asterisk in the report.
Phantom conversions break your bidding strategy
When your reported conversions are two to three times your actual enquiries or bookings, your campaign's bidding strategy — whether that is Target CPA, Target ROAS, or Maximise Conversions — calibrates itself to a benchmark that does not exist. It finds the clicks that generate phantom conversions and doubles down on them. It deprioritises clicks that generate only one conversion signal, even when those are your real customers.
The result: your budget concentrates on a ghost audience, your cost per actual booking climbs, and Google Ads keeps reporting "strong performance" because, by its own broken data, performance looks fine.
The real-world gap is the warning sign you already have
You do not need a data analyst to spot this. The mismatch between what your ad account reports and what actually happened — phone calls logged, emails received, appointments booked in Cliniko, jobs completed in ServiceM8 — is the clearest possible signal that something is wrong with your tag manager setup.
"If your ad account says 40 conversions and your phone rang 18 times, the tracking is lying — not the ads."
Pull your last 30 days of Google Ads conversions. Then open your CRM, your inbox, your Cliniko booking history, or your ServiceM8 job list and count the real enquiries for the same period. A gap of more than 20% deserves immediate investigation. A gap of 50% or more almost always points to a double-fire problem in your GTM container.
The All Pages trigger is the default setting that breaks everything
Every Google Tag Manager container ships with one trigger pre-built: All Pages. It fires on every pageview. It is right there waiting when you open a new container, and nearly every beginner GTM tutorial tells you to attach it to your conversion tag because it is the fastest way to get tracking live.
Fast is not the same as correct.
Why the All Pages trigger exists and why it is wrong for conversions
The All Pages trigger has a legitimate use: firing your base Google Analytics 4 pageview tag so you can track site-wide traffic. That is it. That is the job. The moment you attach it to a conversion tag — a Google Ads purchase event, a lead-form submission, a booking confirmation — you are telling GTM to record a conversion on every single page your visitor loads, not just the one that matters.
GTM practitioner Simo Ahava has documented in detail how the All Pages trigger fires on History Change events in single-page applications (SPAs) — frameworks like React, Vue, or Next.js where the URL changes without a true browser page reload. Each URL change generates a new pageview event in GTM's data layer, and All Pages fires again. Per simo.io, this is one of the most common sources of inflated conversion data in GTM deployments, and it is invisible to the operator because the user never sees a page refresh.
WooCommerce: the double-load problem on your most important page
WooCommerce thank-you pages — URLs containing ?order-received — have a specific and well-documented GTM problem. When certain WooCommerce plugins (payment gateways, order-bump plugins, cart upsell tools) load their own scripts, they can cause the GTM container snippet to initialise twice on the same page. This is documented in WooCommerce GitHub issue #38521. An All Pages trigger attached to your conversion tag will fire once for each container initialisation — so you get two conversion events from a single purchase, on your single most important page, every time.
Cliniko and ServiceM8 have the same structural flaw
Cliniko's booking widget loads inside an iframe on your website. When a patient completes a booking, Cliniko redirects to a confirmation URL. Depending on how your GTM container is implemented, that redirect can trigger a fresh pageview event — and if your conversion tag is on All Pages, it fires again. ServiceM8 job-complete URLs use a job-specific token in the URL and are reached via an email link redirect; the redirect itself can register as a pageview event, causing the same double-fire.
Neither platform documents this as a GTM issue because it is not their bug. It is a trigger architecture decision that falls entirely on whoever set up the tag manager container.
How to run a two-minute live debug in GTM Preview mode tonight
You do not need to hire anyone to confirm whether you have this problem. GTM's built-in Preview mode shows you exactly which tags fire, on which events, and how many times — in real time, on your live site. Here is how to use it.
Opening the debug panel
- Log in to tagmanager.google.com and open your container.
- Click the Preview button in the top-right corner. A new tab opens with a prompt asking for your website URL.
- Enter your website URL and click Connect. Your site opens with a GTM debug panel docked at the bottom of the browser window.
- Per Google Tag Manager Help — 'Troubleshoot tag firing with Preview mode', the debug panel shows every event in the left column and every tag that fired (or did not fire) for each event in the main panel.
Navigating to your confirmation page and reading the result
- Complete a test transaction or navigate directly to your thank-you page URL — for WooCommerce this is a URL containing
?order-received, for Cliniko it is your post-booking confirmation URL. - In the GTM debug panel, look at the Tags Fired column for the Page View event (and any History Change events that appear in the left-column event list).
- Find your conversion tag by name. Check the fire count next to it.
Fire count of 1: your tag is behaving correctly.
Fire count of 2 or more: you have confirmed the double-fire. You are about to fix it.
Before you touch anything: capture your before state
Take a screenshot of the Tags Fired panel showing the incorrect fire count. Save it somewhere you can find it in a week. This is your evidence of the problem, your benchmark for confirming the fix worked, and your explanation for why your Google Ads conversion numbers are about to drop — because they will drop, and anyone watching the account needs to know that a lower number is a better number.
Google Ads reports no error when a tag fires twice — it just records two conversions and optimises toward both as if they were real.
The one firing condition that stops the double-fire dead
The fix is not complicated. You are replacing a broad trigger with a precise one. The conversion tag should only fire when the visitor is on a page that definitively represents a completed conversion — and you define that by the URL.
Creating a Page URL trigger instead of All Pages
- In GTM, go to Triggers and click New.
- Name it something specific: Pageview — WooCommerce Order Received or Pageview — Cliniko Booking Confirmed.
- Set the trigger type to Page View.
- Under This trigger fires on, select Some Page Views.
- Set the condition to: Page URL — contains — and enter the URL fragment that only appears on your genuine confirmation page.
For WooCommerce: order-received
For a generic thank-you page: /thank-you or /booking-confirmed — whatever your exact URL path is.
- Save the trigger. Open your conversion tag and swap the All Pages trigger for this new one.
- Re-run GTM Preview, navigate to the confirmation page, and check the fire count. It should now read 1.
Fixing the conversion counting setting in Google Ads
If you run Google Ads conversion tags directly (not via Google Analytics imported goals), there is a second control to check. In Google Ads:
- Go to Tools and Settings (the wrench icon) — Measurement — Conversions.
- Click into your conversion action.
- Under Count, check whether it is set to Every or One.
- For lead-generation actions — enquiry forms, phone calls, appointment bookings — switch this to One. Per Google Ads conversion counting documentation, Every is appropriate for e-commerce purchases where one customer might legitimately buy twice; One is correct for any action where a single customer should only be counted once per session.
This setting is a second line of defence, not a substitute for fixing the trigger. Fix the tag first, then set the counting correctly.
WooCommerce, Cliniko, and ServiceM8 each have a specific URL pattern to target
The trigger logic is the same across platforms — fire on a specific URL or event that only exists after a genuine conversion. But the exact string to match is different for each platform. Here is what to use.
WooCommerce: target the order-received parameter
WooCommerce appends ?order-received= followed by the order ID to the thank-you page URL. No other page in a WooCommerce store uses this parameter. Your trigger condition:
Trigger type: Page View
Fires on: Some Page Views
Condition: Page URL — contains — order-received This is specific enough to fire only on the post-purchase confirmation and nowhere else in the checkout flow — not the cart, not the checkout page, not the payment processing step.
Cliniko: find your post-booking redirect URL
Cliniko's booking widget loads inside an iframe. After a patient submits a booking, Cliniko can redirect to a URL on your own website that you control. To find or set this URL:
- In Cliniko, go to Settings — Online Bookings.
- Look for the Redirect URL or Confirmation Page field and set it to a page on your own domain — for example,
yourdomain.com.au/booking-confirmed. - Use that URL path as your trigger condition: Page URL contains
/booking-confirmed.
If you have not configured a redirect URL and Cliniko shows its own confirmation screen inside the iframe, the cleanest solution is to set one up now. Without it, your thank-you state never produces a URL change on your domain that GTM can reliably detect.
ServiceM8: use a Custom Event trigger, not a pageview
ServiceM8 job-complete confirmation emails link to a URL with a job-specific token. Because the URL is unique per job, a Page URL contains trigger is impractical — you cannot predict the token. The safer architecture:
- Use ServiceM8's form-submit webhook or the confirmation page's fixed URL slug (the part before the token) as your trigger anchor.
- If ServiceM8 sends the customer to a fixed path like
/job-completebefore appending the token, use Page URL contains/job-complete. - If the entire URL is dynamic, set up a Custom Event trigger in GTM and fire a
dataLayer.pushevent from the confirmation page — this eliminates the redirect double-fire problem entirely because the tag fires on a named event, not a pageview.
| Platform | Trigger type | Condition string | Notes |
|---|---|---|---|
| WooCommerce | Page View | Page URL contains order-received | Works for all WooCommerce payment gateways |
| Cliniko | Page View | Page URL contains /booking-confirmed (your redirect path) | Requires redirect URL configured in Cliniko Online Bookings settings |
| ServiceM8 | Custom Event | Event name: servicem8_job_complete | Requires dataLayer.push on confirmation page; eliminates token URL problem |
| Generic thank-you page | Page View | Page URL contains /thank-you | Confirm this path is not reachable without completing the conversion action |
What the before-and-after debug panel actually looks like
Descriptions of fixes are easy to write and hard to trust. Here is exactly what you should see in GTM Preview before and after making the trigger change, so you know the fix actually worked.
Before: two fires on the same page load
Open GTM Preview and navigate to your WooCommerce order-received page or booking confirmation URL. In the debug panel, select the Page View event from the left-column event list. Under Tags Fired, your conversion tag appears with a fire count of 2 — sometimes 3 if a History Change event also triggered on the same navigation.
You may also see a second entry in the left-column event list labelled History Change. If your conversion tag appears under that event's Tags Fired list as well, that is the SPA virtual pageview problem Simo Ahava documented — the URL changed client-side without a full page reload, GTM registered a new event, and All Pages fired your conversion tag again.
After: exactly one fire on exactly the right page
After swapping All Pages for a Page URL trigger scoped to order-received, run the same Preview session. Navigate to the same confirmation page. The debug panel now shows your conversion tag listed exactly once under Tags Fired, with a fire count of 1. Navigate to any other page in your site — the cart, the product page, the homepage — and the conversion tag does not appear in Tags Fired at all. It is invisible everywhere except the one URL where a real conversion has occurred.
The confirmation that actually matters: your Google Ads conversion count
The debug panel gives you technical confirmation. The real-world confirmation comes over the following seven days: watch your Google Ads conversion count drop to a number that matches your phone calls, inbox enquiries, and booked appointments. A drop in reported conversions is not bad news — it is the system finally telling you the truth. The algorithm can now optimise toward real customers, and your cost per actual booking will, over two to four weeks, begin to reflect that.
If your ad account says 40 conversions and your phone rang 18 times, the tracking is lying — not the ads.
How much budget the phantom conversions have already cost you
This is the uncomfortable part. The double-fire did not just corrupt your data — it actively redirected your budget toward clicks and audiences that generate phantom signals, not real jobs.
Calculating your phantom conversion rate
The formula is straightforward:
Phantom conversion rate = (Reported conversions − Actual conversions) ÷ Reported conversions × 100 If Google Ads reported 40 conversions last month and your actual bookings were 18, roughly 55% of your conversion signals were phantom. That means your Target CPA or Maximise Conversions bidding was calibrated to a benchmark built on data that was more than half fiction. The algorithm was paying for clicks that matched the phantom-conversion profile — clicks that produce a double-fire on your thank-you page but no actual customer.
Running the comparison check in Google Ads right now
- Open Google Ads and go to Campaigns.
- Click Columns — Modify columns — add Conversions and Conv. value to your view if they are not already visible.
- Set the date range to the last 30 days.
- Note the total conversion count.
- Open your CRM, your Cliniko booking history, your ServiceM8 job list, or your email inbox and count real, confirmed enquiries or bookings for the same 30-day period.
- Calculate the gap. A gap of more than 20% is a red flag. A gap of more than 40% is a near-certain double-fire problem in your tag manager setup.
What to do after you fix the tag
Do not immediately change your bid strategy. Google recommends allowing at least two to four weeks of clean conversion data before adjusting bidding — the algorithm needs a reliable signal before it can recalibrate. What you should do immediately:
- Note the exact date you made the trigger change in GTM. Write it in a Google Doc, a calendar event, anywhere you can find it later.
- In Google Ads, use the date as a segment point. Compare conversion counts before and after in your reports — the drop is the evidence that the fix worked.
- If your account uses a third-party reporting dashboard (Agency Analytics, Looker Studio, or a MYOB/Xero integration for revenue tracking), add an annotation on that date so the data break is documented and not misread as a performance collapse.
When to stop DIYing this and call someone who does it daily
The single-conversion-tag fix described in this article is something any owner-operator can do in an evening. But GTM containers in the real world are rarely that clean. If your situation includes any of the following, the trigger architecture becomes non-trivial fast — and a wrong configuration will cost you more in wasted ad spend than a one-hour audit costs.
Signs your container is past the DIY threshold
- You have more than one conversion action tracked (enquiry form and phone call and purchase).
- You use a third-party booking widget (Cliniko, HotDoc, HealthEngine, Timely) that loads in an iframe.
- Your WooCommerce store has upsell, order-bump, or subscription plugins that interact with the checkout flow.
- Your GTM container was set up by a previous contractor whose work you cannot fully trace.
- You have both a Google Analytics 4 conversion event and a Google Ads conversion tag tracking the same action — a common source of double-counting that is separate from the All Pages trigger problem.
- Your site runs on a page builder (Elementor, Divi, Beaver Builder) that loads scripts in a non-standard order, which can cause the GTM snippet to initialise out of sequence.
What SoudCoh's GTM audit actually covers
SoudCoh runs GTM audits for Australian small businesses as part of its Google Ads management service. The audit is not a theoretical review — it is a live Preview-mode walkthrough of every tag and trigger in your container, run against your actual website, with your actual conversion pages. Every mis-firing tag is documented with a screenshot of the fire count, a plain-English explanation of why it is wrong, and a fixed trigger configuration you can verify yourself before anything is published.
The audit output includes a container export — a JSON file of your corrected GTM setup — so if you want a second opinion or want to hand it to a developer, the work is portable and transparent. You are not dependent on SoudCoh to understand what changed.
Why SoudCoh rather than a general digital agency
Most digital agencies fix the tag and move on. The difference with SoudCoh's approach is that every audit includes a before-and-after conversion count comparison using your actual Google Ads data — not a theoretical improvement, but a confirmed drop in phantom conversions with dates and numbers you can verify yourself. If the fix does not reduce your phantom conversion rate, you get an explanation of why and what the correct next step is. There is no invoice for "trust us, it's better now."
You can see how this plays out in practice across SoudCoh's case studies, which document the before and after for Australian service businesses including trades, allied health, and e-commerce operators.
Book a free GTM audit alongside our Google Tag Manager work and get a written list of every mis-firing tag in your container, with a fixed export you can verify yourself before touching your campaigns.

