Running Device Intelligence Behind a Consent Banner

Most device-intelligence integrations are written before anyone asks how they interact with the cookie banner. Then a privacy review asks, and the answer is “it runs on every page, before the banner.” That is rarely the answer you want to give.

This post covers the practical side: how to wire Prynt’s consent options to a consent management platform (CMP), how to decide which checks run before consent, how Global Privacy Control fits in, and what to write down. It is not legal advice. The legal basis for device identification depends on your jurisdiction and your purposes, and your counsel should make that call. The goal here is that whatever they decide, your integration actually does it.

The three switches

Prynt’s browser agent has three privacy options, set in Prynt.load():

Option	Default	Effect
respectGPC	true	If the browser sends Global Privacy Control, identification is withheld
respectDNT	false	If enabled and the browser sends Do Not Track, identification is withheld
requireConsent	false	Identification is withheld until you call setConsent(true)

“Withheld” means something specific. The agent does not collect device signals. It sends a minimal request flagged as consent-withheld; the server meters the call but resolves no identity, stores no event and sets no identifier. identify() resolves with an empty requestId and consentWithheld: true. Nothing breaks, and your server sees “no identification,” which it already has to handle for script blockers.

Wiring it to a CMP

Every CMP exposes some way to read the current choice and to listen for changes. The integration is the same shape regardless of vendor:

const prynt = await Prynt.load({
  apiKey: 'pk_live_…',
  requireConsent: true,       // wait for an explicit yes
});

// 1. Apply the stored choice on page load
prynt.setConsent(cmp.hasConsent('fraud_prevention'));

// 2. Follow later changes, in both directions
cmp.onChange(() => prynt.setConsent(cmp.hasConsent('fraud_prevention')));

// 3. Identify only when it is needed, e.g. on submit
form.addEventListener('submit', async (e) => {
  e.preventDefault();
  try {
    const { requestId } = await prynt.identify({ tag: { action: 'signup' } });
    form.elements.prynt_request_id.value = requestId;   // empty if withheld
  } catch {
    // network error or blocker: submit without an id, the server treats it as missing
  }
  form.submit();
});

cmp.hasConsent and cmp.onChange stand in for your CMP’s real API. Two details are worth getting right:

• Call setConsent(false) when consent is withdrawn, not only true when it is granted. Without that, a user who withdraws consent mid-session keeps being identified until they reload.
• Create a purpose that describes the processing. Folding fraud prevention into “analytics” or “marketing” makes the banner less accurate and makes refusals cost you security for no reason. A clearly described purpose, such as “Security and fraud prevention,” is easier to explain and easier to audit.

Deciding what runs before consent

This is the real decision, and it is a legal and product decision rather than a technical one. Two common positions:

Consent everywhere. requireConsent: true on every page. Identification happens only after the user says yes. This is the simplest position to explain. The cost is that a signup from a user who declined carries no device evidence.

Security-critical actions handled separately. Some organizations conclude, with their counsel, that identifying the device during a security-sensitive action the user initiated, such as creating an account, logging in or paying, can rest on a different basis than marketing measurement. Under that position, they load the agent without requireConsent only on those flows, and keep requireConsent: true everywhere else. Whether that position holds in your jurisdiction is exactly the question for counsel; regulators in the EU and UK have published guidance on device-access rules that your team should read. Our posts on GDPR and device fingerprinting and on ePrivacy and PECR summarize the questions involved.

Either way, avoid the most common mistake: identifying on page load on every page “just in case.” Identify on the action you are protecting. That is better for privacy and it also produces cleaner data, because each event corresponds to a decision.

Honoring GPC by default

Global Privacy Control is a browser signal that the user does not want their data sold or shared. Some US state laws treat it as a valid opt-out. Prynt honors it by default (respectGPC: true): identification is withheld for those browsers no matter what the CMP says.

You can turn it off. Think hard before you do. A user who set GPC has made the most explicit choice a browser can express, and overriding it in the name of fraud prevention is hard to defend in a privacy review. The GPC and Do Not Track post covers the trade-offs.

What the server does without an identification

If a signup arrives without a requestId, whether from declined consent, GPC, a script blocker or a direct POST, the server has to decide. Prynt’s signup recipes default to flag: create the account, mark it for review, show the user nothing different. That keeps privacy choices from turning into lockouts.

Do not use “no identification” as a strong fraud signal. Abusers do block scripts, but so do many careful users, and declining a consent purpose should not make anyone a suspect. If you need more assurance for accounts without device evidence, use a step that works without identification: email verification, a phone number, or a proof-of-work challenge.

Data minimization on the server

Consent controls when data is collected. Minimization controls how much. Prynt supports IP minimization (full, truncated or no IP storage), retention limits per plan, and erasure by visitorId or by your own linkedId, which makes subject-access and deletion requests a single call rather than a hunt. The privacy page and the DPA describe the details.

Write down your reasoning

Whatever you configure, record it next to the code and in your records of processing:

• which pages and actions identify devices, and with which options;
• the purpose and legal basis your counsel chose for each, and why;
• how GPC, DNT and declined consent are handled, and what the server does with missing identifications;
• retention and IP-handling settings, and who can change them.

A page like that turns a privacy review from an investigation into a check. Keep it current when you add a new protected flow.