DEV Community: Kent Spencer

GTM HTML5 Video & Audio Engagement

Kent Spencer — Sun, 26 Jul 2026 17:43:33 +0000

Published · Tags: GTM, GA4, HTML5 Video, HTML5 Audio, Brightcove, CSP, dataLayer, Event Listeners, Custom Templates, Video Engagement

HTML5 & Engagement Tracking in GA4 via GTM — a 2026 Refresh of a 2016 Brightcove Recipe, Built on David Vallejo's Listener Pattern

Track play, pause, progress-percent, and completion for any native HTML5 <video> or <audio> element — Brightcove, self‑hosted MP4, podcasts embedded as <audio>, or anything else that ultimately renders as one of those two tags — using a single Custom HTML listener tag and a native GA4 Event tag. One CSP hash, covers both media types, no per‑vendor JavaScript.

Note: This recipe is a 2026 refactor of a video‑tracking container I originally built in 2016 for a client running Brightcove — a container that, remarkably, is still live on their site today. The underlying pattern is not mine: it is a direct implementation of David Vallejo's excellent 2014 "Tracking HTML5 Videos with GTM" article on Thyngster, which first laid out the tag/rule/macro approach of listening to the native HTML5 media events and pushing them to the dataLayer. All credit for the original concept belongs to him. The JSON container export can be downloaded from Google Drive below.
⬇ Download the GTM Container JSON from Google Drive

Background and Rationale

Back in 2016 I built a Brightcove video‑engagement container for a client, modeled closely on David Vallejo's 2014 Thyngster write‑up: listen for the browser's native play, pause, timeupdate, and ended events on every <video> element on the page, bucket the progress into percent thresholds, and push everything to the dataLayer as a single reusable event. That container is, as of this writing, still running in production for that client a decade later — a good sign the underlying idea has aged well, even as Brightcove's own player markup and GTM's own tooling have moved on.

This post refreshes that original implementation for 2026: it swaps Universal Analytics event pushes for a native GA4 Event tag, replaces vendor‑specific URL parsing with a reusable sandboxed Custom Template, and — the one functional addition beyond Vallejo's original scope — extends the listener to cover <audio> elements as well as <video>, since podcast players and audio‑only embeds share the exact same HTMLMediaElement event API. Everything else — the tag/trigger/variable shape, the reliance on native browser events instead of polling or platform SDKs — is Vallejo's approach, unchanged in spirit.

What's Inside the Container

The exported container (gtm-html5-video-audio-engagement.json) lives in one folder, HTML5 Video Engagement, alongside a shared Analytics folder for the GA4 stream constant. It contains two tags, two triggers, a set of variables covering platform/URL parsing and event‑name mapping, and one Custom Template (URL Component Extractor) that replaces hand‑written per‑vendor JavaScript.

Tags

Tag	Type	Fires On	Purpose
`HTML5 Video Listener`	Custom HTML	Window Loaded	The only custom JavaScript in the recipe. Attaches native event listeners to every `<video>` and `<audio>` element on the page and pushes a `gtm.video` dataLayer event on start, pause, progress‑percent, and completion.
`HTML5 Video Engagement Send Event`	GA4 Event (`gaawe`)	Custom Event: `gtm.video`	Native, already‑sandboxed GA4 Event tag — not Custom HTML. Maps the built‑in Video variables plus the parsed URL variables onto GA4 event parameters using GA4 Enhanced Measurement's own naming (`video_start`, `video_progress`, `video_pause`, `video_complete`) for consistency with any Enhanced Measurement data already in the property.

Triggers

Trigger	Type	Conditions
`Window Loaded - All Pages`	Window Loaded	Fires the single HTML5 Video Listener tag once per page. The listener itself uses a `MutationObserver` to catch media elements that render after this point, so no per‑platform Element Visibility triggers are needed.
`Custom Event - gtm.video`	Custom Event	`{{_event}}` equals `gtm.video`, filtered so `{{HTML5 Video Platform Lookup}}` matches `^[a-zA-Z].*` (i.e., a resolvable platform name). Uses the same event name GTM's own native YouTube video tracking uses. One trigger covers start/progress/pause/complete; branch in tags with `{{Video Status}}` if you need per‑status tags, exactly as you would with a native YouTube trigger.

Note — scope this trigger to your video pages: As published, Window Loaded - All Pages fires on every page. Because the listener's own DOM query (querySelectorAll('video, audio')) is cheap and a no‑op when nothing is found, this is safe — but it is wasteful to run it site‑wide. In your own build, add a page‑path or page‑hostname condition to this trigger (e.g., Page Path matches RegEx a path prefix like ^/videos/, or ^/podcasts/ for audio) so the listener only attaches on pages where you know your target <video>/<audio> elements actually appear. This is also the point at which any applicable host names belong — if your video pages live on a specific subdomain or the Brightcove player is only embedded on a defined set of URLs, restrict the trigger there rather than letting it evaluate globally.

The Listener Tag: How It Works

The HTML5 Video Listener is static vanilla JavaScript with zero {{GTM variable}} interpolation in the tag body. That's deliberate: because the script text never changes between page loads, a CSP script-src 'sha256-...' hash computed for it never changes either. All configuration lives in a plain CONFIG object at the top of the script and in optional data-* attributes on the media element itself — never in GTM variables baked into the tag body.

var CONFIG = {
  eventName: 'gtm.video', // same event GTM's native YouTube tracking uses
  progressThresholds: [1, 10, 25, 50, 75, 90, 99], // % markers
  watchForNewVideos: true, // MutationObserver, for players injected after load
  mediaSelector: 'video, audio' // tracks both <video> and <audio> elements
};

function getProvider(video) {
  // 'html5video' for <video>, 'html5audio' for <audio>
  return video.tagName === 'AUDIO' ? 'html5audio' : 'html5video';
}

['play', 'pause', 'ended', 'timeupdate'].forEach(function(evt) {
  video.addEventListener(evt, handleEvent, false);
});

A few implementation details worth calling out:

Video and audio, one selector. document.querySelectorAll('video, audio') binds the same four listeners — play, pause, ended, timeupdate — to both element types. Every downstream piece (the 8 built‑in Video variables, the URL‑parsing variables, the GA4 tag) is unchanged and now covers audio for free; only gtm.videoProvider branches on tagName to report html5video or html5audio.
Late‑rendered players are still caught. A MutationObserver watches for nodes added after the initial scan, which covers Brightcove‑style players that inject their own <video> node asynchronously, modal/lightbox players, and SPA route changes — without needing a separate Element Visibility trigger per platform.
Title and threshold overrides via data-* attributes, not GTM variables. An author can set title="", data-video-title="", or data-video-progress-thresholds="10,50,90" directly on the media tag to override the auto‑derived title or the default percent markers, on a per‑page or per‑player basis, without ever touching this script or its CSP hash.

Note — only this tag needs a CSP hash: This is the only custom JavaScript in the entire recipe. Because it contains no variable interpolation, you compute one script-src 'sha256-...' hash for it and that hash never has to be recomputed as long as the listener code itself doesn't change. Every other tag in this container — the GA4 Event tag, and the URL‑parsing Custom Template variables — runs as either a native GTM tag type or Sandboxed JavaScript, neither of which is subject to CSP script‑hash requirements, since both execute inside GTM's own sandbox, already covered by the https://www.googletagmanager.com script‑src entry your site already needs.

Reusing `gtm.click` Instead of Reinventing It

Where this recipe deliberately does not add anything new: play/pause button interaction beyond the native media events. Because <video controls> and <audio controls> expose native play/pause events directly on the element, there is no need to separately intercept clicks on the player's own play/pause button — the browser already tells you when playback starts and stops. If your implementation adds custom UI controls layered on top of the native player (a custom play button overlay, for example), that interaction is ordinary DOM interaction and GTM's existing gtm.click / Click trigger machinery — the same built‑in click listener and click variables ({{Click Element}}, {{Click Classes}}, {{Click ID}}, etc.) already ship with GTM — is the right tool, rather than adding bespoke click‑handling JavaScript to the listener tag.

Platform Detection: The URL Component Extractor Template

Rather than hand‑writing regex against {{Video URL}} for every vendor, one sandboxed Custom Template — URL Component Extractor — is instantiated five times, each returning a different piece of the URL (host, path, last path segment, extension, query string) using the sandboxed parseUrl API. Every instance references {{Video URL}} only inside the sandbox, never inside a Custom HTML tag, so none of it is CSP‑relevant.

Variable	Component	Feeds Into
`HTML5 Video URL Host`	host	`HTML5 Video Platform Lookup` (below) and the GA4 `video_url_host` parameter
`HTML5 Video URL Path`	pathname	`video_url_path`
`HTML5 Video URL Filename`	last path segment	`video_url_filename`
`HTML5 Video URL Extension`	file extension	`video_url_extension`
`HTML5 Video URL Query`	query string	`video_url_query`

The HTML5 Video Platform Lookup variable is a Simple Lookup Table keyed off {{HTML5 Video URL Host}}, matching wildcard host patterns such as *brightcove*, *bcove*, *wistia*, *youtube*, *vimeo*, *vidyard*, and *soundcloud* to a friendly platform label. Its own note describes it as a config‑only replacement for what used to be a hand‑written "Coalesce BC ID and Self Hosted" Custom JS variable — this is the place to add a row, not edit code, when a new media platform shows up in your currentSrc values. This is also where any applicable host names belong: if your Brightcove CDN, self‑hosted media bucket, or CDN edge domain differs from the defaults shown here, add or edit rows in this lookup table rather than modifying the listener script.

GA4 Event Mapping

The HTML5 Video Engagement Send Event tag is a native GA4 Event tag (type gaawe), not Custom HTML — already sandboxed by Google. Its event name comes from HTML5 Video Event Name Lookup, a Simple Lookup keyed on {{Video Status}} that maps start → video_start, progress → video_progress, pause → video_pause, and complete → video_complete — the same names GA4 Enhanced Measurement's own native video tracking uses, so this recipe's rows sit consistently alongside any Enhanced Measurement video data already flowing into the property.

Event Parameter	Source Variable
`video_provider`	Video Provider (built‑in)
`video_title`	Video Title (built‑in)
`video_url`	Video URL (built‑in)
`video_current_time`	Video Current Time (built‑in)
`video_duration`	Video Duration (built‑in)
`video_percent`	Video Percent (built‑in)
`visible`	Video Visible (built‑in)
`video_status`	Video Status (built‑in)
`video_platform`	HTML5 Video Platform Lookup
`video_url_host` / `_path` / `_filename` / `_extension` / `_query`	the five URL Component Extractor instances

Replace the {{Measurement Stream ID}} Constant variable (placeholder: G-AAAAAAAA) with your live GA4 Measurement ID after import; the tag references it through measurementIdOverride so it can send independently of an existing GA4 Configuration tag, or you can point it at your existing config tag's own Measurement ID variable if you'd rather not override per‑tag.

Tested With: the Brightcove In‑Page Embed

This recipe was validated against a standard Brightcove In‑Page embed — the same responsive‑wrapper pattern published on CodePen by Broadridge Media:

<!-- start brightcove In-Page embed -->
  <div style="display: block; position: relative; max-width: 100%;">
    <div style="padding-top: 56.25%;">
      <video style="width: 100%; height: 100%; position: absolute; top: 0px; bottom: 0px; right: 0px; left: 0px;border:0;border-radius:5px" data-video-id="4093643993001" data-account="1752604059001" data-player="VyqgG8mql" data-embed="default" class="video-js"
        controls></video>
      <script src="//players.brightcove.net/1752604059001/VyqgG8mql_default/index.min.js"></script>
    </div>
  </div>
<!-- end brightcove In-Page embed -->

Brightcove's player script replaces this markup with its own rendered <video> element after the page has loaded — exactly the "player injected later" case the listener's MutationObserver is there to catch. Note the data-video-id, data-account, and data-player attributes Brightcove leaves on the element: depending on your implementation, you may want to add an additional GTM variable (a small Custom JavaScript or sandboxed template reading {{Click Element}}.getAttribute('data-video-id') equivalent) to surface Brightcove's own video ID as its own event parameter, rather than relying solely on the parsed currentSrc. Or, if your media platform exposes different metadata attributes altogether, the listener's getVideoTitle() helper is the natural place to read them instead — this is implementation‑ and platform‑dependent, so treat the shipped script as a starting point rather than a final answer for your specific player.

How to Import

Download the JSON from the Google Drive link above.
In GTM, go to Admin → Import Container.
Upload gtm-html5-video-audio-engagement.json.
Choose Merge (not Overwrite) to preserve your existing container setup, and pick a new workspace so you can review the diff before publishing.
Update the Measurement Stream ID Constant variable to your live GA4 Measurement ID.
Add a page‑path or hostname condition to the Window Loaded - All Pages trigger so the listener only attaches on pages where your <video> / <audio> elements actually live.
Review and, if needed, extend the rows in HTML5 Video Platform Lookup to match your actual player host names (Brightcove account/player subdomain, self‑hosted CDN, etc.).
Compute a CSP script-src 'sha256-...' hash for the HTML5 Video Listener tag's script body if your site enforces a strict CSP, and add it to your policy. No other tag in this container needs one.
Verify consent settings: the listener requires analytics_storage in this export — adjust to match your CMP setup.
Open GTM Preview mode, load a page containing your video/audio embed, and confirm the gtm.video event fires in the dataLayer on play, at each progress threshold, on pause, and on completion, and that the GA4 Event tag fires alongside it.

The full source — container JSON and documentation — is also published on GitHub. Renewed thanks to David Vallejo / Thyngster for the original 2014 pattern this recipe is built on. If you extend the platform lookup table, add support for additional data-* metadata attributes, or adapt this for a different media platform, open a pull request or issue.

⬇ Download GTM Container JSON

GTM User Session Counter

Kent Spencer — Fri, 24 Jul 2026 12:24:41 +0000

Persistent User Session Counter in Google Tag Manager — A Complete Recipe

Track how many times each visitor has started a new session — no server-side code, no CSP SHA-256 hashes required — and use the count to trigger conversion events, popups, and personalisation logic.

Published · Tags: GTM, Google Analytics 4, Cookies, Sessions, Custom Templates, JavaScript, dataLayer

Most analytics setups can tell you how many sessions a user has started in total across your property, but very few can answer the question at tag-fire time: "Is this visitor on their first session? Their third? Their tenth?" This recipe wires up a fully sandboxed GTM solution that increments a persistent counter cookie on every new session, pushes the count to the dataLayer as a named event, and extends the cookie's expiry on each return visit — all without a single line of Custom HTML or any SHA-256 CSP policy changes.

⬇ Download the GTM Container JSON from Google Drive

Why This Matters

Session count is one of the most actionable engagement signals you can capture. Knowing that a visitor is on their third session lets you:

Fire a conversion-nudge popup only for returning visitors (not first-timers)
Use the dataLayer event as a GA4 custom event trigger for micro-conversion reporting
Suppress first-session noise in paid-media conversion tracking
Build GA4 audiences segmented by session depth (1 session, 2–5 sessions, 6+ sessions)
Feed the count into other GTM tags as a variable — no extra API calls needed

No CSP changes required. Because this recipe uses only GTM's sandboxed Custom Template API (getCookieValues, setCookie, createQueue), there is no inline <script> block whose SHA-256 hash would need to be declared in your Content-Security-Policy header. Everything runs inside GTM's own sandboxed runtime.

What's Inside the Container

The exported container JSON (user-session-counter-measurement-recipe.json) bundles two tags, one trigger, and five custom templates across 25 variables:

Asset Type	Name	Purpose
Tag (Custom Template)	User Session Counter	Reads the persistent counter cookie, increments it, writes it back, and pushes a `dataLayer` event — once per session via a session-scoped guard cookie
Tag (Custom Template)	Extend Cookie Life Tag	On DOM Ready, refreshes the persistent counter cookie's `max-age` so a returning visitor resets the expiry clock without changing the count
Tag (Google Tag)	Google Analytics Configuration	Standard GA4 config tag wired to environment-aware Stream IDs via a RegEx lookup variable
Trigger	Extend Cookie Life Trigger	DOM Ready trigger — fires only when the Extend Cookie Life session-guard cookie is absent or falsy, ensuring one rewrite per session
Custom Template	User Session Counter	The sandboxed JS engine for reading, incrementing, and persisting the counter
Custom Template	Cookie Rewriter	Sandboxed template that refreshes a list of persistent cookies to extend their `max-age`
Custom Template	If Else If – Advanced Lookup Table	Environment-aware RegEx lookup for GA4 Stream ID routing (dev vs. prod)
Custom Template	Timestamp	Millisecond timestamp utility used by session/user ID variables
Custom Template	Get Root Domain	Resolves the root domain for cookie scoping across subdomains

Architecture Overview

The flow across a visitor's two sessions illustrates how the guard-cookie + persistent-cookie pattern works:

Session 1 (first visit ever)

GTM initialises. The User Session Counter tag fires (it has no limiting trigger — it fires on every container load by default, and its own session guard is the gatekeeper).
Session guard is absent. The tag reads the _arusc cookie (Already Ran User Session Counter). It is absent, so sessionIsZero is true.
Persistent counter is absent. The tag reads _i_vstcnt. It doesn't exist yet, so it is initialised to 0 and a persistent cookie is written with a 720-day max-age.
Counter is incremented. 0 + 1 = 1. The counter cookie is rewritten with value 1 and a 720-day max-age.
dataLayer event is pushed. { event: '_i_vstcnt', userSessionCounter: 1 } fires. Any downstream tags listening for this event name (e.g. GA4 event tags, popup triggers) activate now.
Session guard is stamped. _arusc=1 is written as a session cookie (no max-age, expires when the browser closes). This prevents the counter from incrementing again during the same session.
DOM Ready fires. The Extend Cookie Life Trigger activates because _arrewr is absent. The Cookie Rewriter tag refreshes the max-age of _i_vstcnt to another 720 days, then stamps _arrewr=1 for the rest of the session.

Session 2 (return visit, same browser)

_arusc is absent (it was a session cookie — it expired with the browser close). The counter tag fires again.
_i_vstcnt exists with value 1. The tag reads it, increments to 2, writes it back.
dataLayer push: { event: '_i_vstcnt', userSessionCounter: 2 }.
Cookie life is extended again on DOM Ready.

The User Session Counter Template — Sandboxed JS

This is the heart of the recipe. It runs entirely inside GTM's sandboxed JavaScript environment — no document.cookie, no window access — using only approved GTM APIs. This is why no CSP SHA-256 hash is needed : the sandbox, not a Custom HTML tag, is doing all the cookie work.

const log = require('logToConsole');
const getCookieValues = require('getCookieValues');
const setCookie = require('setCookie');
const createQueue = require('createQueue');
const dataLayerPush = createQueue('dataLayer');

const alreadyRanUserSessionCounter = data.alreadyRanUserSessionCounterName || '_arusc';
const cookieName = data.userSessionCounter || 'usrSsnCtr';
const sessionValues = getCookieValues(alreadyRanUserSessionCounter);
const sessionRaw = sessionValues && sessionValues.length > 0 ? sessionValues[0] : null;
const sessionExists = sessionRaw !== null;
const sessionIsZero = !sessionExists || (sessionRaw - 0) === 0;

if (!sessionExists) {
  setCookie(alreadyRanUserSessionCounter, '0', { domain: data.rootDomain, path: '/' });
}

if (sessionIsZero) {
  const persistValues = getCookieValues(cookieName);
  const persistRaw = persistValues && persistValues.length > 0 ? persistValues[0] : null;
  const persistExists = persistRaw !== null;
  let currentCount = 0;

  if (!persistExists) {
    setCookie(cookieName, '0', {
      domain: data.rootDomain,
      path: '/',
      'max-age': 60 * 60 * 24 * (data.persistentCookieExpires - 0)
    });
    currentCount = 0;
  } else {
    currentCount = (persistRaw - 0);
  }

  const newCount = currentCount + 1;

  setCookie(cookieName, newCount.toString(), {
    domain: data.rootDomain,
    path: '/',
    'max-age': 60 * 60 * 24 * (data.persistentCookieExpires - 0)
  });

  dataLayerPush({
    event: cookieName,
    userSessionCounter: newCount
  });

  setCookie(alreadyRanUserSessionCounter, '1', { domain: data.rootDomain, path: '/' });
}

data.gtmOnSuccess();

Dual-purpose dataLayer push: The event name is set to the cookie name itself (_i_vstcnt by default). This means the same event can be listened to by a Custom Event trigger in GTM, enabling the session count to serve as a trigger for GA4 conversion events, timed popup dialogs, chat widget activations, or any other tag that should fire at specific session-depth thresholds.

The Cookie Rewriter Template — Extending Cookie Life

A 720-day max-age is written when the counter cookie is first created, and again each time it is incremented — but what about sessions where the user returns after a long gap and the cookie would otherwise have been expiring soon? The Cookie Rewriter (Extend Cookie Life Tag) handles this: on every session's DOM Ready, it reads the current value and rewrites the cookie with a fresh 720-day expiry.

var getCookieValues = require('getCookieValues');
var setCookie = require('setCookie');
var makeString = require('makeString');
var log = require('logToConsole');

var SESSION_GUARD = data.SESSION_GUARD || '_arrewr';

// Run at most once per session
var guardValues = getCookieValues(SESSION_GUARD);
if (guardValues && guardValues.length > 0 && guardValues[0] === '1') {
  data.gtmOnSuccess();
  return;
}

var rootDomain = data.rootDomain;
var durationDays = data.durationDays;
var cookieList = data.cookieList;
var maxAgeSeconds = makeString(durationDays * 24 * 60 * 60);

if (cookieList && cookieList.length > 0) {
  for (var i = 0; i < cookieList.length; i++) {
    var name = cookieList[i].cookieName;
    if (!name) continue;
    var values = getCookieValues(name);
    if (values && values.length > 0 && values[0] !== '') {
      setCookie(name, values[0], {
        domain: rootDomain,
        path: '/',
        'max-age': maxAgeSeconds,
        samesite: 'Lax',
        secure: true
      });
    }
  }
}

// Stamp the session guard so this doesn't run again this session
setCookie(SESSION_GUARD, '1', { domain: rootDomain, path: '/' });
data.gtmOnSuccess();

Cookies Written by This Recipe

Cookie Name	Type	Purpose	Default Expiry
`_i_vstcnt`	Persistent	The actual session counter value (integer, increments each session)	720 days (refreshed each visit)
`_arusc`	Session	Guard cookie — prevents multiple increments within a single session	Browser close
`_arrewr`	Session	Guard cookie — prevents the Cookie Rewriter from running more than once per session	Browser close

Two types of guard cookies, two jobs: The session-scoped _arusc ensures the counter increments exactly once per browser session. The separate _arrewr guard ensures the Cookie Rewriter runs exactly once per session. Because both guards are session cookies (no max-age), they vanish naturally when the browser is closed — no cleanup needed.

Variables

Key Constants

Variable Name	Type	Value
User Session Counter Cookie Name	Constant	`_i_vstcnt`
Extend Cookie Life Already Ran Cookie Name	Constant	`_arrewr`
Measurement Stream ID Development	Constant	`G-ZZZZZZZZ` (replace with yours)
Measurement Stream ID Production	Constant	`G-AAAAAAAA` (replace with yours)

Key Cookie-Reading Variables

Variable Name	Type	Reads Cookie
User Session Counter Cookie Value	1st-party cookie	`_i_vstcnt` — the count, readable by any other GTM tag
Extend Cookie Life Already Ran Cookie Value	1st-party cookie	`_arrewr` — used by the Extend Cookie Life Trigger condition

Triggers

User Session Counter Tag

The User Session Counter tag fires on All Pages (or any early-firing trigger you choose). Its own internal session guard (_arusc) is the gatekeeper — the guard logic is inside the template rather than in an external trigger condition. This keeps the tag self-contained and avoids the need for a separate "has not already ran" initialization trigger.

Extend Cookie Life Trigger

Fires on DOM Ready , with one filter condition: {{Extend Cookie Life Already Ran Cookie Value}} matches the regex ^(undefined|null|0|false|NaN|)$. In plain English: fire only when the _arrewr cookie is absent or falsy. This ensures the Cookie Rewriter runs exactly once per session.

Dual-Purpose dataLayer Event

The push made by the User Session Counter template serves two roles simultaneously:

Cookie persistence: The counter value is stored in _i_vstcnt and survives across pages and sessions for up to 720 days.
Custom event trigger: The dataLayer.push({ event: '_i_vstcnt', userSessionCounter: N }) can be listened to by a GTM Custom Event trigger. Any tag that should react to session depth — a GA4 conversion event, a popup timer, a live-chat invite — can be wired to this trigger with a variable condition on userSessionCounter.

Example use case: Create a Custom Event trigger matching _i_vstcnt, add a trigger condition where {{User Session Counter Cookie Value}} equals 3, and wire it to a "show free trial popup" tag. The popup fires on the visitor's third session — and never on the first or second.

How to Import

Download the JSON from the Google Drive link.
In GTM, go to Admin → Import Container.
Upload user-session-counter-measurement-recipe.json.
Choose Merge (not Overwrite) to preserve your existing tags.
Update the Measurement Stream ID Development and Measurement Stream ID Production constant variables to your actual GA4 Stream IDs.
Update the Root Domain variable if your site uses a non-standard subdomain structure.
Preview in GTM Preview mode: open your site, check the Variables tab for User Session Counter Cookie Value, and verify it increments to 1 on first load.
Close the browser tab entirely, reopen the site in Preview mode, and verify the counter increments to 2.
Publish when satisfied.

Consent gating: The persistent _i_vstcnt counter cookie is a functional/analytics cookie. If your site uses a consent management platform, gate the User Session Counter tag on analytics_storage or functionality_storage consent as appropriate for your jurisdiction.

What You Can Do With It

Suppress first-session users from conversion funnels to reduce noise in paid-media ROAS reporting
Build GA4 audiences segmented by session depth: New (1 session), Returning (2–5), Loyal (6+)
Trigger a discount popup only on the third session, avoiding offer fatigue for first-time visitors
Read _i_vstcnt server-side (it's a first-party cookie) to personalise page content before GTM even fires
Use userSessionCounter as a GA4 event parameter to segment event reports by engagement depth
Fire a live-chat proactive invite only for visitors on session 4 or higher

The full source — including the container JSON, all custom template code, and a breakdown of every variable — is available on GitHub. Questions or improvements? Open an issue.

⬇ Download GTM Container JSON

GTM postMessage Bridge and Listener

Kent Spencer — Wed, 22 Jul 2026 19:22:54 +0000

postMessage Bridge for iframes in GTM — Sandboxed, Parameterized, and Client-ID Aware

Published · Tags: GTM, Google Analytics 4, postMessage, iframe, Cross-Domain Attribution, Client ID, Sandboxed JavaScript, CSP, Pardot, Lead Generation

Note: This GTM container recipe is designed to work on Google Blogger / Blogspot as well as AEM, Sitecore, WordPress, React.js, and other platforms. It bridges dataLayer events across an iframe boundary using window.postMessage(), implemented with GTM Sandboxed JavaScript Custom Templates rather than hand-rolled inline JavaScript wherever possible. The JSON can be downloaded from Google Drive below.
⬇ Download the GTM Container JSON from Google Drive

A third-party iframe embedded on your page — a Pardot form, a HubSpot form, a scheduling widget, a payment step — runs its own separate browsing context with its own GTM container and its own dataLayer. Nothing that happens inside that iframe is visible to the parent page's GTM container, and nothing the parent page knows is visible to the iframe. They are two completely isolated tag-management setups that happen to share a rectangle of screen space. If a visitor clicks "Submit" inside that embedded form, your parent-site GA4 property never hears about it unless something deliberately carries that event across the origin boundary.

window.postMessage() is the browser API built for exactly this: two windows in different origins exchanging plain-text messages, with each side choosing which origins it trusts. Simo Ahava published the original GTM implementation of this pattern years ago, and I'm using it successfully in a live Pardot implementation today:

▶ Video walkthrough · How Do I Use the postMessage Method With Cross-Site iframes? — Simo Ahava

His article remains the clearest explanation of the underlying mechanics — why evt.origin checking matters, what evt.source buys you, and why a sender/receiver pair of GTM tags is the right shape for the problem. If you haven't read it, start there.

Why I Built a Variant of This

Inspired by Simo's original and earlier work, I reworked the implementation with three goals:

Less reliance on Custom HTML / hand-written JavaScript. Nearly all of the sender and receiver logic now lives in GTM Sandboxed JavaScript Custom Templates instead of inline <script> tags.
More reliance on Sandboxed JavaScript. Template code executes inside GTM's own sandbox and is not subject to CSP script-src SHA-256 hashing — it's already covered by the www.googletagmanager.com allowance your site needs regardless.
Fully parameterized configuration. Target origin, namespace, event allow/exclude lists, the iframe's element ID, and the wrap key are all template fields — not literal values buried in a script body. Porting the recipe to a new site or a new iframe means editing template fields, not rewriting JavaScript.

Decreasing reliance on Custom HTML shrinks — but does not eliminate — the CSP SHA-256 surface. Two small Custom HTML tags remain, one on each side: a Sender Bootstrap on the child/iframe site that performs the actual window.top.postMessage() call, and a Bootstrap Listener on the parent site that registers the single window.addEventListener('message', …) handler. Both exist only because sandboxed JavaScript's access_globals permission cannot reach predefined browser globals like top, window, or parent directly — a Custom Template is not allowed to call window.top.postMessage() itself. Both scripts' literal text is fixed and configuration-free — they read everything they need from plain globals written by their companion Custom Template — so you compute each SHA-256 hash once and it stays valid indefinitely, no matter how many times you reconfigure origins, namespaces, or allow-lists.

Passing the Client ID

This recipe also carries the parent page's GA4 client_id into the iframe, via the _ga query-string parameter on the iframe's src. This uses the URL-decoration mechanism from an earlier recipe of mine (linked below) — the same permitted-host, same-config-object approach, just aimed at an <iframe src> instead of an outbound <a href>.

Passing the client ID is principally for use with the GTM configuration settings inside the iframe's own GTM container. Reading that value back out on the child side gives the child site's GA4 config tag the option to use the parent's client_id instead of generating its own — which gives the receiving property the opportunity to associate the iframe's traffic with the same pseudo_user_id as the parent site. It is not the same session, and it is not full cross-domain session stitching — but it is enough to connect the embedded-content activity back to the same underlying visitor identity, where the receiving side chooses to use it.

Parent Site vs. Child Site — One Download, Two Destinations

Everything in this export is labeled either Parent Site or Child Site. Elements marked Parent Site belong in the GTM container installed on the page that hosts the <iframe>. Elements marked Child Site — along with the shared Google Tag configuration settings that set client_id from the URL query string — belong in the GTM container installed inside the iframe's own page.

I've put both halves into a single container JSON purely for convenience of downloading and importing in one pass. To actually run both halves inside one shared container (rather than importing into two separate containers), do two things:

Add a hostname condition to the Parent Site triggers so they fire only when {{Page Hostname}} equals your parent site's host.
Add a hostname condition to the Child Site triggers so they fire only when {{Page Hostname}} equals your child/iframe site's host.

Without one of those two approaches, the Parent-Site and Child-Site logic will both attempt to evaluate on every page load in whichever container you import them into — which is harmless (the sender finds no matching dataLayer events on a page with no iframe events firing, and vice versa) but wasteful and confusing to debug in GTM Preview mode.

What's Inside the Container

The exported container (gtm-postmessage-bridge-listener.json) is organized into five folders, twelve tags, six triggers, and fourteen variables. Two Sandboxed JavaScript Custom Templates — postMessage Bridge - Sender Configuration and postMessage Bridge - Receiver — do the real work, supported by two small Custom HTML bootstrap tags and the UTM/URL-decoration components carried over from earlier recipes.

Folders

Folder	Side	Contains
`postMessage Bridge Sender`	Child Site	The Sender Configuration template tag, the Sender Bootstrap Custom HTML tag, the diagnostic tag, the all-events custom trigger, the required (unattached) Click trigger, and the referral-host constant.
`UTM & URL Processing`	Child Site	Writes UTM query-string values to session cookies on the child page, plus the `_ga` query-string reader/validator that feeds the GA4 config tag's `client_id` override.
`Analytics`	Shared	GA4 initialization tag, Browser Client ID variable, Measurement Stream ID constant, and the Google Tag Shared Configuration Settings variable used by the child-site GA4 config tag.
`postMessage Bridge Receiver`	Parent Site	The Receiver template tag, the Bootstrap Listener Custom HTML tag, the diagnostic tag, the Initialization trigger, and the custom event trigger that catches the bridged `iframe.gtm.click` event.
`UTM & URL Processing`	Parent Site	The URL Decoration Config, its "set global" tag, the DOM listener/scanner tag, the target-host constant, the UTM cookie-pair reader, and the trigger pair that decorates the iframe's `src` with UTM values and the GA4 `client_id`.

Tags

Tag	Side	Fires On	Purpose
`postMessage Bridge - Sender Configuration`	Child	Custom Event — regex `.*` (all events)	Scans new `dataLayer` entries since it last ran, drops anything in `excludeEvents` (defaults to `gtm.js, gtm.dom, gtm.load`), keeps only events in `eventAllowlist` (`gtm.click` as exported), wraps each surviving event under the `namespace` key, and stages the result on `window. __gtmPmOutbox` / `window.__ gtmPmTargetOrigin`. A per-target cursor in template storage stops it from re-sending events it already staged.
`postMessage Bridge - Sender Bootstrap`	Child	Same trigger, sequenced to run immediately after Sender Configuration (set as its setup tag)	The one piece of unavoidable Custom HTML on this side. Reads `window. __gtmPmOutbox` and `window.__ gtmPmTargetOrigin` and calls `window.top.postMessage(JSON.stringify(item), origin)` for each staged item, because sandboxed JS cannot reach `window.top` directly.
`Diagnostic - Is postMessage Alive`	Child	Same trigger	Off by default. Note in the tag: "diagnostic tag. turn it on to see in the dataLayer if the postMessage processing is alive." Logs outbox contents, target origin, and whether the page is actually running inside an iframe.
`Write UTMs to session cookies`	Child	Initialization	Same UTM-cookie template used in the earlier URL-decoration recipe, scoped to `{{Page Hostname}}`, session-duration by default.
`Google Analytics Initialization`	Shared	Initialization	Standard GA4 config tag, routed to `{{Measurement Stream ID}}` with the Shared Configuration Settings variable applied (see below).
`postMessage Bridge - Receiver`	Parent	Initialization	Writes `window.__gtmPmConfig` (allowed origins + iframe element ID) and defines `window.__gtmPmReceiver()`, which validates the origin and namespace prefix, de-duplicates an exact repeat of the previous payload, and pushes the unwrapped event to the parent's `dataLayer`. Note on this tag: "note the importance of correctly coding the `https://{{postMessage Target Host}}`, the tag element you are tracking - iframe, and the kinds of events you want to receive from the iframe - the gtm.click events. these must all be correct for the solution to work."
`postMessage Bridge - Bootstrap Listener`	Parent	Initialization, sequenced after Receiver	The parent-side Custom HTML counterpart. Registers a single `window.addEventListener('message', …)` handler that checks the message's origin against `__gtmPmConfig.allowedOrigins`, optionally confirms `evt.source` matches the specific iframe element's `contentWindow`, and hands off to `window.__ gtmPmReceiver()`.
`Diagnostic - Is postMessage Alive`	Parent	All Pages	Off by default. Note in the tag: "diagnostic tag. turn it on to see in the dataLayer if the postMessage processing is alive." Logs every raw incoming message, polls for the receiver config/function to appear, and watches `dataLayer.push` for anything landing with an `iframe.`-prefixed event name.
`Set URL Decoration Config Global`	Parent	Setup tag only	Writes `{{URL Decoration Config}}` to `window.gtmUrlDecoratorConfig` before the listener below runs. Carried over from the URL-decoration recipe.
`URL Decoration Listener`	Parent	DOM Ready	Scans the DOM for elements (including `<iframe src>`) pointing at a permitted host and, if found, pushes `urlDecorationTargetFound` to the dataLayer. This is what makes the iframe's `src` a decoration target in the first place — it must find your iframe on the page.

The Decorate Target URLs tag and the Populate form … EXAMPLE tags are also present as reused/example scaffolding: the former is the same tag documented in the URL-decoration recipe (it appends the UTM cookie pairs and the GA4 client_id pair onto the iframe's src); the latter is a paused, illustrative Custom HTML tag on both sides showing one way a downstream form could read the passed-through _ga/utm_campaign cookie values into hidden fields. Neither needs to be enabled for the bridge itself to work.

Triggers

Trigger	Side	Type	Notes
`postMessage Bridge - Custom Event - All Events (regex .*)`	Child	Custom Event, `{{_event}}` matches RegEx `.*`	Deliberately unfiltered at the trigger level. Filtering by event name (the exclude list and the allow-list) happens inside the Sender Configuration template instead, so you never have to edit a trigger's regex to change which events get bridged — you edit a tag field.
`Click - Necessary to Create dataLayer gtm.click`	Child	Click (unattached to any tag)	Note in the trigger: "if you are sending gtm.click from the iframe to the parent site, you must have at least the trigger for gtm.click in the iframe container - even if it is not attached to a tag. the absence of the trigger means the absence of the gtm.click event in the dataLayer and resultingly no iframe.gtm.click will be sent by postMessage." GTM only pushes `gtm.click` into the dataLayer at all when at least one Click trigger exists in the container — this trigger exists purely to satisfy that requirement.
`DOM Ready - All Pages`	Parent	DOM Ready	As exported, unconditional — fires on every parent page. Change this — see below.
`Click from iframe - iframe.gtm.click`	Parent	Custom Event, `{{_event}}` equals `iframe.gtm.click`	Note in the trigger: "the custom event sent by postMessage from the iframe. note that the components tie back to the 'iframe' and 'gtm.click' configuration parameters in the child / iframe. you now have the full payload of the iframe gtm.click in the parent dataLayer. this can be altered for anything captured in the child / iframe based on the event_name in the child / iframe dataLayer." This is the hook point for any downstream parent-side GA4 event tag you want to fire off the bridged click.
`URL decoration target found`	Parent	Custom Event, equals `urlDecorationTargetFound`	Fires the decorator tag only once the DOM scan has actually found a qualifying element on the current page.
`Window Loaded`	Shared	Window Loaded	Utility trigger present from the Analytics folder scaffolding; not wired to a tag in this export.

Key Variables

Variable	Side	Role & Notes
`Referral Host - iframe Parent Site`	Child	Constant, default `drewspen.blogspot.com`. Note: "enter the host name of the parent / referral site here." Feeds the Sender Configuration tag's `targetOrigin` field as `https://{{this}}`.
`postMessage Target Host`	Parent	Constant, default `postmessage-drewspen.blogspot.com`. Note: "the host name of the iframe source. note that not only this must match, but the iframe id must also be configured correctly to match in the tag configuration." Feeds the Receiver tag's `allowedOrigins` field and the URL Decoration Config's `permittedHosts` list.
`Obtain _ga client id from URL query string`	Child	Reads the `_ga` query-string parameter off the child page's own URL. Its format-value fallback substitutes `{{Browser Client ID}}` when the parameter is missing.
`URL Query String _ga Fix`	Child	Note: "necessary so that if the _ga value is blank or empty it is converted to a true undefined. a blank or empty will be used to 'erase' the client_id. an undefined will allow for GA to generate a value." A Regex Table validates the resolved value against the GA4 client-ID shape (`NNNNNNNNNN.NNNNNNNNNN`) before it's trusted; anything malformed falls through to undefined.
`Google Tag Shared Configuration Settings`	Child	Sets the GA4 config tag's `client_id` parameter to `{{URL Query String _ga Fix}}`, `send_page_view` to `false`, and `debug_mode` to the Preview-only wrapper variable. This is the actual mechanism that lets the child iframe's GA4 hits carry the parent's client ID.
`Root Domain` / `Root Domain - old`	Shared	Note: "Root domain of .blogspot.com did not work for Google Blogger. I did not want to do .blogger.com, so changed to page URL host name." Same Blogger-specific decision documented in the earlier UTM/URL-decoration recipes — cookies are scoped to `{{Page Hostname}}`, not a computed eTLD+1.
`Debug Mode (Preview Only)`	Shared	Note: "Wraps the built-in {{Debug Mode}} variable so the debug_mode config parameter is OMITTED (undefined) on normal traffic rather than explicitly sent. Some GA4/gtag implementations key off the parameter's mere presence, not its value, and omitting it avoids sending a needless param on every hit."

How the Full Round Trip Works

Outbound (parent → child) and inbound (child → parent) run independently, but together they form a loop:

1. Outbound: decorating the iframe's `src` (Parent Site)

This reuses the URL-decoration recipe wholesale, aimed at the iframe element instead of an outbound link. On DOM Ready, the listener scans the page; if it finds an <iframe> whose src host matches {{postMessage Target Host}}, it fires the decorator, which appends the parent's UTM cookie values and its GA4 client_id (as _ga) onto the iframe's src before — or as — it loads.

2. Child side picks up the client ID

The child page's own GA4 config tag reads that _ga query parameter (with the validation and fallback described above) and uses it as its own client_id, instead of letting gtag.js generate a fresh one. The two properties now share a client_id, and by extension a pseudo_user_id — though not a session.

3. Sender: staging events inside the iframe

The postMessage Bridge - Custom Event - All Events trigger fires the Sender Configuration tag on every dataLayer push. It walks any dataLayer entries it hasn't seen yet, drops gtm.js/gtm.dom/gtm.load, keeps only gtm.click (as configured), tags each surviving event with the page URL and title, and stages the wrapped result — plus the target origin — on plain window globals. Its setup tag, Sender Bootstrap, runs immediately after and does the one thing the sandbox can't: window.top.postMessage(JSON.stringify(item), 'https://drewspen.blogspot.com').

4. Receiver: unwrapping events on the parent

At Initialization — before most other tags — the Receiver tag writes window.__gtmPmConfig (the allowed origins and the tracked iframe's element ID) and defines window.__gtmPmReceiver(). Its setup tag, Bootstrap Listener, registers the single message event listener for the whole page. When a message arrives, the listener confirms the origin is allowed and, if an iframe element ID is configured, that evt.source really is that specific iframe's contentWindow — then calls the receiver function, which checks the origin again, confirms the event name starts with the configured namespace, drops an exact repeat of the previous payload, and pushes the unwrapped event (iframe.gtm.click, wrapped under postMessageData) into the parent's own dataLayer.

5. Downstream on the parent

The Click from iframe - iframe.gtm.click Custom Event trigger is now listening for exactly that event name. Attach any GA4 event tag (or additional trigger conditions on the bridged payload's fields) to that trigger to turn "someone clicked inside the embedded form" into a first-class parent-site GA4 event.

What You Need to Change Before Using This

Change this — Host names

Two Constant variables carry the placeholder host names in this export: Referral Host - iframe Parent Site (Child, default drewspen.blogspot.com) must be the real host of the page that will embed your iframe. postMessage Target Host (Parent, default postmessage-drewspen.blogspot.com) must be the real host the iframe's src points at. Both origin checks are exact, case-insensitive hostname comparisons — no wildcards, no path matching.

Change this — The tracked iframe element

The Receiver tag's iframeElementId field ships as iframe-form-tracking. This must exactly match the id attribute on the actual <iframe> element in your parent page's HTML — if it doesn't, the receiver's evt.source check will silently reject every message. Leave it blank only if you're comfortable accepting messages from any frame at the allowed origin, regardless of which element it came from.

Change this — Which events get bridged

The Sender Configuration tag's eventAllowlist ships as gtm.click only. Add other dataLayer event names (comma-separated) if you also want to bridge, for example, a custom form_submit event the child container pushes. The Receiver's own eventAllowlist field is a second, independent gate on the parent side — both allow-lists have to agree for an event to land in the parent's dataLayer.

Change this — Trigger scoping (fire only where your iframe actually is)

As exported, DOM Ready - All Pages (Parent) has no conditions and fires on every page, and the Child-side Custom Event - All Events trigger is unconditional inside whatever container it's imported into. Neither is a correctness problem by itself — the decorator only acts when the DOM scan finds something, and the sender only stages events that match its allow-list — but both are worth tightening. On the parent, add a Page Path or Page URL condition to DOM Ready - All Pages so the DOM scan only runs on the specific template(s) that actually embed your tracked iframe. On the child, if you're running a shared container per the two-hostname approach described above, add the child hostname condition to the same trigger. Scope both sides to the pages where your target iframes are actually found, rather than letting either side evaluate everywhere.

Built On Two Earlier Recipes

Part of this solution reuses components from two earlier posts on this blog, unchanged in mechanism:

GTM URL Decoration to Transfer Attribution — the permitted-hosts, config-global, DOM-scan-then-decorate pattern used here to decorate the iframe's src.
UTM & URL Query String 2 Cookies — the session-cookie writer that keeps UTM values available on the parent page beyond the original landing page, so they're still there to decorate the iframe with on a later page view.

Diagnostics

Both sides ship a paused Diagnostic - Is postMessage Alive tag. Enable the child-side one to confirm the outbox is being staged and the target origin is set correctly; enable the parent-side one to confirm the listener is registered, watch every raw incoming message (regardless of origin), and see bridged events land in the dataLayer in real time. Turn both back off before publishing — they're verbose console.log tags meant for GTM Preview mode only.

How to Import

Download the JSON from the Google Drive link above.
In GTM, go to Admin → Import Container.
Upload gtm-postmessage-bridge-listener.json.
Choose Merge (not Overwrite) to preserve your existing container setup, and pick a target Workspace.
If importing into two separate containers (recommended): import the whole file into both, then delete the Parent Site-labeled items from the child container and the Child Site-labeled items from the parent container.
If importing into one shared container: keep everything, but add the hostname trigger conditions described in "Parent Site vs. Child Site" above.
Update Referral Host - iframe Parent Site and postMessage Target Host with your real hostnames.
Update the Receiver tag's iframeElementId to match your actual <iframe id="…">.
Update Measurement Stream ID with your real GA4 Measurement ID on both sides.
Scope the DOM Ready - All Pages trigger (and, if applicable, the child-side custom event trigger) to the pages that actually contain your tracked iframe.
Confirm consent settings — the Sender Configuration and Sender Bootstrap tags require functionality_storage as exported; adjust to match your CMP setup.
Open GTM Preview mode on both the parent page and the child/iframe page. Turn on both diagnostic tags temporarily. Click something inside the iframe and confirm: gtm.click fires in the child dataLayer → the outbox stages an item → postMessage fires → the parent's listener receives it → iframe.gtm.click lands in the parent dataLayer.
Turn the diagnostic tags back off and publish.

The full source — container JSON and documentation — is also published on GitHub. If you extend the recipe (additional bridged event types, a different namespace per iframe, or support for more than one tracked iframe on the same parent page), open a pull request or issue.

⬇ Download GTM Container JSON

GTM e-Commerce Implementation GA4 and Meta

Kent Spencer — Sat, 18 Jul 2026 11:44:28 +0000

GA4 Ecommerce to Meta Pixel & Conversions API Bridge in GTM — Standard Events From a Standard DataLayer

Published · Tags: GTM, GA4, Ecommerce, Meta Pixel, Conversions API, dataLayer, Custom Event Trigger, Standard Events, Advanced Matching

Note: This solution utilizes the standard GTM/GA4 ecommerce data model — the ecommerce object and items[] array documented in Google's GA4 ecommerce specification. Because the dataLayer strictly adheres to that spec, the same ecommerce payload is reused, unmodified, to power both the GA4 event tag and the Meta Pixel / Conversions API tag. The JSON container can be downloaded from Google Drive below.

Sending ecommerce events to GA4 is only half the job on most sites — Meta (Facebook/Instagram) Ads also needs standard events like ViewContent, AddToCart, and Purchase to build audiences and measure ROAS. The naive approach is to hand-build a second dataLayer, or a second set of GTM tags with their own hard-coded parameter mapping for every event, every time a new one is added to the site.

This recipe avoids that duplication entirely. A single set of GTM variables translates whatever event name the site's dataLayer emits — whether it's a textbook GA4 name like add_to_cart or a platform-flavored synonym like product_added_to_cart — down to the canonical GA4 event name, and then across again to the matching Meta standard event name. Both the GA4 tag and the Meta tag read the same ecommerce object off the dataLayer. No parameter is mapped twice.

⬇ Download the GTM Container JSON from Google Drive

What's Inside the Container

The exported container (gtm-ecommerce-meta-measurement.json) is organised into three folders, three tags, three triggers, and a set of variables covering event-name translation, environment/stream routing, and shared GA4 configuration and event settings. One community Custom Template — the Meta Pixel & Conversions API tag from Meta's own GTM Gallery listing — powers both Meta tags.

Folders

Folder	Contains
Analytics	Environment/stream routing variables (`Measurement Stream RegEx Lookup`), Browser Client ID, Google Tag shared configuration and event settings variables.
e-Commerce	The `e-Commerce Send Events` GA4 event tag, its firing trigger, and the `e-Commerce Event Name Translator` lookup variable.
Meta	The `Meta e-Commerce Standard Event` and `Meta Pageview` tags, their triggers, the `Meta Standard Event Name Translator`, the production-traffic gate, and the Meta Pixel ID constant.

Tags

Tag	Type	Fires On	Purpose
`e-Commerce Send Events`	GA4 Event (`gaawe`)	e-Commerce Events	Sends every recognized ecommerce dataLayer event to GA4. Event name comes from the e-Commerce Event Name Translator; ecommerce data is read directly from the dataLayer; the measurement ID is resolved per-environment; shared event settings are appended.
`Meta e-Commerce Standard Event`	Meta Pixel & CAPI (Custom Template)	Meta Standard e-Commerce Event	Sends the equivalent Meta standard event (ViewContent, AddToCart, Purchase, etc.) using the same GA4-shaped ecommerce object (`useGA4Ecommerce: true`), with Advanced Matching and server-side Conversions API forwarding enabled.
`Meta Pageview`	Meta Pixel & CAPI (Custom Template)	Meta DOM Ready	Fires the standard Meta `PageView` event once per page, gated to production traffic only, with the same Advanced Matching parameters as the ecommerce tag.

Triggers

Trigger	Type	Conditions
`e-Commerce Events`	Custom Event	Event name matches any recognized ecommerce event pattern (GA4-standard and common platform synonyms) AND the e-Commerce Event Name Translator output is non-empty. Fires the GA4 tag on every environment.
`Meta Standard e-Commerce Event`	Custom Event	Same event-name pattern as above AND the Meta Standard Event Name Translator resolves to a real Meta event name AND `is Production Traffic` equals `true`. This is the key gate: GA4 receives events from every environment, but Meta only ever receives production traffic.
`Meta DOM Ready`	DOM Ready	`is Production Traffic` equals `true`. Fires the Meta base pixel / PageView once the DOM is ready, on production only.

The GA4 Ecommerce Data Model

Everything in this recipe hinges on the site's dataLayer following Google's standard GA4 ecommerce schema. Each ecommerce event pushes a top-level event name plus an ecommerce object. Item-level detail always lives in an items array, and event-level detail (currency, value, transaction ID, etc.) lives alongside it:

// Reset the ecommerce object first — see note below
dataLayer.push({ ecommerce: null });

dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "USD",
    value: 59.98,
    items: [
      {
        item_id: "SKU_12345",
        item_name: "Classic Denim Jacket",
        item_brand: "Acme Apparel",
        item_category: "Outerwear",
        item_variant: "Indigo / Medium",
        price: 29.99,
        quantity: 2,
        index: 0
      }
    ]
  }
});

Key parts of the model that this recipe depends on:

items[]: one object per product line, carrying identity (item_id, item_name), classification (item_category, item_brand, item_variant), and transaction detail (price, quantity, discount, coupon, index).
Event-level fields: currency and value appear on every commerce event; purchase additionally carries transaction_id, tax, and shipping; view_item_list and select_item carry item_list_id / item_list_name.
Standard event names: view_item_list, select_item, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund.
The ecommerce: null reset: GTM's dataLayer merges new pushes into previous state rather than replacing it. Without clearing ecommerce before every push, stale items from a prior event can leak into the next one. This reset is standard GA4 implementation guidance and is assumed by every tag in this container.

Because the GA4 tag's getEcommerceDataFrom parameter is set to dataLayer, and the Meta tag's useGA4Ecommerce parameter is enabled, both tags parse this exact same object. No product data is manually re-mapped for Meta — it is passed straight through and reshaped internally by the Meta template into Pixel/CAPI's own content_ids / contents format.

Event Name Translation: One DataLayer, Two Vocabularies

Sites rarely emit ecommerce events under a single naming convention. This container's trigger matches both the canonical GA4 names and common alternate naming conventions seen in Shopify, Segment-style, and headless-commerce integrations, then normalizes everything through two chained Simple Lookup Table variables.

Step 1 — `e-Commerce Event Name Translator` (site event name → canonical GA4 name)

Incoming dataLayer Event	Canonical GA4 Event
`product_viewed` / `item_viewed`	`view_item`
`cart_viewed`	`view_cart`
`product_added_to_cart`	`add_to_cart`
`checkout_progress` / `checkout_contact_info_submitted` / `set_checkout_option`	`begin_checkout`
`checkout_address_info_submitted`	`add_shipping_info`
`payment_info_submitted`	`add_payment_info`
`checkout_completed`	`purchase`
Anything else (e.g. already-standard names like `view_item`, `purchase`)	Passed through unchanged (default value = `{{Event}}`)

Step 2 — `Meta Standard Event Name Translator` (canonical GA4 name → Meta standard event)

Canonical GA4 Event	Meta Standard Event
`view_item` / `select_content`	`ViewContent`
`add_to_cart`	`AddToCart`
`begin_checkout`	`InitiateCheckout`
`add_payment_info`	`AddPaymentInfo`
`purchase`	`Purchase`
`generate_lead`	`Lead`
`add_to_wishlist`	`AddToWishlist`
Anything else	No default value — the Meta trigger's regex condition requires a non-empty result, so unmapped events simply never fire the Meta tag.

Chaining the two lookups this way means a new GA4-standard event only has to be added once, to the second table, to also start reaching Meta — the first table only exists to normalize non-standard names down to something the second table already understands.

Meta Advanced Matching & the Production Traffic Gate

Both Meta tags enable Advanced Matching , passing an external_id parameter populated from the same Browser Client ID variable used for GA4's client_id. This gives Meta a stable, first-party identifier to match against without relying solely on third-party cookies, and keeps the identity signal consistent across both platforms.

Both Meta tags also declare consent: true and require ad_storage, ad_user_data, ad_personalization, and analytics_storage — so they respect whatever Consent Mode signals are set on the page before firing, in addition to the optInMetaCAPI and dpoLDU (Limited Data Use) template parameters, which govern server-side Conversions API forwarding and Limited Data Use flagging respectively.

The is Production Traffic variable resolves to true only when Measurement Stream RegEx Lookup resolves to the production GA4 Measurement ID — meaning Meta's tags are gated behind the same environment detection already used for GA4 stream routing. The net effect: GA4 sees events from every environment (dev, staging, production) routed to the correct property, while Meta only ever receives production traffic, keeping ad-platform audiences and CAPI events clean.

Environment-Aware Stream Routing

Like other recipes in this series, the container automatically routes GA4 hits to the correct property:

Measurement Stream RegEx Lookup checks {{Page URL}}. Non-production hostname patterns (dev, uat, qa, stg/staging, int, local, admin, aem, the GTM preview/render endpoints) resolve to Measurement Stream ID Development (placeholder: G-ZZZZZZZZZZ).
Everything else falls through to Measurement Stream ID Production (placeholder: G-AAAAAAAAAA).

Update the two Constant variables with your real GA4 Measurement IDs before publishing, and update Meta Tracking ID (placeholder: 1000000000000000) with your real Meta Pixel ID.

Shared Configuration & Event Settings

Two Google Tag configuration variables keep GA4 settings DRY across the container rather than repeating parameters on every tag:

Variable	Applies	Value
`Google Tag Shared Configuration Settings`	`debug_mode`	`Debug Mode (Preview Only)` — only sets `true` while inside GTM Preview mode.
`Google Tag Shared Configuration Settings`	`send_page_view`	`false` — pageviews are handled deliberately elsewhere rather than automatically on config load.
`Google Tag Shared Event Settings`	`e_client_id` (event param), `u_client_id` (user property)	`Browser Client ID Append Underscore`
`Google Tag Shared Event Settings`	`page_title` (event param)	`Page Title` (`document.title`)

Community Custom Templates Used

Template	Source	Purpose
Meta Pixel & Conversions API	facebook / GTM Gallery	Powers both Meta tags — client-side Pixel firing plus optional server-side Conversions API forwarding, standard event mapping, and Advanced Matching parameters.
If Else If — Advanced Lookup Table	sublimetrix	Imported alongside the Meta template as a general-purpose multi-condition lookup utility. Not actively wired into a live tag in this export, but available for future branching logic (e.g. country/state-conditional Data Processing Options).

Project context: This solution was originally developed as part of an employment evaluation project. Building it end-to-end was a useful demonstration of just how streamlined the GTM tag configuration becomes once the dataLayer strictly adheres to the standard GA4 ecommerce specification — one ecommerce object, one items[] schema, reused without modification by every downstream destination tag.

How to Import

Download the JSON from the Google Drive link above.
In GTM, go to Admin → Import Container.
Upload gtm-ecommerce-meta-measurement.json.
Choose Merge (not Overwrite) to preserve your existing container setup.
Update the Measurement Stream ID Production and Measurement Stream ID Development Constant variables with your real GA4 Measurement IDs.
Update Meta Tracking ID with your real Meta Pixel ID.
Confirm the Meta template is authorized to communicate with the Meta Pixel/CAPI endpoint domains, and, if using server-side forwarding, add your Meta Conversions API access token via the template's CAPI configuration fields.
Verify consent settings on both Meta tags (ad_storage, ad_user_data, ad_personalization, analytics_storage) match your CMP's consent categories.
Confirm your site's dataLayer pushes follow the standard GA4 ecommerce schema — ecommerce: null reset, then event + ecommerce.items[] — for every ecommerce interaction.
Open GTM Preview mode and trigger an ecommerce event (e.g. add to cart). Confirm e-Commerce Send Events fires with the translated event name and the expected items payload.
On a production hostname, confirm Meta e-Commerce Standard Event and Meta Pageview also fire, and verify the events appear in Meta Events Manager (both Pixel and, if enabled, server-side CAPI).
On a dev/staging hostname, confirm GA4 still receives events (routed to the development property) while the Meta tags do not fire — this confirms the production traffic gate is working.

The full source — container JSON and documentation — is also published on GitHub. If you add support for additional GA4 ecommerce events or additional Meta standard events, extend the two lookup tables rather than adding new tags — that's the entire point of the chained-translator pattern.

⬇ Download GTM Container JSON

Microsoft Clarity GTM Integration

Kent Spencer — Thu, 16 Jul 2026 20:33:56 +0000

Microsoft Clarity via GTM — Free Behavioral Analytics That Sits Right Next to GA4

Install Microsoft Clarity through Google Tag Manager in minutes, chain it cleanly off your existing GA4 event tags using Markus Baersch's clarity-events template, and get heatmaps, session recordings, and JavaScript error tracking for the cost of zero dollars.

Published · Tags: GTM, Google Analytics 4, Microsoft Clarity, Heatmaps, Session Recordings, Tag Sequencing, Custom Templates, dataLayer, Free Analytics

Note: This GTM container recipe installs Microsoft Clarity's official Sandboxed JavaScript template alongside a standard GA4 setup, then uses tag sequencing ("fire after") to relay selected GA4 events into Clarity as custom events via the community _clarity-events_template. The container works on Google Blogger / Blogspot as well as AEM, Sitecore, WordPress, React.js, and other platforms. The JSON can be downloaded from Google Drive below.

Google Analytics tells you what happened — sessions, conversions, traffic sources. It does not show you why. Why did users abandon the checkout form? Why does that CTA button get almost no clicks even though it sits above the fold? Why is the bounce rate on one landing page twice as high as a nearly identical one? Those questions need eyes on the page, not just numbers in a report — and that is exactly the gap Microsoft Clarity fills.

This recipe is built around three simple facts: Clarity is free, it drops into a GTM container with one official Custom Template, and once it's in, you can pipe your existing GA4 event data into it with almost no extra work using a community template built specifically for this purpose.

⬇ Download the GTM Container JSON from Google Drive
Incidental code in this container: This export is a Clarity recipe first, but two of its tags — the CookieYes consent-interaction event and the session-duration milestone event — belong to their own complete, previously-published recipes, included here only to illustrate a realistic container. For the full build-out of each, seeCCPA-Style CookieYes Consent Implementation in GTMandSession Duration Timer in GTM.

1. Clarity Is Free — the Same Way GA Is Free

Microsoft Clarity carries no paid tier. There is no traffic cap, no session-recording quota, no feature gate that suddenly asks for a credit card once your site gets popular. Heatmaps, unlimited session recordings, funnels, filters, and the Copilot AI insights layer are all included from the moment you create a project — the same "free at any scale" model that makes GA4 the default choice for web analytics. Sign-in only requires a Microsoft, Google, or Facebook account, and no billing details are collected anywhere in the setup flow.

That matters for the same reason GA4's pricing model matters: it removes the cost conversation entirely. Adding Clarity next to GA4 isn't a budget decision or a tooling trade-off — it's just a checkbox.

2. Clarity Integrates Easily Through GTM

Microsoft publishes an official Community Gallery template — Microsoft Clarity - Official — that handles the entire base install. It's a Sandboxed JavaScript Custom Template, so like the other recipes on this blog, it does not inject inline<script> content and does not require a CSP SHA-256 hash beyond what your existing googletagmanager.com / www.clarity.ms allow-listing already covers.

The template takes a single required field — your Clarity Project ID — plus an optional group of custom-identifier fields (User Id, Session Id, Page Id, Friendly Name) that let you stitch a Clarity session to a known user, and a simple key/value table for custom tags you can filter recordings and heatmaps by later.

In this container, the base tag is configured like this:

Field	Value	Purpose
`projectId`	`{{Microsoft Clarity Project ID}}`	Your Clarity project, stored as a Constant variable so it's easy to swap per environment.
`userId`	`{{Browser Client ID}}`	Reuses the same GA4 client ID already resolved elsewhere in the container, so a Clarity session and a GA4 client ID point at the same visitor.
`sessionId`	`{{Browser Session ID}}`	Aligns the Clarity session identifier with the GA4 session ID for cross-tool debugging.

The base Microsoft Clarity tag itself carries no firing trigger of its own — it's set up as a teardown tag on the Google Analytics Configuration tag (the standard GA4 Google Tag) with "stop teardown on failure" enabled. In plain terms: Clarity loads immediately after the GA4 config tag succeeds, on every page, with no duplicated trigger to maintain and no risk of Clarity firing before consent or configuration settings have been resolved.

3. Sending Additional Events to Clarity with Markus Baersch's Template

The base install gets you heatmaps and recordings for free, but the real value comes from telling Clarity about the events you already care about in GA4 — a CMP interaction, a completed form, a session-duration milestone. Rather than hand-write separate event logic for Clarity, this recipe uses Markus Baersch'sclarity-events Community Template (Custom Template ID cvt_WV8T5), which wraps Clarity's clarity('event', ...), clarity('set', ...), and related JS-API calls in a simple GTM tag with fields for event name, custom tags, session upgrade, and consent state — no Custom HTML and no direct calls to the globalclarity() queue required.

The interesting part is how these tags fire. Rather than duplicating the trigger already attached to each GA4 Event tag, this container uses GTM's built-in tag sequencing to chain the Clarity event tag as a teardown of the corresponding GA4 event tag:

GA4 Event Tag (fires first)	Teardown → Clarity Event Tag	Clarity Event Name	Full Recipe
`CookieYes Interaction Send Event`	`Microsoft Clarity CookieYes Interaction`	`cmp_click`	CookieYes Consent Implementation in GTM
`Session Duration Send Event`	`Microsoft Clarity Session Duration`	`session_duration_{n}sec`	Session Duration Timer in GTM

This is what the "clean up" part of the chaining buys you: the Clarity event tag has_no firing trigger of its own_. It exists purely as a teardown, wired directly to the GA4 event tag whose data it mirrors. There is exactly one place — the GA4 tag's trigger — that decides when the pair fires. Change the trigger, adjust a filter, or retire the event entirely, and there's only one tag to touch. Nothing can drift out of sync between the two tags because there is only one source of truth for "when."

GA4 Event Tag: CookieYes Interaction Send Event
  Trigger: CookieYes Click Interaction
  Teardown → Microsoft Clarity CookieYes Interaction
                   (stop teardown on failure: true)

GA4 Event Tag: Session Duration Send Event
  Trigger: Session Duration Event
  Teardown → Microsoft Clarity Session Duration
                   (stop teardown on failure: true)

"Stop teardown on failure" means if the GA4 tag itself fails (blocked by consent, network error, and so on), the Clarity event never fires either — which keeps the two platforms honest about what actually happened on the page.

This isn't the only valid pattern. Teardown chaining is a convenience, not a requirement. You could just as easily give the Clarity event tag the _identical trigger_already attached to the GA4 event tag (CookieYes Click Interaction orSession Duration Event in this container) and let both tags fire independently off the same condition. The trade-off is duplication: two tags now reference the same trigger, so a future change to firing logic has to be applied twice. Teardown chaining trades that duplication for a small ordering dependency (the Clarity tag always fires slightly after the GA4 tag). Either approach gets the event into both tools — pick whichever fits how your team likes to maintain triggers.

4. What Clarity Adds on Top of GA4

Once the events are flowing, Clarity isn't a duplicate of GA4 — it's a different lens on the same visitors. Where GA4 aggregates events into counts and funnels, Clarity shows you the page itself:

Heatmaps — click, scroll, and area maps generated automatically for every page, no configuration or tagging required, showing exactly where attention concentrates and where it drops off.
Session recordings — DOM-based (not video) replays of real visits: every click, scroll, and mouse movement, playable back at variable speed and filterable by the custom events this container sends.
JavaScript error tracking — Clarity logs JS errors automatically and lets you jump straight to the session recording at the exact timestamp the error occurred, which turns "something broke for some users" into a five-minute investigation.
Rage clicks, dead clicks & quick backs — automatic detection of frustrated repeated clicking, clicks on non-interactive elements, and users who land on a page and immediately bounce back — UX friction signals GA4 has no equivalent for.
Excessive scrolling detection — flags visitors who scroll back and forth repeatedly, often a sign they can't find what they're looking for.
Copilot AI summaries — an AI-generated text summary of each session (traffic source, key actions, behavioral anomalies) and of aggregate heatmap patterns, so you don't have to watch every recording manually.
Smart Funnels — funnel analysis built from Smart Events and page visits, showing exactly where a flow like checkout or signup loses people.
Segments — saved combinations of filters (device, region, referral source, custom tags like the ones this container's customTags field sets) for repeatable analysis.
Official GA4 cross-linking — Microsoft's own GA4 integration adds aclarity_session_url parameter to GA4 events, so a session recording is one click away from inside Google Analytics itself.
Privacy-first by default — password and payment fields are masked automatically, no PII is collected, and Clarity is built to be GDPR- and CCPA-aligned out of the box.

None of this replaces GA4's job of counting sessions, attributing conversions, and feeding Explorations and Audiences. It answers the question GA4 was never built to answer: _why_the numbers look the way they do.

Community & Official Templates Used

Template	Author	Purpose
`Microsoft Clarity - Official`	Microsoft	Base install — injects the Clarity tracking script and handles identify/custom-tag calls.
`Microsoft Clarity Events`	mbaersch	Sends additional named events, custom tags, session upgrades, and consent signals to an already-running Clarity session.
`CookieYes CMP` & consent tags (incidental)	cookieyeshq / Kent Spencer / Simo Ahava	Provides the CMP interaction this recipe relays into Clarity — full build-out in the CookieYes post.
`Session or User Seconds Duration` (incidental)	Kent Spencer (drewspen)	Provides the duration milestone this recipe relays into Clarity — full build-out in the Session Duration post.

How to Import

Download the JSON from the Google Drive link above.
In GTM, go to Admin → Import Container.
Upload the container JSON.
Choose Merge (not Overwrite) to preserve your existing GA4 setup.
Update the Microsoft Clarity Project ID Constant variable with your real Clarity project ID (found in your project URL: clarity.microsoft.com/projects/view/<projectId>/).
Confirm the Microsoft Clarity tag's teardown relationship to Google Analytics Configuration is intact after import — teardown/setup relationships are preserved by Merge but worth a visual check in the tag list.
Open GTM Preview mode and load a page. Confirm the GA4 config tag fires, followed immediately by the Microsoft Clarity base tag in the same tag sequence.
Trigger one of the events this container relays (a CookieYes consent click, or the session duration threshold) and confirm both the GA4 event tag and its paired Clarity event teardown tag fire in order. See the linked posts above if you want the full CookieYes or Session Duration logic rather than just the Clarity relay.
In the Clarity dashboard, open Recordings and confirm the custom event names (cmp_click, session_duration_…sec) appear as filterable events on live sessions.
If you'd rather not rely on tag sequencing, re-point the Clarity event tags at the identical trigger already used by their paired GA4 event tag — both approaches are valid, see the trade-off discussion above.

The full source — container JSON and documentation — is also published on GitHub. If you adapt this pattern to relay additional GA4 events into Clarity, or switch from teardown chaining to shared triggers, open a pull request or issue.

⬇ Download GTM Container JSON

Session Duration Timer in GTM

Kent Spencer — Thu, 09 Jul 2026 22:46:40 +0000

Session Duration Timer in Google Tag Manager — A Complete Recipe Using Sandboxed JS

Measure seconds spent on your site per session — or across all sessions — with no CSP SHA-256 hashes, no external libraries, and a single importable container JSON.

Published · Tags: GTM, Google Analytics 4, Session Duration, Cookies, dataLayer, Custom Template, JavaScript

Most GTM engagement-time solutions either lean on GA4's built-in engagement time (which you can't trigger mid-session) or inject inline <script> tags that break under a strict Content Security Policy. This recipe solves both problems. It uses a GTM Sandboxed JavaScript custom template — the Session or User Seconds Duration tag — to run a per-second callLater loop that writes the running count to a first-party cookie and pushes a named dataLayer event at every tick. The result is importable in one JSON file, zero SHA-256 exemptions required.

⬇ Download the GTM Container JSON from Google Drive

What's Inside the Container

The exported GTM recipe (session-duration-timer-measurement-recipe.json) contains the following assets:

Asset Type	Name	Purpose
Tag (Custom Template)	Session Duration	Sandboxed JS timer loop — increments a counter each second, writes to cookie, pushes `durationSeconds` to the dataLayer
Tag (GA4 Event)	Session Duration Send Event	Fires a dynamically named GA4 event (`session_duration_Nsec`) at configured second milestones
Tag (Google Tag)	Google Analytics Configuration	Standard GA4 config tag routed via environment-aware stream ID lookup
Trigger	Session Duration Event	Custom event trigger — fires when `durationSeconds` matches the regex `^(6
Custom Template (Tag)	Session or User Seconds Duration	The engine: GTM sandboxed JS template by drewspen — no {% raw %}`document.cookie`, no inline script, no CSP issues
Custom Template (Variable)	If Else If – Advanced Lookup Table	Environment-aware regex lookup for GA4 Stream ID routing (by Sublimetrix)
Custom Template (Variable)	Timestamp	Millisecond timestamp provider (by luratic)
Custom Template (Variable)	Get Root Domain	Extracts registrable root domain for cookie scoping (by mbaersch)
Variables (many)	Session Duration Cookie Name, Session Duration dataLayer, is Session Duration Event, Browser Session/Client ID, Timestamps…	Supporting variable layer for stream routing, session identity, and event detection

Architecture Overview

Here is how the timer flows from page load to GA4:

Page loads. The Session Duration tag fires on GTM container load (All Pages trigger or your chosen trigger).
Cookie is read. The template calls GTM's sandboxed getCookieValues(cookieName). If a count already exists in the _i_vstdur cookie — including from a previous page in the same session — the counter resumes from that number rather than zero.
Timer loop starts. callLater(tick) schedules a 1-second recursive loop using GTM's sandboxed callLater API. Each tick: increments the counter, writes it back to the cookie with setCookie(), and pushes a dataLayer event.
dataLayer is updated every second. Each push follows the pattern: { event: '_i_vstdur', durationSeconds: N }. The event name is the cookie name itself, enabling the Simple Value Map lookup variable is Session Duration Event to confirm the event identity.
Trigger fires at milestones. The Session Duration Event custom event trigger checks two conditions: durationSeconds matches ^(6|11)$ AND is Session Duration Event equals true. At second 6 and second 11 (configurable), the trigger fires.
GA4 event is sent. The Session Duration Send Event tag fires a dynamically named GA4 event: session_duration_6sec or session_duration_11sec. A matching event parameter (session_duration_6sec_count: 1) is sent alongside it, making these countable as conversion metrics in GA4.
Loop halts at maxSeconds. The template's if (counter >= maxSecondsNum) return; guard ensures the loop stops cleanly at your configured ceiling (11 seconds by default), preventing runaway calls.

The Core Engine — Session or User Seconds Duration (Custom Template)

This is the heart of the recipe. Rather than injecting a raw <script> tag — which would require a CSP SHA-256 hash for every GTM publish — this is built as a GTM sandboxed JavaScript custom template tag. It uses only GTM's permitted sandboxed APIs: no document.cookie, no setInterval, no window access. This is the key reason the solution is CSP-friendly out of the box.

const log = require('logToConsole');
const getCookieValues = require('getCookieValues');
const setCookie = require('setCookie');
const createQueue = require('createQueue');
const dataLayerPush = createQueue('dataLayer');
const callLater = require('callLater');
const getTimestamp = require('getTimestamp');

const cookieName = data.durationCookie || 'duration';
const maxSecondsNum = (data.maxSeconds || 11) - 0;

const cookieOptions = data.cookieDuration === 'persistentCookie'
  ? { domain: data.rootDomain, path: '/', 'max-age': 60 * 60 * 24 * (data.persistentCookieExpires - 0) }
  : { domain: data.rootDomain, path: '/' };

// Resume from existing cookie value if present
const existingValues = getCookieValues(cookieName);
const existing = (existingValues && existingValues.length > 0) ? existingValues[0] : null;
const existingNum = existing - 0;
let counter = (existing !== null && existing !== '' && existingNum === existingNum)
              ? existingNum : 0;

if (existing === null || existing === '') {
  setCookie(cookieName, '0', cookieOptions);
}

const intervalMs = 1000;
let lastTick = getTimestamp();

function tick() {
  if (counter >= maxSecondsNum) return;
  const now = getTimestamp();
  if ((now - lastTick) >= intervalMs) {
    lastTick = now;
    counter = counter - (-1); // avoids unary + operator (sandboxed constraint)
    setCookie(cookieName, counter + '', cookieOptions);
    dataLayerPush({
      event: cookieName, // e.g. '_i_vstdur'
      durationSeconds: counter
    });
    if (counter < maxSecondsNum) { callLater(tick); }
  } else { callLater(tick); }
}

callLater(tick);
data.gtmOnSuccess();

Why counter - (-1) instead of counter++? GTM's sandboxed JS environment forbids certain operators. Subtracting negative one is a safe equivalent to incrementing that passes the sandboxed linter.

No CSP SHA-256 required. Because this logic lives inside a sandboxed custom template (not a Custom HTML tag), GTM loads it as part of the container's own script bundle. There is no separate inline <script> block that a Content Security Policy would need to whitelist with a hash. Publish freely without touching your CSP headers.

Template Parameters

Parameter	Type	Description
`rootDomain`	Select (macro)	Cookie domain scope. Defaults to `{{Root Domain}}`. Example: `.example.com`
`cookieDuration`	Radio	`sessionCookie` — clears when browser closes. `persistentCookie` — survives across sessions.
`persistentCookieExpires`	Number	Days until expiry when using `persistentCookie`. Defaults to 365. Unused for session cookies.
`durationCookie`	Text	Cookie name. Populated from the Session Duration Cookie Name constant: `_i_vstdur`
`maxSeconds`	Number	Ceiling at which the loop halts. Set to 11 in this recipe (configurable to any value).

Dual Output: Cookie + dataLayer Event

Every second the template does two things simultaneously, and the combination unlocks several use cases that neither output enables alone:

1. Cookie — `_i_vstdur`

The running second count is written to a first-party cookie on every tick. Because cookies are domain-scoped and persist across page navigations, the counter carries across pages within the same session. A visitor who spends 4 seconds on Page A and then navigates to Page B will resume at 4 on Page B — the total session engagement time accumulates naturally.

Switching cookieDuration from sessionCookie to persistentCookie extends this behaviour across sessions entirely. A returning visitor's cumulative seconds on site will pick up from where they left off — even days later — enabling lifetime engagement measurement without a login or backend.

2. dataLayer Event — `_i_vstdur` with `durationSeconds: N`

The dataLayerPush call each second creates a GTM custom event. This event is independently valuable in several ways:

Conversion trigger: The included Session Duration Event trigger fires a GA4 event at second 6 and second 11. In GA4, mark session_duration_6sec as a conversion — now your GA4 reports show how many users reached meaningful engagement thresholds.
Popup / dialog trigger: Any other GTM tag can listen for the same custom event trigger. Fire a newsletter signup popup at second 30, an exit-intent offer at second 60, or a user satisfaction survey at second 120 — all configurable from the trigger's regex without touching a line of JavaScript.
Personalization signal: Read durationSeconds from the dataLayer in other tags or variables to conditionally show content to engaged vs. bounced visitors in real time.

The trigger regex is the configuration knob. The current trigger fires at ^(6|11)$. To fire at 30, 60, and 120 seconds instead, change the regex to ^(30|60|120)$ — no code change, no republish of the template, just a trigger edit and a container publish.

The GA4 Event — Session Duration Send Event

The GA4 event tag produces dynamically named events using GTM variable interpolation:

GA4 Event Property	Value	Example at 6 sec
Event Name	`session_duration_{{Session Duration dataLayer}}sec`	`session_duration_6sec`
Event Parameter (name)	`session_duration_{{Session Duration dataLayer}}sec_count`	`session_duration_6sec_count`
Event Parameter (value)	`1`	`1`
Measurement ID Override	`{{Measurement Stream RegEx Lookup}}`	Routes to dev or prod stream automatically

Sending a parameter with a constant value of 1 alongside each event is intentional. In GA4 Explore reports, summing this parameter gives you the total count of users (or sessions) who reached each second milestone — a simple, reliable engagement funnel without requiring calculated metrics.

Trigger Detail — Session Duration Event

This custom event trigger uses two conditions that must both pass:

Condition	Variable	Value
Seconds match milestone	`{{Session Duration dataLayer}}` (DataLayer variable reading `durationSeconds`)	Matches regex `^(6
Event identity confirmed	{% raw %}`{{is Session Duration Event}}` (Simple Value Map: event name → `true`)	Equals `true`

The second condition prevents false positives if another dataLayer event happens to contain a durationSeconds key. Only events whose name matches the Session Duration Cookie Name constant (_i_vstdur) will resolve the Simple Value Map to true.

Session vs. Persistent Cookie — Cross-Session Measurement

The template ships with cookieDuration set to sessionCookie, which clears when the browser tab or window closes. This measures per-session engagement time — the most common use case. To measure lifetime user engagement across sessions, switch the radio to persistentCookie and set persistentCookieExpires to your desired retention window (365 days is the default). The logic is unchanged; only the cookie's max-age attribute is affected.

Mode	Cookie Type	What It Measures	Use Case
Default	Session cookie (no expiry)	Seconds per browser session	Standard engagement depth, bounce quality, conversion timing
Persistent	Persistent cookie (N days)	Cumulative seconds across all sessions	Lifetime engagement, loyalty scoring, subscriber depth measurement

Environment-Aware Stream Routing

The container includes a dual-layer regex lookup system so the same container file works across dev and production without manual edits:

URL pattern check: Measurement Stream RegEx Lookup scans the Page URL for patterns like dev., staging., uat., local., and the GTM preview URL (gtm-msr.appspot.com). Matches route to the development stream ID.
GTM environment name fallback: Environment Stream ID checks the GTM environment name for a ^liv.* pattern (Live) or pre-release environment names as a secondary signal.
Default: If neither pattern matches, the production stream ID is used.

Update Measurement Stream ID Production and Measurement Stream ID Development with your actual GA4 measurement IDs. The regex patterns need no changes for most standard setups.

How to Import

Download the JSON from the Google Drive link.
In GTM, go to Admin → Import Container.
Upload session-duration-timer-measurement-recipe.json.
Choose Merge (not Overwrite) to preserve your existing tags.
Update Measurement Stream ID Production and Measurement Stream ID Development constants to your actual GA4 stream IDs.
Adjust maxSeconds and the trigger regex ^(6|11)$ to your desired milestone seconds.
If you want cross-session measurement, switch cookieDuration from sessionCookie to persistentCookie in the Session Duration tag parameters.
Preview in GTM Preview mode, confirm cookie writes and dataLayer events at each second, then publish.

Consent: The session duration cookie and GA4 event should be gated on analytics_storage consent in your GTM consent settings if your site is subject to GDPR or similar regulation. The tag will not fire until consent is granted.

What You Can Do With It

Mark session_duration_30sec as a GA4 conversion to track meaningful engagement as a conversion metric in campaign reports
Use the custom event trigger at any second to fire a popup, chat widget, or modal without any additional JavaScript
Read _i_vstdur in other GTM tags or personalization scripts to segment engaged vs. disengaged visitors in real time on the current page
Switch to persistent cookies to build a lifetime engagement score for registered users or newsletter subscribers
Combine with the geolocation recipe to correlate session depth with geography — do users from certain cities engage longer?
Use the durationSeconds dataLayer variable in custom dimensions or BigQuery exports for cohort analysis in Looker Studio

The full source — including the container JSON, all custom template code, variable definitions, and trigger configuration — is available on GitHub. Questions or improvements? Open an issue or submit a pull request.

⬇ Download GTM Container JSON

GTM Form Engagement & Abandonment

Kent Spencer — Sun, 05 Jul 2026 20:55:00 +0000

GTM Form Engagement Waterfall: Visibility, Field, Submit & Response

Four Google Analytics 4 events, one shared event name, and a single contact_step_label parameter — enough to build a true form-abandonment funnel from nothing but Google Tag Manager triggers.

Published · Tags: GTM, Google Analytics 4, Form Tracking, Form Abandonment, Element Visibility, dataLayer, Funnel Exploration, GA4

Standing on the shoulders of giants. This recipe is a direct continuation of two earlier posts on this blog. The field-engagement stage below is built entirely on the generic document.addEventListener pattern that Simo Ahava first published in 2013 and that I adapted for GA4 in Listen to Any Browser Event in GTM. The element-identification logic — the coalesce chains that walk up the DOM to find a usable class, id, or label — comes straight from GTM Universal Click – No JavaScript. Neither of those posts touched forms directly. This one bolts both techniques onto a real Blogger contact form widget and adds two more stages — visibility and response — to turn them into a complete waterfall.
Most GTM form recipes stop at one event: gtm.formSubmit. That tells you a form was submitted, but it tells you nothing about the funnel that led there — how many visitors even saw the form, which field they touched last before giving up, or whether the submission actually succeeded once it reached the server. A single submit event is a snapshot. A waterfall is a story. This recipe sends four GA4 events, in page order, all sharing one event name — contact_form_step — so they stack cleanly into a GA4 Funnel Exploration:

Visible — the contact form widget scrolls into view
Field — a visitor changes a field's value (Simo's 2013 pattern, adapted for forms)
Submit — the visitor clicks the Send button
Response — the page shows a success or error message Compare step 1 against step 3 and you get a scroll-to-submit rate. Compare step 2 against step 3 and you learn whether visitors who engage with a field actually finish. Compare step 3 against step 4 and you catch silent submission failures — the gap that almost no analytics setup measures, because it depends on which DOM element the form's own JavaScript reveals after the request resolves. The illustration form for this recipe is Blogger's own built-in contact form widget — the same three-field Name / Email* / Message* form running in this blog's sidebar.

⬇ Download the GTM Container JSON from Google Drive

What's Inside the Container

The exported container groups the recipe into two folders: Analytics (the shared GA4 configuration and environment routing infrastructure covered in earlier posts) and Contact Form (everything specific to the waterfall). A third folder, Element Hierarchy , supplies the coalesce chains reused from the click-tracking recipe, and Custom Events holds the onChange listener carried over from the 2013 pattern.

Asset Type	Name	Purpose
Tag (Custom HTML)	onChange Listener	Attaches a native `change` event listener to `document`; fires on `gtm.js` load
Tag (GA4 Event)	contact form step visible	Stage 1 — sends `contact_form_step` with `contact_step_label = "visible"` when the form scrolls into view
Tag (GA4 Event)	contact form step field	Stage 2 — sends `contact_form_step` with the changed field's name as the label
Tag (GA4 Event)	contact form step submit	Stage 3 — sends `contact_form_step` with `contact_step_label = "submit"` on Send click
Tag (GA4 Event)	contact form step response	Stage 4 — sends `contact_form_step` with a dynamic `"success"` or `"error"` label
Tag (GA4 Event)	contact form conversion metric	Fires alongside stage 4 — a separate, discretely named conversion event for GA4's Conversions list
Tag (GA4 Event)	onChange Event Push	Legacy tag from the original 2013-pattern recipe; left in the container but paused, superseded by "contact form step field"
Tag (Google Tag)	Google Analytics Configuration	Standard GA4 config tag with environment-aware Stream ID routing
Trigger (Element Visibility)	contact-form-widget	`div[class="contact-form-widget"]` — fires stage 1
Trigger (Custom Event)	gtm.js change	Matches `gtm.change` pushed by the onChange listener — fires stage 2
Trigger (Click)	contact-form-button-submit	Matches the Send button's Click ID and Click Classes — fires stage 3
Trigger (Element Visibility)	contact-form-success-message-with-border	`p[class="contact-form-success-message-with-border"]` — fires stage 4 (success branch)
Trigger (Element Visibility)	contact-form-error-message-with-border	`p[class="contact-form-error-message-with-border"]` — fires stage 4 (error branch)
Trigger (Custom Event)	gtm.js load	Fires the onChange Listener Custom HTML tag when GTM initializes
Variable (Custom JS)	generic event handler	Simo Ahava's 2013 callback pattern — pushes element metadata to the dataLayer on any native browser event
Variable (Custom Template)	coalesce className / coalesce id	If Else If lookups — return the first non-empty class or id walking up the DOM tree
Variable (Custom Template)	Coalesce Click Elements	Returns the first human-readable label: Click Text → Title → Name → Value
Variable (Switch Lookup)	contact form step conversion status	Maps the visible message's Form ID to the literal string `"success"` or `"error"`
Variable (Switch Lookup)	contact form conversion metric name	Maps the same Form ID to a distinct GA4 event name for the conversion tag
Variable (Auto-Event)	Form ID / Form Text / Form Classes	Built-in GTM variable types, repurposed here to read visibility-trigger context (see below)
Custom Template	If Else If – Advanced Lookup Table	Powers every coalesce variable (by Sublimetrix)

Architecture Overview: The Four-Stage Waterfall

Every stage shares the same GA4 event name, contact_form_step, and the same four parameters: contact_step_class, contact_step_name, contact_step_id, and contact_step_label. Only the trigger and the value of contact_step_label change from stage to stage. That single design decision is what makes the waterfall possible — GA4's Funnel Exploration can group all four stages under one event and let contact_step_label define the funnel steps in page order.

Widget enters the viewport. The contact-form-widget Element Visibility trigger fires the first time the form's container is 100% on screen. The contact form step visible tag sends contact_form_step with contact_step_label = "visible".
A visitor changes a field. The onChange Listener Custom HTML tag — registered once at gtm.js load — has already attached a native change listener to document. When a visitor commits a value in Name, Email, or Message, the generic event handler variable pushes a gtm.change event carrying the changed element's id, class, and name. The gtm.js change Custom Event trigger catches it and fires contact form step field, which sends contact_form_step with contact_step_label set to the field's own name.
The visitor clicks Send. The contact-form-button-submit Click trigger matches the exact Click ID and Click Classes of Blogger's submit button. The contact form step submit tag sends contact_form_step with contact_step_label = "submit".
The form responds. Blogger's own form-handling script reveals one of two hidden <p> elements once the submission resolves — a success message or an error message. Two Element Visibility triggers watch both elements. Whichever one appears fires two tags at once: contact form step response, which closes out the waterfall with a dynamic "success" or "error" label, and contact form conversion metric, which sends a separate, discretely named GA4 event so the success case can be marked as a Conversion independently of the funnel.

Stage 1 — Form Visibility

The entry point is a standard GTM Element Visibility trigger targeting the form's wrapping <div>:

Trigger Setting	Value
Selector type	CSS
Element selector	`div[class="contact-form-widget"]`
When to fire this trigger	Many per element
Minimum percent visible	100%
Observe DOM changes	Enabled

Many per element, not once per element: most visibility recipes use "Once per element" so a single impression is logged. This one deliberately uses Many per element, because a visitor who scrolls the form on and off screen repeatedly while deciding whether to fill it out is itself a signal — that behavior is visible in GA4 as multiple visible steps against a single submit, and it's a legitimate hesitation signal worth keeping rather than filtering out.

The contact form step visible tag reads the form's own identifying attributes using the same coalesce variables introduced in the click-tracking recipe — {{coalesce className}}, {{coalesce id}}, and {{Coalesce Click Elements}} — so the event carries a usable label even if Blogger's theme wraps the widget in extra nested containers with no class of their own.

GA4 Parameter	GTM Variable
`contact_step_class`	`{{coalesce className}}`
`contact_step_name`	`{{Coalesce Click Elements}}`
`contact_step_id`	`{{coalesce id}}`
`contact_step_label`	`"visible"` (static string)

Stage 2 — Field Engagement (Simo Ahava's 2013 Pattern, Applied to Forms)

This is the stage that makes the waterfall a waterfall and not just a funnel. Visibility and submit only tell you whether someone saw the form and whether they finished it. Field-level engagement tells you where, between those two moments, a visitor actually stopped.

The mechanism is identical to the one documented in Listen to Any Browser Event in GTM: a Custom HTML tag attaches a native change listener to document once, at gtm.js load, and every field on the page — Name, Email, Message — bubbles its change events up to that single listener automatically.

<script>
  var eventType = 'change';
  if (document.addEventListener) {
    document.addEventListener(eventType, {{generic event handler}}, false);
  }
  else if (document.attachEvent) {
    document.attachEvent('on' + eventType, {{generic event handler}});
  }
</script>

The generic event handler variable is Simo's 2013 callback, unmodified:

function() {
  return function(e) {
    window.dataLayer.push({
      'event': 'gtm.' + e.type,
      'gtm.element': e.target,
      'gtm.elementClasses': e.target.className || '',
      'gtm.elementId': e.target.id || '',
      'gtm.elementTarget': e.target.target || '',
      'gtm.elementUrl': e.target.href || e.target.action || '',
      'gtm.originalEvent': e
    });
  }
}

When a visitor tabs out of the Email field having typed something, the browser's native change event fires, the handler pushes gtm.change, and the gtm.js change Custom Event trigger catches it.

The reuse trick: the contact form step field tag doesn't need any new variables to identify which field changed. Because the handler pushes gtm.element, gtm.elementClasses, and gtm.elementId — the exact same dataLayer keys that GTM's built-in Click auto-event variables read — {{Click ID}}, {{Click Classes}}, and {{Element Name}} populate correctly even though no click ever happened. GTM's auto-event variable families don't actually care which trigger fired; they read whatever is sitting in the generic gtm.element* keys at the time the tag evaluates. That's the same principle this container leans on again in stage 4.

GA4 Parameter	GTM Variable
`contact_step_class`	`{{Click Classes}}`
`contact_step_name`	`{{Element Name}}`
`contact_step_id`	`{{Click ID}}`
`contact_step_label`	`{{Element Name}}` — the field's own `name` attribute

Why contact_step_label repeats contact_step_name here: in a funnel exploration, the label is the axis GA4 groups steps on. Using the field's name — name, email-message, and so on — as the label means each field becomes its own funnel step in the report, letting you see the drop-off between "engaged with Name" and "engaged with Message" directly, rather than collapsing all field interactions into one generic step.

Housekeeping note: the container also ships the original onChange Event Push tag from the 2013-pattern recipe, wired to the same gtm.js change trigger. It's left in place but paused — its onChange event name doesn't fit the shared contact_form_step naming needed for the waterfall, so contact form step field supersedes it for this use case. Unpause it separately if you also want a parallel, form-agnostic onChange event stream.

Stage 3 — Form Submit

The submit stage uses a standard GTM Click trigger with two AND-combined filter conditions, matching Blogger's own submit button precisely:

Filter	Condition
`{{Click ID}}`	equals `ContactForm1_contact-form-submit`
`{{Click Classes}}`	equals `contact-form-button contact-form-button-submit`

Both conditions together avoid false positives from other buttons on the page that might share one attribute but not the other. The contact form step submit tag then sends the same contact_form_step event with a static label:

GA4 Parameter	GTM Variable
`contact_step_class`	`{{Click Classes}}`
`contact_step_name`	`{{Element Name}}`
`contact_step_id`	`{{Click ID}}`
`contact_step_label`	`"submit"` (static string)

Note what this stage deliberately does not use: GTM's built-in Form Submission trigger. Blogger's contact form widget submits via its own script rather than a native form POST that GTM's form trigger reliably detects, so a Click trigger on the button itself is the dependable signal here. This mirrors the point made in Listen to Any Browser Event in GTM about GTM's built-in triggers not always covering every framework's submission behavior.

Stage 4 — Success or Error Response

This is the stage almost no form-tracking setup includes, and it's the one that turns "form submitted" into "form actually worked." Blogger's widget keeps two message elements in the DOM at all times — one for success, one for error — and reveals whichever one applies only after its own script resolves the submission:

Trigger	Element Selector
contact-form-success-message-with-border	`p[class="contact-form-success-message-with-border"]`
contact-form-error-message-with-border	`p[class="contact-form-error-message-with-border"]`

Both are Element Visibility triggers at 100% on-screen ratio with DOM-change observation enabled, since the elements only become visible after a script mutates the page — there's no separate page load or click to hang a trigger off. Two tags fire from these triggers:

contact form step response — closes the waterfall

This tag completes the funnel with the same contact_form_step event name used by every earlier stage. Its label isn't static — it's resolved dynamically by a Switch/Lookup Table variable, contact form step conversion status , keyed on which message element became visible:

if Form ID == "ContactForm1_contact-form-success-message" → "success"
if Form ID == "ContactForm1_contact-form-error-message" → "error"

GA4 Parameter	GTM Variable
`contact_step_class`	`{{Form Classes}}`
`contact_step_name`	`{{Form Text}}`
`contact_step_id`	`{{Form ID}}`
`contact_step_label`	`{{contact form step conversion status}}` — `"success"` or `"error"`

Why Form ID, Form Text, and Form Classes work here even though no form was submitted: these are GTM's built-in auto-event variables, normally populated by the Form Submission trigger family. But like {{Click ID}} in stage 2, they don't actually require that specific trigger — they read the generic gtm.elementId, gtm.elementText, and gtm.elementClasses dataLayer keys, which GTM's Element Visibility trigger populates on its own every time it fires. Because the visible element in this case is the message <p> tag itself, {{Form ID}} resolves to that paragraph's id, and {{Form Text}} resolves to its visible text — the exact success or error copy Blogger renders. This is the same principle documented in GTM Universal Click – No JavaScript: GTM's auto-event variable families are really just labeled windows onto a shared set of generic dataLayer keys, and any trigger that populates those keys can feed any variable family that reads them.

contact form conversion metric — a discrete conversion event

The waterfall step above is useful for funnel analysis, but GA4's Conversions list works best with a single, unambiguous event name per conversion — not one event with a dynamic label buried in a parameter. So the same trigger pair also fires a second tag that sends a distinct event name, resolved by a companion lookup variable, contact form conversion metric name :

if Form ID == "ContactForm1_contact-form-success-message" → "contact-form-success"
if Form ID == "ContactForm1_contact-form-error-message" → "contact-form-error"

GA4 Parameter	GTM Variable
Event name	`{{contact form conversion metric name}}`
`conversion_label`	`{{Form ID}}`
`conversion_value`	`{{Form Text}}`
`conversion_name`	`{{contact form conversion metric name}}`

Mark contact-form-success as a Conversion in GA4 admin and you have a clean, single-purpose conversion metric — independent of the funnel, and unaffected by how you later restructure the waterfall's step labels.

Full Event Reference

Stage	Event Name	`contact_step_label`	Trigger Type
1. Visible	`contact_form_step`	`visible`	Element Visibility
2. Field	`contact_form_step`	field's `name` attribute	Custom Event (`gtm.change`)
3. Submit	`contact_form_step`	`submit`	Click
4. Response	`contact_form_step`	`success` / `error`	Element Visibility
4b. Conversion	`contact-form-success` / `contact-form-error`	— (own event, not a step)	Element Visibility (same trigger as 4)

Building the GA4 Funnel Exploration

In GA4, go to Explore → Funnel exploration.
Add a new step for each waterfall stage, all filtered on Event name = contact_form_step.
On each step, add a second condition on the contact_step_label parameter: visible for step 1, your field names for step 2 (add one sub-step per field if you want field-level resolution), submit for step 3, and success for step 4.
Enable "Open funnel" if you want to include visitors who entered mid-funnel (e.g. arrived already scrolled past the form), or leave it closed to require strict step 1 entry.
Add contact_step_id or contact_step_name as a breakdown dimension on the field step to see exactly which fields are engaged most and least before drop-off.

Register contact_step_class, contact_step_name, contact_step_id, and contact_step_label as custom event-scoped dimensions under Admin → Custom definitions → Custom dimensions before they'll appear as report and exploration options.

How to Import

Download the JSON from the Google Drive link.
In GTM go to Admin → Import Container.
Upload gtm-waterfall-form-field-engagement.json.
Choose Merge to preserve your existing configuration.
Update the Measurement Stream ID Development and Measurement Stream ID Production constants with your own GA4 Measurement IDs.
If your form isn't Blogger's contact widget, update the four CSS selectors in the Element Visibility triggers and the Click ID / Click Classes filter on the submit trigger to match your own markup.
In GA4, register contact_step_class, contact_step_name, contact_step_id, and contact_step_label as event-scoped custom dimensions.
Mark contact-form-success as a Conversion under Admin → Events.
Open GTM Preview mode, scroll to the form, change a field, submit it, and confirm all four contact_form_step events fire in order in the Tag Assistant panel — followed by either contact-form-success or contact-form-error.
Publish the container.

What You Can Do With It

Build a GA4 Funnel Exploration to see exactly where visitors abandon the form — after seeing it, after starting a field, or after submitting
Compare field-level engagement rates to spot a specific field (often Message) that causes disproportionate drop-off
Catch silent submission failures that a submit-only setup would report as successful conversions
Segment the contact-form-error conversion event by page path to find which landing pages produce the most failed submissions
Adapt the same four-stage pattern to any form — checkout, newsletter signup, gated content — by swapping the CSS selectors and Click filter values

The full source — container JSON, all variable code, and the complete event reference — is available via the Google Drive link. This recipe builds directly on the DOM traversal and change-event techniques from the two posts linked above; read those first if any of the coalesce or auto-event variable behavior here is unfamiliar.

⬇ Download GTM Container JSON

Site Landing & Site Referrer Preservation

Kent Spencer — Wed, 24 Jun 2026 12:41:44 +0000

Site Landing Page & Site Referrer to Cookies in Google Tag Manager — A Complete Recipe Without Custom JavaScript

Persist the user's landing page host, landing page path, and referral source into session or long-lived persistent cookies using only GTM sandboxed Custom Templates. No Custom HTML tags. No new CSP hashes.

Published · Tags: GTM, Google Analytics 4, Cookies, Site Referrer, Landing Page, First-Touch Attribution, User Journey, dataLayer, CSP, GA4

Where did this user first land on your site — and what referred them there? Those two pieces of information are foundational to understanding any user journey. But they only exist at the moment of the first page load. Navigate to a second page, return in a new browser session, or submit a form three days after the original visit, and the browser's native referrer is gone and the landing URL has long since changed. Without a persistence layer, you are flying blind.

This recipe solves that problem cleanly. On the very first Initialisation event — before any other tag fires — it captures the site landing host, landing page path, and referral host, and writes them into browser cookies. Session cookies cover the current visit; persistent cookies with a _1 suffix survive for up to 730 days, recording the user's first ever landing and referral. Both cookie sets flow automatically into every GA4 hit via Shared Event Settings and GA4 User Properties. No Custom HTML tags. No new Content Security Policy SHA-256 hashes required.

⬇ Download the GTM Container JSON from Google Drive

The Core Problem: Landing Context Vanishes After the First Page

A visitor arrives at https://example.com/pricing referred from a partner site at https://partner.example.org/blog/recommended-tools. GA4 records the referral for the session. But the user does not convert. They return three days later by typing the URL directly. GA4 now attributes that second session to direct. The referral source that actually initiated the relationship is invisible.

The same problem applies to your own site's landing pages. Knowing that a user's first ever landing was /pricing versus /blog/use-case-study gives you a completely different picture of their intent and where they are in the funnel — information that is lost the moment they navigate away from that first page.

Cookies are the browser's built-in persistence mechanism for exactly this purpose. This recipe writes the landing and referral context on Initialisation (the very first GTM event) and makes those values available across every subsequent page view, event, and session.

Why this matters beyond utm_source: UTM parameters tell you the campaign-level source a marketer chose to declare. But utm_source is a free-text field — there is nothing enforcing that it contains an actual traffic source. A campaign tagged utm_source=spring-promo tells you nothing about where traffic originated. The site referrer, by contrast, is set by the browser and reflects the actual page the user navigated from. Capturing the referral host independently of UTM tagging gives you a ground-truth signal of traffic origin that is not subject to marketer naming conventions.

Why this matters for user journey analysis: The user's first landing page and first referral source are the starting coordinates of their entire journey on your site. Persisting them in long-lived cookies lets you attach first-touch landing context to any downstream event — form submission, purchase, demo request — regardless of how many sessions have elapsed since that first visit. This enables cohort analysis, funnel analysis by entry point, and lifetime value attribution by acquisition source, none of which are possible if you only have the landing data from the current session.

Why no new CSP hashes are required: The traditional approach to writing cookies in GTM is a Custom HTML tag containing an inline <script> block. Any such script requires its SHA-256 hash to be listed in your Content-Security-Policy header's script-src directive. Every time the script changes — even whitespace — the hash changes and must be redeployed. This recipe uses only GTM sandboxed Custom Templates, which execute inside GTM's own sandbox and require zero additions to your CSP. The cookie-writing logic runs entirely within the GTM runtime — no new hashes, no security team review cycles.

What's Inside the Container

The exported container (site-landing-and-referrer-2-cookies-recipe.json) is organised into three folders, plus the existing Analytics infrastructure and sandboxed Custom Templates.

Folders

Folder	Contains
Analytics	GA4 configuration tag, shared settings variables, environment and stream routing variables, and client ID and timestamp utilities.
Process site landing & site referrer 2 cookies	Two tags (session and user/persistent), plus eight Cookie Variable variables reading the landing host, landing path, referral host, and referral path for each track. Fires on Initialisation — the earliest possible GTM event — to capture the landing context before any other tag can fire.
Extend Cookie Life	One tag and two supporting variables. Rewrites the persistent cookies on every page visit to refresh their expiry date, ensuring the 730-day window resets on each visit rather than counting from first write.

Tags

Tag	Type	Purpose
`Google Analytics Configuration`	Google Tag (`googtag`)	Standard GA4 configuration tag. Shared Event Settings and User Properties automatically forward landing and referral cookie values on every GA4 hit.
`Write site landing & site referrer 2 cookies user`	Custom Template — Write site landing & site referrer 2 cookies	Fires on Initialisation, but only if the landing host and referral host persistent cookies do not already exist (trigger condition: both `{{site Referral Host user}}` and `{{site Landing Host user}}` match the empty/null regex). Writes four persistent cookies expiring in 730 days, with the `_1` suffix: `landHost_1`, `landPath_1`, `referHost_1`, `referPath_1`. Because the trigger only fires when the cookies are absent, these values are set exactly once — on the user's first ever visit — and never overwritten.
`Write site landing & site referrer 2 cookies session`	Custom Template — Write site landing & site referrer 2 cookies	Fires on Initialisation, but only if the session-level cookies are absent (both `{{site Referral Host session}}` and `{{site Landing Host session}}` are empty). Writes four session cookies — `landHost`, `landPath`, `referHost`, `referPath` — that expire when the browser closes. Refreshed on each new browser session.
`Extend Cookie Life Tag`	Custom Template — Cookie Rewriter	Fires on DOM Ready, guarded by the `_arrewr` sentinel cookie. Rewrites the persistent landing and referral cookies with a refreshed expiry of 720 days from now, without altering their values.

Triggers

Trigger	Type	Condition	Purpose
`Write site landing & site referrer 2 cookies user`	Initialisation	`{{site Referral Host user}}` AND `{{site Landing Host user}}` both match `^(undefined	null
{% raw %}`Write site landing & site referrer 2 cookies session`	Initialisation	`{{site Referral Host session}}` AND `{{site Landing Host session}}` both match `^(undefined	null
{% raw %}`Extend Cookie Life Trigger`	DOM Ready	`{{Extend Cookie Life Already Ran Cookie Value}}` matches `^(undefined	null

Custom Templates

Template	Author	Purpose
{% raw %}`Write site landing & site referrer 2 cookies`	drewspen	Reads the current page's host, page path, document referrer host, and document referrer path, and writes them to browser cookies with configurable expiry (session or persistent), a cookie name suffix, root domain scoping, and optional URI decoding. Runs entirely within the GTM sandboxed template runtime — no Custom HTML, no CSP implications.
`Cookie Rewriter`	drewspen	Rewrites a specified list of existing cookies with a refreshed expiry date, converting static expiry windows into rolling windows that extend on each visit.
`If Else If — Advanced Lookup Table`	Sublimetrix	Powers coalesce and routing logic elsewhere in the container.
`Timestamp`	Sublimetrix	Reads Unix timestamps from GA4 session and client cookies for shared event parameters.
`Get Root Domain`	drewspen	Extracts the registrable root domain for cookie scoping, ensuring cookies are accessible across subdomains (e.g. `www.example.com` and `app.example.com`).

Two Tracks: Session Cookies and Persistent Cookies

The recipe deliberately writes each landing and referral value twice — once as a session cookie and once as a persistent cookie. This gives you two distinct attribution windows with a single implementation: what happened in this session, and what happened on the user's first ever visit.

Session Cookies — Current Visit Context

Session cookies expire automatically when the browser is closed. They record the landing page and referral source for the current visit only. This is ideal for within-session attribution: if a user arrives from a partner site, browses three pages, and completes a download, the session cookie carries the referral host through the entire session — even though document.referrer changes on every page navigation.

Cookie Name	Type	Content
`landHost`	Session	Hostname of the first page the user landed on this session (e.g. `example.com`)
`landPath`	Session	Page path of the first landing page this session (e.g. `/pricing`)
`referHost`	Session	Hostname of the referring site at session start (e.g. `partner.example.org`)
`referPath`	Session	Full referrer path at session start (URI-decoded)

Persistent Cookies — First-Touch Attribution Across Visits

Persistent cookies survive browser restarts and are retained for up to 730 days (2 years) from initial write. The _1 suffix is the distinguishing convention — these cookies hold the values from the user's very first visit. Because the user-level trigger only fires when both cookies are absent, the values are written exactly once and never overwritten by subsequent visits. When the Cookie Rewriter runs on later visits, it refreshes the expiry without touching the values, preserving the original first-touch context.

Cookie Name	Type	Expiry	Content
`landHost_1`	Persistent	730 days (rolling)	Hostname of the user's first ever landing page
`landPath_1`	Persistent	730 days (rolling)	Page path of the user's first ever landing page
`referHost_1`	Persistent	730 days (rolling)	Hostname of the referring site on the user's first ever visit
`referPath_1`	Persistent	730 days (rolling)	Full referrer path on the user's first ever visit (URI-decoded)

The Rolling Expiry: How the Cookie Rewriter Works

A persistent cookie written once with a 730-day expiry will expire 730 days after it was first written, regardless of how often the user returns. For most use cases, a rolling expiry is preferable — active users should never lose their first-touch attribution simply because they have not visited in 730 days since acquisition.

The Extend Cookie Life Tag achieves rolling expiry by running the Cookie Rewriter template on every page visit. It reads each of the four persistent landing and referral cookies and rewrites them with the same value but a new expiry date set 720 days from the current time. The first-touch values are preserved; only the expiry date changes.

The Sentinel Guard: Firing Exactly Once Per Page

To avoid the Cookie Rewriter firing multiple times per page load, the recipe uses a sentinel cookie named _arrewr. The Extend Cookie Life Trigger condition checks {{Extend Cookie Life Already Ran Cookie Value}} against the regex ^(undefined|null|0|false|NaN|)$. The tag fires only when the sentinel is absent or empty. The Cookie Rewriter template sets _arrewr on its first run, preventing any subsequent firing within the same page load.

Cookie Variables: Reading the Values Back

Eight Cookie Variable variables are included in the Process site landing & site referrer 2 cookies folder, one for each cookie. These use GTM's built-in First-Party Cookie variable type and require no custom code. The landPath and referPath variables are configured with URI decoding enabled; the host variables are not, as hostnames do not require decoding.

Variable Name	Cookie Read	Decode	Track
`site Landing Host session`	`landHost`	No	Current session
`site Landing Page Path session`	`landPath`	Yes	Current session
`site Referral Host session`	`referHost`	No	Current session
`site Referral Page Path session`	`referPath`	Yes	Current session
`site Landing Host user`	`landHost_1`	No	First touch (persistent)
`site Landing Page Path user`	`landPath_1`	Yes	First touch (persistent)
`site Referral Host user`	`referHost_1`	No	First touch (persistent)
`site Referral Page Path user`	`referPath_1`	Yes	First touch (persistent)

How Landing and Referral Data Flow Into Every GA4 Hit

The cookie variable values are wired into the Google Tag Shared Event Settings variable as event-scoped parameters and into the GA4 User Properties block. This means the values are forwarded on every GA4 event sent by the container — page views, scroll events, clicks, form submissions, and conversions alike — without any need to touch individual tag configurations.

Shared Event Settings — Landing and Referral Parameters

GA4 Event Parameter	GTM Variable	Attribution Track
`e_cur_landing_host`	`{{site Landing Host session}}`	Landing hostname for the current session
`e_cur_landing_path`	`{{site Landing Page Path session}}`	Landing page path for the current session
`e_cur_referral_source`	`{{site Referral Host session}}`	Referral hostname for the current session
`e_1st_landing_host`	`{{site Landing Host user}}`	Landing hostname on user's first ever visit
`e_1st_landing_path`	`{{site Landing Page Path user}}`	Landing page path on user's first ever visit
`e_1st_referral_source`	`{{site Referral Host user}}`	Referral hostname on user's first ever visit

GA4 User Properties — Landing and Referral

In addition to event-scoped parameters, the Shared Event Settings variable also populates GA4 User Properties. User Properties persist at the user level in GA4 and are available in audience definitions, Explorations, and BigQuery exports.

GA4 User Property	GTM Variable	Attribution Track
`u_cur_landing_host`	`{{site Landing Host session}}`	Landing hostname for the current session
`u_cur_landing_path`	`{{site Landing Page Path session}}`	Landing page path for the current session
`u_cur_referral_source`	`{{site Referral Page Path session}}`	Referral page path for the current session
`u_1st_landing_host`	`{{site Landing Host user}}`	Landing hostname on user's first ever visit
`u_1st_landing_path`	`{{site Landing Page Path user}}`	Landing page path on user's first ever visit
`u_1st_referral_source`	`{{site Referral Page Path user}}`	Referral page path on user's first ever visit

Architecture: How a Landing Becomes a Cookie Becomes a GA4 Parameter

User lands on the site for the first time. GTM fires the Initialisation event — the very earliest event in the GTM lifecycle, before page view, before DOM Ready, before any other tag.
Both user-level persistent cookie triggers evaluate. Because landHost_1 and referHost_1 do not yet exist, both Cookie Variable variables return empty strings matching the null regex. The trigger fires.
The user-level write tag runs. The Write site landing & site referrer 2 cookies user tag reads the current page hostname, current page path, document referrer hostname, and document referrer path, and writes them as persistent cookies scoped to the root domain (e.g. .example.com), expiring 730 days from now. These values are permanently set for this user.
The session-level write tag also runs. If the session cookies are also absent (new session), the Write site landing & site referrer 2 cookies session tag writes the same four values as session cookies (no expiry — browser-close expiry).
GTM fires DOM Ready. The Extend Cookie Life Trigger checks the _arrewr sentinel. If absent, the Extend Cookie Life Tag rewrites the four persistent cookies with a new 720-day expiry from now.
Cookie Variable variables are evaluated on every GTM event. The eight cookie variables read the current values from the browser for every subsequent event.
Shared Event Settings deliver values to GA4. The six event parameters (e_cur_* and e_1st_*) and six User Properties (u_cur_* and u_1st_*) are included in every GA4 hit automatically.
Days or weeks later, the user returns directly. Their persistent cookies still hold the original first-touch landing and referral values. The session cookies are absent (browser closed), so the session-level write tag fires again, capturing the new session's landing context. The persistent cookies are extended by the Cookie Rewriter but their values are unchanged.
A conversion event fires. GA4 receives both the current-session landing context and the first-ever landing context on the same event hit, allowing multi-session journey analysis in a single query.

Why Sandboxed Templates Do Not Require New CSP Hashes

GTM's sandboxed Custom Template runtime accesses browser APIs through GTM's own internal permission model — not through Content Security Policy. A template that writes a cookie uses GTM's setCookie sandbox API, which executes within code already authorised by the GTM container's existing CSP allowance (the allowance granted to googletagmanager.com).

In contrast, a Custom HTML tag writes a literal <script> element into the DOM. CSP's script-src directive applies to every inline script element. Unless you have unsafe-inline enabled (which defeats much of CSP's purpose) or a matching SHA-256 hash in your CSP header, the browser blocks execution. Every change to that script — adding a comment, reformatting a line, changing a cookie name — changes the hash and requires a CSP header redeployment and typically a security team review cycle.

With sandboxed templates, your CSP never changes when GTM tag logic changes. The entire landing and referral cookie implementation in this recipe is CSP-transparent.

Real-World Use Cases

Identifying the True Referral Source When utm_source Is Not Reliable

Google's convention is that utm_source should identify the actual traffic source — the platform, publisher, or channel that sent the visitor. In practice, many campaigns use utm_source as a free-text label: utm_source=spring-promo, utm_source=email-footer, utm_source=sales-team. These values describe the campaign intent, not the origin of the traffic.

The referral host cookie, set by the browser from document.referrer, reflects where the user actually navigated from — independent of any UTM tagging. A visit tagged utm_source=spring-promo that shows referHost=email.mailprovider.com tells you it was an email campaign. A visit tagged utm_source=newsletter with referHost=t.co tells you the link was actually shared on X (Twitter). The referral host provides a ground-truth origin signal that complements — and sometimes corrects — the UTM source value.

First-Touch Landing Page Analysis for User Journey Mapping

The user's first ever landing page is one of the most predictive signals of their intent and their position in the funnel. A user whose first landing was /pricing is on a fundamentally different journey from one whose first landing was /blog/what-is-x. But without persistent cookies, you can only know the first landing page if the user converted in the same session — which is rare in B2B and considered-purchase categories.

With landPath_1 persisted for up to two years, you can join any downstream event — a contact form submission, a free trial activation, a purchase — to the user's original entry point. In GA4 Explorations or BigQuery, this enables cohort analysis by first landing page, funnel analysis by acquisition path, and lifetime value modelling by initial intent signal.

B2B Multi-Session Lead Attribution

A prospect clicks a LinkedIn post, lands on /case-studies/enterprise, reads for ten minutes, and leaves. The referral host and landing path are stored in persistent cookies: referHost_1=linkedin.com, landPath_1=/case-studies/enterprise. Two weeks later, they return directly, read the pricing page, and submit a demo request form. Your CRM receives hidden form fields populated from the cookie values — and your sales team knows the lead came from LinkedIn via the enterprise case study page, not from direct traffic.

How to Import

Download the JSON file from the Google Drive link.
In GTM, go to Admin → Import Container.
Upload site-landing-and-referrer-2-cookies-recipe.json.
Choose Merge (not Overwrite) to preserve your existing tags and triggers.
Update Measurement Stream ID Production and Measurement Stream ID Development constant variables to your actual GA4 Measurement IDs.
Verify that {{Root Domain}} resolves correctly for your site — this controls the cookie's domain scope. Check its value in GTM Preview mode on your site before publishing.
In GA4, register the following as custom event-scoped dimensions under Admin → Custom definitions → Custom dimensions : e_cur_landing_host, e_cur_landing_path, e_cur_referral_source, e_1st_landing_host, e_1st_landing_path, e_1st_referral_source.
Register the six User Properties under Admin → Custom definitions → Custom dimensions (selecting User scope): u_cur_landing_host, u_cur_landing_path, u_cur_referral_source, u_1st_landing_host, u_1st_landing_path, u_1st_referral_source.
Open GTM Preview mode on a URL with an external referrer and confirm the cookie variables populate in the Tag Assistant panel under the Initialisation event.
Navigate to a second page and confirm that the session and persistent cookie values persist (the landing host should remain the first page URL, not the current page URL).
Close the browser, reopen, and revisit the site directly. Confirm the session cookies are absent (triggering a new session write) and the _1 persistent cookies still hold the original first-visit values.

Cookie consent: Writing persistent cookies that track user journey and referral attribution may require consent under GDPR, CCPA, or equivalent regulations depending on your jurisdiction and how the data is used. Review with your legal team. The recipe writes cookies on the Initialisation event (the very first GTM event); if you operate a consent-managed site, gate both Write tags behind a consent trigger that only fires after the user has accepted analytics or marketing cookies.

What You Can Do With It

Attach first-touch landing page and referral source to CRM lead records via hidden form fields — link pipeline and revenue to the user's original entry point without server-side infrastructure
Compare e_cur_referral_source (this session's referrer) against e_1st_referral_source (first-ever referrer) in GA4 Explorations to identify multi-channel journeys and mid-funnel referral sources
Segment GA4 audiences by u_1st_landing_path to create intent-based audiences (e.g. users whose first landing was /pricing) for remarketing and personalisation
Build BigQuery attribution models joining on e_1st_referral_source to compare first-touch referral attribution against GA4's session-based default attribution
Identify referral traffic where utm_source does not match the actual referHost — a powerful quality signal for your UTM hygiene audits
Measure cohort differences in conversion rate, session depth, and time-to-convert between users by first landing page — enabling landing page optimisation based on downstream outcome data rather than session-level metrics
Use e_1st_landing_path as a dimension in GA4 Explorations funnels to understand which entry points drive users towards high-value conversion paths

The full source — including the container JSON and the drewspen sandboxed Custom Templates — is available on GitHub and via the Google Drive download below. If you extend the implementation with additional cookie naming conventions or add complementary UTM cookie tracks, open a pull request or issue.

⬇ Download GTM Container JSON

UTM & URL Query String 2 Cookies

Kent Spencer — Wed, 24 Jun 2026 02:58:06 +0000

UTM & URL Query String to Cookies in Google Tag Manager — A Complete Recipe Without Custom JavaScript

Persist any URL query string parameter — UTM values, click IDs, or custom campaign codes — into session or long-lived persistent cookies using only GTM sandboxed Custom Templates. No Custom HTML tags. No new CSP hashes.

Published · Tags: GTM, Google Analytics 4, UTM, Cookies, Query String, dataLayer, CSP, GA4, First-Touch Attribution, Lead Attribution

UTM parameters tell you exactly how a visitor arrived at your site. But they only exist in the URL on the landing page. The moment a user navigates to a second page, clicks an internal link, or returns to the site in the same browser session, those parameters vanish from the address bar. If your marketing team needs to know which campaign drove a lead form submission that happened three days after the original visit — a common scenario in B2B with longer consideration cycles — you cannot read the UTMs from the URL. They are gone.

This recipe solves that problem cleanly. On the landing page visit, it reads any nominated URL query string parameter and writes its value into a browser cookie — either a session cookie that expires when the browser closes, or a persistent cookie that survives for up to 730 days. Those cookie values are then available to every subsequent page view and every GTM event throughout the user's future visits, ready to be attached to GA4 events, read by form scripts, or forwarded in dataLayer pushes. No custom JavaScript. No new Content Security Policy SHA-256 hashes required.

⬇ Download the GTM Container JSON from Google Drive

The Core Problem: UTMs Live in the URL, Not in the Session

A visitor lands on https://example.com/?utm_source=newsletter&utm_medium=email&utm_campaign=spring-offer. GA4 picks up those parameters automatically for the page_view event. Three days later, in a fresh browser session, the same visitor returns directly to https://example.com/pricing and submits a lead form. What UTM values does your CRM receive? Without a persistence layer: none. GA4's session attribution helps for analytics, but it does not make the original UTMs available to your form submission handler or marketing automation platform.

Cookies are the browser's built-in persistence mechanism for exactly this purpose. Writing the UTM values to cookies on the first visit and reading them back on the form submission page gives you first-touch attribution data that survives across sessions, browser restarts, and multi-day gaps — without requiring any server-side infrastructure.

Why this matters for CSP: The traditional approach to writing cookies in GTM is a Custom HTML tag containing an inline <script> block. Any such script requires its SHA-256 hash to be listed in your Content-Security-Policy header's script-src directive. Every time the script changes — even whitespace — the hash changes and must be redeployed. This recipe uses only GTM sandboxed Custom Templates, which execute inside GTM's own sandbox and require zero additions to your CSP. The cookie-writing and cookie-rewriting logic runs entirely within the GTM runtime — no new hashes, no security team review cycles.

What's Inside the Container

The exported container (utm-and-url-query-string-2-cookies-recipe.json) is organised into three folders of assets, plus the existing Analytics infrastructure and three sandboxed Custom Templates authored by drewspen.

Folders

Folder	Contains
Analytics	GA4 configuration tag, shared settings variables (including UTM cookie reads), environment/stream routing variables, and client ID and timestamp utilities.
Process URL query strings 2 cookies	Two tags (session and user/persistent), plus ten Cookie Variable variables reading the values back from each cookie. Fires at page load to capture incoming UTM parameters.
Extend Cookie Life	One tag and two supporting variables. Rewrites the persistent UTM cookies on every page visit to refresh their expiry date, ensuring the 730-day window resets on each visit rather than counting from first write.

Tags

Tag	Type	Purpose
`Google Analytics Configuration`	Google Tag (`googtag`)	Standard GA4 config tag, fires once per load. Shared Event Settings automatically forward UTM cookie values as GA4 event parameters on every hit.
`Write certain URL query strings 2 cookies session`	Custom Template — Write URL query strings 2 cookies	Fires on all pages. Reads `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, and `utm_term` from the URL query string and writes each as a session cookie (expires when the browser closes). Cookie names: `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term`.
`Write certain URL query strings 2 cookies user`	Custom Template — Write URL query strings 2 cookies	Fires on all pages (configured with no trigger override — uses the All Pages trigger inherited from the session tag). Reads the same five UTM parameters and writes them as persistent cookies expiring in 730 days (2 years). Cookie names have a `_1` suffix: `utm_source_1`, `utm_medium_1`, `utm_campaign_1`, `utm_content_1`, `utm_term_1`.
`Extend Cookie Life Tag`	Custom Template — Cookie Rewriter	Fires on DOM Ready, but only if it has not already run in the current page load (guarded by the `_arrewr` sentinel cookie). Rewrites all ten persistent UTM cookies — both the `_1` and `_u` variants — resetting their expiry to 720 days from now.

Triggers

Trigger	Type	Purpose
`All Pages` (built-in)	Page View	Fires the two Write query strings tags on every page load so incoming UTM parameters are always captured.
`Extend Cookie Life Trigger`	DOM Ready	Fires the Cookie Rewriter tag, but only when the `_arrewr` sentinel cookie is absent or empty — ensuring the cookie extension runs exactly once per page, not on every DOM mutation.

Custom Templates (by drewspen)

Template	Purpose
`Write URL query strings 2 cookies`	Reads nominated URL query string parameters and writes them to browser cookies, with configurable expiry (session or persistent), cookie name suffix, root domain scoping, and optional URI decoding. Runs entirely within the GTM sandboxed template runtime — no Custom HTML, no CSP implications.
`Cookie Rewriter`	Rewrites a specified list of existing cookies with a refreshed expiry date, allowing persistent cookies to behave as rolling windows that extend on each visit rather than fixed windows from first write.
`If Else If — Advanced Lookup Table` (Sublimetrix)	Powers coalesce and routing logic elsewhere in the container.
`Timestamp` (Sublimetrix)	Reads Unix timestamps from GA4 session and client cookies for shared event parameters.
`Get Root Domain`	Extracts the registrable root domain for cookie scoping, ensuring cookies are accessible across subdomains (e.g. `www.example.com` and `app.example.com`).

Two Tracks: Session Cookies and Persistent Cookies

The recipe deliberately writes each UTM parameter twice — once as a session cookie and once as a persistent cookie. This gives you two distinct attribution windows in a single implementation.

Session Cookies — Current Visit Attribution

Session cookies expire automatically when the browser is closed. They hold the UTM values for the current visit only. This makes them ideal for "last-touch within session" attribution: if a user clicks a paid search ad, lands on the site, navigates through three pages, and completes a transaction, the session cookie carries utm_source=google and utm_medium=cpc all the way through the checkout flow — even though only the landing page URL contained those parameters.

Cookie Name	Type	Content
`utm_source`	Session	Value of `utm_source` query parameter on landing
`utm_medium`	Session	Value of `utm_medium` query parameter on landing
`utm_campaign`	Session	Value of `utm_campaign` query parameter on landing
`utm_content`	Session	Value of `utm_content` query parameter on landing
`utm_term`	Session	Value of `utm_term` query parameter on landing

Persistent Cookies — First-Touch Attribution Across Visits

Persistent cookies survive browser restarts and are retained for up to 730 days (2 years) from initial write. The _1 suffix in the cookie name is the distinguishing convention: these cookies hold the values from the first tracked landing, making them the foundation of first-touch attribution. When the Cookie Rewriter runs on subsequent visits, it refreshes the expiry without overwriting the values — the original campaign data is preserved.

Cookie Name	Type	Expiry	Content
`utm_source_1`	Persistent	730 days (rolling)	Value of `utm_source` on first UTM-tagged landing
`utm_medium_1`	Persistent	730 days (rolling)	Value of `utm_medium` on first UTM-tagged landing
`utm_campaign_1`	Persistent	730 days (rolling)	Value of `utm_campaign` on first UTM-tagged landing
`utm_content_1`	Persistent	730 days (rolling)	Value of `utm_content` on first UTM-tagged landing
`utm_term_1`	Persistent	730 days (rolling)	Value of `utm_term` on first UTM-tagged landing

The _u variants: The Extend Cookie Life Tag also refreshes cookies with a _u suffix (utm_campaign_u, utm_source_u, etc.). These are placeholders for a future-use "last UTM-tagged visit" persistent track — write the user-level tag a second time with a _u suffix to maintain a rolling record of the most recent campaign that drove a visit, distinct from the first-touch _1 values. The extension infrastructure is already in place.

The Rolling Expiry: How the Cookie Rewriter Works

A persistent cookie written once with a 730-day expiry will expire 730 days after it was first written, regardless of how often the user returns. For long sales cycles — a B2B prospect who first visited from a newsletter eleven months ago and finally requests a demo today — a static expiry is often sufficient. But many implementations prefer a rolling expiry: every visit resets the clock, so an active user's attribution never expires.

The Extend Cookie Life Tag achieves this by running the Cookie Rewriter template on every page visit. It reads each of the ten persistent UTM cookies and rewrites them with the same value but a new expiry date set 720 days from the current time. The result is a rolling 720-day window that resets on each visit.

The Sentinel Guard: Firing Exactly Once Per Page

To avoid the Cookie Rewriter firing multiple times per page — once for each DOM Ready event if the page triggers several — the recipe uses a sentinel cookie named _arrewr. The Extend Cookie Life Trigger condition checks this cookie's value against the regex ^(undefined|null|0|false|NaN|)$. The tag fires only when the cookie is absent or empty. The Cookie Rewriter template sets _arrewr on its first run, preventing any subsequent firing within the same page load.

Cookie Variables: Reading the Values Back

Ten Cookie Variable variables are included in the Process URL query strings 2 cookies folder, one for each cookie. These are GTM's built-in First-Party Cookie variable type and require no custom code.

Variable Name	Cookie Read	Track
`utm_source cookie session`	`utm_source`	Current session
`utm_medium cookie session`	`utm_medium`	Current session
`utm_campaign cookie session`	`utm_campaign`	Current session
`utm_content cookie session`	`utm_content`	Current session
`utm_term cookie session`	`utm_term`	Current session
`utm_source cookie user`	`utm_source_1`	First touch (persistent)
`utm_medium cookie user`	`utm_medium_1`	First touch (persistent)
`utm_campaign cookie user`	`utm_campaign_1`	First touch (persistent)
`utm_content cookie user`	`utm_content_1`	First touch (persistent)
`utm_term cookie user`	`utm_term_1`	First touch (persistent)

How UTM Cookies Flow Into Every GA4 Hit

The cookie variable values are wired directly into the Google Tag Shared Event Settings variable. Because this variable is referenced by the Google Analytics Configuration tag, its parameter table is merged into every GA4 event sent by the container — page views, scroll events, clicks, form submissions, and conversions alike. You receive both the current-session UTMs and the first-touch UTMs on every event, without touching individual tag configurations.

Shared Event Settings — UTM Parameters

GA4 Parameter	GTM Variable	Attribution Track
`e_cur_utm_source`	`{{utm_source cookie session}}`	Source from current session's landing page UTMs
`e_cur_utm_medium`	`{{utm_medium cookie session}}`	Medium from current session's landing page UTMs
`e_cur_utm_campaign`	`{{utm_campaign cookie session}}`	Campaign from current session's landing page UTMs
`e_1st_utm_source`	`{{utm_source cookie user}}`	Source from user's first ever UTM-tagged visit
`e_1st_utm_medium`	`{{utm_medium cookie user}}`	Medium from user's first ever UTM-tagged visit
`e_1st_utm_campaign`	`{{utm_campaign cookie user}}`	Campaign from user's first ever UTM-tagged visit

Note on utm_content and utm_term: The five cookies are written for all UTM parameters including utm_content and utm_term, and their cookie variables are available in the container. The Shared Event Settings above are pre-wired for source, medium, and campaign — the most commonly used dimensions. Add e_cur_utm_content, e_cur_utm_term, e_1st_utm_content, and e_1st_utm_term to the Shared Event Settings table if your reporting requires them.

All Available Query String Parameters

The Write URL query strings 2 cookies template supports a wide range of standard and platform-specific click tracking parameters. The container ships with UTM parameters enabled and all click IDs disabled — a sensible default for most implementations. Enable additional parameters by toggling their checkboxes in the tag configuration UI.

Parameter	Default	Platform / Purpose
`utm_source`	✅ Enabled	Standard UTM — traffic source
`utm_medium`	✅ Enabled	Standard UTM — traffic medium
`utm_campaign`	✅ Enabled	Standard UTM — campaign name
`utm_content`	✅ Enabled	Standard UTM — ad content / variant
`utm_term`	✅ Enabled	Standard UTM — keyword
`gclid`	☐ Disabled	Google Ads — auto-tagged click ID
`gad_source`	☐ Disabled	Google Ads — ad source
`gad_campaignid`	☐ Disabled	Google Ads — campaign ID
`gbraid`	☐ Disabled	Google Ads — iOS app conversion
`wbraid`	☐ Disabled	Google Ads — web-to-app conversion
`gclsrc`	☐ Disabled	Google — DoubleClick import source
`dclid`	☐ Disabled	Google Display & Video 360 click ID
`msclkid`	☐ Disabled	Microsoft Advertising click ID
`fbclid`	☐ Disabled	Meta (Facebook/Instagram) click ID
`igshid`	☐ Disabled	Instagram share ID
`ttclid`	☐ Disabled	TikTok click ID
`ttcid`	☐ Disabled	TikTok campaign ID
`twclid`	☐ Disabled	X (Twitter) click ID
`li_fat_id`	☐ Disabled	LinkedIn first-party ad tracking ID
`ScCID` / `ScCid`	☐ Disabled	Snapchat click ID
`rdt_cid`	☐ Disabled	Reddit click ID
`srsltid`	☐ Disabled	Google Shopping — surface result listing ID
`utm_id`	☐ Disabled	UTM campaign ID (GA4 extended)
`utm_source_platform`	☐ Disabled	UTM source platform (GA4 extended)
`utm_marketing_tactic`	☐ Disabled	UTM marketing tactic (GA4 extended)
`utm_creative_format`	☐ Disabled	UTM creative format (GA4 extended)
`epic`	☐ Disabled	Custom campaign / partner click ID
`cid`	☐ Disabled	Custom contact or campaign ID

Architecture: How a Click Becomes a Cookie Becomes a GA4 Parameter

User clicks a UTM-tagged link — e.g. from a newsletter, paid ad, or social post — and lands on your site with query parameters in the URL.
GTM fires on All Pages. The Write certain URL query strings 2 cookies session tag runs immediately. For each enabled parameter, it reads the query string value and writes a session cookie scoped to the root domain (e.g. .example.com).
The user tag also runs. Write certain URL query strings 2 cookies user writes the same values as persistent cookies with the _1 suffix, expiring 730 days from now. If a persistent cookie already exists for a parameter, the existing value is retained — preserving first-touch attribution.
GTM fires DOM Ready. The Extend Cookie Life Trigger checks the _arrewr sentinel. If absent, the Extend Cookie Life Tag runs the Cookie Rewriter against all ten persistent UTM cookies, resetting their expiry to 720 days from now.
Cookie Variable variables are evaluated. On every subsequent GTM event, the ten Cookie Variable variables read the current values from the browser cookies.
Shared Event Settings deliver values to GA4. The six UTM shared event parameters (e_cur_utm_* and e_1st_utm_*) are included in every GA4 hit automatically via the Google Tag Shared Event Settings variable.
Days or weeks later, the user returns. Their persistent cookies still hold the original first-touch UTM values. On this second visit, the same session cookies are overwritten with the new landing page UTMs (or remain blank if this visit has no UTMs). The persistent cookies are extended again by the Cookie Rewriter.
The user submits a form. Your form handler can read the UTM cookies directly from document.cookie, or a separate GTM tag can read the GTM Cookie Variable values and push them into the form's hidden fields or a dataLayer event.

The Real-World Use Case: Lead Attribution Across Days

Consider a B2B software company running LinkedIn campaigns. A prospect clicks an ad on a Monday, lands on a product page, reads a case study, and leaves without converting. The UTM parameters from that Monday click are now stored in persistent cookies: utm_source_1=linkedin, utm_medium_1=paid-social, utm_campaign_1=q2-enterprise-saas.

On Thursday, the prospect types the company URL directly into their browser, reads the pricing page, and submits a contact form. The URL has no UTM parameters. GA4 attributes this session to direct. But your CRM receives the hidden form fields populated from the persistent cookies — and your sales team knows this lead originated from the LinkedIn Q2 enterprise campaign.

This is the gap that UTM-to-cookie bridging fills: GA4 session attribution versus real-world multi-touch, multi-day customer journeys where the conversion rarely happens on the same visit as the first paid impression.

Why Sandboxed Templates Do Not Require New CSP Hashes

GTM's sandboxed Custom Template runtime is granted access to browser APIs through GTM's own internal permission model — not through Content Security Policy. A template that writes a cookie uses GTM's setCookie sandbox API, which executes within code already authorised by the GTM container's existing CSP allowance (the allowance granted to googletagmanager.com or your server-side GTM origin).

In contrast, a Custom HTML tag writes a literal <script> element into the DOM. CSP's script-src directive applies to every inline script element. Unless you have unsafe-inline enabled (which defeats much of CSP's purpose) or a matching SHA-256 hash, the browser will block execution. Every change to that script — adding a comment, reformatting a line — changes the hash and requires a CSP header update.

With sandboxed templates, your CSP never changes when GTM tag logic changes. The entire cookie management implementation in this recipe is CSP-transparent.

How to Import

Download the JSON file from the Google Drive link.
In GTM, go to Admin → Import Container.
Upload utm-and-url-query-string-2-cookies-recipe.json.
Choose Merge (not Overwrite) to preserve your existing tags and triggers.
Update Measurement Stream ID Production and Measurement Stream ID Development constant variables to your actual GA4 Measurement IDs.
Review the enabled query string parameters in both Write tags and toggle on any additional parameters (click IDs, custom fields) that your implementation requires.
Verify that {{Root Domain}} resolves correctly for your site — this controls the cookie's domain scope. Check its value in GTM Preview mode on your site.
In GA4, register e_cur_utm_source, e_cur_utm_medium, e_cur_utm_campaign, e_1st_utm_source, e_1st_utm_medium, and e_1st_utm_campaign as custom event-scoped dimensions under Admin → Custom definitions → Custom dimensions.
Open GTM Preview mode on a URL with UTM parameters (e.g. ?utm_source=test&utm_medium=test&utm_campaign=test) and confirm the cookie variables populate correctly in the Tag Assistant panel.
Navigate to a second page with no UTM parameters and confirm the session and persistent cookie values persist across the navigation.

Cookie consent: Writing persistent cookies that track marketing attribution may require consent under GDPR, CCPA, or equivalent regulations depending on your jurisdiction and how the data is used. Review with your legal team. The recipe writes cookies on the first page view; if you operate a consent-managed site, gate both Write tags behind a consent trigger that only fires after the user has accepted marketing or analytics cookies.

What You Can Do With It

Attach first-touch UTM values to CRM lead records by reading persistent cookies from hidden form fields — connect campaign spend to closed revenue without server-side infrastructure
Compare e_cur_utm_campaign (session UTM) against e_1st_utm_campaign (first-touch UTM) in GA4 Explorations to understand how many conversions involve multi-campaign journeys
Persist platform click IDs (gclid, fbclid, msclkid) by enabling the relevant parameters — forward them to your CRM for enhanced conversions and offline conversion imports
Build BigQuery attribution models that join on e_1st_utm_source to compare first-touch against data-driven attribution without rebuilding your tracking implementation
Extend the cookie name suffix convention (_1 for first touch, _u for last touch) to create a full first/last attribution duality in a single container
Use session UTM cookies to personalise on-site content via GTM variables — show a returning email subscriber a different headline without any server-side personalisation

The full source — including the container JSON, variable inventory, and the drewspen sandboxed Custom Templates — is available on GitHub. If you enable additional query string parameters or extend the cookie naming convention, open a pull request or issue.

⬇ Download GTM Container JSON

GTM Browser Viewport Measurement

Kent Spencer — Wed, 24 Jun 2026 02:31:57 +0000

Browser Viewport Measurement in Google Tag Manager — A Complete Recipe Without Custom JavaScript

Send the user's current browser viewport dimensions as an event-level parameter on every GA4 hit — using only GTM's built-in JavaScript Variable type and a Constant. No Custom HTML tags. No new CSP hashes.

Published · Tags: GTM, Google Analytics 4, Browser Viewport, Window Size, JavaScript Variable, CSP, GA4, Shared Event Settings

How big is the browser window when a user converts? Does your checkout funnel drop off more on narrow viewports than wide ones? These questions sound like they should be answerable from GA4's built-in device category dimension — but device category is derived from the User-Agent string and tells you nothing about how much screen space the browser is actually using. A desktop user with a browser snapped to half-screen is classified as "desktop" even though their experience is closer to a narrow tablet. This recipe measures the actual viewport: the rendered area available to your page at the moment of each event.

Crucially, viewport size is an event-level metric , not a user or session property. A user can resize their browser, rotate their phone, or dock a floating panel at any point during a session. Capturing it at session start misses every mid-session change. Sending it as a shared event parameter on every GA4 hit means you always know the viewport at the exact moment each interaction happened.

⬇ Download the GTM Container JSON from Google Drive

Why Viewport Size Is an Event-Level Metric

It is tempting to record viewport dimensions once — at page load or session start — and treat them as a fixed property for the session. This is wrong for several reasons.

Users resize browser windows during long sessions. Mobile users rotate their devices between portrait and landscape. Tablet users attach and detach keyboards that alter the usable viewport. Users on multi-monitor setups drag the browser between screens with different resolutions. In all these cases, a single session-start capture would reflect the viewport at the wrong moment.

By attaching the viewport to every event via the Shared Event Settings variable, you get the actual viewport at the time of every page view, click, form submission, and conversion. This means you can ask GA4: "Of the users who completed checkout, what was their viewport size at the moment they clicked the buy button?" — not "what was it when they arrived?"

Why this matters for CSP: Measuring viewport dimensions might seem to require a Custom HTML tag or inline <script> block that reads window.innerWidth. That approach would require a new SHA-256 hash in your Content Security Policy every time the script content changed. This recipe avoids all of that: GTM's built-in JavaScript Variable type reads any JavaScript expression from the page context without introducing new CSP requirements. No custom JavaScript. No new CSP hashes.

What's Inside the Container

The exported container (browser-viewport-measurement-recipe.json) adds one new folder of assets to the existing Analytics infrastructure, and wires the result into the shared event settings so every GA4 hit carries the viewport dimension automatically.

Folders

Folder	Contains
Analytics	GA4 configuration tag, shared settings variables, environment/stream routing variables, client ID utilities, and session/timestamp infrastructure — carried over from the base container.
Browser Viewport	Six JavaScript Variable variables reading the three standard width sources and three height sources, plus the `Browser Viewport` Constant that assembles them into a single `WIDTHxHEIGHT` string.

Tags

Tag	Type	Purpose
`Google Analytics Configuration`	Google Tag (`googtag`)	Standard GA4 config tag wired to environment-aware Stream IDs via shared configuration and event settings variables. Fires once per load. The shared event settings variable it references includes `e_browser_viewport`, so every hit from this container carries the viewport string.

Variables Added

Variable	Type	JavaScript Expression
`window.innerWidth`	JavaScript Variable	`window.innerWidth`
`window.innerHeight`	JavaScript Variable	`window.innerHeight`
`document.body.clientWidth`	JavaScript Variable	`document.body.clientWidth`
`document.body.clientHeight`	JavaScript Variable	`document.body.clientHeight`
`document.documentElement.clientWidth`	JavaScript Variable	`document.documentElement.clientWidth`
`document.documentElement.clientHeight`	JavaScript Variable	`document.documentElement.clientHeight`
`Browser Viewport`	Constant	`{{window.innerWidth}}x{{window.innerHeight}}`

The Three Viewport Width Sources — and Why We Expose All Three

There is no single universally correct way to read browser viewport width in JavaScript. Three properties exist, each returning subtly different values depending on the browser engine, the presence of scrollbars, zoom level, and whether the page has a CSS viewport meta tag. This recipe exposes all three so you can compare them across your traffic.

`window.innerWidth` / `window.innerHeight`

The CSS viewport size — the space available to the page's layout after browser chrome (toolbar, address bar, tabs) is excluded. On most desktop browsers this includes the scrollbar width, so it may be slightly larger than the usable content area. This is the value most commonly recommended for responsive design breakpoint analysis because it matches what CSS @media queries see.

`document.documentElement.clientWidth` / `clientHeight`

The width of the <html> element's content box. Scrollbars are excluded, so this is typically a few pixels narrower than window.innerWidth on desktop when a vertical scrollbar is visible. On mobile, where scrollbars overlay the content rather than displacing it, the two values converge. This is often the most accurate proxy for "how wide is the content area the user actually sees."

`document.body.clientWidth` / `clientHeight`

The width of the <body> element's content box. This can differ from documentElement.clientWidth if the body has margins, padding, or an explicit width set in CSS. On pages with a centred fixed-width layout, body.clientWidth may be narrower than the viewport. Less reliable for breakpoint analysis, but useful as a diagnostic comparison when values diverge unexpectedly.

Which one to use in GA4 reports? The Browser Viewport Constant uses window.innerWidth and window.innerHeight because they most closely match the breakpoints your CSS framework responds to. The other four variables are available in GTM Preview for diagnostic comparison; you can promote any of them to a GA4 parameter if you have a specific reason to prefer a different source.

The Browser Viewport Constant: Assembling the String

The seven variables above are designed as building blocks. The Browser Viewport Constant ties them together into a single dimension value:

{{window.innerWidth}}x{{window.innerHeight}}

This produces strings like 1440x900, 390x844, or 1024x768 — a format familiar from screen resolution reporting and directly usable as a GA4 custom dimension value. The lowercase x separator is intentional: it avoids confusion with multiplication operators and is the conventional format used by analytics platforms and browser developer tools.

The Constant type was chosen deliberately over a more complex variable type. A Constant re-evaluates its template expression references at the time each event fires — it does not cache the value at page load. This means that if a user resizes their browser between a page view and a click event, the click event captures the resized viewport, not the original one. This is exactly the event-level behaviour described in the opening section.

How It Plugs Into Every GA4 Hit: Shared Event Settings

Rather than adding e_browser_viewport to every individual tag's event parameter table, the recipe wires {{Browser Viewport}} into the Google Tag Shared Event Settings variable. This variable is referenced by the Google Analytics Configuration tag, which means its parameter table is merged into every GA4 event sent by the container — page views, scroll events, click events, custom events, and conversions alike.

Shared Event Settings Parameters (full list)

GA4 Parameter	GTM Variable	Description
`container_id`	`{{GTM Container ID}}`	The GTM container public ID (e.g. `GTM-XXXXXX`). Useful for filtering in BigQuery when multiple containers write to the same GA4 property.
`environment_name`	`{{GTM Environment Name}}`	The GTM Environment label (live, staging, development) when GTM Environments are in use.
`stream_id`	`{{Measurement Stream RegEx Lookup}}`	The GA4 Measurement ID that received this event, after environment routing. Confirms which stream a hit was routed to.
`e_session_id`	`{{Browser Session ID RegEx Table}}`	GA4 session ID extracted from the `_ga_XXXXX` cookie. Makes session-level joins in BigQuery straightforward.
`e_client_id`	`{{Browser Client ID Append Underscore}}`	GA4 client ID with trailing underscore to force BigQuery string typing and avoid float precision loss.
`e_1st_session_ts`	`{{Timestamp Session Start}}`	Unix timestamp of the start of the current session, from the GA4 session cookie.
`e_cur_session_ts`	`{{Timestamp Current}}`	Unix timestamp at the moment the event fired.
`e_1st_user_ts`	`{{Timestamp First User}}`	Unix timestamp of the user's first ever session, from the GA4 client ID cookie.
`page_title`	`{{Page Title}}`	The `document.title` value at event time.
`e_browser_viewport`	`{{Browser Viewport}}`	The viewport string — e.g. `1440x900` — captured at the moment this event fired.

Event-level, not session-level: Because e_browser_viewport is sent with every event via shared event settings, it reflects the viewport at event time, not at session start. A session where the user rotates their phone mid-way through will show the correct viewport for each individual event.

Why JavaScript Variable Type Does Not Require New CSP Hashes

Content Security Policy's script-src directive controls which JavaScript is permitted to execute. Custom HTML tags in GTM that contain <script> blocks with inline code must be covered by a SHA-256 hash of the script content (or an unsafe-inline allowance, which defeats CSP's purpose). Every time the script text changes — even by one character — the hash changes and must be updated in the CSP header.

GTM's JavaScript Variable type works differently. It evaluates a JavaScript expression inside GTM's own sandboxed runtime, which runs under the existing permission granted to the GTM container snippet. No new <script> tags are injected into the DOM. The expression window.innerWidth is read directly from the page's window object at variable evaluation time, inside code that is already covered by the GTM container's own CSP allowance.

The practical result: you can add, modify, or remove JavaScript Variable variables in GTM as many times as you like, and your CSP never needs updating. This is a significant operational advantage for organisations that maintain strict CSPs and require security team review for any hash change.

How to Import

Download the JSON file from the Google Drive link.
In GTM, go to Admin → Import Container.
Upload browser-viewport-measurement-recipe.json.
Choose Merge (not Overwrite) to preserve your existing tags and triggers.
Update Measurement Stream ID Production and Measurement Stream ID Development constant variables to your actual GA4 Measurement IDs.
Review the Measurement Stream RegEx Lookup variable and adjust hostname patterns to match your non-production environments.
In GA4, register e_browser_viewport as a custom event-scoped dimension under Admin → Custom definitions → Custom dimensions.
Open GTM Preview mode, interact with your site, and verify that the e_browser_viewport parameter appears on every event in the Tag Assistant panel before publishing.

Custom dimension registration: GA4 does not automatically expose new event parameters as dimensions in reports or Explorations. You must register e_browser_viewport as a custom event-scoped dimension in GA4 Admin before it becomes available for filtering, segmenting, or use in Funnel Explorations. Registration takes up to 24 hours to propagate into the GA4 interface, but the data is collected immediately once the container is published.

What You Can Do With It

Compare conversion rates across viewport size buckets — identify whether narrow viewports underperform wide ones on specific funnel steps, independent of device category
Detect mid-session viewport changes: a session where early events show 1440x900 and later events show 720x900 indicates a window resize, not a device switch
Validate responsive design breakpoints against real user data — see the actual distribution of viewport widths hitting each breakpoint boundary in your traffic
Correlate viewport size with scroll depth, time on page, or click-through rate to understand how layout affects engagement at different viewport widths
Use e_browser_viewport as a secondary dimension in GA4 Explorations to understand whether a high-exit page affects wide viewports, narrow viewports, or both equally
Filter BigQuery exports by e_browser_viewport to build custom viewport-aware cohort analyses without touching the raw User-Agent string

Attribution

The three-source approach to reading viewport dimensions — using window.innerWidth, document.documentElement.clientWidth, and document.body.clientWidth in parallel — is based on a solution by Matthew Edgar. The implementation here adapts that approach to GTM's built-in JavaScript Variable type and wires it into the Shared Event Settings pattern so it propagates automatically to all GA4 events without Custom HTML tags or CSP implications.

The full source — including the container JSON and variable inventory — is available on GitHub. If you adapt the viewport string format or add additional measurement sources, open a pull request or issue.

⬇ Download GTM Container JSON

GTM / GA Page Count Measurement

Kent Spencer — Mon, 22 Jun 2026 16:19:23 +0000

Page View Counter in GA4 via GTM — Session & User-Level Counting Without CSP SHA-256

Count how many pages a visitor has seen — within a session or across multiple visits — using GTM Custom Templates that write cookies and push events to the dataLayer, with no inline JavaScript and no Content Security Policy headaches.

Published · Tags: GTM, Google Analytics 4, Page View Counter, Cookies, dataLayer, Custom Event Trigger, CSP, SPA, History Change

Note: This GTM container recipe is designed to work on Google Blogger / Blogspot as well as AEM, Sitecore, WordPress, React.js, and other platforms. A key design decision — using the page hostname instead of a computed root domain — is documented where it matters. The JSON can be downloaded from Google Drive below.

Knowing how many pages a visitor has viewed — either within the current browser session or accumulated over multiple visits — opens up powerful segmentation and trigger logic in GA4. You can fire different tags on a visitor's first page versus their fifth, suppress introductory banners for returning heavy readers, or use the count as a GA4 custom dimension to analyse depth-of-engagement cohorts.

The challenge is doing this cleanly inside GTM. The obvious approach — a Custom HTML tag with inline JavaScript — collides with Content Security Policy on sites that require script-src 'nonce-...' or explicit SHA-256 hashes. Every time you edit the script, the hash changes and you have to update your CSP headers. This recipe solves that by using GTM Sandboxed JavaScript Custom Templates instead. Template code runs inside GTM's sandbox and is not subject to CSP SHA-256 requirements — the container itself is already allowed by the www.googletagmanager.com script-src entry your site already needs.

Pageview counts are persisted in two cookies and simultaneously pushed into the dataLayer as custom events , making the counters available both as GTM variables (readable on any subsequent tag) and as custom event triggers (fire a tag on the Nth pageview).

⬇ Download the GTM Container JSON from Google Drive

What's Inside the Container

The exported container (pageview-count-measurement-recipe.json) is organised into four folders, four tags, two triggers, and a set of variables covering cookie names, cookie values, environment/stream routing, timestamps, and history-change helpers. Three community Custom Templates round out the package: Page View Counter, Cookie Rewriter, and three previously-imported utilities (If Else If, Timestamp, Get Root Domain).

Folders

Folder	Contains
Analytics	GA4 configuration tag, shared event-settings variable, environment/stream routing variables, Browser Client ID, Root Domain, session-start and first-user timestamp utilities.
Page View Counter	The two counter tags (User and Session), their cookie-name constants, and the cookie-value variables that surface the counts to other tags.
History Change	Variables for `gtm.oldUrl`, `gtm.newUrl`, and a Simple Lookup that resolves whether the new URL differs from the old one — used to fire the counter accurately on SPA navigation.
Extend Cookie Life	The Cookie Rewriter tag and its trigger, session-guard cookie name/value pair, and the Extend Cookie Life Trigger that runs once per session to refresh persistent cookie expiry dates.

Tags

Tag	Type	Fires On	Purpose
`Google Analytics Configuration`	Google Tag (`googtag`)	All Pages (built-in)	Standard GA4 config tag. Uses the Measurement Stream RegEx Lookup variable for environment-aware stream routing and the Google Tag Shared Event Settings to append counter values and timestamps to every event.
`Page View Counter - User`	Custom Template (Page View Counter)	All Pages + History Change	Reads the _i_mpvcnt persistent cookie, increments it by 1, writes it back with a 720-day max-age, and pushes a dataLayer event named `_i_mpvcnt` with the new count in `pageViewCounter`.
`Page View Counter - Session`	Custom Template (Page View Counter)	All Pages + History Change	Same logic but uses the _i_spvcnt session cookie (no max-age). Resets automatically when the browser session ends. Pushes a dataLayer event named `_i_spvcnt`.
`Extend Cookie Life Tag`	Custom Template (Cookie Rewriter)	DOM Ready (once per session)	On the first page of each browser session, rewrites the _i_mpvcnt persistent cookie with its current value and a fresh 720-day expiry. Sets a session-guard cookie _arrewr to prevent running again in the same session.

Triggers

Trigger	Type	Conditions
`Page View Counter History Change`	History Change	History Source equals `pushState` AND Updated History URL equals `true` AND New History URL does not match `^(undefined
{% raw %}`Extend Cookie Life Trigger`	DOM Ready	Fires when Extend Cookie Life Already Ran Cookie Value matches `^(undefined

The Page View Counter Template: How It Works

The Page View Counter Custom Template is a Sandboxed JavaScript tag that uses only GTM's built-in sandboxed APIs — {% raw %}getCookieValues, setCookie, and createQueue('dataLayer'). Because it is a Template (not a Custom HTML tag), it does not inject any inline <script> element into the page and therefore does not require a CSP SHA-256 hash.

// Page View Counter — Sandboxed JS (inside GTM Custom Template)
const getCookieValues = require('getCookieValues');
const setCookie = require('setCookie');
const createQueue = require('createQueue');
const dataLayerPush = createQueue('dataLayer');

const cookieName = data.pageViewCounterName || 'pv_cntr';

// Build cookie options: persistent cookie uses max-age, session cookie omits it
const cookieOptions = data.cookieDuration === 'persistentCookie'
  ? { domain: data.rootDomain, path: '/',
      'max-age': 60 * 60 * 24 * (data.persistentCookieExpires - 0) }
  : { domain: data.rootDomain, path: '/' };

// Read current count (default 0 if cookie absent)
const cookieValue = getCookieValues(cookieName);
const existingValue = cookieValue.length > 0 ? cookieValue[0] : null;
const currentCount = existingValue !== null ? (existingValue - 0) : 0;
const newCount = currentCount + 1;

// Persist the incremented count
setCookie(cookieName, newCount + '', cookieOptions);

// Push to dataLayer so the count is available as a custom event trigger
// and as a dataLayer variable in any subsequent tag
dataLayerPush({
  event: cookieName, // e.g. '_i_mpvcnt' — usable as a GTM custom event trigger
  pageViewCounter: newCount
});

data.gtmOnSuccess();

Dual persistence — cookie AND dataLayer event: Writing the count to both a cookie and a dataLayer event is intentional. The cookie lets any subsequent tag (or future page) read the accumulated total via a GTM First-Party Cookie variable. The dataLayer push makes the count available as a Custom Event trigger condition — for example, fire a specific tag only when pageViewCounter equals 3 (the visitor's third page in this session).

Session-Level vs User-Level Counting

The template is instantiated twice, with a single parameter difference that changes its persistence behaviour entirely:

Tag	Cookie Name	Cookie Type	Expiry	Measures
`Page View Counter - User`	_i_mpvcnt	Persistent	720 days from last write	Total pages viewed across all sessions within 720 days (multi-visit / user-level depth)
`Page View Counter - Session`	_i_spvcnt	Session	Browser session end	Pages viewed in the current browser session only (resets on next visit)

Both counts flow into GA4 as event parameters via the Google Tag Shared Event Settings variable, where they are mapped to e_cur_session_pv (session counter) and e_cur_multi_pv (user/persistent counter). Register these as custom dimensions in GA4 to use them in Explorations and Audiences.

Using the Counter as a GTM Custom Event Trigger

Because the template pushes { event: '_i_mpvcnt', pageViewCounter: N } to the dataLayer, you can create a GTM Custom Event trigger that listens for _i_mpvcnt and adds a condition on the dataLayer variable pageViewCounter. For example:

Fire a "Welcome back" popup — Custom Event: _i_mpvcnt with condition pageViewCounter equals 5
Show a newsletter prompt on the second page of a session — Custom Event: _i_spvcnt with condition pageViewCounter equals 2
Suppress an introductory banner for returning heavy users — Custom Event: _i_mpvcnt with condition pageViewCounter greater than 10

Extending Cookie Life Without Re-Counting

A persistent cookie with a fixed expiry silently shrinks: a cookie written with a 720-day max-age on day one has only 700 days remaining by day 20. Without intervention, active users lose their accumulated count on a fixed schedule.

The Extend Cookie Life Tag (using the Cookie Rewriter Custom Template) solves this by rewriting the _i_mpvcnt cookie with its current value and a fresh 720-day max-age once per browser session. A session-guard cookie (_arrewr) prevents the tag from running more than once per session regardless of how many pages load.

// Cookie Rewriter — Sandboxed JS (inside GTM Custom Template)
// Runs once per session to refresh persistent cookie expiry

const SESSION_GUARD = data.SESSION_GUARD || '_arrewr';
const guardValues = getCookieValues(SESSION_GUARD);

if (guardValues && guardValues.length > 0 && guardValues[0] === '1') {
  data.gtmOnSuccess(); // Already ran this session — exit immediately
  return;
}

const maxAgeSeconds = makeString(durationDays * 24 * 60 * 60);

for (var i = 0; i < cookieList.length; i++) {
  var name = cookieList[i].cookieName;
  var values = getCookieValues(name);
  if (values && values.length > 0 && values[0] !== '') {
    setCookie(name, values[0], {
      domain: rootDomain, path: '/', 'max-age': maxAgeSeconds,
      samesite: 'Lax', secure: true
    });
  }
}

// Set session guard so this tag is skipped for the rest of the session
setCookie(SESSION_GUARD, '1', { domain: rootDomain, path: '/', samesite: 'Lax', secure: true });

SPA Support via History Change Trigger

Single-page applications (React, Vue, Angular) update the URL via the History API without triggering a full page reload. The standard GTM All Pages (pageview) trigger does not fire on these navigations. The Page View Counter History Change trigger fills this gap:

It listens for GTM's built-in gtm.historyChange event.
It filters to pushState changes only (not replaceState or back-button hash changes that don't actually navigate to a new page).
It verifies the new URL is genuinely different from the old URL before firing.

Both counter tags fire on All Pages AND this History Change trigger , so they accumulate correctly whether the site is a traditional multi-page site or a SPA.

The Root Domain Decision for Google Blogger

Google Blogger / Blogspot note: Most GTM setups write cross-domain cookies to the root domain (e.g. .example.com) using a "Get Root Domain" template so that cookies are shared across subdomains. On Blogger/Blogspot, this approach produces .blogspot.com as the root domain — which scopes the cookie to every Blogspot site on the internet, not just yours. Using .blogger.com would require hard-coding a platform-specific value. This recipe therefore sets {{Root Domain}} to the page URL hostname (e.g. yourblog.blogspot.com) rather than the computed root domain. The cookie is scoped to your specific blog. The variable is lowercased and has "strip www" enabled. On non-Blogger platforms (AEM, WordPress, React.js) the same variable continues to work correctly — it just scopes to the full hostname instead of the root domain.

Environment-Aware Stream Routing

Like the other recipes in this series, the container automatically routes hits to the correct GA4 property:

Measurement Stream RegEx Lookup checks {{Page URL}}. Non-production hostname patterns match {{Measurement Stream ID Development}} (placeholder: G-ZZZZZZZZ).
Environment Stream ID checks GTM's {{Environment Name}} built-in: live environments match ^liv.*; pre-production matches ^(pre|de|st|ua|qa|te).*. The default falls through to {{Measurement Stream ID Production}} (placeholder: G-AAAAAAAA).

Update the two Constant variables (Measurement Stream ID Production and Measurement Stream ID Development) with your real GA4 Measurement IDs before publishing.

Shared Event Settings and GA4 Custom Dimensions

The Google Tag Shared Event Settings variable appends the following parameters to every GA4 event fired by this container:

Event Parameter	Source Variable	Description
`e_cur_session_pv`	Page View Counter - Session - Cookie Value	Pages viewed in current session
`e_cur_multi_pv`	Page View Counter - User - Cookie Value	Total pages viewed across sessions
`e_client_id`	Browser Client ID (with appended underscore)	GA4 client identifier
`e_session_id`	Browser Session ID RegEx Table	GA4 session identifier
`e_1st_session_ts`	Timestamp Session Start	First session timestamp (ms)
`e_cur_session_ts`	Timestamp Current	Current timestamp (ms)
`e_1st_user_ts`	Timestamp First User	First-ever user timestamp (ms)
`page_title`	Page Title (document.title)	Page title at event time
`container_id`	GTM Container ID	GTM container for debugging
`environment_name`	GTM Environment Name	Live / preview environment label
`stream_id`	Measurement Stream RegEx Lookup	Active GA4 stream ID

To use the page-view counters in GA4 Explorations and Audiences, register e_cur_session_pv and e_cur_multi_pv as Custom Dimensions (Event scope) in GA4 → Admin → Custom definitions → Custom dimensions.

Community Custom Templates Used

Template	Author	Purpose
`Page View Counter`	drewspen (this recipe)	Increments a cookie counter and pushes a dataLayer event on each page view.
`Cookie Rewriter`	drewspen (this recipe)	Refreshes persistent cookie expiry once per session without modifying the value.
`If Else If – Advanced Lookup Table`	sublimetrix	Multi-condition lookup table for timestamp and session-ID extraction.
`Timestamp`	luratic	Returns current time in milliseconds since epoch.
`Get Root Domain`	mbaersch	Extracts root domain from hostname or URL (used for the Root Domain - Old variable; the active `Root Domain` variable uses the hostname directly for Blogger compatibility).

No CSP SHA-256 required: All counter logic lives in GTM Sandboxed JavaScript Custom Templates. Template code is not injected as an inline script — it runs inside GTM's own sandboxed execution environment, which is already covered by your existing script-src https://www.googletagmanager.com CSP directive. You never need to compute or update an inline-script hash when the counter logic changes.

How to Import

Download the JSON from the Google Drive link above.
In GTM, go to Admin → Import Container.
Upload pageview-count-measurement-recipe.json.
Choose Merge (not Overwrite) to preserve your existing container setup.
Update the Measurement Stream ID Production Constant variable to your live GA4 Measurement ID.
Update Measurement Stream ID Development for your dev/staging GA4 property.
Verify consent settings: both counter tags are set to require analytics_storage; the Cookie Rewriter requires both analytics_storage and functionality_storage. Adjust to match your CMP setup.
Open GTM Preview mode and load a page. Confirm the Page View Counter - User and Page View Counter - Session tags fire and that the browser cookies _i_mpvcnt and _i_spvcnt are set.
Navigate to a second page (or trigger a pushState navigation on a SPA). Confirm both counters increment correctly.
In GA4, create custom dimensions for e_cur_session_pv and e_cur_multi_pv (event scope) to surface the counters in Explorations.

Blogger / Blogspot users: The Root Domain variable is already configured to use the page hostname. No changes needed. However, confirm that your GTM container snippet is installed correctly in your Blogger theme — go to Theme → Edit HTML and verify both the <head> and <body> GTM snippets are present.

The full source — container JSON and documentation — is also published on GitHub. If you adapt the cookie naming scheme, add additional counters (e.g. a "pages viewed this week" counter with a 7-day cookie), or extend the Extend Cookie Life template to rewrite additional cookies, open a pull request or issue.

⬇ Download GTM Container JSON

GA4 Page Performance - Bring Back Site Speed

Kent Spencer — Mon, 22 Jun 2026 16:16:12 +0000

Page Performance Timing in GA4 via GTM — Bringing Back Site Speed Without Universal Analytics

Send eight browser performance timing metrics to Google Analytics 4 on every sampled page load, using GTM's Window Loaded trigger, a Custom HTML timing script, and a custom event — no additional tools required.

Published · Tags: GTM, Google Analytics 4, Performance Timing, Navigation Timing API, Site Speed, dataLayer, Custom Metrics, BigQuery

Original concept and code: This recipe is a rewrite and GTM container implementation of the performance timing approach originally published by David Vallejo (@thyngster) at thyngster.com — Performance Timing tracking with Google Analytics 4 (July 2022). David's article remains the authoritative reference for the original technique, the sampling logic, and the GA4 custom metric definitions. This post documents a ready-to-import GTM container that packages his approach into a deployable recipe.

One of the most frequently missed features after migrating from Universal Analytics to GA4 is the Site Speed report. UA tracked eight browser timing metrics out of the box — page load time, DNS lookup, server response, and more — and surfaced them in a dedicated report. GA4 ships with none of this by default.

The good news is that the browser's window.performance.timing API (part of the Navigation Timing Level 1 specification) is still available in every modern browser, and GTM's Window Loaded trigger fires at exactly the right moment to read it. This recipe collects all eight timing metrics, pushes them to the dataLayer, guards against negative or zero values that indicate a timing anomaly, applies the same client-ID-based sampling logic that Universal Analytics used, and sends a clean page_performance event to GA4 with four parameters that you register as custom millisecond metrics.

⬇ Download the GTM Container JSON from Google Drive

What's Inside the Container

The exported container (page-performance-measurement-recipe.json) is organised into two folders, three tags, two triggers, twenty-five variables, and three community Custom Templates.

Folders

Folder	Contains
Analytics	GA4 configuration tag, shared settings variables, environment/stream routing, Browser Client ID, session and timestamp utilities, Root Domain helper.
Page Performance	The Custom HTML timing tag, the GA4 send event tag, the custom event trigger, and the four dataLayer variables that bridge the timing push to the GA4 tag.

Tags

Tag	Type	Fires On	Purpose
`Google Analytics Configuration`	Google Tag (`googtag`)	All Pages (built-in)	Standard GA4 config tag with environment-aware stream ID routing.
`Page Performance`	Custom HTML	Window Loaded	Reads `window.performance.timing`, applies sampling, performs sanity checks, and pushes a `performance_timing` custom event to the dataLayer.
`Page Performance Send Event`	GA4 Event (`gaawe`)	Page Performance Send Event Trigger (custom event)	Listens for the `performance_timing` dataLayer event and forwards four timing metrics to GA4 as a `page_performance` event with millisecond parameters.

Triggers

Trigger	Type	Conditions
`Window Loaded`	Window Loaded	No additional filter. Fires after all resources on the page have finished loading — the correct moment to read `loadEventStart` from the timing API.
`Page Performance Send Event Trigger`	Custom Event	Event name equals `performance_timing` AND all four metrics match `^[1-9][0-9].*` — meaning each value must be at least 10 ms. This prevents the GA4 tag from firing when the timing script ran but produced zero or sub-10 ms values, which typically indicate cached or pre-rendered pages where timing data is unreliable.

The Timing Script: How It Works

The Page Performance Custom HTML tag contains a self-executing function that runs at Window Load. Here is the full script with commentary:

<script>
// Performance Timing GTM Custom HTML Javascript Tag
// Rewrite by Claude.ai of https://www.thyngster.com/performance-timing-tracking-with-google-analytics-4

(function() {
  var siteSpeedSampleRate = 100; // 100 = measure every visitor; lower to reduce volume
  var gaCookieName = '_ga';
  var dataLayerName = 'dataLayer';

  // ── Sampling ──────────────────────────────────────────────────────
  // Replicates Universal Analytics' siteSpeedSampleRate logic.
  // Hashes the GA client ID and checks whether it falls within the
  // sample bucket. Deterministic: the same visitor is always in or
  // always out for a given rate.
  var hashId = function(a) {
    var b = 1, c;
    if (a) {
      for (b = 0, c = a.length - 1; 0 <= c; c--) {
        var d = a.charCodeAt(c);
        b = (b << 6 & 268435455) + d + (d << 14);
        d = b & 266338304;
        b = d ? b ^ d >> 21 : b;
      }
    }
    return b;
  };

  var rate = siteSpeedSampleRate > 100 ? 100 : siteSpeedSampleRate < 1 ? 1 : siteSpeedSampleRate;
  var cookieMatch = ('; ' + document.cookie).split('; ' + gaCookieName + '=').pop()
                     .split(';').shift().split(/GA\d\.\d\./);
  var clientId = cookieMatch.length > 1 ? cookieMatch[1] : null;

  if (!clientId || hashId(clientId) % 100 >= rate) return; // not in sample — exit

  // ── Timing API ────────────────────────────────────────────────────
  var pt = (window.performance || window.webkitPerformance);
  pt = pt && pt.timing;

  if (!pt || !pt.navigationStart || !pt.loadEventStart) return; // API unavailable or page not fully loaded

  var ns = pt.navigationStart;
  var timingData = {
    page_load_time: pt.loadEventStart - ns, // total time to loadEventStart
    page_download_time: pt.responseEnd - pt.responseStart, // bytes transfer time
    dns_time: pt.domainLookupEnd - pt.domainLookupStart,
    redirect_response_time: pt.fetchStart - ns, // redirect overhead
    server_response_time: pt.responseStart - pt.requestStart,
    tcp_connect_time: pt.connectEnd - pt.connectStart,
    dom_interactive_time: pt.domInteractive - ns, // time to DOM ready
    content_load_time: pt.domContentLoadedEventStart - ns // time to DOMContentLoaded
  };

  // ── Sanity check: abort if any metric is negative ─────────────────
  // Negative values occur when the timing API is partially reset (e.g.
  // bfcache navigations, some SPAs). Sending negative milliseconds to
  // GA4 would corrupt metric averages.
  for (var key in timingData) {
    if (timingData[key] < 0) return;
  }

  // ── Push to dataLayer ─────────────────────────────────────────────
  var dl = window[dataLayerName];
  if (dl) dl.push({ event: 'performance_timing', timing: timingData });

}());
</script>

Window Loaded vs DOM Ready: The script fires on GTM's Window Loaded trigger (equivalent to the browser's window.onload event) because pt.loadEventStart is only populated after the load event has fired. Using DOM Ready would cause loadEventStart to read as 0, making the sanity check !pt.loadEventStart bail out immediately.

Sampling: Replicating Universal Analytics' siteSpeedSampleRate

Universal Analytics sampled site speed hits using a deterministic hash of the client ID so that the same visitor was consistently included or excluded — avoiding session-level inconsistency where a user's first page was sampled but their second was not. This recipe replicates that exact logic.

The hashId() function produces an integer from the client ID string. The result modulo 100 gives a value in the range 0–99. If that value is less than siteSpeedSampleRate, the visitor is in the sample and the timing data is collected. At a rate of 100 (the default in this container), every visitor is included. At a rate of 10, approximately 10% of visitors are measured.

The cookie parsing uses a regex compatible with both GA1.2. and GA4.2. style client ID prefixes (the original Thyngster script used a GA1.[0-9]\. pattern; this rewrite generalises to GA\d\.\d\. to accommodate multi-domain tagging configurations that produce different domain depth prefixes).

Adjust the sample rate for high-traffic sites: At siteSpeedSampleRate = 100 every page load sends a page_performance event. On GA4 free properties, which have a 1,000 events-per-session cap before sampling, this adds one event to every session. For sites with very high page-view volume consider setting the rate to 10–50. The trade-off is wider confidence intervals on average timing metrics in GA4 Explorations and BigQuery.

The dataLayer Push

When sampling and sanity checks pass, the script pushes this object to the dataLayer:

{
  event: 'performance_timing',
  timing: {
    page_load_time: 131, // ms from navigationStart to loadEventStart
    page_download_time: 0, // ms to transfer response bytes
    dns_time: 0, // ms for DNS resolution
    redirect_response_time: 1, // ms of redirect overhead
    server_response_time: 34, // ms from request sent to first byte
    tcp_connect_time: 0, // ms to establish TCP connection
    dom_interactive_time: 63, // ms to DOM interactive
    content_load_time: 63 // ms to DOMContentLoaded
  }
}

All eight metrics are present in the push, but only four are forwarded to GA4 in this recipe. The four dataLayer variables read from the timing.* path and are filtered by the send event trigger before any hit leaves the browser.

The Four dataLayer Variables

GTM Variable	dataLayer Path	GA4 Parameter Name
`Page Performance dataLayer page_load_time`	`timing.page_load_time`	`e_pageload_ms`
`Page Performance dataLayer content_load_time`	`timing.content_load_time`	`e_windowload_ms`
`Page Performance dataLayer page_download_time`	`timing.page_download_time`	`e_initialization_ms`
`Page Performance dataLayer dom_interactive_time`	`timing.dom_interactive_time`	`e_domready_ms`

Why only four parameters? GA4's free tier allows up to 50 custom event parameters per event, but registering custom metric definitions in the GA4 property UI takes deliberate effort and namespace. The four parameters selected — page load, DOMContentLoaded, DOM interactive, and page download — cover the metrics most directly equivalent to the UA Site Speed report's headline figures. The remaining four (dns_time, redirect_response_time, server_response_time, tcp_connect_time) are available in the dataLayer push and can be added to additional GTM variables and GA4 parameters without changing the script.

The Send Event Trigger: Double-Gating on Data Quality

The Page Performance Send Event Trigger applies a second layer of data quality filtering beyond the script's own sanity check. In addition to matching the custom event name performance_timing, it requires that all four forwarded metrics match the regex ^[1-9][0-9].*:

The pattern requires the value to start with a non-zero digit followed by at least one more digit — meaning the metric must be ≥ 10 ms.
Metrics of 0–9 ms are excluded. Single-digit values can arise from cached resources, service worker interceptions, or HTTP/2 push where timing boundaries collapse to near-zero. These readings are real but skew average metrics significantly when mixed with genuine navigation timings, and are excluded here for analytical cleanliness.
All four parameters must pass simultaneously. If any one of the four key metrics is below 10 ms, the entire event is suppressed.

GA4 Event Parameters Sent

GA4 Parameter	Source Variable	Measures
e_initialization_ms	`{{Page Performance dataLayer page_download_time}}`	Time in ms to transfer the response body bytes (`responseEnd − responseStart`)
e_pageload_ms	`{{Page Performance dataLayer page_load_time}}`	Total time in ms from navigation start to `loadEventStart` — the closest equivalent to UA's Page Load Time metric
e_domready_ms	`{{Page Performance dataLayer dom_interactive_time}}`	Time in ms from navigation start to the DOM becoming interactive (`domInteractive − navigationStart`)
e_windowload_ms	`{{Page Performance dataLayer content_load_time}}`	Time in ms from navigation start to `DOMContentLoaded` firing (`domContentLoadedEventStart − navigationStart`)

All Eight Timing Metrics Available in the dataLayer

The script computes and pushes all eight metrics even though only four are currently forwarded to GA4. The full set mirrors the metrics David Vallejo documented in the original Thyngster article:

Metric Key	Timing API Calculation	UA Equivalent
`page_load_time`	`loadEventStart − navigationStart`	Page Load Time
`page_download_time`	`responseEnd − responseStart`	Page Download Time
`dns_time`	`domainLookupEnd − domainLookupStart`	Domain Lookup Time
`redirect_response_time`	`fetchStart − navigationStart`	Redirection Time
`server_response_time`	`responseStart − requestStart`	Server Response Time
`tcp_connect_time`	`connectEnd − connectStart`	Server Connection Time
`dom_interactive_time`	`domInteractive − navigationStart`	Document Interactive Time
`content_load_time`	`domContentLoadedEventStart − navigationStart`	Document Content Loaded Time

Registering GA4 Custom Metrics

Sending event parameters to GA4 does not automatically make them available in reports. You must register each parameter as a custom metric in the GA4 property with event scope and Milliseconds as the unit of measurement. This allows GA4 Explorations and the standard reports to compute averages correctly.

In GA4, go to Admin → Custom definitions → Custom metrics and create:

Metric Name (suggested)	Scope	Unit	Event Parameter
Page Load Time	Event	Milliseconds	`e_pageload_ms`
DOM Ready Time	Event	Milliseconds	`e_domready_ms`
Window Load Time	Event	Milliseconds	`e_windowload_ms`
Initialization Time	Event	Milliseconds	`e_initialization_ms`

If you choose to add the remaining four timing metrics from the dataLayer push, add additional GTM variables for timing.dns_time, timing.redirect_response_time, timing.server_response_time, and timing.tcp_connect_time, wire them into the GA4 event tag, and register them as custom metrics with millisecond units in GA4.

Querying the Data in BigQuery

Once GA4 is linked to BigQuery, performance data becomes available for flexible querying. As David Vallejo showed in the original article, you can identify slow pages directly:

-- Pages where page load exceeded 1 second
SELECT
  event_date,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page,
  (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'e_pageload_ms') AS page_load_ms
FROM `your_project.your_dataset.events_*`
WHERE event_name = 'page_performance'
  AND (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'e_pageload_ms') > 1000
ORDER BY page_load_ms DESC

-- Average timing metrics by page path
SELECT
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page,
  ROUND(AVG(
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'e_pageload_ms')
  )) AS avg_page_load_ms,
  ROUND(AVG(
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'e_domready_ms')
  )) AS avg_dom_ready_ms,
  COUNT(*) AS samples
FROM `your_project.your_dataset.events_*`
WHERE event_name = 'page_performance'
GROUP BY page
ORDER BY avg_page_load_ms DESC

Environment-Aware Stream Routing

Like the other recipes in this series, the container routes traffic to development or production GA4 properties automatically:

Measurement Stream RegEx Lookup checks {{Page URL}} against non-production hostname patterns (dev|uat|qa|orig|stg|stage|staging|int|local|admin|aem, plus the GTM Preview appspot.com domain). Matches route to {{Measurement Stream ID Development}}.
Environment Stream ID checks the GTM {{Environment Name}} built-in. Live environments match ^liv.*; pre-production matches ^(pre|de|st|ua|qa|te).*. The default is {{Measurement Stream ID Production}}.

Update the Measurement Stream ID Production (placeholder: G-AAAAAAAA) and Measurement Stream ID Development (placeholder: G-ZZZZZZZZ) Constant variables before publishing.

How to Import

Download the JSON from the Google Drive link above.
In GTM, go to Admin → Import Container.
Upload page-performance-measurement-recipe.json.
Choose Merge (not Overwrite) to preserve your existing container.
Update Measurement Stream ID Production and Measurement Stream ID Development.
Adjust siteSpeedSampleRate in the Page Performance Custom HTML tag if needed (line 3 of the script; range 1–100).
In GA4, create four custom metrics (event scope, Milliseconds unit) for e_pageload_ms, e_domready_ms, e_windowload_ms, and e_initialization_ms.
Open GTM Preview mode, load any page, and confirm the performance_timing custom event appears in the Tag Assistant panel. Check that the four parameter values are positive integers above 10.
Confirm the Page Performance Send Event tag fires on the same event in Preview.
Wait 24–48 hours for GA4 to begin populating the custom metrics in Explorations.

Navigation Timing Level 1 deprecation: The window.performance.timing API (Navigation Timing Level 1) is deprecated in favour of the Navigation Timing Level 2 PerformanceNavigationTiming interface accessible via performance.getEntriesByType('navigation')[0]. Level 1 remains supported in all major browsers as of mid-2025, but a future version of this recipe will migrate to Level 2 for forward compatibility. The core timing calculations and metric names will not change.

The full source — container JSON, script commentary, and variable inventory — is available on GitHub. Credit and gratitude to David Vallejo (@thyngster) for the original technique and for sharing it openly. If you extend the metric set, add Level 2 API support, or adapt the sampling logic, open a pull request or issue.

⬇ Download GTM Container JSON

DEV Community: Kent Spencer

GTM HTML5 Video & Audio Engagement

HTML5 & Engagement Tracking in GA4 via GTM — a 2026 Refresh of a 2016 Brightcove Recipe, Built on David Vallejo's Listener Pattern

Background and Rationale

What's Inside the Container

Tags

Triggers

The Listener Tag: How It Works

Reusing gtm.click Instead of Reinventing It

Platform Detection: The URL Component Extractor Template

GA4 Event Mapping

Tested With: the Brightcove In‑Page Embed

How to Import

GTM User Session Counter

Persistent User Session Counter in Google Tag Manager — A Complete Recipe

Why This Matters

What's Inside the Container

Architecture Overview

Session 1 (first visit ever)

Session 2 (return visit, same browser)

The User Session Counter Template — Sandboxed JS

The Cookie Rewriter Template — Extending Cookie Life

Cookies Written by This Recipe

Variables

Key Constants

Key Cookie-Reading Variables

Triggers

User Session Counter Tag

Extend Cookie Life Trigger

Dual-Purpose dataLayer Event

How to Import

What You Can Do With It

GTM postMessage Bridge and Listener

postMessage Bridge for iframes in GTM — Sandboxed, Parameterized, and Client-ID Aware

Why I Built a Variant of This

Passing the Client ID

Parent Site vs. Child Site — One Download, Two Destinations

What's Inside the Container

Folders

Tags

Triggers

Key Variables

How the Full Round Trip Works

1. Outbound: decorating the iframe's src (Parent Site)

2. Child side picks up the client ID

3. Sender: staging events inside the iframe

4. Receiver: unwrapping events on the parent

5. Downstream on the parent

What You Need to Change Before Using This

Change this — Host names

Change this — The tracked iframe element

Change this — Which events get bridged

Change this — Trigger scoping (fire only where your iframe actually is)

Built On Two Earlier Recipes

Diagnostics

How to Import

GTM e-Commerce Implementation GA4 and Meta

GA4 Ecommerce to Meta Pixel & Conversions API Bridge in GTM — Standard Events From a Standard DataLayer

What's Inside the Container

Folders

Tags

Triggers

The GA4 Ecommerce Data Model

Event Name Translation: One DataLayer, Two Vocabularies

Step 1 — e-Commerce Event Name Translator (site event name → canonical GA4 name)

Step 2 — Meta Standard Event Name Translator (canonical GA4 name → Meta standard event)

Meta Advanced Matching & the Production Traffic Gate

Environment-Aware Stream Routing

Shared Configuration & Event Settings

Community Custom Templates Used

How to Import

Microsoft Clarity GTM Integration

Microsoft Clarity via GTM — Free Behavioral Analytics That Sits Right Next to GA4

1. Clarity Is Free — the Same Way GA Is Free

2. Clarity Integrates Easily Through GTM

3. Sending Additional Events to Clarity with Markus Baersch's Template

4. What Clarity Adds on Top of GA4

Community & Official Templates Used

How to Import

Session Duration Timer in GTM

Reusing `gtm.click` Instead of Reinventing It

1. Outbound: decorating the iframe's `src` (Parent Site)

Step 1 — `e-Commerce Event Name Translator` (site event name → canonical GA4 name)

Step 2 — `Meta Standard Event Name Translator` (canonical GA4 name → Meta standard event)

1. Cookie — `_i_vstdur`

2. dataLayer Event — `_i_vstdur` with `durationSeconds: N`