#GTMTips: Delayed date change trigger – News Couple
ANALYTICS

#GTMTips: Delayed date change trigger


When working with Single Page Application Analytics (SPA), there are a number of things to watch out for. For example, you need to make sure that Google Analytics does not break session referral, and that you are not inadvertently inflating your page speed timing metrics. In fact, there are a lot of “problems” when it comes to SPA tracking in tools like Google Analytics which you can’t get with a plug-and-play implementation.

See Dan Wilkerson’s excellent article, which nicely summarizes a can of worms involved in SPA tracking.

One of the problems with frameworks that dynamically load their content using JavaScript (such as React) is when the log event is sent before The content has been uploaded or the URL has already been changed.

This is a problem, since you may actually want to indicate which items are loaded in this dynamic state change in your tags, but since the Change History is triggered as soon as the event is sent, the content may not be there yet when your tags are activated.

So in this article I will show a quick and dirty way to delay the trigger, so that your tags are not activated until the page has time to load the content.


X


Simmer . Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava right in your inbox!

Tip 79: Delay the date change trigger

The easy way To do this is to launch a Custom HTML tag with the History Trigger change that causes problems on your site.

First, make sure that all the built-in variables related to the registry are enabled in the container.

Then, in your custom HTML tag, add the following code:

<script>
  (function() {
    var timeout = 500; // Milliseconds - change to what you want the timeout to be.
    window.setTimeout(function() {
      window.dataLayer.push(
        event: 'custom.historyChange',
        custom: 
          historyChangeSource: History Source,
          newHistoryState: New History State,
          oldHistoryState: Old History State,
          newHistoryFragment: New History Fragment,
          oldHistoryFragment: Old History Fragment
        
      );
    }, timeout);
  })();
</script>

As mentioned above, be sure to activate this flag on the “change history” trigger you want to delay.

The custom HTML tag adds a delay of 500ms, after which it pushes a custom event named custom.historyChange inside the dataLayer. With this event, five new data layer variables are pushed, each with values ​​from A native The log event that triggered the custom HTML tag in the first place. These new variables are:

  • custom.historyChangeSource – The date event that caused the delay (eg pushState or replaceState).

  • custom.newHistoryState – The state object Set in event history.

  • custom.oldHistoryState – The state object which has been replaced by the new state object.

  • custom.newHistoryFragment – The hash mark part group in history event (eg #contactus).

  • custom.oldHistoryFragment – The hash mark part which has been replaced by new retail.

Now, create a file Custom event trigger event name custom.historyChangeand create data layer variables For all the new custom variables mentioned above (or at least the ones that make sense in your case). Here’s what the trigger and sample variable would look like:

Custom event trigger and data layer variable

Add the custom event trigger to whatever tag you want to fire with the log event, and use the new data layer variables as necessary.

You may be wondering why the original built-in variables are rewritten in the custom data layer variables. This is just a precaution. If your site sends more than one history event before the 500ms delay expires, the inline variables will always indicate the most recent The case of the date, not the one that is overdue.

problem with this approach

There is one, potentially significant problem with this approach. By firing a custom HTML tag with each individual log event, you clog the document object model of the page, because that is unloaded when the user navigates away from the page, not when new content is checked out. For example, after ten historical events, this is what the DOM could eventually look like:

DOM is full of custom html tags

The problem with rewriting the DOM multiple times is that each new element added forces a re-evaluation of the Document Object Model, and the more elements in the DOM, the longer this re-evaluation period. Therefore, the more custom HTML tags that are activated without the page being reloaded or refreshed, the more poorly the page will perform.

Possible solution

One potential solution is to use only one custom HTML tag, which overwrites a file window.history.pushState And window.history.replaceState Techniques. The replaced code must include the delay dataLayer.push(), And you Should Passing arguments to the original window.history.pushState Use apply(), unless you want to destroy your site navigation. See here for inspiration.

Basically, you’re writing a custom event listener, but instead of listening for user interactions, you’re going to listen to it pushState And replaceState events.

I won’t write the solution here – it’s hard to write a general history listener that works for your use case. But this Stack Overflow article should help you get started. Just remember to test Carefully In the case of overwriting basic browser interfaces such as the Window History API.

summary

The trick described in this article should be a file temporary The solution (as all hacks should be). You should really talk to your developers and ask them to implement the custom event push directly to whatever JavaScript handles path/state changes on the site.

By delegating the work to your developers, they can ensure that the dataLayer The event is sent at the exact right time. Using a delay like 500ms from this article is suboptimal for two reasons:

  1. Maybe too short, which means the delay ends, the custom event is pushed, but the transition is still incomplete.

  2. Maybe Very long, which means you waste time with the launcher, keeping track of the page rendering of each dynamic transition that can lag behind events sent with each new piece of content.

Regardless, it’s a way Make things work, which I think is as good a justification as any justification for using a hack.



Source link

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button