Consent and identity in Data Collection

Consent and identity are closely connected in Web SDK implementations. How and when you collect consent directly affects when and whether the Web SDK generates an ECID, sets identity cookies, and sends data to the Edge Network. When consent is not handled carefully, the result is often unexpected visitor inflation, gaps in identity continuity, or both.

This page explains how consent choices interact with identity behavior and provides guidance for configuring your implementation to avoid common pitfalls. For background on how the Web SDK handles ECIDs, FPIDs, and other identity signals, see Identity in Data Collection.

How consent affects identity how-consent-affects-identity

The Web SDK uses both the defaultConsent configuration variable and the setConsent command to control if it sends data to the Edge Network. Consent status directly determines when an ECID is generated and when identity cookies are set.

The following table shows the combined effect of defaultConsent and setConsent on data collection, cookie setting, and identity behavior.

When a visitor re-grants consent after previously revoking it (by calling setConsent with "general": "in" after "general": "out"), the Web SDK resumes sending events and uses the existing ECID from the cookie if it has not expired. The visitor’s identity is preserved.

After a visitor grants or denies consent, the Web SDK persists their preference in a kndctr_ consent cookie. On subsequent page loads, the SDK reads this cookie and applies the stored preference automatically — you do not need to call setConsent again unless the visitor’s preference changes. Note that the defaultConsent configuration value does not persist between page loads, but the visitor’s resolved consent (set through setConsent) does.

Implementation patterns implementation-patterns

Opt-in model (consent required before collection) opt-in

Use this pattern when regulations (such as GDPR) require explicit consent before collecting any data.

alloy("configure", {
  orgId: "YOUR_ORG_ID@AdobeOrg",
  edgeDomain: "data.example.com",
  defaultConsent: "pending"
});

// When the visitor grants consent:
alloy("setConsent", {
  consent: [{
    standard: "Adobe",
    version: "1.0",
    value: { general: "in" }
  }]
});

With this pattern:

Opt-out model (collection by default, stop on denial) opt-out

Use this pattern when regulations allow data collection by default with an option to opt out.

alloy("configure", {
  orgId: "YOUR_ORG_ID@AdobeOrg",
  edgeDomain: "data.example.com",
  defaultConsent: "in"
});

// If the visitor opts out:
alloy("setConsent", {
  consent: [{
    standard: "Adobe",
    version: "1.0",
    value: { general: "out" }
  }]
});

With this pattern:

Consent with first-party device IDs consent-with-fpids

If your implementation uses first-party device IDs (FPIDs), the FPID cookie is set by your server independently of the Web SDK’s consent state. The FPID cookie is an identifier you manage on your own infrastructure. However, the FPID is only sent to the Edge Network when the Web SDK makes a request (which is gated by consent):

If your consent implementation requires that no identifier be set before consent, delay setting the FPID cookie until after consent is communicated. The Web SDK’s consent gating alone does not prevent the FPID cookie from being set, since it is managed by your server.

Common pitfalls common-pitfalls