search

Adsmurai-Google-Tag-Manager-Templates / adsmurai-facebook-pixel-and-conversions-api

Google Tag Manager template that fires Facebook, TikTok & Pinterest events through regular pixel and Conversions API.
Apache License 2.0
23 stars 8 forks source link

Disable firing PageView on history.pushState() #7

Open kahalabrands opened 1 year ago

kahalabrands commented 1 year ago

Hi, thanks for all the work on this. Wonderful tools here.

I have a situation where one of my vendors requires the history state to track page views. After testing the history.pushState() toggled both on and off and I am getting the same outcome. Toggled on or off fires the page view but only on the browser side. Not getting a server sibling event fired. The event also comes in with no event id. I added a history change trigger for both gtm.historyChange and gtm.historyChange-v2. Used the gtm.historyChange as an exception trigger in hopes that it would negate the history.pushState(). Added the the gtm.historyChange-v2 as a trigger. This configuration fired page views with server sibling but it still fired the same orphaned page view mentioned earlier. So not sure what is going on with this. Need to be able to fix this or find some trigger that will negate the default one being pushed by history.pushState().

For the orphaned page view coming from history.pushState I don't see anything firing in either the client gtm or server gtm debug mode. just fyi

thoughts?

chelseakramer commented 1 year ago

I am seeing this same issue.

@kahalabrands if this helps: **Edit- For me, this issue was caused due to us having multiple FB pixels being initialized in our app. We were using 3 separate GTM tags, all initialized separately, and one of the other tags was calling track() PageView causing duplicate PageViews. We also have a mix of Pixels being sent from the GTM client side container and some from the GTM server side container. In our case, using the default PageView event on the first 2 tags was fine as they were sent from the browser. But sending the default PageView event on the third tag (my server side tag) meant the browser was sending without an event_id and the server sending with an event_id (preventing deduplication on the Facebook side).

To avoid the conflict, Facebook has implemented a trackSingle() method that we used to target individual Pixels.

My FB Pixel tag is initialized on all page views in GTM and looks like this:


<script>
  ... base FB Pixel code
  // initialize first Pixel and track PageView for only that Pixel
  fbq('init', '<Pixel_ID_1>');
  fbq('trackSingle', '<Pixel_ID_1>', 'PageView');

  // initialize second Pixel and track PageView for only that Pixel
  fbq('init', '<Pixel_ID_2>'); 
  fbq('trackSingle', '<Pixel_ID_2>', 'PageView');

  // initialize NEW Pixel and do not track PageView- we have a custom event set up for it that goes through the server container
  fbq.disablePushState = true;
  fbq('init', '<Pixel_ID_3>');
</script>```
ErwanGouyette commented 9 months ago

Hello,

Same here with WIX website. No workaround. Only one Pixel with GTM.

How to get some help with this issue?

Thank you