Over-reporting revenue on G Analytic

Hi @gentlemako

That we need to investigate. The way how the code works, especially in the pro version, it is almost impossible to overreport. So I’m really curious what the details are. Could you send the details of a specific day from Google Analytics and your shop, where you see over reporting? Basically a list of all order IDs. In GA you will find this under > Conversions > E-commerce > Sales Performance.

Please send it to [email protected].

Even better if you can give me access to WooCommerce and GA.

Hello there,

As of today, there’s a big difference between analytic and woo-commerce, after looking at some transaction IDs like you mentioned, I see that Google Analytics is reporting old transactions from April 12 and other old dates for today’s date. like they happened today.

Thank you.

Ah.The reason is, that the Pro version switches from purchase reporting through the browser pixel to purchase reporting through the Google Measurement Protocol. The Measurement Protocol is much more accurate for new orders (for orders from the moment you activate the pro version).

But the way I implemented it, the purchase hit through the Measurement Protocol will happen on each order status change towards order completion (only one report). That means it also happens on orders before activation of the Pro version.

Since on those old orders the purchase report already happened through the pixel, the new report through the Measurement Protocol leads to a duplication.

If you don’t have too many order status changes on old orders anymore, then keep the Pro version running. The duplicate reportings will go away.

I will think of a way to prevent this entirely. It is tricky, so it might take a few days.

kk then, hopefully, it will go away soon.

I already have a fix in dev and will publish it tomorrow or Friday.

I’ll let you know once it’s available.

Ok, Thanks,

One last thing, I see that the plugin is putting a request for cart items on all the pages that take more than half a second to load,

admin-ajax.php?action=wooptpm_get_cart_items / 533.5ms

I don’t have the option that tracks the customer’s cart on MC.

Thanks for your response.

That ajax request is not slowing down the website. The request happens right after the page load.

Please read the following article in our documentation: https://docs.woopt.com/wgact/#/troubleshooting?id=is-wooptpm_get_cart_items-slowing-down-my-website

• This reply was modified 3 years, 6 months ago by alekv.

There is no way to reliably detect within WooCommerce if a mini cart is being used in the theme or not.

For shops where no mini cart is being used I therefore added a filter with wich the shop owner can disable tracking of the mini cart. This will prevent that additional ajax call. (available with the next release)

You will be able to use that filter to disable tracking on a theme where mini cart is still enabled. But, this will impair the measurement for Google Analytics and dynamic remarketing. Since the call is not relevant for page load time anyway, I advise against disabling tracking of the mini cart if it is being used in the theme.

You can use the following filter to deactivate mini cart tracking. Place it in the functions.php of your child theme:

add_filter('wooptpm_track_mini_cart', '__return_false');

Hi @gentlemako

I’ve just released version 1.10.1. If fixes the duplication on orders that happened before activation of the pro version.

Let me know how it goes.

I just updated it to the new version.

You said that disabling the mini cart tracking will impact dynamic remarketing, doesn’t google ads tracking track the click on add to cart button only?

Thank you for your assistance.

That’s a good point. You’re right. Disabling mini cart tracking won’t impact dynamic remarketing for Google Ads. Since Google Ads only track add-to-cart events which we can’t trigger in the mini cart.

It will impact all other tools though that listen to the remove-from-cart event.

Roger that, Thank you.