翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# MediaTailor サーバー側の広告の追跡とレポート
<a name="ad-reporting-server-side"></a>

AWS Elemental MediaTailor は、包括的な広告の追跡と測定のためのサーバー側のレポートにデフォルト設定されています。サーバー側のレポートでは、プレイヤーがマニフェストからの広告 URL をリクエストするときに、サービスが広告消費を広告追跡 URL に直接報告します。プレイヤーが MediaTailor との再生セッションを開始したら、サーバー側のレポートを実行するためにユーザーまたはプレイヤーからの追加入力が必要になることはありません。MediaTailor は、各広告が再生されるたびに広告サーバーにビーコンを送信して、広告がどのくらい閲覧されたのかを報告します。MediaTailor は、広告の開始時点と、広告の進行における四分位点 (第 1 分位点、中間点、第 3 分位点、および広告の終了時点) に関するビーコンを送信します。

**サーバー側の広告レポートを実行する**
+ プレイヤーから、プロトコルに従った以下のいずれかの形式を使用して、新しい MediaTailor 再生セッションを開始します。
  + 例: HLS 形式

    ```
    GET <mediatailorURL>/v1/master/<hashed-account-id>/<origin-id>/<asset-id>?ads.<key-value-pairs-for-ads>&<key-value-pairs-for-origin-server>
    ```
  + 例: DASH 形式

    ```
    GET <mediatailorURL>/v1/dash/<hashed-account-id>/<origin-id>/<asset-id>?ads.<key-value-pairs-for-ads>&<key-value-pairs-for-origin-server>
    ```

  キーバリューペアは、広告追跡用の動的なターゲティングパラメータです。リクエストへのパラメータの追加については、「[ADS リクエストの MediaTailor 動的広告変数](variables.md)」を参照してください。

AWS Elemental MediaTailor はマニフェスト URL を使用してリクエストに応答します。マニフェストには、メディアマニフェストの URL が含まれています。メディアマニフェストには、広告セグメントリクエストに対する埋め込みリンクが含まれています。

**注記**  
MediaTailor が追跡 URL で二重スラッシュ (//) を検出すると、スラッシュは 1 (/) に折りたたまれます。

プレーヤーが広告セグメント URL (`/v1/segment` パス) に再生をリクエストすると、 AWS Elemental MediaTailor は該当するビーコンを広告追跡 URL を介して広告サーバーに送信します。それと同時に、サービスが実際の `*.ts` 広告セグメントへのリダイレクトを発行します。広告セグメントは、MediaTailor がトランスコードされた広告を保存する Amazon CloudFront ディストリビューション、または広告をキャッシュしたコンテンツ配信ネットワーク (CDN) のいずれかにあります。

以下のセクションでは、MediaTailor からのサーバー側の広告追跡の操作について詳しく説明します。

**Topics**
+ [SGAI サーバー側の追跡](ad-reporting-server-side-sgai.md)
+ [ビーコン用語集](ad-reporting-server-side-beacon-glossary.md)
+ [タイミングとキャッシュの動作](ad-reporting-server-side-timing-behavior.md)
+ [追跡機能](ad-reporting-server-side-features.md)

# サーバーガイド広告挿入によるサーバー側の追跡 (SGAI)
<a name="ad-reporting-server-side-sgai"></a>

サーバーガイド広告挿入 (SGAI) を使用する場合、サーバー側の追跡は、上記のステッチモードアプローチとは異なる*セッションレスビーコン*メカニズムを使用します。MediaTailor が広告セグメントをコンテンツマニフェスト (`/v1/segment`リクエストを追跡する場所) にステッチする代わりに、SGAI は広告参照を個別のプレイリストとしてアセットリストレスポンスに返し、ビーコンメタデータが広告 URIs。

## セッションレスサーバー側のビーコンの仕組み
<a name="ad-reporting-server-side-sgai-how-it-works"></a>

次の手順では、SGAI セッションでサーバー側のビーコンがどのように機能するかについて説明します。

1. **セッションの初期化**: プレイヤーは を使用して HLS マルチバリアントプレイリストをリクエストします`aws.insertionMode=GUIDED`。サーバー側のレポートはデフォルトです (`aws.reportingMode`パラメータは必要ありません）。ステッチモードとは異なり、セッション初期化レスポンスには *は含まれません*`trackingUrl`。

1. **キャッシュ可能なマニ**フェスト: MediaTailor は、MediaTailor インタースティシャルアセットリストエンドポイントを指す `CLASS="com.apple.hls.interstitial"`および `X-ASSET-LIST` 属性を持つ`EXT-X-DATERANGE`タグを含むキャッシュ可能なマニフェストを返します。

1. **ビーコンメタデータを含むアセットリスト**: プレイヤーが広告時間枠に遭遇すると、アセットリストが取得されます。MediaTailor は、各広告 URI に暗号化されたビーコンメタデータが含まれる JSON レスポンスを返します。

   ```
   {
     "ASSETS": [
       {
         "DURATION": 30.0,
         "URI": "https://cdn.example.com/ad/master.m3u8?awsBeaconData=<encrypted>&awsBeaconDomain=<MediaTailor-endpoint>&awsConfigurationName=<config-name>"
       }
     ]
   }
   ```

   サーバー側のレポートがアクティブな場合、レスポンスには `TRACKING`セクション*は含まれません*。広告 URIs格納されます。

1. **HLS 変数置換**: プレイヤーはアドマルチバリアントプレイリストを取得します。広告マニフェストは、 `#EXT-X-DEFINE:QUERYPARAM` ディレクティブを使用して、URI クエリ文字列から HLS 変数置換を介してセグメント URLs にビーコンパラメータを渡します。

   ```
   #EXTM3U
   #EXT-X-DEFINE:QUERYPARAM="awsBeaconData"
   #EXT-X-DEFINE:QUERYPARAM="awsBeaconDomain"
   #EXT-X-DEFINE:QUERYPARAM="awsConfigurationName"
   #EXTINF:5.0,
   {$awsBeaconDomain}/segment/hash/{$awsConfigurationName}/{$awsBeaconData}/0/0?aws.segmentRelativePath=asset_00001.ts
   ```

   プレイヤーは、広告マニフェスト URI クエリ文字列の値を使用して `{$awsBeaconData}`、`{$awsBeaconDomain}`、および `{$awsConfigurationName}`変数を解決し、MediaTailor を介して各広告セグメントをリクエストします。

1. **セグメントリクエストでビーコンが発射**する: プレイヤーが各広告セグメントをリクエストすると、リクエストは MediaTailor を経由します。サービスはビーコンデータを復号し、広告内のセグメントの位置 (インプレッション、第 1 四分位、中間、第 3 四分位、または完了) を決定し、適切な VAST 追跡ビーコンを広告サーバーに発射します。MediaTailor は、プレイヤーを実際の広告コンテンツセグメントにリダイレクトします。

## SGAI サーバー側のビーコンのプレイヤー要件
<a name="ad-reporting-server-side-sgai-requirements"></a>

SGAI でサーバー側のビーコンを使用するには、プレイヤーが次の要件を満たしている必要があります。
+ HLS バージョン 11 以降
+ HLS Interstitials の `CLASS` 属性`EXT-X-DATERANGE`を使用した のサポート
+ `#EXT-X-DEFINE:QUERYPARAM` 可変置換 (RFC 8216bis) のサポート。プレイヤーは、クエリパラメータ値をセグメント URLs に置き換える前に、それらをパーセントデコードする必要があります。

**注記**  
SGAI サーバー側のビーコンは現在、HLS でのみサポートされています。DASH は、SGAI サーバー側のビーコンではまだサポートされていません。

## ステッチモードのサーバー側の追跡との比較
<a name="ad-reporting-server-side-sgai-comparison"></a>

次の表は、ステッチ広告挿入とサーバーガイド広告挿入でサーバー側の追跡がどのように異なるかをまとめたものです。


| 側面 | ステッチ (SSAI) | サーバーガイド (SGAI) | 
| --- | --- | --- | 
| マニフェストのキャッシュ可能性 | セッションごと、キャッシュ不可 | キャッシュ可能、ビューワー間で共有 | 
| 広告セグメントのルーティング | セッション ID /v1/segment/を使用する | 暗号化されたビーコンデータ BLOB /v1/segment/を使用する | 
| ビーコンのセッション状態 | MediaTailor にセッションごとに保存 | セッションレス — すべての状態は暗号化されたawsBeaconDataパラメータで伝送されます | 
| セッション開始時の追跡 URL | セッション初期化レスポンスで返されます | 指定なし — ビーコンデータは各アセットリストレスポンスの広告 URIs に埋め込まれます | 
| DASH サポート | サポート | まだサポートされていません。 | 

**注記**  
ライブ SGAI セッションでは、 を使用してマニフェストベースの広告プリフェッチを有効にできます`aws.guidedPrefetchMode=MANIFEST`。これは、スティッチド (SSAI) セッションで使用されるスケジュールベースのプリフェッチ API とは異なります。詳細については、「[マニフェストハートビートを使用したガイド付きプリフェッチ](sgai-guided-prefetch.md)」を参照してください。

# サーバー側の追跡ビーコン用語集
<a name="ad-reporting-server-side-beacon-glossary"></a>

MediaTailor サーバー側の追跡では、標準化されたビーコンのセットを使用して、広告表示の進行状況を広告サーバーと検証サービスに報告します。これらのビーコンは、動画広告測定のインタラクティブ広告局 (IAB) 標準に準拠しており、広告インプレッションと完了率を正確に報告できます。


**サーバー側の追跡ビーコンタイプ**  

| ビーコンタイプ | 発砲時 | 目的 | タイミングの詳細 | 
| --- | --- | --- | --- | 
| インプレッション | プレイヤーが最初の広告セグメントをリクエストしたとき | 広告コンテンツのロードが開始され、ビューワーに表示しようとしていることを示します。 | 広告の最初の/v1/segmentリクエストで発砲されました。インプレッションをカウントする前に広告コンテンツのロードを開始することを義務付ける IAB ガイドラインに準拠しています。完全なシーケンス[サーバー側の追跡ワークフロー](ad-reporting-server-side-timing-behavior.md#ad-reporting-server-side-timing-behavior-workflow)については、「」を参照してください。 | 
| 開始 | プレイヤーが広告コンテンツのレンダリングを開始したとき | 広告再生が実際に開始されたことを確認します | 通常、最初のセグメントリクエストでインプレッションビーコンと同時に起動されますが、広告レンダリングの実際の開始を表します。この区別は、インプレッションイベントと開始イベントの両方を個別に追跡する検証サービスにとって重要です。 | 
| 第 1 四分位数 | プレイヤーが広告期間の 25% に達した場合 | 広告の第 1 四半期を通じて広告表示を継続した測定値 | プレイヤーが広告期間の 25% ポイントを含むセグメントをリクエストしたときに発生します。たとえば、2 秒のセグメントを持つ 20 秒の広告では、通常、これは 3 番目のセグメントのリクエストで発生します (広告から約 4～6 秒後）。 | 
| 中間点 | プレイヤーが広告期間の 50% に達した場合 | 広告の半分までの継続的な広告表示を測定します。 | プレイヤーが広告期間の 50% ポイントを含むセグメントをリクエストしたときに発生します。たとえば、2 秒のセグメントを持つ 20 秒の広告では、通常、これは 5 番目のセグメント (広告から約 8～10 秒) のリクエストで発生します。 | 
| 第 3 四分位 | プレイヤーが広告期間の 75% に達した場合 | 広告の 4 分の 3 を通じて継続的な広告表示を測定する | プレイヤーが広告期間の 75% ポイントを含むセグメントをリクエストしたときに発生します。たとえば、2 秒のセグメントを持つ 20 秒の広告では、通常、これは 8 番目のセグメント (広告から約 14～16 秒) のリクエストで発生します。 | 
| 完了 | プレイヤーが広告の最後に到達したとき | 広告全体がビューワーに配信されたことを確認します | プレイヤーが広告の最終セグメントをリクエストしたときに発生します。これは、ビューワーが広告コンテンツ全体を表示した可能性があることを示します。例えば、2 秒のセグメントを持つ 20 秒の広告では、これは通常、10 番目のセグメントのリクエスト (広告から約 18～20 秒) で発生します。 | 

**注記**  
ビーコン発射の正確なタイミングは、セグメントの期間と広告の長さによって異なります。MediaTailor は、特定の広告期間とセグメント構造に基づいて、各四分位位置に対応する適切なセグメントリクエストを計算します。

# サーバー側の追跡タイミングとキャッシュ動作
<a name="ad-reporting-server-side-timing-behavior"></a>

サーバー側のレポートでは、MediaTailor は、マニフェスト解析やプリロードアクティビティではなく、プレイヤーからの実際のセグメントリクエストに基づいて追跡イベントを実行します。このアプローチにより、動画広告測定の業界標準に沿った正確なインプレッションカウントが保証されます。

## 主要なタイミングの原則
<a name="ad-reporting-server-side-timing-behavior-principles"></a>

MediaTailor サーバー側の追跡は、以下の基本的なタイミング原則に従います。
+ **実際のセグメントリクエストで追跡イベントが発生する** - ビーコンは、マニフェストの解析やキャッシュ中ではなく、プレイヤーが `/v1/segment` URLs に HTTP リクエストを行った場合にのみ送信されます。
+ **プレイヤーのキャッシュとマニフェストの事前ロードはイベントをトリガーしません** - プレイヤーは追跡イベントを生成せずにマニフェスト情報を解析、キャッシュ、または事前ロードできます。
+ **セグメントプリフェッチ*は*イベントをトリガーします** - プレイヤーが再生前に実際の広告セグメントをプリフェッチする場合、これはセグメントリクエストが有効なインプレッションを構成する業界標準の動作に従います。
+ **各 /v1/segment request triggers appropriate beacon** - 特定の追跡イベント (インプレッション、四分位数、完了) は、リクエストされる広告の位置とセグメントによって決まります。
+ **タイミングは IAB 標準に準拠** - このアプローチは、動画広告の測定とインプレッションカウントに関するインタラクティブ広告局のガイドラインに従います。

## サーバー側の追跡ワークフロー
<a name="ad-reporting-server-side-timing-behavior-workflow"></a>

次の図は、サーバー側の完全な追跡ワークフローを示しています。このワークフローは、プレイヤーリクエストに関連して追跡イベントが発生するタイミングを示しています。

**フェーズ 1: セッションの初期化**  
プレイヤーは MediaTailor にマニフェストをリクエストし、広告セグメント URLs を含むパーソナライズされたマニフェストを返します。  

![\[MediaTailor にマニフェストをリクエストし、広告セグメント URLs を使用してパーソナライズされたマニフェストを受信するプレイヤーを示すセッション初期化フェーズ。\]](http://docs.aws.amazon.com/ja_jp/mediatailor/latest/ug/images/ss-track-phase1.png)


**フェーズ 2: 広告リクエストとインプレッションの追跡**  
プレイヤーが最初の広告セグメントをリクエストすると、MediaTailor はインプレッションを起動し、広告決定サーバーと広告検証サービスの両方にビーコンを開始します。  

![\[プレイヤーが最初の広告セグメントをリクエストしたときに MediaTailor がインプレッションビーコンと開始ビーコンの両方を広告決定サーバーと広告検証サービスに送信することを示す広告インプレッション追跡フェーズ。\]](http://docs.aws.amazon.com/ja_jp/mediatailor/latest/ug/images/ss-track-phase2.png)


**フェーズ 3: 四分位数の追跡**  
MediaTailor は、後続のセグメントリクエストに基づいて四分位ビーコン (第 1 四分位、中間点、第 3 四分位、完了) を起動します。  

![\[プレイヤーが後続の広告セグメントをリクエストする際にMediaTailor が広告決定サーバーと広告検証サービスの両方に四分位ビーコンを発射することを示す四分位追跡フェーズ。\]](http://docs.aws.amazon.com/ja_jp/mediatailor/latest/ug/images/ss-track-phase3.png)


**フェーズ 4: セグメント配信**  
追跡ビーコンを発射すると、MediaTailor は Amazon CloudFront または CDN から実際の広告セグメントにリダイレクトします。  

![\[追跡ビーコンを発射した後、MediaTailor がプレイヤーを CloudFront または CDN から実際の広告セグメントにリダイレクトすることを示すセグメント配信フェーズ。\]](http://docs.aws.amazon.com/ja_jp/mediatailor/latest/ug/images/ss-track-phase4.png)


サーバー側の追跡ワークフローには、次の主要なタイミング動作が含まれます。

1. **セッションの初期化** - プレイヤーは MediaTailor にマニフェストをリクエストします。MediaTailor は、 `/v1/segment`パスを持つ広告セグメント URLsを含むパーソナライズされたマニフェストを返します。

1. **マニフェスト解析とキャッシュ** - プレイヤーはマニフェストを解析し、セグメント情報をプリロードまたはキャッシュできます。**このフェーズでは、プレイヤーのキャッシュ動作に関係なく、追跡イベントは発生しません**。

1. **広告セグメントのリクエストとインプレッションの追跡** - プレイヤーが実際に最初の広告セグメントをリクエストすると (通常は再生用）、MediaTailor はインプレッションビーコンを起動し、広告決定サーバーと広告検証サービスの両方にイベントの追跡を開始します。これは、マニフェストが解析されるときではなく、`/v1/segment`URL への実際の HTTP リクエストで発生します。

1. **セグメントリクエストに基づく四分位追跡** - MediaTailor は、広告期間中の計算された四分位位置に対応する後続のセグメントリクエストに基づいて、広告決定サーバーと広告検証サービスの両方に四分位ビーコン (第 1 四分位、中間点、第 3 四分位、完了) を起動します。

1. **セグメント配信** - 適切な追跡ビーコンを発射した後、MediaTailor は実際の広告セグメント (Amazon CloudFront または CDN) への HTTP リダイレクトを発行します。

## プレイヤーキャッシュとプリロードに関する考慮事項
<a name="ad-reporting-server-side-timing-behavior-caching-considerations"></a>

MediaTailor サーバー側の追跡は、正確なインプレッション測定を維持しながら、さまざまなプレイヤーキャッシュおよびプリロード戦略と互換性があるように設計されています。
+ **マニフェストプリロード** - マニフェスト情報をプリロードまたはキャッシュするプレイヤーは、追跡イベントをトリガーしません。追跡イベントは、実際のセグメントリクエストが行われた場合にのみ発生します。
+ **セグメントのプリフェッチ** - プレイヤーが再生前に広告セグメントをプリフェッチすると、それらのセグメントがリクエストされたときに、実際の再生時間よりも前に追跡イベントが発生します。この動作は、セグメントリクエストを有効なインプレッションと見なす業界標準と一致しています。
+ **プレイヤーバッファリング** - 標準プレイヤーバッファリング動作 (再生の少し前にセグメントをリクエスト) は、セグメントリクエストパターンに基づいて、適切なタイミングで追跡イベントをトリガーします。

## 追跡の不一致のトラブルシューティング
<a name="ad-reporting-server-side-timing-behavior-troubleshooting"></a>

MediaTailor のサーバー側の追跡とサードパーティーのメトリクスの間に不一致がある場合は、次の要素を考慮してください。
+ **プレイヤーの動作の違い** - プレイヤーごとにプリフェッチ戦略とバッファリング戦略が異なり、セグメントリクエストが行われたときに に影響する場合があります。
+ **ネットワーク条件** - ネットワーク条件が悪いと、プレイヤーが複数回、または予想とは異なる間隔でセグメントをリクエストする可能性があります。
+ **CDN 設定** - `/v1/segment`リクエストの CDN キャッシュが正しくないと、追跡イベントが見逃されたり、重複したりする可能性があります。
+ **セッション管理** - イベント競合の追跡を防ぐために、各再生セッションで一意のセッション識別子が使用されていることを確認します。

トラブルシューティングの詳細なガイダンスについては、「」を参照してください[一般的な問題のトラブルシューティング](monitoring-and-troubleshooting.md#troubleshooting-common-issues)。

# MediaTailor サーバー側の追跡機能
<a name="ad-reporting-server-side-features"></a>

AWS Elemental MediaTailor は、これらの統合されたサーバー側の追跡機能を自動的に適用して、広告測定の精度と信頼性を最適化します。このシステムは、ビーコンの重複を防ぎ、大量の期間中のトラフィックを管理し、適切なイベントシーケンスを維持し、ユーザーによる設定を必要とせずに包括的なパフォーマンスモニタリングを提供します。広告決定サーバー (ADS) が VAST レスポンスで追跡ビーコンを提供することを確認するだけで済みます。

**注記**  
これらの機能は、2025 年 9 月 30 日以降、新規のお客様にご利用いただけます。既存のお客様は、継続的なサービス改善の一環として、2025 年を通じて にアクセスできます。これらの機能にすぐにアクセスしたい場合は、[AWS サポート](https://aws.amazon.com/premiumsupport/)にお問い合わせください。

**注記**  
これらの機能は、スティッチド (SSAI) 広告挿入方法とサーバーガイド (SGAI) 広告挿入方法の両方に適用されます。ビーコンのタイプとタイミングは、両方のモードで同じです。MediaTailor がビーコンをトリガーする方法は異なります。SGAI サーバー側のビーコンの詳細については、[サーバーガイド広告挿入によるサーバー側の追跡 (SGAI)](ad-reporting-server-side-sgai.md)「」を参照してください。

## ビーコン重複排除
<a name="ad-reporting-server-side-beacon-deduplication"></a>

MediaTailor は、同一の広告イベントに対するビーコンの重複射撃を防止します。サーバー側の追跡システムは、各インプレッション、四分位数、完了ビーコンを広告表示セッションごとに 1 回のみ送信します。ネットワーク条件、ビットレートの変更、バッファリング戦略により、ビデオプレイヤーが同じ広告セグメントを複数回リクエストすると、MediaTailor は発射されたビーコンを追跡し、冗長な送信をブロックします。

重複排除は、ビーコン数の増加を引き起こす一般的なシナリオを自動的に解決します。
+ **アダプティブビットレートストリーミング** - プレイヤーが同じ広告セグメントの異なる品質バリアントをダウンロードする場合
+ **ネットワーク再試行シナリオ** - ネットワークの問題またはタイムアウトが原因でプレイヤーがセグメントを再リクエストする場合
+ **プレイヤーバッファリング戦略** - プレイヤーがバッファリング目的でセグメントをプリフェッチまたは再フェッチする場合

このシステムは、プレイヤーが異なる品質レベルを切り替える場合でも、インプレッションビーコンを 1 回だけ発射するように設計されています。

## アダプティブスロットリングとビーコンの再試行
<a name="ad-reporting-server-side-adaptive-throttling"></a>

MediaTailor は、サーバーレスポンスインジケータに基づいてビーコントラフィックレートを自動的に管理します。システムは HTTP レスポンスパターン、接続タイムアウト、エラーコードをモニタリングして輻輳を検出し、それに応じてトラフィックレートを調整します。システムがサーバーのストレスインジケータを識別すると、影響を受けるドメインのトラフィックレートが低下し、サーバーが容量の改善を示すと自動的にレートが増加します。

システムは、次のインジケータを使用してサーバーの状態をモニタリングします。
+ **HTTP 接続タイムアウト** - 測定プラットフォームが想定期間内に応答しない場合
+ **エラーレスポンスコード** - サーバーの過負荷を示す 503、504、および 507 レスポンス。広告サーバーは、完全な互換性のためにこれらのエラーコードもサポートする必要があります。
+ **レスポンスパターン** - 容量の問題を示す測定プラットフォームのパフォーマンスの変化

再試行動作は、最大 1 時間、試行間の最小 30 秒の遅延で自動的に配信を試行します。この再試行動作は設定できません。

## 1 秒あたりのビーコントラフィックの管理
<a name="ad-reporting-server-side-tps-management"></a>

TPS 制限を設定して、ビーコン配信レートを制御できます。これは、サーバー側の追跡機能に対して設定可能な唯一の設定です。アカウントレベルの制限は、すべての測定パートナーに送信される広告追跡リクエストの合計数を制限します。MediaTailor は、エンタープライズ規模のオペレーションに十分な容量を提供するために、最小 TPS 制限 10,000 を適用します。

 AWS サポートチケットを送信して、以下の情報を含む TPS 制限を確立します。
+ **AWS アカウント ID** - 特定のアカウント識別子
+ **ターゲットリージョン** - TPS 制限を適用する AWS リージョン
+ **希望する TPS しきい値** - 1 秒あたりの必要なトランザクション数の制限 (最小 10,000)

デフォルトでは、TPS の制限はありません。広告決定サーバー (ADS) で必要な場合は TPS 制限をリクエストできますが、制限は 10,000 TPS を超える必要があります。MediaTailor は指定された制限を超えることはありませんが、その制限まで一貫したスループットを保証するものではありません。広告決定サーバーは、サポートできる TPS 制限を知らせます。

## インオーダービーコン
<a name="ad-reporting-server-side-in-order-beaconing"></a>

MediaTailor は、広告追跡イベントのシーケンシャル配信を自動的に維持します。システムは、ネットワークの問題、再試行、またはトラフィック管理が発生した場合でも、ビーコンの順序を保持します。これにより、測定パートナーは正確な分析のために正しい順序でイベントを受信できます。

システムは、標準の業界ビーコンシーケンスに従います。

1. **開始イベント** - 広告の再生が開始されると起動します

1. **第 1 四分位イベント** - 広告完了率 25% で発生

1. **中間イベント** - 広告完了率 50% で発生

1. **第 3 四分位イベント** - 広告完了率 75% で発生

1. **完了イベント** - 広告が終了すると起動します

これらの機能は、自動的に連携します。
+ 適切な順序を維持するために、スロットリング中にビーコンが保持されます
+ 各測定パートナードメインには、レート調整中の中断を防ぐために個別のイベントキューがあります。
+ 重複排除は、時系列を維持しながらイベントタイプとタイムラインの位置を追跡します