Skip to main content

Consent Overview

DATA Reshape treats user consent as the gatekeeper for every piece of data that flows through the platform. Consent is enforced across all connected destinations automatically — you do not need to write per-destination logic to honor a user's privacy choices.

Default state: denied​

By default, every visitor starts with consent denied for analytics, personalization and marketing. Tracking runs in a GDPR-restricted mode until DATA Reshape receives an explicit consent signal. This default-deny posture is what keeps your implementation GDPR-compliant out of the box, even before a Consent Management Platform (CMP) is wired in.

There are three sources, listed in order of preference. You almost never need more than one:

  1. Native CMP integrations. DATA Reshape is integrated with most major Consent Management Platforms and commerce platforms (Shopify, MerchantPro, Gomag and others). On sites where one of these is detected, Reshape listens to the native consent signal automatically — no manual push needed.
  2. Google Consent Mode v2 (GCMv2). If your site already implements GCMv2 via gtag('consent', 'update', ...), Reshape listens to it natively. An anti-spoofing protection layer validates each signal against the expected origin and timing to prevent client-side tampering from bypassing consent enforcement.
  3. Manual consent_updated event. Use this only when your CMP is not auto-detected, when relaying a stored consent decision from a non-DOM source (mobile webview, SPA route guard, server-rendered banner), or when the CMP/GCMv2 sources are unavailable. See Consent Updated event for payload shapes.

DATA Reshape exposes three configurable modes that govern what happens to events fired before consent is granted and what continues to happen after an explicit deny. The mode is set per account and dramatically affects both compliance posture and server-side processing volume. They are listed below from the strictest to the most permissive.

1. Full restriction​

The strictest mode. The full DATA Reshape tracking JavaScript is not loaded until the visitor grants consent, and nothing is sent anywhere — no ping, no server-side call, no destination forwarding.

  • Decision pending on the current page — each event is captured into a per-key in-page queue holding the full event payload. Nothing leaves the browser until consent lands.
  • Consent granted on the same page — the script loads and the queued events are replayed in full in their original order, so destinations receive the complete pre-consent activity from this page.
  • Explicit deny + navigation — the tracking JS continues not to load and no tracking happens at all, not even server-side. The visitor is completely invisible for the rest of the session, and any previously queued events for that page are dropped.

Highest legal protection in jurisdictions with strict pre-consent tracking rules; zero post-deny visibility on any page.

2. Anonymous ping (with optional Replay)​

The JS loads from the start but operates in restricted mode until consent. Recommended as the optimal balance for most accounts.

  • Decision pending — each event is sent as a stripped-down anonymous ping (no PII, no cookies, no fingerprint), giving you aggregate volume and a basic shape of the funnel. Full payloads are held in a per-page in-memory queue.
  • Consent granted on the same page — full versions are replayed and deduplicated against the anonymous pings so destinations receive enriched events in the correct order.
  • Explicit deny + navigation — the per-page queue is dropped, but anonymous pings keep flowing for each subsequent page, so you still get aggregate volume and funnel shape for the denied portion of the session. The visitor is not invisible.
Server-side pings for unsupported destinations

Some destinations (server-only APIs, destinations that reject low-fidelity browser hits, etc.) do not support browser-side anonymous pings. For those, DATA Reshape sends the pre-consent ping server-side only, so the destination still receives an event in a shape it can accept. This routing is automatic — you do not need to configure it per destination.

3. Server-side queue + Replay​

Events are accepted from the start and held in a persistent server-side queue for a configurable retention window (or until consent is granted, whichever comes first).

  • Cross-page and cross-session — unlike the in-page queues in modes 1 and 2, this queue survives page navigation and even browser-close within the retention window.
  • Consent granted at any time inside the window — the entire pre-consent journey is replayed in order with full deduplication on the server-side path. Practically no server-side data is lost.
Browser-side pixels cannot be replayed

While consent is denied or still pending, browser-side pixel calls (fbq, ttq, gtag, etc.) are not fired in the visitor's browser, even though the event is being queued server-side. Those browser pixel firings are tied to the visitor's session and cannot be recovered later — once the visitor leaves without consent, the browser-context signals (cookies set by the pixel, third-party ad IDs, browser fingerprint at that moment) are gone. Replay on consent will deliver the event server-side only, which is what most ad platforms expect via CAPI / Events API anyway — but if a destination relies specifically on the browser-side pixel for full attribution, that portion is lost.

On request + significant cost

This mode is available on request only and introduces significant additional processing and storage costs — every pre-consent event consumes server-side queue capacity for the full retention window, even if consent is never granted. Pick this only if losing pre-consent journey data is genuinely unacceptable for your use case and you are prepared for the cost impact.

Choosing a mode​

The choice depends on your jurisdiction, your appetite for processing cost, and the analytics fidelity you need. Modes with Replay can noticeably increase request volume against your account quota — pick the one that matches your compliance and budget.

Per-destination parameter restrictions (any mode)

Independently of the operating mode chosen above, each destination can be configured to receive only a subset of the available parameters — for example, an analytics destination can be restricted to receive only context and product data while a marketing destination receives the full payload including hashed user identifiers. This is a per-destination configuration and applies in all three modes, both pre-consent (pings/replays) and post-consent (full forwarding). Use it to enforce data-minimization principles destination by destination, even when consent allows the broader category.

Each connected destination is configured with the consent categories it requires (analytics, personalization, marketing). When an event is processed, Reshape forwards it only to the destinations whose required consent categories are all granted. The same event can reach some destinations and be blocked from others — this is normal and intentional, and it's what lets a partial-consent user (e.g. accepted analytics but not marketing) still feed your analytics stack without leaking to ad platforms.

If the visitor changes consent mid-session (opens cookie settings, revokes marketing, etc.), Reshape applies the new state immediately for all subsequent events. For events held in any replay-capable mode (in-page queue in modes 1 and 2, server-side queue in mode 3), the new state is also applied before replay — so a withdrawn consent will not cause queued events to leak to destinations that no longer have permission.

Audit trail​

DATA Reshape is not a Consent Management Platform — your CMP (or commerce platform integration) remains the source of truth for the consent record itself. For organizations that need an internal audit trail of consent decisions alongside their tracking data, DATA Reshape can persist each received consent signal with a timestamp and the originating source (native CMP plugin, GCMv2, manual consent_updated event, etc.), available for GDPR compliance audits and for responding to Data Subject Access Requests (DSARs) without having to instrument extra retrieval logic on your side.

This audit-trail persistence has two requirements:

  • You must push a consent.id with every consent signal (your CMP consent record ID, IAB TC string hash, or any stable internal identifier) so each stored decision is tied to a verifiable reference. See the id field on the consent_updated event.
  • The feature is paid / on request — it consumes long-term storage and is not part of the default tracking flow. Contact us to enable it on your account.

Without consent.id and without the feature enabled, DATA Reshape still enforces consent in real time (default-denied, per-destination gating, mid-session updates) but does not retain a queryable historical record — refer back to your CMP for that.