--- name: implement-server-side-tagging description: >- Supports moving conversion measurement onto a first-party server container so data stops leaking to ad blockers, tracking prevention, and script weight, routing browser hits through a custom subdomain to a server-side GTM container that forwards to Google Ads and GA4. The provisioning, DNS/SSL, and container configuration are infrastructure work done by humans; VigilDog contributes the decision evidence (quantifying current data loss vs backend numbers) and the launch-safety checks (parallel-run count comparison and double-count detection via GAQL). Use when client-side loss is measurable and material. Not the base tag build (set-up-google-ads-conversion-tracking), not consent collection (configure-google-consent-mode, consent gaps are not fixed by a server), and not hashed-data attribution recovery (implement-enhanced-conversions), though the server can carry that data too. --- # Server-Side Tagging Support ## Purpose Shift tag processing from the visitor's browser to a server you control: the browser sends one stream to a first-party subdomain, and the server container forwards clean events to Google Ads and analytics. Benefits are recovered conversions (blockers and browser restrictions bite less), lighter pages, and a single controlled egress for measurement data. VigilDog's role is before/after truth: prove the loss justifies the effort, then prove the migration neither dropped nor doubled conversions. ## When to run - Backend orders/leads consistently exceed Google Ads conversions by a margin ad-blocker/browser loss plausibly explains (after tracking bugs are ruled out). - The audience skews privacy-tooled (tech, EU browsers with tracking prevention). - Page-speed work wants marketing scripts off the critical path. - Bidding needs maximal signal fidelity and the account can support ~€20+/month hosting plus setup effort. ## When NOT to run - The gap is a tracking bug (missing tag, bad trigger, no dedup), fix via set-up-google-ads-conversion-tracking / implement-transaction-id-deduplication first; a server faithfully forwards broken data. - The loss is consent-driven, configure-google-consent-mode; server routing does not create consent. - The account is small and the measured loss is a few percent, the operational overhead outruns the benefit; say so and stop. - Attribution (not delivery) is the gap, implement-enhanced-conversions is cheaper and faster. ## Prerequisites - Working client-side GTM setup with Google Ads conversions configured. - A hosting decision: managed server-GTM hosting (simplest), Google Cloud (moderate setup), or self-managed infrastructure (only with dedicated ops). - A spare subdomain on the site's own domain for first-party routing, with DNS access and SSL (managed hosts handle SSL automatically). - Backend conversion export for loss quantification. ## Procedure 1. Quantify the case first with VigilDog: `gads_run_gaql_query` for 28 days of conversions per action; user supplies backend counts for the same window. Compute the loss percentage. Under ~5%: recommend against proceeding. 5-15%: worthwhile. Over 20%: first rule out tracking bugs before crediting blockers. 2. HUMAN STEP (outside VigilDog): create the server-type GTM container and provision hosting, managed provider (enter container id, pick the region nearest the primary audience) or Cloud Run via the container's provisioning flow. 3. HUMAN STEP (outside VigilDog): first-party domain, create the CNAME from the chosen subdomain to the hosting endpoint, ensure SSL covers it, allow DNS propagation (up to ~24 h), and confirm the endpoint responds and the server container's preview connects. 4. HUMAN STEP (outside VigilDog): route the web container, set the server/transport URL on the Google Tag so browser hits go to the subdomain instead of Google's endpoints; verify in the network panel that measurement requests now hit the first-party host. 5. HUMAN STEP (outside VigilDog): build the server-side tags, the analytics client claims incoming events; one Google Ads conversion tag per conversion action (id, label, value, transaction id, currency mapped from event data) triggered on the matching event; analytics forwarding tag if GA4 is in play. Debug in the server container's preview: event claimed, tags fired, outbound requests present. 6. Parallel-run verification with VigilDog: for 48-72 hours run both paths and compare daily conversion counts per action via `gads_run_gaql_query` against the pre-migration daily baseline. - Counts roughly doubled → both web and server tags are firing for the same actions; the transaction-id dedup is the safety net, but remove the duplicate client tags (HUMAN STEP). - Counts dropped → server tags not firing for some events; back to step 5. - Counts steady or slightly up → healthy cutover; the "up" is recovered blocked traffic. 7. HUMAN STEP (outside VigilDog): publish both containers with descriptive version names; retire redundant client-side conversion tags once the server path is proven. 8. Post-launch monitoring with VigilDog: for 2 weeks watch daily conversions for gaps that would indicate server downtime; report the final recovered-conversion percentage vs the step-1 baseline. Add a monthly server-health check to the account rhythm (HUMAN: hosting dashboard; VigilDog: conversion-continuity query). ## Decision rules - Go/no-go on measured loss, not fashion: <5% skip, 5-15% proceed, >20% investigate bugs first. - Hosting: managed provider unless the org already runs cloud infrastructure fluently; the failure modes (SSL, scaling, region) are all things managed hosts absorb. - Region: closest to the primary audience, cross-continent routing adds latency to every page. - Transaction ids become mandatory, not optional: they are the only protection against double-counting during the parallel run. - Never remove the client-side conversion tags before the server path has 48-72 verified hours. - A sudden multi-hour conversion gap post-launch = suspect server availability first, tags second. - SST is additive to consent and enhanced conversions, not a substitute for either. - Cost sanity: managed hosting starts around €20/month and scales with request volume; weigh that against the value of the recovered conversion percentage from step 1, the business case is arithmetic, not ideology. - Ownership: agree up front who owns server-container health (marketing, dev, or the managed host), an unowned container fails silently at the worst time. ## Common failure modes - Declaring victory before DNS propagates, then debugging a "broken" setup that just needed hours. - Both tag paths left live indefinitely, dedup hides it until an untagged path leaks doubles. - Server hosted in a distant region, quietly taxing every page load. - SSL lapse on the custom subdomain silently killing all measurement, put renewal on a calendar or use a managed host. - Forwarding tags misconfigured for some conversion actions only, producing a partial, hard-to- spot count drop; the per-action comparison in step 6 exists precisely for this. ## Related skills - Run before: set-up-google-ads-conversion-tracking, implement-transaction-id-deduplication (both hard prerequisites), configure-google-consent-mode. - Run alongside/after: implement-enhanced-conversions (same data can ride the server path), set-up-offline-conversion-tracking. - Feed results into: run-a-monthly-performance-review (recovered-volume step change becomes the new baseline). - If the recovered volume changes campaign economics: recalibrate targets via calculate-bid-targets and revisit budget caps via allocate-budget-across-campaigns, a 10% conversion uplift at constant spend is a real CPA improvement worth re-planning around.