New installation & setup

  • Resolved westonworkshops

    (@westonworkshops)


    3 weeks, 1 day ago

    Hi,

    I installed the plug-in over the weekend and found a couple of small bugs:

    1. Import of the GTM template into Google Tag Manager fails with error: File format is invalid. Error deserializing enum type [Type]. Unrecognized value [EVENT].
    2. 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

Viewing 15 replies - 1 through 15 (of 36 total)
1 2 3
  • Plugin Author shan

    (@suhanduman)

    3 weeks, 1 day ago

    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


    Plugin Author shan

    (@suhanduman)

    3 weeks, 1 day ago

    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

    Thread Starter westonworkshops

    (@westonworkshops)

    3 weeks, 1 day ago

    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

    Plugin Author shan

    (@suhanduman)

    3 weeks, 1 day ago

    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

    Thread Starter westonworkshops

    (@westonworkshops)

    3 weeks, 1 day ago

    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

    Plugin Author shan

    (@suhanduman)

    3 weeks, 1 day ago

    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

    Plugin Author shan

    (@suhanduman)

    3 weeks ago

    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

    Thread Starter westonworkshops

    (@westonworkshops)

    3 weeks ago

    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

    Plugin Author shan

    (@suhanduman)

    3 weeks ago

    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

    Thread Starter westonworkshops

    (@westonworkshops)

    3 weeks ago

    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

    Plugin Author shan

    (@suhanduman)

    3 weeks ago

    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_metaevent, 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_metaguarantees that your browser Pixel tag fires at the exact millisecond the unique event_id is ready.

    Regards,
    Suhan

    Thread Starter westonworkshops

    (@westonworkshops)

    2 weeks, 6 days ago

    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

    Thread Starter westonworkshops

    (@westonworkshops)

    2 weeks, 6 days ago

    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

    Plugin Author shan

    (@suhanduman)

    2 weeks, 6 days ago

    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.

    Thread Starter westonworkshops

    (@westonworkshops)

    2 weeks, 6 days ago

    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

Viewing 15 replies - 1 through 15 (of 36 total)
1 2 3

You must be logged in to reply to this topic.