FAQ

Frequently Asked Questions

↑ Back to top

The number of conversions counted in Google Ads are less than what’s actually reported in my shop. Why?

↑ Back to top

There are a number of reasons.

1. Google Ads only counts conversions that have been triggered by an ad.
2. The conversion window of Google Ads is typically 30 days (can be customized). That means Google Ads only counts conversions of clicks that happened during that time.
3. If you compare Google Ads to Google Analytics, you also will not see the same numbers, as both have a different standard approach on measuring conversions: https://support.google.com/analytics/answer/2679221

What if a user refreshes the the thankyou page multiple times, does it recount? How do you handle duplication?

↑ Back to top

We also transmit the transaction ID to Google Ads. This helps Google Ads to deduplicate all conversions that have been transmitted more than once.

This process doesn’t run immediately in Google Ads but over a period of several hours after the conversion. So it might happen, that you will see a recent conversion duplicated but then fixed a few hours later.

I see issues in the back-end of my shop. Admin pages get rendered weird, and popups don’t go away when I click to close them. How can I fix this?

↑ Back to top

You probably have some script or ad blocker activated. Deactivate it and the issues should go away. Usually, you can disable the blocker for just that particular site (your WooCommerce back end).

Our plugin injects tracking pixels on the front-end of WooCommerce shops. As a consequence scripts of our plugin have been added to some privacy filter lists. The idea is to prevent the scripts from running if a shop visitor has some ad blocker enabled and wants to visit the front-end of the shop. This is totally ok for visitors of the front-end of the shop. But, it becomes an issue for admins of the shop who have a blocker activated in their browser and visit the back-end of the shop.

Unfortunately, there is no way for us to generally approve our scripts in all blockers for the WooCommerce back end.

Therefore, we recommend admins of the shop to exclude their own shop from the blocker in their browser.

When I open the plugin settings, I see a warning flashing that goes away after half a second or so. What is this?

↑ Back to top

In rare cases scripts, that we use to render the settings page, get blocked. We use those scripts to make the interface faster and more useful. Without those scripts, the settings page would look horrible. And the reason why those scripts sometimes get blocked is ad-and script-blockers that have been installed in the browser of some of the users.

The warning that you see is only intended to be seen by those people who have an active script-blocker. The only way we have come up with so far, to detect if a script blocker is running, is the following:

In the first step, we output the warning into the HTML source of everyone who is accessing the page. And then, in the second step, we hide the warning with a script. This second step will only work for users who have no script blocker running. It is the safest way to be sure that the warning will be seen by users with script blockers. But this method has one downside. If the server is a bit slow, the scripts for people who don’t have a script blocker running, get loaded slow, and therefore it takes half a second or so, until the warning gets hidden.

If this happens to you, you can safely ignore the warning, since it means that no script blocker is running and all is rendered correctly.

In the Google Ads audience manager I see the warning ecomm_prodid never received. Why?

The plugin uses the newest version of the Google Ads dynamic data tracking code, which doesn’t use the ecomm_prodid parameter anymore. This parameter was replaced with the view_item and items parameters. Google specifications

If you see the warning, this could have several causes.

• You haven’t set up the plugin correctly yet. You will need to enable dynamic remarketing within the plugin. Only then that tracking code will be injected.
• You made the switch from the old to the new tracking code just recently. In that case, Google will need a few days before it picks up the new parameters and removes the warning.
• Google Ads is reporting a false warning. The report shows, that a parameter is missing, but in fact it is being transmitted and received by Google Ads. Look at the following example:

If the warning doesn’t go away, please reach out to us and ask for support.

Google Tag Assistant reports multiple installations of Global site tag (gtag.js) detected. What shall I do?

↑ Back to top

There are two main reasons, why this warning pops up.

• You have activated more than one Google service, such as Google Ads and Google Analytics. During initialization gtag.js is configured once for each service. Google Tag Assistant detects this as separate global site tag, but it should not. It is safe to ignore that warning.

We implemented this exactly as specified by Google.

• Some other plugin also injects a gtag source file into the HTML output of the page. As a consequence, the gtag namespace will be declared two times. Technically this is no problem, as they both initialize exactly the same namespace. So one just overwrites the other. Therefore it is safe to ignore that warning.

No conversions are being reported in Google Ads

↑ Back to top

There are several possible reasons why this can happen:

• Cookie Management Platforms (cookie banners) might be blocking the conversion tracking
• Off-page payment gateways need to be configured to redirect back to the purchase confirmation page. If that’s not set up correctly, or if a user interrupts the redirect, no conversion is reported.
• Google Ads only shows conversions which were triggered through an ad click. Please follow these testing procedures exactly: How to test conversion tracking
• It can take up to 48 hours before the conversion appears in Google Ads
• Either the conversion ID or the conversion label or both are wrong
• If you are using caching you must make sure to exclude the purchase confirmation page
• If you are using minification plugins, turn them off and try again. Some minification plugins break the conversion code
• Users who disabled JavaScript or users who are blocking cookies (eg. with ad blockers) can’t be tracked

Not all conversions are being reported

↑ Back to top

Unfortunately, it is not possible to track 100% of all conversions. There are several possible reasons why this can happen:

• Some users might be using Brave browser (that blocks all trackers by default) or strict privacy settings in other browsers.
• Some users might be using privacy-enhancing browser extensions that block Google Analytics and Google Tag Manager. Adblockers and other privacy-related browser extensions.
• Browsers with strict privacy settings.
• JavaScript disabled in a browser.
• Cookie Management Platforms (cookie banners) might be blocking the conversion tracking
• Off-page payment gateways need to be configured to redirect back to the purchase confirmation page. If that’s not set up correctly, or if a user interrupts the redirect, no conversion is reported.

The dismiss button doesn’t work. Why?

↑ Back to top

You are using some kind of ad- or script-blocker in your browser. It blocks the script in our plugin that is responsible to dismiss the notification.

You have the following options:

• Temporarily disable the ad- / script-blocker in your browser and then dismiss the notification.
• Whitelist our scripts in the ad- / script-blocker.
• Switch to a different ad- / script-blocker. Not all of them block our scripts.

We recommend to whitelist our scripts because they are also required on the plugin’s settings page.

Why is tracking accuracy so important?

↑ Back to top

You might ask yourself why tracking accuracy is important and why it can be low.

If for some reason only 20% of the visitors and conversions can be tracked, then paid ads platforms like Google Ads only get 20% of the data that they could get. Such a low accuracy prevents campaigns to run optimally. Actually, the difference in campaign performance can be as large as day and night. We’ve seen revenues and profit margins more than double in certain cases, just by fixing the visitor and conversion tracking. It doesn’t mean that accurate conversion tracking makes every campaign high-performing and profitable. But it will give you the best shot possible.

Here are a few (of many) possible reasons why the accuracy can be low:

• Using off-site payment gateways
• Misconfigured cookie consent banners
• Custom purchase confirmation pages that don’t properly follow WooCommerce specifications

I am using a different Facebook plugin and get the error “Receive the same event_id for many events”. Does this also happen with this plugin?

↑ Back to top

When using Facebook CAPI with other Facebook plugins it can happen that you run into one of the following errors:

• “Deduplication not set”
• “Receive the same event_id for many events”
• “Event Purchase not deduplicated”

This happens when the browser and server-side event IDs are not unique for each event.

Our plugin properly deals with this. It creates a unique event ID for each event which is why you should not run into that issue with our plugin.

Is it possible to use multiple Facebook pixels with the plugin?

↑ Back to top

Short answer: No

Detailed answer: The common reason why you would want to install more than one Facebook pixel is to be able to use more than one Facebook ad account to drive traffic to the same WooCommerce shop. Facebook allows you to share a pixel with other Facebook ad accounts, which makes it unnecessary to install more than one pixel. In fact, sharing the pixel is the best practice. Therefore the WooCommerce Pixel Manager doesn’t offer a way to add multiple Facebook pixels.

Will the Pixel Manager host tracking scripts locally?​

↑ Back to top

After careful analysis, we concluded that there is no benefit in hosting tracking scripts, such as Google Analytics, locally. Considering all factors, hosting the tracking scripts locally is detrimental to the user experience.

The promise stands in the room that when hosting tracking scripts locally this would be beneficial for speed, caching, and improved scores in speed measurement tools such as Google PageSpeed Insights, GT Metrix, etc.

Following is a point-by-point analysis:

Caching on the first page-load on the website

Local: The browser of each visitor has to download the script from your server.

CDN: The browser of the visitor only needs to download the script from the CDN, if the script is not already in the browser cache. It can be in the browser cache already after having visited another website earlier, which includes the same tracking script.

Conclusion: It is very likely that visitors to your website have browsed the web before they reached your website. Therefore using the CDN will much more likely speed things up. Because, in many, if not most cases, the script is already in the browser cache.

Caching on the second page-load on the website

Local: The browser takes the script from the cache. This will only work however if the setup has been done correctly. There is a small chance that the developer didn’t set up the script hosting correctly, which will make the browser download the script on each page load.

CDN: The browser takes the script from the cache.

Conclusion: Both methods take the script from the cache. CDNs are generally better engineered which lowers the risk of some misconfiguration that would lead to disabling the browser cache and making the script download on each page load.

Caching the latest version

Local: In order to make sure that the latest version of the tracking script is served by your website, the developer needs to build some logic to regularly download the latest version from the CDN. This adds complexity which can break. Also, depending on how often this is done, your server might serve outdated versions of the tracking script.

CDN: The CDN always serves the latest version of the tracking script.

Conclusion: In favor of the CDN.

Caching in general

If you want to run a fast website, chances are high that you are using some kind of cache layer. Cache layers usually load the locally hosted scripts into their CDN cache layer keeping an outdated tracking script for much longer. Plus, user browsers will still have to first download the script from there on the first visit. The cross-website CDN cache only works if you use the CDN of the tracking script provider.

Those are two more disadvantages of hosting tracking scripts locally.

Speed

Local: Downloading the script is limited by your server’s bandwidth.

CDN: Downloading the script is limited by the CDN’s bandwidth.

Conclusion: Guess which one is faster. CDNs have much higher bandwidths. Using a CDN will less likely limit the download speed of the script. Also, it alleviates stress on your own server.

Speed Measurement Tools

Speed Measurement Tools such as PageSpeed Insights test with a headless browser with an empty cache. That means they test as if your website is the first thing that the visitor is opening in his browser. That by itself is a special case, because in most cases the visitor has browsed other websites before, and probably has the tracking script in his browser cache from one of those visits already. So using the CDN method again, is the more favorable method.

There is one way how you can fool Speed Measurement Tools and improve your scores massively. Use a JavaScript optimizer that only loads all scripts after the first user interaction on each page of your website. If high PageSpeed scores is what you’re after, this is what you need to do. However, this also comes with a downside. Visitor tracking accuracy will be slightly negatively impacted.

Overall Conclusion

Keep using the CDN version of the scripts.

And don’t get us wrong. Building local script hosting is technically easy to do and would not take much time. We’re not lazy but really convinced that using the tracking script CDNs is a much better option for website owners.

Why is the order count between GA3 (Google Universal Analytics) and GA4 sometimes different (pro version)?

↑ Back to top

GA3 and GA4 should receive and report precisely the same order count and total revenue.

But, due to a few processing differences between GA3 and GA4, you may see differences in the order count for a particular date range.

In the pro version of the plugin, the Pixel Manager sends orders to GA3 using the Google Analytics Measurement Protocol. This is a server-to-server protocol and makes the tracking 100% accurate.

GA4’s setup is a little different from GA3’s. And GA4’s processing speed is slower than GA3’s. So when you analyze data between the two, you need to know what to do to verify the same data.

1. The Pixel Manager Pro version doesn’t use the Google Analytics Measurement Protocol for GA4 out-of-the-box. The reason is that Google introduced a security measure in GA4 to avoid abuse of the Measurement Protocol like it was possible for GA3 (e.g., referrer spam). So you have to set a GA4 API secret in the Pixel Manager. Once the API secret has been added to the settings, the Pixel Manager will also use the Measurement Protocol for GA4.

2. (As long as the Measurement Protocol is inactive, GA4 uses the browser pixel to report orders. This is less accurate because ad blockers or technical issues can prevent the browser pixel from working correctly.)When you compare data between GA3 and GA4, make sure that the from date is a date where the GA4 API secret had been active for the entire day.

3. GA4 takes much longer to process and show orders in the reports. You’ll have to wait 24 hours before comparing a specific date between GA3 and GA4. So if today is December 15, you can only compare data up to December 13.

Following these rules, you should see exactly (or nearly exactly) the same amount of orders and revenue in GA3 and GA4.

Suddenly very long URLs with a _gl parameter show up​

If you see very long URLs with a _gl parameter while browsing your website, don’t worry. This appears when you enable the Google Consent Mode and explicit tracking mode in the Pixel Manager. Under these conditions, the Pixel Manager instructs Google Analytics to track visitors without using cookies. To still be able to track visitors, Google Analytics uses the _gl URL parameter to keep tracking visitors.

Such an URL looks like this:

https://example.com/?_gl=1*3p75d6*_up*MQ..*_ga*MTIwNjU1MjM2NC4xNjc0NTU3MDky*_ga_YQBXCRGVLT*MTY3NDU1NzA5MS4xLjAuMTY3NDU1NzA5MS4wLjAuMA..