Shopee数据预警：什么数字值得拉响警报

不是每个数字都值得设预警

预警的成本不只是设置那一下。每收到一条提醒，人都要看一眼、判断一下要不要处理，这个动作本身就在消耗注意力。一天五条还能认真对待，一天三十条就会变成自动划掉。设置预警之前先想一想，这个数字一年会响多少次，每次都值得我停下来看吗。

很多指标本身波动就很大，属于正常范围里的上下起伏。点击率、单日转化率这类数字，受时间段、人群分布、流量来源影响明显，今天低一点明天高一点是常事。给这类指标设紧阈值，响的都是噪音。真正需要预警的是那些一旦异常就意味着有具体问题要处理的项。

还有一类指标虽然重要，但变化的过程很缓慢。利润率、复购率这类数字，一个月变化一两个点就已经算明显。用预警去盯这种慢变量，短时间内报警的次数很少，作用也有限。这类更适合放进固定的定期复盘，而不是靠实时提醒。

预警的价值在于争取时间。一个数字异常之后，如果早发现两小时能让损失少一些，那它值得设预警。如果早发现两小时和晚一天处理，结果没什么差别，那预警的意义就打折了。用这个标准去筛，能很快把清单缩短一半。

最容易设太多预警的时候，是刚经历完一次事故之后。被某件事伤到，就把相关的十几个数字全设上提醒。这种应激式的设置，通常过两周就被自己关掉了。更稳的做法是事故处理完之后，只挑出当时如果早发现就能避免损失的那一两个数字。

第一步是把现在所有在响的提醒列出来。很多人其实不清楚自己一共设了多少条，散落在各个模块里，谁设的也记不清。列出来之后按响过的频率排个序，从最吵的那几条开始处理。清单本身就是缩小范围的第一步。

第二步是给每条提醒算一个处理率。一段时间里响了多少次，其中需要实际处理的有几次。处理率低的那几条，要么阈值不合适，要么指标本身就不适合预警。用数字说话，比凭印象判断哪条重要准确得多。

第三步是把指标分成两类：一类是必须第一时间知道的，一类是可以等定期看的。这个分类不看指标重不重要，只看时间敏感度。利润率的绝对值很重要，但晚两天知道问题不大，它属于第二类。

第四步是给留下来的每一条配一个动作。响了之后具体做什么，是去查库存、去暂停广告、还是去联系供应商。配不出动作的提醒，说明它只是一个信息，不是预警。信息可以放在报表里，不必占用提醒的通道。

第五步是把删掉的那些项记一笔。为什么删、什么时候删、下次什么条件下可以考虑加回来。记录下来是为了避免过一阵子又重新设上，来回折腾。预警清单的稳定，本身就是它有效的前提之一。

有一个容易被忽略的边界条件：刚开店或者刚上新类目的时候，历史数据太少，定不出可靠的范围。这个阶段不适合设严格的预警，用宽阈值或者干脆只做人工巡检更稳妥。等积累了两三个月的完整数据，再回头把预警补上。

还有一类指标看起来适合预警，实际效果不好，就是由买家主观行为决定的项。评分、评价数量这类数字，受订单量和买家习惯影响，短期波动往往没有具体原因。它们更适合按周观察趋势，而不是按天报警。

遇到过这样的情况：为了防止漏单，把某个时段的订单量设了很紧的阈值。结果每天凌晨都报警，因为凌晨本来就没什么订单。后来改成按当日累计和同期对比，报警就正常了。阈值脱离时间语境，就会持续产生误报。

记录删掉的预警项时，建议注明当时删的原因和触发条件。比如某条是因为促销期噪音太大才关掉的，那么下次促销期结束之后就可以考虑加回来。写清楚原因，下次做决定时省了重新判断一遍的功夫。

给自己的预警清单留一点余量，不要设满。业务发展到某个阶段很可能会出现新的重要指标，事先留出位置，加进去的时候不至于要先去删旧的。清单保持五到八条，是一个比较舒服的规模。

预警的价值在于响得少、但每次都值得处理

预警指标的筛选标准

第一条标准是信号方向明确。数字掉下去或者涨上去，含义是清楚的，不需要额外的解释。订单量骤降就是订单少了，库存告急就是快没货了。方向含糊的指标不适合，因为收到之后还得先判断这算好还是算坏。

第二条标准是可以马上去做点什么。仓库快没货了，可以去催补货；广告花费超了，可以去看是哪个单元在烧。能对应到具体动作的指标，才具备预警的资格。有些指标虽然异常，但看完之后无事可做，那它更适合放在月度复盘里观察。

第三条标准是波动幅度足够大。正常波动只有几个点，异常的时候动辄三成五成，这种区分度才够。如果正常波动和异常波动差不多，阈值就没有地方可放。筛选的时候把过去几个月的高低范围列出来，看异常值能不能明显跳出这个范围。

第四条标准是核实成本低。收到提醒之后，花两三分钟就能确认是真问题还是假报警，这样的指标才适合放进日常预警。需要翻好几张表、跑几段查询才能核实的项，报警之后的处理成本本身就很高，容易拖着不处理。

符合这四条的项目通常不多，五到八个已经够用。清单短的好处是每条都会被认真看，也不会因为长期忽略而失去敏感度。清单长到二十条，实际效果和没设预警差不多，人会产生习惯性的无视。

第一步是列出候选指标。从日常最关注的数字里挑，订单、流量、转化、退款、库存、广告花费这几类各取一两个。候选不用太全，先把常见项放进来，后面再筛。

第二步是用方向明确这条筛一遍。删掉那些涨跌含义需要额外解释的指标。剩下的一般是订单量、库存可售天数、退款笔数这类一看就知道好坏的项。

第三步是用能不能马上处理筛一遍。有些指标即使异常，也只能记录下来等月度复盘再看，这类不适合进预警。留下来的是那些收到之后当天就能做出反应的项。

第四步是核对波动范围。把候选指标过去几个月的数据拉出来，看看正常波动的幅度有多大。正常波动和异常波动区分不开的，暂时放回观察名单，等积累了更多数据再定。

第五步是做一次演练。假设某条预警现在响了，把处理流程走一遍：去哪看、看什么、多长时间能确认。演练下来发现流程走不通的，说明这条预警还缺配套的动作，先补齐再上线。

跨品类的店铺要按品类分别定筛选标准。同一个订单量阈值，用在小件快消和大件耐用品上，意义完全不同。耐用品一天两单是正常的，快消品一天两单就说明出问题了。分品类设标准，筛选才不会误伤。

多站点经营的时候，站点之间的差异也要考虑进去。不同市场的流量结构、节假日、消费习惯都不同，阈值不能直接平移。分别在各自的数据上定范围，比套用同一个数字更贴近实际。

有一类指标适合做组合预警，而不是单独报警。比如流量和转化率同时下降才报警，单独某一项波动就忽略。组合条件能显著降低误报率，代价是配置复杂一点。对容易互相干扰的指标，这个办法很实用。

筛选的时候不要只看当前阶段。有些指标现在不重要，等业务结构变了可能就重要了。把候选指标放在一个观察名单里，定期看一看，需要的时候再提升为预警项。观察名单是预警的储备池。

不要把别人的清单照搬过来。别人的业务结构、订单规模、品类组合都和自己的不同，适合他们的阈值未必适合自己。可以参考思路，具体数字要自己在数据里找。照搬是误报的主要来源之一。

波动幅度大、动作明确的指标才值得设预警

阈值怎么定才合理

最实用的做法是回看历史数据，找出正常范围，再在边界留一点余量。取过去两三个月的水平，看这个数字大部分时间落在什么区间里，把阈值设在区间之外一点。留余量的目的是让正常波动不要触发，而不是追求灵敏度。

不同指标该留的余量不同。波动大的指标余量要留得宽，比如单日订单量，周末和工作日的差异本来就有两三成。相对稳定的指标余量可以留窄一些，比如可售库存天数，这个数字的变化通常有明确原因。

阈值可以分两级。第一级是提示，提醒你留意一下，不必立刻动手。第二级是处理，收到就要去看。分级的好处是可以把一些不确定的项放进提示级，观察一段时间之后再决定要不要升级。全是同级报警，处理优先级就分不出来。

刚设好的阈值需要试用期。设定之后观察一到两周，把期间响过的次数和实际需要处理的次数都记下来。响十次只处理两次，说明太灵敏，放宽。响一次都不响，但也确实错过了问题，说明太迟钝，收紧。用实际数据调，比一次到位更靠谱。

阈值跟着经营节奏走会更准。促销期订单量本来就高，用平时的阈值去看，天天都会触发。同样，淡季的低量也不代表出了问题。给不同时期设不同的阈值，或者干脆在特殊时期临时把某些预警关掉，都比让它们一直响更好。

第一步是取足够长的历史数据，至少覆盖两三个月，包含一个完整的促销周期。只看平稳期的数据，会把促销期的正常高峰当成异常。数据区间选对，阈值的基准才可靠。

第二步是找出正常范围的上下边界。把数据按从小到大排列，看大部分值落在什么区间里。边界不必严格按比例取，目测出大致的范围和离群点就够了。日常用的阈值不需要很精确。

第三步是在边界之外留余量。余量的大小和指标的波动性挂钩，波动大就多留一点。留余量的目的是让正常波动安静下来，所以宁可松一点，不要紧一点。

第四步是把阈值分成提示和处理两级。提示级设在稍早的位置，处理级设在明显异常的位置。两级之间的区间，是留给自己判断的空间。只有一级阈值，要么太吵，要么太钝。

第五步是记录试行期的表现。设好之后的两周里，每响一次就记一下是处理了还是忽略了。两周结束之后算一次处理率，据此决定放宽还是收紧。用真实数据调出来的阈值，比一次性拍出来的可用得多。

对于容易受单日大促影响的指标，可以考虑用滚动平均值来当基础。取最近七天或者最近十四天的平均，波动会平缓很多，阈值也更容易定。单日数据用来做提示，滚动平均用来判断趋势，两者配合使用效果更好。

新品的阈值要和老品分开。新品上架初期，订单量和流量的变化幅度本来就大，用老品的标准去衡量，会频繁触发。给新品设一段观察期，观察期内的波动不计入预警判断，过完再按常规来。

阈值定好之后，建议写在预警项的备注里，连同设定的日期一起。过一段时间回头看，能知道这个数字是什么时候、基于什么数据定下来的。没有这行备注，半年之后就没人说得清阈值的来由了。

有一种情况需要临时调整阈值：平台在改算法或者做流量分配调整。这类变化会在一段时间内让数据整体偏移，原来的范围失效。遇到这种情况，先临时放宽，等数据稳定下来之后再重新基于新数据定一遍。

阈值不必追求最优解。业务是持续变化的，不存在一个长期有效的理想值。定一个大致合理的，用起来，然后在使用中调整，比花很多时间推敲一个精确数字更实际。用起来比定得准更重要。

预警的触发频率与噪音

噪音的一大来源是观察周期的选择。用按天看的周期去盯一个本来就每天波动的指标，报警会非常频繁。换成按周看，或者用滚动几天的平均值，同样的数据就会安静很多。周期选对了，很多噪音不需要调阈值就消失了。

第二个来源是数据延迟。刚发完一批货，库存数字可能还没有同步更新，这时候的库存预警就是假报警。类似的还有结算数据、物流状态这些有处理时间的项。知道每个数据的更新节奏，就不会对着还没更新的数字做判断。

第三个来源是统计口径的变化。某个数字突然异常，回头看是计算方式改了，比如把某个品类并入了另一个统计范围。这类报警不是误报，但也不需要处理。建立变更通知的习惯，改口径之前说出来，能减少很多无谓的核实。

噪音多到一定程度，人就会开始无视所有预警，包括那些真的重要的。这种无视一旦形成，再想恢复对预警的信任就难了。控制噪音不是一件锦上添花的事，它直接决定了整套预警还能不能用。

处理噪音要有明确的动作，不能只是抱怨。每收到一条不需要处理的预警，都记一下原因：阈值太紧、周期太短、还是数据延迟。积累一两个月之后，把这些原因归类，一次把对应的规则改掉。零散地关掉某几条提醒，效果不如集中调整一次。

第一步是给每条预警标上观察周期。按天看的和按周看的混在一起，噪音水平完全不同。把周期拉长是降低噪音最省力的办法，往往不需要动阈值就能把频率降下来。

第二步是核对每条预警背后的数据更新节奏。数据本身有延迟的，预警的时间点要相应往后放。比如结算相关的指标，按结算完成的时点去看，比按订单发生时点去看要准。

第三步是建立口径变更的通知习惯。任何统计范围或者计算方式的调整，都提前说一声，并记下生效时间。这一条能消掉相当一部分看起来莫名其妙的异常报警。

第四步是定期统计噪音来源。按阈值太紧、周期太短、数据延迟、口径变更这几类归一下原因，看看哪一类占的比例最大。集中改掉占比最大的那一类，效果最明显。

第五步是设定一个噪音容忍线。比如一个月里不需要处理的报警不超过某个数量。超过了就启动一次校准。有了明确的线，什么时候该动手就不用凭感觉判断了。

有一个常见的假报警来源是统计口径里的商品范围变化。新上架的商品还没积累数据，被计入统计之后，会拉低或者拉高整体平均值。把新品、停售品这些特殊状态从预警统计里排除，能减少一批无谓的提醒。

物流和结算类数据的延迟往往有规律。周末不处理、节假日顺延，这些节奏固定的延迟是可以预判的。把预警的时间点放在数据处理完成之后，而不是数据产生的那一刻，误报会少很多。

遇到过这样的情况：某条预警连续一个月每天都响，检查下来每次都正常，但没人去把这个阈值改掉。久而久之，这条预警就被自动无视了，连真正异常的那天也没人看。一条长期误报的预警，危害不只是它本身，还在于它会训练出忽略的习惯。

噪音统计建议做成一张简单的表。日期、预警项、是否处理、原因分类。一张表填一两个月，哪条预警值得保留、哪条该改，看一眼就清楚。表格不需要复杂，关键是持续填。

如果某类噪音反复出现，说明问题可能不在预警本身，而在数据链条上。比如某个字段经常延迟，导致依赖它的预警总在报假警。这时候更值得做的是把数据更新的环节理顺，而不是反复调阈值。

收到预警之后做什么

第一件事是确认这条预警是真信号还是假信号。最快的确认方式是看数据有没有延迟，以及口径最近有没有改过。这两项排除之后，如果数字确实异常，再进入下一步。跳过确认直接行动，容易在假信号上白费功夫。

第二件事是判断异常的边界。是单个商品的问题，还是一批商品都在变。是单个渠道的流量掉了，还是所有渠道都掉了。范围判断清楚了，问题的性质就大致知道了。范围越大，越可能是外部因素。

第三件事是找同期对照。和上一周、上一个月、去年同期比一比，看这个异常是不是只在当下这个时点显眼。有些数字在特定的时间点本来就有规律性变化，对照一看就明白了。没有对照，任何变化看起来都像问题。

第四件事是先做止损动作，再查原因。库存告急就先下架或者限购，广告超支就先暂停超出的单元。止损和归因是两件事，不要等查清楚原因才动手。查原因可能要花一两天，损失的订单却是实时的。

第五件事是把这次的处理过程记下来。什么时候收到预警、怎么确认的、最后发现是什么、做了什么。这些记录积累起来，下次同类预警响起的时候，处理速度会快很多。记录不必长，几句话就够，关键是留下判断的依据。

第一步是核实真假。查数据有没有延迟，查口径最近有没有改过。这两个动作花不了几分钟，但能挡掉相当一部分假报警。核实这一步不能省，省下来的时间往往会在后面加倍花掉。

第二步是划定异常范围。看是一个商品还是多个商品，是一个渠道还是所有渠道，是一个时间段还是持续到现在。范围这个信息，很大程度上已经指向了问题的类型。

第三步是做时间上的对照。和前一天比、和上周同期比、和上月同期比。有些异常在对照之后会自然消解，因为它在同期本来就是这样。对照能过滤掉大量伪问题。

第四步是先止损再归因。能马上减少损失的动作用最快速度做完，再回头慢慢查原因。这两件事的顺序不能颠倒，等查清楚了再动手，损失可能已经扩大了。

第五步是当天就把处理过程记下来，哪怕只写几句。收到时间、判断过程、采取的动作、后面的观察结果。记录的价值在下次同类情况出现时体现，那时候你会庆幸当时写了几笔。

确认真假的顺序有讲究。先看数据延迟，再看口径变化，最后才去看数字本身。顺序对了，能用最少的时间排掉最常见的两种假报警。顺序如果反了，会先花时间研究一个本来就没问题的数字。

止损动作要提前想好，不能等报警来了才决定。库存告急的时候是先下架还是先限购，广告超支的时候是停单元还是降预算，这些最好在设预警的时候就写清楚。事发当下再讨论，容易因为着急而做出过头的处理。

处理完之后要有一个复查的时间点。比如停了广告之后三天回来看数据，改了库存之后一周回来看。没有复查，你就不知道当初的处理是对的还是错的，下次遇到同类情况仍然没有经验可用。

有一类预警不需要立刻处理，但需要登记。比如某个指标只是轻微越界，看着不像大问题，可以先记下来，观察两三天。如果自己恢复了就是波动，如果继续恶化就升级处理。轻信号不放过，也不用每次都大动干戈。

如果预警响了但自己判断不了，最好找个人一起看一眼。两个人的判断不一定都对，但比一个人钻进去更容易看出方向。排查最忌讳的是在一个假设上越走越远，有第二个人在旁边，这种情况会少很多。

越容易核实、越能马上处理的项，越适合作预警

预警与日常巡检的分工

预警擅长的是响应快、影响明确的事。数字越过某个边界，就说明有具体的动作等着去做。这类事靠人每天盯着看不现实，交给预警更合适。预警的作用是把你从盯表中解放出来，只在需要的时候提醒你。

巡检擅长的是缓慢变化、需要横向比较的事。一个数字本身没有超出边界，但和同类商品比、和上个月比，能看出趋势在往不好的方向走。这类判断机器做不来，需要人去看、去想。放进固定的巡检清单里，按周或者按月过一遍。

两条线要明确分开，不要混着做。同一件事既设预警又每天手工核对，重复投入，而且两边的判断标准可能不一致，反而产生新的困扰。分清楚之后，什么交给系统提醒、什么靠自己定期看，心里就有数了。

巡检的清单也要短。太长会变成走过场，看一眼就翻过去。三到五项，每项都有明确的判断标准，比如某项连续三期下降就展开。清单短而固定，执行起来才有连续性。

两条线之间要保持信息互通。巡检中发现某个数字值得实时盯，就把它加进预警。预警响了很多次都判断为误报，就把它挪回巡检，改成定期看。这种来回调整是正常的，说明规则在跟着实际情况变。

第一步是把现有的检查动作分成两类。一类是数字越界才需要看的，一类是需要横向比较才能看出问题的。分完之后，前者进预警，后者进巡检清单。

第二步是给巡检定一个固定时间。比如每周固定一天，把清单上的项过一遍。固定时间的好处是形成习惯，不容易被别的事情挤掉。临时想起来了才看一次，等于没有巡检。

第三步是给每项巡检写清楚判断标准。连续几期下降就展开，低于同类商品多少就展开。标准写清楚了，执行的人才知道什么时候该停下来处理，什么时候看一眼就可以过。

第四步是检查两条线有没有重复。同一件事既在预警里又在巡检里，就去掉一个。判断保留哪边的方法很简单：看它是需要即时响应，还是可以等到固定时间再看。

第五步是定期在两条线之间挪动项目。巡检里发现某项变得紧急了，挪进预警。预警里某项反复误报，挪回巡检。这种流动是正常现象，说明规则在适配实际。

巡检清单里建议保留一项固定内容：看一遍过去一周所有响过的预警是什么，处理结果如何。这项检查能发现规则是不是在逐渐失效。只看预警本身，很难察觉自己已经开始无视某些提醒了。

巡检还有一个作用是发现预警覆盖不到的地方。有些问题不属于任何一条预警的管辖范围，但会体现在几个数字的组合上。定期整体看一遍数据，这类问题才浮得出来。只看单项，永远看不到组合的异常。

两条线共用一份数据出口会更省事。预警和巡检都从同一份数据看，避免同一天出现两个不同的数字。数据出口不统一，讨论的时候会先花时间争论哪个数字对，而不是讨论问题本身。

人员分工上，预警的处理可以按品类或者按模块分给具体的人，巡检则建议由一个人统一负责。巡检需要横向比较，分散到多人手里就失去了全局视角。预警处理需要快速响应，分给具体的人才不会互相等待。

遇到需要长期跟踪的问题，可以在巡检清单里单开一项，标明观察期限。比如改过包装之后连续观察两个月。到期之后把这一项结掉或者转入常规。有期限的观察，比无限期地挂着更有效率。

把无效预警压下去，有效的那些才会被认真对待

预警规则的定期校准

校准的第一个触发条件是业务结构变化。换了主推品类、调整了投放结构、新开了站点，这些变化都会让原来的正常范围失效。旧阈值在新结构下可能天天触发，也可能完全失效。改完结构之后，找一次时间把相关的预警重新过一遍。

第二个触发条件是季节或者促销周期。进入旺季之前，把订单量类预警的阈值临时上调；旺季结束之后调回来。不调整的话，要么旺季天天报警，要么淡季该响的时候不响。把这件事写进促销准备清单里，不容易漏。

第三个触发条件是预警的命中率开始下降。一段时间里响了很多次、处理的不多，说明规则已经和实际情况脱节了。用一段时间的记录算一下命中比例，低于一半就值得展开看看到底是哪些项在制造噪音。

校准要留下版本记录。哪一天改了哪一条、为什么改、改成什么，写清楚。过一段时间回头看，能知道规则是怎么一步步演变成现在这样的。没有版本记录，改过几次之后就没人记得原来的阈值是多少了。

校准的频率不必很高，平稳期按季度过一次就够。频率太高反而会让人觉得规则一直在变，失去稳定预期。重点是每次校准都基于实际观察到的数据，而不是凭感觉临时调整。

第一步是定一个校准的时间点。可以是季度末，也可以是某次大促之后。定下来之后写进工作的例行安排里，不靠临时记起。有固定节点，这件事才不会被一直往后拖。

第二步是调出这段时间的预警记录。哪些响过、响了几次、处理了几次、最后发现是什么。数据摆出来，哪几条需要调整就很清楚了。没有记录就没法校准。

第三步是按项检查阈值是否还合适。业务量涨了或者跌了，原来的绝对值阈值可能已经失去意义。改成相对值，或者按当前规模重设一遍，都是可行的做法。

第四步是删掉确实没用的项。长期不响且不需要响的预警，留着只是占用清单的空间。删掉不是放弃监控，而是承认这个指标更适合用别的方式看。

第五步是把这次校准的结果写进版本记录，注明日期和原因。下一次校准的时候，从这份记录接着往下改，不用每次重新讨论一遍原理。规则有了延续性，用起来才顺手。

校准的时候要把预警和实际问题的对应关系一起看。一条预警响过之后，有多少次确实找出了真问题。如果对应关系很弱，说明这个指标和实际问题之间的关联没那么强，值得考虑换一个更贴合的信号。

业务增长之后，有些阈值需要从绝对值改成相对值。比如订单量，早期可能设一个固定的数字，规模上来之后固定数字就失去意义了，改成和上周同期对比的百分比更合适。规模变化时记得检查这一项。

删掉一条预警之前，先确认它对应的风险有没有别的监控方式。如果确实没有任何其他地方盯着，那就先保留，只是把阈值放宽。删除的前提是风险仍然在视野里，只是换了个方式看。

校准的记录建议保留完整的历史版本，不要只留最新一版。有时候会发现某个阈值改来改去又回到了原点，这时候看看中间的记录，能知道当时为什么要改，避免来回重复。

校准完之后，把改动点知会给相关的人。改了阈值但处理的人不知道，收到报警的时候还是会按老经验判断。通知不必正式，一条说明就够了，关键是让接手的人知道规则变了。

常见问题（FAQ）