Conversation
supportHi, I installed the plug-in over the weekend and found a couple of small bugs: Import of the GTM template into Google Tag Manager fails with error: File format is invalid. Error deserializing enum type [Type]. Unrecognized value [EVENT]. In the event log the event time does not reflect the local time on the server – it is two hours ahead in my case. My server is on Prague time, so currently CEST. One other issue I am currently seeing in the Event Log is a lot of spurious PageView and AddToCart events (700+ over the last couple of hours). I do not see corresponding activity in the GA4 realtime view. Any ideas on that? Other than that, I see events coming into Meta CAPI and GA4. More work to be done on my side to tune this I think, but that was expected. Kind regards, Tim
Hello Tim, Thank you for the detailed feedback. Here are the insights regarding the issues you’ve encountered: 1. GTM Template Import Error The Unrecognized value [EVENT] error usually stems from version mismatches between GTM container exports or custom template definitions. Some other users reported the same, and i had re-created the template several times. Solution: While I re-investigate the JSON compatibility, the most reliable path is manual configuration as described in the installation page. Takes couple of minutes to create the required tags manually. Guide: Please refer to the “MANUAL SETUP” section in the readme.txt file included with the plugin. It outlines every variable, trigger, and tag required to mirror the template’s functionality. 2. Event Log Time Mismatch The plugin uses the WordPress native function current_time( 'mysql' ) to log events . Technical Reason: This function retrieves the time based on the settings in your WordPress Admin > Settings > General > Timezone . Fix: If the log is 2 hours ahead of your local Prague time, please ensure your WordPress Timezone setting matches your server’s local time (Prague/CEST) rather than being set to UTC. (Also I’will re-check the code to see if it’s my mistake) 3. Spurious PageView and AddToCart Events Seeing 700+ events that don’t appear in GA4 is a common side effect of server-side tracking being “too accurate.” Bot Activity: Standard GA4 relies on JavaScript. Bots, crawlers, and security scanners (like Wordfence or Ahrefs) often do not execute JS, making them invisible to GA4 Realtime. Server Hooks: Our plugin triggers the AddToCart event using the woocommerce_add_to_cart PHP hook. If a bot hits a URL with an ?add-to-cart=ID parameter—common for price scrapers—the server fires the event regardless of browser activity. Investigation: Check your server access logs for high-frequency requests from specific User Agents or Plug-ins during those hours. You might find a security scanner or a crawler hitting your product links. If you reply with your findings, we can generate a solution together. Kind regards, Suhan
Hello Tim; 1. I think i have found the time mismatch problem. The plugin was saving logs in the WordPress timezone but parsing them back using the server’s PHP default (likely UTC), causing a double-offset. Please do not change your WP settings; I am releasing a fix to standardize logging in UTC and display in your local time. 2. For the bots, i’m adding a User-Agent filter. Regards Suhan
Hi Suhan, Thanks for the quick response and feedback. Re 1) . Yes I already added the tags and triggers manually. However I am going to consolidate those down to a single tag that fires the correct event based on a lookup table that maps ‘GA4 ecommerce event’ to ‘Meta event’. I will share that with you when I have it ready. I noted that all the Meta events are using the same ‘DLV – ecommerce’ variable. Is there a need to do any parameter mapping between the GA4 and Meta data schemas, as I don’t think they fully align? One supplementary question on the tags I created: I did not select the ‘Enhanced Ecommerce dataLayer integration’ or the ‘Use GA4 dataLayer Integration’ options in the Meta Pixel template…is that correct? Re 2). Nothing changed on my side – I will wait for your fix. Re 3). I had sort of assumed it was bot or crawler activity. Happy to work with you on testing some mitigations. Kind regards, Tim
Hi Tim, Your observations are incredibly sharp. You’ve hit on a core architectural nuance between GA4 and Meta. 1. Single Tag Consolidation: Using a Lookup Table variable to map GA4 event names to Meta standard events and firing a single Meta tag is the optimal, cleanest way to structure GTM. Great approach. 2. Parameter Mapping (GA4 vs. Meta Schemas): You are 100% correct. The schemas do not align. Our plugin pushes modern GA4 schema ( ecommerce.items array) to the dataLayer . Meta expects contents (array of id , quantity , item_price ) or content_ids . If you pass the raw {{DLV - ecommerce}} directly into Meta’s Object Properties, Meta receives the items array, which it doesn’t fully understand natively, leading to warnings in Events Manager. To fix this for your consolidated tag, create a Custom JavaScript Variable in GTM to map the GA4 schema to Meta’s schema. Use this variable in your Meta tag’s “Object Properties” field instead of {{DLV - ecommerce}} . Here is the exact mapping script you need: function() { var ecommerce = {{DLV - ecommerce}}; if (!ecommerce || !ecommerce.items) return undefined; var contents = ecommerce.items.map(function(item) { return { id: item.id || item.item_id, quantity: item.quantity || 1, item_price: item.price }; }); return { value: ecommerce.value, currency: ecommerce.currency, content_type: 'product', contents: contents, content_ids: contents.map(function(item) { return item.id; }) }; } 3. Integration Checkboxes in the Template: You were absolutely right not to check “Enhanced Ecommerce dataLayer integration” or “Use GA4 dataLayer Integration”. The specific Facebook Pixel template version relies on the older Universal Analytics (UA) structure ( ecommerce.detail , ecommerce.add ) for its auto-integration. Since our plugin feeds modern GA4 data, checking that box would fail to parse the data anyway. Using the Custom JS mapping variable above keeps you fully in control of the payload. Looking forward to seeing your consolidated setup! BTW, I have applied the fixed and re-generated the gtm template anyway : ) (I hope it works) Regards Suhan
Hi Suhan, Thanks for the update and the suggestion. I will see if I can integrate the script into the workflow. The Meta tags are based on what is now called the ‘Meta Pixel by facebook’ template. That is currently at version 2.0.5 dated 28th April. This version also supports Consent Settings which is a whole other ‘rabbit hole’ to visit. 😀 Back to you in due course. Kind regards, Tim
Hi Tim, You are spot on about the “Meta Pixel by facebook” template. Version 2.0.5 is indeed the standard now. The Custom JavaScript variable I shared will slot perfectly into the “Object Properties” field of that template, bypassing the auto-integration hiccups while keeping everything clean. And yes—Consent Mode is absolutely a rabbit hole! It’s the biggest challenge in tracking today. Getting the server-side events and browser-side signals to align under strict CMP (Consent Management Platform) rules is no small feat. Another user was already reported the same thing today. Take your time with the integration. Whenever you have the consolidated setup ready, or if you run into any weird data-mapping issues along the way, just let me know. I’d love to see how you structure the final lookup table! Good luck with the build! Kind regards, Suhan
Hello; I have published the version v3.5.0-alpha release that implements the best current workaround: Google Consent Mode v2 . (3.4.2 remains the stable release for everyone else) Here is what the Google Consent Mode v2 does: Cookieless Pings: When a visitor denies consent, the updated GTM template allows an anonymous, cookieless ping to be sent to Google instead of completely blocking the tag. Conversion Recovery: Google uses machine learning on these pings to model behavior, allowing you to recover roughly 20% to 50% of the conversions you are currently losing. The PHP code itself is totally identical to 3.4.2. The v3.5.0-alpha update only includes the new GTM template and updated GTM setup instructions in the readme to help you wire up Consent Mode v2 properly. Kind Regards, Suhan
Hi Suhan, One clarification…all the Meta tags are set to fire on the various events but in the Meta Pixel Helper no pixels are reported on the site pages. Do I still need to include the basic Meta Pixel code in the <head> section of the site to successfully capture browser traffic? Tim
Hi Tim, Short answer: No, absolutely do not add the basic Meta Pixel code to your site. If you hardcode the base pixel into your theme while GTM is also trying to fire Meta tags, you will create a duplicate tracking environment. This will completely break the event_id deduplication we set up, causing Meta to double-count your conversions. The GTM tags you configured are designed to automatically inject both the base code and the specific event code whenever they fire. Regards, Suhan
That’s what I thought, but I am starting to doubt my sanity… 😀 Using Meta Pixel Helper in Incognito mode now shows the Pixel as active on the pages. I also just realised that I had the Meta PageView tag triggering on page_view instead of page_view_meta . What is the distinction between those? Tim
Hi Tim; Here is the critical distinction: page_view is a generic event name (often used by GA4 defaults or other plugins). It usually fires without our plugin’s specific deduplication keys. page_view_meta is a custom event pushed explicitly by the Easy Meta CAPI plugin into your dataLayer. If you use a full-page cache (like WP Rocket, Varnish, or Cloudflare), the server delivers identical HTML to every visitor. If we generated the event IDs strictly via PHP, every cached visitor would send the exact same Event ID to Meta, and Meta would deduplicate all your traffic into a single page view. To solve this, my plugin uses JavaScript to generate a mathematically unique event_id for every single visit (combining a path hash, timestamp, and a random string). It pushes this unique ID into the dataLayer explicitly under the page_view_meta event, and immediately sends the exact same event_id to the Meta server via CAPI. If your GTM tag triggers on a generic page_view , it either fires before our script generates the ID, or it misses the ID entirely. This breaks the deduplication between the browser and the server. Triggering specifically on page_view_meta guarantees that your browser Pixel tag fires at the exact millisecond the unique event_id is ready. Regards, Suhan
Hi Suhan, Thanks for the explanation – makes total sense. In this thread discussion we started yesterday I now realise that we might have had mismatch because the version of the plugin I installed on Sunday was actually version 3.3.3 (I am not sure how I ended up with that version as 3.4.2 was available I think). Some of the answers you gave may have been in the context of 3.4.2 which I just got the update notification for and have now updated to. My to-do is now to update the tags for the latest version. BTW I tried loading the GTM template file but it still triggers an error. This time it is: Error deserializing enum type [EventType]. Unrecognized value [customEvent]. I’ll let you know how things look after the next steps. Knd regards, Tim This reply was modified 2 months ago by westonworkshops .
Hi Suhan, I have the 3.4.2 recommended setup now in place with all GA4 / Meta tags, triggers and variables defined (I don’t use Pinterest). The new Custom Javascript variable is also in place. I wanted to get this out-of-the-box setup working before embarking on the ‘unified-tag’ approach. GCMv2 is enabled in CookieYes, and in GTM Preview I can see Consent updates happening as well as the GA4 and Meta tags firing successfully. What I do not see is any activity in t...
Hello Tim, Thank you for the detailed feedback. Here are the insights regarding the issues you’ve encountered: 1. GTM Template Import Error The Unrecognized value [EVENT] error usually stems from version mismatches between GTM container exports or custom template definitions. Some other users reported the same, and i had re-created the template several times. Solution: While I re-investigate the JSON compatibility, the most reliable path is manual configuration as described in the installation page. Takes couple of minutes to create the required tags manually. Guide: Please refer to the “MANUAL SETUP” section in the readme.txt file included with the plugin. It outlines every variable, trigger, and tag required to mirror the template’s functionality. 2. Event Log Time Mismatch The plugin uses the WordPress native function current_time( 'mysql' ) to log events . Technical Reason: This function retrieves the time based on the settings in your WordPress Admin > Settings > General > Timezone . Fix: If the log is 2 hours ahead of your local Prague time, please ensure your WordPress Timezone setting matches your server’s local time (Prague/CEST) rather than being set to UTC. (Also I’will re-check the code to see if it’s my mistake) 3. Spurious PageView and AddToCart Events Seeing 700+ events that don’t appear in GA4 is a common side effect of server-side tracking being “too accurate.” Bot Activity: Standard GA4 relies on JavaScript. Bots, crawlers, and security scanners (like Wordfence or Ahrefs) often do not execute JS, making them invisible to GA4 Realtime. Server Hooks: Our plugin triggers the AddToCart event using the woocommerce_add_to_cart PHP hook. If a bot hits a URL with an ?add-to-cart=ID parameter—common for price scrapers—the server fires the event regardless of browser activity. Investigation: Check your server access logs for high-frequency requests from specific User Agents or Plug-ins during those hours. You might find a security scanner or a crawler hitting your product links. If you reply with your findings, we can generate a solution together. Kind regards, Suhan
Hello Tim; 1. I think i have found the time mismatch problem. The plugin was saving logs in the WordPress timezone but parsing them back using the server’s PHP default (likely UTC), causing a double-offset. Please do not change your WP settings; I am releasing a fix to standardize logging in UTC and display in your local time. 2. For the bots, i’m adding a User-Agent filter. Regards Suhan
Hi Suhan, Thanks for the quick response and feedback. Re 1) . Yes I already added the tags and triggers manually. However I am going to consolidate those down to a single tag that fires the correct event based on a lookup table that maps ‘GA4 ecommerce event’ to ‘Meta event’. I will share that with you when I have it ready. I noted that all the Meta events are using the same ‘DLV – ecommerce’ variable. Is there a need to do any parameter mapping between the GA4 and Meta data schemas, as I don’t think they fully align? One supplementary question on the tags I created: I did not select the ‘Enhanced Ecommerce dataLayer integration’ or the ‘Use GA4 dataLayer Integration’ options in the Meta Pixel template…is that correct? Re 2). Nothing changed on my side – I will wait for your fix. Re 3). I had sort of assumed it was bot or crawler activity. Happy to work with you on testing some mitigations. Kind regards, Tim
Hi Tim, Your observations are incredibly sharp. You’ve hit on a core architectural nuance between GA4 and Meta. 1. Single Tag Consolidation: Using a Lookup Table variable to map GA4 event names to Meta standard events and firing a single Meta tag is the optimal, cleanest way to structure GTM. Great approach. 2. Parameter Mapping (GA4 vs. Meta Schemas): You are 100% correct. The schemas do not align. Our plugin pushes modern GA4 schema ( ecommerce.items array) to the dataLayer . Meta expects contents (array of id , quantity , item_price ) or content_ids . If you pass the raw {{DLV - ecommerce}} directly into Meta’s Object Properties, Meta receives the items array, which it doesn’t fully understand natively, leading to warnings in Events Manager. To fix this for your consolidated tag, create a Custom JavaScript Variable in GTM to map the GA4 schema to Meta’s schema. Use this variable in your Meta tag’s “Object Properties” field instead of {{DLV - ecommerce}} . Here is the exact mapping script you need: function() { var ecommerce = {{DLV - ecommerce}}; if (!ecommerce || !ecommerce.items) return undefined; var contents = ecommerce.items.map(function(item) { return { id: item.id || item.item_id, quantity: item.quantity || 1, item_price: item.price }; }); return { value: ecommerce.value, currency: ecommerce.currency, content_type: 'product', contents: contents, content_ids: contents.map(function(item) { return item.id; }) }; } 3. Integration Checkboxes in the Template: You were absolutely right not to check “Enhanced Ecommerce dataLayer integration” or “Use GA4 dataLayer Integration”. The specific Facebook Pixel template version relies on the older Universal Analytics (UA) structure ( ecommerce.detail , ecommerce.add ) for its auto-integration. Since our plugin feeds modern GA4 data, checking that box would fail to parse the data anyway. Using the Custom JS mapping variable above keeps you fully in control of the payload. Looking forward to seeing your consolidated setup! BTW, I have applied the fixed and re-generated the gtm template anyway : ) (I hope it works) Regards Suhan
Hi Suhan, Thanks for the update and the suggestion. I will see if I can integrate the script into the workflow. The Meta tags are based on what is now called the ‘Meta Pixel by facebook’ template. That is currently at version 2.0.5 dated 28th April. This version also supports Consent Settings which is a whole other ‘rabbit hole’ to visit. 😀 Back to you in due course. Kind regards, Tim
Hi Tim, You are spot on about the “Meta Pixel by facebook” template. Version 2.0.5 is indeed the standard now. The Custom JavaScript variable I shared will slot perfectly into the “Object Properties” field of that template, bypassing the auto-integration hiccups while keeping everything clean. And yes—Consent Mode is absolutely a rabbit hole! It’s the biggest challenge in tracking today. Getting the server-side events and browser-side signals to align under strict CMP (Consent Management Platform) rules is no small feat. Another user was already reported the same thing today. Take your time with the integration. Whenever you have the consolidated setup ready, or if you run into any weird data-mapping issues along the way, just let me know. I’d love to see how you structure the final lookup table! Good luck with the build! Kind regards, Suhan
Hello; I have published the version v3.5.0-alpha release that implements the best current workaround: Google Consent Mode v2 . (3.4.2 remains the stable release for everyone else) Here is what the Google Consent Mode v2 does: Cookieless Pings: When a visitor denies consent, the updated GTM template allows an anonymous, cookieless ping to be sent to Google instead of completely blocking the tag. Conversion Recovery: Google uses machine learning on these pings to model behavior, allowing you to recover roughly 20% to 50% of the conversions you are currently losing. The PHP code itself is totally identical to 3.4.2. The v3.5.0-alpha update only includes the new GTM template and updated GTM setup instructions in the readme to help you wire up Consent Mode v2 properly. Kind Regards, Suhan
Hi Suhan, One clarification…all the Meta tags are set to fire on the various events but in the Meta Pixel Helper no pixels are reported on the site pages. Do I still need to include the basic Meta Pixel code in the <head> section of the site to successfully capture browser traffic? Tim
Hi Tim, Short answer: No, absolutely do not add the basic Meta Pixel code to your site. If you hardcode the base pixel into your theme while GTM is also trying to fire Meta tags, you will create a duplicate tracking environment. This will completely break the event_id deduplication we set up, causing Meta to double-count your conversions. The GTM tags you configured are designed to automatically inject both the base code and the specific event code whenever they fire. Regards, Suhan
That’s what I thought, but I am starting to doubt my sanity… 😀 Using Meta Pixel Helper in Incognito mode now shows the Pixel as active on the pages. I also just realised that I had the Meta PageView tag triggering on page_view instead of page_view_meta . What is the distinction between those? Tim
Hi Tim; Here is the critical distinction: page_view is a generic event name (often used by GA4 defaults or other plugins). It usually fires without our plugin’s specific deduplication keys. page_view_meta is a custom event pushed explicitly by the Easy Meta CAPI plugin into your dataLayer. If you use a full-page cache (like WP Rocket, Varnish, or Cloudflare), the server delivers identical HTML to every visitor. If we generated the event IDs strictly via PHP, every cached visitor would send the exact same Event ID to Meta, and Meta would deduplicate all your traffic into a single page view. To solve this, my plugin uses JavaScript to generate a mathematically unique event_id for every single visit (combining a path hash, timestamp, and a random string). It pushes this unique ID into the dataLayer explicitly under the page_view_meta event, and immediately sends the exact same event_id to the Meta server via CAPI. If your GTM tag triggers on a generic page_view , it either fires before our script generates the ID, or it misses the ID entirely. This breaks the deduplication between the browser and the server. Triggering specifically on page_view_meta guarantees that your browser Pixel tag fires at the exact millisecond the unique event_id is ready. Regards, Suhan
Hi Suhan, Thanks for the explanation – makes total sense. In this thread discussion we started yesterday I now realise that we might have had mismatch because the version of the plugin I installed on Sunday was actually version 3.3.3 (I am not sure how I ended up with that version as 3.4.2 was available I think). Some of the answers you gave may have been in the context of 3.4.2 which I just got the update notification for and have now updated to. My to-do is now to update the tags for the latest version. BTW I tried loading the GTM template file but it still triggers an error. This time it is: Error deserializing enum type [EventType]. Unrecognized value [customEvent]. I’ll let you know how things look after the next steps. Knd regards, Tim This reply was modified 2 months ago by westonworkshops .
Hi Suhan, I have the 3.4.2 recommended setup now in place with all GA4 / Meta tags, triggers and variables defined (I don’t use Pinterest). The new Custom Javascript variable is also in place. I wanted to get this out-of-the-box setup working before embarking on the ‘unified-tag’ approach. GCMv2 is enabled in CookieYes, and in GTM Preview I can see Consent updates happening as well as the GA4 and Meta tags firing successfully. What I do not see is any activity in the Event Log, so I am wondering if events are actually going to Meta CAPI. Any thoughts? Kind regards, Tim
Hello Tim; 1. For the empty Event Log: First; could you please go to WooCommerce > Status > Scheduled Actions and check if the mcapi_process_event_queue hook is stuck in the “Pending” state. 2. I’ll test and add a check for CookieYes GCMv2 mode. (it may block our JSs) 3. Trigger names probably needs uppercase, i’ll update the template to use CUSTOM_EVENT instead of customEvent. New release will also include the Consent Mode explanations. Will be ready soon.
Hi Suhan, I checked the Scheduled Actions. There are no references at all to the mcapi_process_event_queue hook in the 18,500 entries – time to clean that up I think! Tim
Hello Tim, 18,500 entries in Action Scheduler indicates a severe backlog. If the Action Scheduler is choked, background tasks (including WooCommerce order emails, webhooks, and our CAPI queue) will either fail to register or never execute. Here is the immediate action plan: Force the Scheduler: Deactivate and reactivate the All-in-one CAPI for Meta & Pinterest + GTM plugin. This will not delete your settings, but it will forcefully re-register the mcapi_process_event_queue hook into the system. Clear the Backlog: You need to clean up those 18k entries. You can use a free plugin like WP Crontrol to run stuck crons or clean the wp_actionscheduler_actions table directly from your database. Until that queue is breathing again, CAPI events will remain stuck. Update to v3.5.0: The major update is now live. It resolves the GTM template import issue ( CUSTOM_EVENT schema) and includes full integration and documentation for CookieYes and Consent Mode v2. Please update to v3.5.0, deactivate -> reactivate the plugin, and let me know if the Event Log starts populating.
Sorry, I wasn’t clear – all of those (bar about 20) are Completed , a few Failed relating to failed Stripe sessions and a handful that are Pending for scheduled events. I will clean the list anyway for good housekeeping – I have tool for that. I’ll then install 3.5.0 and let you know what happens. Tim
Installed 3.5.0 and I now see this error “There has been a critical error on this website. Please check your site admin email inbox for instructions. If you continue to have problems, please try the support forums .” when clicking on the settings menu. Here is the debug message – looks like CookieYes does not like something: WordPress verze 6.9.4 Aktuální šablona: Avada Child (verze 1.0.0) Aktuální plugin: CookieYes | GDPR Cookie Consent (verze 3.4.2) Verze PHP 8.3.30 Podrobnosti chyby ================= Na řádku č. 47 v souboru /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-content/plugins/cookie-law-info/class-autoloader.php došlo k chybě typu E_ERROR. Chybová zpráva: Uncaught Error: Failed opening required ‘/data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-content/plugins/cookie-law-info/’ (include_path=’.:/usr/share/php’) in /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-content/plugins/cookie-law-info/class-autoloader.php:47 Stack trace: #0 [internal function]: CookieYes\Lite\Autoloader::load_class(‘CookieYes’) #1 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-content/plugins/easy-meta-capi/easy-meta-capi.php (247): class_exists(‘CookieYes’) #2 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-content/plugins/easy-meta-capi/easy-meta-capi.php (500): mcapi_detect_cmp_plugins() #3 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-includes/class-wp-hook.php (341): {closure}(”) #4 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-includes/class-wp-hook.php (365): WP_Hook->apply_filters(NULL, Array) #5 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-includes/plugin.php (522): WP_Hook->do_action(Array) #6 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-admin/admin-header.php (313): do_action(‘admin_notices’) #7 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/ mywave.cz/www/wp-admin/admin.php (244): require_once(‘/data/7/7/77bb2…’) #8 {main} thrown
Actually it’s a bug on CookieYes. (class_exist function) But i have solved it on my side. Released 3.5.1 for you.
OK. Do you want me to notify them about it or have you already done it? I have to pop out for a bit…I will update to 3.5.1 when I get back and continue testing. Tim
v3.5.2 just shipped — full GTM API schema rebuild. (template is working) The previous 3.5.x template wasn’t importing into modern GTM workspaces (Unknown entity type errors). I tested the new build end-to-end in a fresh GTM workspace and it now imports cleanly with all 19 tags, 10 triggers, 13 variables, and the Meta Pixel custom template. Please re-download the template from the plugin settings and re-import. Thanks for the patience while we chased this through. : ) Regards, Suhan
Hi Suhan, I’m really impressed with your level of support here! Thanks for your hard work. I will install it shortly (didn’t get to 3.5.1 yet) and see how things test out. Kind regards, Tim
FYI: I was just offered an update to the Meta template version 19af9 > version 0c574 . Did you see that already? This reply was modified 2 months ago by westonworkshops .
Hi Suhan, Just a quick status update before I head off to bed. 3.5.2 installed and all tags, variables and triggers from the GTM template are in use. Meta template was not updated yet – there was some error condition being flagged with the revised template. Events are being sent to GA and Meta – all visible in GTM Preview. Consent mode seems to be working fine – I will test more tomorrow. Events are visible in the plugin Event Log but still many hits from bot traffic and price scrapers – do you still plan to look at that? The only issue I have noticed so far is that clicking to open the cart page triggers a view_cart event (correct), then a PageView event (correct) followed by a spurious add_to_cart event (incorrect). Not sure why that is happening. I’ll update more tomorrow. Tim
Hi Tim — thanks for the detailed status, very useful. (1) Meta template update error — Could you grab the exact message (or screenshot) when GTM offers the 19af9 → 0c574 update and you accept it? GTM’s “wait, terms of service for this template” or schema-validation message would tell me exactly which field it’s unhappy about. Without that I’d be guessing. (2) Spurious add_to_cart on cart page — Probably needs an improvement, if we hit such a condition: The woocommerce_add_to_cart PHP hook the plugin uses can fire on cart page reload when a third-party plugin (subscriptions, free gifts, cart persistence) re-adds items in the cart-page lifecycle. I can ship 3.5.3 with an early-exit when is_cart() or is_checkout() is true — real add-to-cart actions happen BEFORE the visitor lands on /cart/, so suppressing fires from those two pages is safe. (3) Bot / price-scraper traffic — They are still on the list. The current regex catches self-identifying crawlers (Googlebot, AhrefsBot, etc.) but commercial scrapers spoof real browsers. Could you paste a couple of example User-Agent strings from your Event Log’s failed/spurious rows? With real samples I can extend the regex tightly instead of casting too wide a net and catching real visitors. Regards, Suhan
Hi Suhan, Re 1. It seems that GTM was not telling the truth…the Meta template is in fact updated and is at version 0c574 . Re 2. Sounds plausible. Our Cart page has a progress bar that loads to show how much more value needs to be added to the cart to get free shipping – so that may be a factor. Let me know if you want some more specifics. Re 3. Where does the plug-in store the Event Log…in a directory or in the database? Tim
Hi Tim — thanks for the update. (1) Glad it sorted itself out. Old Meta Pixel plug-ins will be updated with the template. 0c574 is the correct version. (2) The free-shipping progress bar plugin is a strong lead. 3.5.3 (shipping today) already includes a fix for one variant of the cart-widget replay issue: the AJAX add-to-cart payload was previously emitted as an inline script inside a WooCommerce fragment, and WC caches fragments in browser sessionStorage, so any later page load that re-rendered the cart widget would silently fire the script again. 3.5.3 moves the payload to a self-clearing data attribute, so cached fragments are inert on replay. That should cover the browser-side noise. If the spurious events continue after 3.5.3, the next likely vector is your progress bar plugin re-invoking woocommerce_add_to_cart on cart-page render. To confirm or rule out, after upgrading could you check the Event Log on the cart page (no actual add-to-cart action) and let me know if any AddToCart rows appear with source_info matching items already in your cart? (3) Event Log lives in a custom database table (wp_mcapi_logs by default — your table prefix may differ). You can view/filter it from WP Admin → All-in-one CAPI → Logs. Filter by status=failed and event_name=PageView (or any event you suspect bots are spamming), then click any row to see the full User-Agent. Two or three real samples and I’ll extend the bot regex tightly. Thanks again for the patience — 3.5.3 should be live in your auto-update channel within a couple of hours.
Hi Suhan, OK…I’ll check when the next release drops. For the Event Log, in the backend admin for the plugin I see only Success (Meta) messages – no failures. I just cleared the log, so I’ll monitor to see how many events are being recorded over the next 24 hours – my impression is that it may now be less. The messages in the Event Log display are not clickable, but I looked at the database and see that there is no additional info beyond that already displayed. User agent does not seem to be captured. A couple of useful enhancements perhaps: Time/date filtering on the log data. Ability to change the default 15-day log storage period. I will be travelling this afternoon, so I will update you this evening. Tim
Hi Suhan, Back on-line today! I was just able to install the new release. Thanks for the log management features – a good addition! I cleared the log and can confirm that events are now captured in the log with User Agent data. I’ll let it run over the weekend to see what insights I can get on bot activity. Thanks for your support – much appreciated! Tim
Hi Suhan, Logging seems to have stopped…not sure if that means events are still being sent or not. I looked at the database and I can that the log has exactly 1,000 entries. The log runs from 2026-05-09 07:09:37 with 1,000th entry at 2026-05-09 18:16:40 . I checked the PHP error log and I also see the following PHP Warnings now being generated: http://www.mywave.cz [Sun May 10 16:31:10.045065 2026] [proxy_fcgi:error] [pid 716410:tid 136659114899008] [client xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:65058] [upstream php83] AH01071: Got error ‘PHP message: PHP Warning: Undefined variable $events_to_track in /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/easy-meta-capi/easy-meta-capi.php on line 1192; PHP message: PHP Warning: foreach() argument must be of type array|object, null given in /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/easy-meta-capi/easy-meta-capi.php on line 1192’, referer https://www.mywave.cz/wp-admin/admin.php?page=easy-meta-capi&mcapi_filter_nonce_field=yyyyyyyyyy&_wp_http_referer=%2Fwp-admin%2Fadmin.php%3Fpage%3Deasy-meta-capi%26mcapi_filter_nonce_field%3Dyyyyyyyyyy%26filter_event%3DPageView%26filter_from%3D2026-05-04%26filter_to%3D2026-05-10%26filter_action%3DFilter&filter_event=all&filter_from=2026-05-04&filter_to=2026-05-10&filter_action=Filter Note: IPv6 and nonce fields anonymised by me. Looking at the wp_mcapi_event_queue table in the database I see 15,313 entries, with the first of those dated at 2026-05-09 18:16:55 and the last dated at 2026-05-10 18:58:53 . I have dumped the DB to this CSV file – I guess that will give you a good handle on bot activity. Note: The site uses WordFence, so I will be able to set some firewall rules to hopefully minimise the bot activity. I also checked the Woocommerce Scheduled Action list. The mcapi_process_event_queue hook seems to be running fine, with 3,808 completed actions and no failures. The last triggered and ran 1 minute ago, but unclear if any events are being sent as the queue seems to be getting longer rather than shorter. I cleared the event log – the database table is now empty but no new entries are being added. Does that give you some data to work out what is happening? Kind regards, Tim
Hi Tim, Thank you for the incredibly detailed reports. The PHP error log, the queue dump, the Action Scheduler stats — that level of detail let me identify exactly what’s going on. Quick summary, then specifics: The “spurious” PageView and AddToCart events — confirmed bot/scraper activity, not a plugin bug I went through the queue CSV you sent. The traffic profile is unmistakable: 14,036 AddToCart vs only 871 PageView events. Real shoppers always generate far more PageViews than AddToCarts (typical ratio is 5–20× the other way). This inversion means clients are calling the cart endpoint directly without ever navigating the site. (which is impossible) Top source IPs are all known hosting providers: 2a01:4f8:151:841e::2 (171 hits) → Hetzner IPv6 43.130.139.214, 43.130.107.148, 43.131.63.234, 8.219.99.6 (96+ hits combined) → Tencent Cloud (Singapore / HK) 47.237.254.73, 47.236.133.154 (57+ hits) → Alibaba Cloud User-agents are realistic Chrome/macOS strings — that’s why our existing UA-based bot filter in 3.5.3 lets them through. The bots are paying attention to fingerprint detection. This isn’t visitor activity. These are competitor-research scrapers, ad-fraud bots, and price-monitoring tools hitting your add_to_cart endpoint directly. What 3.6.0 does about it (already coded and tested, still working on an elegant solution) The next version adds a server-side datacenter IP filter with the following stack: (real users don’t use datacenters) A 9,000+ CIDR blocklist covering AWS, GCP, Azure, DigitalOcean, Hetzner, Tencent, Alibaba, Linode, Vultr, OVH, Oracle, Fastly — the exact providers your CSV is dominated by. Updates daily from a CC0-licensed upstream. A “real-user bypass” so legitimate visitors behind VPNs/corporate proxies don’t get caught: ad-click IDs (fbclid/gclid/ttclid), Apple iCloud Private Relay egress IPs (whitelisted from Apple’s published list), logged-in WooCommerce customers, and visitors with a _fbp (Meta Pixel) or _ga (Google Analytics) cookie set from a previous visit. Purchase events are never blocked — your revenue tracking stays clean by design. A funnel-chain recovery mechanism: if a real user happens to be filtered (rare edge case) and then completes a Purchase, the plugin replays their full funnel (PageView → ViewContent → AddToCart → InitiateCheckout) so Meta still sees the complete journey. I’ve tested this end-to-end against synthetic bot traffic and against real edge cases (Apple Private Relay, click-ID bypass, etc.). On a sample run, ~95% of datacenter-source events get filtered before they reach the queue or your logs. In the meantime, the Wordfence rule you mentioned will help — blocking known scraper ASNs (AS24940 Hetzner, AS45090 Tencent, AS37963 Alibaba) at the firewall is the right interim move. GTM template “Unrecognized value [EVENT]” import error — fixed This was a real bug in the 3.5.3 template. The container had a built-in variable entry of type “EVENT” that GTM’s deserializer rejected on import in some re...
Hi Suhan, Thanks for the update, Happy the data I provided gave the some good insights to move forward! As of right now (on the 3.5.3) the wp_mcapi_event_queue is at 19,197 events. However the first entry in the table is still timestamped 2026-05-09 18:16:55 (the first event in the CSV file). Is it possible that events are simply not being deleted properly from the table once they are processed? The event log was cleared yesterday in the UI. The database table and log display remain empty as of now. Before I cleared it, the wp_mcapi_logs table had exactly 1,000 entries and had not got any larger. Note that I have set log retention at 5 days. On the site, the time zone is set to: Prague Kind regards, Tim
Hi Tim, 3.6.0 just shipped — should resolve everything you flagged. The queue-leak you spotted is fixed (rows now correctly drop when an event’s send_to targets a platform with no credentials configured, instead of accumulating). I also ran end-to-end tests against the timezone scenario you mentioned and the plugin behaves correctly across the time-difference cases I could reproduce. Really appreciate the thorough review — these were exactly the kind of edge cases that would have been painful to debug in production. Regards, Suhan
Hi Suhan, 3.6.0 installed…I will monitor overnight and feedback tomorrow. Many thanks, Tim
Hi Suhan, Things seem to be working. In the blocklists I have enabled both Auto-fetched and Custom. Some bot traffic has been blocked (348 events) but a lot (nearly 6,000 events in 24 hours) has still got through. I have made a few manual blocks from the Event Log as well. An idea to make manual blocking easier: What about an option to display the Event Log by ‘grouping’ events by IP address? No need to show the individual event details, just show the IP address and the number of events associated to it. If the list is displayed in descending order of the number of events counted, it would then be quick and easy to add the worst offenders to the blocklist with the manual ‘block’ button. Perhaps consider greying out the ‘block’ button when the IP range has been added. Time to go and set some rules on the WordFence firewall! Kind regards, Tim
Hi Tim; Thanks for the suggestions; advice from a real user is incredibly valuable in a UI/UX context. All done and version 3.7.0 was released. Regards, Suhan