Werken met Metriek op de server understanding-server-side-metrics

Inleiding intro

In dit document worden de gegevens van de Adobe Primetime-verificatieserver beschreven die zijn gegenereerd door de ESM-service (Entitlement Service Monitoring). Het beschrijft niet de zelfde gebeurtenissen zoals gezien vanuit het cliënt-zijperspectief (wat Programmeurs zouden zien als zij een metingsdienst zoals Adobe Analytics op hun pagina/toepassing zouden uitvoeren).

Overzicht van gebeurtenissen events_summary

Vanuit het oogpunt van de Adobe Primetime-verificatieserver worden de volgende gebeurtenissen gegenereerd:

Het aantal unieke gebruikers wordt in de Unieke gebruikers hieronder. Als overzicht, aangezien de verleende authentificatie en de vergunningsreacties gewoonlijk in het voorgeheugen ondergebracht zijn, zijn de volgende formules gewoonlijk van toepassing:

Voorbeeld example

In het volgende voorbeeld worden de afmetingen aan de serverzijde voor één maand voor één merk getoond:

De-duplicatie zou in dit geval geen effect moeten hebben omdat verschillende MVPD-gebruikers niet dezelfde gebruikersnaam zouden moeten ontvangen. Wanneer u een bedrag voor twee verschillende merken maar hetzelfde MVPD doet, zou het deduplicatie-effect veel groter moeten zijn.

Gebeurtenistriggers event_triggers

Nieuwe gebruiker - Volledige stroom new-user-full-flow

In het volgende diagram worden de gebeurtenissen en stappen beschreven voor een gebruiker zonder verificatietoken (een nieuwe gebruiker of een gebruiker die een verificatietoken heeft verlopen):

De stroom omvat ronde-reizen aan MVPDs voor zowel Authentificatie (#5 tot #7) als Vergunning (#11).

Nadat de flow is voltooid, worden de verificatie- en autorisatietokens in het cachegeheugen opgeslagen op het apparaat van de gebruiker. De tijd-aan-Levende (TTL) waarden voor de tekenen van de Authentificatie zijn tussen 6 uur en 90 dagen. Een AuthN symbolische vervaldatum dwingt automatisch een AuthZ symbolische vervaldatum. De waarde van TTL voor het teken van de Toestemming is gewoonlijk 24 uren.

Het terugkeren van Gebruiker - AuthZ en AuthN Tokens in de cache

Voor gebruikers die geldige tokens AuthZ en AuthN in het cachegeheugen hebben, gebeuren de volgende stappen:

Dit wordt automatisch geactiveerd wanneer wordt aangeroepen getAuthorization()en omvat alleen controles met Adobe Primetime-verificatie. MVPD is niet betrokken bij deze stroom.

Gebruiker retourneren - AuthN-tokens in cache geplaatst, AuthZ-token verlopen

Voor gebruikers die nog geldige AuthN tokens hebben, gebeuren de volgende stappen:

Deze stroom omvat een ronde reis naar de MVPD.

Verificatiegebeurtenissen authn_events

Verificatiepoging authentication-attempt

Zoals geïllustreerd in het diagram hierboven, worden de authentificatiegebeurtenissen slechts teweeggebracht wanneer de gebruiker een ronde reis aan MVPD doet; de authentificatiegebeurtenissen omvatten geen symbolische authentificatie in de cache.

De gebeurtenis van de authentificatiepoging wordt teweeggebracht nadat de gebruiker op een bepaalde MVPD van de plukker heeft geklikt.

Verificatie in behandeling authentication-pending

Deze gebeurtenis treedt op wanneer het omleidingsproces naar Adobe Primetime-verificatie is gestart.

Verificatie verleend authentication-granted

De gebruiker is een bekende abonnee van MVPD, typisch met een abonnement van de Tv van het Betaal, maar soms met slechts de toegang van Internet. Een succesvolle authentificatie kan of voorkomen omdat de gebruiker uitdrukkelijk geldige geloofsbrieven met hun MVPD inging, of omdat zij eerder geldige geloofsbrieven hadden ingegaan en "herinner me"gecontroleerd (en de vorige zitting niet was verlopen).

De MVPD verzendt daarom een positieve reactie van de Adobe Primetime-authenticatie op het verificatieverzoek en de Adobe Primetime-verificatie zorgt voor een AuthN-token.

Comcast-verificatie comcast-authentication

Comcast heeft een andere AuthN-stroom dan de andere MVPD's.

De verschillen worden beschreven in de volgende functies:

Als de gebruiker "herinner me"op de Comcast login pagina klikt, dan zullen de verdere bezoeken aan deze pagina (in een periode van twee weken) enkel een snel terugleiden zijn. Anders zullen de gebruikers eigenlijk op de pagina voor authentiek moeten verklaren.

Verificatie is mislukt unsuccessful-authentication

Een mislukte verificatie is niet per se een gebeurtenis in Adobe Primetime-verificatie, maar kan worden berekend als het verschil tussen poging en succes.

In de release van mei 2013 voegt Adobe Primetime-verificatie foutcodes toe voor mislukte verificaties die het gevolg zijn van systeem- of netwerkfouten, waaronder DRM-fouten (symbolische binding mislukt) en LSO-fouten (geen ruimte om het token te schrijven, enz.).

Conversiesnelheid verificatie authenitication-conversion-rate

Één interessante metrisch die Programmeurs kunnen volgen is de authentificatieomzettingspercentage, dat als (de verzoeken van AuthN/toegekende AuthN)% wordt berekend.

Sommige notities over de meetgegevens:

Autorisatiegebeurtenissen authorization_events

Verificatiepoging authorization_attempt

Naast het krijgen van een authentificatietoken, moeten de gebruikers ook een toestemmingstoken krijgen alvorens inhoud te spelen. Dit gebeurt gewoonlijk na authentificatie, of als het toestemmingstoken verloopt. Aangezien deze controle op de server wordt uitgevoerd (van de Adobe Primetime-verificatieservers naar de MVPD-servers), hoeft de gebruiker niets te doen.

Toelating verleend authorization-granted

Een "vergunning verleend"signalen dat het voor authentiek verklaarde gebruikersabonnement de gevraagde programmering omvat.

Merk op dat niet alle MVPDs een afzonderlijke vergunningsstap steunt; voor sommige authentificatie wordt gelijkgesteld met vergunning. MVPD verzendt de authentificatie van Adobe Primetime een succesvolle reactie op het backchannel verzoek AuthZ, en de authentificatie van Adobe Primetime leidt tot een teken AuthZ.

Autorisatie geweigerd authorization-denied

Als een autorisatie wordt geweigerd, heeft de geverifieerde gebruiker geen bevestigd abonnement op de aangevraagde programmering. De meest waarschijnlijke oorzaak is dat het kanaal geen deel uitmaakt van het abonnementspakket van de gebruiker, maar dit kan ook een weerspiegeling zijn van een gebruiker die alleen toegang tot internet heeft via het MVPD.

Voor sommige MVPD's zijn gebruikers geverifieerd, ook al hebben ze alleen een internetabonnement van de MVPD (geen abonnement op betaaltelevisie). In dit geval, alhoewel het kanaal waarvoor de gebruiker om toestemming verzoekt in het basispakket is, zal de vergunning worden ontkend.

Sommige MVPDs biedt de berichten van de douanefout voor ontkenning AuthZ aan die aanbiedingen kunnen omvatten om hun pakket te bevorderen.

Conversiesnelheid autorisatie authorization-conversion-rate

De omrekeningskoers voor verificatie kan worden berekend als (AuthZ-verzoeken / AuthZ toegekend)%.

Aanvraag voor succesvol afspelen successful-play-request

Een gebruiker die zowel geautoriseerd als geautoriseerd is, mag beveiligde inhoud weergeven.

Bij een succesvol afspeelverzoek genereert Adobe Primetime-verificatie een kortstondig mediatoken waarin wordt bevestigd dat de gebruiker het recht heeft de gevraagde video te bekijken. De programmeur gebruikt dit Media Token voor verdere bevestiging van de potentiële kijker. Media Tokens worden bijgehouden als afspeelverzoeken.

Unieke gebruikers unique-users

Definitie definition

Bij een geslaagde verificatie wordt het bestaan van een unieke gebruiker bijgehouden op basis van de geretourneerde waarde voor de MVPD-gebruikersnaam. Deze waarde is gebaseerd op de aanmeldingsgegevens van de gebruiker, maar bevat geen identificeerbare gegevens.

Deze waarde wordt ook doorgegeven aan de site/app in de callback sendTrackingData.

Deze waarde kan blijvend over apparaten zijn (MVPD veroorzaakt de zelfde waarde voor een bepaalde gebruiker, geen kwestie waar login voorkomt) of transient (voor elke login, wordt een nieuwe waarde geproduceerd, die MVPD in zijn achtereind in kaart brengt. Doorgaans zijn de waarden die door MVPD's aan Adobe Primetime-verificatie worden geleverd, blijvend voor sessies en apparaten, maar zoals opgemerkt is de persistentie niet gegarandeerd en niet gevalideerd.

Deze waarde wordt gebruikt als een manier om de unieke gebruikers te berekenen. De gerapporteerde waarde (per aanvrager-id/interval/MVPD) wordt voor het opgegeven interval gededupliceerd. De som van de unieke gebruikers per dag is dus gewoonlijk anders dan de maandelijkse waarde, waarbij de maandelijkse waarde de lagere waarde heeft.

Dit nummer bevat alle gebeurtenissen vanaf Adobe Primetime-verificatie, minus verificatiepogingen (zonder gebruikersnaam) maar inclusief geprobeerd (en mogelijk mislukt) autorisaties.

Voorbeelden examples

Dag 1 day1

Gebruiker XYZ gaat naar de site om een video te bekijken.

Afgebroken gebeurtenissen:

Dag 1 (later ingeschakeld) day1-later-on

Gebruiker XYZ kijkt een andere video.

Afgebroken gebeurtenissen:

Dag 3 day3

Gebruiker XYZ kijkt een andere video.

Afgebroken gebeurtenissen:

Dag 31 day31

Gebruiker XYZ kijkt een andere video.

Hetzelfde als in dag 1 sinds de caching van AuthN verliep.

Als dezelfde gebruiker de autorisatie niet zou hebben doorstaan, zou het maandelijkse aantal unieke gebruikers nog steeds met 1 worden verhoogd omdat er twee gebeurtenissen zijn die de gebruikersnaam bevatten - verificatie die is verleend en autorisatiepoging.

Single Sign-On (SSO) single-sign-on-sso

In sommige gevallen kan het aantal unieke gebruikers groter zijn dan het aantal geslaagde verificaties. Dit is meestal het geval wanneer veel gebruikers via SSO van andere sites/apps binnenkomen en alleen autorisatie hoeven te krijgen op de huidige site/app.

Unieke gebruikers op client en server vergelijken comparing-client-side-and-server-side-unique-users

Als de gebruiker-id-waarde van sendTrackingData() op de client wordt gebruikt om unieke gebruikers te tellen, moeten de client-side en server-side nummers overeenkomen.

Als er grote verschillen zijn, zijn de volgende redenen doorgaans verantwoordelijk voor het verschil: