サーバーサイド指標について understanding-server-side-metrics

概要 intro

このドキュメントでは、Entitlement Service Monitoring （ESM）サービスによって生成されるAdobe Pass認証サーバーサイドの指標について説明します。 クライアントサイドの観点から見た場合と同じイベント（ページやアプリケーションにAdobe Analyticsなどの測定サービスを実装する場合にプログラマーに表示されるイベント）ではありません。

イベントの概要 events_summary

Adobe Pass認証サーバー側の観点から、次のイベントが生成されます。

ユニークユーザーの数について詳しくは、以下の ​ ユニークユーザー ​ の節を参照してください。 概して、付与された認証応答と承認応答は通常キャッシュされるので、次の式が通常適用されます。

例 example

次の例は、1 か月間のサーバーサイド指標を示しています
1 つのブランド：

異なるMVPD ユーザーが同じユーザー ID を受け取らないようにする必要があるので、この場合は重複排除を実行しても効果はありません。 2 つの異なるブランドで同じMVPDの合計を計算する場合は、重複除外効果がはるかに大きくなる必要があります。

イベントのトリガー event_triggers

新規ユーザー – フルフロー new-user-full-flow

次のグラフは、認証トークンがないユーザー（新しいユーザーまたは認証トークンの有効期限が切れているユーザー）のイベントと手順を示しています。

このフローでは、認証（#7 への#5）と認証（#11）の両方で MVPD へのラウンドトリップが必要です。

フローが完了すると、認証トークンと認証トークンがユーザーのデバイスにキャッシュされます。 認証トークンの有効期間（TTL）の値は、6 時間～90 日です。 AuthN トークンの有効期限が切れると、AuthZ トークンの有効期限が自動的に強制されます。 認証トークンの TTL 値は通常 24 時間です。

再来訪ユーザー – キャッシュされた AuthZ および AuthN トークン

有効な AuthZ および AuthN トークンをキャッシュしているユーザーの場合は、以下を行います
実行される手順：

これは getAuthorization() の呼び出し時に自動的にトリガーされ、Adobe Pass Authentication でのチェックのみが必要です。 MVPDはこのフローに関与していません。

再来訪ユーザー – AuthN トークンがキャッシュされ、AuthZ トークンが期限切れです

有効な AuthN トークンをまだ持っているユーザーの場合、次の手順が行われます。

この流れはMVPDへの往復を含む。

認証イベント authn_events

認証の試行 authentication-attempt

上の図に示すように、認証イベントは、ユーザーがMVPDにラウンドトリップを行った場合にのみトリガーされます。認証イベントには、キャッシュされたトークン認証は含まれません。

認証試行イベントは、ユーザーがピッカーから特定のMVPDをクリックした後にトリガーされます。

認証を保留中 authentication-pending

このイベントは、Adobe Pass認証へのリダイレクトプロセスが開始されたときに発生します。

Authentication Granted authentication-granted

ユーザーはMVPDの既知の購読者であり、通常は有料のテレビ購読を使用しますが、インターネットアクセスのみの場合もあります。 認証が成功する理由は、ユーザーがMVPDで有効な認証情報を明示的に入力したか、以前に有効な認証情報を入力し、「自分を記憶する」がオンになっていたためです（以前のセッションが期限切れになっていませんでした）。

そのため、MVPDは、Adobe Pass Authentication に対して、認証リクエストに対する肯定的な応答を送信し、Adobe Pass Authentication は AuthN トークン を作成します。

マルチキャスト認証 comcast-authentication

Comcast には、他の MVPD とは異なる AuthN フローがあります。

次の機能で違いを説明します。

ユーザーが Comcast ログインページ上の「自分を記憶する」をクリックすると、その後の（2 週間の）このページへの訪問は、単なるクイックリダイレクトになります。 そうでない場合、ユーザーは実際にはそのページで認証を行う必要があります。

認証に失敗しました unsuccessful-authentication

認証の失敗は、Adobe Pass認証のイベントそのものではありませんが、試行と成功の違いとして計算できます。

2013 年 5 月のリリースでは、DRM エラー（トークンバインディングに失敗しました）、LSO エラー（トークンを書き込むスペースがありません）など、システムエラーまたはネットワークエラーが原因の認証失敗のエラーコードがAdobe Pass認証によって追加されます。

認証コンバージョン率 authenitication-conversion-rate

プログラマーが追跡できる興味深い指標の 1 つは、（AuthN リクエスト/AuthN 許可された）パーセントとして計算される認証コンバージョン率です。

指標に関する注意事項：

認証イベント authorization_events

認証の試行 authorization_attempt

認証トークンの取得に加えて、ユーザーはコンテンツを再生する前に認証トークンも取得する必要があります。 これは通常、認証後、または認証トークンの有効期限が切れた場合に発生します。 このチェックは（Adobe Pass認証サーバーからMVPD サーバーに対して）サーバーサイドで行われるので、ユーザーは何もする必要はありません。

付与された認証 authorization-granted

「認可された」信号は、認証されたユーザの購読が要求されたプログラミングを含むことを示す。

なお、すべての MVPD が個別の認証手順をサポートしているわけではありません。一部の認証は認証と同じです。 MVPDは、Adobe Pass Authentication にバックチャネル AuthZ リクエストへの成功したレスポンスを送信し、Adobe Pass Authentication は AuthZ トークンを作成します。

認証が拒否されました authorization-denied

認証が拒否された場合、認証済みユーザーには、要求されたプログラミングに対する確認されたサブスクリプションがありません。 最も可能性の高い原因は、チャネルがユーザーのサブスクリプションパッケージに含まれていないことですが、MVPDからのインターネットアクセスしか持たないユーザーが含まれる可能性もあります。

一部の MVPD では、MVPDからのインターネット購読（有料 TV 購読なし）しかなくても、ユーザーは正常に認証されます。 この場合、ユーザーが認証をリクエストするチャネルがベースパッケージ内にある場合でも、認証は拒否されます。

一部の MVPD は、AuthZ 拒否に対してカスタムエラーメッセージを提供し、パッケージのアップグレードのオファーを含めることができます。

認証コンバージョン率 authorization-conversion-rate

認証コンバージョン率は、（AuthZ リクエスト/AuthZ 付与） % として計算できます。

成功した再生リクエスト successful-play-request

認証済みおよび承認済みのユーザーは、保護されたコンテンツを表示できます。

再生リクエストが成功すると、Adobe Pass認証は、リクエストされたビデオを表示する権限がユーザーに付与されていることをアサートする、短期間有効なメディアトークンを生成します。 プログラマーは、このメディアトークンを使用して、将来のビューアをさらに検証します。 メディアトークンは、成功した再生リクエストとして追跡されます。

Unique Users unique-users

定義 definition

認証に成功すると、Adobe Pass Authentication は、返されたMVPD ユーザー ID 値に基づいて、一意のユーザーの有無を追跡します。 この値はユーザーのログイン情報に基づいていますが、個人を特定できる情報は含まれていません。

この値も sendTrackingData コールバックのサイト/アプリに渡されます。

この値は、デバイスをまたいで永続的にできます（MVPDは、ログインが発生した場所に関係なく、特定のユーザーに対して同じ値を生成します）。または一時的な値（ログインごとに、MVPDがバックエンドでマッピングする新しい値が生成されます）です。 通常、MVPD からAdobe Pass認証に提供される値は、セッションやデバイスをまたいで永続的ですが、前述のように、永続性は保証も検証もされません。

この値は、一意のユーザーを計算する方法として使用されます。 レポートされた値（リクエスター ID/インターバル/MVPDごとに）は、特定のインターバルについて重複排除されます。 したがって、通常、1 日あたりの一意のユーザーの合計は月額の値とは異なり、月額の値はより低い値になります。

この数には、Adobe Pass認証からのすべてのイベントから、ユーザー ID を持たない認証試行を差し引き、試行された（および失敗した）認証を含みます。

例 examples

1 日目 day1

ユーザー XYZ はビデオを視聴するためにサイトに移動します。

発生したイベント：

1 日目（後日） day1-later-on

ユーザー XYZ が別のビデオを視聴します。

発生したイベント：

3 日目 day3

ユーザー XYZ が別のビデオを視聴します。

発生したイベント：

31 日目 day31

ユーザー XYZ が別のビデオを視聴します。

AuthN キャッシュの有効期限が切れてから 1 日目と同じです。

同じユーザーが認証に失敗した場合でも、ユーザー ID を含むイベント（許可された認証と認証試行）が 2 つあるので、月間ユニークユーザー数は 1 増加します。

シングルサインオン（SSO） single-sign-on-sso

一意のユーザーの数が、成功した認証の数よりも多くなる場合があります。 これは通常、多くのユーザーが他のサイトやアプリから SSO を介して入ってきて、現在のサイトやアプリで認証を受ける必要があるだけの場合です。

クライアントサイドとサーバーサイドの一意のユーザーの比較 comparing-client-side-and-server-side-unique-users

sendTrackingData() のユーザー ID 値をクライアントサイドで使用して一意のユーザーをカウントする場合は、クライアントサイドとサーバーサイドの番号が一致する必要があります。

大きな違いが生じる場合、次の理由が考えられます
相違点：