Ad Incident Evidence Capture Guide: Preserve the Record Before You Change the System

Direct answer

Before changing an ad account, campaign, payment method, permission, tracking endpoint, domain, catalog, integration, or appeal, capture the current state. Start a UTC incident record; preserve notices, object IDs, URLs, statuses, permissions, billing and transaction references, configuration exports, measurement samples, support case IDs, and official status observations. Keep raw records separate from screenshots and hypotheses. Record unavailable evidence instead of guessing. Then make one authorized, reversible change with an expected read-back and stop condition. Never send passwords, MFA codes, cookies, full payment details, unrestricted keys, or identity documents to an inbound “recovery” contact.

Who this is for

Fit: operators, executives, finance/security owners, agencies, and client administrators of high-spend Meta, Google Ads, or TikTok programs facing delivery, restriction, verification, billing, access, tracking, domain/catalog, integration, or appeal incidents.

Not a fit: this is not forensic, legal, provider-escalation, or outcome advice. Do not submit evidence outside organizational authority, contract, privacy policy, or law. Provider routes and labels vary by account/region; re-check current official sources. [PR-P03][PR-P10][PR-P11][PR-P13][PR-P15]

Decision model

Treat every item as one of four kinds of knowledge:

Use this evidence hierarchy as an operating aid, not a universal rule:

1. Native/account-specific records: notices, detail/object IDs, URLs, audit/permission history, billing/config exports, and API request/trace IDs with non-secret response metadata (status, date, rate limits). Never preserve Authorization, Proxy-Authorization, Cookie, Set-Cookie, X-API-Key, CSRF, bearer, or other secret/token values. Native records are usually closer to scope, not automatically authentic or immutable.
2. Independent correlated records: bank/card, agency, backend, CRM, server/tag, consent/event, second-admin, clean-device, and customer records. They corroborate timing or impact but do not alone prove platform cause.
3. Context records: screenshots, notices, email headers, notes, chats, and recordings. They can be weaker than exports, but an ephemeral screenshot may be the only contemporaneous capture; preserve provenance.
4. Signals/hypotheses: status pages, social/community reports, vendor explanations, and theories. Use them to generate checks, not proof of account cause, prevalence, loss, or recovery rate. [RS-S03][RS-S07][RS-S15][PR-P01][PR-P09][PR-P17][PR-P18][PR-P21]

Shared identity, payment, domain, dataset, catalog, vendor, token, admin, or policy exposure can make accounts common-mode; this is an operating inference, not a statistic. [RS-S08][PR-P10][PR-P11][PR-P13][PR-P15]

Diagnostic or control sequence

1. Open the record before configuration changes. Evidence/input: symptom, surface, region, entity, first-seen and last-known-good times. Owner: incident lead/recorder. Action: assign an ID; retain verbatim displayed time, source/system, timezone, capture time, derived UTC, and skew note. Stop: unknown authority or scope means no change.
2. Capture provider state. Evidence/input: exact label/error, detail/verification ID, status URL, account/object IDs, request ID, and read-only/delivery state. Owner: authorized administrator. Action: export notice; save URL, scope, UTC observation, and failed retrievals. Stop: a generic page is not proof.
3. Freeze the object map. Evidence/input: portfolio/manager, account, campaign/ad, catalog/feed, pixel/dataset, domain, app, token, and parent/child links. Owner: asset owner. Action: export IDs, relationships, owner, billing entity, and agency authority. Stop: do not relink, delete, rebuild, or replace an account around an unclear dependency.
4. Preserve permission and security state. Evidence/input: admins/partners, roles, recovery contacts, sessions, apps, OAuth grants, extensions, rules, scripts, and changes. Owner: security/asset owner; finance reviews spend. Action: from a clean endpoint retain only token/session metadata—object/fingerprint, owner, client, scopes, lifecycle, status—and revoke one identified suspect session/token if authorized. Never copy bearer, cookie, API-key, OAuth-secret, CSRF, or other credential values; exceptional secret handling is qualified-forensics-only. Stop: preserve metadata before cleanup. [RS-S05][PR-P12]
5. Preserve billing and transactions. Evidence/input: balance, invoice, payment-profile/transaction IDs, amount/currency, timestamps, masked descriptor, bank/card reference, agency invoice, authorized users, served period. Owner: finance. Action: retain original/redacted copies and branch:
   • Suspected unauthorized activity: capture minimum transaction/access evidence and promptly use current platform and issuer/bank fraud routes; follow authorized issuer process; promise no outcome. [PR-P11]
   • Legitimate platform-balance disagreement: reconcile invoice, transaction, delivery, users, and payment state before reversal; Google distinguishes unauthorized disputes from legitimate-balance reversal, which can trigger suspension risk. [DRS-A07][PR-P11]
   • Agency invoice mismatch: separate agency/platform records; match entity, account, period, media, fees, and contract; route contract questions to finance, procurement, or counsel. Stop: never let the legitimate-balance rule delay suspected-fraud routing; document branch/authority before any dispute, chargeback, payment replacement, or spend change. [RS-S03][RS-S09][PR-P15]
6. Preserve campaign/configuration state. Evidence/input: campaign/ad exports, budgets, bids, schedules, targeting, placements, creatives, destinations, rules, scripts, feeds, catalogs, and changes. Owner: operations executor with asset-owner approval. Action: export current/last-good versions. Google Ads Scripts are best-effort; a completed run does not prove every mutation, so read back state. Stop: seal before-state before disabling automation. [DRS-A05][RS-S06][RS-S07][PR-P12]
7. Preserve measurement samples. Evidence/input: schema/version, consent, event samples, request times, deduplication IDs, analytics, CRM/backend records, landing response, feed diagnostics, and cohort. Owner: data owner. Action: freeze scope/window/cutoff; retain raw/redacted extracts; separate billed, served, attributed, analytics, and settled ledgers. Stop: quarantine stale or cross-account reports. [RS-S07][RS-S08][PR-P09][PR-P18]
8. Preserve notices and chronology. Evidence/input: email headers, in-account notices, status URL/scope, status/API/RSS response, case ID, submissions, responses, and actions. Owner: recorder/platform liaison. Action: save source URL, displayed status, raw response, access UTC, and chronology. Stop: green status and public incidents remain signals, not account-loss proof. [PR-P01][PR-P09][PR-P17][PR-P21]
9. Create custody and secure copies. Evidence/input: every file, screenshot, export, and note. Owner: evidence custodian. Action: assign ID; record collector, method, source timestamp, capture UTC, filename, storage/access/transfers, and hash/version. Record algorithm/digest/capture/collector and re-verify transfers; a hash proves integrity from capture onward, not authenticity, completeness, authorization, or causation. Keep the pack secret-scrubbed; qualified forensics governs exceptional secrets. Stop: approved encrypted least-privilege storage/transfer only. [DRS-A01][RS-S15]
10. Make one bounded change or use the official route. Evidence/input: sealed before-state, authority, expected result, rollback, current route, gaps. Owner: incident lead/executor/recorder. Action: one reversible change or factual official submission; record response. Stop: halt on unexpected read-back, blast-radius growth, secret request, or unverified transfer; no identity rotation, rented account, forged record, cloaking, or appeal flooding. [PR-P03][PR-P07][PR-P10][PR-P14][PR-P15]
11. Reconcile and close after verification. Evidence/input: before/after exports, permissions, billing, delivery, events, backend outcomes, case chronology, and unavailable-evidence log. Owner: incident lead, finance, asset owner. Action: compare the frozen cohort and record residual provider unknowns. Stop: login restoration, active campaign, or green dashboard alone is not closure; obtain owner sign-off. [RS-S03][RS-S09][RS-S10]

Evidence to preserve

Use this checklist before changing any material state:

• Incident ID/reporter, opened UTC, first-seen/last-good times, verbatim source timestamp and timezone, source/system, capture time, platform, region, and entity.
• Exact label/error, raw text, policy/detail/verification ID, account/object IDs, URL, request/trace ID, and native notices or exports.
• Permissions, partners, admins, recovery contacts, and non-secret session/token metadata (object/fingerprint, owner, client, scopes, lifecycle, status). Never copy bearer, cookie, API-key, OAuth-secret, CSRF, or other credential values; exceptional handling is qualified-forensics-only.
• Current/last-good campaign/config exports and actor/time changes; billing, invoice, transaction/reference ID, amount/currency, masked descriptor, bank/card reference, agency invoice, authorized users, and served period.
• Measurement samples with schema, consent, request time, deduplication key, analytics/CRM/backend record, feed status, landing response, and cohort/window; keep billed, served, attributed, analytics, and settled ledgers separate.
• Status/API/RSS observations, support case/submissions/responses, and unavailable evidence with reason, owner, next check, and consequence.
• Custody: evidence ID, collector, method, original filename, verbatim timestamp, capture UTC, storage/access/transfers, retention/deletion, and redaction. If hashing, record algorithm/digest/capture/collector and transfer re-verification; a hash does not prove authenticity, completeness, authorization, or causation. Use approved encrypted least-privilege storage; retain a secret-scrubbed original only when authorized, redaction manifest/version, and metadata review (tabs, comments, filenames, metadata, EXIF, embedded objects). Redacted/pseudonymized copies may still contain personal/confidential data and remain controlled. [DRS-A01][RS-S05]

What not to do

Do not collect passwords, MFA/recovery codes, session cookies, browser profiles, remote access, unrestricted keys, OAuth secrets, signing keys, full payment numbers, CVV, or unrelated identity data. Never send identity documents to inbound contacts, brokers, recovery intermediaries, or unverified links. If the verified in-account provider route requests authentic identity/entity evidence, asset/legal/privacy owners verify domain, document type, entity/region, authority, and retention; submit only what it requests, directly. Do not retain a local copy by default; if required, document purpose, owner, access, hold/deletion date, and redaction limits. [PR-P07][PR-P12][PR-P14][PR-P15][PR-P24]

Do not alter timestamps, forge notices, hide actions, delete originals, share another advertiser’s data, infer fraud/cause/loss from one signal, evade enforcement, rotate identity/payment, cloak, use anti-detect tools, submit false documents, or spam appeals. [PR-P07][PR-P10][PR-P14][PR-P16]

Retention/deletion follow approved schedule, contract, privacy/security policy, hold, and qualified privacy/legal guidance; this is not legal advice. Retain only what is necessary, restrict access, review metadata, and document deletion. Redacted/pseudonymized copies may still contain personal/confidential data. [DRS-A01][RS-S05]

When to escalate

Use self-service when one known object, authority/ownership, no compromise, and the current official route define the bounded next action; preserve first.

Escalate to qualified security, privacy, finance, data, or incident-response specialists when systems/owners cross, unauthorized access/spend is plausible, evidence may disappear or cross tenants, parent impact is possible, billing entities differ, measurement diverges from settlement, or custody/authority/retention/clean endpoint is unclear. Privacy/legal owners address jurisdiction, disclosure, holds, contracts, and identity-document questions. This is not legal advice.

Escalation creates no special provider channel or outcome. Continue current platform and issuer/bank routes where relevant. [PR-P03][PR-P10][PR-P11][PR-P13][PR-P15]

FAQ

Should I pause before collecting evidence? Preserve first. An authorized lead may approve a bounded pause for suspected unauthorized spend, data exposure, or unsafe automation; record reason, before-state, read-back, and rollback.

Is a screenshot enough? No. Pair it with native export, IDs, URL, raw notice/error, and source time; it does not alone establish cause, scope, authorization, or recovery.

What if status is green? Record product scope and UTC as one signal; compare UI/API, delivery, billing, measurement, and independent observations. Green is not account proof. [PR-P01][PR-P09]

How do I preserve payment evidence safely? Keep payment-profile/transaction IDs, amount/currency, descriptor, timestamp, and masked reference. Use secret-scrubbed redacted copies; never share full PAN, CVV, bank password, MFA code, or credential values. [PR-P11]

Can I submit every record in an appeal? No. Submit only authentic records the verified current route requests, directly through that route. Omit unnecessary personal data, secrets, and other advertisers’ data; requirements vary by account/entity/region. [PR-P03][PR-P10][PR-P14][PR-P15]

Source appendix

Accessed 2026-07-19. Before acting, authorized owners should check the current first-party route for the affected account, product surface, and region; labels, eligibility, timing, and payment behavior may vary.

First-party route verification