去年 Q4，我陪一个做厨房小家电的卖家复盘旺季表现，遇到了一件挺尴尬的事：他们的评价监控报表做得非常漂亮，每周一早上九点准时发到群里，星级、评论总数、差评关键词一应俱全。可整个旺季，他们没有一次在差评扩散之前做出反应。
真正让他们掉排名的那个主题，「噪音大、用两周就异响」，第一次出现在 10 月 8 日，被写进周报是 10 月 14 日，产品端回复加上 Listing 卖点调整是 10 月 26 日。那时候同类评论已经积累到 37 条，主推变体的转化率从 11.2% 掉到 8.6%。
问题不在执行，在观测系统本身的设计。这也是我想认真聊「亚马逊软件管理要点：评价管理的趋势观察如何设计」的起点。评价管理早就不是「看星级、回差评」这么简单，它是一套需要被设计出来的观测系统：口径怎么定、指标怎么分层、基线怎么选、异常怎么判、归因怎么做。下面我把这几年做跨境数据咨询和工具选型时攒下的判断，一条条拆开讲。
第一个结论：评价管理的核心动作，不是「回复差评」，而是「在 24 到 72 小时内发现结构性变化」。单条差评是噪声，同一主题在一周内重复出现三次以上才是信号。绝大多数卖家的系统只能处理前者，处理不了后者。
第二个结论：趋势观察的价值不在「看得全」，而在「口径稳定、基线可比、异常可判」。我见过太多团队买了很贵的工具，把 30 个指标堆在一个看板上，结果运营每天只看那个最大的星级数字。指标越多，判断越慢，这是评价管理里最常见的反直觉现象。
第三个结论：工具只是载体，观测框架才是资产。换一个数据平台，把口径和阈值规则一起搬过去，三天就能重建；但如果框架只存在某个运营的脑子里，人一走，系统就归零。这是我判断一个团队评价管理成熟度的第一条标准。
说它免费，是因为平台不向你收评论的钱；说它贵，是因为它对转化率的影响是即时且非线性的。我手上复盘过的一个样本集里，主图、价格、A+ 都不动的前提下，星级从 4.5 掉到 4.2，转化率的中位数变化是 -1.9 个百分点；从 4.2 掉到 3.9，中位变化是 -3.6 个百分点。这条曲线不是线性的，越往下越陡。
更麻烦的是它的滞后性。评分是「同步指标」，评论文本里的关键词才是「领先指标」，而转化率是「滞后指标」。你在转化率报表上看到问题时，领先指标已经报警两三周了。如果观测系统只盯同步指标和滞后指标，你永远在救火，而不是在预警。
我一般把评价观测系统拆成四层，每层解决一个不同的问题：
四层里，最容易被跳过的是第二层和第三层。绝大多数团队直接从第一层跳到第四层，数据抓回来，看到差评就让人去处理。中间两层空着，系统就退化成「人工刷评论列表」。
最早我自己做运营的时候，也是周报模式。周一导出数据，周二分析，周三开会，周四安排动作。这个节奏在人少、SKU 少的时候没问题，因为那时候一条差评的传播速度也慢。
但现在的环境变了。我对比过自己手上两组店铺样本：一组是周报模式，一组是日级自动监控，从「差评首次出现」到「人工首次触达」的中位时延，前者是 6.2 天，后者是 0.8 天。从「首次出现」到「首次有效处置」，前者 11.3 天，后者 2.2 天。将近 5 倍的差距，直接决定了负面主题有没有机会形成规模。
这里有个反直觉的地方：不是所有差评都要 24 小时响应。真正需要快的是「主题识别」，不是「逐条回复」。一条孤立差评可以慢慢处理，但一个新主题第一次出现，必须当天进入观察名单。
很多选品和竞品分析里，评论数的月增量被当成销量的影子指标。这个做法在三五年前还凑合，现在越来越不准。原因有几个：平台评论获取路径变多了（站内索评、Vine、品牌引流），评论留存率也有波动，加上变体合并会一次性带入大量历史评论。
我自己做过一次小样本验证：把 20 个 ASIN 的评论月增量与实际销量做相关性分析，在「以自然评论为主」的子样本里相关系数还能到 0.6 左右；但在「大量使用评论获取项目」的子样本里，相关系数掉到 0.2 以下。也就是说，同样是评论涨了 100 条，背后代表的销量可能差好几倍。
更危险的是，评论数增长如果主要来自被动差评，它和销量是负相关的。我后面第五节的案例里会看到，有一个 ASIN 评论月增速 +22%，转化率却掉了 2.6 个百分点。
这是最隐蔽的一个坑。变体合并时，父 ASIN 的星级会按评论数加权平均，子变体的极端评分往往被稀释。结果就是：你看到整体星级从 4.2 回升到 4.4，松了一口气，但真正卖得最好的那个颜色变体，星级其实还在往下走。
我见过最典型的一次，是卖家把一个「高星低销量」的旧变体合并进主推链接，整体星级回升 0.3，团队当月把评价相关的投入砍了一半。两个月后主推变体差评累积到 60 多条，整体星级又跌回去，还多损失了两个月的窗口期。
结论很简单：任何评价指标，只要不做变体粒度的拆分，就在结构上不可信。这一条我在后面会反复回到。
差评率看起来非常合理，但它有两个致命缺陷。第一，分母是评论总数，而评论总数本身受索评策略影响，分母一变，指标就失真。第二，差评率无法区分「1 条差评」和「50 条同类差评」，而后者才是真正伤转化的。
我更推荐的核心指标组合是：负面主题集中度（某一主题在近 30 天负面评论中的占比）加上主题扩散速度（该主题评论数从首现到翻倍的天数）。这两个指标的组合，能同时捕捉「有多严重」和「扩散多快」。
评论总数是存量指标，它反映的是历史，不反映当下。一个积累了 5000 条评论但近 30 天新增差评集中在某个质量问题的 ASIN，风险比一个只有 200 条评论但近期全是好评的 ASIN 高得多。
我通常看的比值是：近 30 天评论增量 / 总评论数。这个比值太低（比如低于 1%）说明链接已经进入静默期，评论结构固化，一旦出问题缺乏新增好评去稀释；太高（比如高于 15%）反而要警惕是不是在短期内大量获取评论，质量可能参差。
「行业平均 4.3 星，我们 4.4，还行」，这句话在 90% 的情况下是错的。基线必须至少满足三个同质条件：同品类、同价格带、同评论量级。
一个 4.6 星、80 条评论的 ASIN，和一个 4.2 星、4000 条评论的 ASIN，它们面对的评价环境完全不同。前者评论少、易操控、波动大；后者评论多、韧性高、但一旦下滑极难拉回。用同一个基线去判断，等于用体温计去量血压。
平台在前台给出的评分分布、买家画像标签、评论有用投票数，这些是结构化信息，价值不比文本低。比如评分分布的形态：同样是 4.3 星，「大量 5 星 + 少量 1 星」和「集中在 3 到 4 星」是两种完全不同的产品信号。
前者说明产品两极分化，可能有批次或适配问题；后者说明产品整体平庸，缺乏惊喜点。对应的动作也完全不同：前者查供应链，后者改卖点和产品定位。只看平均星级，这两种情况会被压成同一个数字。
这两类评论的评分分布、语言风格、留存表现都不一样。混在一起算，会系统性地高估评价健康状况。我的建议是在数据库里加一个「评论来源」字段，默认是自然，通过特定渠道获取的单独标记，分析时分开看，只有在看「总量趋势」时才合并。
分开之后你会发现一个很实用的判断：如果一个 ASIN 的评分改善主要来自非自然评论，那它的真实口碑其实没有变好，只是被暂时盖住了。
口径是观测系统的地基，它决定了所有后续分析是否可比。我通常固定三个参数：
这三个参数一旦定下来，就要写进文档，不能因为某次分析需求临时改。我见过团队为了「看清楚上周发生了什么」把滚动周期改成 5 天，结果整个历史序列都不可比，等于把过去半年的观测记录废掉了。
这是整篇文章里我认为最重要的一条判断逻辑。评价相关的指标必须按时间属性分三层，每层配不同的响应节奏：
| 层级 | 典型指标 | 领先/滞后关系 | 建议响应窗口 |
|---|---|---|---|
| 领先层 | 负面关键词新增条数、主题集中度、评分分布形态变化 | 比转化率变化早 7-21 天 | 24 小时内进入观察名单 |
| 同步层 | 滚动星级均值、近 7 天评分均值、评论增速 | 与转化率基本同步 | 3 天内确认并归因 |
| 滞后层 | 转化率、广告 ACOS、自然排名 | 比评价变化晚 7-30 天 | 用于验证处置效果 |
为什么分层这么关键？因为大多数团队的告警全设在同步层，星级掉了才报警。而星级是加权平均，有很强的惯性，等它明显下降时，领先层的信号已经响了十几天。
我自己在项目里的经验是：把 80% 的告警预算放在领先层，20% 放在同步层，滞后层只做效果验证不做告警。这样既不漏报，也不会被大量噪声拖垮。
基线不是「行业平均」这一个数字，它应该是一组条件。我通常用四个维度来定义基线：品类节点、价格带区间、评论量级分档、变体类型。只有四个条件都匹配的 ASIN 群，才能放在一个基线池里。
实际操作中，如果某个细分条件下样本太少（比如少于 8 个 ASIN），我会退一步，用「同品类 + 同价格带」做基线，但在报表上标注样本量不足。这一点很重要，因为小样本基线波动大，容易产生假告警。
单看阈值会漏，单看变化率会误报。我的做法是三个条件组合，必须同时满足才触发告警：
第三条是最容易被省略的，也是最关键的。没有持续时长条件，一次促销带来的评分正常波动就会触发告警，运营很快会对告警脱敏，这才是观测系统真正的死亡方式，不是漏报，是被无视。
告警如果不能落到具体动作，就是噪声。我要求每一条告警必须绑定三样东西：责任人、可能的动作清单、闭环时限。
比如「某变体噪音类负面主题 7 天新增 5 条」这条告警，绑定的动作清单可能是：核对近期批次质检记录、检查包装缓冲材料是否更换、在 QA 里回复并引导联系客服、评估是否需要在 Listing 里补充使用说明。责任人通常是运营 + 供应链的双人组合，闭环时限 5 天。
这套映射关系不要一次性设计完美，从最高频的三类负面主题开始，跑三个月再扩展。我见过团队一开始就设计了 40 条映射规则，结果没一条被真正执行。
去年我帮一个家居类目的卖家做评价观测体系重建，他们在亚马逊美国站和欧洲站一共 6 个店铺、约 120 个 ASIN，主推 18 个。之前的做法是运营助理每周手动导出评论，用表格统计，再做一份 PPT。
重建目标有三个：一是把观测频率从周级提到日级；二是把变体粒度拆开；三是把领先层指标的告警跑起来。
选工具的时候我们对比了几种路径，最后落在「数跨境」上（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。选择理由不是功能最多，而是它的数据结构和我们设计的观测框架对得上，能按 ASIN 和变体拉历史序列，能把关键词维度单独抽出来，这两点比多十几个花哨指标更重要。
看板跑起来 30 天后，出现了三组和我们预期不一致的数据，我印象很深。
第一组：评论增速和转化率几乎不相关，甚至负相关。我们原本以为评论涨得快的 ASIN 转化应该更好。结果 5 个主推 ASIN 里，评论月增速最高的那个（+38%）转化率只提升了 0.4 个百分点，而评论月增速只有 +6% 的那个，转化率提升了 1.8 个百分点。拆开看才发现，前者增长主要来自评论获取项目，后者几乎全是自然评论，而且集中在「安装简单」「尺寸合适」这类决策相关卖点上。
第二组：评论基数最大的 ASIN 反而最脆弱。评论基数 940 条的 ASIN C，评论月增速 +22%，看起来最健康，但转化率掉了 2.6 个百分点。原因是这 22% 的增量里，超过六成是同一主题的负面评论，产品在静默期被卷入了一个适配性问题，而总量大掩盖了结构恶化。
第三组：安静不一定安全。ASIN D 评论月增速只有 +2%，看起来进入稳定期。但它的「近 30 天评论增量 / 总评论数」比值只有 0.6%，意味着几乎没有新增好评去稀释任何潜在的负面。这种链接一旦出问题，评分修复周期是新增活跃链接的两到三倍。
我们把看板拆成四块：变体健康度、负面主题追踪、评论来源结构、竞品对标。其中告警规则是在工具里配置的，配置思路我写成了一段结构化示例，可以直接对照迁移：
{
"rule_name": "negative_topic_acceleration",
"scope": {
"asins": "priority_18",
"granularity": "variant",
"marketplaces": ["US", "DE", "FR"]
},
"window": {
"rolling_days": 7,
"compare_with": "previous_7_days",
"min_history_windows": 2
},
"conditions": {
"topic_new_count_gte": 3,
"topic_growth_rate_gte": 1.0,
"must_persist_windows": 2
},
"severity": {
"high": "topic_new_count_gte >= 6 AND affected_variants_gte >= 2",
"medium": "topic_new_count_gte >= 3",
"low": "topic_new_count_gte >= 2 AND topic_growth_rate_gte >= 0.5"
},
"actions": {
"owner": ["category_ops", "supply_chain"],
"sla_hours": {"high": 24, "medium": 72, "low": 168},
"checklist": ["batch_quality_check", "listing_copy_review", "qa_reply"]
}
}
这段配置里最关键的两个字段是 must_persist_windows 和 sla_hours。前者防误报，后者防拖延。很多团队规则写得漂亮，但没有 SLA，告警发出来就在群里躺着。
看板跑了 45 天之后，我们做了一次回溯分析：把期间出现的 23 次负面主题告警按「从告警到首次处置」的时长分成三组，看后续转化率的恢复曲线。
结果比我预期的更明确。24 小时内处置的那一组，第 7 天转化率恢复到基线的 96%，第 14 天超过基线到 101%，第 30 天到 103%；3 天内处置的那组，第 7 天只有 89%，要到第 30 天才回到 98%；而 7 天以上才处置的那组，第 30 天仍停留在 88%，基本没有自愈。
这里有一个重要的判断：差评造成的转化损伤，有一部分是不可逆的。处置得越晚，越多的潜在买家已经带着负面印象离开，而且不会再回来。这也是为什么我一直强调领先层指标的价值，它买到的不只是时间，是修复的可能性。
新品期的评价结构还没成型，观测重点不是「趋势」而是「第一批真实反馈的方向」。这个阶段我建议把 45% 的观测精力放在差评关键词上，30% 放在评分分布形态，15% 放在竞品对标，10% 放在合规审查（防止违反平台评价政策）。
具体动作上，新品期最关键的一件事是建立「主题词典」。把前 30 条评论里出现的所有描述性词汇手工归类，形成 8 到 12 个主题标签，后续所有分析都基于这套标签。这套词典是临时的，但它决定了你后面能不能做趋势追踪。
成长期评论量快速增加，噪声也快速增加。这个阶段的重点是「区分信号和噪声」。建议把观测资源调整为：差评主题追踪 40%、变体健康度拆分 25%、评论来源结构 20%、竞品对标 15%。
特别要盯的是变体之间的口碑分化。成长期最容易出现的情况是，某个颜色或尺寸的变体因为适配问题积累了负面评价，但被其他变体的好评平均掉了。如果不做变体拆分，这个问题会被隐藏到爆发。
成熟期的链接评论基数大，抗波动能力强，但修复速度也慢。这个阶段的重点从「发现新问题」转向「监测结构变化」。建议配比是：评分分布形态 35%、负面主题追踪 30%、新增评论占比 20%、竞品对标 15%。
我特别建议成熟期链接关注一个指标：近 90 天新增评论中，负面主题的占比变化。总星级可能纹丝不动，但这个占比在缓慢爬升，通常预示着半年后的口碑拐点。
这种情况的处理逻辑和自然差评完全不同。第一步是确认，不是申诉。判断依据包括：评论发布时间是否集中、账号历史行为是否异常、评论文本是否与产品实际功能无关、是否集中在同一时间窗口内多个变体同时出现。
确认之后，观测系统要做的是「隔离」，把疑似异常评论单独打标，不计入常规趋势指标，避免污染基线。同时保留原始数据，因为申诉时平台通常会要求提供时间线和影响评估。
这个阶段最忌讳的是用常规告警规则去处理异常情况，导致整个看板被一条攻击刷屏，真实信号反而看不见。
多站点团队最大的问题不是数据量，是口径不统一。美国站看 7 天滚动，欧洲站看 30 天，最后汇总出来的数字没有意义。
我的建议是先在总部层面定义一套「最小公共口径」，包含三个参数：滚动周期、变体拆分规则、负面主题分类标准。所有站点必须按这套口径输出。至于各站点特有的指标（比如某些市场的语言风格差异），可以放在站点专属看板里，不进入汇总。
这是被问得最多的问题。我的判断框架是三个变量：ASIN 数量、团队技术能力、观测框架的成熟度。
ASIN 少于 20 个、团队没有开发资源，直接采购；ASIN 超过 100 个、有稳定的开发资源、并且已经有一套跑通的口径文档，自建才有意义。中间的区间，通常是采购更划算。
我算过一笔 12 个月的账：采购成熟工具的年成本大约在 1.5 万到 3 万元人民币区间（按 100 个 ASIN、多站点口径估算），加上运营配置和维护的人力约 2.4 万元；自建脚本的初期开发投入约 3.5 万元，年维护 1.8 万元，人力 1.2 万元，总计约 6.5 万元。差距主要来自维护成本，平台数据结构一变，自建脚本就得改。
我几乎从不建议全量监控。原因是监控成本不只是工具费用，更是人的注意力。一个运营同时看 120 个 ASIN 的告警，等于一个都不看。
我的做法是分三档：核心 ASIN（贡献 70% 以上营收的）日级监控 + 全维度告警；腰部 ASIN 周级监控 + 只看领先层告警；长尾 ASIN 月度巡检，不做告警。这个分档每季度重算一次，因为营收贡献结构会变。
不建议全自动，也不建议全人工。我的配比是：高严重度告警自动推送到责任人 + 强制人工复核；中严重度告警进日报，运营每天早上扫一遍；低严重度告警只进周报汇总，不单独提醒。
这样做的原因是，人工复核本身是有价值的，它能不断校正你的主题词典和阈值设置。完全自动化的系统会慢慢偏离业务实际，因为你再也没有人去看原始评论了。
这是最现实的一个取舍。同样的预算，投在广告上见效快、可衡量；投在评价管理上见效慢、难归因。
我的判断标准是看「评价问题是否已经在拖累广告效率」。如果 ACOS 在自然排名没有大变化的情况下持续上升，通常说明 Listing 的转化能力在下降，这时候评价管理的边际收益高于加广告预算。反过来，如果评价健康、转化稳定，那把预算压在广告上更合理。
一个粗略的经验值：当某 ASIN 的滚动星级在 30 天内下降超过 0.15 星，且负面主题集中度超过 25% 时，评价管理的优先级应该高于广告加预算。
回到开头那个案例。那个卖家的问题从来不是不努力，而是把评价管理当成了一项「阅读任务」，而不是一套「运行系统」。阅读任务是靠人的勤奋，系统是靠设计。
我想留下的三个独特判断是：
第一，评价管理的核心战场在领先层指标上。负面关键词的新增速度和集中度，比星级早 7 到 21 天发出信号。把告警预算压在这一层，你买到的是处置窗口，而不只是提前知情。
第二，任何不做变体拆分的评价指标，在结构上都不可信。父 ASIN 的加权平均会系统性地掩盖主推变体的恶化，这是我在咨询项目里见到频率最高的误判来源。
第三，观测系统真正的失败模式不是漏报，是被无视。灵敏度设置得越高，误报越多，运营脱敏越快。中灵敏度加持续时长条件，比高灵敏度裸跑更有效。
如果你现在就想动手，我建议的下一步只有一件：不要先买工具，先花两个小时把你手上主推 ASIN 的负面评论按主题手工归类一遍，形成一份 8 到 12 个标签的临时词典。然后拿这份词典去验证你现在的观测系统能不能识别这些主题，大概率你会发现，缺的不是数据，是分类标准。
词典建立起来之后，再去选工具、配阈值、设 SLA，顺序就不会错。就像我在第五节里展示的那套看板，真正让它跑起来的不是数据源有多全，而是口径、分层和映射关系先被设计清楚了。数跨境的接口和数据结构帮我们省了很多采集和整理的时间（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys），但观测框架本身，还是得自己长出来。
我一开始只盯平均星级和评论总数，结果每次汇报都像复读机，老板问一句“口碑是变好了还是变差了”，我就答不上来。后来才发现，是指标设计本身太浅。到底要布哪些指标，才能既反映真实口碑变化，又能直接指导运营动作？
建议把指标分三层来看。结果层看平均星级（近7/30/90天滚动值，不要看累计值）、1-2星评论占比、评论总数增速、带图带视频评论占比。过程层看差评率，分母一定要用同期订单数而不是累计评论数，否则不同链接之间没法横向比；
同时看差评主题分布，按物流、产品功能、说明书、包装、期望落差五类打标，再看评论响应时长中位数。势能层看Top3差评主题占全部差评的比重变化，以及新主题的首现时间。
判断依据来自一次踩坑：我操盘的一个链接整体星级4.4一直没动，但“电池续航”这个主题的差评占比从8%涨到27%，两个月后星级才开始掉，这个结构指标提前了6到8周给出预警。只看星级，等于把预警窗口全部浪费掉。
我们做的是小类目，一天可能只有两三条新评论，有时候一周都没变化，我就怀疑是不是自己抓的数据量不够。也试过每天全量抓，结果看板上全是锯齿线，涨一点跌一点，根本分不清是趋势还是随机波动。采样频率和样本量到底该怎么定？
用“固定周期加事件驱动”双轨制。固定周期按日均新增评论量分档：日均超过20条每天抓，5到20条每3天抓，低于5条每周抓一次。
样本量上，单次趋势判断至少要有30条新评论，或者连续两周的稳定数据，低于30条只做定性观察、不下结论，因为亚马逊评论星级的方差本身极大，我实测过一条1星评论对30条样本的平均星级影响能到0.05到0.1，足以制造出假趋势。
事件驱动这条线更关键：星级单日跌0.1、单日新增差评达到3条、或者出现此前没见过的差评主题词，立即触发一次抓取并做归因。另外统计窗口要用近14天滚动均值，不要用自然周，自然周会把周中和周末的流量结构差异混进来看，换成滚动均值后锯齿明显平了。
最头疼的是老板看到一条差评就说我们口碑崩了，我说是偶发他又不信，因为我自己也拿不出判断标准，全靠感觉。我需要一套能摆在会议室里说服人的口径，而不是互相拍脑袋。
用三重交叉验证。第一，绝对阈值和相对阈值同时满足才算趋势，比如差评率高于近90天基线的1.5倍，且连续两个统计周期成立，只满足一个就只记录不预警。
第二，必须先下钻再上升，同一父体下不同变体的差评可能高度集中：我遇到过一个变体的差评率是其他变体的4倍，只看父体整体数据完全看不出来，等发现时已经亏了一波退货。
第三，找对照组，看同类目Top5竞品的同期差评率是否也在上升，如果竞品同步上升，大概率是旺季物流延误或平台政策变化带来的系统性因素，不是你的产品问题，这时候该做的是调整预期和客服话术，而不是改产品。这套标准落地之后，“是不是趋势”就从主观争论变成了一道算术题。
我们做过一个挺漂亮的看板，每周例会过一遍数据，然后就没有然后了。运营说数据不是他想要的，做数据的人说运营不行动，最后看板成了摆设。到底怎么把趋势观察和实际动作串起来？
核心是给每个趋势指标预设一个“条件动作”和唯一责任人，而不是等开会讨论。具体做法是写死触发规则：某差评主题连续两个周期占比超过15%，触发质检抽样加Listing文案和图片核查；评论响应时长中位数超过48小时，触发客服排班调整；带图差评集中在同一批次，触发FBA批次核查并评估换货或召回。
每条动作都必须在执行后第4周和第8周回看该主题占比是否下降，不降就说明归因错了，重新排查，这一步最容易被省掉，但恰恰是唯一能让经验沉淀下来的环节。我自己的看板固定三列：指标与当前值对比基线、责任人加动作、复盘日期，缺任何一列都不算闭环。
判断依据很直白，没有验证回看的动作本质上还是一次性救火，做十次也攒不下方法论。
读者评论
变体拆分这条我认，但落地比想象中难。我们后台导出的评论报告只到父ASIN，颜色尺码这些维度得靠人工对着评论内容猜，猜错的概率不低，后来是自己写脚本抓子体页面的评分分布才勉强能用。所以问题可能不只是框架没设计，而是数据源本身就不给这个粒度。工具选型时得先问清楚能不能按子体出评分分布，不然框架画得再漂亮也落不了地。
日级监控的收益我信，但没提成本。我们二十几个核心链接，一天一轮人工过评论至少两个人时，小团队根本排不出来。另外对「主题识别要当天进观察名单」有点保留，有些主题其实就是单一批次问题，等两天看清是批次还是设计问题再动手，反而少做很多无用功。我觉得更该先定的是谁来看、看完能拍板做什么，不然告警再快也是堆在群里没人接。
近30天评论增量除总评论数那个1%到15%的区间，感觉品类差异很大。我们做低频耐用品，评论增速常年低于1%，按这个标准早该进静默期预警，但销量挺稳。还有评论来源字段，平台不给标记，只能靠时间间隔和语言风格推断，我试过误判不少，拿它分开算自然和非自然评论，结论未必比混着看更可靠。