Why Conversion Tracking is Broken?

So, the number of conversions and revenue are a lot lower in GA4 and Google Ads than what your back-end data shows you. Well, conversion tracking should tell you which marketing campaigns generate leads and sales. Too often, it does not. These are common problems we come across every day and we see the same causes across different sectors and website platforms.

Quick plugins and native integrations make conversion tracking easy to install, but easy does not always mean accurate. Here are five common weaknesses, and how web and server-side Google Tag Manager can create a more reliable measurement setup.

Conversions may be missing, duplicated or attributed to the wrong channel. The numbers reported in Google Analytics 4 (GA4), Google Ads, Meta and an ecommerce platform may all disagree. Worse still, inaccurate conversion data can influence automated bidding, causing advertising platforms to optimise campaigns using unreliable signals.

The problem often begins with a tracking setup chosen because it was quick to install rather than because it was designed around the business’s measurement requirements.

In the accompanying video, I explain five common weaknesses in conversion tracking and how to build a more robust setup using Google Tag Manager (GTM) and server-side GTM.

1. Do not assume a plugin or native integration gives you reliable tracking

WordPress plugins such as Site Kit and ecommerce integrations available through app marketplaces can make GA4 quick to install. That is useful for a basic setup, especially when a business has limited technical resources.

However, convenience comes with trade-offs. You may have limited control over:

• which events are sent;
• when tags fire;
• the data attached to each event;
• consent behaviour;
• duplicate-event prevention;
• debugging and quality assurance; and
• how tracking changes when the plugin or platform is updated.

Most plugins rely on third-party cookies, and even those that do incorporate server-side tracking, set limitaions on which events and parameters which are sent server-side. Bowser-based implementations depend heavily on client-side scripts and requests. These can be restricted by browser privacy controls, content blockers, consent choices, network failures and implementation conflicts.

This creates gaps between what actually happened on the website and what appears in your analytics and advertising platforms.

Why Google Tag Manager is usually a better foundation

A well-managed web GTM container gives you much more control. You can create a documented data layer, use consistent event names, apply validation rules and decide exactly which platforms receive each event.

GTM is not automatically accurate simply because it has been installed. It still needs a proper measurement plan, consent configuration, testing and ongoing governance. But it provides a far more flexible foundation than a collection of disconnected plugins.

2. Remove duplicate GA4 and Google tag loaders

After implementing GTM, check whether another plugin, theme, app or hard-coded script is also loading GA4 or the Google tag.

For example, a YouTube or GA4 app may continue to load its own tracking code after a new GTM implementation goes live. Two loaders can cause:

• duplicate page views or ecommerce events;
• the same transaction being reported more than once;
• conflicting configuration settings;
• inconsistent consent signals;
• inflated conversion rates; and
• more difficult debugging.

This does not mean every website with two Google-related scripts will definitely duplicate every event. The outcome depends on how each implementation is configured. Nevertheless, multiple uncontrolled loaders are a major warning sign. It is generally best practice to limit to a single loader.

Choose one governed implementation and remove or disable redundant tracking. Then test it in GTM Preview, GA4 DebugView and the browser’s network requests before publishing.

3. Move from web GTM to server-side GTM where the business case supports it

Web GTM is a major improvement over a fragmented plugin-based setup, but it still runs primarily in the visitor’s browser. Some measurement requests will be lost because of privacy controls, blockers, poor connectivity, page closures and technical errors.

Server-side Google Tag Manager adds a controlled tagging server between the website and analytics or advertising platforms.

Instead of the browser sending every request directly to several vendors, data can be routed through the business’s tagging endpoint. The server container can then validate, enrich, redact and distribute approved data to its destinations.

Google identifies improved performance, security and data control as key benefits of server-side tagging. A first-party context can also improve cookie durability and reduce the website’s direct communication with third-party domains.

Why consider Stape?

You can host server-side GTM through Google Cloud or another suitable platform. Stape offers managed hosting that can reduce the technical work and cost of deployment, particularly for small and medium-sized organisations.

Its custom-loader options can serve tagging resources from a first-party route and alter recognisable loading patterns. This may improve resilience in some environments, but it should not be described as invisible tracking or as a guaranteed way to defeat blockers. Tracking must still respect consent choices, privacy law and the user’s browser settings.

Server-side tagging is also not a magic fix. A badly designed data layer will send bad data more efficiently. The underlying event logic must be correct before it is routed through a server container.

4. Configure a first-party custom domain

Creating a server container is only part of the job. If it continues to use the cloud provider’s default domain, you will not receive all the benefits associated with first-party serving.

Configure the tagging server on a domain connected to your website—for example, data.example.co.uk—or use a same-origin path where the infrastructure supports it.

Google describes same-origin serving as best practice because it provides the security and durability benefits of server-set cookies. A first-party subdomain is also a common and practical option.

After configuring the domain, verify:

• DNS and SSL are working correctly;
• the web container sends requests to the correct server URL;
• the server client claims the expected requests;
• cookies are set with the intended domain and attributes;
• consent signals pass correctly;
• GA4 and advertising tags receive the expected parameters; and
• the endpoint continues to work after publishing.

A custom domain that exists but is not used by the live tags achieves very little. Test the actual network traffic rather than relying on configuration screens.

5. Send Google Ads conversions directly rather than relying only on GA4 imports

GA4 conversions—now called key events in the GA4 interface—can be imported into Google Ads. This is convenient and can be useful for reporting or as a secondary comparison.

However, for the conversion actions used for bidding, I generally recommend implementing dedicated Google Ads conversion tags through web and server-side GTM. This gives you greater control over the data sent to Google Ads and avoids making the GA4 import the only source used for campaign optimisation.

The dedicated setup should include, where relevant:

• a unique transaction or lead identifier;
• conversion value and currency;
• consent signals;
• enhanced conversions using appropriately collected first-party data; and
• deduplication between browser and server events.

In Google Ads, mark the trusted conversion action as Primary so it is included in the Conversions column and can be used for bidding. Keep the GA4-imported action as Secondary if you want it for observation and comparison without double-counting it in bidding goals.

Do not make this switch blindly. Run both sources in parallel, compare volumes and values, investigate discrepancies and confirm the direct Google Ads action is stable first.

A practical conversion-tracking architecture

A robust setup normally follows this route:

1. The website pushes a clearly defined interaction into a data layer.
2. Web GTM validates the event and applies the user’s consent state.
3. The browser sends approved measurement data to a first-party tagging endpoint.
4. Server-side GTM processes and controls the event.
5. Dedicated tags send the required data to GA4, Google Ads and other approved platforms.

This architecture will not produce a perfect one-to-one record of every conversion. No modern web analytics system can promise that. It does, however, give you more control, better governance and a stronger opportunity to recover valid measurement signals than a collection of unmanaged plugins.

How to check whether your conversion tracking is broken

Look for these warning signs:

• GA4 purchases do not match backend orders;
• the same transaction ID appears more than once;
• Google Ads reports substantially more conversions than your CRM or ecommerce platform;
• key events fire when no genuine conversion occurred;
• several plugins or scripts load the same GA4 measurement ID;
• campaign attribution frequently appears as Direct, Unassigned or Referral;
• consent is denied but marketing tags still set cookies or send identifiable data;
• the server container exists, but browser requests still go directly to vendor domains; or
• GA4 imports and direct Google Ads conversions are both Primary and double-counting the same outcome.

These symptoms do not all have the same cause. A proper audit should examine the website, data layer, GTM containers, consent platform, browser requests, server logs, platform settings and backend totals.

Final thoughts

Fast tracking installations are attractive, but a tracking tag appearing on a website is not proof that conversions are measured correctly.

Start by replacing fragmented plugins with a governed web GTM implementation. Remove duplicate loaders. Where the value and volume of conversions justify it, add server-side GTM, use a genuine first-party endpoint and send dedicated conversion data to advertising platforms.

Most importantly, test the complete journey—from the user’s action to the final platform report. Reliable conversion tracking is an engineered system, not a box to tick.

Call to action: If your analytics and advertising platforms disagree—or you are unsure whether your conversion data is trustworthy—Conversion Uplift can audit your GA4, Google Tag Manager, consent and server-side tracking setup. [Contact us to discuss a conversion-tracking audit.]

Suggested FAQs

Why is my conversion tracking not working?

Common causes include incorrect triggers, duplicate tags, missing consent configuration, browser restrictions, cross-domain problems, broken data-layer values and platform settings that count the wrong actions as conversions.

Is Google Tag Manager more accurate than a WordPress plugin?

Not automatically. GTM provides greater control, debugging and flexibility, which makes a robust implementation easier. Its accuracy still depends on the quality of the event logic, consent setup and testing.

Does server-side GTM prevent all tracking loss?

No. It can improve measurement resilience and control, but it cannot recover every blocked or uncollected interaction. It must also continue to respect valid consent choices and applicable privacy law.

Should I import GA4 conversions into Google Ads?

GA4 imports can be useful for reporting and comparison. For bidding-critical actions, a dedicated Google Ads conversion implementation often gives greater control. Avoid treating both versions of the same conversion as Primary unless intentional deduplication is in place.

Do I need a custom domain for server-side GTM?

You can technically send data to a provider’s default server URL, but a correctly configured first-party domain—or preferably a same-origin path where practical—is needed to gain the main cookie durability and first-party serving benefits.