Understanding Server-side Metrics
- Topics:
- Authentication
NOTEIntroduction
This document describes the Adobe Pass Authentication server-side metrics generated by the Entitlement Service Monitoring (ESM) service. It does not describe the same events as seen from the client-side perspective (what Programmers would see if they were to implement a measurement service such as Adobe Analytics on their page / application).
Events Summary
From the Adobe Pass Authentication server-side point of view the following events are generated:
-
Events Generated in the Authentication Flow(An actual login with the MVPD)
- Notification of AuthN Attempt - This is generated when the user is sent to the MVPD login site.
- Notification of AuthN Pending - If the user succeeds in logging in with their MVPD, this is generated when the user is redirected back to Adobe Pass Authentication.
- Notification of AuthN Granted - This is generated when the user is back on the Programmer’s site, and has successfully retrieved the Authentication token from Adobe Pass Authentication.
-
Authorization Flow (Just a check for authorization with an
MVPD)
Prerequisite: A valid AuthN token- Notification of AuthZ Attempt
- Notification ofAuthZ Granted
-
Successful Play Request
Prerequisite: Valid AuthN and AuthZ tokens- Notification of a check with Adobe Pass Authentication
- A play request requires both a granted authentication and a granted authorization
The number of unique users is covered in detail in the Unique Users section below. As an overview, since granted authentication and authorization responses are usually cached, the following formulas usually apply:
- Number of AuthN attempts > Number of AuthN granted
- Number of AuthZ attempts > Number of AuthZ granted
- Number of AuthZ attempts > Number of AuthN granted (usually)
- Number of Successful Play requests > Number of AuthZ granted
Example
The following example shows the server-side metrics for one month for
one brand:
De-duplication in this case should have no effect as different MVPD users should not receive the same User ID. When doing a sum for two different brands but the same MVPD the de-duplication effect should be much bigger.
Event Triggers
New User – Full Flow
The following chart describes the events and steps for a user with no authentication token (a new user or a user who’s authentication token has expired):
The flow involves round-trips to MVPDs for both Authentication (#5 to #7) and Authorization (#11).
After the flow is completed, the Authentication and Authorization tokens are cached on the user’s device. The Time-to-Live (TTL) values for Authentication tokens are between 6 hours and 90 days. An AuthN token expiration automatically forces an AuthZ token expiration. The TTL value for the Authorization token is usually 24 hours.
- Authentication attempt, Authentication pending, Authentication granted
- Authorization attempt, Authorization granted
- Successful Play request
Returning User – AuthZ and AuthN Tokens Cached
For users who have valid AuthZ and AuthN tokens cached, the following
steps happen:
This is triggered automatically when calling getAuthorization(), and involves only checks with Adobe Pass Authentication. The MVPD is not involved in this flow.
Returning User – AuthN Tokens Cached, AuthZ Token Expired
For users who still have valid AuthN tokens, the following steps happen:
This flow involves a round trip to the MVPD.
- Authorization attempt, Authorization OK
- Successful Play request
Authentication Events
Authentication Attempt
As illustrated in the diagram above, the authentication events are only triggered when the user does a round trip to the MVPD; authentication events do not include cached token authentications.
The authentication attempt event is triggered after the user has clicked on a particular MVPD from the picker.
- The first event on the MVPD side that is close to this is the page load
- Adobe Pass Authentication does not count repeated attempts by the user to log in on the MVPD page (incorrect password, try again)
- multiple attempts are counted as one attempt
- Some MVPDs also perform Authorization in the Authentication step, and the user is not redirected back if authorization fails.
Authentication Pending
This event occurs when the redirect process to Adobe Pass Authentication has started.
Authentication Granted
The user is a known subscriber of the MVPD, typically with a Pay TV subscription, but sometimes with only Internet access. A successful authentication may occur either because the user explicitly entered valid credentials with their MVPD, or because they had previously entered valid credentials and had “remember me” checked (and the prior session had not expired).
The MVPD therefore sends Adobe Pass Authentication a positive response to the authentication request and Adobe Pass Authentication creates an AuthN token.
- Authentication is usually cached for a long period of time (a month or more). Due to this, authentication events will not be present anymore until the token expires and the flow is started again.
- Coming in from another site / app via Single Sign On will not trigger authentication events.
Comcast Authentication
Comcast has a different AuthN flow compared to the rest of the MVPDs.
The following features describe the differences:
-
Session cookie behavior: This causes a complete removal of any authentication tokens after the user has closed the browser. This feature is present on the web only. The main purpose is to ensure that your Comcast session is not persisted on unsafe / shared computers. The impact is that there will be more authentication attempts / granted flows than for the rest of the MVPDs.
-
AuthN per requestorID: Comcast does not allow AuthN state to be cached from one requestor ID to another. Due to this, each site /app has to go to Comcast to get an authentication token. Besidesuser experience considerations, the impact, as above, is that more authentication attempts / granted events will be generated.
-
Passive Authentication: In order to improve user experience but
still maintain the AuthN per requestorID functionality, a passive authentication flow happens in a hidden iFrame. The user will not see anything but the events will still be triggered as before.
If the user clicks “remember me” on the Comcast login page, then subsequent visits to this page (in a 2 week period) will be just a quick redirect back. Otherwise users will actually have to authenticate on the page.
Unsuccessful Authentication
An unsuccessful authentication is not an event per-se in Adobe Pass Authentication – but can be computed as the difference between attempts and successes.
In the May 2013 release, Adobe Pass Authentication will add error codes for unsuccessful Authentications that are due to system or network errors, including DRM errors (token binding failed) and LSO errors (no space to write the token etc).
Authentication Conversion Rate
One interesting metric that Programmers can track is the authentication conversion rate, computed as (AuthN requests / AuthN granted)%.
Some notes about the metrics:
- Since it’s an event-based metric, it doesn’t really reflect unique user conversion rate – if a user attempts eight times and succeeds the ninth time – this will reflect very badly in the conversion rate above.
- There is no way (yet) in Adobe Pass Authentication (on the server-side) to compute a unique based authentication conversion.
- If automatic AuthN retries are present in the site/app, this will also skew the metric above.
Authorization Events
Authorization Attempt
In addition to getting an authentication token, users must also get an authorization token before playing content. This usually happens after authentication, or if the authorization token expires. Since this check is done server-side (from the Adobe Pass Authentication servers to the MVPD servers) the user is not required to do anything.
Authorization Granted
An “authorization granted” signals that the authenticated user’s subscription includes the requested programming.
Note that not all MVPDs support a separate authorization step; for some authentication is equated with authorization. The MVPD sends Adobe Pass Authentication a successful response to the backchannel AuthZ request, and Adobe Pass Authentication creates an AuthZ token.
- The AuthZ token is cached for a period of time, typically 24 hours During this period no AuthZ events will be fired.
- Some MVPDs work with Asset Level Authorizations, others work with Channel Level Authorizations; – depending on which one is used, more or fewer AuthZ events are fired. Even for channel level authorization, caching is in place – so if the same asset is requested in less than 24 hours, no events will be fired.
Authorization Denied
If an authorization is denied, the authenticated user does not have a confirmed subscription to the requested programming. The most likely cause is that the channel is not part of the user’s subscription package, but this can also reflect a user having only internet access from the MVPD.
For some MVPDs, users are successfully authenticated even though they only have an internet subscription from the MVPD (no pay TV subscription). In this case, even though the channel for which the user requests authorization is in the base package, the authorization will be denied.
Some MVPDs offer custom error messages for AuthZ denials that can include offers to upgrade their package.
Authorization Conversion Rate
The Authentication conversion rate can be computed as (AuthZ requests / AuthZ granted)%.
Successful Play Request
A user who is both authenticated and authorized is permitted to view protected content.
Upon a successful play request, Adobe Pass Authentication generates a short-lived Media Token asserting that the user is entitled to view the requested video. The Programmer uses this Media Token for further validation of the prospective viewer. Media Tokens are tracked as successful play requests.
- Adobe Pass Authentication does not track whether the video playback actually began after generating the Media Token. For example, if there is a geo-restriction on the content, the transaction still counts as a successful play request, even though the stream never actually starts.
- Since AuthN and AuthZ tokens cache the MVPD response for a period of time, the successful play request event is the most frequent event in the metrics.
Unique Users
Definition
Upon a successful authentication, Adobe Pass Authentication tracks the existence of a unique user, based on the returned MVPD User ID value. This value is based on the user’s login info, but it contains no personably identifiable information.
This value is also passed to the site/app in the sendTrackingData callback.
This value can be persistent across devices (the MVPD produces the same value for a given user, no matter where the login occurs) or transient (for each login, a new value is generated, which the MVPD maps in its back-end. Typically the values provided by MVPDs to Adobe Pass Authentication are persistent across sessions and devices but, as noted, the persistence is neither guaranteed nor validated.
This value is used as a way to compute the unique users. The value reported (per requestor ID/interval/MVPD) is deduplicated for the particular interval. So the sum of the unique users per day is usually different than the monthly value, with the monthly value having the lower value.
This number includes all events from Adobe Pass Authentication, minus Authentication attempts (which have no user ID) but including attempted (and possibly failed) authorizations.
Examples
Day 1
User XYZ goes to the site to watch a video.
Events fired:
-
AuthN attempt (no unique user yet)
-
AuthN granted
- at this point we uniquely identify the user based on what the MVPD returns - so the daily unique user count is increased by 1
- the AuthN token is cached for 30 days
-
AuthZ attempt / granted event
- AuthZ token cached for 1 day
-
Successful play request event
Day 1 (Later On)
User XYZ watches another video.
Events fired:
- Successful play request event (the rest are cached)
- No increase in daily or monthly uniques
Day 3
User XYZ watches another video.
Events fired:
- AuthZ attempt / granted event
- Since 1 day caching from day 1 expired
- Successful play request event (the rest are cached)
- Daily unique users increased by 1 - monthly uniques are still 1
Day 31
User XYZ watches another video.
Same as in day 1 since AuthN caching expired.
If the same user were to fail authorization the monthly unique users count would still be increased by 1 because there are two events that contain the user ID – authentication granted and authorization attempt.
Single-Sign-On (SSO)
In some cases, the number of unique users can be larger than the number of successful authentications. This is usually the case when a lot of users are coming in via SSO from other sites/apps, and only need to get authorization on the current site/app.
Comparing Client-Side and Server-Side Unique Users
If the user ID value from sendTrackingData() is used on the client-side to count unique users then the client-side and server-side numbers should match.
If differences are major, the following reasons usually account for the
difference:
-
Video play uniques versus all events uniques. As mentioned, Adobe Pass Authentication counts unique users for all events except AuthN attempts. This means that if the user only authenticates (on the page) but doesn’t view a video, a unique user count increase is still triggered.
-
Counting users who failed authorization – Adobe Pass Authentication counts these users as well in the reported number.