Web Consent Receipts

Last updated: October 4, 2026

Direct Web CMP TCF decisions use the wcev5 receipt contract from Web CMP 1.5.28. This page describes that path; it does not change the contracts of mobile SDKs, CMS plugins or non-TCF regional integrations.

The Google-ready banner’s category-only decisions are outside this TCF receipt contract. Web CMP 1.5.30 reports category-contract-unavailable for that receipt path instead of fabricating a TC String or presenting a category decision as a TCF receipt. This does not prevent local category choices or Google consent updates. Do not claim server-side category receipts until a separate category contract has been implemented and verified.

1. What a completed choice records

A receipt associates the property and decision identity with:

• the action and TCF string from the completed choice;
• the independent Analytics preference, including an explicit refusal;
• the four Google consent values the CMP attempted to publish, when that transport is enabled;
• the transport used and whether that local publication call was accepted;
• the CMP, TCF policy and vendor-list versions;
• a fingerprint of the consent configuration presented for that choice.

Analytics can change without changing the TCF advertising-purpose string. Those are separate decisions and must remain distinguishable. Opening preferences or cancelling a draft is not a completed choice.

2. Snapshot example

This example shows the added receipt object inside a wcev5 TCF consent event. The fingerprint is illustrative, not an installation setting.

{
  "version": 1,
  "framework": "tcf",
  "analyticsChoice": false,
  "google": {
    "signals": {
      "ad_storage": "granted",
      "analytics_storage": "denied",
      "ad_user_data": "granted",
      "ad_personalization": "granted"
    },
    "transport": "gtag",
    "accepted": true
  },
  "policy": {
    "cmpId": 471,
    "cmpVersion": 2,
    "tcfPolicyVersion": 5,
    "gvlVersion": 179
  },
  "configuration": {
    "sha256": "0000000000000000000000000000000000000000000000000000000000000000",
    "revision": null
  }
}

analyticsChoice is true, false, or null when no separate explicit value is available. Never infer it solely from TCF purpose 7. Google transport is gtag, native-gtm, disabled, or not-attempted. Disabled or unattempted publication has signals: null and accepted: false.

accepted: true means the local publication call accepted the update. It does not prove a Google request, measurement report, legal assessment or certification. Compare actual Google behavior separately using Tag Assistant.

3. Delivery and history

A retried decision keeps the same event identity and snapshot. A later choice has a new identity even when its TC string is unchanged. Delivery failures do not change the visitor’s consent. An HTTP 202 response indicates the receipt has been accepted for processing; durable receipt completion requires a separate delivery check.

Completed, undelivered decisions use first-party storage on the visitor’s device for retry, bounded to 32 records and 256 KB per property. Each record has a seven-day retry window; expired records are removed when the CMP next processes the queue. Accepted and permanently rejected records leave the queue. Storage unavailability, capacity limits and permanent failures are observable in integration diagnostics. Delivery is not guaranteed if storage is unavailable, the visitor never returns, or the device cannot reconnect.

The saved TCF choice and its matching integrity record expire after 180 days. Returning to the site does not renew that completed choice’s lifetime. The pending receipt queue and the saved consent choice have separate retention purposes; a pending receipt never grants consent.

Receipts created before this contract may have no independent Analytics snapshot. Do not backfill a guessed preference from an old TC string. Disabling consent-record transport means no server receipt is produced for that installation; local consent and Google signaling are separate behaviors.

4. Verification and handling

Verify a completed acceptance followed by an Analytics-only refusal. The two decisions should have distinct identities, preserve their individual Analytics and Google snapshots, and retain their order through retry and reload. Check that rejected choices remain rejected after a reload and that failure recovery cannot rewrite a prior receipt.

Keep raw consent records and device identifiers out of public screenshots and support posts. Use the minimum redacted evidence needed to investigate a property-specific issue. Apply your organization’s disclosed retention and access rules; a receipt is an implementation record, not proof of compliance by itself.