2024 年 3 月，我帮一个做家居品类的亚马逊卖家复盘他们的广告账户，年投放预算大约 180 万美金。团队有三个人专职盯广告，每天出一份 40 行的广告报表，每周开一次 90 分钟的广告会。我第一次旁听那场会，会议结束时落地的行动只有两条：加两个否定词、把两组广告活动的预算各降 20%。三周后我回访，同样的 40 行报表里，有 27 行的核心指标几乎没有变化，下降的 ACOS 又涨回来了，被降预算的活动曝光量掉了 38%，但转化并没有转移到其他活动上。
问题不出在数据，出在数据到动作之间那一截断掉的链路。广告报表告诉你"发生了什么"，但它不会告诉你"这件事归谁、什么时候必须处理完、处理完怎么验证、没处理会怎样"。这正是软件规划方法能帮上忙的地方：把广告异常当成软件缺陷来对待，用问题清单（Issue List）承接它，让每一个广告问题都有编号、有状态、有负责人、有验收标准、有复燃监控。
这篇文章想讲清一件事：亚马逊广告管理和问题清单的衔接点，不是"把报表搬进工具"，而是把广告异常重新建模成一个有生命周期的对象。下面会拆开讲核心结论、真实场景、常见误区、判断逻辑、以数跨境为例的数据实践，以及不同团队规模下该怎么落地和怎么取舍。
先把结论摆出来，后面的内容都在展开这四条。
广告报表是一个状态快照，它的时间属性是"过去 7 天""过去 14 天"。问题清单是一个任务队列，它的时间属性是"截止到今天几点""已经挂了多少天"。这两者的时间语义完全不同，很多人做工具衔接时最大的错误就是试图用一张报表同时承担这两个职责。
我见过太多团队把广告后台导出的 Excel 加一列"备注"，就认为这就是问题清单。备注列里写着"待优化""观察中""已处理"，这些词没有责任主体，没有时间边界，也没有验收标准，一周之后没人能说清哪些真的处理完了。
一个合格的广告问题条目，必须能让一个完全不熟悉这个账户的人，在 30 秒内判断出：这是谁的问题、卡在哪一步、下一步做什么。
广告管理到问题清单之间有三个典型的断裂带，我在多个卖家团队里反复见到同一套模式。
这三个断裂带叠加起来，就是"报表看得很勤、账户就是不见好"的根本原因。
不管你用什么工具，广告问题条目至少要包含六个字段。缺哪一个，闭环就会在那里断掉。
| 字段 | 作用 | 缺失后的典型症状 |
|---|---|---|
| 问题类型 | 区分是出价、结构、Listing、库存还是竞争问题 | 所有问题都被当成"降 ACOS"处理 |
| 触发依据 | 记录是哪个指标、哪个阈值、哪个时间窗触发的 | 复盘时无法判断规则是否合理 |
| 责任主体 | 明确到人，而不是明确到岗位 | 多人负责等于无人负责 |
| 处理截止时间 | 给出 SLA，通常 24 小时到 5 个工作日 | 问题长期挂在"处理中" |
| 验收标准 | 写清什么状态算关闭，比如"该词 7 天 ACOS 低于 25%" | 关闭靠感觉，复燃率极高 |
| 复燃监控窗口 | 关闭后继续观察 7 到 14 天 | 关了又开，问题反复出现 |
我把这套方法的核心动作叫"问题对象化"。它的意思是：不要让广告异常停留在一句话、一个备注、一次会议纪要里，而是把它实例化成一条有唯一 ID 的记录。
这条记录一旦存在，它就有了三个属性：可被检索、可被指派、可被统计。可被检索意味着三个月后你能查"所有因为广告位调整导致的问题最后都怎么处理的"；可被指派意味着每个问题都有唯一负责人；可被统计意味着你能算出问题老化中位数、复燃率、人均处理量这些运营指标。
没有对象化，前面三个断裂带一个都补不上。
我做过一次比较粗糙但很有说服力的记录。在一场标准的周度广告复盘会上，我按分钟标注了内容类型，连续记了四周。四周平均下来的时间分配是这样的：
四周里，形成具体行动的时间平均每周 10.5 分钟，占 90 分钟的 11.7%。而同一账户当周的广告花费是 3.4 万美金，折算下来每分钟会议时间对应约 380 美金广告预算。
这不是在说会议开得不好，而是说当问题没有被对象化，会议的第一功能就变成了"对齐事实"，而不是"推进动作"。
同一个"某关键词表现差"的现象，在三个角色眼里是三件不同的事。
如果这三个视角没有被写进同一条问题记录里，结果就是：广告投放员按自己的理解降了价，运营觉得问题没解决，供应链完全不知道发生了什么。三周后这个 SKU 断货，广告活动空烧，谁也没有做错自己分内的事。
问题清单的一个隐性价值，是强迫跨角色在同一条记录上写下各自的判断依据。写下来的过程本身就是对齐。
很多团队从 Excel 起步，这没问题。问题出在规模。
当一个账户每周产生 60 到 100 个广告问题时，Excel 会同时暴露三个硬伤：没有状态机（无法知道谁在处理中）、没有审计日志（无法知道谁在什么时候改了什么）、没有提醒机制（无法让问题自动浮上来）。
微信群部分弥补了提醒，但引入了新的问题：讨论内容和处理结果散落在聊天记录里，三个月后无法检索，也无法统计"哪类问题处理得最慢"。
我的经验阈值是这样的：当广告问题周均超过 40 条，或者同时管理的广告账户超过 3 个，Excel 加群聊的组合就开始产生明显的管理成本。这个数字不是绝对标准，但多次验证下来比较接近拐点。
这里有一个很关键的架构判断：广告数据层和问题管理层，应该是两层，不应该混在一起。
数据层的职责是：接入亚马逊广告 API、广告后台报表、业务报告、库存数据，做口径统一、时间对齐、指标归集。它面向的是"事实"。
问题层的职责是：接收触发信号、生成问题条目、驱动状态流转、记录处理结果、统计数据指标。它面向的是"动作"。
混在一起的后果是：每次改一个问题模板，就要重新拉一遍数据；每次改一个数据口径，历史问题记录全部失真。我在一个中型卖家那里见过这种耦合的代价，他们把问题备注直接写在数据透视表的单元格里，后来换了一版指标定义，三千多条历史问题的上下文全部作废。
最普遍的做法是：在广告报表里加一列"状态"，用下拉菜单选"待处理/处理中/已完成"。看起来像问题清单，实际上不是。
根本差别在于：报表是周期性重建的快照，问题清单是持续累积的日志。报表下周重新生成时，上周的状态列会怎样？绝大多数团队的答案是，被覆盖了。于是"这个问题上周处理到哪一步"这个问题永远没有答案。
更隐蔽的问题是：报表的行是"关键词"或"广告活动"，而问题的行应该是"问题本身"。一个关键词可能同时触发三个问题：出价过高、否定词缺失、Listing 主图与搜索意图不匹配。用报表行当问题行，三个问题会被压缩成一个，处理其中一个就算"关闭"了。
红色代表紧急、黄色代表观察、绿色代表完成。这套颜色系统在个人使用时很舒服，在团队协作时几乎必然失效。
原因很简单：颜色没有定义"进入条件"和"退出条件"。什么情况下从黄变红？谁有权把红改成绿？改成绿之后还需要继续观察吗？没有这些定义，颜色就变成了主观表达，而主观表达在跨人协作时会迅速退化，所有人都会倾向于把问题标成绿色。
状态机的核心不是状态名称，而是状态迁移的条件。没有迁移条件的颜色，只是情绪。
这是我最常看到的结构性缺陷。团队把问题清单限定在"广告问题"范围内，结果所有根因在广告之外的异常，都无法进入闭环。
典型的例子：某个词的点击率从 0.42% 掉到 0.18%，广告侧看起来是"素材疲软"，实际上是对手在主图上加了一个更强的卖点标识。这个问题如果只能记录在广告问题清单里，负责人会把时间花在调整出价和匹配方式上，而正确的动作是更新主图。
我的做法是：问题清单的类型字段必须允许"跨域"，并且在问题条目里强制填写"根因归属域"。根因归属域可以是广告、Listing、价格、库存、竞争、评价。一旦填了这个字段，问题就能自动路由到正确的负责人队列。
绝大多数团队用 ACOS、ROAS、CTR 衡量广告健康度，很少有人用"问题老化中位数"衡量管理健康度。
我建议加三个管理指标：
这三个指标不直接改善广告效果，但它们决定了广告优化动作能不能持续积累。一个每周只解决 10 个问题但复燃率 5% 的团队，长期表现会明显好过每周解决 30 个问题但复燃率 40% 的团队。
下面是我实际用过、并且在不同规模团队里调整过的建模方法。分四层，从数据字段到规则到验收。
先给出一条问题记录的完整字段。下面是我常用的一版结构，用 YAML 表示，实际落地时可以映射到任何工作流工具的自定义字段。
issue:
id: ADV-20240612-0037
type: bid_structure # 出价结构 / listing / stock / price / review
root_cause_domain: listing # 根因归属域，用于路由
trigger:
metric: ctr
window: 7d
threshold: 0.20 # 低于 0.20% 触发
baseline: 0.42 # 前 28 天均值
deviation: -57% # 偏离幅度
scope:
campaign_id: C-8823
ad_group_id: AG-11902
keyword: "kitchen organizer rack"
owner: "运营-王" # 必须是人，不是岗位
due_at: 2024-06-15T18:00:00
acceptance:
metric: ctr
window: 7d
target: ">= 0.30%"
reopen_window: 14d
status: in_progress
history:
{at: "2024-06-12T09:10", by: "system", action: create}
{at: "2024-06-12T11:02", by: "运营-王", action: assign, to: "设计-李"}
{at: "2024-06-13T16:40", by: "设计-李", action: comment, note: "主图已替换"}
这里有几个设计要点值得说明。id 必须是可读的稳定标识，不能用自增数字，因为跨表引用和口头讨论都需要它。history 必须只追加不覆盖，这是后续复盘唯一可信的依据。
trigger 里我坚持保留 baseline 和 deviation 两个字段，而不是只存一个阈值。原因是在复盘时，"偏离了多少"比"是否越线"更有信息量。
我用六个状态，不多不少。
其中"待验证"这个状态是最容易被省略、也最不该省略的。没有它，问题的关闭就变成了"我觉得改好了"，而"我觉得"在跨人协作里几乎等同于"我不确定"。
这张图也解释了一个常见困惑：为什么问题 SLA 不能随便压到 24 小时？因为验证窗口本身就要 3 到 5 天。真正该被压缩的是"新建"到"已确认"这段，也就是 6.2 小时加 14.5 小时那部分。
从单阈值到复合规则，是这套方法能不能规模化的分水岭。
单阈值规则的问题是误报率极高。比如"CTR 低于 0.2%"这一条，会因为曝光量太小而频繁误报，某个词只曝光 12 次、点击 0 次，CTR 是 0，但这毫无意义。
我的做法是引入三个约束条件：最小样本量、持续时间、复合条件。
rule:
name: "高曝光低CTR-需修改Listing"
all_of:
metric: impressions
window: 7d
operator: ">="
value: 3000 # 样本量约束，过滤小曝光噪音
metric: ctr
window: 7d
operator: "<"
value: 0.20
metric: ctr_deviation_vs_28d
operator: "<"
value: -0.40 # 相对自身基线下跌超 40%
metric: orders
window: 7d
operator: "<"
value: 3
sustained: 3d # 连续 3 天满足才触发
route_to: "listing_queue" # 自动路由到 Listing 队列
suppress_if:
stock_days_remaining < 30 # 临近断货时抑制此类问题
引入 sustained 这个字段之后，我观察到的误报率下降非常明显。下面这组数据来自一个中型卖家的实测对比，覆盖 6 周。
11% 的漏报率听起来不理想，但在广告场景里，误报的代价远高于漏报。误报会消耗人的注意力并让人放弃使用问题清单，漏报只是少发现几个问题，而人类本来就会用别的方式发现它们。
验收标准必须写在问题创建时，而不是关闭时。这是我在踩过坑之后最坚持的一条。
原因在于：如果验收标准是关闭时才写的，写的人会有强烈的动机把标准定得刚好能被满足。这也是复燃率居高不下的主要原因。
验收标准的写法我建议用三段式：指标 + 观测窗口 + 目标区间。例如"目标关键词 7 天滚动 ACOS 落在 18% 到 25% 之间"。用区间而不用单点，是为了避免"刚好压到阈值就关闭"这种行为。
回滚是很多人没考虑的一环。问题关闭后，如果复燃，不应该新建一个问题，而应该把原问题从"已关闭"改到"已复燃"，并保留完整历史。这样复燃率才能被正确统计，也才能回答一个更有价值的问题：哪一类处理方式最容易复燃？
这是一个纯工程问题，但影响很大。亚马逊广告 API 的数据有延迟，广告报表通常 T+1 到 T+2 可用，部分指标可能延迟更久。
我的建议是把触发频率和数据新鲜度解耦：
这三条的核心逻辑是：广告问题的处理窗口以天为单位，不以小时为单位。为了实时性牺牲数据完整度，得不偿失。
这一节讲具体落地。前面讲的建模，需要有人把亚马逊广告数据接进来、把口径统一、把指标算出来，问题清单层才能拿到干净的触发信号。我把这个环节放在"数跨境"这类跨境电商数据工具里完成，然后问题清单层用通用的工作流工具承接。
数据接入这一步，最耗时的从来不是接口对接，而是口径统一。
举一个非常具体的问题：ACOS 的分母是什么？最常用的有两种口径，广告销售额（attributed sales）和总销售额（total sales）。同一组数据，前者的 ACOS 可能是 32%，后者可能是 8%。
如果触发规则的阈值是按 32% 这个口径设的，但看报表的人习惯看 8% 这个口径，那么每一次问题复盘都会退化成口径争论。这正是前面那幅会议时间分布图里"数据校准与口径争论"占 22 到 31 分钟的原因。
在用数跨境的流程里，我通常会把这一步固化成三件事：
acos_attributed_7d、acos_total_7d，两个都保留，不合并。这三件事做完，讨论的起点就从"这个数字怎么算的"变成了"这个数字说明什么"。
规则层我一般按四类问题分别配置，每一类有独立的触发条件和路由目标。
| 问题类型 | 主要指标 | 典型触发条件 | 默认路由 |
|---|---|---|---|
| 出价与结构 | ACOS、CPC、曝光份额 | 7 天 ACOS 超目标 1.3 倍且曝光量 ≥ 2000 | 广告投放队列 |
| Listing 内容 | CTR、转化率、搜索词匹配度 | CTR 相对 28 天基线跌 40% 且曝光 ≥ 3000 | Listing 运营队列 |
| 库存联动 | 可售天数、广告花费环比 | 可售天数 < 30 且广告花费环比上升 | 供应链队列 |
| 价格与促销 | 转化率、Buy Box 占有率、价格指数 | 转化率跌 30% 且竞品均价降幅 > 5% | 定价队列 |
这里有个我反复验证的经验：每一类问题的触发条件里，至少要有一个"非广告指标"。否则问题会永远在广告侧打转。比如库存联动那一类，触发条件里的"可售天数"就完全来自供应链数据。
问题清单层我不建议用广告工具自带的备注功能，也不建议继续用表格。这一层需要的是状态机、权限、提醒、历史和统计能力，这些恰好是通用工作流工具或者项目管理工具的标准能力。
实际做法很直接：把工作流工具的自定义字段映射成前面那套问题实体结构，用自动化规则把数据层产出的触发信号转成问题条目。常见的映射方式是这样：
我见过不少团队在这一步选型时纠结，其实判断标准很简单：看这个工具能不能给同一个问题类型配置不同的状态机。如果所有类型的任务共用一套状态，那么 Listing 类问题会永远卡在"待验证"，因为它的验证窗口天然比出价类问题长得多。
复盘不应该是重新看一遍广告报表，而应该是看问题清单本身的统计。
我每周看的四个数字：
这四个数字放在一起看，比任何一张广告效果报表都更能说明一个团队的管理水平。
下面这组数据来自一个中型卖家（3 个北美站点、4 个欧洲站点，月广告花费约 11 万美金）的六周实践记录。起始状态是 Excel 加群聊，第三周切换到数据层加问题清单层的结构。数据为实际记录，部分指标做了脱敏处理。
这两个图放在一起看，最有意思的一点是：实践后 2 到 7 天完成的问题占比从 34% 上升到 62%，而 15 天以上的僵尸问题从 33% 降到 6%。平均值改善只是结果，分布形态的改变才是原因。原来的团队不是处理慢，而是大量问题被遗忘在某个角落，永远没人碰。
下面按广告花费规模和团队结构分四档，给出我认为比较务实的起点。每一档的目标不是"做完整套方法"，而是"先补上最致命的那一个断裂带"。
这个阶段不建议上任何专门的问题管理系统，成本不划算。核心动作只有三个：
这个阶段衡量指标只需要一个：一周结束时，还有多少条问题没有明确负责人。这个数字应该接近 0。
这一档开始需要结构化的数据层。核心动作：
这一档最容易犯的错误是过度自动化。我的建议是：触发可以自动，分派可以自动，关闭必须人工。自动关闭会掩盖大量改了但没效果的问题。
到这一档，问题的复杂度不再是"发现问题"，而是"跨站点、跨角色、跨时区协调"。
关键动作：
这一档还有一个经常被忽略的动作：把问题清单的统计结果反向输入到广告预算分配里。如果一个站点长期问题老化最长、复燃率最高，那它的广告预算增长就该被谨慎对待，因为管理带宽跟不上投放规模。
品牌卖家的特殊之处在于：广告问题的根因有很大比例在产品内容和品牌层面，而不在流量层面。
我服务过的一个品牌卖家，在问题清单里专门给"品牌资产类问题"开了一条路径，触发条件包括品牌搜索量下滑、品类词自然排名下降、Review 评分跌破 4.2。这类问题的处理周期往往以月计，不适合放在普通广告问题的 SLA 里。
他们的做法是把问题清单分成两个时间尺度：周级队列（广告、价格、库存）和月级队列（内容、品牌、品类结构）。两条队列共用同一套问题实体字段，但状态机的超期定义完全不同。周级队列超过 5 天算超期，月级队列超过 30 天才算超期。
方法本身不难，难的是知道自己该放弃什么。下面是我认为最需要提前想清楚的四个取舍。
这个取舍的标准不是团队大小，而是问题规则的稳定程度。
| 判断维度 | 倾向自建 | 倾向采购现成工具 |
|---|---|---|
| 触发规则复杂度 | 规则高度定制，涉及多源数据交叉 | 规则以单指标阈值为主 |
| 团队技术能力 | 有稳定的数据或研发资源 | 没有专职技术人手 |
| 问题量级 | 周均 200 条以上，值得投入 | 周均 100 条以下，人工可控 |
| 迭代频率 | 规则每月都在调整 | 规则半年内基本不变 |
| 数据敏感性 | 数据不愿出内网 | 接受 SaaS 托管 |
我的实际经验是：优先采购问题清单层，优先自建触发规则层。因为问题清单层的通用性很强，自己造轮子收益有限；而触发规则层高度依赖你自己的品类、季节性和竞争格局，通用工具很难覆盖。
自动化这一步，我建议按"越靠近数据越自动，越靠近决策越手动"的原则。
把关闭动作留给人，是因为关闭这个动作本身就承载了"我认为它解决了"这个判断。一旦系统自动关闭，这个判断就消失了，复燃也就变成了两个独立问题。
粒度太粗，一个问题里塞十个关键词，处理起来无从下手；粒度太细，一个账户每周产生上千条，人力根本处理不完。
我的经验规则是按"处理动作的一致性"来决定粒度：如果同一个修改动作能同时解决几个对象，就把它们合成一条问题；如果需要不同的修改动作，就拆开。
举例：某个广告组里 8 个长尾词都表现为高曝光低转化，处理动作都是加否定，那就合成一条"广告组 AG-11902 长尾词否定清理"。但如果其中 3 个词的问题是出价过高、另外 5 个是匹配方式不当，就应该拆成两条。
最后一个取舍：要不要用实时数据。
我的答案是：广告问题清单不用实时数据，用 T-1 完整数据。原因是广告的自然波动很大，单日数据噪音极高。用 T-1 数据加 7 天滚动窗口，稳定性和可解释性都远好于实时数据。
唯一需要用近实时数据的场景是"花费异常"，比如某活动在 6 小时内花掉了日预算的 80% 而订单为 0。这类问题用轻量通道单独处理，阈值设得保守一些，只作为提示，不作为正式问题条目。
这个取舍的实际收益是：触发规则的误报率能下降大约三分之一，因为绝大多数日内波动在 T-1 周窗口下会被自动平滑掉。
把整篇文章压缩成三句话：
第一，亚马逊广告管理的瓶颈不在数据获取，而在数据到动作之间的三段断链，指标、责任和时间。补这三段，比多接一个数据源有价值得多。
第二，问题清单的价值不在记录问题，而在把问题对象化。一旦问题有了唯一 ID、状态机、责任人和验收标准，它就能被检索、被指派、被统计，三个断裂带才补得上。
第三，数据层和问题层必须分开。数据层用跨境电商数据工具做口径统一和指标归集，问题层用通用工作流工具做状态流转和统计，中间用触发清单连接。混在一起，任何一边的调整都会污染另一边。
如果你现在就要动手，我建议按这个顺序走：
最后提醒一句：这套方法的收益不会在第一个月显现。前两周问题数通常会上升，因为此前被忽略的异常开始浮出来。真正能感受到差别，往往是在第六周，当你能说清"上周有多少问题、谁在处理、平均花了几天、有几条又回来了"的时候，那一刻你才真正拥有了一个可持续优化的广告体系，而不只是一堆看起来还不错的报表。
我做亚马逊广告运营有一年多了，每周复盘的时候最头疼的就是广告后台看一套数据，问题清单里记的是另一套，开会两边对不上，最后变成念报表。我也试过让助理把广告报告直接贴进清单，结果清单变成了报表副本，没人愿意看。所以特别想知道，这两件事的衔接点到底在哪。
衔接的核心不是把广告报表搬进问题清单，而是把广告决策里所有未完成的事抽出来，变成有对象、有动作、有负责人的条目。每条问题必须能落到一个具体广告对象（广告活动、广告组、关键词或ASIN）和一个动作（加词、否词、调价、调预算、改结构），落不到的一律不进清单，这是第一道筛子。
实操上设三个衔接点：一是广告报表出现异常，比如某关键词ACOS连续高于目标、某活动预算日耗尽时间提前，这时自动或人工生成问题条目并带上广告对象ID；二是条目在清单里被指派、排期、跟进状态；三是处理完成后把动作和动作前后的数据回写到条目里，下次复盘同一指标时能直接看到上次谁改了什么。
日期口径要分开记，发现日和处理日不是一个东西，用广告后台的日期区间做数据基准，用清单的日期做响应时效基准，混在一起算就永远扯不清。
我刚开始做清单的时候，想着越细越好，每个高ACOS的关键词都建一条，一个店铺一周就攒了几百条，清单长得没人愿意翻。后来我又走到另一个极端，一个广告活动只写一条ACOS高、待优化，结果执行的人根本不知道从哪下手。所以我一直拿不准，到底该按什么标准拆。
按可执行动作拆，不要按数据行拆。判断标准很简单：如果一个条目需要两个人分别动手才能完成，就拆开；如果一个人一次就能做完，就合并。举个例子，同一个广告活动下十个关键词都是因为竞品降价导致点击成本上升，这是同一个原因、同一个动作类型，可以合成一条，后面附上关键词列表；
但其中三个词要降价、五个词要否定、两个词要加预算，动作类型不同，就必须拆成三条。颗粒度是否合适可以用两个信号自检：单条问题的处理周期超过三天，说明拆得太粗，执行人拿不到明确指令；一天新增超过二十条，说明拆得太细，清单会变成流水账。
建议做分层，把异常信号、待决策、执行任务分成三个层级，信号层可以多，决策层必须收敛到人能消化的数量，执行层再展开成具体动作，这样清单既不丢信息也不会压垮人。
我们团队一开始用共享表格，两三个人、一个站点的时候完全够用，后来三个站点、五个店铺一起做，表格版本就开始乱，谁改了什么根本查不到，经常出现两个人改同一行把对方的内容盖掉。但我也怕换了工具之后流程更重，大家反而不用了。
判断标准不是团队人数，而是三个条件有没有同时出现：问题是否跨店铺或跨站点、是否需要状态流转和提醒、是否需要留痕追溯。三条里满足两条以上，表格就会开始拖后腿。表格在单店铺、单人、问题类型少于五类的时候依然是最快的方案，改字段不用求人。
真要上工具，选型时看三件事：能不能把广告对象作为独立字段而不是写在标题里，广告活动ID、广告组、关键词、ASIN、站点这些必须是字段，才能做筛选和统计；能不能配置多种视图，按站点、按负责人、按截止日各看一遍；能不能保留每次改动的记录，用来回溯谁在什么时候把状态改了。
还有一个容易踩的坑，别为了工具而上工具，先用表格跑两周，把真实的问题类型分布摸出来，再拿这个分布去决定工具里要建哪些字段和哪些工作流，否则建出来的流程一定是拍脑袋的，最后没人用。
我们把这套东西跑起来之后，老板问我到底有什么用，我一开始只能回答感觉顺了很多，因为ACOS该高还是高，广告花费也没立刻降。但团队内部明明感觉响应速度快了、扯皮少了。所以我想知道，这种情况到底该用什么口径去衡量，不然说不清楚就容易被砍掉。
别用ACOS单独归因，广告问题清单的收益主要体现在响应速度和执行一致性上，ACOS受季节、竞品、库存、Listing质量影响太大，拿它当唯一指标一定说不清。用三组口径更靠谱。第一是闭环率和平均关闭时长，算法是周期内产生的问题条目中被关闭的比例，时长按发现日到处理日计算，这个能直接反映响应速度。
第二是重复率，同一个广告对象、同一类问题在三十天内再次出现的比例，这个数字降下来才说明根因被解决了，如果一直不降，说明清单只是在反复擦地板。第三是动作可追溯率，随机抽十条已关闭的问题，看能不能查到当时是谁改的、改之前和改之后的数据是什么，这是过程指标，决定了下次遇到同类问题能不能复用经验。
落地的时候建议每周固定跑一次这三组数，把重复率排在第一位看，因为它最能区分真在解决问题和只是把问题标成已完成。
读者评论
六个字段里，触发依据和复燃监控窗口最容易被形式化。我们三个人的广告组试过把所有异常都建问题，一周积压两百多条，最后只点红色看。我的经验是先定入池阈值：连续两天花费超多少、ACOS 超目标几个点才生成条目，不然问题清单会变成第二张报表，没人清得动。
我理解跨域问题清单的必要性，但创建时就强制填根因归属域值得商榷。很多广告异常看到的是点击率跌，查完才发现是主图或库存。过早要求选域，投放员会默认选广告侧，路由反而错。更合理的是先建“待诊断”状态，由一人24小时内补根因再改派，否则字段只是多一个拍脑袋选项。
文章说周均40条或3个账户是Excel加群聊的拐点，我们的体感更低：两个店铺每周不到30条问题，光靠聊天记录已经查不清哪条处理到哪了。阈值可能跟人员流动和跨时区有关。先别急着上大系统，把问题表加上负责人和截止时间，往往就能解决大半扯皮。