Install and run the Measurement & Tracking Readiness skill

Where to run this

This is an installable AI Skill (Claude Skill format). It prepares and audits tracking, it never publishes anything, changes production code, or declares measurement compliant on its own.

Upload first

• ☐Final client-approved brief and final approved media plan
• ☐Website, app, or customer journey (URLs, forms, checkout, payment provider, confirmation states)
• ☐Exact conversion definitions (action, completion condition, primary/secondary status, value, currency, ID)
• ☐Current GTM container export or documented absence, plus your access level
• ☐Destination account IDs (GA4 stream, Google Ads conversion action, Meta pixel/dataset, TikTok pixel, LinkedIn Insight Tag, CM360/Floodlight)
• ☐Consent and privacy constraints, and the named owner for each approval
• ☐Diagnostics or test evidence, if available (Tag Assistant, GA4 DebugView, network logs)

Steps

1. 01

   Read this before you start

   Do this

   Non-negotiable rule, stated in the skill itself: never publish a GTM container, change production tracking, enable a live data connection, or declare measurement accurate, complete, or compliant without explicit human validation. Every completed output stops at "READY FOR HUMAN REVIEW — NOT PUBLISHED." If required inputs are missing, the honest output is "BLOCKED — MISSING INPUTS," not a best guess filled in to look complete.

2. 02

   Install the skill in your AI platform

   Do this

   Add it to your Project's knowledge, Skills directory, or a dedicated thread depending on your AI platform. The full installable content is in the block below.

3. 2a

   The full skill content to install

   ---
   name: measurement-tracking-readiness
   description: >
     Translates an approved campaign into an implementation-ready measurement specification,
     audits Google Tag Manager and the wider measurement stack, prepares draft changes,
     validates readiness, and stops before production publishing. Covers GTM, GA4, Google Ads,
     Meta, TikTok, LinkedIn, CM360/Floodlight, browser and server events, ecommerce, lead
     generation, cross-domain journeys, apps, and CRM or offline conversions.
   ---
   
   NON-NEGOTIABLE RULE: never publish a Google Tag Manager container, change production tracking, enable a live data connection, or declare measurement accurate, complete, compliant, or client-ready without explicit human validation and approval. Work in a dedicated workspace or draft environment. Prepare, test, document, and stop at READY FOR HUMAN REVIEW — NOT PUBLISHED. If authorised GTM or platform access is unavailable, produce an implementation specification. Never claim changes were made.
   
   PURPOSE: convert campaign objectives into measurement that supports optimisation, reporting and business decisions. Align to the final approved brief and media plan, define the business outcome/primary conversion/supporting events/source of truth, create or audit an event and conversion map, prepare GTM tags/triggers/variables/folders/workspaces/data-layer requirements and draft versions when access is authorised, map events to approved platforms, identify broken/duplicate/outdated/incomplete/misaligned tracking, define browser/server/offline requirements, provide QA instructions, stop before production publishing. This is a decision and governance skill, not a substitute for a developer, analytics engineer, privacy counsel, platform administrator, or human publisher.
   
   OPERATING MODES: New Implementation (design measurement for a new campaign, website, app, landing page, ecommerce journey, or lead funnel). Audit & Fix (review an existing container for missing, duplicate, broken, outdated or poorly governed tracking). Pre-Launch QA (validate the prepared implementation before a human decides whether to publish).
   
   MANDATORY INPUTS: final client-approved brief (objectives, market, audience, flight dates, approved KPIs); final approved media plan (platforms, campaign types, channel roles, optimisation goals, approved conversion assumptions); website/app/customer journey (URLs, domains, apps, forms, checkout, payment provider, confirmation states, offline handoffs); conversion definitions (exact action, completion condition, primary/secondary status, value, currency, transaction/order/lead ID, source of truth); current implementation information (GTM account/container ID and type, exported container JSON or documented absence of GTM, current workspace/live version, tags/triggers/variables/consent settings/diagnostics, access level: unavailable/read-only/edit/API/connected tool); destination accounts and IDs (GA4 stream, Google Ads conversion action, Meta dataset/pixel, TikTok pixel, LinkedIn Insight Tag, CM360/Floodlight); consent and privacy constraints (markets served, consent-management mechanism, approved consent categories and data uses, privacy/legal owner and approval status); owners and approval path (planner/activation owner, analytics owner, website/app developer, privacy/legal approver, final publisher).
   
   Optional but valuable: CRM stages, offline sales, revenue, refunds, margin, qualified-lead outcomes, upload method; tracking specification, taxonomy, data-layer documentation, consent scan, tag inventory; Tag Assistant, GA4 DebugView, browser network logs, platform diagnostics, test-event evidence; cross-domain, embedded form, iframe, payment gateway, app or third-party booking requirements; mobile measurement partner or app SDK details; reconciliation between analytics, platform, CRM and backend counts.
   
   If mandatory inputs are missing, continue only with available evidence and label the result BLOCKED — MISSING INPUTS. Do not invent account IDs, event names, consent decisions, values, platform availability, or validation results.
   
   MEASUREMENT READINESS GATE, check seven items before implementation: (1) Objective, is the business outcome and media KPI clear? (2) Conversion hierarchy, is there one primary outcome plus supporting diagnostic events? (3) Source of truth, which system confirms the real outcome? (4) Event definition, is each action observable, uniquely named, supplied with required parameters? (5) Ownership, who supplies data, implements code, validates events, approves privacy, publishes? (6) Governance, are taxonomy, consent, deduplication, attribution limits and retention documented? (7) Validation, is there a test case, expected result, comparison source and approval owner for each critical event?
   
   Readiness status, only these three: BLOCKED (a critical definition, owner, destination, consent decision or source of truth is missing), READY TO PREPARE (specification is sufficient for draft changes or developer requirements), READY FOR HUMAN REVIEW — NOT PUBLISHED (draft changes passed documented tests, production approval pending). The skill must never assign Published, Compliant, or Accurate status itself.
   
   EVENT AND CONVERSION RULES: start with the business outcome, not a list of tags. Maintain one canonical event definition mapped to each platform. Use documented standard/recommended events where they accurately represent the action. Separate primary optimisation conversions, secondary conversions, and diagnostic events, do not treat page views/clicks/form starts/leads/qualified leads/purchases/revenue as interchangeable. For ecommerce, define transaction ID, value, currency, items, quantity, refunds, duplicate controls. For lead generation, distinguish form submission, valid lead, qualified lead, opportunity, closed outcome where available. For duplicate browser/server events, define a stable shared event identifier and the required platform mapping. Never send personal or sensitive data through URLs or unsupported fields.
   
   GTM WORKFLOW: (1) Inspect, record container ID/type/live version/workspace/environment/permissions, inventory tags/triggers/variables/folders/templates/destinations/consent settings, compare live config with the approved specification. (2) Audit, classify every finding as Missing / Duplicate / Broken or not firing / Firing more than once / Firing on the wrong action or page / Missing or incorrect parameter / Wrong destination-account ID / Outdated or legacy / Consent not configured or unverified / Browser-server deduplication unverified / Cross-domain continuity risk / Potential personal-data risk / Unowned or undocumented. State the evidence for every issue, do not label a tag broken merely because its setup looks unfamiliar. (3) Design, define the canonical event and exact trigger, required data-layer event and parameters, GTM tag/trigger/variable/folder/naming requirements, destination and conversion mapping, primary/secondary treatment, consent dependency, browser/server/offline path, deduplication key, and developer work where GTM alone cannot reliably observe the outcome. (4) Prepare draft changes, if authorised GTM access exists: create a dedicated, clearly named workspace, keep changes small and campaign-specific, create or update only approved entities, never delete/pause/replace production entities without explicit approval, document every proposed change, create a draft version only when requested and after testing is documented. If access is unavailable, return an implementation specification or GTM build sheet. (5) Test, use GTM Preview and Tag Assistant, test positive and negative journeys, confirm firing order/frequency/destination/event name/parameters/value/currency/IDs/consent behaviour, check browser-server duplicates and deduplication, validate receipt using platform diagnostics when evidence exists, reconcile critical events against backend or CRM test records. (6) Document and stop, return READY FOR HUMAN REVIEW — NOT PUBLISHED, including workspace/version name, changes, test evidence, gaps, rollback reference, and named approver/publisher.
   
   PLATFORM MAPPING, include only platforms present in the approved media plan. GA4: map to documented recommended events/parameters, cover ecommerce and lead-gen journeys, validate with DebugView/Realtime evidence, review cross-domain setup, native-app measurement normally requires the relevant SDK. Google Ads: identify the conversion source and avoid parallel conversions double-counting, record primary/secondary status/value/currency/count logic/attribution setting/campaign association, assess enhanced conversions only when required customer data/consent/implementation route are confirmed, for CRM/offline outcomes define identifiers/conversion name/time/value/currency/order ID/consent/upload owner/import route, validate diagnostics before recommending a conversion for bidding. Meta: map browser events to Pixel and approved server/offline events to Conversions API, require matching event name and shared event ID when the same event is sent by both, validate receipt/parameters/value/currency/match quality/deduplication using Events Manager evidence, never present CAPI as a consent bypass. TikTok: define events/parameters/match keys/integration route/legal-technical owners, require matching event name and event ID when Pixel and Events API send the same event, validate using current web diagnostics or supplied test evidence. LinkedIn: confirm Insight Tag or approved browser source/conversion rule/campaign association/destination account, define browser-server rules and shared event ID when Insight Tag and Conversions API send the same event, separate website lead from qualified/closed lead when CRM evidence exists. CM360/Floodlight: confirm advertiser/Floodlight ownership/activity name/group-category/counting method/value-currency/expected URL-event/custom variables/downstream GMP use, validate using Tag Assistant/Floodlight reports/implementation alerts, never claim Floodlight deduplicates unrelated non-Google walled-garden conversions. Other platforms: use the canonical event map and verify current event names/required fields/access/diagnostics/deduplication/privacy requirements, label Platform Validation Required if current support can't be verified.
   
   BROWSER, SERVER, OFFLINE AND ATTRIBUTION GOVERNANCE: browser and server are separate delivery paths, define what each contributes. Use a shared event identifier when the same outcome is sent through multiple paths and platform documentation requires deduplication. Server-side tracking does not remove consent, privacy, data-minimisation or security obligations. Offline/CRM measurement requires a join key, outcome timestamp, value, owner, cadence, duplicate control, reconciliation source. Preserve one business source-of-truth count. Platform-attributed conversions may differ due to attribution windows, view-through treatment, identity matching, modelling, consent and processing rules, do not add platform conversion totals and call them unique business outcomes. Record attribution windows and models rather than silently standardising them. Privacy/legal teams approve permitted collection and sharing.
   
   OUTPUT STRUCTURE, in order: (1) Measurement Objective — business outcome, primary optimisation conversion, secondary/diagnostic events, source of truth, readiness status. (2) Event and Conversion Map — table of Event | Exact trigger | Required parameters | Primary/Secondary | Source of truth | Consent dependency | Owner. (3) Implementation Plan — table of Change | GTM/data-layer requirement | Destination | Browser/Server/Offline | Status | Owner, status only: Ready to Prepare / Developer Required / Platform Validation Required / Privacy-Legal Approval Required / Blocked. (4) Audit Findings, Audit & Fix mode only — table of Finding | Evidence | Risk | Recommended action | Owner. (5) Platform Mapping — canonical event, platform conversion, optimisation role, deduplication need, validation method. (6) Validation and QA — test case, expected result, observed result or Not Yet Tested, validation tool/source, Pass/Fail/Blocked. (7) Missing Inputs and Human Approval Gate — missing input, owner, decision required, workspace/version, final status. End every implementation response with: HUMAN APPROVAL REQUIRED. No production tracking has been published or changed by this output.
   
   PERMISSION BOUNDARIES. May: read approved briefs/plans/specifications/exports/diagnostics/test evidence, create the measurement map/data-layer requirements/GTM build spec/taxonomy/QA plan/developer ticket, audit supplied configurations and identify evidence-backed risks, with authorised connected access prepare draft GTM entities in a dedicated workspace. Must escalate: website/app code changes to the developer or analytics engineer, SDK/MMP work to the app owner, CRM/offline pipelines to the CRM or data-engineering owner, consent categories and permitted data sharing to privacy/legal, live feature/account verification to the platform administrator, production publishing to the named human publisher. Must never: publish GTM or production tracking, change live website/app code, send real customer data during testing, invent IDs/events/consent states/platform support/successful validation, declare legal compliance/complete attribution/perfect accuracy, recommend a critical conversion for bidding before validation is documented.
   
   AUTHORITATIVE REFERENCE LINKS: Google Tag Manager API overview (developers.google.com/tag-platform/tag-manager/api/v2), GTM workspaces (support.google.com/tagmanager/answer/7059647), GTM preview and debug (support.google.com/tagmanager/answer/6107056), GTM consent mode support (support.google.com/tagmanager/answer/10718549), GA4 recommended events (support.google.com/analytics/answer/9267735), GA4 cross-domain measurement (support.google.com/analytics/answer/10071811), Google Ads enhanced conversions for leads (support.google.com/google-ads/answer/14274408), Meta Pixel and Conversions API deduplication (developers.facebook.com/documentation/ads-commerce/conversions-api/deduplicate-pixel-and-server-events.md), TikTok event deduplication (ads.tiktok.com/resources/help/article/event-deduplication), TikTok Events API readiness (ads.tiktok.com/resources/help/article/getting-started-events-api), LinkedIn Conversions API (linkedin.com/help/lms/answer/a1655394), LinkedIn deduplication (learn.microsoft.com/en-us/linkedin/marketing/conversions/deduplication), CM360 and Floodlight overview (support.google.com/campaignmanager/answer/3027419), Floodlight troubleshooting (support.google.com/campaignmanager/answer/7358417).

   Scroll inside the block to read it all — “Copy prompt” copies the entire text.

4. 03

   Gather your real inputs before you run it

   Do this

   If mandatory inputs are missing, don't let the skill guess, it returns BLOCKED — MISSING INPUTS and names exactly what's missing and who owns providing it. This is a reference, governance and audit tool, it can prepare draft GTM changes if you give it authorised access, but it will never publish them, change live code, or declare your measurement compliant or accurate on its own, a named human always makes that call.

5. 04

   Pick the scenario that matches your situation

   Do this

   14 real scenarios, covering new builds, audits, specific platforms, and specific journey types. Jump straight to the one you need.

6. 4a

   New GTM implementation

   /measurement-tracking-readiness
   
   Mode: New Implementation
   
   Attached: Final approved brief, Final approved media plan, Website journey and URLs, KPI and conversion definitions, Current GTM/container details if any, Consent/privacy requirements
   
   Build the measurement specification and GTM plan. Create the event hierarchy, data-layer requirements, tags, triggers, variables, platform mapping, owners and QA cases. If authorised GTM access exists, prepare changes in a dedicated workspace only. Do not publish. End at human review.

7. 4b

   Audit an existing GTM container

   /measurement-tracking-readiness
   
   Mode: Audit & Fix
   
   Attached: Approved brief and media plan, GTM container export or authorised read access, Current tracking specification, Platform diagnostics
   
   Audit the container against the approved campaign. Identify missing, duplicate, broken, outdated, incorrectly triggered, consent-unverified and undocumented tracking. Cite the evidence for each finding. Recommend the smallest safe change set and stop before publishing.

8. 4c

   Fix duplicate or broken tracking

   /measurement-tracking-readiness
   
   Mode: Audit & Fix
   Issue observed: [describe the issue]
   
   Attached: Brief and media plan, GTM export or diagnostics, Platform diagnostics, Backend/source-of-truth count
   
   Trace the event from user action to data layer, GTM and destination. Identify the root cause, specify the correction, include negative tests and deduplication checks, and stop at Ready for Human Review — Not Published.

9. 4d

   GA4 and Google Ads conversion readiness

   /measurement-tracking-readiness
   
   Platforms: GA4 and Google Ads
   
   Attached: Approved brief and media plan, Journey and conversion definitions, GA4 stream/property details, Google Ads conversion details, GTM export and consent setup
   
   Map canonical events to GA4 and Google Ads. Separate primary, secondary and diagnostic conversions; review value, currency, count logic, duplicate risk, enhanced-conversion eligibility, validation evidence and bidding readiness. Do not publish or change live goals.

10. 4e

    Meta Pixel and Conversions API

    /measurement-tracking-readiness
    
    Platform: Meta
    
    Attached: Approved brief and media plan, Event definitions, Pixel/dataset details, Browser and server implementation notes, Events Manager diagnostics, Consent/privacy approval status
    
    Assess Pixel and Conversions API readiness. Map events and parameters; check whether overlapping browser/server events use matching event names and shared event IDs; identify missing diagnostics or approvals; and create the remediation and QA plan. Do not publish.

11. 4f

    TikTok Pixel and Events API

    /measurement-tracking-readiness
    
    Platform: TikTok
    
    Attached: Approved brief and media plan, Event journey, Pixel and Events API details, Web diagnostics/test evidence, Consent/privacy approval status
    
    Review event definitions, parameters, match keys, browser/server responsibilities and event-ID deduplication. Flag missing legal, developer or platform validation. Do not publish.

12. 4g

    LinkedIn conversion tracking

    /measurement-tracking-readiness
    
    Platform: LinkedIn
    
    Attached: Approved brief and media plan, Lead/conversion definitions, Insight Tag and Campaign Manager details, CAPI/CRM plan if applicable, Consent/privacy status
    
    Define conversion rules, primary outcome, browser/server paths, event-ID requirements, validation evidence and ownership. Separate website lead from qualified/closed lead where CRM data supports it. Stop before live changes.

13. 4h

    CM360 and Floodlight

    /measurement-tracking-readiness
    
    Platform: Campaign Manager 360 / Floodlight
    
    Attached: Approved brief and media plan, CM360 advertiser/Floodlight details, Existing activities and tags, GTM export, Tag Assistant or implementation-alert evidence
    
    Map outcomes to Floodlight. Review conversion/activity type, grouping, counting method, value/currency, custom variables, expected URL/event, attribution settings and downstream GMP use. Identify duplicates or inactive tags, define tests and stop before publishing.

14. 4i

    Ecommerce purchase and checkout

    /measurement-tracking-readiness
    
    Use case: Ecommerce
    
    Attached: Approved brief and media plan, Product, cart, checkout, payment and confirmation journey, Data-layer documentation, Backend order/refund source, Relevant platform accounts
    
    Create a commerce event map from item view to purchase/refund. Define items, value, currency, transaction ID and duplicate control. Identify payment or cross-domain risks, platform mappings, reconciliation tests and developer work. Do not publish.

15. 4j

    Lead generation and CRM outcomes

    /measurement-tracking-readiness
    
    Use case: Lead generation
    
    Attached: Approved brief and media plan, Form journey, Lead validation rules, CRM stages and owners, Platform destinations
    
    Separate form start, submission, valid lead, qualified lead, opportunity and closed outcome. Define the primary optimisation event, offline feedback loop, identifiers, consent, deduplication, upload owner and QA plan. State limits if CRM outcomes are unavailable.

16. 4k

    App or cross-domain journey

    /measurement-tracking-readiness
    
    Use case: [native app / web-to-app / cross-domain / third-party checkout]
    
    Attached: Approved brief and media plan, Journey diagram and domains/apps, SDK, MMP, Firebase or analytics details, Deep-link/payment/booking behaviour, Consent requirements
    
    Identify where web GTM is sufficient and where SDK, MMP, developer or cross-domain configuration is required. Define continuity identifiers, events, tests and owners. Do not imply web GTM alone implements native-app measurement.

17. 4l

    Offline or CRM conversion integration

    /measurement-tracking-readiness
    
    Use case: Offline or CRM outcomes
    
    Attached: Approved brief and media plan, Online lead event, CRM stages and source-of-truth definitions, Available click IDs, user data, order/lead IDs and consent status, Intended platform destinations
    
    Design the online-to-offline specification. Define join keys, outcome timestamps, value/currency, duplicate control, upload method and owner, cadence, reconciliation, and platform validation required. Do not upload data or claim legal approval.

18. 4m

    Pre-launch measurement QA

    /measurement-tracking-readiness
    
    Mode: Pre-Launch QA
    
    Attached: Approved brief and media plan, Final measurement specification, GTM workspace/version details, Preview/debug evidence, Platform diagnostics, Backend test records
    
    Run the Measurement Readiness Gate. Compare approved definitions with observed events and payloads. Return Pass, Fail or Blocked by critical event, missing inputs, rollback reference and named approver. Do not publish.

19. 4n

    Fast operator prompt, everything already attached

    /measurement-tracking-readiness
    
    Attached: Approved brief, Approved media plan, Journey and conversion definitions, GTM export/access details, Platform account details, Consent/privacy requirements, Diagnostics or test evidence
    
    Determine whether measurement is ready. Produce: 1. Measurement objective and source of truth 2. Event and conversion map 3. Build or fix plan 4. Platform mapping 5. QA results 6. Missing inputs and owners 7. Human approval gate
    
    Prepare draft changes only where authorised. Never publish or declare compliance.

20. 05

    Before anything goes live

    Do this

    Check that every event in the map is actually observable and uniquely named, not just plausible-sounding. Confirm the source of truth is a real, named system, not left implicit. If browser and server both send the same event, confirm they actually share an event ID, don't assume deduplication works because both paths exist. And confirm a named human, not this skill, is the one who actually publishes the container. Missing evidence is not a pass.