Consent & privacy

Fidero treats consent as part of the data, not a banner sitting in front of it. Every event carries the visitor’s consent, and every third-party destination is gated by it – in the browser when integrations load, and on the server when events fan out. None of that is wiring you build: the enforcement is in the platform, and your part is telling Fidero what the visitor chose.

This page is the mental model: the consent object and where it comes from, the two rules Fidero enforces, and what happens before consent, on the server and when consent is withdrawn.

The consent object

Consent travels on the event envelope, as categories mapped to booleans:

"context": {
  "consent": {
    "categoryPreferences": {
      "essential": true,
      "functional": true,
      "analytics": true,
      "advertising": false,
      "dataSharing": false
    }
  }
}

Category	Covers
essential	Basic functionality – always granted
functional	Preferences and personalisation
analytics	Usage tracking and identity persistence
advertising	Ad targeting and conversion tracking
dataSharing	Sharing with third parties

All five reach the server and gate third-party destinations. Two of them also change how the SDK itself behaves: analytics governs whether Fidero persists identity in the browser, and advertising governs the ad destinations. Before consent covers both.

Two rules

Everything on this page follows from two rules.

A present consent object is enforced exactly – and anything it doesn’t state is denied. A category set to true is granted. A category set to false, or simply missing from the object, is denied. Silence inside a consent object is never consent, which is the behaviour GDPR’s explicit-consent model expects.

An absent consent object passes through. An event with no consent object at all is delivered, not blocked. That’s most often a server event from your backend, where no banner was ever shown. Absent doesn’t mean all-denied: blocking it would fabricate a consent decision that was never made. Where Fidero can fill that gap from the person’s profile, it does – On the server covers how.

Enforcement is rule-based and applied per destination, with nothing probabilistic in it. What that lets Fidero guarantee is on Guarantees & coverage.

From your CMP

In the browser, the consent object comes from your CMP. Fidero ships native adapters for Complianz, Cookiebot, CookieYes, HubSpot, Pandectes, Shopify and Termly: the adapter reads the visitor’s choice, maps your CMP’s category names onto Fidero’s and keeps the two in sync when the choice changes. Which adapter runs is part of your project configuration.

On any other CMP, or a custom banner, call updateConsent with the same categories – on every page load, because Fidero reads consent fresh each page rather than keeping a stale copy.

When Google destinations are enabled, the SDK also signals Google Consent Mode from the same consent state (basic or advanced mode, part of the same configuration), so Google’s tools follow your CMP without a separate integration.

Before consent

A visitor’s first page view usually lands before they’ve answered the banner. Fidero queues rather than drops: events wait, and when consent arrives they replay – so a choice made two pages in doesn’t cost you the start of the session. If consent never comes, they’re never sent.

What runs meanwhile depends on what’s been granted:

The visitor has granted	What Fidero does
Nothing yet	Queues events. Identity stays in memory only – nothing is written to the browser
Advertising only	Sends events, and the server fans out to your ad destinations (and your warehouse, which consent doesn’t gate). No persisted ID and no first-party attribution – ad platforms match on their own click IDs
Analytics (with or without advertising)	Everything: identity persists, queued events replay and each destination the consent allows receives the event

Note

Some events are operational rather than analytical – a demo request the visitor expects to reach your CRM. Your project configuration can allow-list specific events to send regardless of consent state, with minimal enrichment.

On the server

Server events are where consent usually breaks, because the system sending them never saw a banner. Fidero closes that gap with the same memory it uses for attribution: the consent captured in the browser is stored on the person’s profile, and when a server event arrives for that person – a renewal from your billing system, a CRM update – Fidero re-attaches the stored consent before fan-out and enforces it per destination.

When there’s no consent on file, nothing is invented. The event passes through under the second rule, with no consent object added – an empty one would read downstream as “consent collected, everything denied”, which would be false.

Each third-party destination requires one or more consent categories, and the standard requirements are built in: ad platforms typically require advertising, analytics tools analytics. Your own warehouse requires none: it’s your system of record, in infrastructure you own, so it receives every event that reaches Fidero, regardless of consent state. Consent categories gate what reaches other tools. Your configuration can also change the categories a named destination requires – say, classifying a support chat widget as essential, so it loads for every visitor. That’s a deliberate, per-destination decision, and it’s yours to make. The effective consent a destination is gated by is the visitor’s choice, enforced against that destination’s required categories.

The profile that carries consent lives on Fidero’s server – the platform overview covers the architecture behind that.

Withdrawal and erasure

Consent can be taken back. When a visitor withdraws analytics consent, Fidero deletes the visitor’s identity from that browser and records the withdrawal on the profile, so later events for that person – including server events – are gated against the revoked state at every third-party destination.

Withdrawal is not erasure. A right-to-erasure request removes the profile itself, and Fidero fans the deletion out to downstream destinations. Security & compliance covers data handling in full.

Related

Guarantees & coverage What consent enforcement is guaranteed, stated as rules rather than percentages.

Data quality & delivery Consent is one of the places data breaks quietly – how Fidero validates and delivers.

Methods The consent API: updateConsent to set the visitor's choice, getConsent to read it.