Medgivande och identitet i datainsamling

Samtycke och identitet är nära sammankopplade i Web SDK-implementeringar. Hur och när du samlar in ditt samtycke påverkar direkt när och om Web SDK genererar ett ECID, ställer in identitetscookies och skickar data till Edge Network. När samtycke inte hanteras med omsorg blir resultatet ofta oväntad besöksinflammation, luckor i identitetskontinuiteten eller både och.

På den här sidan beskrivs hur medgivandeval interagerar med identitetsbeteenden och ger vägledning för hur du konfigurerar implementeringen för att undvika vanliga fallgropar. Bakgrund om hur Web SDK hanterar ECID:n, FPID:n och andra identitetssignaler finns i Identitet i datainsamling.

Hur samtycke påverkar identitet how-consent-affects-identity

Web SDK använder både konfigurationsvariabeln defaultConsent och kommandot setConsent för att kontrollera om data skickas till Edge Network. Medgivandestatus avgör direkt när ett ECID genereras och när identitetscookies ställs in.

I följande tabell visas den kombinerade effekten av defaultConsent och setConsent på datainsamling, cookie-inställning och identitetsbeteende.

När en besökare återger sitt samtycke efter att tidigare ha återkallat det (genom att anropa setConsent med "general": "in" efter "general": "out"), fortsätter Web SDK att skicka händelser och använder det befintliga ECID:t från cookien om det inte har gått ut. Besökarens identitet bevaras.

När en besökare har gett eller nekat sitt samtycke, kommer Web SDK att behålla sin inställning i en cookie för kndctr_-samtycke. Vid efterföljande sidinläsningar läser SDK in denna cookie och tillämpar den lagrade inställningen automatiskt - du behöver inte anropa setConsent igen om inte besökarens inställning ändras. Observera att konfigurationsvärdet defaultConsent inte finns kvar mellan sidinläsningar, men besökarens lösta samtycke (som anges via setConsent) gör det.

Implementeringsmönster implementation-patterns

Modell för anmälan (samtycke krävs före insamling) opt-in

Använd det här mönstret när bestämmelser (som GDPR) kräver uttryckligt medgivande innan data samlas in.

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

Med detta mönster:

Modell för avanmälan (samling som standard, stopp vid nekande) opt-out

Använd det här mönstret när reglerna tillåter datainsamling som standard med ett alternativ att välja bort.

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

Med detta mönster:

Samtycke med enhets-ID:n från första part consent-with-fpids

Om implementeringen använder FPID:n (First-party device ID:n) anges FPID-cookien av servern oberoende av Web SDK-medgivandetillståndet. FPID-cookie är en identifierare som du hanterar på din egen infrastruktur. FPID skickas dock endast till Edge Network när webb-SDK skickar en begäran (som skapas genom samtycke):

Om implementeringen av ditt samtycke kräver att ingen identifierare anges före samtycke, fördröjs inställningen av FPID-cookie tills efter att samtycke har skickats. Enbart SDK-samtycke förhindrar inte att FPID-cookien ställs in eftersom den hanteras av servern.

Vanliga fallgropar common-pitfalls