Destinations

Consent rules

Gate each destination on the consent the visitor actually granted.

Every event carries a consent snapshot — the four Google Consent Mode v2 categories as they stood when the event fired. Each destination decides, on its own, which of those categories it requires before it will forward anything.

This is a per-destination control on purpose. The consent basis you rely on for one ad platform is not necessarily the basis you rely on for another, and one legal review shouldn’t force you to loosen every integration at once.

The four categories

  • ad_user_data — permission to send the visitor’s data to an ad platform.
  • ad_storage — permission to store and read advertising identifiers.
  • ad_personalization — permission to use the data for personalized ads.
  • analytics — permission for analytics storage.

Enforcement

Each destination has an enforcement toggle plus a switch per required category.

  • Enforcement on (the default) — if the event’s consent snapshot denies any required category, the send is skipped.
  • Enforcement off — consent is recorded on the event but never blocks a send. You are then relying on some other basis for the transfer.

The required categories default to ad_user_data and ad_storage. Those are the two that describe what a conversions API actually does: it takes user data and sends it to an advertiser’s platform. ad_personalization and analytics are available but not required by default.

Unset is not denied. Only an explicit denial gates a send. A visitor who has never interacted with your consent banner has no denial recorded, so events flow — which is why your banner’s default state, not Pivolio’s, decides what happens to first-page-view traffic.

What a gated send looks like

A gated event is recorded with a delivery status of skipped. In the dashboard it appears in the destination’s delivery breakdown and in the Live Debugger next to the event, alongside genuinely unmapped events.

Two consequences worth internalizing:

  • Skipped is not a failure. It doesn’t count against your success rate, doesn’t retry, and doesn’t raise an error. A destination can be perfectly healthy and delivering almost nothing.
  • The event is still tracked, stored and reported. Consent gating stops the outbound send, not the collection. Your Pivolio reporting still shows the conversion; the ad platform just never hears about it.

If a destination’s delivered count collapsed after a consent-banner change, skipped is the first number to look at.

Separately from destination gating, the browser SDK trims what it collects based on the same categories:

  • ad_storage denied — the event is not sent at all.
  • ad_user_data denied — PII traits are stripped before the event leaves.
  • ad_personalization denied — ad click IDs are stripped.

So an event that arrives at a destination under partial consent may be missing the identifiers that make it matchable. It will be delivered and it will match poorly. That shows up as a falling match quality score rather than as an error.

Choosing a setting

  • Regulated market, cookie banner in place — leave enforcement on with the defaults. Denied traffic gets skipped and your reports still count it.
  • Adding ad_personalization as required — reasonable if your legal basis ties conversion uploads to personalized advertising. Expect delivered volume to drop, since banners commonly get partial grants.
  • Turning enforcement off — only with a documented basis. Nothing in Pivolio will stop you; nothing in Pivolio will defend you either.