PixelYourSite

Please test the events the way it’s shown in the video. It’s possible is some cases to have those events triggered even when the option is turned OFF.

Do you see the extra purchase event? Does it have our default parameters?

I recommend you watch this video: https://www.youtube.com/watch?v=4eMKGxT7qMk

Meta has an option called “automated events without code” that can lead to purchase events getting fired on the checkout page. This is the first suspect for such a problem.

It looks like I’ve added an answer for a different topic here, sorry about that.

We can look into the cache issues, but since this is about the paid plugin, we are not suppose/allowed to offer support on this forum. Please contact us directly on the site, and mention this conversation. We will take it from there.

Hello,

There is a small chance that even with “automatic events without code” turn OFF, Meta can still trigger the automatic event on the Checkout page, when the place order button is clicked.

Please check this by clicking that button without any data in the checkout form (so that the order is not actually placed). If you see a Purhcase event, check its parameters. If there are only a few, like currency and value, this event is triggered by Meta. It’s the most common cause for such a problem, and the only solution I know is to replace the pixel ID.

If that’s not the problem here, I need more info:

1. Do you see any extra purhcase events when placing an order?
2. Do you see a large number of reported events in the Meta Events Manager reports? It’s suppose to show you tag and browser events, with quite similar numbers. Small differences there are normal.
3. Do you have multiple pixels on the site?

The picture confirm that currency is present with the event that we send automatically.

Do you have other events manually configured inside the plugin? A possible explanation would be that there are such events that don’t have the currency parameter configured. Check on our plugin’s Events page.

Is there anything else that can send Meta API events? Another plugin, GTM, custom code?

Another plausible explanation is a Meta false positive.

The recent update includes some changes that can help with the Litespeed problem. Please update the plugin, and let me know if the issue is still present.

First of all, I am sorry for what happened. I searched all our inboxes and found nothing that resembles what you describe here.

I am not sure what “fake sales” are suppose to be. We fire the purchase event when the order is placed by the customer, we have no way to tell if it’s a fake order.

I tried to think of possible causes of such a mess. The usual suspect, an option Meta has inside Events Manager Settings called “fire automatic events without code” would lead to extra tag Purchase events, but would have no impact on API events. So that’s probably not the issue here. Anyway, it’s important to mention that this option should always be OFF.

There is an interesting mention here: old orders were tracked as conversions.

We have a feature called “Advanced Purchase Tracking” that you can control on the plugin’s WooCommerce page. With this option ON, we will send an API Purhcase event for orders that never triggered the default tag/API purchase event when the order was placed, when such orders’ status is changed to Completed. So there is a scenario when the plugin can send API purhcase events for older orders: when there are orders untracked in real time (maybe the plugin was not installed), and when such orders are modified to Completed.

However, Meta should not and will not automatically see such orders as conversions. We send user data with these API purhcase events, and they can match them correctly. So even in such a scenario, where lots of old orders triggered the API Purhcase event, Meta has plenty of user data to do proper matching and attribution. So for what you describe to happen, another condition would be required: those old clients saw or clicked your recent ads.

But what I explained here is a niche scenario that should not happened all the time. I guess you don’t have a bulk of old orders that are constantly modified to Completed.

The thing is, the plugin will not fire purchase events out of the blue. WooCommerce Purhcase events are fired when orders are placed on the site. As explained, sometimes we fire API Purhcase events when the order status is changed to Completed. There is no other scenario we fire Purchases for WooCommerce.

Automatic Events Without Code, Meta’s own option, can fire extra Purchase events and should be always OFF. Such events get fired when a visitor clicks on the place and order button. These are Tag only events.

Other sources: Purchase events configured inside the plugin. You should know about them, not recommended when using WooCommerce.

Events configured with Meta’s Events setup tool. Again, you should know about them.

Events configured with something else, GTM, custom code, another plugin.

This message should go away once the old UA property code is removed. Do you have the new GA4 tag ID configured but still see the warning?

• This reply was modified 2 months, 3 weeks ago by PixelYourSite.

So it’s working fine now? If yes, please mark this one as completed.

That’s indeed a strange one, we send the same set of events with all our events, both tag or API.

Is there any chanced there is something else sending API events?

Do you see the same issue in our native logs? Open the logs page, enable Meta API Logs, save. Place an order. Get back to the logs, disable and save (to avoid having a large file). Check the data for the purhcase event recorded in the logs. Does it have currency?

@afriville

The WPRocket issue was a different thing, the plugin was hidden for their crawler that preloaded caches. This seems to be a different issue, but it’s not something I am able to replicate. We also use Cloudflare for all our website. Please share a link to the site with the problem, so we can take a look.

What happens when you clear all caches? Do you still have it? If yes, please share the site with this problem, so we can take a look.

@olgamm

I can’t replicate this issue on our end. Please make sure you clear all caches, and test in an incognito window.

I can’t be sure, but it’s probably necessary to remove the previously added code related to the manual implementation.

I’ve answer your message on our site, please check it. Right now, we need to find a way to replicate/investigate the issue.

Hello,

The reported warnings don’t seem related to the PHP version. More likely some data is missing, but it’s not clear why. I can’t replicate the issue on our own testing environment. We can add some checks to avoid the warnings but this will not fix the actual problem.

Send me a message on our site with your URL address. We need to take a closer look.

https://www.pixelyoursite.com/contact