
April 4, 2025
Google Ads Conversion Tracking Not Working? Here’s how to fix it
Updated: April 4th, 2025
Google Ads conversion tracking. The cornerstone of measuring your advertising success, yet sometimes very slippery. If you’re pulling your hair out because Google Ads keeps showing zero conversions, don’t worry; you’re not alone.
There are many places where things could have gone wrong.
If you googled something like “Google Ads conversion tracking not working”, you’ve come to the right place. I’ll walk you through a handful of tips I’ve gathered over the years, covering everything from the basics to the more advanced stuff.
Whether you’re a seasoned pro or just dipping your toes into the world of PPC, buckle up.

Table of Contents
Here’s what you will learn in this article
- 3 categories of tips
- Tips that apply to the native conversion tracking and imported conversions
- #1. Changes in your GTM container are not published
- #2. Check what changes were made in Google Tag Manager
- #3. Tracking codes/GTM were removed from the website’s code
- #4. There must be an ad click before the conversion
- #5. Auto-tagging is not enabled
- #6. gclid is missing from the landing page’s URL
- #7. gclid is removed in web Google Tag Manager container
- #8. gclid is modified
- #9. Consent mode was recently implemented
- #10. Consent mode: ad_storage and ad_user_data remain denied
- #11. Consent mode: regions
- #12. Consent popup/bar is ignored
- #13. You are not sending consent data to Google
- #14. Not enough time has passed
- #15. Iframes
- #16. Multiple domains
- #17. Content security policy
- #18. Browser protection and ad blockers
- #19. Your usual conversion volume is low
- #20. Incorrect conversion ID or label
- #21. Website migration: domain changed
- #22. Website migration: tracking codes were forgotten
- Tips related to the native Google Ads conversion tracking
- Tips related to imported conversions from Google Analytics
- Final Words
3 categories of tips
In this blog post, I will focus on two most popular ways how Google Ads conversion tracking can be implemented (at least, that’s what I see):
#1. Native Google Ads conversion tracking tag in Google Tag Manager when you use this template (or a similar template in the server-side GTM container)
#2. Imported conversions from Google Analytics 4 when you select one or more key event and import it/them to Google Ads.
Quick side note: personally, I always prefer the native tracking because it works more reliably. Looks like this is a general consensus among many people in the industry.
Anyway, since there is more than one conversion tracking method, I have split all tips from this blog post into three categories:
- Tips that apply to both setup methods
- Tips that apply to the native tracking
- Tips that apply to the conversions imported from Google Analytics
Even if you use a different conversion tracking method (for example, a hardcoded Google Tag that sends data directly to Google Ads), many of these tips can still be helpful.
PART I: Tips that apply to the native conversion tracking and imported conversions
Let’s start with the universal troubleshooting tips that apply to both conversion tracking methods.
#1. Changes in your GTM container are not published
We are human, and sometimes we make mistakes. Thus, it’s worth mentioning this reason, too.
When you implement conversion tracking via GTM, you must ensure that changes in your container are published. Every time you change something in the Google Tag Manager container and test it, you have to publish the container. Only then will these changes go live for your website visitors.
Log in to your Google Tag Manager container > Overview and look at the Workspace changes.
If you see that the Google Ads conversion tag (or GA4 tag related to the key event) is in the list of Workspace Changes, it means that you have not published it.
Test that Google Tag Manager setup (with a preview mode) and then publish (by clicking the Submit button in the top-right corner).
#2. Check what changes were made in Google Tag Manager
If you see in your reports that conversion tracking stopped working on a particular day, check if there were any changes made in the Google Tag Manager container around that date.
Let’s say that your conversion tracking broke on August 28th, 2024. Go to Google Tag Manager > Versions and see if anything was published on that day (or several days before that).
If you see something, click on each version in that period and see what exactly was changed. That might give you clues on what to investigate then. Maybe some Google Ads tags were modified. Maybe some tags were paused. Maybe something else.
I cannot give you specific instructions here because there are a million things that could have been changed. But at least you should have more ideas to verify.
If you spent many hours troubleshooting this and still could not find the solution, try rolling back to the container version that was before a certain date (e.g., August 7th, in my case).
You can do that by clicking three dots next to the container version and then selecting “Publish to…”. Then, complete the steps to complete this process.
Also, you should click three dots next to that version and select “Set as Latest Version”.
Then wait for a day or two to see if things got back to normal.
But please keep in mind that you will roll back ALL changes that were made after that version. If you have multiple versions afterward, you will need to implement them once again (manually).
Think of the “rolling back” option as your last resort. Don’t rush here. First, read all the other tips mentioned in this guide.
#3. Tracking codes/GTM were removed from the website’s code
If you cannot find any significant changes in the Google Tag Manager container, ask the developers what code changes they made around the date your Google Ads conversion tracking stopped working.
Maybe they accidentally changed the data layer. Maybe something else. But it’s important to ask them if they modified anything.
For example, it’s possible that they accidentally removed your tracking codes (or Google Tag Manager) from the website’s source code. I had multiple situations where this happened.
In fact, you can check this yourself. I have written a blog post on this topic. Read it and follow the steps.
#4. There must be an ad click before the conversion
If you are working on the Google Ads conversion tracking implementation and you want to verify if Google Ads receives your conversions, keep this in mind: there must be an ad click before the conversion.
If you just fire the Google Ads conversion tag, it won’t be counted as a conversion in their reports.
First, click your ad (e.g., in Google Search or wherever you run ads). Only then should you complete the conversion.
When a visitor lands on your site from an ad click, a cookie is stored in the browser (if consent is given). Then, the conversion tag reads the cookie’s information, and this information is used to attribute the conversion to an ad click. Thus, it’s imperative that you first click the ad.

#5. Auto-tagging is not enabled
Auto-tagging is a feature responsible for adding particular ad-click-related parameter(s) (e.g., gclid) to the URL of your page after the visitor clicks an ad. Then, that information (available in the URL) is stored in a cookie (for example, thanks to the Conversion Linker). Finally, the cookie information is used by Google Analytics and Google Ads to attribute the conversion to a particular conversion.
Having this disabled makes conversion tracking more difficult; thus, it should be kept active.
You can check if auto-tagging is enabled by going to Google Ads > Admin > Account settings > Auto-tagging.
#6. gclid is missing from the landing page’s URL
When a visitor clicks the ad and lands on your site, the page URL contains a special parameter called gclid (if auto-tagging is enabled).
This parameter is necessary because it is stored in a cookie in the visitor’s browser. Later, this cookie is used by the conversion tracking mechanism.
However, it’s possible that your website removes it. And that’s a problem.
You can verify this by clicking one of your ads, landing on your website, and then checking its URL. If gclid is present, that’s good. If not, this must be fixed.
A Chrome extension called Redirect Path will show you any redirects that happen after a specified URL.
Enter the site you want to check, wait for the redirect, and click the Redirect Path extension to see what is causing the redirect.
You can see two things here: the top section shows the link with the gclid, and the bottom section shows that the user was eventually redirected to another URL without it, and the gclid is gone.
The only solution is to work with the developers on your team. Explain the issue to them and see if there is a way they can reconfigure things on the server level to avoid the redirect.
#7. gclid is removed in web Google Tag Manager container
This tip applies if you are tracking Google Ads conversions with server-side GTMÂ or you are importing GA4 conversions to Google Ads.
When I am writing this blog post, Google Analytics 4 does not offer a built-in feature to remove unwanted query parameters. Yes, there is data redaction, but it’s not exactly what we had in the previous version.
As a workaround for that, I wrote a blog post explaining that you can modify the Page URL in the web GTM container and then overwrite the page_location parameter.
The general idea is to create a variable in Google Tag Manager that returns a “cleaner” URL. Then, you set that URL in your GA4 tags.
However, it’s important that you do not remove the gclid parameter this way. So, if you have something like this…
…that’s a problem. I cannot provide specific instructions here because there are various ways how you might have built the variable for “cleaner URL”. But the idea here is that first, you must check if GA4 requests contain the gclid.
Go to tagassistant.google.com and enter your website’s URL. The URL should contain the gclid parameter, too (any bogus value will suffice).
Once the Tag Assistant has connected, check the Page URL (in the browser’s address bar). If gclid is present, go to the Tag Assistant, select your GA4 property’s measurement ID, and click the “Page view” event.
Check if the dl parameter contains the gclid. If not, something in web GTM is overwriting it.
Verify if your Google Tags (and GA4 event tags) have the page_location overwritten, and investigate what that variable does.
Most likely, that variable is causing you the problems. The goal is to ensure that page_location still contains the gclid parameter when the request is sent.

#8. gclid is modified
Technically, this tip could be placed in the section of imported conversions from GA4. But it made sense to mention it here because we are talking about the gclid parameter. Also, it can affect your conversion tracking if you use server-side GTM.
Check the Google Tag (and GA4 event tags) in your Google Tag Manager container.
Maybe page_location is being overwritten in your web container, and the variable sets the value to lowercase. You can check it by enabling Google Tag Manager preview mode. Add a bogus gclid, too. Just make sure that some letters in it are lowercase while others are uppercase.
Once the GTM preview mode is connected, verify the value of the variable that contains the modified page URL. If the gclid in that URL is all lowercase (instead of the original value), that’s a problem.
Google is case-sensitive here. gclid=abcDEF is not the same as gclid=abcdef. Thus, the value must not be modified.
#9. Consent mode was recently implemented
Chances are that you were previously firing your tracking codes/tags without thinking about the user’s consent. The visitor lands on a site, converts, and you track it. That’s it.
Let’s say your business is operating in a region where stricter privacy regulations are in place, and eventually, it decides to take user’s privacy preferences into account. As a result, you started blocking tracking codes from firing if consent was not given.
Or maybe you learned that Google now requires companies in the EEA (European Economic Area) and several other countries to implement Consent Mode (basic or advanced).
This changed the status quo. Previously, you were tracking most of the visitors regardless of their preferences. Now, your tracking setup is limited (by consent mode or by blocked tags when consent is not given).
This means less data. A drop in your conversion numbers can be massive. 30%, 50% or even more of lost data. This is the new normal.
I have seen some people being confused and thinking that if they implement advanced consent mode (CoMo), they will track more conversions. That’s not completely true. Advanced CoMo would track more data ONLY if you were already blocking your tracking codes based on the user’s consent. It can “recover” a portion of *lost* data.
In the EU, we have to block tracking since 2018, when GDPR went live. So, if you were blocking tags and now implemented advanced CoMo, then your numbers will increase to some extent.
But if you were tracking everything you could and only implemented Consent Mode recently, then there will be a drop in your conversions. In fact, it can be pretty significant.
This part of the article is less of a tip and more of a reality check. If your current setup started relying on the user’s consent choices (at least to some extent), there will be a drop in your numbers.
However, it’s also possible that you already expected a drop, but it’s too large (e.g., 90% or more of lost data). Then it’s probably because your Consent Mode setup is incorrect.
In the several upcoming tips, I’ll show you common problems.
Â
#10. Consent mode: ad_storage and ad_user_data remain denied
I will not dive deeper into the proper setup of the consent mode (that goes out of the scope of this article). However, two of the consent groups in CoMo are called ad_storage and ad_user_data.
ad_storage is responsible for setting cookies related to advertising. ad_user_data is responsible for sending user data related to advertising to Google.
If both consent groups remain denied for the visitor, it will affect your Google Ads conversion tracking. You can use Google Tag Assistant to verify this.
Go to tagassistant.google.com and enter your website’s URL. Once the assistant is connected, give consent to the tracking (i.e., by clicking “I agree,” “I accept,” or another similar button that you have on a website). Or maybe you have already given consent before.
Then select the Consent Update in the assistant and go to the Consent tab. If ad_storage and ad_user_data remain denied, that’s a problem. Verify your setup and ensure that consent groups change to granted when consent is given.
By the way, I explain Consent Mode (in-depth) in my Google Tag Manager course for beginners.
#11. Consent mode: regions
Consent mode’s behavior can be modified based on the visitor’s region. For example, you can configure stricter rules for the European Union (where the default is “denied”), and then the US, for example, will always use “granted” as a default.
This can be achieved with the region-specific behavior. However, it can be misconfigured.
gtag('consent', 'default', { 'ad_storage': 'denied', // sets denied for the US and several EU countries 'ad_user_date' : denied, 'region': ['FR,DE,ES,US'] //let's imagine that all EU countries are listed here }); gtag('consent', 'default', { 'ad_storage': 'granted', 'ad_user_date' : 'granted' });
In the example above, the traffic coming from France, Germany, Spain, and other EU countries will get the ad_storage denied (by default). However, the company accidentally included the US on that list, too. They originally intended to have the US (and other non-EU countries) as “granted by default”.
In that case, they should remove the US from the first consent command, and the final code would look like this:
gtag('consent', 'default', { 'ad_storage': 'denied', // sets denied for the US and several EU countries 'ad_user_date' : denied, 'region': ['FR,DE,ES'] //let's imagine that all EU countries are listed here }); gtag('consent', 'default', { 'ad_storage': 'granted', 'ad_user_date' : 'granted' });
The first consent command sets the denied storages for a particular list of countries, while the second command sets a different default command for everything else.
#12. Consent popup/bar is ignored
It’s also possible that your consent mode is implemented properly. However, the cookie consent popup/bar is barely visible and easy to ignore. Take a look below.
The cookie consent message is visible at the very bottom of the page. And if visitors don’t click “Got it!”, the tags will not be fired (or the consent categories will remain “denied” if they are using Advanced Consent Mode).
The visitor can continue browsing the site without ever engaging with this message. That means your conversion numbers will be significantly lower than they could be.
In this case, I would recommend changing the layout of the message. Instead of having a bar at the bottom of the screen, I would change it to a popup that overlays the website’s content (I would add the “Deny” button, too).
Your goal would be to force the user to interact with the cookie consent banner (click either “Accept” or “Deny”).
If you keep the bar like this (at the bottom, barely visible), 90%+ of visitors will probably never interact with it. This means that you lose 90% of data. If you had a popup that blocks the content, the opt-in rate would be higher. Yes, you would still lose some data, but at least not 90%.
#13. You are not sending consent data to Google
This tip applies to businesses that run ads in the EEA (European Economic Area) or several other regions (the region list might be expanded in the future).
Starting March 2024, Google requires advertisers to send consent data with all Google Ads requests (or Google Analytics if you use it for conversion tracking and audience building). This means that an Advanced or Basic Consent Mode must be implemented.
If you haven’t done this, that might be the reason why Google Ads Conversion Tracking is not working for you.
#14. Not enough time has passed
If you just published your Google Ads conversion tracking, the data will not appear in real time. Google mentions different periods you must wait (depending on your setup), but I would say you should wait 24 hours before panicking. Just to be safe.

#15. Iframes
Iframes have always been a pain for web analytics. If your landing page contains an iframe and your tracking codes fire inside that iframe, that might be a problem.
If an iframe is of a different domain (rather than your website’s domain), Google Ads and Google Analytics inside the iframe will not be able to access the necessary ad click cookie data. This means that conversions tracked inside the iframe will not be attributed to Google ads.
Ideally, you should pass the event from the iframe to the parent page and then fire your conversion tags on the parent page. This will ensure that conversion tracking is consistent. I explain iframe tracking in my intermediate/advanced GTM course.
#16. Multiple domains
If your user journey (between an ad click and the conversion) takes place on multiple domains, that will cause problems. Cross-domain tracking should be implemented.
If you import conversions from Google Analytics, configure cross-domain tracking in your GA4 web data stream.
If you are using native Google Ads conversion tracking, use the Conversion Linker tag and configure the Enable linking across domains option inside of it.
When the visitor lands on domainA.com, then clicks a link that redirects them to domainB.com and converts there, cross-domain tracking will handle this kind of journey. It will decorate the links (between domainA and domainB) with special parameters (necessary to set correct cookie values).
However, things get more complicated if a visitor goes from one domain to another after a form submission or another interaction that is not a link click.
Some non-official workarounds have been created, but generally, it’s not a walk in the park.
If a visitor submits a form on domainA.com and is then redirected to a “thank you” page on domainB.com, then I highly HIGHLY recommend your company change the user experience here.
Instead of redirecting visitors to another domain, let them stay on the same domain. It can be a “thank you” page on the same domain or a simple success message that appears without a page reload. Your life would become easier trying to track this.
#17. Content security policy
If your website has a Content Security Policy, it might block Google Ads requests. You can identify this by going to your browser’s developer console (On Windows, Chrome, you should go to Browser’s Menu > More Tools > Developer Tools > Console.
Then, refresh the page. If you can find an error that looks like this (or something similar), this means that you are dealing with the Content Security Policy.
In this case, the URL of the error should contain gooeladservices.com, google.com, or something similar.
What does that mean? Your developers will have to update the CSP of the website. There are no workarounds. You can’t avoid developers here. Here are the instructions on what they should do.
#18. Browser protection and ad blockers
If your Google Ads conversions show zeros, skip to the next tip. This part of the article is just a reminder that losing a portion of conversion data is natural.
Browsers have various protection mechanisms to limit tracking. Also, visitors can use browser extensions that block trackers (like Ghostery, AdBlocker, etc.).
Even though it’s possible (at least right now) to mitigate this with server-side tagging, you should never expect 100% accuracy (I also talk about this here).
So if you had 100 sales (that you know came from Google Ads) but Google Ads only shows 80, this can be considered normal. Don’t forget that consent also plays a significant role here.
If you are testing your conversion tracking setup (after an ad click) and don’t see it the next day, maybe you have an extension that blocked it.
#19. Your usual conversion volume is low
Here’s another situation: your business usually gets just a few sales/leads daily.
If you recently launched conversion tracking and still see zero conversions, you might need to wait longer. There is a higher chance that some converters used browses with stricter privacy settings or ad blockers.
If you usually have 2 conversions per day and Google ads tracked just 1, the sample size is just too small to draw conclusions. You cannot say that you are losing 50% of data. Collect data for a more extended period and see if the situation changes.
#20. Incorrect conversion ID or label
Yes, I understand that this might sound silly, but it’s still worth double-checking. Compare the Conversion ID and Label that you got from Google Ads. Make sure that the same value is used in the Google Ads tag (inside GTM). Make sure that there are no typos.
#21. Website migration: domain changed
Did your business recently migrate to a new domain? If yes, then there will be a dip in the number of conversions attributed to Google Ads.
If a lot of visitors previously were landing on olddomain.com, all ad-click-related cookies were set on the olddomain.com. The Google Ads conversion tracking used that domain.
Now, the visitors land on newdomain.com. Ad-click-related cookies are set on this new domain and when the conversion tag fires, it will be able to access the cookies only of the newdomain.com. They will not be able to access the cookie from olddomain.com (and there are probably thousands of visitors who have that old domain’s cookie(s)).
Sure, Google will try to use third-party cookies, too (I think), but a portion of your visitors have already blocked them.
So, just accept the fact that switching domains will cause a temporary dip in your conversion numbers. But if they dropped to zero, then the problem is somewhere else (keep reading).
If you wonder whether you can migrate all cookies from olddomain.com to newdomain.com, the answer is no.
You could try (for a transitional period) to direct visitors to the olddomain.com where they would need to click a button/link that redirects them to the newdomain.com. Then Google’s cross-domain tracking would handle the cookie. But it’s a pretty terrible way, in my opinion. You are making the user journey worse, and this would still not migrate the cookies of the people who visited you in the past.
So, accept the fact, swallow this hard pill, and move on.

#22. Website migration: tracking codes were forgotten
This happens more often than I wish. A company builds a new website, launches it, and only then informs the analytics/ad agency that this happened.
Since the company was focused more on the color of buttons (#sarcasm), nobody thought about tracking. The result: Google Tag Manager (and/or other tracking codes) were not added to the website. Conversion numbers plummeted. Yikes.
You already know the solution here. Tell the company/developers to add the tracking codes, too. You don’t need to create a new GTM container or new GA4 property. You can keep using the old ones.
However, you must verify that things still work there (maybe some tags/triggers/variables/etc. were configured to look specifically for the old domain).
Also, if the old website had a custom dataLayer, that should be implemented on a new website, too.
Unfortunately, I cannot give you specific tips here because setups vary a lot from one website to another.
PART II: Tips related specifically to the native Google Ads conversion tracking
This next batch of tips is related to the native Google Ads conversion tracking in Google Tag Manager.
#23. Conversion tag is not firing
If your conversion numbers show zeros in Google ads, check if the conversion tag fires in Google Tag Manager preview mode. There are various reasons for that, and I have listed them in this article. For example, maybe your tag conditions are incorrect, or maybe a blocking trigger prevents the tag from firing.
#24. Conversion tag fires right before the redirect
This is relevant if a visitor is redirected to another page when the conversion happens. If you fire a Google Ads conversion tag right before the redirect, the tag might not have enough time to properly send the request.
Then, the tag will be displayed as “Still running” in the preview mode.
The best solution here would be to fire the tag after the redirect (e.g., on the “Thank you” page). Then, the tag will have plenty of time to send the request.
#25. “Still running” tag
This is the continuation of the previous tip (and can also be related to the consent mode). Even if the tag is displayed in the “Tags fired” section of the preview mode, its execution might not have succeeded. Then, you see the “Still running” status.
In some cases, this is not a problem. However, sometimes, it is. That’s why you should verify. I have published a troubleshooting guide explaining the issue in greater detail.
#26. Missing Conversion Linker
Let’s say a person clicks on your ad, lands on a website, and the URL contains the Google Click ID (GCLID). Technically, the browser could store this as a third-party Google Ads cookie.
Provided that a visitor completes an action you’ve defined as a conversion, the Google Ads conversion tracking tag is triggered. Then, the conversion is associated with the initial ad click that brought the visitor to your site.
With the restrictions and the removal of third-party cookies, this is a problem for us. You can no longer rely on the third-party Google Ads cookie to collect this information.
If you have tracking set up with Google Tag Manager, then the Conversion Linker Tag is the solution. This tag stores ad click information in a first-party cookie on your domain, providing Google Ads with the means to measure conversions after a visitor clicks on an ad to your site.
If you open any Google Ads conversion tag in your GTM container and see this message…
Then you’re good to go. Otherwise, you should create the Conversion Linker tag. I talk more about this in my other blog post.
Recently, Google started forcing Google Ads users to implement a Google Tag with the AW- ID. This tag should fire before any Google Ads conversion tag. I have noticed that if Google Tag is implemented, the Google Tag Manager interface no longer asks you to implement the conversion linker.
Nevertheless, if your conversion tracking is not working, it’s worth considering installing the Conversion Linker.
PART III: Tips related specifically to imported conversions from Google Analytics
The following tips are specifically related to conversions that are imported from Google Analytics 4.
#27. Conversion is not created in Google Ads
It’s not enough to link Google Analytics with Google Ads. You also must create a conversion based on the GA4 event.
In Google Ads, go to Goals > Conversions > Summary and check if the conversion (based on a Google Analytics 4 event) is created in that list. If not, click Create conversion action > Import > Google Analytics 4 properties > Web. Then click continue, select the GA4 event, and click Import and continue. Done.
Now, that Google Analytics 4 event will be treated as a conversion in Google Ads. Keep in mind that historical data will not be counted. Conversion will be tracked only after you import it into Google Ads.
#28. Data sharing is not enabled for Ads
Go to your Google Analytics 4 property > Admin > Data streams and select your website data stream.
Expand the Consent settings section and click “Manage data use across Google services“.
If you see that “All Google services” is selected, that’s ok. Skip to the next tip of this blog post. If you see that “Select Google services” is selected, check if Ad services is ticked.
If Ad services is unchecked, select it and then click Save.
#29. Check what changes were made in Google Tag or GA4 property
If your conversion tracking was working but suddenly stopped, check if any changes were made in the settings. There are two places you should verify.
#1. Property change history. First, go to Google Analytics > Admin > Property change history. Here, you will see a list of changes that were made for that particular property.
See if anything was modified around the date when your conversion tracking stopped working. You can click on each change to see more details.
#2. Google Tag changes. Go to Google Analytics > Admin > Data Streams > Select web data stream > Configure tag settings > History.
See if anything was modified around the date when your conversion tracking stopped working. You can click on each change to see more details. Maybe this will give you more clues about what to troubleshoot next.
Google Ads Conversion Tracking Not Working: Final Words
Whew! That was quite the journey. We’ve covered a lot of ground, from the simple “oops, I forgot to publish my GTM container” to the more complex realms.
Keep in mind that perfect tracking is a myth. Between browser protection mechanisms, ad blockers, and the ever-changing landscape of privacy regulations, you’ll always lose some data. The goal is to minimize that loss and ensure you’re capturing as much accurate data as possible.
If you’re still struggling after going through this guide, comment below (and explain your issue). Maybe you have a situation that would be a great addition to this troubleshooting guide.
And if you have any tips/reasons to add to this list, feel free to share them in the comments. I will be more than happy to extend this guide even more.

2 COMMENTS
Hi Julius, thank you for this very helpful article, I very much appreciate the level of detail and practical steps you provide
I also appreciate your offer to share here in a comment if still struggling, so this is this comment:
I believe to have covered every potential cause of missing conversions (Native Google Ad Conversions) that you discuss, and yet very few are actually reported in Google Ads
We have enhanced conversions set up, and advanced Consent Mode, both receiving 'excellent' in Ads diagnostics, in accordance too with our Tag Assistant tests
GA reports about 30% of actual traffic (with a clear drop on the date of implementing Consent Mode)
G Ads registers about 5% of conversions originating from ad clicks. We do not get 100s of conversions per day so I know limited statistics can impact day to day measurement, but looking at a period that does give us 100+ conversions (we know through other means when a sale originate from ad clicks), this 5% reported ad conversions holds
Both the 30% but especially the 5% are data losses higher than I'd expect based on the high consent opt-in rates we see
Might be helpful to add: conversions happen on a 3rd party domain (we have cross domain set in the conversion linker). We also have a conversion for a simple click on the main domain, mainly to see if avoiding the cross domain helps, but it suffers the same level of data loss
I don't want to assume this is sufficient information for you to assess this in full here, I know each setup is complex and unique and not really share-able here, but if there is something that stands out for you, or any suggestion you can offer, I would be very, very grateful
Kind regards,
Heidi
Hi Julius, thank you for this very helpful article, I very much appreciate the level of detail and practical steps you provide
I also appreciate your offer to share here in a comment if still struggling, so this is this comment:
I believe to have covered every potential cause of missing conversions (Native Google Ad Conversions) that you discuss, and yet to my understanding they are heavily under-reported in Google Ads
We have enhanced conversions set up, and advanced Consent Mode, both receiving 'excellent' in Ads diagnostics
GA reports about 30% of actual traffic (with a clear drop on the date of implementing Consent Mode)
Troubleshooted Consent Mode to the best of our knowledge, both with your suggestions and with the iubenda platform support, and no issues come up there, consent shows granted in GTM/Tag assistant if consent is given
G Ads registers about 5% of conversions originating from ad clicks. We do not get 100s of conversions per day so I know limited statistics can impact day to day measurement, but looking at a period that does give us 100+ conversions (we know through other means when a sale originate from ad clicks), this 5% reported ad conversions holds
Both the 30% but especially the 5% are data losses higher than I'd expect based on the high consent opt-in rates we see
Might be helpful to add: conversions happen on a 3rd party domain (we have cross domain set in the conversion linker). We also have a conversion for a simple click on the main domain, mainly to see if avoiding the cross domain helps, and it suffers the same level of data loss
I don't want to assume this is sufficient information for you to assess this in full here, I know each setup is complex and unique and not really share-able in a comment, but if there's something that stands out for you, or any suggestion you can offer, I'd be very grateful
Kind regards,
Heidi