Toestemming en identiteit in gegevensverzameling

De toestemming en de identiteit worden nauw verbonden in de implementaties van SDK van het Web. De manier waarop en wanneer u toestemming verzamelt, beïnvloedt rechtstreeks wanneer en of de Web SDK een ECID genereert, identiteitscookies instelt en gegevens naar de Edge Network verzendt. Wanneer de toestemming niet zorgvuldig wordt behandeld, is het resultaat vaak onverwachte bezoekersinflatie, hiaten in identiteitscontinuïteit, of allebei.

Deze pagina verklaart hoe de toestemmingskeuzen met identiteitsgedrag in wisselwerking staan en verstrekt raad voor het vormen van uw implementatie om gemeenschappelijke valkuilen te vermijden. Voor achtergrond op hoe het Web SDK ECIDs, FPIDs, en andere identiteitssignalen behandelt, zie ​ Identiteit in de Inzameling van Gegevens ​.

Hoe invloed de toestemming heeft op de identiteit how-consent-affects-identity

Web SDK gebruikt zowel de defaultConsent configuratievariabele als het setConsent bevel om te controleren als het gegevens naar Edge Network verzendt. De status van toestemming bepaalt rechtstreeks wanneer een ECID wordt gegenereerd en wanneer identiteitscookies worden ingesteld.

In de volgende tabel ziet u het gecombineerde effect van defaultConsent en setConsent op gegevensverzameling, cookie-instelling en identiteitsgedrag.

Wanneer een bezoeker toestemming opnieuw verleent nadat deze eerder is ingetrokken (door setConsent met "general": "in" after "general": "out" aan te roepen), hervat Web SDK het verzenden van gebeurtenissen en gebruikt de bestaande ECID van het cookie als deze nog niet is verlopen. De identiteit van de bezoeker blijft behouden.

Nadat een bezoeker zijn toestemming heeft verleend of geweigerd, houdt de Web SDK zijn voorkeur aan in een kndctr_ toestemmingscookie. Als de volgende pagina wordt geladen, leest de SDK deze cookie en past de opgeslagen voorkeur automatisch toe. U hoeft setConsent niet opnieuw aan te roepen tenzij de voorkeur van de bezoeker verandert. De configuratiewaarde defaultConsent blijft niet bestaan tussen paginaladingen, maar de door de bezoeker gekozen toestemming (ingesteld via setConsent ) wel.

Implementatiepatronen implementation-patterns

Inschakelmodel (toestemming vereist voor verzameling) opt-in

Gebruik dit patroon als voorschriften (zoals GDPR) uitdrukkelijke toestemming vereisen voordat u gegevens verzamelt.

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

Met dit patroon:

Opt-out model (verzameling standaard, stoppen bij ontkennen) opt-out

Gebruik dit patroon als de regelgeving gegevensverzameling standaard toestaat, met de optie Weigeren.

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

Met dit patroon:

Goedkeuring met apparaat-id's van de eerste partij consent-with-fpids

Als uw implementatie ​ eerste-partijapparaat IDs (FPIDs) ​ gebruikt, wordt het FPID- koekje geplaatst door uw server onafhankelijk van de de toestemmingsstaat van SDK van het Web. Het FPID-cookie is een id die u beheert op uw eigen infrastructuur. De FPID wordt echter alleen naar de Edge Network verzonden wanneer de Web SDK een aanvraag indient (die met instemming wordt ingediend):

Als voor de uitvoering van uw toestemming geen id moet worden ingesteld voordat toestemming wordt gegeven, stelt u het FPID-cookie pas in nadat toestemming is gegeven. Alleen de toestemming van SDK Web verhindert niet dat het FPID-cookie wordt ingesteld, omdat dit cookie door uw server wordt beheerd.

Veelvoorkomende valkuilen common-pitfalls