Reusable AI capability
Audit Conversion Tracking Before Analytics Release
Review Google Tag Manager, GA4, ads, and consent-mode evidence to identify missing, duplicate, or unreliable conversion events before a tracking change is published or trusted for reporting.
This Skill is a reusable set of instructions based on the linked Amo.ng Prompt or Workflow. It tells you what to provide, how to apply the method and how to know when the task is complete. It does not run automatically.
# Audit Conversion Tracking Before Analytics Release Skill ID: AMO-S-000047 Skill URL: https://amo.ng/skills/audit-conversion-tracking-before-analytics-release Purpose: Produce an evidence-based QA brief for conversion tracking implementations, covering triggers, tags, parameters, data-layer events, consent behavior, duplicate firing, platform reconciliation, and safe release controls. Required inputs: - Conversion goals and expected events, including event names, triggers, platforms, and success criteria. - GTM container export or screenshots of relevant tags, triggers, variables, data-layer pushes, and consent settings. - GA4, Google Ads, Tag Assistant, DebugView, browser network, server log, CRM, or backend evidence where available. - Known user journeys such as form submission, checkout, lead capture, subscription, account creation, or thank-you page flow. - Recent changes, affected pages, environments, consent requirements, duplicate-event concerns, and release constraints. How to use: When to use: - A GTM container change, GA4 event setup, Google Ads conversion, or consent-mode update is ready for pre-publish QA. - Reported leads, purchases, signups, or other conversions differ between GA4, ad platforms, CRM, or backend records. - A site migration, checkout change, landing-page update, or form change may affect conversion measurement. - Marketing, analytics, or RevOps teams need a traceable tracking QA plan before using conversion data for spend or performance decisions. When not to use: - Do not use as a general marketing performance analysis when tracking integrity is not in question. - Do not use to approve legal compliance for consent, privacy, or data processing; use it to organize evidence and questions for qualified review. - Do not use to publish GTM changes, edit tags, or change ad-platform settings without explicit authorization. - Do not use when no implementation evidence is available; first gather container exports, event specs, screenshots, debug traces, or platform reports. Instructions: 1. Open AMO-P-000226, supply its required inputs, and run the complete source Prompt in ChatGPT. Review its evidence register and limitations before using the result. 2. Map each conversion journey from user action to data-layer signal, GTM trigger, tag firing, platform ingestion, and downstream reporting or reconciliation point. 3. Separate supplied evidence from assumptions, inferred risks, missing implementation details, and unresolved questions. 4. Check for missing events, duplicate events, broken triggers, unstable selectors, incorrect parameters, consent-mode conflicts, cross-domain or iframe issues, and environment mismatches. 5. Compare expected conversion counts and identifiers across inspectable sources, noting timing windows, attribution differences, sampling, deduplication, and platform-specific definitions. 6. Prioritize issues by decision risk, spend impact, privacy or consent sensitivity, reporting dependency, and ease of pre-release verification. 7. Produce a release recommendation such as ready for human publish review, publish with conditions, hold for fixes, or retest required, without claiming any container was published. Expected output: A conversion-tracking QA brief with journey map, tag and trigger findings, consent and duplication risks, platform reconciliation notes, issue severity, required fixes or checks, pre-publish test cases, post-release monitoring plan, and human approval gates. Constraints and boundaries: - Require evidence for claims about tag firing, event counts, consent behavior, and platform discrepancies. - Do not treat GA4, ad-platform, CRM, or backend numbers as identical without explaining definition, timing, and deduplication differences. - Do not provide legal determinations about consent or privacy; identify evidence gaps and route consequential questions to qualified reviewers. - Do not imply live testing, publishing, or production changes unless the user supplies evidence that they occurred. - A fired tag is not proof of destination acceptance, processing, attribution or reporting. Keep those evidence layers separate. Use sanitized test records, never customer/payment data or credentials. Test consent behaviour against supplied policy, not an invented legal determination; preserve the release version, owner approval and rollback plan. Based on Prompt: Google Tag Manager Conversion Tracking QA Brief Source ID: AMO-P-000226 https://amo.ng/prompts/google-tag-manager-conversion-tracking-qa-brief Completion criteria: Complete when: - Each issue links to a supplied tag, trigger, variable, debug trace, platform report, screenshot, or clearly labeled inference. - The QA plan covers at least one happy path and relevant failure or duplicate-fire scenarios for each critical conversion. - Consent, deduplication, attribution, and platform reconciliation risks are explicitly addressed when applicable. - Release status is conditional on observable checks and identifies owners for unresolved items. - The output distinguishes pre-publish checks from post-release monitoring and from decisions requiring human approval. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Audit Conversion Tracking Before Analytics Release Skill ID: AMO-S-000047 Skill URL: https://amo.ng/skills/audit-conversion-tracking-before-analytics-release Purpose: Produce an evidence-based QA brief for conversion tracking implementations, covering triggers, tags, parameters, data-layer events, consent behavior, duplicate firing, platform reconciliation, and safe release controls. Required inputs: - Conversion goals and expected events, including event names, triggers, platforms, and success criteria. - GTM container export or screenshots of relevant tags, triggers, variables, data-layer pushes, and consent settings. - GA4, Google Ads, Tag Assistant, DebugView, browser network, server log, CRM, or backend evidence where available. - Known user journeys such as form submission, checkout, lead capture, subscription, account creation, or thank-you page flow. - Recent changes, affected pages, environments, consent requirements, duplicate-event concerns, and release constraints. How to use: When to use: - A GTM container change, GA4 event setup, Google Ads conversion, or consent-mode update is ready for pre-publish QA. - Reported leads, purchases, signups, or other conversions differ between GA4, ad platforms, CRM, or backend records. - A site migration, checkout change, landing-page update, or form change may affect conversion measurement. - Marketing, analytics, or RevOps teams need a traceable tracking QA plan before using conversion data for spend or performance decisions. When not to use: - Do not use as a general marketing performance analysis when tracking integrity is not in question. - Do not use to approve legal compliance for consent, privacy, or data processing; use it to organize evidence and questions for qualified review. - Do not use to publish GTM changes, edit tags, or change ad-platform settings without explicit authorization. - Do not use when no implementation evidence is available; first gather container exports, event specs, screenshots, debug traces, or platform reports. Instructions: 1. Open AMO-P-000226, supply its required inputs, and run the complete source Prompt in ChatGPT. Review its evidence register and limitations before using the result. 2. Map each conversion journey from user action to data-layer signal, GTM trigger, tag firing, platform ingestion, and downstream reporting or reconciliation point. 3. Separate supplied evidence from assumptions, inferred risks, missing implementation details, and unresolved questions. 4. Check for missing events, duplicate events, broken triggers, unstable selectors, incorrect parameters, consent-mode conflicts, cross-domain or iframe issues, and environment mismatches. 5. Compare expected conversion counts and identifiers across inspectable sources, noting timing windows, attribution differences, sampling, deduplication, and platform-specific definitions. 6. Prioritize issues by decision risk, spend impact, privacy or consent sensitivity, reporting dependency, and ease of pre-release verification. 7. Produce a release recommendation such as ready for human publish review, publish with conditions, hold for fixes, or retest required, without claiming any container was published. Expected output: A conversion-tracking QA brief with journey map, tag and trigger findings, consent and duplication risks, platform reconciliation notes, issue severity, required fixes or checks, pre-publish test cases, post-release monitoring plan, and human approval gates. Constraints and boundaries: - Require evidence for claims about tag firing, event counts, consent behavior, and platform discrepancies. - Do not treat GA4, ad-platform, CRM, or backend numbers as identical without explaining definition, timing, and deduplication differences. - Do not provide legal determinations about consent or privacy; identify evidence gaps and route consequential questions to qualified reviewers. - Do not imply live testing, publishing, or production changes unless the user supplies evidence that they occurred. - A fired tag is not proof of destination acceptance, processing, attribution or reporting. Keep those evidence layers separate. Use sanitized test records, never customer/payment data or credentials. Test consent behaviour against supplied policy, not an invented legal determination; preserve the release version, owner approval and rollback plan. Based on Prompt: Google Tag Manager Conversion Tracking QA Brief Source ID: AMO-P-000226 https://amo.ng/prompts/google-tag-manager-conversion-tracking-qa-brief Completion criteria: Complete when: - Each issue links to a supplied tag, trigger, variable, debug trace, platform report, screenshot, or clearly labeled inference. - The QA plan covers at least one happy path and relevant failure or duplicate-fire scenarios for each critical conversion. - Consent, deduplication, attribution, and platform reconciliation risks are explicitly addressed when applicable. - Release status is conditional on observable checks and identifies owners for unresolved items. - The output distinguishes pre-publish checks from post-release monitoring and from decisions requiring human approval.Copy Skill copies the full Skill instructions. Use with AI copies those instructions with a short guide for your chosen AI tool. Both actions only copy text—they do not send anything to an AI provider or run the Skill.
Purpose
Produce an evidence-based QA brief for conversion tracking implementations, covering triggers, tags, parameters, data-layer events, consent behavior, duplicate firing, platform reconciliation, and safe release controls.
Required inputs
Have these details available before following the usage instructions.
- Conversion goals and expected events, including event names, triggers, platforms, and success criteria.
- GTM container export or screenshots of relevant tags, triggers, variables, data-layer pushes, and consent settings.
- GA4, Google Ads, Tag Assistant, DebugView, browser network, server log, CRM, or backend evidence where available.
- Known user journeys such as form submission, checkout, lead capture, subscription, account creation, or thank-you page flow.
- Recent changes, affected pages, environments, consent requirements, duplicate-event concerns, and release constraints.
How to use this Skill
When to use:
- A GTM container change, GA4 event setup, Google Ads conversion, or consent-mode update is ready for pre-publish QA.
- Reported leads, purchases, signups, or other conversions differ between GA4, ad platforms, CRM, or backend records.
- A site migration, checkout change, landing-page update, or form change may affect conversion measurement.
- Marketing, analytics, or RevOps teams need a traceable tracking QA plan before using conversion data for spend or performance decisions.
When not to use:
- Do not use as a general marketing performance analysis when tracking integrity is not in question.
- Do not use to approve legal compliance for consent, privacy, or data processing; use it to organize evidence and questions for qualified review.
- Do not use to publish GTM changes, edit tags, or change ad-platform settings without explicit authorization.
- Do not use when no implementation evidence is available; first gather container exports, event specs, screenshots, debug traces, or platform reports.
Instructions:
1. Open AMO-P-000226, supply its required inputs, and run the complete source Prompt in ChatGPT. Review its evidence register and limitations before using the result.
2. Map each conversion journey from user action to data-layer signal, GTM trigger, tag firing, platform ingestion, and downstream reporting or reconciliation point.
3. Separate supplied evidence from assumptions, inferred risks, missing implementation details, and unresolved questions.
4. Check for missing events, duplicate events, broken triggers, unstable selectors, incorrect parameters, consent-mode conflicts, cross-domain or iframe issues, and environment mismatches.
5. Compare expected conversion counts and identifiers across inspectable sources, noting timing windows, attribution differences, sampling, deduplication, and platform-specific definitions.
6. Prioritize issues by decision risk, spend impact, privacy or consent sensitivity, reporting dependency, and ease of pre-release verification.
7. Produce a release recommendation such as ready for human publish review, publish with conditions, hold for fixes, or retest required, without claiming any container was published.
Expected output:
A conversion-tracking QA brief with journey map, tag and trigger findings, consent and duplication risks, platform reconciliation notes, issue severity, required fixes or checks, pre-publish test cases, post-release monitoring plan, and human approval gates.
Constraints and boundaries:
- Require evidence for claims about tag firing, event counts, consent behavior, and platform discrepancies.
- Do not treat GA4, ad-platform, CRM, or backend numbers as identical without explaining definition, timing, and deduplication differences.
- Do not provide legal determinations about consent or privacy; identify evidence gaps and route consequential questions to qualified reviewers.
- Do not imply live testing, publishing, or production changes unless the user supplies evidence that they occurred.
- A fired tag is not proof of destination acceptance, processing, attribution or reporting. Keep those evidence layers separate. Use sanitized test records, never customer/payment data or credentials. Test consent behaviour against supplied policy, not an invented legal determination; preserve the release version, owner approval and rollback plan.
Based on an Amo.ng Prompt
Google Tag Manager Conversion Tracking QA Brief
Open the linked Prompt to read the instructions this Skill is based on.
Open prompt
You are an expert Google Tag Manager measurement QA analyst specializing in web and server-side tagging, data-layer contracts, GA4 events and key events, Google Ads conversion actions, Consent Mode, debugging, reconciliation, and controlled container releases.
Inspect the supplied conversion-tracking implementation and produce an evidence-based QA brief. Determine whether each conversion occurs at the correct business moment, fires once, contains the correct values, respects the required consent state, reaches the intended destination, and appears correctly in downstream reporting.
Do not access, edit, preview, submit, approve, publish, or roll back a GTM container unless the user explicitly authorizes that action and provides the required access.
## Context Placeholders
Use the context below. If critical evidence is missing, request it in one consolidated list before reaching conclusions. If non-critical information is missing, continue with clearly labeled assumptions, unknowns, and unassessed areas.
- [Website, application, and test environment]
- [GTM account, container IDs, container types, workspace, and live version]
- [Business conversion definitions and source-of-truth records]
- [Conversion journeys and expected outcomes]
- [Tags, triggers, variables, exceptions, sequencing, and templates]
- [Data-layer events and sanitized example payloads]
- [GA4 property, data stream, events, and key-event settings]
- [Google Ads destinations and conversion actions]
- [Consent Management Platform, Consent Mode, policy requirements, and regions]
- [Hardcoded tags, CMS plugins, platform integrations, and server-side tagging]
- [Tag Assistant, DebugView, network, and platform diagnostic evidence]
- [Reporting discrepancies, incidents, and recent changes]
- [Test accounts, transactions, devices, browsers, and permitted actions]
- [Owners, approval requirements, rollback constraints, and deadline]
## Important Constraints
- Do not invent container settings, tag behavior, trigger conditions, data-layer values, consent states, network requests, diagnostic results, report counts, conversion actions, processing behavior, or test outcomes.
- Separate confirmed evidence, observations, inferred behavior, hypotheses, risks, unknowns, and recommendations.
- Tie every material finding to a supplied configuration, sanitized payload, screenshot, debug record, network request, platform diagnostic, report, or business requirement.
- Do not claim that a tag fired, failed, or delivered data unless the supplied evidence demonstrates that result.
- Do not treat a tag appearing under “Tags Fired” as proof that the destination accepted, processed, attributed, or reported the conversion.
- Do not treat a successful network request as proof that the event contained correct values or produced the intended reporting result.
- Distinguish these evidence layers:
1. Business conversion or source-of-truth record
2. Website or application state
3. Data-layer event and payload
4. GTM trigger and tag evaluation
5. Browser or server network delivery
6. Destination collection or diagnostic evidence
7. Processed platform reporting
- Use current terminology. Distinguish GA4 events and key events from Google Ads conversion actions.
- Do not assume GA4, Google Ads, Campaign Manager, Meta, or another destination processes, deduplicates, attributes, or reports events identically.
- Identify every tagging route, including GTM containers, hardcoded Google tags, CMS plugins, ecommerce integrations, third-party scripts, server-side containers, and platform imports.
- Do not assume that GTM firing options provide complete business-level duplicate prevention.
- For transactional events, verify that the transaction or order identifier is dynamic, unique, stable, non-personal, and consistently mapped.
- Do not expose credentials, authentication headers, customer records, email addresses, phone numbers, payment data, private URLs, or unnecessary personal information.
- Use sanitized payloads and test records.
- Do not recommend sending personal information to GA4.
- Treat enhanced-conversion or user-provided-data handling as privacy-sensitive. Require the appropriate policy, privacy, and platform-owner review.
- Do not determine the legally required consent state. Test technical behavior against the supplied organizational policy and require privacy review where requirements are unclear.
- Verify that consent defaults occur before relevant measurement activity and that consent updates occur following user interaction at the required time.
- Review `analytics_storage`, `ad_storage`, `ad_user_data`, and `ad_personalization` where applicable.
- Do not assume that absent DebugView data proves the implementation is broken; consider consent, privacy controls, filters, blockers, configuration, and debugging state.
- Do not compare GTM, GA4, Google Ads, CRM, and backend totals until their conversion definitions, identifiers, time basis, attribution basis, filters, and processing windows are documented.
- Do not recommend suppressing duplicate firing with a broad “once per page” rule until the intended event semantics and user journey are confirmed.
- Do not publish changes directly from an unreviewed workspace.
- Require a named version, change description, test evidence, approval, rollback path, and post-release verification before publication.
- Do not describe a test as passed unless its result was supplied.
- Make recommendations specific to the supplied website, container, events, platforms, consent requirements, and business definitions.
## QA Instructions
1. Define every business conversion being tested. For each conversion, identify:
- business meaning;
- completion condition;
- source-of-truth system;
- unique record or transaction identifier;
- expected value and currency behavior;
- intended analytics and advertising destinations;
- owner;
- reporting use.
2. Map the complete measurement architecture:
- website or application;
- data layer;
- GTM web container;
- Google tag;
- GA4 event tags;
- Google Ads conversion tags;
- Conversion Linker;
- hardcoded tags;
- CMS or ecommerce integrations;
- optional server-side container;
- destination platforms;
- backend, CRM, order, booking, or lead system.
3. Inventory all relevant GTM tags, triggers, variables, exceptions, tag sequencing rules, firing options, custom templates, Custom HTML, workspaces, environments, and container versions.
4. Trace each conversion from the user action to the source-of-truth record and every intended reporting destination.
5. Audit data-layer events for:
- event name;
- push timing;
- number of pushes;
- parameter names;
- parameter types;
- required and optional values;
- null and undefined values;
- stale values from previous events;
- ecommerce object structure;
- transaction or order identifier;
- value and currency;
- item data;
- consent state;
- personal or sensitive information.
6. Audit tags, triggers, and variables for:
- incorrect or overlapping trigger conditions;
- multiple tags responding to the same event;
- triggers based on unstable page text or CSS selectors;
- confirmation-page reloads;
- repeated clicks or form submissions;
- history and route changes;
- single-page application behavior;
- incorrect event names;
- unresolved variables;
- wrong data-layer versions;
- stale sample data;
- exception-trigger conflicts;
- sequencing assumptions;
- environment or hostname mistakes.
7. Investigate duplicate-conversion paths, including:
- repeated data-layer pushes;
- duplicate GTM containers;
- hardcoded tags running alongside GTM;
- CMS plugins or native integrations;
- client-side and server-side delivery of the same conversion;
- multiple Google Ads conversion actions;
- GA4-imported and directly tagged Ads conversions;
- page reloads, back navigation, and resubmission;
- webhook or server retries;
- missing, static, reused, or inconsistently formatted transaction IDs;
- duplicate destination requests;
- testing activity appearing in production reporting.
8. Investigate missing-conversion paths, including:
- absent data-layer events;
- trigger-condition failures;
- missing required values;
- JavaScript errors;
- blocked containers or requests;
- consent restrictions;
- cross-domain or payment-provider transitions;
- single-page application navigation;
- iframe boundaries;
- authentication or destination configuration errors;
- unpublished workspace changes;
- reporting filters or processing delays.
9. Review Consent Mode and CMP behavior. Test, where applicable:
- initial page load before a choice;
- acceptance of all categories;
- rejection of all optional categories;
- customized choices;
- returning users with a stored choice;
- consent revocation;
- consent updates before page transitions;
- region-specific behavior;
- tag built-in and additional consent checks;
- tags fired, blocked, or adjusted under each state.
10. Review GA4 configuration and delivery:
- property and data-stream identifiers;
- Google tag destinations;
- event names and parameters;
- recommended-event alignment;
- key-event status;
- DebugView evidence;
- Realtime evidence where supplied;
- internal and developer traffic filters;
- unwanted referrals and cross-domain behavior where relevant;
- ecommerce parameters;
- duplicate purchase protection;
- processed reporting evidence.
11. Review Google Ads configuration and delivery:
- destination or account identifier;
- conversion ID and label;
- conversion action;
- primary or secondary use where supplied;
- counting behavior;
- value and currency;
- transaction or order ID;
- Conversion Linker;
- enhanced-conversion configuration where applicable;
- consent signals;
- conversion diagnostics;
- imported versus directly tagged conversions;
- processed reporting evidence.
12. Where server-side tagging is used, review:
- client-to-server request;
- server-container client;
- event transformations;
- destination tags;
- duplicate client and server delivery;
- event identifiers;
- request validation;
- consent propagation;
- retry behavior;
- logging and sensitive-data controls.
13. Design a controlled test plan that covers:
- one valid conversion;
- repeated clicking or submission;
- page refresh;
- back and forward navigation;
- duplicate data-layer event;
- missing and malformed parameters;
- new and returning visitors;
- each material consent choice;
- single-page application navigation where applicable;
- cross-domain or payment-provider journeys;
- client-side and server-side delivery where applicable;
- test transaction cancellation or cleanup;
- non-converting journeys that must not fire a conversion.
14. For every test, require evidence from the relevant layers. Use Tag Assistant, GTM Preview, the browser network panel, GA4 DebugView, destination diagnostics, processed reports, and source-of-truth records where applicable.
15. Reconcile observed conversions against the business source of truth. Explain definition, timing, attribution, consent, processing, and identifier differences before classifying a discrepancy as a defect.
16. Prioritize findings by measurement impact, privacy risk, financial or bidding impact, frequency, detectability, reversibility, evidence strength, and urgency.
17. Produce the smallest safe remediation plan. Separate:
- immediate containment;
- configuration correction;
- developer or data-layer work;
- consent remediation;
- destination-platform correction;
- testing;
- publishing;
- rollback;
- post-release reconciliation.
## Output Format
Use markdown headings and concise tables. Do not repeat generic filler beneath each heading.
### Context Review and Evidence Status
Provide:
| Evidence or Configuration | Supplied | Reliability | Gap | Required Follow-Up |
|---|---:|---|---|---|
List all assumptions, unavailable settings, missing debug evidence, and unassessed destinations.
### Executive QA Summary
Summarize:
- conversions reviewed;
- strongest confirmed findings;
- duplicate and missing-event exposure;
- consent risks;
- destination and reporting discrepancies;
- immediate containment;
- publication readiness;
- owner decisions required.
### Measurement Architecture
Map:
| Stage | System or Component | Identifier | Input | Output | Owner | Evidence |
|---:|---|---|---|---|---|---|
Include parallel or overlapping tagging routes.
### Conversion Definition and Source-of-Truth Matrix
Provide:
| Conversion | Business Completion Condition | Source of Truth | Unique Identifier | Intended Destinations | Reporting Use | Owner |
|---|---|---|---|---|---|---|
Flag conversions without an agreed business definition or reliable source of truth.
### GTM Tracking Inventory
Provide:
| Component | Name or ID | Purpose | Trigger or Input | Destination | Consent Requirement | Live Version | Finding |
|---|---|---|---|---|---|---|---|
Include tags, triggers, variables, exceptions, hardcoded tags, plugins, and server-side components where relevant.
### Conversion Traceability Matrix
Provide:
| Conversion | User Action | Data-Layer Event | GTM Trigger | Tag | Network Destination | Platform Record | Source-of-Truth Record |
|---|---|---|---|---|---|---|---|
Mark each stage as confirmed, failed, unknown, or not applicable.
### Data-Layer and Parameter Review
Provide:
| Event | Parameter | Expected Type or Value | Observed Evidence | Destination Mapping | Risk | Required Fix |
|---|---|---|---|---|---|---|
Review identifiers, value, currency, items, consent state, nulls, undefined values, and unnecessary personal data.
### Duplicate and Missing Event Findings
Provide:
| ID | Conversion | Failure Path | Duplicate or Missing | Evidence | Likely Cause | Reporting Impact | Confidence |
|---|---|---|---|---|---|---|---|
Do not classify a hypothesis as confirmed without evidence.
### Consent and Privacy-Control Review
Provide:
| Test State | Expected Consent State | Observed State | Tags Fired or Blocked | Data Sent | Evidence | Review Required |
|---|---|---|---|---|---|---|
Cover default, accept, reject, customize, returning-user, and revocation behavior where applicable.
Do not provide a legal-compliance conclusion.
### Platform Delivery and Reporting Review
Provide:
| Destination | Expected Event or Action | Delivery Evidence | Diagnostic Evidence | Reporting Evidence | Discrepancy | Explanation or Next Check |
|---|---|---|---|---|---|---|
Keep GA4 key events and Google Ads conversion actions distinct.
### QA Test Plan and Results
Provide:
| Test ID | Journey and State | Expected Result | Evidence Required | Observed Result | Status | Owner |
|---|---|---|---|---|---|---|
Use `Not run` when no result was supplied.
### Risk Register
Provide:
| Risk | Evidence | Measurement Impact | Privacy or Business Impact | Likelihood | Priority | Owner |
|---|---|---|---|---|---|---|
### Prioritized Remediation Plan
Provide:
| Priority | Action | Component | Risk Addressed | Owner | Preconditions | Validation | Review Gate |
|---:|---|---|---|---|---|---|---|
Separate configuration changes from developer work and destination-platform changes.
### Publish Approval and Rollback Plan
Define:
- workspace and affected components;
- current live version;
- proposed version name and description;
- approved change set;
- required test evidence;
- analytics approval;
- privacy approval where applicable;
- development or ecommerce-owner approval;
- publication owner;
- publication window;
- rollback version and trigger;
- test-data cleanup;
- duplicate or missing-record reconciliation;
- post-publication verification.
### Post-Release Monitoring Plan
Provide:
| Signal | Source | Expected Behavior | Decision Rule | Owner | Response | Review Period |
|---|---|---|---|---|---|---|
Do not invent numeric thresholds. Explain how baselines should be established when operating evidence is unavailable.
### Follow-Up Questions
List only questions that could materially change the findings, publication decision, or remediation priority.
## Verification Checklist
Before finalizing the brief, confirm that:
- every conversion has a defined business completion condition;
- every conversion has an identified source of truth;
- all GTM, hardcoded, plugin, platform-native, and server-side tagging routes were considered;
- the live container version and proposed workspace were distinguished;
- data-layer events, triggers, tags, variables, and destination requests were traced separately;
- a fired tag was not treated as proof of destination collection or reporting;
- GA4 events and key events were distinguished from Google Ads conversion actions;
- duplicate data-layer pushes, tags, containers, conversion actions, reloads, and retries were considered;
- transaction or order identifiers were checked for uniqueness, stability, dynamic values, and absence of personal information;
- missing, null, undefined, malformed, and stale values were reviewed;
- value, currency, item, and identifier mappings were verified where applicable;
- Consent Mode defaults, updates, timing, and material consent choices were tested;
- `analytics_storage`, `ad_storage`, `ad_user_data`, and `ad_personalization` were reviewed where applicable;
- no legal-compliance conclusion was presented;
- no personal data, credentials, customer records, or payment information was reproduced;
- Preview Mode, Tag Assistant, network, destination diagnostic, and reporting evidence were distinguished;
- source-of-truth totals were not compared with platform totals without documenting definition and timing differences;
- no test was described as passed without supplied evidence;
- no container change was recommended for publication without approval and rollback controls;
- every material finding is tied to evidence or labeled as unverified;
- post-publication validation and reconciliation are included.
## Final Instruction to Begin
Begin by reviewing the business conversion definitions, source-of-truth records, GTM containers and live version, tracking architecture, tags, triggers, variables, sanitized data-layer payloads, consent setup, destination configuration, debug evidence, reporting discrepancies, and allowed test actions.
If critical evidence is missing, request it in one consolidated list. Otherwise, produce the complete Google Tag Manager Conversion Tracking QA Brief in the requested markdown format.
Completion criteria
Complete when:
- Each issue links to a supplied tag, trigger, variable, debug trace, platform report, screenshot, or clearly labeled inference.
- The QA plan covers at least one happy path and relevant failure or duplicate-fire scenarios for each critical conversion.
- Consent, deduplication, attribution, and platform reconciliation risks are explicitly addressed when applicable.
- Release status is conditional on observable checks and identifies owners for unresolved items.
- The output distinguishes pre-publish checks from post-release monitoring and from decisions requiring human approval.
Was this useful?
Related Prompts
Browse PromptsReview an Audit Sampling and Control-Test Design
Challenge a proposed audit sampling and control-test design for population coverage, selection logic, evidence requirements, exception handling and defensible inference before testing begins.
View prompt
35 views · 3 copies
Automate KPI Reporting from Approved Metric Definitions
Implement a repeatable KPI-reporting process from approved metric definitions, with traceable calculations, authoritative reconciliation, failure and rerun tests, disabled delivery, and recovery evidence.
Analytical Conclusion Sensitivity Review
Test whether a consequential analytical conclusion survives plausible changes to data, cohort, definitions, assumptions, model choices, and missing-information treatment.
Data Lineage Break Investigation
Reconstruct where a data product diverged from authoritative lineage, bound affected outputs and decisions, and define safe repair and reprocessing.
Forecast Assumption and Model Drift Challenge
Challenge forecast assumptions, structural stability, backtest evidence, scenario sensitivity, and decision thresholds before relying on projected outcomes.
Knowledge Entitlement Drift Review
Reconcile authoritative access policy with effective permissions across source, ingestion, index, cache, retrieval, citation, and response layers.