Skip to main content

Consent Updated

Push the consent state for the visitor — analytics, personalization and marketing — so DATA Reshape can enforce per-destination tracking restrictions. Without this signal (or an equivalent native CMP/Google Consent Mode v2 signal), Reshape stays in the default-denied state and tracking runs in GDPR-restricted mode.

Native CMP integrations

DATA Reshape is integrated with most major Consent Management Platforms and commerce platforms (Shopify, MerchantPro, Gomag and others) — when one is detected, the native consent signal is read automatically and you do not need to fire this event manually. The same applies to Google Consent Mode v2 (gtag('consent', 'update', ...)), which Reshape listens to natively with anti-spoofing protection. See the Consent Overview for the full list and detection logic.

Use this manual push only when your CMP is not auto-detected, or when you need to relay a stored consent decision programmatically (mobile webview, SPA route guard, server-rendered banner, etc.).

When to push​

  • First-time consent decision — push immediately after the visitor interacts with your consent banner.
  • Returning visitor with stored consent — push once at the start of the session, before any tracked event, so Reshape exits the default-denied state immediately.
  • Mid-session change — push every time the visitor opens preferences and updates the consent state. The new state applies to all subsequent events; in Queue+Replay mode, the new state is also applied to queued events before replay.
  • Programmatic update from a non-DOM source (mobile webview bridge, SSO callback that restores a stored consent, etc.).

Payload variants​

The consent_updated push supports three shapes — pick the one that matches your scenario.

The standard variant — push as a normal Reshape event with an event object and the consent object.

window.reshape = window.reshape || [];
reshape.push({
  "event": {
    "name": "consent_updated"
  },
  "consent": {
    "analytics": true,
    "personalization": true,
    "marketing": false
  }
});

Complete Reference​

The consent_updated push accepts the following objects.

event object

When present, contains a single static value. The event object is optional for consent_updated — pushing a payload with only the consent object is also valid (see the Consent-only push variant above).

name string required when event is present

info

Use only static value consent_updated for event.name.

name: "consent_updated"

consent object required

info

The consent state for the three categories DATA Reshape enforces. Optionally include id to associate the consent decision with a record identifier (useful for relaying or persisting in an audit destination).

analytics boolean required

info

Consent for performance monitoring, usage statistics, and service optimization.

analytics: true

personalization boolean required

info

Consent for tailored experiences and content customization.

personalization: true

marketing boolean required

info

Consent for targeted advertising, remarketing, and campaign measurement.

marketing: false

id string

info

Optional consent-record identifier. When present, DATA Reshape can persist or relay the consent decision under this ID — useful when you want each stored decision to be tied to a verifiable reference from your Consent Management Platform (CMP consent ID, IAB TC string hash, internal record ID, etc.). Required when the optional audit-trail persistence feature is enabled on the account.

id: "consent_record_abc123"
One push, many native events

A single Reshape consent signal can produce one or more native consent updates per destination, with different shapes depending on each website's destination configuration (Google Consent Mode v2 updates, Meta CAPI data_processing_options, TikTok limited_data_use, etc.).

Custom properties

Custom properties (event.properties, user.properties, products[*].properties) are fully processed server-side. On browser-side pixels and tags, only a subset may be available. Server-side processing can also enrich the outgoing payload with additional parameters derived from context and data quality.

Best Practices​

  • Push as early as possible — for returning visitors with stored consent, push the consent state at session start, before any tracked event. This avoids unnecessary queueing or anonymous-pinging in restricted modes.
  • Push every change — every time the visitor updates their consent (cookie settings, withdrawal, etc.), push the new state immediately. Reshape applies it to all subsequent events and to queued events before replay.
  • Skip the manual push when a native integration handles it — if your CMP or Google Consent Mode v2 is auto-detected, you do not need to fire this event. Double-firing is harmless (Reshape deduplicates) but unnecessary.
  • Use the consent-only variant for state relay — when you are not also tracking an action, omit the event object to keep the payload minimal.
  • Treat id as opaque — it is not validated by Reshape, it is just stored/relayed. Use a stable identifier from your consent platform (CMP consent ID, IAB TC string hash, internal record ID, etc.).
  • Server-side push — for sensitive flows (mobile webview, server-rendered banner), prefer pushing the consent state from your server via the API instead of relying on the browser. Reshape applies it the same way.