概要： 一部の集計データがexceeded と表示される理由と、それを防止する方法にするについて記載しています。
exceeded とは何ですか？
AppsFlyerではインストールデータとイベントデータを収集して集計しており、そのデータは特定の項目を設定する一意の値として集計されます。このとき、各項目内のユニークな値の個数のことをカーディナリティと呼び、殆どの分析ツールや集計ツールには各項目ごとにカーディナリティの上限があります。
その結果、各項目内のユニークな値の数がカーディナリティの上限を超えてしまった場合には、残りのデータはexceededのグループに割り当てられます。以下の例では、カーディナリティとそれがレポートにどのように影響するかを示しています。
例
例１：カーディナリティとは？
Campaign IDのカーディナリティ上限は3000です。特定の日において、計測されたCampaign IDの数が3000を超えた場合、残りのCampaign IDはすべてExceeded_CampaignID_Limitとしてグループ化 / 集計されます。
例２：一部のイベントがExceeded_Events_Limitのグループに集計されるのはなぜですか？
- イベントのカーディナリティ上限が3であるとします。
- 特定の日に、A / B / C / D / E / F / Gという7つのユニークなイベントが記録されたとすると、このときイベントのカーディナリティは7になります。
- このとき、集計レポート内では、A / B / Cのイベントはそれぞれ別々に一覧に表示されますが、D / E / F / GのイベントはExceeded_Events_Limitにグループ化された状態で表示されます。
ローデータレポートは、カーディナリティ上限の影響は受けないのでご安心ください。
データの大部分が exceededのグループに集計されてしまうと、相当量のデータの詳細が分からなくなってしまい、分析レポートが不正確な結果になってしまいます。
必要に応じて、ローデータを使ってカーディナリティの上限を受けない形でグループを作成しましょう。
以下の表では、各項目（ディメンション）のカーディナリティ上限を記載しています。
| ディメンション | Exceeded group name | 上限対象となる対象の区分 | 1日あたりのカーディナリティ上限 | 1日あたりのProtect360におけるカーディナリティ上限 |
|---|---|---|---|---|
| Ad | Exceeded_Ad_Limit | メディアソース | 1000 | - |
| Ad ID | Exceeded_AdID_Limit | メディアソース | 1000 | - |
| 広告セット | Exceeded_AdSet_Limit | メディアソース | 1000 | - |
| Adset ID | Exceeded_AdSetID_Limit | メディアソース | 1000 | - |
| Campaign | Exceeded_Campaign_Limit | メディアソース | 3000 | 3000 |
| Campaign ID | Exceeded_CampaignID_Limit | メディアソース | 3000 | 3000 |
| Channel | Exceeded_Channels_Limit | メディアソース | 20 | 1000 |
| Site ID | Exceeded_SiteID_Limit | メディアソース | 1000 | 1000 |
| イベント | Exceeded_Events_Limit | アプリ | 300 | 300 |
| Keywords | Exceeded_Keywords_Limit | メディアソース | 1000 | - |
| メディアソース名 | Exceeded_MediaSource_Limit | アプリ | 1000 | 1000 |
各項目（ディメンション）毎のカーディナリティ上限
Exceeded_AdSet_Limit と Exceeded_Ad_Limit
- メディアソース毎に、それぞれ最大1000個のユニークなアドセット名 (af_adset) とアド名 (af_ad) を利用可能です。
- 特定の日において、1001個目のアドセット名以降は全てのアドセット名のデータが Exceeded_AdSet_Limit というグループに紐づき、同じことがアド名の場合にはExceeded_Ad_Limit に適用されます。
ヒント
データを細分化して克服しましょう。一般的なアドセット名（理想的には最大50個まで）をいくつか定義し、これまで使っていた全てのアドセット名を代わりにアド名へ割り当ててください。また、af_subのパラメータも計測リンクに追加して利用することが可能なので、これらを活用することで以下のことが可能になります：
1. Exceeded_AdSet_Limit や Exceeded_Ad_Limitの発生の防止
2. より有効なアドセット名とアド名のトラフィックの効果的な最適化
3. ローデータ内における、アドセット名やアド名に基づいた深い分析の実行
Exceeded_AdSetID_Limit と Exceeded_AdID_Limit
- メディアソース毎に、それぞれ最大1000個のユニークなアドセットID (af_adset_id) とアドID (af_ad_id) を利用可能です。
- 特定の日において、1001個目のアドセットID以降は全てのアドセットIDのデータが Exceeded_AdSetID_Limit というグループに紐づき、同じことがアドIDの場合にはExceeded_AdID_Limit に適用されます。
Exceeded_Campaign_Limit
- 1日あたり最大 3000 個のユニークなキャンペーン名 (c) を使用できます。
- 特定の日において、3001個目のアドセットID以降は全てのアドセットIDのデータが Exceeded_Campaign_Limit というグループに紐づきます。
ヒント
一般的なキャンペーン名（理想的には最大300個まで）をいくつか定義し、これまで使っていた全てのキャンペーン名を代わりにアドセット名へ割り当ててください。（AppsFlyerの計測リンクにおける対象パラメータはaf_adsetです。）これにより、以下のことが可能になります：
1. Exceeded_Campaign_Limitの発生の防止
2. より有効なアドセット名のトラフィックの効果的な最適化
3. ローデータ内における、キャンペーン名やアドセット名に基づいた深い分析の実行
Exceeded_CampaignID_Limit
- 1日あたり最大 3000 個のユニークなキャンペーンID (af_c_id) を使用できます。
- 特定の日において、3,001番目のキャンペーンからは全てのキャンペーンデータが Exceeded_CampaignID_Limit というメディアソースに紐づきます。
Exceeded_Channels_Limit
- メディアソース毎に、1日あたり最大20個のユニークなチャネル名 (af_channel) を計測可能です。（Protect360の画面上では1000個が上限です。）
- 特定の日において、21個目のチャネル名以降は全てのチャネル名のデータが Exceeded_Channel_Limit というグループに紐づきます。
Exceeded_Events_Limit
- 1日あたり最大 300 個のユニークなイベント名を計測可能です。
- 特定の日において、301個目のイベント名以降は全てのイベント名のデータが Exceeded_Events_Limit というグループに紐づきます。
ヒント
Exceeded_Events_Limitが表示されないようにするには、以下のような対策を検討してください：
- リッチアプリ内イベントをご利用ください。何百もの異なるイベント名は定義せずに、少数の一般的なイベント名（理想的には最大20個）を定義し、動的なイベント値 (event_value) を使用してこれらのイベントを区別しましょう。アプリ内イベントのローデータを使うことで、イベント値のパラメータを使った最適化や、イベント値を基にした分析が可能になります。
- 不必要なアプリ内イベントのデータをAppsFyerのプラットフォームから除外するために、検証ルールの活用も検討してください。
例
「com.greatapp」というアプリが、販売している靴下の色別にそれぞれ購入イベントを定義して送信するとします。イベント名の例：buy_red_socks、buy_blue_socks、buy_white_socksなど。イベント数が膨大になることを防ぐために、これらを「buy_socks」という単一のイベントに統一し、購入された靴下の色をイベントパラメーターとして挿入してください。
Exceeded_Keywords_Limit
- メディアソース毎に、1日あたり最大1000個のユニークなキーワード (af_keywords) を計測可能です。
- 特定の日において、1001番目のキーワード以降は全てのキーワードデータが Exceeded_Keywords_Limit というグループに紐づきます。
Exceeded_MediaSource_Limit
- 1日あたり最大 1000 個のユニークなメディアソース名 (pid) を使用できます。
- 特定の日において、 1001番目のメディアソース名以降は全てのメディアソースが Exceeded_MediasSource_Limit というグループに紐づきます。
Exceeded_SiteID_Limit
- メディアソース毎に、1日あたり最大1000個のユニークなサイトID (af_siteid) を計測可能です。
- 特定の日において、1001番目のサイトID以降はメディアソースごとの全てのサイトIDのデータがExceeded_SiteID_Limit という１つのグループに紐づきます。したがって、Exceeded_SiteID_Limit というサイトIDが表示されている場合、該当のメディアソースで使用されているサイトIDが多すぎることを意味し、このソースのトラフィックをサイトIDごとに最適化する際の精度と効率が低下してしまいます。
ヒント
「細分化して克服」メディアソースごとに数千個のサイトIDを使用する代わりに、計測リンクに af_sub_siteid というサブサイトIDのパラメーターを使用してください。小数の一般的なサイトID（理想的には最大50個）を定義し、以前のサイトIDを全てサブサイトIDとして一般的なサイトIDの下に割り当ててください。これにより、次のことが可能になります：
1. Exceeded_SiteID_Limit を防ぐことができます。
2. 重要なサイトIDのトラフィックに基づいて効果的に最適化できます。
3. ローデータ内のサイトIDとサブサイトIDに基づいて詳細な分析を実行できます。
注意
リテンションレポートでは、Exceeded_SiteID_Limit は表示されませんが、全てのサイトIDが表示されるわけではありません。サイトIDはランダムに表示されますが、UIの制限により全てを表示することができません（上限を超えている場合）。この問題を回避するためには、リテンションデータをMaster APIから取得してください。
Exceededという表示を防ぐ方法は？
長期的なソリューション
通常、ほとんどの広告主は3000個を超えるキャンペーン名を手動で定義することはないので、Exceededというキャンペーン名は表示されません。
仮にExceeded が表示された場合には、1つまたは複数のメディアソースにて、キャンペーン名、サイトID、広告セット、広告などのパラメータに対して動的に値を振り当てている可能性があります。また、アプリのコード内で動的にアプリ内イベント名を作成して使用した場合にも、Exceeded_Events_Limit と表示されることがあります。
ヒント
Exceeded の表示を避けるためには、アプリ内イベント、キャンペーン、サイトID、広告セット、広告に静的な値のみを使用してください。
また、Exceededのタイプごとに特定のヒントを確認してください。
短期的なソリューション
長期的なソリューションの実装を完了するには、数日から数週間かかることがあります。
では、今すぐにデータを確認したい場合はどうすればよいでしょう？
上記で説明した通り、Exceeded は、AppsFlyerが特定の日に、N+1のクリック（またはイベント）を受信した場合に発生します。その日の後半に重要なメディアソースからのデータを受信したために、それらがExceededとしてまとめられてしまう可能性もあります。その場合、Exceededの影響を最小限にとどめるためのシンプルな対策を以下でご紹介します。
ヒント
本日のデータではなく、昨日とそれ以前のデータのみを分析対象にしてください。データ集約プロセスは、毎日昨日のデータを再度計算し、過去のデータを対象に最小コホートのソースからExceededグループに割り当てていきます。これにより、クリックのオーバーフローによるデータの歪みを最小限に抑えられます。