概要：本文解释了汇总数据中某些维度显示为exceeded（超限）的原因，以及避免数据超限的方法。
超限维度的含义
AppsFlyer会收集您的激活和事件数据并对其进行汇总。数据汇总的原理是将唯一值填充到给定的维度，而某个维度中唯一值的数量即称为基数（Cardinality，在数据表中体现为行数）。大部分的数据分析及汇总工具都有分维度的行数限制。当某个维度中的唯一值数量超出该限制时，超出部分的数据就会被另行分组为exceeded（超限），单独分行显示。当媒体渠道维度中的唯一值数量超出行数限制时，剩余的渠道数据，包括所有相关维度的渠道细分数据都会被归到exceeded分组下。
关于行数限制对具体报告的影响，请见下文示例。
示例
示例A：广告系列ID的行数限制
广告系列ID的行数限制为3000行。也就是说，如果某天上报的广告系列ID数量超过3000，则超出部分的广告系列ID会被另行分组为Exceeded_CampaignID_Limit，单开一行显示。
示例B：事件的行数限制
- 假设相关事件的行数限制为3行。
- 某天上报的独立事件数量为7，分别是A、B、C、D、E、F 和 G。换句话说，此时事件维度下有7个唯一值。
- 汇总报告中会分别列出事件A、B、和C，而事件D、E、F和G会被一起归到Exceeded_Events_Limit一行中。
维度值超限以及行数限制会影响到下列汇总数据：
- 数据总览面板
- 汇总数据导出和Pull API报告
- Master API报告
- 活跃数据和自定义面板中的点击和展示数据
- Protect360面板
原始数据不受行数限制的影响。
如果您的大部分数据都被归到exceeded分组内，表示这些数据并没有得到细分，致使分析报告的结果不够精确。您可以根据实际需求，使用原始数据来创建没有行数限制的分组。
下表列出了单个应用每天的数据行数限制。
| 维度 | 超限数据的分组名称 | 限制类型的维度 | 每天的数据行数限制 | Protect360每日数据行数 |
|---|---|---|---|---|
| 广告 | Exceeded_Ad_Limit | 媒体渠道 | 1000 | - |
| 广告ID | Exceeded_AdID_Limit | 媒体渠道 | 1000 | - |
| 广告组 | Exceeded_AdSet_Limit | 媒体渠道 | 1000 | - |
| 广告组ID | Exceeded_AdSetID_Limit | 媒体渠道 | 1000 | - |
| 广告系列 | Exceeded_Campaign_Limit | 媒体渠道 | 3000 |
|
| 广告系列ID | Exceeded_CampaignID_Limit | 媒体渠道 | 3000 |
|
| 流量入口（Channel） | Exceeded_Channels_Limit | 媒体渠道 | 20 | 20 |
| 子渠道ID | Exceeded_SiteID_Limit | 媒体渠道 | 1000** |
|
| 事件 | Exceeded_Events_Limit | 应用 | 300 | 激活/应用内事件：300 |
| 关键词 | Exceeded_Keywords_Limit | 媒体渠道 | 1000 | - |
| 媒体渠道名称* | Exceeded_MediaSource_Limit | 应用 | 1000 |
|
|
*当媒体渠道维度中的唯一值数量超出行数限制时，剩余的渠道数据，包括所有相关维度的渠道细分数据都会被归到exceeded分组下。 **详情请见Exceeded_SiteID_Limit部分的说明。 |
||||
每个维度的数据行数限制
Exceeded_AdSet_Limit and Exceeded_Ad_Limit
- 每个媒体渠道下，独立广告组名称的数量上限为1000个，独立广告名称的数量上限也是1000。
- 也就是说，任意一天内，从第1001个开始的所有广告组信息都会被归到名为Exceeded_AdSet_Limit的渠道分组下。同理，超限广告的信息会被归到名为Exceeded_Ad_Limit的渠道分组下。
提示
出现超限情况时，可以使用“分治法”来解决数据细分问题。具体方法为：设置少量通用广告组名称（最好不超过50个），然后将之前所有的广告组名称作为单个广告的名称，放到新设置的通用广告组名称下。您也可以在AppsFlyer归因链接中使用 af_sub参数来解决此问题。这一方法可以帮助您：
1. 防止数据表中出现Exceeded_AdSet_Limit 或Exceeded_Ad_Limit分组。
2. 根据重要的广告组和广告流量有效优化投放。
3. 根据原始数据中的广告组和广告名称进行深度分析。
Exceeded_AdSetID_Limit和Exceeded_AdID_Limit
- 每个媒体渠道下，独立广告组ID的数量上限为1000个，独立广告ID的数量上限也是1000。
- 也就是说，任意一天内，从第1001个开始的所有广告组ID信息都会被归到名为Exceeded_AdSetID_Limit的渠道分组下。同理，超限广告ID的信息会被归到名为Exceeded_AdID_Limit的渠道分组下。
Exceeded_Campaign_Limit
- 一天内独立广告系列名称的数量上限为3000个。
- 也就是说任意一天内，从第3001个开始的所有广告系列都会被归到名为Exceeded_Campaign_Limit的渠道分组中。
提示
解决方法如下：设置少量通用广告系列名称（最好不超过300个），然后将之前所有的广告系列名称作为广告组的名称，放到新设置的通用广告系列名称下。您也可以在AppsFlyer归因链接中使用 af_sub参数来解决此问题。这一方法可以帮助您：
1. 防止数据表中出现Exceeded_Campaign_Limit。
2. 根据重要的广告组流量有效优化投放。
3. 根据原始数据中的广告系列和广告组名称进行深度分析。
Exceeded_CampaignID_Limit
- 一天内独立广告系列ID的数量上限为3000个。
- 也就是说任意一天内，从第3001个开始的所有广告系列ID都会被归到名为Exceeded_CampaignID_Limit的渠道分组中。
Exceeded_Channels_Limit
- 一天内每个渠道下独立流量入口名称的数量上限为20个。Protect360中该维度的数量限制是1000个。
- 也就是说任意一天内，从第21个开始的所有流量入口都会被归到名为Exceeded_Channel_Limit的渠道分组中。
Exceeded_Events_Limit
- 一天内独立事件名称的数量上限为300个。
- 也就是说任意一天内，从第301个开始的所有事件名称都会被归到名为Exceeded_Events_Limit的分组中。
提示
如需解决超限问题，使数据表中不再出现Exceeded_Events_Limit分组，可使用以下方式：
- 配置富应用内事件。设置少量通用事件名称（最好不超过20个），减少独立事件的上报数量。使用动态事件值来区分这些事件。这样您就可以根据事件值参数来优化投放，并使用应用内事件原始数据报告中的事件值进行数据分析。
- 利用验证规则，将多余的应用内事件从AppsFlyer平台中移除。
示例
您有一个名为com.greatapp的应用，该应用针对每种已出售的袜子颜色发送一个购买事件，如buy_red_socks、buy_blue_socks、buy_white_socks等等。为了避免上报过多的独立事件，您使用单个事件名buy_socks来概括这些事件，并将袜子颜色信息作为一个事件参数添加到该购买事件中。
Exceeded_Keywords_Limit
- 一天内每个渠道下独立关键词的数量上限为1000个。
- 也就是说，任意一天内，从第1001个开始的所有关键词信息都会被归到名为Exceeded_Keywords_Limit的渠道分组下。
Exceeded_MediaSource_Limit
- 一天内独立媒体渠道名称的数量上限为1000个。
- 也就是说任意一天内，从第1001个媒体渠道开始，所有渠道的投放信息都会被归到名为Exceeded_MediasSource_Limit的渠道分组中。
Exceeded_SiteID_Limit
子渠道ID（分点击、展示、激活和应用内事件）有2个限值：1000和5000。
- 一般情况下，一天内每个渠道下独立子渠道ID的数量上限为1000个。
- 也就是说任意一天内的单个媒体渠道下，从第1001个开始的所有子渠道ID都会被归到名为Exceeded_SiteID_Limit的子渠道分组中。因此，如果您的数据表中出现名为Exceeded_SiteID_Limit的子渠道ID，即表示相关渠道下的子渠道ID数量超限，此时若针对子渠道ID进行流量优化，其准确性和有效性会有所下降。
- 从2024年8月19日起，如果一点内单个媒体渠道下的子渠道ID数量超过5000个，则数据表仅显示其中的10个子渠道ID。剩余的所有子渠道ID都会被归到一个名为Exceeded_SiteID_Limit的子渠道ID下。
提示
出现超限情况时，可以使用“分治法”来解决数据细分问题。建议您在归因链接中增加一个名为af_sub_siteid的参数，避免在一个渠道下出现上千个子渠道ID，导致汇总数据失真。您可以设置少量通用的子渠道ID（最好不超过50个），然后将之前所有的子渠道ID作为次级子渠道ID，放到这些通用子渠道ID下。这一方法可以帮助您：
1. Prevent seeing Exceeded_SiteID_Limit
2. 根据重要的子渠道流量有效优化投放。
3. 根据原始数据中的子渠道ID和次级子渠道ID进行深度分析。
注意
查看留存报告时，即使其中不包含Exceeded_SiteID_Limit也不表示该报告已呈现所有的子渠道ID。当子渠道ID数量超限时，面板会随机显示子渠道ID。若使用Master API获取留存数据，即可克服这一限制。
避免数据超限的方法
长期方案
正常情况下，大部分广告主不会手动设置超过3000个广告系列，因此不会在数据表中看到Exceeded这个数据超限分组。
如果您遇到了Exceeded超限分组，很可能是因为您的一个或多个渠道在广告系列名称、子渠道ID、广告组名称或广告名称中使用了动态值。应用代码中的动态应用内事件也可能会导致事件数量超限，并产生Exceeded_Events_Limit超限分组。
提示
建议在应用内事件、广告系列、子渠道ID、广告组和广告名称中仅使用静态值，避免出现Exceeded数据超限分组。
另请参见上文针对各个Exceeded超限分组的具体解决方式。
短期方案
长期方案的实施可能需要数天到数周的时间。
在此期间，如需解决当前的数据超限问题，可参考下文说明。
如前文所述，当AppsFlyer在一天内收到N+1个点击（或事件）带量渠道时，数据表中就会出现Exceeded超限分组。这时有可能发生这样的情况：某个较为重要的渠道由于数据送达时间较晚而被归到Exceeded超限分组中。这种情况下，您可以使用以下方式来减轻Exceeded分组带来的影响：
提示
忽略当天数据，仅查看前一天及之前的数据。AppsFlyer的数据汇总流程每天都会重新计算前一天的数据，并将流量最小的（而非数据到达最晚的）渠道归到Exceeded分组中。这样就能在数据超限的情况下，尽可能地减少结果失真所产生的影响。