Tag Monitoring: Catch Broken Conversion Tags Early

Tag monitoring is a scheduled check that loads your site the way a visitor does and confirms your analytics and ad tags still fire and send their data. On a lead site the tag that matters is the conversion, so the check worth automating is a test lead: a headless browser fills in your form on a schedule and fails if the Google Ads conversion request or the GA4 key event does not go out. The Google, Wix and Playwright documentation below was checked on October 3, 2026.

What breaks conversion tags on a lead site?

Four kinds of change, none of them announced.

What does a tag monitoring check need to prove?

That the lead path still sends the conversion, which is a network request, not a green light in a dashboard. Google's help says a Google Ads conversion goes to googleadservices.com/pagead/conversion/, or to google.com/pagead/1p-conversion/ in some browsers (Google Ads help), and a GA4 hit goes to google-analytics.com/g/collect or analytics.google.com/g/collect (GA4 troubleshooting). So the check counts those requests: no Google Ads conversion before the submit, exactly one after it, and a GA4 request carrying your key event. Two Google Ads requests, not counting redirects, mean the tag fires twice for one lead.

How do I run a scheduled test lead?

With a browser automation library and a scheduler. This sketch uses Playwright; replace the URL, field selectors and event name with yours, and run it once by hand to confirm the hosts match what your site really sends.

// test-lead.mjs: exits with an error if the lead form stops sending its conversions
import { chromium } from "playwright";
 
const FORM_PAGE = "https://www.example.com/contact"; // the page your ads send people to
const KEY_EVENT = "generate_lead";                    // your GA4 key event
 
const isAds = (r) =>
  !r.redirectedFrom() && // Playwright reports each redirect as a new request
  /googleadservices\.com\/pagead\/conversion\/|google\.com\/pagead\/1p-conversion\//.test(r.url());
const isKeyEvent = (r) =>
  /(google-analytics\.com|analytics\.google\.com)\/g\/collect/.test(r.url()) &&
  (r.url() + (r.postData() ?? "")).includes(KEY_EVENT);
 
const browser = await chromium.launch();
const page = await browser.newPage();
let adsHits = 0;
page.on("request", (r) => { if (isAds(r)) adsHits++; });
 
await page.goto(FORM_PAGE);
// accept the consent banner here if your site shows one
if (adsHits > 0) throw new Error("Ads conversion fired before the submit");
 
await page.fill("#name", "Tag Monitor Test");
await page.fill("#email", "tag-monitor@example.com");
 
const adsSent = page.waitForRequest(isAds);      // start waiting before the click
const keyEventSent = page.waitForRequest(isKeyEvent);
await page.click('button[type="submit"]');
await Promise.all([adsSent, keyEventSent]);      // each throws after 30 s if nothing goes out
await new Promise((done) => setTimeout(done, 5000)); // give a duplicate time to show
 
await browser.close();
if (adsHits !== 1) throw new Error(`${adsHits} Ads conversion requests, expected 1`);

page.waitForRequest is started before the click, as Playwright's docs show, and throws after its 30-second default timeout if nothing matches, so a broken tag ends the run with an error your scheduler can email you. Run it daily and right after every release and Tag Manager publish.

Where should the test lead run from?

Run it from the country your customers are in. My agents audited the public pages of practices I researched for outreach with headless Chrome and network capture, read-only, never submitting a form. One finding had to be withdrawn: consent showed as denied on a Wix site with no banner only because the check ran from Bulgaria. Wix's help says that without a cookie banner, a visitor from a country that requires consent sends no data to Google Analytics (Wix). More in measuring conversions under consent.

How do I keep test leads out of the reports?

Google Ads should not count them: it records a conversion when it recognizes the cookie from a click on your ad or a view of your video ad (conversion measurement), and the runner has neither. GA4 will count them. Run the job from a fixed IP and define that IP as internal traffic under Admin > Data collection and modification > Data streams > your web stream > Configure tag settings > Show more > Define internal traffic. Leave the data filter in Testing, where matching hits get the Test data filter name dimension, and switch it to Active only when that label shows on the test leads and nothing else, because an active filter's effect is permanent (internal traffic). Give the test identity a name the front desk recognizes.

Which Google signals back it up?

The Google Ads status sits in the Status column of Goals > Conversions > Summary, where Misconfigured means conversions stopped recording because of a setup error or a broken tag; Google Ads conversion status covers each value. Open Tag Diagnostics from the Google tag settings: under Your Google tag, in the Tag quality section, select View diagnostics. For GA4, create a custom insight from the Insights card (View all insights, then Create) on your key event, with a % decrease more than or Has anomaly condition and your email as a recipient. On a site with a handful of leads a day I would evaluate it daily, since an hour without a lead is normal. Which events you mark as key events decides what this check can see.

How is this different from monitoring inside Google Ads?

A monitoring agent for Google Ads reads the account and your outcome data and decides whether a drop is real or a quiet window. That works on counts, so on a site with a few leads a day a break takes days to stand out, and the alert says that something broke, not which change did it. A test lead checks the cause directly and does not depend on traffic. They see different failures: the browser never sees an offline upload that stopped, and the account never sees which trigger stopped matching. Run both.

What should happen when a run fails?

Treat it as a bug report and reproduce it. In a recorded talk, Lauren Tan, an engineer at Cursor, describes an agent that takes incoming bug reports, opens its own machine in the cloud, drives the application with the same control skills she built for local work and tries to reproduce each report; in her example it reproduced the bug and found it was already fixed on main. A failed test lead is that kind of report with its reproduction attached. Rerun it in a clean browser, then compare against the last site release, the consent banner and the latest container version, since every publish records one (versions). If the publish is the cause, choose Set as Latest Version on the previous version, publish it, check the fix in Tag Assistant and rerun the script.

When can I trust the script?

Tan also advises starting locally, where you can watch how the agent works with the application, and trusting it there before handing work to cloud agents. Same here: run the script with a visible browser on your machine next to Tag Manager's Preview in the Workspace tab (preview) until its result matches what you see. Without an automated check, as she puts it, "you're the bottleneck", and on a lead site the bottleneck is whoever first wonders why the leads went quiet.

Where does this fit?

Tag monitoring keeps a working setup working; it cannot make a wrong one right. If the conversion it guards was never tied to a real lead, start with the measurement itself. That is the marketing analytics work I do: one set of numbers across ads, GA4 and the CRM, verified in the account.