概要： 一部の集計データがexceeded と表示される理由と、それを防止する方法にするについて記載しています。
What are exceeded dimensions?
AppsFlyerではインストールデータとイベントデータを収集して集計しており、そのデータは特定の項目を設定する一意の値として集計されます。 Data is aggregated using unique values populating a given dimension. The number of unique values in a dimension is called cardinality. Most analytics and aggregated reporting tools have cardinality limits per dimension. その結果、各項目内のユニークな値の数がカーディナリティの上限を超えてしまった場合には、残りのデータはexceededのグループに割り当てられます。 And when the number of unique values in the media source dimension exceeds the cardinality limit, the remaining media source data as well as all dimensions based on the remaining media sources are grouped in exceeded groups.
以下の例では、カーディナリティとそれがレポートにどのように影響するかを示しています。
例
Example A: Campaign ID cardinality limit
Campaign IDのカーディナリティ上限は3000です。特定の日において、計測されたCampaign IDの数が3000を超えた場合、残りのCampaign IDはすべてExceeded_CampaignID_Limitとしてグループ化 / 集計されます。
Example B: Events cardinality limit
- イベントのカーディナリティ上限が3であるとします。
- 特定の日に、A / B / C / D / E / F / Gという7つのユニークなイベントが記録されたとすると、このときイベントのカーディナリティは7になります。
- このとき、集計レポート内では、A / B / Cのイベントはそれぞれ別々に一覧に表示されますが、D / E / F / GのイベントはExceeded_Events_Limitにグループ化された状態で表示されます。 Events D, E, F, and G are grouped in the Exceeded_Events_Limit.
Exceeded dimensions and cardinality limits affect aggregate data as follows:
- Overview dashboard
- Aggregate data export and Pull API reports
- Master API reports
- Click and impression data in Activity and Custom dashboards
- Protect360 dashboard
ローデータレポートは、カーディナリティ上限の影響は受けないのでご安心ください。
データの大部分が exceededのグループに集計されてしまうと、相当量のデータの詳細が分からなくなってしまい、分析レポートが不正確な結果になってしまいます。 This can lead to imprecise results in analytics reports.
必要に応じて、ローデータを使ってカーディナリティの上限を受けない形でグループを作成しましょう。
The table that follows lists the cardinality limits per day, per app.
| ディメンション | Exceeded group name | Limit type per... | 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 |
|
| Campaign ID | Exceeded_CampaignID_Limit | メディアソース | 3000 |
|
| Channel | Exceeded_Channels_Limit | メディアソース | 20 | 20 |
| Site ID | Exceeded_SiteID_Limit | メディアソース | 1000** |
|
| イベント | Exceeded_Events_Limit | アプリ | 300 | Installs/in-app events: 300 |
| Keywords | Exceeded_Keywords_Limit | メディアソース | 1000 | - |
| メディアソース名 | Exceeded_MediaSource_Limit | アプリ | 1000 |
|
|
* If the number of unique values in the media source dimension exceeds the cardinality limit, the remaining media source data as well as all dimensions based on the remaining media sources are grouped in exceeded groups. ** See Exceeded_SiteID_Limit for more details and limits. |
||||
各項目（ディメンション）毎のカーディナリティ上限
Exceeded_AdSet_Limit と Exceeded_Ad_Limit
- メディアソース毎に、それぞれ最大1000個のユニークなアドセット名 (af_adset) とアド名 (af_ad) を利用可能です。
- 仮にExceeded が表示された場合には、1つまたは複数のメディアソースにて、キャンペーン名、サイトID、広告セット、広告などのパラメータに対して動的に値を振り当てている可能性があります。また、アプリのコード内で動的にアプリ内イベント名を作成して使用した場合にも、Exceeded_Events_Limit と表示されることがあります。
ヒント
"Divide and Conquer" again. 一般的なアドセット名（理想的には最大50個まで）をいくつか定義し、これまで使っていた全てのアドセット名を代わりにアド名へ割り当ててください。 （AppsFlyerの計測リンクにおける対象パラメータはaf_adsetです。）これにより、以下のことが可能になります：
1. Exceeded_AdSet_Limit や Exceeded_Ad_Limitの発生の防止
2.2. Efficiently optimize according to significant ad sets and ad traffic.
3. ローデータ内における、キャンペーン名やアドセット名に基づいた深い分析の実行
Exceeded_AdSetID_Limit と Exceeded_AdID_Limit
- メディアソース毎に、それぞれ最大1000個のユニークなアドセットID (af_adset_id) とアドID (af_ad_id) を利用可能です。
- 特定の日において、1001番目のサイトID以降はメディアソースごとの全てのサイトIDのデータがExceeded_SiteID_Limit という１つのグループに紐づきます。したがって、Exceeded_SiteID_Limit というサイトIDが表示されている場合、該当のメディアソースで使用されているサイトIDが多すぎることを意味し、このソースのトラフィックをサイトIDごとに最適化する際の精度と効率が低下してしまいます。
Exceeded_Campaign_Limit
- 1日あたり最大 3000 個のユニークなキャンペーン名 (c) を使用できます。
- 特定の日において、3,001番目のキャンペーンからは全てのキャンペーンデータが Exceeded_CampaignID_Limit というメディアソースに紐づきます。
ヒント
「細分化して克服」メディアソースごとに数千個のサイトIDを使用する代わりに、計測リンクに af_sub_siteid というサブサイトIDのパラメーターを使用してください。小数の一般的なサイトID（理想的には最大50個）を定義し、以前のサイトIDを全てサブサイトIDとして一般的なサイトIDの下に割り当ててください。これにより、次のことが可能になります：
1. Exceeded_SiteID_Limit を防ぐことができます。
2. 重要なサイトIDのトラフィックに基づいて効果的に最適化できます。3. ローデータ内のサイトIDとサブサイトIDに基づいて詳細な分析を実行できます。
Exceeded_CampaignID_Limit
- 1日あたり最大 3000 個のユニークなキャンペーンID (af_c_id) を使用できます。
- 特定の日において、3001個目のアドセットID以降は全てのアドセットIDのデータが Exceeded_Campaign_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) を使用してこれらのイベントを区別しましょう。 Use dynamic event values to differentiate between these events. アプリ内イベントのローデータを使うことで、イベント値のパラメータを使った最適化や、イベント値を基にした分析が可能になります。
- 不必要なアプリ内イベントのデータを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
Site ID (per clicks, impressions, installs, and in-app events) has 2 thresholds, 1000 and 5000.
- メディアソース毎に、1日あたり最大1000個のユニークなサイトID (af_siteid) を計測可能です。
- On a day, site ID information from the 1001st site ID and above per media source is grouped into a single site ID titled Exceeded_SiteID_Limit. Therefore, if you do see the site ID Exceeded_SiteID_Limit, it means there are too many used site IDs per the media source in question, and trying to optimize the source's traffic according to site IDs becomes less accurate and less effective.
- From August 19, 2024, if there are more than 5000 site IDs per day per media source, only 10 site IDs display. 特定の日において、1001個目のアドセットID以降は全てのアドセットIDのデータが Exceeded_AdSetID_Limit というグループに紐づき、同じことがアドIDの場合にはExceeded_AdID_Limit に適用されます。
ヒント
"Divide and Conquer". Instead of using thousands of site IDs per media source, which distorts your aggregate data, use a second parameter on your attribution links called af_sub_siteid. Define a small number of general site IDs (ideally up to 50), and assign all previous site IDs as sub-site IDs under these general site IDs. ）これにより、以下のことが可能になります：
1. Exceeded_Campaign_Limitの発生の防止
2. より有効なアドセット名のトラフィックの効果的な最適化
3. ローデータ内における、アドセット名やアド名に基づいた深い分析の実行
注意
リテンションレポートでは、Exceeded_SiteID_Limit は表示されませんが、全てのサイトIDが表示されるわけではありません。サイトIDはランダムに表示されますが、UIの制限により全てを表示することができません（上限を超えている場合）。この問題を回避するためには、リテンションデータをMaster APIから取得してください。
How to avoid getting exceeded sources?
長期的なソリューション
通常、ほとんどの広告主は3000個を超えるキャンペーン名を手動で定義することはないので、Exceededというキャンペーン名は表示されません。
If you do encounter Exceeded sources it's probably because one or more media sources is using dynamic values for names of campaigns, site IDs, ad sets, or ads. Dynamic in-app events within the app code may cause the Exceeded_Events_Limit source data to appear.
ヒント
Exceeded の表示を避けるためには、アプリ内イベント、キャンペーン、サイトID、広告セット、広告に静的な値のみを使用してください。
また、Exceededのタイプごとに特定のヒントを確認してください。
短期的なソリューション
長期的なソリューションの実装を完了するには、数日から数週間かかることがあります。
では、今すぐにデータを確認したい場合はどうすればよいでしょう？
上記で説明した通り、Exceeded は、AppsFlyerが特定の日に、N+1のクリック（またはイベント）を受信した場合に発生します。その日の後半に重要なメディアソースからのデータを受信したために、それらがExceededとしてまとめられてしまう可能性もあります。その場合、Exceededの影響を最小限にとどめるためのシンプルな対策を以下でご紹介します。
ヒント
本日のデータではなく、昨日とそれ以前のデータのみを分析対象にしてください。データ集約プロセスは、毎日昨日のデータを再度計算し、過去のデータを対象に最小コホートのソースからExceededグループに割り当てていきます。これにより、クリックのオーバーフローによるデータの歪みを最小限に抑えられます。