PixelYourSite

You can disable the crawler blocking option on the plugin’s Global Settings page.

For a proper solution, we need access to a site where the Litespeed crawler. If you can give us access to such a staging site, it would be perfect. Send us a message directly on our site, please.

The logs are there for debugging only. You should keep them OFF by default.

Very different issues:

1. Catalog matching rate: the events must have the same IDs as the items in your Meta Catalog. If the products are uploaded using Facebook for WooCommerce, you need to use that dedicated option inside our plugin.
2. It’s all explained here: https://www.pixelyoursite.com/facebook-event-match-quality-score

Changing the host will have no impact on events’ IPs. The IP is related to the visitor’s own connection. Some providers simply don’t use IPv6 yet.

All our events have the required event ID. Missing event ID indicates that there is something else triggering the events. In fact, when I check your site I can see that the same pixel is installed twice: once using our plugin, once by something else. Remove that second install. It might be another plugin, like Meta for WordPress. I can’t test the purchase events, so I can’t give you a definitive answer.

As a general answer, make sure that:

1. The pixel is not installed multiple times (seems to be the case here).
2. Purhcase events are not configured outside the plugin (GTM, Meta Events Setup Tool).
3. There is no custom code triggering events (purchase events).
4. Automatic events without code is not enabled inside Meta Events Manager Settings. This is a known source for duplicating purhcase events, since Meta will trigger a purhcase event when the WooCommerce place order button is clicked.

When testing your events with Pixel Helper or inside Events Manager, you can easily identify our events. They have a large number of parameters, including one showing the plugin’s name.

As for the Meta’ support recommendation, it doesn’t apply when you use our plugin. Their instructions are useful if you manually configure your API integration.

You mentioned adding Cookiebot scripts manually. We don’t have support for such an approach. But again, this is not a definitive answer. Cookiebot has ways to block scripts independent of our own integration. They can detect scripts on their own, or use our dedicated filters to control them.

So, while manually added Coockiebot scripts are not supported by us, it doesn’t necessarily mean that Cookiebot can’t detect them. This needs clarified by their team.

You need to remove the manually added code. As a rule, don’t add any extra code, and don’t’ configure events outside the plugin.

Your last screenshot does’t work. Your previous one shows the results from tagassistant.google.com, where normal events are reported as conversions.

However, unlike tagassistant, ads will report conversions only when the event has a conversion label.

Alternatively, you can open each event in tagassistant and confirm they don’t have a conversion label.

Consent plugins are suppose to block tracking until the user agrees to it, so it’s quite normal for the first interaction not to trigger any events. Events should start working once consent is express by the user. Depending on how the consent plugins work, a page refresh might be necessary. This is usually configurable inside the plugin itself.

It’s a good idea to ask similar questions directly to the consent plugin’ support.

Simply delete the pixel from inside the plugin, and save. It’s a good idea to clear all caches too.

That’s just how tagassistant reports each event, showing them as a conversion for some strange reason. The ads system will not count them as conversions.

Hello,

I don’t have a definitive answer because developers of consent solutions such as Cookiebot can use various ways to block scripts or cookies like ours. So it’s best you ask them directly.

Our support for Cookiebot is limited to their plugin, so a manual script configuration will not work as expected.

It was most likely a cache thing, but I can’t tell for sure. The fact that it appeared out of nowhere and went away by itself indicates that something else was the cause of the problem.

Excluding our JS files from caching is helpful.

No need to open a new thread.

We use Meta’s own code that doesn’t include any alt tag for the 1 pixel image. This is just a meaningless warning that some SEO tools can trigger. There is no real impact when it comes to search engines, they are able to understand the actual situation with millions of websites having the same code.

You can disable it completely from the plugin’s settings, is almost never used anyway.

1. Use Pixel Helper Chrome extension to test your events. Make a transaction, and click on the reported Purchase events to see the parameters.
2. It’s a false positive, all our API events are sent in real time.

This particular issue was fixed. However, I am not sure it was related to caches.