FAQ

We started to collect telemetry from users who are willing to share some data with us, like WooCommerce, WordPress and PHP versions, or the shop language:

This will help us to better prioritize our development roadmap for the plugin. For example, we’ve been working on translations recently and didn’t know which ones would be the most important ones (the ones with the highest user count). Unfortunately, the wordpress.org repository doesn’t provide us with much data about that.

Also, we will invest more time to build even more useful features and possibly add some pro features too.

If you wish to help us in this way, you can opt-in, but it is absolutely voluntary and won’t change how the plugin works in any way.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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..

Under rare conditions this so called URL passthrough can cause issues. It is possible to disable it. However, disabling the URL passthrough will also deteriorate tracking accuracy. A better way would be to fix the underlying condition that causes the URL passthrough not to work properly. If you decide to disable the ULR passthrough the following support article explains how to do that: How to disable the Google Analytics url_passthrough

When Meta CAPI is enabled, the Pixel Manager doesn’t send PageView events to Meta CAPI.

Here are the reasons why:

• Tracking PageView events would add tremendous stress to the server. It would be as if no caching is enabled on the server.
• For optimizing campaigns, tracking the PageViews through CAPI is not necessary.
  • Most of the PageViews are being tracked through the browser pixel.
  • The Pixel Manager sends all the lower funnel events, which are important for campaign optimization, to CAPI.

• PageView events are no conversion events. (otherwise, the Conversion API would not be called Conversion API)
• Tracking PageView events is not documented in the Conversion API documentation.

When the GA4 Measurement Protocol is active by adding the GA4 API Secret there are a few shortcomings to be aware of.

While the order purchase count and total amount are tracked much more accurately using the GA4 Measurement Protocol, other metrics and dimensions are not tracked as accurately (or not at all) as they are when using the browser pixel.

• Realtime order events are missing.
• GA4 takes 24 hours up to 48 hours to process and show orders in the reports. You’ll have to wait 48 hours before analyzing or comparing a specific date between your shop system and GA4. So if today is December 15, you can only analyze or compare data up to December 13. This is also true for the channel attribution report.
• Geographic information is missing such as countries and cities. Google’s suggested solution doesn’t work (we tested that). Hopefully they will fix that in the future. (more info)
• Device information: Device information is only available through automatic collection from gtag, Google Tag Manager, or Google Analytics for Firebase.
• When Google Signals is enabled, same device remarketing is supported. For cross-device remarketing, reporting the User ID is an additional requirement. (more info)
• Purchases can only be attributed to a user session for up to 72 hours after the session ends. After that, the purchase is attributed to (not set). That means if a placed order doesn’t change into a paid state within 72 hours (no payment arrived), the purchase will be attributed to (not set).

If geographic information is more important to you than purchase count and purchase value accuracy, you can disable the GA4 Measurement Protocol by removing the GA4 API Secret and using the browser pixel for GA4.

Only partially.

With the Pixel Manager order tracking can only work with the original order and not with the upsells.

FunnelKit (formerly WooFunnels) uses an uncommon way to track orders.

FunnelKit allows adding upsells to the checkout process. That’s great to increase the average order value, and not a problem by itself.

Different from other upsell plugins, FunnelKit allows adding the upsells after the initial purchase. It makes a reservation on the credit card of the customer for the original order. And with each successful upsell, it increases the amount of the reservation.

Similarly to this process, FunnelKit also tracks orders. It tracks the initial order and then sends new purchase events for each successful upsell.

But, there is a significant problem with this approach. FunnelKit doesn’t send the order ID with the initial order because generally, conversion pixels don’t allow to amend the value of the order after it has been sent.

There is one advantage to this approach. The initial order is captured, no matter if the customer later abandons the upsell process or not. And each value of the upsell is also captured.

But, there are several significant disadvantages the shop managers have to deal with:

• Order duplication prevention and order deduplication don’t work. If a customer reloads the thank-you page, the order will be duplicated in Google Ads, Google Analytics, and all other tracking pixels. On average this artificially inflates the order value by 20%. This is an enormous problem for campaign optimization.
• Orders in Google Analytics can not be linked to the original order. This makes it impossible to analyze the customer journey in Google Analytics.
• Google Ads Conversion Adjustments, which allow for even more accurate conversion tracking, can’t be used.

The Pixel Manager’s strength is to track orders accurately, which allows for much better campaign optimization and a much better return on advertising investment. Therefore, we can’t fully support FunnelKit’s order-tracking approach.

No, the Pixel Manager doesn’t directly support the Google Tag Manager (GTM). The Google Tag Manager is a different tracking code manager than the Pixel Manager.

In theory, it is possible to use the GTM alongside the Pixel Manager. But, it is not recommended. The reason is that the GTM is a very complex tool that requires a lot of knowledge to use it correctly. That is true for the GTM itself, and especially true if used alongside the Pixel Manager. You need to make sure that the Google Tag Manager doesn’t interfere with the Pixel Manager, which requires a lot of knowledge about both tools.

If something is missing in the Pixel Manager that you need and think you could solve with the GTM, please let us know (contact). We are always happy to add new features to the Pixel Manager.

No, you shouldn’t. This would lead to double tracking and inaccurate data in Google Analytics.

No, you shouldn’t. This would lead to double tracking and inaccurate data in the respective ad platform.

Currently not.

The Pixel Manager already has a way to make page load times much faster without compromising tracking accuracy through its Lazy Load feature (pro version).

So there is no need to use Cloudflare Zaraz.

However, we will keep an eye on Cloudflare Zaraz and might add support for it in the future.

Currently no.

Google’s threshold to process store sales measurement is very high. The store must have at least 300’000 store visits in average over the past 90 days and a minimum of 30’000 transactions per month. (eligibility)

Generally said, yes, you can, as long as the custom thank-you page follows the WooCommerce specifications.

WooCommerce offers an endpoint and a conditional to check if the current page is the thank-you page. If the custom thank-you page uses the standard WooCommerce endpoint and conditional, the Pixel Manager will work with it. Most plugins that offer custom thank-you pages follow the WooCommerce specifications.

If you want to verify if your custom thank-you page follows the WooCommerce specifications and works with the Pixel Manager, please follow the testing procedure described in the following article: Testing

If your plugin or custom code doesn’t follow the WooCommerce specifications, the Pixel Manager will not work with it. You will have to fix the custom thank-you page by implementing the WooCommerce specifications.

The recommendation is to enable lazy loading in both, your optimization plugin and the Pixel Manager, and exclude the lazy loading of the Pixel Manager script in your optimization plugin.

This will result in all third-party scripts being lazy-loaded by the optimization plugin, while the Pixel Manager manages the lazy loading of its own functions.

You might ask yourself, why enable it in both and then exclude the Pixel Manager in the optimization plugin?

The Pixel Manager has several improvements in its lazy loading logic. One optimization is that the Pixel Manager ensures that the tracking accuracy is as high as possible by automatically disabling lazy loading in the cart and checkout funnel. Those are pages where tracking should always load immediately. Another optimization is to disable lazy loading automatically in case AB testing tools are active within the Pixel Manager. To generate valid test results, AB testing tools need to always be loaded immediately, not delayed.

If you’re using WP Rocket you can enable lazy loading in both without having to manually exclude the Pixel Manager from lazy loading in WP Rocket. The Pixel Manager automatically excludes itself from WP Rocket’s lazy loading.

No. The Pixel Manager takes care of the conversion linker automatically.

When Google Ads is enabled in the Pixel Manager, the Pixel Manager injects the Google gtag.js tracking library into every page of the shop. This tracking library takes care of the conversion linker automatically.

If you see the following warning in your Meta (Facebook) Business Manager, don’t worry. It is not a problem.\

Meta (Facebook) is misguided in those cases. Here is why:

• Browser ID (fbp): The fbp can only be set if the browser loads the Meta (Facebook) pixel. Some visitors use ad or tracking blockers. Those prevent the Meta (Facebook) pixel from loading. This why this percentage cannot be 100%.
• Click ID (fbc): The fbc is only set if the visitor clicks on a Meta (Facebook) ad. If the visitor doesn’t click on a Meta (Facebook) ad, the fbc cannot be set. If not all your visitors come to your website through clicking on a Meta (Facebook) ad, this percentage cannot be 100%. Essentially the percentage is as high as the traffic that comes through Meta (Facebook) ad clicks.
• External ID: The external ID can only be set if a visitor is logged into the shop. The Pixel Manager can’t determine who the visitor is and therefore can’t set the external ID. This is why this percentage cannot be 100%.

The Pro version of the Pixel Manager also allows you to enable Meta’s (Facebook)’s Advanced Matching feature. Once enabled the Pixel Manager will send more identifiers like first name, last name, email, etc. to Meta (Facebook). This will increase the match quality. However, you will need to make sure that your privacy policy allows you to send this data to Meta (Facebook).

If you are using a Content Security Policy (CSP) you need to whitelist the following domains to make the Pixel Manager work:

• myexternalip.com
• ipify.org
• cloudflare.com
• geojs.io
• ipinfo.io
• ipapi.co

The Pixel Manager uses those services to determine the visitor’s IP address and location under certain conditions. For instance, if the Pixel Manager is configured to block the pixels only in certain regions, it needs to detrimne the visitor’s location and decide if the pixels should be blocked or not.

No. You can remove it after you have successfully tested the Meta (Facebook) CAPI. You can also keep it, it doesn’t hurt.

You only need to make sure to updated the test event code when you test again. Facebook requires that the test event code is updated after approx. 24 hours (there is no exact time frame given by Facebook).

As long as you don’t cancel your subscription, we will never increase the price for you. Even if we increase the price for new customers, you will always pay the same price as when you subscribed.

Yes, it is.

To upgrade from the free version of the Pixel Manager plugin to the pro version, you can follow these steps:

1. Visit the Pixel Manager for WooCommerce pricing page by clicking here and choose the pro plan that suits your needs.
2. Purchase the pro plan that aligns with the number of sites you want to set up conversion tracking for.
3. Once you have purchased the pro plan, you will get an email with instructions how to install it.