/conversion-tracking

name: conversion-tracking
description: Set up, audit, verify, or fix website conversion tracking. Use when the conversion is a form submission, booked meeting, chat, phone call, signup, or purchase; when conversions must reach Google Ads, Meta, GA4, LinkedIn, TikTok, or Microsoft Ads; when the work involves GTM tags and dataLayer events, pixels, the Conversions API (CAPI), Enhanced Conversions, server-side tagging, or gclid and fbclid capture; or when the user reports conversion problems like "conversions stopped", "double counting", "spend but no conversions", "GA4 and Google Ads don't match", or an Unverified or Inactive status. Covers lead gen and ecommerce. Always fire on confirmed success, never the submit click; verify a test conversion arrives; diagnose before changing anything; offer free and native paths alongside paid ones and disclose partner tools. For tracking plans and UTMs, see analytics. For attribution models, see attribution. For campaigns and bidding, see ads. For CRM lead-stage design, see revops.
metadata:
  version: 1.0.0

Conversion Tracking

You help people set up conversion tracking that provably works, or find out exactly why their existing tracking doesn't. Everything you recommend should be fitted to what they actually run and where the data needs to go, and every finding you report should say how you learned it.

One rule sits above everything else here. If a test conversion can safely be fired, the job isn't done until one demonstrably arrived. And if it can't be fired, say plainly what remains unverified rather than implying it all works.

The one distinction that drives everything

There are two kinds of conversions, and they break in completely different ways.

**Lead generation** covers things like a form being submitted, a meeting being booked, a chat being started, or a phone number being called. The tricky part is that the browser is often the only place these moments are reliably visible. Many sites have no backend record of "contact form submitted" (some do, through a form tool's webhook or the site's own backend, and those are worth using), so success usually has to be worked out from a signal in the page, and every form and booking tool signals success differently. Getting that signal wrong is the single most common cause of tracking that looks fine but is quietly wrong. Fire on the submit button and you count failed submissions and bots. Fire on a thank-you page and you count refreshes.

**Ecommerce** covers purchases and subscriptions. Here the hard part of lead gen simply doesn't exist, because an order record does. The store knows a purchase happened, so knowing the conversion is real is nearly free. The difficulty moves elsewhere instead. Is the value right (tax and shipping in or out, and in which currency)? Does the item data match the merchant feed? Are the browser pixel and the server event deduplicated so each sale counts once? Are the pre-purchase events (view item, add to cart, begin checkout) flowing, since that's what the platforms optimise on? And what happens when an order is refunded?

Work out which side of this line you're on before doing anything else. It decides which reference files apply, which failure modes to suspect, and which delivery options even make sense.

Start here

| The user's opening move | What to do | |---|---| | Nothing set up yet | Run the **setup flow** below | | Something exists and it's misbehaving | Run the **audit flow** below | | Something exists and they don't know if it works | Run the audit flow as a verification pass. There's no symptom to route on, so do the full evidence sweep | | "Should we go server-side?" or "Is tool X worth it?" | Go straight to `references/server-side.md` and answer the question with the real options and real numbers. Don't put a decision question through a setup wizard | | "Just give me the snippet for tool X" | Read `assets/snippets/{tool}.js` and hand over its contents verbatim, header included. Never retype or condense a snippet from memory, because the shipped file carries edge cases a rewrite silently drops. Name the dataLayer event it pushes and offer the one-minute console check. No interrogation first |

The three questions

Setup and audit both run on the same three facts. In setup you're establishing them so you can build. In an audit you're establishing them so you know what *should* be true before you go looking at what is.

**1. What counts as a conversion?** Be precise here, because most people haven't actually decided. A *confirmed* form submission is not a click on the submit button, and a purchase is not someone starting checkout. Does a newsletter signup count? Are a quote request and a contact form one conversion or two? Settling this is the first place you add value, before any code gets touched. And ask whether the conversion that actually matters sits further down the funnel, a qualified lead or a closed deal only the CRM knows about. That has its own path and its own volume gates, covered in `references/server-side.md` under tracking what happens after the lead.

**2. Where does it need to land?** GA4 only, one ad platform, or several? This matters because it decides how much the lead's details (email, phone, name) matter. Ad platforms bid real money on these numbers and match on the lead's details, so the stakes are highest there. But an analytics-only setup still loses some conversions to ad blockers and the like (typically 10–30% depending on audience; magnitudes are in `references/discrepancies.md`), so server-side is worth mentioning for more accurate numbers even when no ad platform is involved.

**3. What runs the moment?** Which form, booking, chat, or checkout tool, what the site is built on, and whether Google Tag Manager is installed.

**Look before you ask.** Try to answer these three questions from evidence first, and only ask about what's left, in a single batched message. If `.agents/product-marketing.md` exists (or `