广告活动太多，管不过来了怎么办？
活动数量本身不是问题，说不清钱漏在哪一层才是。先按报表原始的定向类型与匹配方式看结构分布，再逐层下钻——它告诉你漏在哪层，但不替你决定结构怎么搭。
列表滚不到底，你只认得最上面那十几个
广告活动列表滚不到底。上面十几个你熟，名字是自己起的，预算改过好几轮；往下是自动活动、测试活动、旺季留下的活动、同事交接时说不清用途的活动——名字看不出意图，也不敢关，因为不知道关掉会掉多少单。真要动手时你其实只做两件事：把总花费和上周比一比，再把最贵的几个点开看看。剩下的每周照跑，从没被打开过。
为什么不好办
「太多」的代价不是花时间，是你不再逐个看
数量过了某条线之后，管理方式会悄悄换掉：从逐个判断变成看总数加抽查。这个切换发生得没有声音，你不会感觉到自己漏了什么——被漏掉的那部分本来就不出现在你眼前。所以「管不过来」的真实症状不是忙，是**你说不出自己有没有漏、漏在哪**。
先合并精简，是拿历史换整洁
第一反应通常是重搭：合并同类、按命名规范重建、把测试活动清掉。整洁是真的整洁，代价是每条被合并的活动的历史一起断了：**跨期对齐靠的是广告活动名、广告组、投放对象这些身份字段直接比对**，在平台上改了名或重建，前后就接不上——新结构好不好，得等新数据攒够才知道。更麻烦的是这一步跳过了诊断：如果钱不是漏在活动数量上，重搭一遍之后你会得到一批干净的、仍然在漏的活动。顺带说清这套东西的边界：它答得了**「你现在的结构漏在哪一层」，答不了「结构该怎么搭」**——后者没有能从报表里读出来的答案。
结构的问题不在活动列表这一维上
同一类定向散在十几个活动里，同一个活动里又混着几种匹配方式。「自动跑掉的钱是不是太多了」「广泛匹配占了几成」这类问题，在按活动排列的列表里没有对应的一行——不是藏得深，是那张表压根不是按这个维度切的。你要的那个分布，得跨活动汇总之后才存在。
活动越多，排行榜之外的部分越长
一次诊断装不下几千行，每一层都有上限：广告活动 50、投放 40、搜索词 60。活动多意味着三层的总量都更大，被挡在上限之外的比例也更高。入选口径不是只按花费排——花费 TOP、零订单花费 TOP、窗口内有执行记录的对象，三者取并集，第二项正是为长尾留的位置。但上限就是上限：**活动这一层的第 51 个，这一轮确实拿不到属于它的那条判断。**
该按什么顺序判断
- 01
先别看活动列表：钱在各类定向之间怎么分？
把所有投放按报表原始的「定向类型 | 匹配方式」分组，看花费、点击、订单在各组之间的分布。分组用的是报表里本来的写法，不做人为归类——看到的就是你实际的结构，不是某套模板认为你该有的结构。一个限定写在前面：这里的「结构」指定向类型与匹配方式两维，广告位（placement）这一维产品不做，要看得去后台。
- 02
每一类该放大、保持，还是收缩？
这一层的判断落成五选一：放大 / 保持 / 收缩 / 优化 / 暂停。先在这一层定方向，是因为它决定下面几层值不值得细看——如果整类自动投放该收缩，逐条去调它底下的出价，就是在给一个要缩的盘子做精装修。
- 03
往下一层：具体漏在哪个活动、哪个组？
方向定了再下钻：定向类型 → 广告活动 × 广告组 → 投放 → 搜索词。搜索词按触发它的那条投放挂上去，「这个词该去哪个组加否定」就变成能点开的一行。每层有自己的决策枚举——活动层是继续/加预算/降预算/优化/暂停，投放层是保留/提价/降价/暂停/拆分，搜索词层是收割/否定/提价/观察——因为这几层能做的动作本来就不是一回事，共用一套词只会把判断磨钝。
- 04
排行榜之外还剩多少？
逐条看完，再看被截掉的那批。投放和搜索词这两层有兜底：没入选的按广告活动 × 广告组汇总成长尾泄漏行，带上未展示对象数、合计花费、零订单花费及其占比，照样落一条组级的可执行判断。所以「这个组该整体收紧，还是挑几条逐条否定」在这里能有答案。活动这一层没有这个兜底，下一节单说。
- 05
这些活动只服务一个产品吗？
活动一多，一个活动服务多个 ASIN、一个词在两个产品下都在跑，就成了常态。这类重叠会被代码按共享实体分组打上标签，因为在单产品视角下它不可见：A 的判断说这个词该收割，B 的说该否定，两条单看都成立，你会两条都做。最后还有一个只在全店视角才存在的问题——预算该从哪款收回、投到哪款去。
产品在这件事上做了什么
- 投放结构按报表原始的「定向类型 | 匹配方式」分组，不做人为归类——看到的就是你实际的结构，不是某套模板认为你该有的结构。
- 结构这一层给出放大 / 保持 / 收缩 / 优化 / 暂停的五选一判决，和活动层、投放层、搜索词层各自的决策枚举分开，因为这几层能做的动作不是一回事。
- 被截断的投放和搜索词不丢弃：按广告活动 × 广告组汇总成长尾泄漏行，带未展示对象数、合计花费、零订单花费及其占比，照样落一条组级可执行的判断。
- 跨 ASIN 共用同一个广告活动、或同一个词在两个产品下都在跑，会被代码打上冲突标签。标记器只贴标签，不替你裁决。
- 组合层是所有单 ASIN 判断之后独立的一次汇总调用，只回答按 ASIN 切片看不见的那个问题：预算该从哪款收回、投到哪款去。只有成功诊断的 ASIN 多于一个时才跑。
广告活动这一层没有长尾泄漏行——超出上限的活动确实拿不到判断
投放和搜索词被截断时有兜底：没入选的按广告活动 × 广告组汇总成泄漏行，组级判断照给。广告活动这一层没有这层兜底。上限是 50，超出的部分只出现在一条截断说明里——未逐条展示 N 个、合计花费多少、订单多少——它们不会各自拿到一条判断。
这条截断说明本身会进模型的输入，所以模型知道自己看到的不是全部，总评不会建立在「这就是全部活动」的假设上。但你想要的那句「第 51 个活动该不该关」，这一轮确实没有。能确定的只有入选口径：花费 TOP 50、零订单花费 TOP、以及窗口内有执行记录的活动——你上一轮动过的活动一定在场，因为诊断必须看得见自己上次动作的对象，否则它会把自己造成的变化当成趋势。
把这条边界写在这里，是因为反过来那种做法更糟：给每个活动都凑一条判断，看上去覆盖满了，实际是拿没看过的数据编的。同样的原则贯穿整套判决——覆盖率是校验并记录，缺哪条判决就记一条警告，不会静默补一条上去。你能分清「产品判过、结论是保持」和「产品根本没看这一行」，这个区别比一个好看的覆盖率数字重要得多。