--- name: set-up-data-exclusions description: >- Protects Smart Bidding after a conversion-data corruption event, tag outage, checkout down, payment gateway failure, duplicate-count spike, by pinpointing the exact corrupted window from hourly data and getting a data exclusion applied so the bidder ignores that period. VigilDog does the forensic part (hourly/daily GAQL anomaly detection, precise start/end proposal, scope determination, post-exclusion stabilization monitoring); the exclusion object itself is created in the Google Ads UI by a human. Use when conversions flatlined or spiked abnormally for a bounded period. Not for correcting individual conversions (configure-conversion-adjustments), not for anticipated demand shifts like sales or holidays (that is a seasonality adjustment, out of scope here), and not a substitute for fixing the root tracking break first (set-up-google-ads-conversion-tracking / implement-transaction-id-deduplication). --- # Data Exclusions for Corrupted Conversion Periods ## Purpose When tracking breaks or the site goes down, Smart Bidding keeps learning from the garbage data the outage produced. A data exclusion tells the bidder to skip that window. This skill finds the exact corrupted window from hourly conversion data, decides the right scope (account, campaigns, devices), hands a precise exclusion spec to the human for UI entry, and then monitors bidding stabilization afterward. ## When to run - Conversions dropped to zero or near zero for a bounded period while clicks stayed normal (classic tag or checkout failure signature). - A duplicate-counting bug inflated conversion counts for a period. - The site, CDN, or payment gateway was down and conversions could not complete. - A consent or GTM publish error suppressed tracking for hours or days. ## When NOT to run - One specific order/lead needs correcting → configure-conversion-adjustments (RESTATE/RETRACT). - You expect a future conversion-rate swing (sale, holiday) → that is a seasonality adjustment, not a data exclusion; exclusions are retroactive only. - The tracking issue is ongoing and unfixed → fix it first (set-up-google-ads-conversion-tracking, implement-transaction-id-deduplication); excluding a still-bleeding period accomplishes nothing. - Campaigns are on manual bidding only → exclusions affect Smart Bidding models only; nothing to protect. ## Prerequisites - Smart Bidding active on at least one affected campaign. - Any external evidence available (incident log, uptime monitor, GTM publish history) to bracket the incident, VigilDog will refine it from hourly data. - The root cause already fixed, or a clear plan to fix it before the exclusion is filed. ## Procedure 1. Classify the incident with the user: outage (zero conversions), site down (no converting clicks), payment failure (normal sessions, zero purchases), or inflation (count spike). This determines what anomaly signature to hunt for. 2. Locate the window mechanically. Run `gads_run_gaql_query` over the suspect date range at hourly grain (segment by date and hour) pulling conversions, clicks, and cost. Find the first hour where conversions diverge from the same hour on prior comparable days, and the first hour they recover. Propose start/end timestamps in the account's timezone, corruption start, not discovery time. 3. Determine scope from the same data: break the anomaly out by campaign and by device via `gads_run_gaql_query`. If the collapse is uniform, scope = all campaigns; if only certain campaigns or only mobile shows the signature, scope narrowly to those campaigns and/or that device. Narrow scope preserves good learning data. 4. Verify the root cause is resolved before proceeding: pull the most recent 24 hours of hourly conversions and confirm the pattern is back to baseline. If not, stop and route to the fix, do not file an exclusion over an open wound. 5. HUMAN STEP (outside VigilDog): create the data exclusion in Google Ads (bid strategy advanced controls area) using the exact spec VigilDog produced, name it descriptively with the incident and dates, paste the start/end timestamps, set the campaign/device scope. No VigilDog tool creates exclusion objects. 6. HUMAN STEP (outside VigilDog): confirm the exclusion shows as active and its dates/scope match the spec. 7. Monitor stabilization with VigilDog. Do not judge bidding for the first 48 hours, the models need time to re-solve without the excluded data. Then check via `gads_get_campaign` and `gads_run_gaql_query`: - Days 2-7: CPA/ROAS on affected campaigns should be converging toward pre-incident levels. - Day 14: performance should be back at baseline. If still erratic, re-verify the window covered the whole corrupted period (step 2, wider range). 8. Log the incident summary (what, when, scope, exclusion filed, recovery date) in the session notes so the next review has context. ## Decision rules - Exclusion window: as tight as the hourly data supports. Too wide starves the bidder of good data; too narrow leaves poison in the training set. Hourly precision beats calendar-day rounding. - A single exclusion covers at most 14 days. Longer incidents need to be split, and an incident that long is itself a monitoring failure worth flagging. - Keep the total excluded across all exclusions under roughly 2-3 weeks; beyond that, recurring tracking failures are the real problem, not the exclusions. - Zero conversions with normal clicks → tracking/payment failure. Zero clicks too → site down (less conversion damage, exclusion may be unnecessary if spend also stopped, check cost in the window). - Count spike with flat clicks → duplication; pair the exclusion with implement-transaction-id-deduplication. - Old exclusions for past periods need no cleanup; they are inert documentation. - Excluded data still appears in reports, only bid learning ignores it. Never "verify" an exclusion by expecting reporting numbers to change. Anomaly-detection heuristics for the step-2 query: - Compare each hour against the median of the same hour/weekday over the prior 3-4 weeks; flag hours below ~20% of that median (outage signature) or above ~250% (inflation signature). - Require at least 2-3 consecutive anomalous hours before calling a boundary, single-hour dips are normal variance on most accounts. - Cross-check the click series for the same hours: conversions collapsing while clicks hold is the tracking/payment signature; both collapsing together points at delivery or site-wide outage. ## Common failure modes - Using the time the problem was noticed as the start time; the corruption almost always began earlier. Trust the hourly query, not the ticket timestamp. - Whole-day rounding that throws away good morning/evening data around a midday outage. - Filing the exclusion but never fixing the root cause, then filing another next month, watch the cumulative excluded-window budget. - Scoping to all campaigns when only mobile checkout broke, discarding valid desktop learning data. - Judging Smart Bidding 12 hours after the exclusion and reverting strategy in a panic; the 48-hour adjustment lag is normal. ## Related skills - Run before (fix the cause): set-up-google-ads-conversion-tracking, implement-transaction-id-deduplication, configure-google-consent-mode. - Run alongside: configure-conversion-adjustments (if individual conversions also need correction). - Run after: monitor-and-maintain-bid-strategy-health, run-a-weekly-performance-review. - Prevention: the weekly review's KPI checks are the early-warning system that shortens the next incident's corrupted window, tighten that cadence if incidents keep being found late.