Consenso e identità nella raccolta dati

Il consenso e l’identità sono strettamente connessi nelle implementazioni di Web SDK. Le modalità e i tempi di raccolta del consenso influiscono direttamente su quando e se Web SDK genera un ECID, imposta i cookie di identità e invia i dati ad Edge Network. Quando il consenso non viene gestito con attenzione, il risultato è spesso un’inflazione inaspettata dei visitatori, lacune nella continuità dell’identità o entrambi.

Questa pagina spiega come le scelte di consenso interagiscono con il comportamento di identità e fornisce indicazioni per configurare la tua implementazione per evitare insidie comuni. Per informazioni generali sulla gestione di ECID, FPID e altri segnali di identità da parte del Web SDK, vedere Identità nella raccolta dati.

Come il consenso influisce sull’identità how-consent-affects-identity

Il Web SDK utilizza sia la variabile di configurazione defaultConsent che il comando setConsent per controllare se invia dati ad Edge Network. Lo stato di consenso determina direttamente quando viene generato un ECID e quando vengono impostati i cookie di identità.

Nella tabella seguente viene illustrato l'effetto combinato di defaultConsent e setConsent sulla raccolta dati, l'impostazione dei cookie e il comportamento di identità.

Quando un visitatore concede nuovamente il consenso dopo averlo revocato in precedenza (chiamando setConsent con "general": "in" dopo "general": "out"), il Web SDK riprende a inviare eventi e utilizza l'ECID esistente dal cookie se non è scaduto. L’identità del visitatore viene mantenuta.

Quando un visitatore concede o nega il consenso, il Web SDK mantiene la preferenza in un cookie di consenso kndctr_. Al caricamento delle pagine successive, il SDK legge il cookie e applica automaticamente la preferenza memorizzata. Non è necessario chiamare nuovamente setConsent a meno che la preferenza del visitatore non cambi. Il valore di configurazione defaultConsent non persiste tra i caricamenti di pagina, ma il consenso risolto del visitatore (impostato tramite setConsent) sì.

Modelli di implementazione implementation-patterns

Modello Opt-in (consenso necessario prima della raccolta) opt-in

Utilizza questo modello quando le normative (come il RGPD) richiedono il consenso esplicito prima di raccogliere i dati.

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" }
  }]
});

Con questo pattern:

Modello di rinuncia (raccolta per impostazione predefinita, interruzione in caso di rifiuto) opt-out

Utilizza questo modello quando le normative consentono la raccolta dei dati per impostazione predefinita con un’opzione di rinuncia.

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" }
  }]
});

Con questo pattern:

Consenso con gli ID dispositivo di prime parti consent-with-fpids

Se la tua implementazione utilizza ID dispositivo di prime parti (FPID), il cookie FPID viene impostato dal server indipendentemente dallo stato del consenso di Web SDK. Il cookie FPID è un identificatore che gestisci sulla tua infrastruttura. Tuttavia, l’FPID viene inviato all’Edge Network solo quando il Web SDK effettua una richiesta (che viene gestita dal consenso):

Se l’implementazione del consenso richiede che nessun identificatore sia impostato prima del consenso, ritarda l’impostazione del cookie FPID fino alla comunicazione del consenso. Il solo controllo del consenso del Web SDK non impedisce l’impostazione del cookie FPID, in quanto è gestito dal server.

Insidie comuni common-pitfalls