Consent integration for privacy teams
Plain-language guidance for how Apex renders tests before consent while blocking persistent identity and tracking until permission is available.
Apex separates storefront rendering from analytics consent. This lets a visitor receive a stable page treatment without Apex writing a persistent identifier or sending tracking events before the store's consent rule allows it.
This page explains product behavior and implementation choices; it is not legal advice. The store's privacy owner or DPO should decide which consent categories and regional rules apply.
What can happen before consent
- Apex can evaluate eligibility and render the assigned variation.
- The visitor identifier exists only in browser memory for that page load.
- Anti-flicker can hide and reveal treatment elements so the control does not flash first.
The memory-only identifier is temporary. A reload can produce a new identifier and assignment until consent permits persistence.
What stays blocked
While consent is required but not granted, Apex treats tracking as blocked and persistent storage as unavailable:
- no analytics, exposure, goal, heatmap, revenue, or other tracking events are sent;
- no persistent visitor or assignment identity is written;
- existing Apex consent-controlled visitor, goal, signal, config-cache, session, QA, and identity context storage is cleared where possible.
After consent is granted, the SDK can enable the configured storage mode, persist the active anonymous assignment, and start permitted tracking. Revoking consent stops tracking again and clears consent-controlled storage.
Connect a consent manager
For a custom CMP, initialize Apex in consent mode and pass every consent change to setConsent:
Drip.init({
shopId: "demo-shop",
endpoint: "https://events.drip-apex.com",
requireConsent: true,
hasConsent: false
});
cmp.on("consentChanged", ({ analyticsAllowed }) => {
window.drip.setConsent(analyticsAllowed);
});The queued equivalent before the hosted SDK finishes loading is:
window.drip.push({ type: "setConsent", granted: true });Apex can also read supported providers through consentMode:
| Provider | Configuration Apex reads |
|---|---|
onetrust | A required OneTrust group, using OnetrustActiveGroups or a configured getter path. |
usercentrics | A matching service name, ID, template ID, or data processor from UC_UI. |
cookiebot | A Cookiebot consent category such as statistics. |
ccm19 | A matching accepted embedding name or ID. |
pandectes | A Pandectes consent purpose (analytics, marketing, preferences, or sale_of_data), read from the Pandectes API with a Shopify customerPrivacy fallback. |
custom | A configured window getter, or explicit setConsent calls. |
consentMode: {
enabled: true,
provider: "usercentrics",
requiredGroup: "Apex"
}Test the initial denied state, later grant, later revocation, and a fresh page load in every region where the configuration is used.
Why the script itself must not be consent-gated
Place the Apex snippet directly in <head>. A tag manager or CMP that loads the script only after consent prevents Apex from installing anti-flicker before the first paint. Visitors can then see the original page and a late jump to the treatment.
Loading the script is not the same as granting analytics consent. With consent mode enabled, Apex can render a consistent page using memory-only identity while its tracking and persistent-storage gates remain closed.
Review checklist for a DPO
- Confirm which CMP category or service authorizes Apex storage and analytics.
- Confirm the initial page-load state is denied until the CMP provides a positive signal.
- Confirm variation rendering before consent is acceptable for the store's policy.
- Verify no Apex network tracking or persistent identity appears before consent.
- Verify grant and revocation update the SDK without reloading the page.
- Record the configured storage mode and the store's retention policy.