idMigrationEnabled
Die idMigrationEnabled-Eigenschaft ermöglicht es dem Web-SDK, AMCV-Cookies zu lesen, die von vorherigen Adobe Experience Cloud-Implementierungen festgelegt wurden. Wenn Ihr Unternehmen Ihre Implementierung auf Web SDK aktualisiert, ermöglicht diese Einstellung einen reibungsloseren Übergang zum aktuellen Adobe Experience Cloud ID-Service. Diese Einstellung ist nützlich, damit beim Upgrade auf Web SDK keine starke Zunahme von Unique Visitors auftritt.
Wenn Ihr Unternehmen eine neue Web SDK-Implementierung ausführt, hat die Aktivierung dieser Einstellung keine Auswirkungen auf die Datenerfassung oder Besucheridentifizierung. Es hat keine Nachteile, wenn es für alle Implementierungen aktiviert bleibt.
Funktionsweise der Identitätsmigration how-it-works
Die Besucher-API speichert die Experience Cloud-ID (ECID) in einem Cookie namens AMCV_<ORG_ID>. Wenn idMigrationEnabled (Standard) true ist, liest Web SDK automatisch die ECID aus dem AMCV-Cookie und verwendet sie bei der ersten Edge Network-Anfrage als Besucheridentität.
- Ein Besucher gelangt auf eine Seite, die jetzt Web SDK anstelle der Besucher-API verwendet.
- Web SDK sucht nach einem vorhandenen
kndctr_-Identitäts-Cookie (seinem eigenen Cookie-Format). Wenn kein Cookie gefunden wird, wird nach einemAMCV_Cookie gesucht. - Wenn ein
AMCV_Cookie gefunden wird, extrahiert Web SDK die ECID und verwendet sie, um die Besucheridentität zu initialisieren. - Web SDK setzt ein neues
kndctr_-Identitäts-Cookie mit derselben ECID. - Bei nachfolgenden Besuchen verwendet Web SDK das
kndctr_-Cookie direkt. DasAMCV_-Cookie wird nicht mehr benötigt.
Damit die Migration funktioniert, muss die Web-SDK mit demselben orgId konfiguriert werden, den die Besucher-API verwendet hat, und muss in derselben Domain (oder einer Subdomain derselben übergeordneten Domain) bereitgestellt werden, in der das AMCV-Cookie gesetzt wurde.
Unterstützte Migrationsszenarien
Die ID-Migration unterstützt die folgenden Übergangsmuster:
- Einige Seiten verwenden weiterhin die Besucher-API, während andere Seiten Web SDK verwenden: Die SDK liest vorhandene AMCV-Cookies und schreibt ein neues Cookie mit der bestehenden ECID. AMCV-Cookies werden auch so geschrieben, dass Seiten, die noch die Besucher-API verwenden, weiterhin denselben Besucher erkennen.
- Web-SDK und Besucher-API sind beide auf derselben Seite vorhanden: Wenn das AMCV-Cookie nicht gesetzt ist, sucht die SDK auf der Seite nach der Besucher-API und verwendet diese, um die ECID abzurufen.
- Die Website wurde vollständig in Web SDK verschoben: Sie können die Migration für einen bestimmten Zeitraum aktiviert lassen, sodass bestehende AMCV-basierte Besucherinnen und Besucher die Kontinuität behalten, während ihre Cookies übergeben werden.
Deaktivieren der Migration turn-off-migration
Nachdem Ihre gesamte Site auf der Web-SDK ausgeführt wird und keine Besuchenden nur ein AMCV_ Cookie ohne das entsprechende kndctr_-Cookie mit sich führen, können Sie die Identitätsmigration sicher deaktivieren, indem Sie idMigrationEnabled auf false setzen. Dies ist eine geringfügige Leistungsoptimierung und reduziert die Oberfläche Ihrer Identitätslogik.
Warten Sie als Richtlinie, bis die maximale Lebensdauer des AMCV-Cookies nach der Migration der letzten Seite abgelaufen ist. Wenn Ihre AMCV-Cookies zwei Jahre ablaufen, warten Sie zwei Jahre, nachdem die letzte Seite an die Web-SDK übergeben wurde. In der Praxis deaktivieren die meisten Unternehmen die Migration früher (nach einigen Monaten) und akzeptieren eine zu vernachlässigende Inflation durch die geringe Anzahl von Besuchern, die nach langer Abwesenheit zum ersten Mal zurückkehren.
Audience Manager-Eigenschaftsaktualisierungen
Wenn während der Migration XDM-formatierte Daten an Audience Manager gesendet werden, müssen diese Daten in Signale konvertiert werden. Ihre Eigenschaften müssen aktualisiert werden, um die neuen, von XDM bereitgestellten Schlüssel widerzuspiegeln. Dieser Prozess wird durch die Verwendung des BAAAM-Tools vereinfacht.
Migration der Drittanbieter-ID third-party-id
Wenn Ihre Besucher-API-Implementierung Drittanbieter-IDs (das demdex.net-Cookie) verwendet, kann die Web-SDK diese ebenfalls migrieren. Konfigurieren Sie thirdPartyCookiesEnabled für true in Ihrer Web SDK-Konfiguration. Web SDK liest das vorhandene Demdex-Cookie und fügt die Drittanbieteridentität in seine Edge Network-Anfragen ein, wobei demselben Migrationsmuster wie das AMCV-Cookie gefolgt wird.
Validierung validation
So überprüfen Sie, ob die Identitätsmigration ordnungsgemäß funktioniert:
- Öffnen Sie eine Seite, die zuvor die Besucher-API verwendet hat (jetzt unter Verwendung der Web-SDK), in einem Browser, der über ein
AMCV_-Cookie verfügt. - Stellen Sie in den Entwickler-Tools sicher, dass ein
kndctr_Identitäts-Cookie gesetzt wurde und dass die ECID mit der imAMCV_-Cookie übereinstimmt. - Vergleichen Sie nach der Bereitstellung die Zahlen der Unique Visitors vor und nach der Migration für denselben Zeitraum. Ein deutlicher Anstieg der Unique Visitors kann darauf hinweisen, dass die Migration keine Identitäten weiterträgt.
getIdentity , um die ECID zum Vergleich programmgesteuert abzurufen:| code language-js |
|---|
|
Konfigurieren idMigrationEnabled configure
Legen Sie beim Ausführen des idMigrationEnabled-Befehls den booleschen Wert configure fest. Wenn Sie diese Eigenschaft beim Konfigurieren der Web-SDK auslassen, wird sie standardmäßig auf true gesetzt. Legen Sie diese Eigenschaft fest, wenn Sie die Möglichkeit deaktivieren möchten, AMCV-Cookies zu lesen, die von der Besucher-API festgelegt werden. Die meisten Organisationen müssen diese Eigenschaft nicht festlegen.
alloy("configure", {
datastreamId: "ebebf826-a01f-4458-8cec-ef61de241c93",
orgId: "ADB3LETTERSANDNUMBERS@AdobeOrg",
idMigrationEnabled: false
});
Aktivieren der Migration von Besucher-IDs mithilfe der Tag-Erweiterung von Web SDK
Diese Einstellungen können in der Tag-Erweiterung „Web SDK" mithilfe von Identitätskonfigurationseinstellungen konfiguriert werden.