GoogleTagManager-WebTemplate-For-FacebookPixel

Summary When Advanced Matching is enabled on a "Meta Pixel" tag, is called twice within the same, single tag execution — even for the very first tag that fires on a page, before any other tag has run. This triggers Meta's own SDK console warning ("Duplicate Pixel ID: ") on every page load, for any site with at least one Advanced-Matching-enabled tag. This is a regression introduced in v2.0.7 (per ): v2.0.7 Remove enable_reinit_cidparams2 GK and _fbq_gtm_cidparams_initialized window guard; always re-init pixels with cidParams when Advanced Matching data is present. Root cause is declared once per script execution and is the same array reference used by both the first-time-init block and the re-init block below it: This preserves the intended v2.0.7+ behavior (a tag with richer/different Advanced Matching data — e.g. Purchase vs. PageView — still correctly re-applies it, with no data loss) while eliminating the redundant call, and its console warning, whenever the same data would just be reapplied — including on the very first tag fire. Environment Template version: v2.0.8 (also present in v2.0.7) Reproduced via direct execution of 's sandboxed JS in a Node.js context simulating GTM's sandbox API surface (-only globals, no bare , etc.)

Description Hello Meta team, After updating the Meta Pixel GTM template to the latest version, we started experiencing JavaScript issues on a Magento 2 checkout page. Environment Platform: Magento 2 Theme setup: Hyvä theme on most frontend pages Luma-based checkout Tag Manager: Google Tag Manager Template: Meta/Facebook Pixel GTM template Issue appeared after updating the GTM template to the latest version Issue After the latest template update, the template started loading the following bundle: https://capi-automation.s3.us-east-2.amazonaws.com/public/client_js/capiParamBuilder/clientParamBuilder.bundle.js On the Magento 2 checkout page, this caused JavaScript conflicts and instability. In GTM Preview, some Meta Pixel tags were stuck in a state. We also observed logs like: ParamBuilder script loaded successfully, processing and collecting all params... ERROR: clientParamBuilder wasn't loaded correctly. The object was not available on in the checkout page. Investigation The issue appeared only after the latest GTM template update Reverting the GTM container version to a version before the update resolved the issue Checkout started working normally again after the revert This strongly suggests that the issue is related to the Param Builder bundle introduced in the latest template version. Expected behavior The Meta Pixel GTM template should not interfere with Magento 2 checkout JavaScript execution If the Param Builder bundle fails to initialize, the tag should fail gracefully The tag should not remain in a state Actual behavior Checkout JavaScript instability Meta Pixel tags sometimes remain in is undefined Reverting to previous GTM version fixes the issue Suggested improvement The Param Builder integration should be more fault-tolerant. If is not available, the template should: gracefully skip Param Builder logic call to complete execution This would prevent blocking behavior in environments where the script does not initialize properly. Thank you.

Bug report — Meta Pixel GTM Web Template v2.0.8 Repo: Template: Meta Pixel (GTM community gallery, 1158) Version: (, ) Title Advanced Matching re-init block fires a second on a tag's first fire → "[Meta Pixel] - Duplicate Pixel ID" warning Summary A single Meta Pixel tag with Advanced Matching enabled produces a console warning on its very first fire on a page — with no second pixel tag, no hardcoded base pixel, and only one pixel instance created. The cause is a logic error in the re-init block: the first-init loop mutates the same local array that the re-init block then reads, so the re-init block always sees the pixel as "already initialized" and calls a second time in the same execution. Root cause (code walkthrough) The sandboxed template code: On the first fire of a tag with a non-empty : 1. does not contain the pixel ID → first (line 642). 2. mutates the local array (line 648). 3. The re-init block (line 664) checks , which is now true because of step 2. 4. A second runs (line 665) → Meta's SDK logs "Duplicate Pixel ID"* and stamps the agent . The re-init block's own comment (lines 659–661) says it should only run "when we have NOT yet initialized any pixel with cidParams on this page", and the first-init loop sets a window flag (lines 651–654) for exactly this purpose — but the re-init block never reads that flag. It gates only on , which is unconditionally true after the first-init loop pushed the ID. Suggested fix Gate the re-init block on the flag it already sets, so a first fire that just initialized with cidParams does not immediately re-init: (Legitimate cross-tag re-inits — a later tag refreshing Advanced Matching after the pixel was initialized by an earlier tag without* cidParams — still work, because the flag is only set when the first init itself carried cidParams.) Reproduction 1. In GTM, add one Meta Pixel tag with a valid Pixel ID and a non-empty Advanced Matching list. 2. Fire it once on a fresh page load (no other Meta Pixel tag on the page). 3. Observe console: . Live evidence (staging.surlatable.com, single page load) Captured on a shopping-bag page where exactly one Meta Pixel tag fired: events on the load: — no second Meta Pixel tag, no SPA history-change fire. → (one ID). → (one pixel instance — not a duplicate pixel). Pixel string → (proves the re-init branch ran on the lone tag's first fire). No inline in the DOM; single loader. Impact Cosmetic. One pixel instance is created and Advanced Matching data is correctly attached; events are not double-counted. The only effect is the misleading console warning, which causes false "duplicate pixel" investigations.