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

Inleiding intro

In dit document worden de afmetingen aan de serverzijde van de Adobe Pass-verificatie beschreven die door de service Entitlement Service Monitoring (ESM) worden gegenereerd. 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 Pass-verificatieserver worden de volgende gebeurtenissen gegenereerd:

Het aantal unieke gebruikers wordt behandeld in detail in de ​ Unieke sectie van 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 gedurende een maand getoond voor
één merk:

In dit geval mag deduplicatie geen effect hebben omdat verschillende MVPD-gebruikers niet dezelfde gebruikersnaam mogen ontvangen. Wanneer u een bedrag voor twee verschillende merken maar dezelfde 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 AuthZ en AuthN tokens caching hebben, het volgende
er treden stappen op:

Dit wordt automatisch geactiveerd wanneer getAuthorization() wordt aangeroepen en omvat alleen controles met Adobe Pass-verificatie. De 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 retourtocht 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 verificatiepooggebeurtenis wordt geactiveerd nadat de gebruiker op een bepaalde MVPD van de kiezer heeft geklikt.

Verificatie in behandeling authentication-pending

Deze gebeurtenis treedt op wanneer het omleidingsproces naar Adobe Pass Authentication is gestart.

Verificatie verleend authentication-granted

De gebruiker is een bekende abonnee van de MVPD, meestal met een abonnement op Pay TV, maar soms met alleen internettoegang. Een geslaagde verificatie kan optreden omdat de gebruiker expliciet geldige gegevens heeft ingevoerd bij zijn MVPD of omdat de gebruiker eerder geldige gegevens had ingevoerd en "onthoud mij" was ingeschakeld (en de vorige sessie was niet verlopen).

MVPD verzendt daarom de Authentificatie van Adobe Pass een positieve reactie op het authentificatieverzoek en de Authentificatie van Adobe Pass leidt tot een token AuthN.

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 Pass-verificatie, maar kan worden berekend als het verschil tussen poging en succes.

In de release van mei 2013 voegt Adobe Pass Authentication foutcodes toe voor mislukte verificaties die het gevolg zijn van systeem- of netwerkfouten, waaronder DRM-fouten (tokenbinding 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 Pass-verificatieservers tot 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. De MVPD verstuurt Adobe Pass Authentication als een succesvol antwoord op de backchannel AuthZ request en Adobe Pass Authentication maakt een AuthZ token.

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 heeft tot internet vanuit de 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 Pass Authentication 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 zijn op verschillende apparaten (de MVPD produceert dezelfde waarde voor een bepaalde gebruiker, ongeacht waar de aanmelding plaatsvindt) of tijdelijk (voor elke aanmelding wordt een nieuwe waarde gegenereerd, die de MVPD in de back-end toewijst. Doorgaans zijn de waarden die door MVPD's aan Adobe Pass-verificatie worden geleverd, blijvend in 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 Pass-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 waarde voor de gebruikers-id 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 de
verschil: