Shopee数据可信度：让自己相信自己的数据

数据可信度决定决策质量

数据不可信的最直接代价是决策会反复。今天按这个数字调了价格，明天发现数字不对，又调回来。这种来回折腾消耗的不只是时间，还有团队对判断这件事本身的信心。几次之后，大家会开始凭感觉做决定，因为数据看起来也不可靠。

第二个代价是讨论会跑偏。开会本来是要解决流量为什么下滑，结果前二十分钟在争论谁的数字对。这类争论往往没有结论，因为两个数字可能来自不同的口径，各有各的道理。数据不统一的时候，会议时间就消耗在建立共同前提上。

第三个代价是问题会被掩盖。一个数字看起来正常，可能只是因为它算错了。真实的异常被口径问题盖住，等到发现的时候，窗口期已经过去了。可信度的问题不只是效率问题，它会让人错过本该抓住的信号。

第四个代价是浪费排查成本。数据不可信的时候，排查的方向本身可能就是错的。花一天时间追一个不存在的问题，这种浪费在数据混乱的团队里并不少见，而且很难被察觉，因为看起来一直在忙。

反过来说，数据可信度提升之后，最明显的变化是决策速度变快。不用先花时间确认数字，可以直接进入分析和判断。这个提升不会体现在某一次具体的决策上，但会在每天的工作里持续累积。

第一步是找出最常被质疑的几个数字。团队里反复被问到的是哪几个，把它们列出来。这几个就是可信度建设的重点，其他数字可以先放一放。集中力量把最常出问题的几个理顺，效果最明显。

第二步是给每个数字写一句来源说明。来自哪个入口、什么时候取的、统计范围是什么。一句话就够，但必须有。写不出来的数字，说明它的来源本身就不清楚，这已经是一个需要解决的问题。

第三步是建立一个出错之后的处理流程。发现数字可疑的时候，找谁确认、多长时间给答复、要不要暂停基于它的决策。有流程之后，遇到问题不会慌乱，也不会因为等待而耽误事情。

第四步是把数据质量放进日常的检查项里。每周花十几分钟，看一看常用数字有没有异常波动，来源有没有变化。放在日常检查里，问题能在早期被发现，不会积累到影响决策的程度。

第五步是记录可信度建设带来的变化。争议变少了、决策变快了、排查时间缩短了，这些都是可以感受到的。把变化记下来，能让这件事持续下去，也能让新人理解为什么要做这些看似繁琐的约定。

有一个边界条件值得注意：可信度要求到什么程度，取决于决策的代价。调一个广告出价，用大致准确的数字就够了。决定要不要下几十万的采购单，就需要更严格的数据。把严格的核对流程用在所有决策上，成本会高得没必要。

遇到过这样的情况：团队花了很多时间统一口径，结果发现数字统一之后，原先的争议本来就不影响决策。因为两种算法得出的结论方向一致。这说明可信度建设也要抓重点，先解决那些真的会改变结论的差异。

还有一种常见情况是，数据本身没问题，但使用的人不理解它的含义。同样一个转化率，有人以为是下单转化，有人以为是付款转化。这类误解造成的争议，靠统一口径解决不了，还需要在使用说明里写清楚每个指标的确切含义。

数据可信度的建设要避免走极端。追求极致精确，会把大量时间花在核对小数点后的数字上。实际需要的是，关键结论不会被数据误差改变。判断标准可以定成：如果误差在某个范围内，结论不变，那这个程度就够了。

小规模业务不用一开始就建全套规则。先把来源写清楚、把口径固定，这两件最基础的事做了，就能消掉大部分争议。剩下的验证和分工，等业务量上来之后再逐步补。顺序对了，负担可控。

可信不是感觉，是一步步能说得清楚

来源与采集方式要清楚

来源清楚的第一层意思是知道数据从哪个入口取的。后台自带的报表、导出的明细文件、工具汇总后的表格，这三类来源的更新时间和统计范围都不同。写清楚取自哪一个，别人才能按同样的方式复现一遍。

第二层意思是知道采集的时间点。同样是昨天的订单数，上午十点取和下午三点取，结果可能不一样，因为中间有新的数据处理进来。把取数的时间也标上，数字才有确定的时间坐标，两个数字的比较才有意义。

第三层意思是知道原始数据的更新节奏。有的数据是实时的，有的每小时更新一次，有的要等到隔天结算。不知道这个节奏，就会把还没更新的数字当成最终结果。前面讲到的很多误判，根子都在这一层。

采集方式本身也要固定。手工从页面上抄、导出表格后加工、直接用工具汇总，这三种方式得到的结果可能有细微差别。同一种分析，每次都从同一个入口用同一种方式取，是目前最简单也最有效的保持一致的办法。

如果数据经过了中间加工，加工的步骤要写下来。哪些行被过滤了、哪些列被重新算了、特殊状态的数据怎么处理。这些步骤不写下来，别人拿到最终数字也无法还原，数字就成了一个无法验证的黑箱。

第一步是给每个常用指标标明来源。一张对照表，左边是指标名，右边是数据入口和更新频率。这张表做一次可以长期用，变动的时候更新一下就行。它是所有后续讨论的共同基础。

第二步是统一取数入口。同一个指标只从一个地方取，不要今天从报表取、明天从明细取。不同入口的数字即使口径相同，也可能因为更新时点不同而不一致。统一入口能消掉很大一部分差异。

第三步是把取数和加工的过程写成步骤。从打开哪个页面、选哪些条件、导出哪几列，到之后的处理动作，一步一步写。写得越具体，换人操作的时候结果一致性越高。

第四步是标注数据的更新节奏。哪些是实时的、哪些有延迟、延迟大概多长。把这些信息挂在指标对照表上，取数的人一眼就知道现在看到的数字是不是最终值。

第五步是定期回头检查来源有没有变。平台改版、报表结构调整、导出字段变化，这些都会让原来的取数方式失效。发现方式失效了要及时更新步骤，不然还会按老办法取出已经变形的内容。

平台改版是来源失效的常见原因。页面结构调整、报表入口改位置、导出字段增减，都会让原来的取数步骤失效。改版之后如果不检查，可能会取到一份看起来正常、实际含义已经变了的数据。

还有一种容易出问题的情况是时区。跨境业务涉及不同市场的当地时间，同一个日期在不同时区对应的实际时间段不一样。取数的时候如果不确认用的是哪个时区，和别人的数字对不上就很正常。

导出的文件本身也要留意。有的导出是当时数据的快照，有的是每次打开都重新生成。这两种性质不同，前者可以用作历史记录，后者不适合存档。区分清楚，才能判断这份文件能不能作为比对基准。

手工录入的数据要特别标注。它的准确性取决于录入的人，误差不可避免。用手工数据去校验系统数据，方向就反了。一般是拿系统数据来校验手工录入的部分。

如果一项数据来自多个入口的拼合，把拼合的方式也写下来。哪部分来自哪里、怎么合并的、遇到冲突时以哪个为准。拼合的数据在可追溯性上先天弱一些，说明写得越细越好。

决定可信度的是来源和口径，不是处理速度

计算过程能不能复现

复现的标准很简单：换个人，拿着同样的口径和步骤，能不能算出同一个结果。能做到就是可复现，做不到就说明中间有没写下来的东西。手工调整是最常见的隐藏步骤，也是复现失败的主要原因。

很多看起来简单的指标，算起来有很多分叉。转化率的分子是订单数还是付款人数，分母是访客数还是点击数，退款订单算不算在内，新老买家要不要分开。每一个分叉都会得到不同的数字。把这些选择写下来，指标才有一个确定的含义。

计算步骤要有顺序。先过滤时间范围、再排除测试订单、然后统计、最后算比例，这个顺序本身会影响结果。顺序不对，比如先算比例再排除，结果就会偏。步骤写下来的时候，把顺序也写清楚。

中间结果最好保留下来。从原始数据到最终结论之间的那几个中间数字，留着的话，出问题的时候能快速定位是哪一步偏了。只留最终结果，一旦对不上，就只能从头再算一遍。

复现不一定要每次都真的算一遍。它的价值在于当你需要验证的时候，能验证得了。知道自己随时可以复现，本身就会让人在写计算规则时更认真。可复现是对计算过程最低的要求。

第一步是把每个指标的计算规则写成公式。分子是什么、分母是什么、过滤条件有哪些。公式写出来之后，很多平时含糊的地方会立刻暴露出来，这些含糊的地方正是数字对不上的根源。

第二步是把规则里的每个选择都明确下来。退款订单算不算、测试订单要不要排除、跨期的数据归到哪一期。这些选择没有对错，但必须统一。统一之后，不同的人算出来的结果才会一致。

第三步是保留一份完整的计算示例。从原始数据到最终结果的完整过程，包括中间用到的每一个数字。以后有疑问的时候，拿这个示例逐段对照，能很快找出偏差出现在哪一步。

第四步是换个人按规则算一遍。这是检验可复现性最直接的办法。如果算出来不一样，说明规则里还有没写清楚的地方。这个过程本身就是一次规则的完善。

第五步是把计算规则纳入变更管理。规则要改，就说明改了哪里、从什么时间的数据开始适用。历史数据按老规则算，新数据按新规则算，中间不混用。这样时间序列才保持可比。

有一种复现失败的原因是数据源本身在变。历史数据被平台修正之后，用现在的数据重算，结果和当初记录的不一样。这不一定是算错了，而是数据源变了。遇到这种情况，把原始取数的时间点也记录下来，可以避免把这类变化误判成计算错误。

手工整理过的数据要格外小心。中间插入过一行、调整过某个值，这些动作很容易被遗忘。如果确实做了手工调整，就在数据旁边写一行说明。没有说明的手工调整，是复现失败最主要的来源之一。

规则里如果有模糊表述，比如排除异常订单，要让不同的人理解一致，得把异常具体化。是金额超过某个数、还是状态是某种类型。模糊的词在计算规则里会带来很大偏差。

复现的检查可以和新人培训结合起来。让新来的人按文档算一遍常用指标，算不对的地方就是文档需要补充的地方。这个过程一举两得，既检验了文档，也让新人理解了指标的含义。

有些指标的计算依赖外部条件，比如汇率、平台费率。这些条件变化之后，同样的订单算出来的成本就不同。把这类依赖条件列出来，说明清楚，可以避免用不同时间的条件去比较同一批订单。

交叉验证的几种办法

第一种是把两个不同来源的数字放在一起比。后台的汇总数和导出的明细数，通常应该能对上，对不上就有问题需要查。这种比对不需要很频繁，发现异常的时候做一次就够。

第二种是抽样手工核对。从明细里随机抽十几条，逐条手工算一遍，看和系统统计的对不对。抽样量不用大，十几条就能发现系统性的偏差。这个方法最原始，但也最可靠。

第三种是换一个时间区间再看。同一个指标，按周看和按月看，趋势应该是一致的。如果按周看在涨、按月看在跌，说明中间有周期性的因素被忽略了，或者某个时间段的数据有问题。

第四种是拿不同维度的数据互相印证。流量涨了但订单没涨，转化率就应该是下降的，这符合逻辑。如果数字组合起来不符合基本逻辑，说明其中至少有一个数字有问题。

第五种是找一线的人确认。财务说结算金额是多少、仓库说这周发了多少件，这些一手信息可以用来校验系统里的数字。人提供的信息不够精确，但能快速判断出量级上有没有问题。

第一步是定几组固定的对照关系。比如订单数和结算流水应该能对上，流量和曝光的比例应该在合理范围内。把这几组关系提前定好，日常核对的时候直接看关系成不成立，比每次重新想怎么验证高效得多。

第二步是准备一个抽样核对的流程。抽多少条、怎么抽、核对哪些字段、发现差异怎么记录。流程固定下来，抽样核对这件事才有可重复性。每次随机抽法不同，结论也没有可比性。

第三步是把验证结果记下来，包括验证通过的情况。只记有问题的验证，会让人误以为数据一直在出问题。通过的记录同样有价值，它说明这套数据在某个时间点是可靠的。

第四步是遇到解释不了的差异时，先回到最原始的数据。回到第一手的数据重取一次，然后一层一层往上对，看差异是在哪一步产生的。这个顺序比在两个二手数字之间反复比较更有效率。

第五步是把有效的验证方式固化进流程。验证过几次都有效的方法，就写进日常操作里，变成例行动作。验证不应该每次都临时决定怎么做，那样很难持续。

交叉验证要注意方向，也就是哪个数字更权威。系统生成的明细通常比手工汇总的金额更可信，因为中间没有人工环节。确定权威源之后，验证就变成了拿权威源去检验另一个数字，而不是两边互相怀疑。

两个数字的差异如果长期存在且稳定，说明是口径差异，不是错误。这类差异不需要每次都去查，记下来就行了。真正需要查的是差异突然变大或者方向变化的情况。

抽样核对时样本的选择要随机，不要专挑看起来正常的。挑着核对容易得到一个偏乐观的结论。随机抽的好处是能发现系统性的偏差，这类偏差往往比个别错误影响更大。

交叉验证不限于数字之间。买家的反馈、客服的记录、仓库的反馈，这些定性信息也可以用来印证数字。数字说退货率没变，但客服说最近退货的沟通明显变多，这个矛盾就值得查一查。

验证的结论要反馈给承担数据责任的人。让负责的人知道自己的口径或者步骤哪里容易出偏差，他才能去改进。验证只做了但没反馈，下一次还是同样的问题。

异常值处理的规则

遇到异常值，第一步是判断它是真异常还是数据问题。真异常指的是业务上确实发生了特别的事，比如大促带来的订单高峰。数据问题指的是采集或者计算出了错，比如某天的数据重复计入了一次。两种情况的处理方式完全不同。

真异常要保留并标注。它反映的是真实发生的情况，删掉它就等于篡改历史。正确做法是把它留在数据里，同时加一个备注说明当天发生了什么。这样后续分析的时候，看到这个点就知道原因。

数据问题要修正，但修正过程要留痕。改了什么、为什么改、改成什么，写清楚。直接覆盖原值是很危险的，因为以后没人知道这里被动过，也没人知道动得对不对。

暂时判断不出来的异常值，可以先标记为待确认，不要急着处理。标记之后继续观察，如果后面几期恢复正常，说明是偶发波动。如果持续异常，再深入查。急着下结论或者急着删掉，都会掩盖问题。

处理规则本身要固定。什么情况算真异常、什么情况算数据问题、遇到之后各自怎么处理，最好事先定下来。事先没定，每次都要重新讨论一遍，而且不同的人可能得出不同的结论。

第一步是先标记，不要处理。看到一个离群的点，第一反应应该是把它圈出来，而不是直接删掉或者改掉。标记之后继续观察，很多问题会自己显形。急着处理反而会把线索弄掉。

第二步是给标记的异常值分类。业务真实发生的、数据采集出问题的、暂时判断不了的，分成三类。分类之后，处理方式就有了依据，不用每次重新想。

第三步是为业务真实发生的异常值写备注。什么时候、发生了什么、影响范围多大。备注写在数据旁边，后续分析看到这个点就知道要单独考虑，不会被当成异常数据排除掉。

第四步是修正数据问题时保留原始值。原始值放在旁边的列里，不要覆盖。修正的记录包括修正时间、修正原因、修正方式。这三项写全了，以后复核的时候才能说得清。

第五步是定期回看标记的异常值有没有新的解释。有些当时判断不了的，过一段时间有更多信息之后就能解释了。把这些补上，数据的完整度会随时间提升。

有一个容易被忽略的边界是多个异常同时出现在同一时间点。单个异常可能是巧合，同时出现往往意味着有一个共同的原因，比如某天系统出问题导致多个指标一起异常。这种情况要把几个异常放在一起看，而不是逐个处理。

季节性商品的周期本身就带有规律性的高低起伏。每年同一时期都会出现的数值变化，不算异常，是周期。建立规则的时候要把已知的周期排除在外，不然每年这个时候都会触发一次处理。

处理规则要写明由谁来决定。遇到判断不了的异常值，应该找谁确认。如果没有指定人，这个异常值就会被搁置，最后不了了之。指定一个判断的人，处理过程才有推进。

标记的异常值要定期回顾。当时判断不了的，过一个月再看可能有新的解释。回顾不必频繁，跟着月度或者季度的数据核对一起做就行。不回顾的话，待确认的标记会越积越多，最后失去作用。

不要把处理规则定得太复杂。规则太细，执行的时候需要频繁查阅，反而没人愿意遵守。几条清晰的判断标准就够用了，剩下的交给判断力。规则的目的是一致性，不是覆盖所有情况。

能长期做下去的验证方式，才是有效的验证

数据责任的明确分工

每一项对外使用的数据，都要有一个人负责说清它的来源和口径。别人对这个数字有疑问的时候，知道该找谁问。没有人负责的数字，出了问题只能大家一起猜，猜的过程往往比数据本身更耗时。

负责不等于自己算。责任人的核心工作是确认口径写清楚了、来源标明了、复现步骤留下来了。具体计算可以交给工具，但确认这件事得有人做。把确认的责任落实到人，数据的规范性才会慢慢建立起来。

分工要按数据来源分，而不是按使用的人分。管订单数据的人、管广告数据的人、管库存数据的人，各管一块。按使用者分会出现同一份数据被不同的人各自解释的情况，反而更乱。

责任人之间要有交接约定。某项数据谁在什么时候交给谁、以什么形式交、交的时候要带上什么说明。这些约定写下来，人员变动的时候才不至于断档。口头交接在稳定期没问题，一旦有人离开就暴露缺口。

还要有一个总的把关角色。不一定要设成一个专门岗位，但需要有人定期看看各项数据的口径有没有漂移、来源有没有变。这个人不必懂所有细节，但要知道去哪里问。

第一步是列出所有对外使用的数据项，然后逐项指派责任人。指派的时候要考虑这个人是否实际接触这份数据，随便指定一个不相关的人，责任会落空。责任人要是数据流的实际经手者。

第二步是把责任内容写清楚。责任人要做的通常是三件事：确认口径写下来了、确认来源标明了、回答别人对这份数据的疑问。写清楚之后，责任才有边界，不会无限扩大。

第三步是建立一个提问和答复的通道。可以是固定的群、固定的文档评论，关键是提问有人看、答复有记录。答复也记下来，以后遇到同样的问题就不用再问一遍。

第四步是把责任分工和人员变动绑在一起。有人离开或者换岗，对应的数据责任要同步转交，转交的内容包括口径说明和已知的问题。不转交的话，接手的人要重新摸索一遍。

第五步是定期检查分工有没有落空。责任人不一定每次都记得自己的职责，需要有人定期确认。检查的频率不用高，季度一次就够，重点是确认这件事没有因为人员变化而中断。

责任划分要和实际的取数流程对齐。如果某项数据实际上是几个人都在用、都从不同地方取，那就要先统一取数入口，再指定责任人。不然责任人管不住来源，责任就变成了形式。

有一个务实的做法是让责任人负责一份简短的说明，而不是负责数据本身。说明里写清来源、口径、更新节奏、已知问题。这份说明跟着数据走，谁用谁看。责任人做的是维护说明，这个工作量是可控的。

责任交接要有清单。交接内容至少包括：数据来源入口、口径说明的存放位置、历史上出现过的问题、当前待确认的事项。有清单的话，交接可以在半小时内完成，没有清单可能要好几天。

对于使用人数很少的数据，可以不指定专门的责任人，但要有一个人兜底。兜底的人不需要每天关注，只是确保有事的时候找得到人。完全没有责任人的数据，出问题时会成为盲区。

责任人这个机制要定期确认还成不成立。人走了、岗位调了、项目停了，责任都会失效。半年左右过一遍名单，把失效的更新掉。这件事花不了多少时间，但不做的话，名单会变成一张过期的纸。

当数字本身不再被质疑，讨论才能聚焦到问题上

建立数据信任的长期动作

第一个动作是把常用的指标口径写成一份文档，放在所有人都能找到的地方。文档不用写得很学术，一个指标三五句话，说清分子分母和时间基准就够了。写了不更新等于没写，所以要指定人定期维护。

第二个动作是每次发现数据不一致，都把原因和处理过程记下来。这些记录积累起来，会形成一份很实用的清单：哪些地方容易出问题、常见的差异来源有哪些。以后遇到类似情况，直接翻清单。

第三个动作是定期做一次全面核对。把所有常用指标按各自的口径重新算一遍，和当前使用的数字对一对。频率不用高，季度一次就够。重点是保持这个动作的连续性，不要做一次就停。

第四个动作是在团队里保留一个提问的通道。任何人发现数字可疑，都可以提出来并且会有人跟进。如果提出来之后没人回应，大家慢慢就不提了，问题也会被积压下来。

数据信任是一点一点累积起来的。它的积累很慢，但塌掉很快，一次严重的错误就足以让人怀疑所有数字。所以长期动作的重点不是追求完美，而是保持稳定和透明，让人觉得这些数字是可靠、可追溯的。

第一步是把指标口径文档建起来。不求一次写全，先把最常用的十几个写下来。文档放在固定的位置，所有人都知道去哪看。有了这个起点，后面就是持续补充和维护。

第二步是养成发现不一致就记录的习惯。不用写得很正式，记下是什么不一致、查出来的原因、最后怎么处理的就行。这些记录的价值会随时间增长，是团队独有的资料。

第三步是固定一个周期做全面核对。季度一次，把所有常用指标重新对一遍。核对的过程可能会发现一些平时没注意到的偏移，这类偏移积累久了会造成判断错误。

第四步是保留一个宽松的质疑环境。发现问题的人敢于提出来，是数据质量能持续改善的前提。如果每次提出疑问都被当作找麻烦，大家就会选择沉默，问题也就没有机会被解决。

第五步是不要追求一次到位。数据可信度是一个持续改善的过程，一开始会有很多不完善的地方，这很正常。重要的是方向明确、动作持续，而不是一开始就设计一套完美的体系。

长期动作里最重要的一条是保持口径的稳定。口径频繁变动，前面积累的所有对比都会失去意义。有变动的时候要能说清楚为什么变，以及变动之后新老数据怎么衔接。

文档的维护建议指定一个人而不是轮流负责。轮流负责的结果往往是没人真正上手，写出来的内容风格和深度都不一致。指定一个人长期维护，文档的连续性才保得住。

不要让数据规则变成只有少数人懂的东西。规则如果只有制定的人清楚，这个人一旦忙起来或者离开，整个体系就会停摆。规则写下来、放出来，是让它能脱离具体的人而存在。

遇到数据出错的时候，重点是查清原因并补上规则，而不是追究谁的责任。追责的氛围一旦形成，出问题的人会倾向于把问题藏起来，这对数据质量的伤害远大于那一次错误本身。

衡量数据可信度有没有改善，可以看几个简单的信号：同一个问题被反复问起的次数、因为数据对不上而耽误的时间、排查时找不到来源的情况。这几个信号在往好的方向走，就说明努力是有效的。

常见问题（FAQ）