The Chrome DevTools Recorder for Tracking QA

Tracking QA is repetitive by nature. Every GTM publish, every front-end release, every new consent banner means walking the same signup form or checkout again, watching the same hits. By the fifth time today you are clicking fast and reading less.

The Recorder fixes the repetition. It captures a journey — clicks, form fills, navigations — as a list of steps you can replay, edit, and share. Google pitches it for performance testing. For tracking, it means you walk the checkout once, and from then on Chrome walks it for you while you watch the hits.

This guide covers creating, replaying, and asserting on recordings, with sample use cases at the end. The examples run against the Google Merchandise Store in Chrome 156.

How to open it#

The Recorder is not one of the default tabs, so open it by name:

• Press F12 (Mac: Cmd+Option+I), then Ctrl+Shift+P (Mac: Cmd+Shift+P) for the Command Menu, type Show Recorder, and press Enter.
• Or use the DevTools ⋮ menu → More tools → Recorder.

Once opened, it stays in the tab strip for that profile.

From the Command Menu to a finished recording: name it, start, walk the journey, end.

Create a recording#

Click Create recording. Two settings deserve thirty seconds of thought before you start.

The two settings that decide whether a recording survives a redesign: the selector attribute and the selector types.

1. Selector attribute. If your developers add a stable test attribute — data-testid, data-qa, data-track — enter it here and the Recorder will prefer it over generated CSS paths. This is the biggest factor in whether a recording still replays in three months. The same attribute makes a robust GTM trigger (see testing selectors in the Elements panel), so it is worth asking for either way.
2. Selector types to record. CSS, ARIA, Text, XPath, and Pierce (which reaches into shadow DOM). Leave them all checked: each step stores several selectors, and replay falls back through them if the first no longer matches.

Name the recording after the journey — "Newsletter signup" beats the default "Recording 10/26/2026 at 12:49:16 PM" the first time you share it.

Click Start recording, walk the journey normally, and click End recording. You get an editable step list: Set viewport, Navigate, Click, Change, Key down, Key up. Each step expands to show its type, target, and selectors, and every value is editable.

A few habits make recordings more reliable:

• Start from a clean state. Clear site data (Application → Storage → Clear site data) before recording, so the journey begins with the cookie banner a new visitor sees — and the replay does too.
• Click deliberately. Hovering menus and stray clicks become steps. Delete them afterwards from each step's ⋮ menu → Remove step.
• Avoid personal data. Typed values are stored in the recording in plain text. Use test emails and test cards.

Replay it#

Click Replay with the Network panel open and filtered to collect?v=2, with Keep log on so hits survive each navigation. Two controls matter:

• Replay speed. Normal is fast enough that some tags will not finish before the next step navigates away. Slow or Very slow is closer to a human, and is the honest test for tags that fire on a click just before a page change.
• Replay settings. Network throttling and a per-step timeout. Throttled replays find tags that only work on fast connections — the outbound-link and form-submit events that undercount on mobile.

You can also set a breakpoint on any step by clicking its marker in the step list, then step through the journey one action at a time. That is far easier than clicking fast and hoping when you are chasing a form_submit that sometimes fires twice: pause before the submit, clear the Network log, step once, and count the hits.

Assert on tracking, not just the page#

Add assertion waits for an element to appear, which proves the results page loaded but says nothing about tags. The more useful step type is waitForExpression, which waits until a JavaScript expression in the page returns true — and fails the replay if it never does:

1. Open the last step's ⋮ menu → Add step after.
2. Expand the new step, click its type value and change it to waitForExpression.
3. Set the expression that must become true:

1window.dataLayer.some((e) => e.event === 'view_item_list')
Copy

The replay now fails if the view_item_list push never happens. You can be stricter — check a value, not just the event:

1window.dataLayer.some((e) => e.event === 'purchase' && e.ecommerce?.value > 0)
Copy

What this still does not prove is that the GA4 hit left the browser with the right parameters. A dataLayer assertion checks what the site told GTM; for what GTM sent, you still read the Network panel and the payload reference.

Import and export#

The export button offers JSON, @puppeteer/replay, Puppeteer (including variants for Firefox and with Lighthouse analysis), and more formats through Recorder extensions.

Share the JSON: a colleague imports it into their own Recorder with the import button and replays exactly your journey. For an agency, that is a cleaner bug report than a screen recording — the developer replays it with their own DevTools open.

The @puppeteer/replay export goes further: the same file runs headlessly from a terminal or a CI pipeline with npx @puppeteer/replay recording.json, including your waitForExpression steps.

Use cases#

Regression check after every GTM publish#

1. Record the three journeys that carry revenue: product view → add to cart, checkout, and lead form.
2. Add a waitForExpression step for each key event (add_to_cart, begin_checkout, generate_lead).
3. After each publish, replay all three in GTM Preview mode. A failed step names the journey and the missing event before the change reaches a report.

A form_submit that sometimes fires twice#

1. Record the form fill and submit.
2. Set a breakpoint on the submit step, replay, and clear the Network log when it pauses.
3. Step once and count collect?v=2 hits with en=form_submit. Two hits with different initiators mean two tags; two from the same initiator mean the trigger matched twice — often a click trigger and a form trigger on the same button.

Outbound link events undercount on mobile#

1. Record a click on an outbound link.
2. Replay with Replay settings → network throttling set to a slow profile and device mode at phone width.
3. If the hit is missing or shown as cancelled in the Network panel, the browser left the page before the tag finished — enable a beacon transport or delay the navigation in GTM.

Reproducing a client's bug report#

The client says "the newsletter conversion doesn't fire after you accept cookies."

1. Clear site data, start recording, accept the banner, and complete the signup.
2. Export the JSON and attach it to the ticket. The developer imports it and sees the same journey, step for step.

Testing a consent-gated journey#

1. Record the same journey twice: once accepting the banner, once rejecting.
2. Replay each with the Network panel open and check the gcs parameter on every hit — see consent mode v2 in GTM for the values to expect. A rejected replay that still sends gcs=G111 is a consent bug.

Where the Recorder stops#

The Recorder replays only when someone opens it and clicks Replay. A recording sits unreplayed while the front-end team renames the submit button's class. Its assertions check the page and the dataLayer, not the hits GA4 received. Nothing alerts you when a journey would have failed.

How Tagfire helps#

Tagfire's Recordings work like DevTools recordings — record a journey once as steps, replay it any time — with one difference: you attach expectations to the analytics hits, not to the page. A sign_up event must fire; a purchase must have value greater than zero and currency equal to USD. After every replay the captured hits are checked against them, in the Tag Debugger.

Monitors group several recordings for one site and replay them on a schedule in a headless browser. Each run checks the expectations, compares a full-page screenshot to an accepted baseline, and emails your recipients if anything fails. Replays use a distinctive user agent, so the synthetic traffic can be filtered out of the property. The journeys and monitors documentation covers setup.