---
name: set-up-google-ads-conversion-tracking
description: >-
  Stands up native Google Ads conversion tracking end to end: audit what already exists, create the
  conversion actions with correct category/count/value/window settings through VigilDog, coordinate
  the human GTM/gtag install, set account-default goals, and verify conversions actually record
  within 48 hours against backend numbers. This is the foundation skill, run it on new accounts,
  after site migrations, when an audit finds broken or duplicate tracking, or when moving off
  GA4-imported goals. Do not use it for hashed-data attribution recovery
  (implement-enhanced-conversions), CRM outcome imports (set-up-offline-conversion-tracking),
  first-party server routing (implement-server-side-tagging), or consent banners
  (configure-google-consent-mode), those all build on top of what this skill creates.
---
# Google Ads Conversion Tracking Setup

## Purpose
Create and verify the account's native conversion measurement: the right conversion actions with
the right counting and value settings, tags firing on the right events, correct primary/secondary
classification, and reported numbers that reconcile with the backend. Everything else in the
measurement stack, enhanced conversions, offline imports, value-based bidding, assumes this layer
is correct.

## When to run
- New account or new website with no (or untrusted) conversion tracking.
- Migration from GA4-imported goals to native Google Ads tracking.
- Post-migration rebuild after a site replatform.
- An account audit (gads_audit_account) flags missing, duplicate, or misconfigured conversion
  actions.

## When NOT to run
- Tracking works and you want to recover unattributed conversions with hashed user data, implement-enhanced-conversions.
- The real conversion happens in the CRM after the form fill, set-up-offline-conversion-tracking.
- You need ad-blocker/browser-restriction resilience, implement-server-side-tagging.
- Counts are inflated by refresh/double-fire, implement-transaction-id-deduplication (usually run
  immediately after this skill anyway).
- EU/EEA consent collection, configure-google-consent-mode.

## Prerequisites
- Admin access to the Google Ads account (VigilDog connection active).
- A written list of conversion events: macro (purchase, lead form, call) and micro (add-to-cart,
  signup step) with which are business-critical.
- GTM container or site-code access for the human tagging steps; developer available for
  data-layer work on dynamic values.
- If GA4 exists: the GA4 property linked to Google Ads before creating actions, to avoid duplicate
  goal imports (HUMAN STEP in the GA4/Ads UI).

## Procedure
1. Consult `gads_policy_guardrail` before any write in this session.
2. Audit the existing state. Call `gads_list_conversion_actions` and record for every action:
   status, category, primary/secondary, counting method, value settings, attribution window, and
   recent conversion volume (supplement with `gads_run_gaql_query` for 30-day counts per action).
   Flag duplicates (a native action and a GA4-imported goal both primary for the same event) and
   orphans (actions with zero recent conversions).
3. Design the action set with the user. One action per meaningful business event. Per action decide:
   - Category: the most specific goal category (purchase, lead submission, booking, contact...).
   - Counting: one-per-click for lead-type events (repeat submissions add no value); every for
     purchases (each transaction counts).
   - Value: transaction-specific values for ecommerce; no value or a computed average for lead gen
     without deal data.
   - Windows: click-through matched to the sales cycle (30 days default, longer for slow B2B),
     view-through short (about 1 day), engaged-view about 3 days.
   - Classification: macro events primary (bidding), micro events secondary (reporting only).
4. Create the actions with `gads_create_conversion_action`, one preview per action showing name,
   category, counting, value settings, and windows; apply only after the user approves each (or an
   explicitly approved batch). Fix misconfigured existing actions with `gads_update_conversion_action`
   under the same preview → approval → commit flow rather than creating duplicates.
5. Record the tag identifiers for the human: each action's conversion id (constant per account) and
   per-action label, retrievable from the create/list responses.
6. HUMAN STEP (outside VigilDog): implement the tags. In GTM: a Google Tag on all pages, a Conversion
   Linker tag on all pages, one conversion tag per action wired to its trigger (data-layer event,
   thank-you URL, or click), with value / transaction id / currency mapped from data-layer
   variables for ecommerce. gtag route: event snippets on conversion pages below the base tag.
   Always populate a transaction id, it is the dedup key.
7. HUMAN STEP (outside VigilDog): debug in GTM preview, fire a real test conversion, confirm the
   linker and conversion tags fire with correct id/label/value/transaction id, then publish the
   container.
8. Set the account-default goal so campaigns bid on the right category:
   `gads_set_campaign_conversion_goal` (preview first, apply after approval) to align campaign
   goal settings with the primary macro action(s).
9. Verify after 24-48 hours with VigilDog:
   - `gads_run_gaql_query` segmented by conversion action: each new action shows conversions.
   - Check classification: only intended actions counted in the primary conversions column.
   - Reconcile against the backend export the user provides for the same window.
10. Report the reconciliation and any actions still at zero, with the likely cause (trigger not
    firing, page not tagged, volume genuinely low).

## Decision rules
- Google Ads vs backend discrepancy under 10% → normal (attribution and timing differences);
  10-20% → monitor and re-check next review; over 20% → treat as broken and debug before any
  bidding work relies on the data.
- Never leave both a native action and an imported GA4 event as primary for the same real-world
  event, one primary, the other secondary or removed. Duplicates double-count into bidding.
- Lead events: one-per-click counting. Purchases: every. Getting this backwards inflates lead
  counts or undercounts revenue.
- No transaction id mapped → stop and add it; without it every page refresh is a new conversion.
- An action showing zero conversions after 48 hours with real traffic → tag/trigger problem, not
  patience problem.
- Micro conversions never primary: they drown the bidding signal in cheap events.
- Naming convention: encode source and event into the action name (e.g., a native-tag prefix plus
  the event) so lists stay auditable as actions accumulate; whatever convention is chosen, apply
  it to every action created in step 4.
- Value settings drive later bidding options: no-value actions permanently exclude the account
  from value-based strategies, if average lead values are even roughly known, prefer a computed
  average over no value.

## Common failure modes
- Skipping the Conversion Linker tag, quietly degrading click attribution, always all-pages.
- Creating actions before linking GA4, ending up with parallel duplicate goals.
- Trigger fires on every page containing the thank-you string, not just the confirmation page, URL conditions must be tight.
- Dynamic value never wired because the data layer was an afterthought; brief the developer before
  the tag work, not after.
- Declaring success from the GTM debugger alone; only conversions visible in reports and
  reconciled with backend numbers count as done.

## Related skills
- Run before everything else in measurement; this is the root dependency.
- Run immediately after: implement-transaction-id-deduplication, configure-google-consent-mode
  (EU/EEA traffic).
- Then: implement-enhanced-conversions, set-up-offline-conversion-tracking (lead gen/SaaS),
  set-up-cart-data-and-profit-tracking (ecommerce), set-up-conversion-based-bidding once volume
  supports it.