Optimize event tracking with GTM’s triggers
1. Use an All Elements click trigger to track when key calls-to-action are interacted with.
Navigate to Triggers in the Google Tag Manager user interface. Create a new Click – All Elements trigger. Set the trigger condition to match the element you want to track. Use the matches CSS selector predicate with the Click Element variable for best accuracy. This trigger would fire when any button is clicked. Click Element is a Built-in Variable, so make sure it is activated by going to Variables > Built-in Variables > Configure in the GTM UI. Avoid measuring too much and be deliberate about your measurement to avoid flooding your data set with noise and making it harder to measure meaningful data.
2. Use a Just Links trigger to measure outbound link clicks to learn how users are exiting your site.
Navigate to Triggers in the Google Tag Manager user interface. Create a new Click – Just Links trigger. Set the condition to: Click URL does not contain . This trigger fires whenever a link is clicked where the link URL does not contain “cxl.com” You can experiment with the Wait for Tags and Check Validation settings, but remember to test them thoroughly since they might have negative repercussions on your site’s navigation (particularly Wait for Tags).
3. Track form submissions to find out whether users are interacting with your key calls to action.
Navigate to Triggers in the Google Tag Manager user interface. Create a new Form Submission trigger. Set the trigger condition to match the element you want to track. This trigger will fire when a form with the Form ID contact is submitted. Note that the Form Submission trigger is notoriously fragile because site code often handles forms in ways that aren’t compatible with Google Tag Manager’s trigger. The most typical problem is site code that stops propagation of the Form Submit event – this is common with jQuery. Be sure your site developers know that GTM’s triggers require event propagation all the way to the top of the document.
4. Use the Scroll Depth trigger to measure how far down the content users scroll.
Navigate to Triggers in the Google Tag Manager user interface. Create a new Scroll Depth trigger. Set the Thresholds (pixels or percentages) for the scrolled content. This trigger would fire when the content is scrolled to 25%, 50%, 75% and 100% length Note that the trigger fires when the scrolled content is at any of the given thresholds. It doesn’t actually require a scroll action! For example, if you reload the page while at the bottom of the content, the 100% threshold will fire even though the user didn’t actually scroll to the bottom. Use Enable this trigger on creatively. If your content is loaded dynamically, the Window Load setting is your best friend, as this won’t activate the trigger all content has loaded.
5. Use Visibility triggers that fire when a given element enters the viewport to ensure that users actually see the elements.
Navigate to Triggers in the Google Tag Manager user interface. Create a new Element Visibility trigger Use the CSS Selector selection method to define the element(s) that fire the trigger. Set When to fire this trigger to determine how often can fire per element. Tick Observe DOM changes in case the element is added dynamically to the page (such as a form Thank You message). This trigger fires when an
6. Use Custom Events encoded into dataLayer.push() calls instead of the History trigger to ensure only relevant state changes are tracked.
Ask your web developers to add custom dataLayer.push() calls whenever page transitions take place. Use the Event key in these calls to create a Custom Event Trigger. Set your Page View tags to fire with this Custom Event Trigger. This trigger fires when an event named pageChange is pushed into dataLayer With dynamic page change tracking, the History trigger is often too sensitive for most uses, and you’d need to write complex conditional logic to check things like whether the new URL is different from the previous one. For example, a single-page app might use a few replaceState calls to update the user’s login information and a pushState to update the URL with the login token, while the user would really only see the page load. With custom events pushed into dataLayer by your developers, you have full control over when your virtual page view tags fire in response to page transitions in your single-page app.