- Hjälp för identitetstjänst
- Översikt
- Implementering
- Implementeringsmetoder
- Implementeringsguider
- Implementera med Experience Platform-taggar
- Implementering för Analytics
- Implementera för mål
- Implementering för Analytics och Audience Manager
- Implementering för Analytics, Audience Manager och Target
- Använda ID-tjänsten med A4T och en implementering på serversidan av Target
- Direktintegrering med ID-tjänsten
- Användningsexempel för direktintegrering
- Testa och verifiera ID-tjänsten
- Anmälningstjänst
- Översikt över anmälningstjänsten
- Konfigurera anmälningstjänst
- Validerar anmälningstjänst
- Konfigurera deltagande med Experience Platform Launch
- Konfigurera deltagande med DTM
- Åtgärder för kontroll av Experience Cloud baserat på användares samtycke
- Användningsexempel
- Anmälningsreferens
- Använda Opt-in-tjänster med IAB Framework
- ID-tjänst-API
- API-översikt för ID-tjänst
- Konfiguration
- Översikt över konfigurationer
- auditionManagerServer och auditionManagerServerSecure
- cookieDomain
- cookieLifetime
- disableIdSyncs
- disableThirdPartyCalls
- disableThirdPartyCookies
- idSyncAttachIframeOnWindowLoad
- idSyncContainerID
- idSyncSSLUseAkamai
- loadTimeout
- overwriteCrossDomainMCIDAndAID
- resetBeforeVersion
- sdidParamExpiry
- Säkra konfigurationer och samma webbplats
- secureCookie
- useCORSOnly
- whitelistParentDomain och whitelistIframeDomains
- Metoder
- Metoder
- appendSupplementalDataIDTo
- appendVisitorIDsTo (spårning mellan domäner)
- callTimeOut-metoder
- ID-synkronisering efter URL eller datakälla
- getInstance
- getAnalyticsVisitorID
- getCustomerIDs
- setCustomerIDs
- getMarketingCloudVisitorID
- getLocationHint
- getVisitorValues
- isClientSideMarketingCloudVisitorID
- resetState
- Referens
- Referensöversikt
- Analysreferens
- Analysreferensöversikt
- CNAME-implementering - översikt
- Ställa ID:n för Analytics och Experience Cloud
- Åtgärdsordning för analys-ID:n
- Beslutspunkter för migrering av ID-tjänst
- Migreringsscenarier för ID-tjänst
- Analys- och identitetsförfrågningar
- Implementering på serversidan blandad med JavaScript
- Giltighetsperioden för ID-tjänsten
- Google Chrome SameSite-etikettändringar
- Skyddsprofiler för innehåll och ID-tjänsten
- Stöd för COPPA i ID-tjänsten
- CORS-stöd i ID-tjänsten
- Kund-ID:n och autentiseringstillstånd
- ECID-biblioteksmetoder i en Safari ITP-värld
- Identifiera unika besökare
- Hämta region- och användar-ID från AMCV Cookie eller ID-tjänsten
- Krav för ID-tjänsten
- Videopulsslag och ID-tjänst
- Data Workbench och ID-tjänst
- SHA256 Hash-stöd för setCustomerIDs
- Vanliga frågor och svar
- Versionsinformation för ID-tjänst
Vanliga frågor om ID-tjänster
Vanliga frågor och svar om funktioner, funktioner och problem i samband med användning av ID-tjänsten.
Funktionalitet
Vilken typ av funktioner tillhandahåller ID-tjänsten?
Se Översikt.
Varför gör ID-tjänsten inget anrop för att hämta Experience Cloud-ID?
Detta kan vara svårt att diagnostisera. En sak som du kan kontrollera är rubrikerna för skyddsprofiler på din webbplats. Om du har en strikt säkerhetsprincip kan dessa inställningar blockera tredjepartssamtal som görs av ID-tjänsten. Se Skyddsprofiler för innehåll och Experience Cloud Identity Service.
Lagring av VisitorAPI.js-filer
Du kan få problem om du har VisitorAPI.js som värd för en lokal fil i mobilappar. Vi rekommenderar att du har filen på en webbserver.
Inläsningstider för sidor och fördröjning
Hur påverkar placeringen av ID-tjänstens VisitorAPI.js-bibliotek sidinläsningstiderna?
Placera VisitorAPI.js-biblioteket överst på sidan i <head> i koden. Detta bidrar till att säkerställa att anropet för ett ID skickas innan sidans brödtext börjar läsas in och maximerar chanserna för att ett ID returneras korrekt.
ID-tjänstanropet är asynkront och är det enda anropet till demdex.net-domän. Anropet till ID-tjänsten blockerar inte andra element från att läsas in på sidan.
För Target kunder, placera ID-tjänstkoden i <body> på sidan kan öka chanserna att den kan blockera en Target ring. Om du måste placera ID-tjänstkoden i sidans brödtext bör den placeras efter den öppna <body> -tagg.
Gör ID-tjänsten ett serversamtal med varje sidinläsning?
Nej, det här samtalet sker endast första gången sidan återges och därefter var sjunde dag. Under tiden krävs inga serversamtal. ID-tjänsten körs i klientläge och behöver inte göra något serveranrop för att returnera ett ID.
Se Översikt.
När du använder ID-tjänsten, vad kan orsaka långsam sidinläsning eller påverka användarupplevelsen?
Det är svårt att katalogisera alla möjliga villkor. Miljoner kunder ansluter till våra tjänster och den enorma variationen i var och hur de kopplar samman påverkar prestandan. Exempel:
- Hastigheten varierar kraftigt i mobilnätverk. Dessa nätverk lider också av signal- och data- eller röstpaketsförlust.
- Anslutningen påverkas av enheter som ansluter via WiFi under olika förhållanden. Exempel: paketförluster och hastighetsproblem är vanliga på offentliga platser som kaféer eller i andra miljöer som flygplan där paketen måste studsa genom en satellit innan de når markbundna nätverk.
- Dåligt konfigurerade lokala nätverk kan påverka anslutningsmöjligheterna och hastigheten negativt.
- Klientenheter kan ha egna problem, t.ex. för lite minne, för mycket diskbyte eller begränsad processorkraft jämfört med den aktuella arbetsbelastningen.
- Webbläsarna köar och kör fjärrserveranrop och bearbetar till och med svaren med olika regler, beroende på webbläsartillverkare och version. Det här beteendet påverkar hastighet och prestanda.
Kan du ange några förbättringar som du har gjort för att korta sidinläsningstiderna?
Till exempel, trådgenerering. Vi introducerade trådgenerering vid flera begäranden om synkronisering av ID. Vi har observerat från labbrapporter att användargränssnittet skulle blockeras för kunder som utför flera ID-synkroniseringar på grund av att en mängd kontinuerliga CPU-beräkningar sker. Därför introducerade vi trådar som separerar begäranden om ID-synkronisering med 100 msek vardera.
Den här förändringen förbättrar prestanda för kunder som använder Visitor 2.3.0+ och DIL 6.10+. Förbättringarna av sidinläsningstiderna visas i bilden nedan:
Påverkar webbläsarbegäranden med CORS jämfört med JSON-P sidprestanda?
Resursbegäranden med CORS är vanligtvis mer att föredra än med JSONP. Med JSONP kan vissa webbläsare köa och avprioritera begäranden i förhållande till andra synkrona och asynkrona anrop på sidan. CORS ser till att dessa begäranden behandlas med högre prioritet i webbläsarens anropsstack.
Se CORS-stöd i Experience Cloud Identity Service.
Säkerhet
Stöder ID-tjänsten CORS?
Ja. Se CORS-stöd i Experience Cloud Identity Service.
Vad är CORS?
Cross-Origin Resource Sharing eller CORS är en metod som används i webbläsare för att begära resurser. ID-tjänsten begär alltid resurser med CORS i webbläsare som stöder det. ID-tjänsten begär resurser med JSON-P i äldre webbläsare som inte stöder CORS. Se Experience Cloud.
Vad händer om mina säkerhetskrav är så strikta att jag aldrig vill använda JSONP?
Om du har strikta säkerhetskrav anger du API-konfigurationen för ID-tjänsten useCORSOnly: true. Du bör bara aktivera det här läget om du är säker på att webbplatsens besökare använder webbläsare som stöder CORS.
Se Experience Cloud och useCORSOnly.
Resurser
Adobe-konto
