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?

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.

Relaterade artiklar