Eerste-partij apparaat IDs in Web SDK

De Adobe Experience Platform Web SDK wijst Adobe Experience Cloud-id's (ECID's) aan websitebezoekers door koekjes te gebruiken, om gebruikersgedrag te volgen. Als u browserbeperkingen voor de levensduur van cookies wilt compenseren, kunt u ervoor kiezen om uw eigen apparaat-id's in te stellen en te beheren. Deze worden ook wel FPID's (First-Party Device ID's) genoemd.

Dit document behandelt hoe te om eerste-partijapparaat IDs voor uw implementatie van SDK van het Web van het Platform te vormen.

Vereisten

Deze gids veronderstelt u vertrouwd met bent hoe de identiteitsgegevens voor het Web SDK van het Platform werken, met inbegrip van de rol van ECIDs en identityMap. Zie het overzicht op identiteitsgegevens in de SDK van het Web voor meer informatie .

FPID's gebruiken

FPID's volgen bezoekers met behulp van cookies van de eerste partij. De eerste partijkoekjes zijn het meest efficiënt wanneer zij gebruikend een server worden geplaatst die DNS gebruikt Een record (voor IPv4) of AAAA-record (voor IPv6), in tegenstelling tot een DNS CNAME- of JavaScript-code.

Nadat een FPID-cookie is ingesteld, kan de waarde ervan worden opgehaald en naar de Adobe worden verzonden wanneer gebeurtenisgegevens worden verzameld. Verzamelde FPID's worden gebruikt als zaden om ECID's te genereren, die in Adobe Experience Cloud-toepassingen nog steeds de belangrijkste identificatoren zijn.

Als u een FPID voor een websitebezoeker naar het Platform Edge Network wilt verzenden, moet u de FPID opnemen in het dialoogvenster identityMap voor die bezoeker. Zie de sectie verderop in dit document op FPID's gebruiken in identityMap voor meer informatie .

Vereisten voor id-opmaak

Het Netwerk van de Rand van het Platform keurt slechts identiteitskaart's goed die aan het voldoen UUIDv4-indeling. Apparaat-id's die niet de UUIDv4-indeling hebben, worden geweigerd.

Het genereren van een UUID zal bijna altijd resulteren in een unieke, willekeurige id, waarbij de kans dat een botsing optreedt verwaarloosbaar is. UUIDv4 kan niet worden verzonden gebruikend IP adressen of een andere persoonlijke identificeerbare informatie (PII). UUID's zijn alomtegenwoordig en bibliotheken kunnen voor vrijwel elke programmeertaal worden gevonden om ze te genereren.

Een cookie instellen met uw eigen server

Wanneer u een cookie instelt met een server die u bezit, kunt u verschillende methoden gebruiken om te voorkomen dat het cookie wordt beperkt door het browserbeleid:

Wanneer stelt u het cookie in

Het FPID-cookie moet idealiter worden ingesteld voordat u een aanvraag indient bij het Edge-netwerk. In gevallen waarin dat niet mogelijk is, wordt een ECID echter nog steeds gegenereerd met behulp van bestaande methoden en fungeert deze als primaire id zolang het cookie bestaat.

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

De vervaldatum van de cookie instellen

Het instellen van de vervaldatum van een cookie moet zorgvuldig worden overwogen wanneer u de FPID-functionaliteit 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

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 HTTPOnly Markering kan niet worden benaderd met clientscripts. Dit betekent dat als u een HTTPOnly markering bij het instellen van de FPID, moet u een scripttaal aan serverzijde gebruiken om de cookiewaarde voor opname in de identityMap.

Als u ervoor kiest om het Edge-netwerk van het platform de waarde van het FPID-cookie te laten lezen, stelt u de optie HTTPOnly De vlag zorgt ervoor dat de waarde niet toegankelijk door om het even welke cliënt-zijmanuscripten is maar geen negatieve invloed op de capaciteit van het Netwerk van de Rand van het Platform zal hebben om het koekje te lezen.

Secure secure

Cookies die zijn ingesteld met de Secure wordt alleen naar de server verzonden met een gecodeerde aanvraag via het HTTPS-protocol. 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, indien mogelijk, de Secure markering.

SameSite same-site

De SameSite Met dit kenmerk 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.

Indien niet SameSite kenmerk is opgegeven. De standaardinstelling voor sommige browsers is nu SameSite=Lax.

FPID's gebruiken in identityMap identityMap

Hieronder ziet u hoe u een FPID instelt in het dialoogvenster identityMap:

{
  "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 binnen identityMap. Hieronder ziet u een voorbeeld van de FPID die is opgenomen in een geautoriseerde CRM-id:

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

Als FPID in een koekje bevat dat door het Netwerk van de Rand wordt gelezen wanneer de inzameling van de eerste-partijgegevens wordt toegelaten, zou u slechts voor authentiek verklaarde identiteitskaart van CRM moeten vangen:

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

Het volgende identityMap zou resulteren in een foutreactie van het Edge Network, omdat het de primary -indicator voor de FPID. Ten minste een van de id's in identityMap moeten worden gemarkeerd als primary.

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

De foutenreactie die door het Netwerk van Edge in dit geval is teruggekeerd zou aan het volgende gelijkaardig zijn:

{
    "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}"
    }
}

ID-hiërarchie

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

Identiteiten krijgen prioriteit in de volgende volgorde:

Migreren naar apparaat-id's van eerste bedrijven

Als u naar het gebruiken van FPIDs van een vorige implementatie migreert, kan het moeilijk zijn om te visualiseren hoe de overgang op een laag niveau zou kunnen kijken.

Om dit proces te illustreren, overweeg een scenario dat een klant impliceert die eerder uw plaats heeft bezocht en welke invloed een migratie FPID op hoe zou hebben die klant in de oplossingen van de Adobe wordt geïdentificeerd.

Veelgestelde vragen

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 begrip zaaien is uniek omdat 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 het Adobe Experience Platform Edge Network wordt verzonden, wordt dezelfde ECID van de FPID verzonden.

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 SDK van het Web. Als u dit echter niet kunt doen, wordt er nog steeds een ECID gegenereerd voor die gebruiker en wordt deze gebruikt als primaire id. De gegenereerde FPID wordt pas de primaire id als de ECID niet meer aanwezig is.

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

Momenteel steunt slechts Web SDK FPIDs.

Worden FPIDs opgeslagen op om het even welk platform of Experience Cloud oplossingen?

Zodra FPID is gebruikt om een ECID te zaaien, wordt het geschrapt van identityMap en vervangen door de ECID die is gegenereerd. De FPID wordt niet opgeslagen in Adobe Experience Platform- of Experience Cloud-oplossingen.