Skip to main content

​
Integration

Choose one of three consent paths: default (consent-aware), strict (withhold data until consent), or alternative (disable opt-in). All three use only first-party cookies, never third-party cookies. Visitors start not opted in. Pagent still runs tests and reports pseudonymous events, but does not write persistent visitor-ID, visit, variation, or cohort cookies or local storage before consent. A short-lived, daily-rotating seed cookie is still set to keep test assignment stable within a day.
Connect your consent platform to the opt-in and opt-out commands below. Keep the default consent wiring and add data-require-consent="true" to the SDK snippet:
Variations still apply and events are still collected, so the visitor’s experience and test assignment do not change. No request is made to the Pagent event endpoint until the SDK processes an opt-in command. Buffered events are then sent in bulk with their original timestamps.
  • The buffer lives in memory only, with a soft limit of 1,000 events per page load. Older behavioral events are discarded first; session and conversion events are preserved where possible, so the buffer can exceed that limit.
  • Nothing in the buffer survives a page reload. Visitors who leave without ever consenting are never reported.
  • The opt-out command discards the buffered events.
  • Use your consent platform as the source of truth. Queue an opt-in command on every page load where your consent platform reports acceptance.
  • data-disable-opt-in="true" takes precedence: if both attributes are set, data-require-consent="true" has no effect.
  • The daily seed cookie is still set to keep assignment stable. This flag gates event reporting; it does not prevent the SDK and experiment configuration from loading.

​
Alternative path: disabling opt-in

Use data-disable-opt-in="true" to treat every visitor as opted in immediately. This writes identifiers and reports events as soon as the SDK loads.
This path is recommended for testing only, or when your consent platform already controls when the snippet loads. Compliance depends on your own consent gating. When your consent platform records acceptance, queue an opt-in command. This pattern works before and after the SDK loads:
For both the default and strict paths, repeat this on every page load where your consent platform reports acceptance. Opt-in allows Pagent to persist stable identifiers and, in the strict path, releases the buffered events. On decline or withdrawal, queue an opt-out command. This pattern also works before and after the SDK loads:
Opt-out deletes visitor, visit, variation, and cohort cookies and clears the associated Pagent storage. It does not delete data already reported to Pagent. In the strict path it also discards buffered events and withholds subsequent events until another opt-in.

​
Daily seed and persistent identifiers

Before consent, Pagent derives identity from a daily-rotating seed instead of a persistent visitor ID. The short-lived _pgnt-seed cookie keeps assignment stable within a day and carries no stored personal identifier. It is set in both the default and strict paths, so neither path is entirely cookie-free. After opt-in, Pagent can write persistent identifiers for visitor, visit, variation, and cohort tracking. Choose the consent path that fits your site’s consent platform and privacy policy. See the SDK integration guide for loading strategies and other snippet attributes.