Apparaat-id's van de eerste partij gebruiken in Web SDK

Het Web SDK van Adobe Experience Platform wijst Adobe Experience Cloud IDs (ECIDs)aan websitebezoekers toe die koekjes gebruiken om gebruikersgedrag te volgen. Als u browserbeperkingen op de levensduur van cookies wilt verhelpen, kunt u uw eigen apparaat-id's (zogenaamde FPID's) instellen en beheren.

Vereisten prerequisites

Voordat u begint, moet u goed op de hoogte zijn van de werking van identiteitsgegevens in de Web SDK, inclusief ECID's en identityMap . Zie het overzicht op identiteitsgegevens in het Web SDKvoor meer informatie.

Opmaakvereisten voor eerste apparaat-id's formatting-requirements

Edge Network keurt slechts IDs goed die aan het formaat UIDv4voldoen. Apparaat-id's die niet de UUIDv4-indeling hebben, worden geweigerd.

Stel het cookie FPID in met uw eigen server set-cookie-server

Wanneer u een cookie instelt via uw eigen server, kunt u verschillende methoden gebruiken om te voorkomen dat het cookie wordt beperkt door het browserbeleid:

Bovendien moet u het FPID-cookie altijd onder de A -record van uw domein instellen.

Wanneer stelt u het cookie in when-to-set-cookie

Het cookie FPID moet idealiter worden ingesteld voordat aanvragen bij de Edge Network worden ingediend. In situaties waarin dat niet mogelijk is, wordt een ECID echter nog steeds gegenereerd met bestaande methoden en fungeert het als de primaire id zolang het cookie bestaat.

Ervan uitgaande dat ECID uiteindelijk wordt beïnvloed door een beleid voor het verwijderen van browsers, maar FPID niet, wordt FPID de primaire id bij het volgende bezoek en wordt deze gebruikt om ECID bij elk volgend bezoek te begeleiden.

De vervaldatum van de cookie instellen set-expiration

Het instellen van de vervaldatum van een cookie moet zorgvuldig worden overwogen wanneer u de functie FPID implementeert. Wanneer u hierover beslist, moet u rekening houden met de landen of regio's waarin uw organisatie werkt, samen met de wetten en het beleid in elk van die regio's.

Als onderdeel van dit besluit wilt u mogelijk een beleid voor het instellen van cookies in het hele bedrijf toepassen of een beleid dat per landinstelling verschilt.

Ongeacht de instelling die u kiest voor de aanvankelijke vervaldatum van een cookie, moet u logica opnemen die de vervaldatum van de cookie verlengt telkens wanneer een nieuw bezoek aan de site plaatsvindt.

Gevolgen van cookie-vlaggen cookie-flag-impact

Er zijn verschillende cookiemarkeringen die van invloed zijn op de manier waarop cookies in verschillende browsers worden verwerkt:

HTTPOnly http-only

Cookies die zijn ingesteld met de markering HTTPOnly , zijn niet toegankelijk met clientscripts. Dit betekent dat als u bij het instellen van de FPID -markering een HTTPOnly -markering instelt, u een scripttaal aan de serverzijde moet gebruiken om de cookiewaarde te lezen voor opname in de identityMap .

Als u ervoor kiest dat de Edge Network de waarde van het cookie FPID laat lezen, zorgt het instellen van de markering HTTPOnly ervoor dat de waarde niet toegankelijk is voor clientscripts, maar geen negatieve invloed heeft op de mogelijkheid van de Edge Network om de cookie te lezen.

Secure secure

Cookies die zijn ingesteld met het kenmerk Secure worden alleen naar de server verzonden met een gecodeerde aanvraag via het protocol HTTPS . Door deze markering te gebruiken, kunt u ervoor zorgen dat aanvallers van 'man in the middle' de waarde van het cookie niet gemakkelijk kunnen benaderen. Het is altijd verstandig om de markering Secure in te stellen, als dat mogelijk is.

SameSite same-site

Met het kenmerk SameSite kunnen servers bepalen of cookies worden verzonden met aanvragen die verwijzen naar andere sites. Het kenmerk biedt enige bescherming tegen valsemunterij op andere locaties. Er zijn drie mogelijke waarden: Strict, Lax en None . Raadpleeg uw interne team om te bepalen welke instelling geschikt is voor uw organisatie.

Als er geen kenmerk SameSite is opgegeven, is de standaardinstelling voor sommige browsers nu SameSite=Lax .

ID-hiërarchie id-hierarchy

Wanneer zowel een ECID als een FPID aanwezig zijn, krijgt ECID prioriteit bij het identificeren van de gebruiker. Dit zorgt ervoor dat wanneer er een bestaande ECID aanwezig is in de cookie-opslag van de browser, dit de primaire id blijft en dat het aantal bestaande bezoekers niet kan worden beïnvloed. Voor bestaande gebruikers wordt FPID pas de primaire identiteit nadat ECID is verlopen of is verwijderd als gevolg van een browserbeleid of handmatig proces.

Identiteiten krijgen prioriteit in de volgende volgorde:

Migreren naar apparaat-id's van eerste bedrijven migrating-to-fpid

Als u van een vorige implementatie naar apparaat-id's van de eerste partij migreert, kan het moeilijk zijn om te visualiseren hoe de overgang er op een laag niveau uitziet.

Om dit proces te illustreren, kunt u een scenario overwegen waarbij een klant betrokken is die eerder uw site heeft bezocht en welke invloed een FPID -migratie zou hebben op de manier waarop die klant wordt geïdentificeerd in Adobe-oplossingen.

worden bijgewerkt

FPID's (First-party device ID's) gebruiken using-fpid

First-party apparaat IDs (FPIDs) houdt bezoekers door eerste-partijkoekjes te gebruiken bij. De koekjes van de eerste partij zijn het meest efficiënt wanneer zij gebruikend een server worden geplaatst die een DNS verslag van A(voor IPv4) of het verslag van AAAA(voor IPv6), in tegenstelling tot DNS CNAME of JavaScript code gebruikt.

Nadat een FPID -cookie is ingesteld, kan de waarde ervan worden opgehaald en naar Adobe worden verzonden wanneer gebeurtenisgegevens worden verzameld. Verzameld FPIDs wordt gebruikt om ECIDs te genereren. Dit zijn de primaire id's in Adobe Experience Cloud-toepassingen.

U kunt FPIDs op twee manieren gebruiken:

Methode 1: Vorm een CNAME voor uw vraag van SDK van het Web en plaats een Koekje van identiteitskaart van de Eerste Partij in uw gegevensstroom setting-cookie-datastreams

Als u een FPID cookie vanuit uw eigen domein wilt instellen, moet u uw eigen CNAME (Canonical Name) voor uw Web SDK-aanroepen configureren en vervolgens de First Party ID Cookie -functionaliteit in uw datastreamconfiguratie inschakelen.

Stap 1. Vorm een NAAM voor uw de plaatsingsdomein van SDK van het Web

Met een CNAME -record in uw DNS kunt u een alias maken van de ene domeinnaam naar de andere. Hierdoor kunnen services van derden er uitzien alsof ze deel uitmaken van uw eigen domein, waardoor hun cookies er zo uitzien als cookies van andere bedrijven.

Voorbeeld

Laten we overwegen of u Web SDK wilt implementeren op uw website mywebsite.com . Web SDK verzendt gegevens naar de Edge Network naar het edge.adobedc.net -domein.

Wanneer de inzameling van de eerste-partijgegevens gebruikend CNAME wordt toegelaten, zullen alle koekjes voor uw domein op verzoeken worden verzonden die aan het eindpunt van de gegevensinzameling worden gemaakt.

Als u deze functionaliteit wilt gebruiken, moet u de cookie FPID op het hoofdniveau van uw domein instellen in plaats van op een specifiek subdomein. Als u de waarde instelt op een subdomein, wordt de waarde van het cookie niet verzonden naar de Edge Network en werkt de oplossing FPID niet naar behoren.

Stap 2. ​First Party ID Cookie​ functionaliteit voor uw datastream inschakelen

Nadat u uw CNAME hebt gevormd, moet u First Party ID Cookie optie voor uw gegevensstroom toelaten. Dit het plaatsen vertelt Edge Network om naar een gespecificeerd koekje te verwijzen wanneer het kijken omhoog identiteitskaart van het eerste-partijapparaat, in plaats van het opzoeken van deze waarde in het identiteitskaart.

Zie de documentatie van de gegevensstroomconfiguratiehoe te opstelling uw datastream.

Zie de documentatie op eerste-partijkoekjesvoor meer details over hoe zij met Adobe Experience Cloud werken.

benadrukt

Wanneer u deze instelling inschakelt, moet u de naam opgeven van het cookie waarop de FPID moet worden opgeslagen.

Methode 2: FPID's gebruiken in identityMap identityMap

Als alternatief voor het opslaan van de FPID in uw eigen cookie, kunt u de FPID naar de Edge Network verzenden via de identiteitskaart.

Hieronder ziet u een voorbeeld van hoe u een FPID -element in de identityMap instelt:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ]
  }
}

Net als bij andere identiteitstypen kunt u de FPID opnemen met andere identiteiten in identityMap . Hieronder ziet u een voorbeeld van de lus FPID die is opgenomen met een geverifieerde CRM ID :

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": false
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

Als de FPID is opgenomen in een cookie die door de Edge Network wordt gelezen wanneer gegevensverzameling van de eerste partij is ingeschakeld, moet u alleen de geverifieerde CRM ID vastleggen:

{
  "identityMap": {
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

De volgende identityMap resulteert in een foutreactie van de Edge Network omdat deze de primary -indicator voor de FPID mist. Ten minste een van de id's in identityMap moet zijn gemarkeerd als primary .

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-12d3-a456-426614174000",
        "authenticatedState": "ambiguous"
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated"
      }
    ]
  }
}

De door de Edge Network in dit geval geretourneerde foutreactie zou vergelijkbaar zijn met het volgende:

{
    "type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
    "status": 400,
    "title": "No primary identity set in request (event)",
    "detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
    "report": {
        "requestId": "{REQUEST_ID}",
        "configId": "{CONFIG_ID}",
        "orgId": "{ORG_ID}"
    }
}

Veelgestelde vragen faq

Hieronder volgt een lijst met antwoorden op veelgestelde vragen over apparaat-id's van andere leveranciers.

Hoe anders zaait u een id dan eenvoudig een id genereren?

Het concept van zaaien is uniek in die zin dat de FPID die aan Adobe Experience Cloud wordt doorgegeven, wordt omgezet in een ECID met behulp van een deterministisch algoritme. Telkens wanneer dezelfde FPID naar de Edge Network wordt verzonden, wordt dezelfde ECID verzonden vanuit de FPID .

Wanneer moet de apparaat-id van de eerste partij worden gegenereerd?

Om potentiële bezoekersinflatie te verminderen, zou FPID moeten worden geproduceerd alvorens uw eerste verzoek te maken gebruikend het Web SDK. Als u dit echter niet kunt doen, wordt nog steeds een ECID gegenereerd voor die gebruiker en wordt deze gebruikt als primaire id. De gegenereerde FPID wordt pas de primaire id wanneer ECID niet meer aanwezig is.

Welke methodes van de gegevensinzameling steunen eerste-partij apparaat IDs?

Alleen Web SDK biedt momenteel ondersteuning voor apparaat-id's van andere leveranciers.

Worden de eerste-partijapparaat IDs opgeslagen op om het even welke oplossing van het Platform of van Experience Cloud?

Nadat FPID is gebruikt om een ECID te verzenden, wordt het verwijderd uit de identityMap en vervangen door de ECID die is gegenereerd. FPID wordt niet opgeslagen in Adobe Experience Platform- of Experience Cloud-oplossingen.