Ad Conversion Tracking

Conversion Tracking

Verify that conversion tracking actually measures reality before a single dollar of campaign budget spends.

• The anti-pattern this skill exists to prevent: teams treat tracking as a launch-checklist checkbox, tick it off from a settings screenshot, and discover it was broken only once the spend report stops making sense. 70-80% of B2B SaaS search accounts audited by GrowthSpree carry at least one significant conversion tracking issue.
• The governing principle: bad conversion data does not merely misreport, it actively trains the bidding algorithm to find the wrong people - "if your tracking is inaccurate, every optimisation decision made by the platform will be based on incorrect data" (PPC Hero).

The output is a verification report with per-check evidence, ending in an explicit GO / NO-GO decision with a named approver.

Scope and handoffs

This skill verifies; it never implements. It produces the checklist, walks the evidence, and issues the verdict - writing or installing tracking code belongs to whoever owns implementation (identified in the Interview). Adjacent ground goes to siblings:

• Reconciling cross-platform numbers after launch → mbfinotti/advertising-skills@ad-attribution-gap.
• Account-level performance root-cause diagnosis → mbfinotti/advertising-skills@ad-account-diagnostic (it hands tracking FAILs back here).
• Landing-page conversion-rate review → mbfinotti/advertising-skills@paid-landing-page-audit.
• Ongoing creative decay monitoring → mbfinotti/advertising-skills@ad-creative-fatigue.

Interview

Ask one question at a time; skip anything already known or visible in the setup. This is a tactical pass, not an interview - keep it brief.

1. Which platform(s) will the campaign run on?
2. Funnel type: B2B lead gen, B2C ecommerce, or both?
3. Do server-side events run alongside the browser pixel/tag, or browser only?
4. Who owns implementation - you, a dev team, an agency? (Fixes get addressed to them.)
5. Is a consent banner live, and does traffic include a consent-regulated region?
6. Budget behind this launch? (Sets how much is at risk behind the gate.)
7. Is the launch date hard or movable? A hard date promotes the near-zero-effort settings and trigger fixes and pushes the click-identifier chain past launch as a risk-accepted item; a movable date lets the whole defect batch ship in one release and relearn once.
8. One-off clearance for this campaign, or a tracking setup you intend to trust for quarters? Compounding intent promotes the click-identifier chain and the shared event ID - they pay every future campaign; one-off intent promotes only the checks that clear this launch.
9. Effort ceiling before launch: your own hours in a tag manager, dev and CRM coordination, or a legal sign-off too? No dev access caps the fix list at settings and tag-manager work, and everything below that line is deleted from the list by name in the report, with the measurement it costs and who accepted the loss - never silently dropped and never left ranked last.

Answers 7-9 re-rank the fix ordering in the Defect checklist. Record them - the report has to say which defects were deferred and on whose authority.

Evidence gate

Never issue a GO verdict from configuration screenshots alone - a settings page that looks right, or even a tag firing green in a debugger, is not proof of accurate measurement. A GO requires at least one real test conversion traced end to end:

1. Action performed.
2. Payload inspected.
3. Event received in the platform UI with correct value and currency.
4. Deduplicated.
5. Test data excluded.

One named exception: a brand-new property with no traffic yet cannot show a platform-UI conversion within the verification session (events can take hours to appear, and a fresh conversion action starts in a waiting status). It may receive a provisional PASS, labelled as such, on the strength of debug-mode evidence plus a correct payload - with a mandatory re-verification the moment the first live conversions land.

The verification sequence

Nine steps, fixed order. Each step's evidence is only readable once the steps before it hold:

• The platform UI cannot be judged until what the tag actually sent is known.
• You cannot judge deduplication until events arrive from both sources.
• Test-data exclusion must exist before the soak period generates data - exclusion filters are not retroactive.

Do not rank these steps by efficiency, and do not reorder them to front-load the cheap ones: the sequence is a dependency chain, so a value-per-effort ordering here would be false precision. Efficiency ordering belongs to the fix list this sequence produces (Defect checklist), not to the sequence itself.

Record per-step evidence as you go.

1. Settings and conversion-action configuration. Confirm the primary conversion designation matches the business goal - revenue-relevant actions primary, page views and micro-actions secondary and excluded from bidding. Rawsoft found an account with 13 primary conversion actions of which only 4 were business outcomes, so smart bidding optimized against 1.5M+ monthly noise conversions. For lead gen, confirm count-once (not count-every) per click. _Evidence: list of primary actions, each mapped to a business outcome; counting method per action._
2. Enter tag debug / preview mode. Use the tag manager's preview mode and the platform's test-event or tag-inspection tool. _Evidence: the conversion tag visible and armed on the conversion page, firing on the intended trigger only._
3. Perform a real test conversion end to end. Walk the exact user journey a paid click takes - land with the click identifier in the URL, accept (and separately reject) the consent banner, complete the action. B2C: place a real low-value test order (near-zero discount code, or refund it later). B2B: submit a test lead with a unique QA value and confirm it lands in the CRM record. _Evidence: the test order/lead ID, and the identifier it carries._
4. Inspect the event payload. In the browser's network inspector or the tag debug tool, read the actual request: correct event name, value, currency, a per-conversion event ID, the click identifier, and hashed identifiers where used. _Evidence: the payload fields, copied into the report._
5. Confirm the event in the platform UI. The test event appears in the platform's event manager, marked browser or server, and the conversion action shows a healthy recording status. Any primary action in a misconfigured or no-recent-conversions status is an automatic NO-GO. Allow a few hours of reporting lag before concluding an event is missing. _Evidence: status per primary action; the test event visible with correct value and currency._
6. Verify deduplication (section below) whenever browser and server events both run. _Evidence: one counted conversion for the test action; dedup rate._
7. Exclude and clean the test data (section below). _Evidence: filter state active, test conversion retracted, test order refunded/removed._
8. Soak. Let real signals accumulate for a few days before scaling judgment - practitioners confirm the conversion has been reporting signals for a few days so the platform understands the goal (Pearmill); reconciliation against backend or CRM should wait roughly 4 days for data to settle (Enalitica). _Evidence: daily counts trending, gaps within thresholds (Objective section)._
9. Document and sign off. Fill the output-shape report, name the approver, date it, and issue GO / NO-GO. Launch checklists that skip an explicit approval field get skipped under launch pressure (Marketing Machine's template carries a GO/NO-GO block with approver and date). _Evidence: the completed report itself._

Deduplication check

When a conversion is sent from both the browser tag and a server-side endpoint, the platform needs a shared key to count it once. Three conditions must hold (Analyzify):