翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
以下は、MediaTailor コンソールを使用してプリフェッチスケジュールを作成する方法を説明する手順です。MediaTailor API を使用してプログラムでプリフェッチスケジュールを作成および管理する方法の詳細については、 API AWS Elemental MediaTailor リファレンスのPrefetchSchedules」を参照してください。
注記
スケジュールで avail 一致条件を使用する場合は、まず再生設定の ADS URL テンプレートを動的セッション変数で設定してください。そうしないと、avail 一致条件は効果がありません。動的変数の使用については、MediaTailor の使用開始の広告挿入トピックにある「ステップ 3: ADS リクエスト URL とクエリパラメータを設定する」を参照してください。
コンソールを使用して新しいプリフェッチスケジュールを作成する
-
MediaTailor コンソール (https://console.aws.amazon.com/mediatailor/
) を開きます。 -
ナビゲーションペインで [Configurations] (設定) をクリックします。プリフェッチスケジュールを作成する再生設定を選択します。
-
[Prefetch schedules] (プリフェッチのスケジュール) タブで、[Add prefetch schedule] (プリフェッチスケジュールを追加) をクリックします。
-
[Prefetch schedule details] (プリフェッチスケジュールの詳細) ペインで、以下を実行します。
-
[Name] (名前) には、プリフェッチスケジュールの識別子 (my-prefetch-schedule など) を入力します。
[Stream ID] (ストリーム ID) には、オプションで一意の ID を入力します。オリジンに複数の再生ストリームが含まれている場合は、この ID を使用して、特定のストリームに広告を配置するよう MediaTailor に指示することができます。例えば、オリジンにスポーツストリームとテレビ番組ストリームがある場合は、ストリーム ID を使用して、スポーツストリームを対象とした広告を挿入するためのプリフェッチスケジュールを作成できます。ストリーム ID 値は、クライアントのセッション開始またはマニフェストリクエストで MediaTailor に渡します。詳細については、以下の例を参照してください。
-
サーバー側の追跡の場合は、MediaTailor エンドポイントに対するクライアントの
GET HTTP
リクエストに?aws.streamId
クエリパラメータと値を含めます。サーバー側の追跡に関する一般情報については、「サーバー側の広告追跡」を参照してください。ストリーム ID が含まれた HLS エンドポイントに対するマニフェストリクエストは以下のようになります。
はストリーム ID の名前です。myStreamId
GET <mediatailorURL>/v1/master/
<hashed-account-id>
/<origin-id>
/<asset-id>
?aws.streamId=myStreamId
-
クライアント側の追跡の場合は、MediaTailor /v1/Session エンドポイントに対するクライアントの
POST HTTP
セッション開始リクエストボディにstreamId
キーと値を含めます。クライアント側の追跡に関する一般情報については、「クライアント側の広告追跡」を参照してください。ストリーム ID が含まれたセッション開始リクエストは以下のようになります。
はストリーム ID の名前です。myStreamId
POST <mediatailorURL>/v1/session/
<hashed-account-id>
/<origin-id>
/<asset-id>
{ 'streamId': 'myStreamId
' }
-
-
-
[Retrieval] (取得) ペインで、使用する取得設定を指定します。これらの設定は、MediaTailor が ADS から広告をプリフェッチするタイミングを決定します。また、ADS へのリクエストに含める動的セッション変数があれば決定します。
-
[Start time] (開始時間) には、MediaTailor がこの広告ブレーク用のプリフェッチ取得を開始できる時刻を入力します。MediaTailor は、この時刻以降にクライアントによって行われるマニフェストリクエストのための広告のプリフェッチを試みます。デフォルト値は現在の時刻です。値を指定しない場合、サービスは可能な限り速やかにプリフェッチ取得を開始します。
-
[End time] (終了時間) には、MediaTailor がこの広告ブレーク用のプリフェッチ取得を停止する時刻を入力します。MediaTailor は、この時刻以前に行われるマニフェストリクエストのための広告のプリフェッチを試みます。取得時間枠は、消費時間枠と重複させることができます。
-
動的変数 セクションには、最大 100 個の動的セッション変数を入力します。MediaTailor は、ADS に送信するプリフェッチリクエストでの代入にこれらの変数を使用します。動的セッション変数を入力しない場合、MediaTailor は ADS URL に含まれる動的変数の値を補間するよう最善を尽くします。
-
[Add dynamic variable] (動的変数を追加) をクリックします。
-
キーには、 などの動的セッション変数キーを入力します
scte.event_id
。これには、MediaTailor がサポートする任意の動的変数を使用できます。動的セッション変数の詳細については、「」を参照してくださいセッション変数の使用。 -
[Value] (値) には、
my-event
などの動的変数値を入力します。 -
別の動的変数を追加するには、[Add dynamic variable] (動的変数を追加) をクリックします。
-
-
-
[Consumption] (消費) ペインで、消費時間枠に使用する設定を指定します。これらの設定は、MediaTailor が広告ブレークに広告を配置するタイミングを決定します。また、使用する avail 使用条件も決定します。
-
[Start time] (開始時間) には、MediaTailor がプリフェッチされた広告の広告ブレークへの配置を開始する時刻を入力します。デフォルト値は現在の時刻です。時刻を指定しない場合、サービスは可能な限り速やかにプリフェッチ消費を開始します。
-
[End time] (終了時間) には、MediaTailor がプリフェッチされた広告の広告ブレークへの配置を停止する時刻を入力します。MediaTailor は、この時刻以前に行われるクライアントのマニフェストリクエストのための広告のプリフェッチを試みます。終了時刻は、開始時刻の後、かつ現時点から 1 日未満の時刻にする必要があります。消費時間枠は、取得時間枠と重複させることができます。
-
[Avail matching criteria] (Avail 一致条件) セクションで [Add avail criteria] (avail 条件を追加) をクリックし、スケジュールに最大 5 個の avail 一致条件を追加します。その後、[Dynamic variable key] (動的変数キー) で、
scte.event_id
などの動的変数キーを追加します。MediaTailor が広告ブレークにプリフェッチされた広告を配置するのは、クライアントが MediaTailor に渡す動的変数値、または MediaTailor がセッションデータなどの情報から推測する動的変数値によって定義された条件を広告ブレークが満たす場合のみです。条件については、上記の「avail-matching-criteria」セクションを参照してください。
-
-
[Add avail criteria] (Avail 条件を追加) をクリックします。
プリフェッチスケジュールは、消費時間枠の終了時間後、自動的に期限が切れます。これらは、診断目的のために少なくとも 7 日間表示された後、MediaTailor によって自動的に削除されます。また、プリフェッチスケジュールはいつでも手動で削除できます。プリフェッチスケジュールを手動で削除する方法については、以下の「プリフェッチスケジュールの削除」セクションを参照してください。
クライアントが CreatePrefetchSchedule API を呼び出す頻度の決定
広告ブレークが配信される正確なタイミングをユーザーが把握している場合、クライアントは 1 日 1 回 CreatePrefetchSchedule API をプログラム的に呼び出して、取得と消費をセットアップできます。クライアントは、一日中何度も API を呼び出して、取得と消費を定義することもできます。API コールの頻度を選択するときは、アクティブなプリフェッチスケジュールの最大数と、プリフェッチスケジュールの作成後に広告時間枠スケジュールが変更される可能性を考慮してください (複数可)。プリフェッチスケジュールの作成後に広告ブレークスケジュールが変更される可能性が高い場合は、API をより頻繁に呼び出すことをお勧めします。