Consent
The SDK is consent-first. Until evx.consent({ analytics: true }) it sets no cookie, uses no storage and sends nothing; calls wait in memory (up to 100) and are dropped when the page unloads. Call it on every page load from the site's banner, with the current state:
evx.consent({ analytics: true, ads: false, personalisation: false });
| Category | Unlocks |
|---|---|
analytics | the anonymous id cookie, sessions, sending at all |
ads | reading ad click ids from the address and cookies into the touch |
personalisation | recorded in the consent snapshot for the CRM; the SDK itself needs nothing from it |
Declining removes the SDK's cookies and its retry queue; calls not yet sent are dropped, except the banner-exempt ones below.
Banner-exempt actions
Some actions have their own lawful basis and must not wait for a banner: a newsletter sign-up, the buyer entering their details in the checkout, a basket being placed. The server marks those activities (banner_exempt in the configuration), and the SDK sends a track of such a name before consent, without an anonymous id or session: the action is recorded, the visitor is not followed. By default these are subscribed_newsletter, entered_details and placed_basket, and any name the owner's rules map onto one. The SDK knows no names of its own: if the configuration does not arrive, nothing is sent before consent. The CRM's sign-up forms record a sign-up from the server instead, and read the SDK's id only when there is analytics consent.
What the server records
Every call carries the consent snapshot under context.evx.consent, and started_session keeps it in its touch, so a later question "was this click id read with ads consent?" has an answer in the stream. Consent facts for marketing (what box, which text) are not the SDK's: the system that holds the form sends granted_consent.