Förstå mått på serversidan understanding-server-side-metrics

Introduktion intro

I det här dokumentet beskrivs de mått på serversidan för Adobe Pass-autentisering som genereras av ESM-tjänsten (Entitlement Service Monitoring). Det beskriver inte samma händelser som de ser ur kundsidans perspektiv (vad programmerare skulle se om de skulle implementera en mättjänst som Adobe Analytics på sin sida/i sin tillämpning).

Sammanfattning av händelser events_summary

Följande händelser genereras från serversidan för Adobe Pass-autentisering:

Antalet unika användare beskrivs i detalj i avsnittet Unika användare nedan. Som en översikt gäller följande formler vanligtvis eftersom autentiserings- och auktoriseringssvar vanligtvis cachelagras:

Exempel example

I följande exempel visas serversidans mått för en månad för
ett varumärke:

Borttagning av dubbletter bör inte ha någon effekt eftersom olika MVPD-användare inte ska få samma användar-ID. När du gör en summering för två olika varumärken men samma MVPD bör effekten av borttagning av dubbletter bli mycket större.

Händelseutlösare event_triggers

Ny användare - fullständigt flöde new-user-full-flow

I följande diagram beskrivs händelser och steg för en användare utan autentiseringstoken (en ny användare eller en användare som har en autentiseringstoken har gått ut):

I flödet ingår rundresor till distributörer av videoprogrammeringstjänster för både autentisering (#5 till #7) och auktorisering (#11).

När flödet är klart cachelagras autentiserings- och auktoriseringstoken på användarens enhet. TTL-värdena (Time-to-Live) för autentiseringstoken är mellan 6 timmar och 90 dagar. Ett AuthN-tokenförfallodatum tvingar automatiskt en AuthZ-token att upphöra. TTL-värdet för auktoriseringstoken är vanligtvis 24 timmar.

Returnerande användare - AuthZ- och AuthN-token cachelagrade

Följande gäller för användare som har giltiga AuthZ- och AuthN-tokens cachelagrade
steg utförs:

Detta aktiveras automatiskt när getAuthorization() anropas och innebär endast kontroller med Adobe Pass-autentisering. MVPD är inte involverat i detta flöde.

Returnerande användare - AuthN-token cachelagrade, AuthZ-token har upphört att gälla

För användare som fortfarande har giltiga AuthN-tokens utförs följande steg:

Detta innebär en rundtur till MVPD.

Autentiseringshändelser authn_events

Autentiseringsförsök authentication-attempt

Som framgår av diagrammet ovan aktiveras autentiseringshändelserna endast när användaren gör en rundtur i MVPD. Autentiseringshändelser innehåller inte cachelagrade tokenautentiseringar.

Autentiseringsförsökshändelsen utlöses när användaren har klickat på en viss MVPD från väljaren.

Väntande autentisering authentication-pending

Den här händelsen inträffar när omdirigeringsprocessen till Adobe Pass Authentication har startats.

Autentisering beviljad authentication-granted

Användaren är en känd prenumerant på MVPD, vanligtvis med en Pay TV-prenumeration, men ibland med enbart Internet-åtkomst. En lyckad autentisering kan inträffa antingen på grund av att användaren uttryckligen har angett giltiga inloggningsuppgifter med sin MVPD, eller på grund av att han/hon tidigare har angett giltiga inloggningsuppgifter och kontrollerat "kom ihåg mig" (och den tidigare sessionen hade inte gått ut).

MVPD skickar därför Adobe Pass Authentication ett positivt svar på autentiseringsbegäran och Adobe Pass Authentication skapar en AuthN-token.

Komcast Authentication comcast-authentication

Comcast har ett annat AuthN-flöde än resten av de alternativa programmeringsdokumenten.

Följande funktioner beskriver skillnaderna:

Om användaren klickar på "kom ihåg mig" på inloggningssidan för Comcast, kommer efterföljande besök på den här sidan (under en tvåveckorsperiod) bara att vara en snabb omdirigering. Annars måste användarna autentisera på sidan.

Misslyckad autentisering unsuccessful-authentication

En misslyckad autentisering är inte en händelse i sig i Adobe Pass-autentiseringen, men kan beräknas som skillnaden mellan försök och lyckade.

I versionen från maj 2013 kommer Adobe Pass Authentication att lägga till felkoder för misslyckade autentiseringar som beror på system- eller nätverksfel, inklusive DRM-fel (tokenbindning misslyckades) och LSO-fel (inget utrymme att skriva token osv.).

Konverteringsgrad för autentisering authenitication-conversion-rate

Ett intressant mått som programmerare kan spåra är konverteringsgraden för autentisering, beräknad som (AuthN-begäranden/AuthN-beviljad) %.

Nedan följer några kommentarer om mätvärdena:

Auktoriseringshändelser authorization_events

Auktoriseringsförsök authorization_attempt

Förutom att hämta en autentiseringstoken måste användarna också få en autentiseringstoken innan de kan spela upp innehåll. Detta sker vanligtvis efter autentisering eller om auktoriseringstoken förfaller. Eftersom kontrollen görs på serversidan (från Adobe Pass-autentiseringsservrar till MVPD-servrar) behöver användaren inte göra något.

Tillstånd beviljad authorization-granted

En"auktorisering beviljad" signalerar att den autentiserade användarens prenumeration innehåller den begärda programmeringen.

Observera att inte alla programmeringsdokument har stöd för ett separat auktoriseringssteg. För viss autentisering är autentiseringen lika med auktorisering. MVPD skickar ett svar på AuthZ-begäran via Adobe Pass Authentication och Adobe Pass Authentication skapar en AuthZ-token.

Behörighet nekad authorization-denied

Om en auktorisering nekas har den autentiserade användaren ingen bekräftad prenumeration på den begärda programmeringen. Den troligaste orsaken är att kanalen inte ingår i användarens prenumerationspaket, men detta kan även återspegla en användare som bara har internetåtkomst från MVPD.

För vissa distributörer av videoprogrammeringstjänster kan användare autentiseras trots att de bara har en Internetprenumeration från MVPD (ingen betal-TV-prenumeration). Även om den kanal som användaren begär auktorisering för finns i baspaketet, kommer auktoriseringen i det här fallet att nekas.

Vissa MVPD-program erbjuder anpassade felmeddelanden för AuthZ-nekanden som kan innehålla erbjudanden om att uppgradera sitt paket.

Konverteringsgrad för auktorisering authorization-conversion-rate

Konverteringsgraden för autentisering kan beräknas som (AuthZ-begäranden/AuthZ-beviljad) %.

Begäran om uppspelning har slutförts successful-play-request

En användare som är både autentiserad och behörig får visa skyddat innehåll.

När uppspelningen är klar genererar Adobe Pass Authentication en kortlivad medietoken som försäkrar att användaren har rätt att visa den begärda videon. Programmeraren använder denna medietoken för ytterligare validering av den potentiella användaren. Medietoken spåras som lyckade uppspelningsbegäranden.

Unika användare unique-users

Definition definition

Vid en lyckad autentisering spårar Adobe Pass Authentication om det finns en unik användare, baserat på det returnerade användar-ID-värdet för MVPD. Värdet baseras på användarens inloggningsinformation, men det innehåller ingen identifierbar information.

Det här värdet skickas också till webbplatsen/appen i sendTrackingData-återanropet.

Detta värde kan vara beständigt på olika enheter (MVPD skapar samma värde för en viss användare, oavsett var inloggningen sker) eller tillfälligt (för varje inloggning genereras ett nytt värde som MVPD mappar i bakgrunden. Vanligtvis är de värden som tillhandahålls av MVPD till Adobe Pass Authentication beständiga mellan sessioner och enheter, men, som det noteras, är beständigheten varken garanterad eller validerad.

Det här värdet används som ett sätt att beräkna de unika användarna. Det rapporterade värdet (per begärande-ID/intervall/MVPD) dedupliceras för det aktuella intervallet. Summan av unika användare per dag skiljer sig alltså vanligtvis från månadsvärdet, där månadsvärdet har det lägre värdet.

Detta antal omfattar alla händelser från Adobe Pass-autentisering, minus autentiseringsförsök (som inte har något användar-ID) men inklusive försök till (och eventuellt misslyckade) auktoriseringar.

Exempel examples

Dag 1 day1

Användare XYZ går till webbplatsen för att titta på en video.

Utlösta händelser:

Dag 1 (senare på) day1-later-on

Användare XYZ tittar på en annan video.

Utlösta händelser:

Dag 3 day3

Användare XYZ tittar på en annan video.

Utlösta händelser:

Dag 31 day31

Användare XYZ tittar på en annan video.

Samma som i dag 1 sedan AuthN-cachelagringen upphörde.

Om samma användare skulle misslyckas med auktoriseringen kommer antalet unika användare per månad fortfarande att ökas med 1 eftersom det finns två händelser som innehåller användar-ID:t - autentiseringen har beviljats och auktoriseringsförsöket.

enkel inloggning (SSO) single-sign-on-sso

I vissa fall kan antalet unika användare vara större än antalet lyckade autentiseringar. Detta är vanligtvis fallet när många användare kommer in via enkel inloggning från andra webbplatser/appar och bara behöver få behörighet för den aktuella webbplatsen/appen.

Jämföra unika användare på klient- och serversidan comparing-client-side-and-server-side-unique-users

Om användar-ID-värdet från sendTrackingData() används på klientsidan för att räkna unika användare, måste klientsidans och serversidans nummer matcha.

Om skillnaderna är större är det vanligen följande skäl
differens: