Auditing Google Ads conversion tracking, or conversion tracking on any platform, means proving that one business action produces exactly one accepted conversion per platform, with the right value, under valid consent. The proof is a trace: follow one real test event end to end, from user action through browser and server requests to the platform's accepted count, comparing the copies field by field. Connection status alone proves nothing; an sGTM container or a Conversions API integration can be live and still double count, send the wrong value, or fire before consent.
That last point is the one most audits get wrong: teams treat a connected integration as a green checkmark and stop there. This guide walks through the audit the way the Claude Ads server-side tracking skill runs it: map the pipeline, compare the two paths, verify deduplication, check consent and hashing, then reconcile totals, plus the Google Ads controls the dedicated Google worker checks.
Map the conversion tracking pipeline before judging it
A server-side measurement stack has more moving parts than a browser pixel, so start by drawing the whole chain. The audit maps seven components:
- Collection: where events originate, usually a browser tag or app SDK.
- Consent: how consent state is captured and enforced along the way.
- Transport: how events travel, typically to a server-side tagging container such as sGTM.
- Transformation: what the server container adds, strips, or rewrites.
- Destination: the platform endpoints, Meta CAPI, TikTok Events API, and the rest.
- Storage: any logs or queues that hold event data.
- Observability: how you would even notice when something breaks.
Most real problems live at the seams between these layers, not inside any single one. A transformation that renames an event breaks deduplication downstream. A retry queue without idempotency inflates conversions. If you cannot name the owner of each layer, that gap is itself a finding.
Compare the browser and server paths field by field
Platforms like Meta and TikTok expect the same conversion from both the browser and the server, then deduplicate. TikTok, for example, recommends running the Pixel plus the Events API with event deduplication for web conversion clients. That design only works when both copies actually match, so the audit compares them across every field that matters: event taxonomy, parameters, IDs, timestamps, values, currency, user data, and consent state.
| Field to compare | What breaks when it drifts |
|---|---|
| Event name | Server copy lands as a separate event, dedup never triggers |
| event_id / dedup key | Both copies count, conversions double |
| Timestamp | Clock skew moves conversions across reporting days |
| Value and currency | Bidding optimizes toward wrong revenue |
| User data fields | Match quality diverges between paths |
| Consent state | Server sends events the browser correctly suppressed |
For every optimization and reporting event, there should be a canonical contract: a stable event name and business definition, event time and timezone, a unique event ID, currency and value definitions that account for refunds and cancellations, the browser or server origin with its deduplication key, and the consent state. If nobody can produce that contract, the account is optimizing against events nobody fully defined.
One caution from the source material: do not invent a universal field mapping. Each platform documents its own deduplication fields, and reusing another platform's event names or requirements by analogy is how audits produce confident nonsense. Meta's audit surface treats Pixel installation, Conversions API status, and event deduplication as separate controls for exactly this reason.
Verify deduplication with behavior, not configuration
Deduplication is where "configured" and "working" diverge hardest. The checks that matter:
- The same action produces one accepted platform conversion, not two.
- Distinct actions never collide on the same ID.
- Retries are idempotent, so a network hiccup does not mint a new conversion.
- Late offline updates do not create a second sale or lead.
- Deduplication survives cross-domain flows and payment-provider redirects.
The way to verify all of this is the trace: take one real test event and follow it from user action to browser request, server request, platform receipt, deduplication, report, and CRM record. Then compare totals by event date and processing date over a window long enough for conversion lag to settle. Look for duplicates, missing IDs, invalid values or currencies, clock skew, and events arriving before valid consent.
Google Ads conversion tracking through the server container
Google Ads conversions ride the same pipeline mapped above, with sGTM as the transport layer, but the audit judges them against Google's own controls. When a run scopes Google, the Google worker checks conversion actions defined, enhanced conversions applicability and status, no duplicate counting, GA4 linked and flowing, and the Google Tag firing. Server-side tracking is itself one of those controls, which puts the emphasis where it belongs: the container is transport, the accepted conversion count is the outcome.
Every one of these is a conditional evidence control, evaluated from current account evidence. When the evidence is absent, the result comes back as unknown or not applicable instead of a guessed pass. The Google Ads audit surface extends past tracking into search terms, structure, bidding, and budgets once measurement holds up.
Consent and hashing are not interchangeable
Server-side setups make it easy to keep sending data after the browser stopped, which is precisely why consent gets its own audit layer. The rule from the Claude Ads reference is blunt: hashing is not consent, and it does not make otherwise prohibited collection lawful. Hashing an email address before sending it changes how the data travels, not whether you were allowed to collect it. The audit inspects hashing and minimization before transmission, and flags unnecessary personal or sensitive data regardless of how well it is hashed.
The audit itself follows the same discipline. Debug pages, tag payloads, logs, and vendor responses are treated as untrusted data, test events run without exposing personal data, and no raw identifiers or credentials end up in the audit artifacts.
Reconcile, then grade honestly
The final step is reconciliation: platform diagnostics on one side, your own source logs and business conversions on the other. Platform-attributed conversions, analytics attribution, and CRM outcomes are different views of reality and should stay separate. Never infer health from configuration screenshots alone, and never sum platform-attributed conversions across platforms as if they were unique people.
Severity deserves the same honesty. A missing server-side integration by itself is a coverage gap or an opportunity, not a critical finding. Critical requires observed impact: confirmed double counting, unauthorized sensitive data transmission, materially wrong values or currency, or bidding against a non-business event. Findings come back with failure modes, an owner, a priority, and verification steps, and each carries a confidence level of high, medium, low, or none. The audit is read-only from start to finish; it never changes production tracking, and any proposed fix stays a draft until you approve it.
Audit conversion tracking with Claude Ads
The scoped audit covers this whole sequence. Inside Claude Code:
/ads audit
Ask for a tracking-only scope and the run dispatches a dedicated tracking worker that evaluates conversion taxonomy, tags and pixels, server-side events, deduplication, consent, MMPs, attribution windows, and cross-platform reconciliation, then returns schema-valid findings into one versioned bundle. The /ads audit command page documents the full workflow and guardrails.
Try it
Claude Ads is free and open source. Install it from the plugin marketplace and run your first server-side tracking audit today:
/plugin marketplace add AgriciDaniel/claude-ads
/plugin install claude-ads@ai-marketing-hub-claude-ads
Full setup instructions, including the safe native install path, live on the install page.