Shopee数据口径拉齐：同一个指标只留一种算法

口径不统一会带来什么混乱

第一个混乱是讨论无法推进。当两个人拿着不同的数字讨论同一个问题，话题会自然滑向谁的算法更合理，而原来要讨论的业务问题被搁在一边。一次会开完，除了争论什么结论都没得到。

第二个混乱是结论无法验证。口径不一致的情况下，某个调整是不是有效根本判不出来。你说改善了他却说变差了，很可能只是两边用的算法不同，而不是效果真的出现了分化。

第三个混乱是历史数据断裂。口径在某个时间点变了，前后的数字就不能直接比较。如果变更时没有记录，后面的人会看到一条莫名其妙的断层，既找不到原因也不敢继续用这批数据。

第四个混乱是责任无法界定。当指标是考核依据时，口径分歧会直接变成利益分歧。同一份业绩在两个人的算法下差出很多，这种情况下讨论就不再是技术问题，处理起来难度完全不一样。

还有一个不太明显但影响很远的混乱，是经验无法沉淀。每次做完分析，结论都依赖于当时用的那个算法。算法没写下来，三个月后回看这个结论，根本不知道当时算的是什么，经验就丢掉了。

排查这类混乱有个很实用的第一步：把两个数字并排写出来，让差异可见。不要停留在感觉不一样，而是把两个具体的数和各自的算法制成一张对照表。差异一旦被写下来，性质往往一眼就清楚了。

第二步是定位分歧点。从分子、分母、时间范围、包含状态四个方向逐个比。多数分歧集中在其中一两个方向上，比完就能找到。这个过程不需要讨论对错，只需要找到是哪一项不同。

第三步是判断影响面。算出如果用另一种算法，数字会差多少。如果差幅很小，可能不值得花时间统一；如果差幅很大，就说明这个指标的口径必须尽快拉齐，因为它已经在影响判断了。

第四步是决定处理方式。要么统一成一种，要么明确区分两种的使用场景。前者的适用条件是用途相同，后者的适用条件是用途确实不同。选哪一种都要写下来，不要靠口头约定。

处理完之后回头看这次分歧是怎么产生的。多数情况是某个人在早期按自己的理解算了一次，之后就这么沿用下来。找到源头之后，可以在流程上加一个小小的检查点，避免同类问题再出现。

举一个绩效考核上的例子。某家店铺给运营定的目标是转化率不低于某个水平。半年之后复盘，发现两个人的转化率差了很多，其中一个一直用的是付款口径，另一个用的是下单口径。整个考核结果需要重算。

这类问题的代价不在于重算本身，而在于这期间的所有激励和判断都是基于错误比较做出的。有人可能被低估了，也有人被高估了，团队的信任会因此受到影响，这种损失比数字本身更难修复。

另一个例子是商品取舍。店铺按利润率决定下架哪些商品，而利润率的成本口径没有统一。一种算法只算采购成本，另一种把推广费也摊进去。同一批商品在两种算法下，下架名单完全不一样。

这个例子的后果是决策失去依据。你不知道按哪个名单执行才是对的，两个名单看起来都合理。这时候要么重新梳理口径，要么承认这个决策只能靠经验，两条路都比有一个统一口径要多花时间。

边界条件在于，口径混乱在业务量小的时候不太明显。一个月几十单，两个人算出来的数差不了多少。随着订单量增长，差异被放大，问题才暴露出来。所以口径这件事，规模上来之前做掉成本最低。

口径拉齐的关键不是选出最正确的算法，而是选出大家共用的那一种

一个指标可能有几种算法

以转化率为例，分子的选择就有好几种。可以是下单数、付款数、也可以是完成交易的订单数。分母的选择也有几种，可以是商品访问次数、访问人数、也可以是商品页曝光量。三四乘三，能组合出很多种算法。

客单价的算法分歧主要在统计单位上。按订单算，一笔多件商品的订单只算一次，客单价会偏高。按商品行算，多件订单会被拆开，算出来的值会偏低。两个数都叫客单价，但含义并不一样。

退款率的分歧集中在分子。有一种是按退款申请量算，反映的是买家的诉求强度。另一种是按退款完成量算，反映的是实际的资金流出。前者反应更快，后者更接近真实损失，用途不同。

曝光和访问类指标的分歧主要在去重。同一个人一天访问五次，算一次还是算五次，得出的数能差好几倍。这类指标的口径不写清楚，任何和它相关的比率都会跟着出问题。

广告相关指标的分歧在于归因方式。是按点击归因还是按成交归因，归因窗口是当天还是几天内，这些选择会让同一个广告活动的效果数据出现很大差异。不写清归因方式，讨论广告效果就没有共同基础。

要摸清一个指标到底在用几种算法，最直接的办法是问使用它的人。找三到五个经常用这个指标的人，让他们各自说一遍怎么算。把说法列在一起，分歧点会立刻显现出来。

问的时候要注意问细节，不要问概念。问分子取哪个字段、分母取哪个字段、时间按什么取、包含哪些状态。只问概念会得到一堆听起来一样的回答，问到细节才会发现差异。

还有一种发现算法的方式是看历史表格。翻一翻过去几个月别人做过的表，看里面同一指标的算法有没有变化。历史表格是分歧的高发区，因为不同人做表的时候习惯不一样，而这些差异往往没有被记下来过。

找到多种算法之后，不要急着取舍。先把每一种算法对应的场景写下来，看看是不是真的需要这么多。很多情况下，多种算法里只有一两种是常用的，其余的是某一次临时分析留下的，可以归并掉。

最后一步是把选定后的算法固化成一条可执行的规则，并把被淘汰的算法标注为不再使用。不标注的话，隔一段时间它们又会被重新拿出来用，因为看起来也说得通。淘汰就要明确淘汰。

有一个具体的场景是关于曝光量的。同一个商品在推荐位和搜索结果里都出现，算一次还是算两次，两种算法都说得通。前者衡量的是覆盖了多少人，后者衡量的是出现了多少次。看数据的人常常不知道自己在看哪一种。

这种分歧会直接影响后续的判断。曝光量涨了但点击没涨，如果两次曝光是同一个人看到的，那说明这个位置的重复展示没有价值。如果曝光增长来自触达了更多人，那结论完全相反，属于正常增长。

还有一个涉及退款率的场景。买家在大促后集中申请退款，按申请口径看退款率会立刻飙升，按完成口径看则滞后一段时间才上升。两个数都在动，如果不写清用的是哪一个，讨论改善效果就是对不上。

广告归因的窗口也是类似的分歧。把归因窗口设成一天和设成七天，同一个广告活动的成交数会差出不少。做广告效果对比时，两边的窗口设置不一样，得出的优劣结论可能正好相反。

边界情况是有些指标确实需要多套算法并存。比如获客成本，按新客算和按全部订单算用途不同，都该保留。这种情况下要做的是给两套算法起不同的名字，写清各自的适用场景，而不是强行合并成一套。

越是被频繁引用的指标，口径分歧出现得越多

先定核心指标清单

清单的第一步是盘点，而不是设计。把团队现在实际在用的指标全部列出来，不用考虑是否合理，先列全。很多分歧的根源在于，有些指标大家嘴上都在说，但从没有人把它正式写下来过。

盘点的第二个动作是找重复。同一个业务含义在团队里有几个不同的叫法，或者同一个叫法对应几种算法，这一类要合并。合并的时候以业务用途为准，用途相同的归成一个指标。

第三步是筛出核心指标。判断标准是这个指标一旦出问题，会不会影响到决策。会影响决策的留下，纯粹记录用、没人看的先放一边。核心清单短一点更好，五个到十个通常就够覆盖日常判断。

第四步是给每个核心指标指定一个负责人。负责人的职责不是算数，而是在口径要变更时提出讨论、写清规则、通知到人。有人负责的指标才会被维护，没人负责的指标很快会退回到各自理解的状态。

清单定下来之后要发布出去，让所有相关的人知道核心指标是哪几个、去哪看规则。发布这个动作很容易被跳过，但它恰恰是让清单从个人整理变成团队共识的关键一步。不做这一步，清单只是一个人的笔记。

盘点的时候建议从报表倒推。打开现在在用的每一张报表，看里面出现了哪些指标，把这些指标全部抄下来。从报表倒推比凭记忆列更完整，因为记忆里通常只留了常用的那几张。

抄完做一次去重。同一个字段在不同报表里可能有不同的名字，比如访问量、访客数、流量，意思可能是一样的。去重的时候以字段来源为准，来源相同的合并成一个。

去重之后按使用频率排序。看每个指标在多少张报表里出现、多久被引用一次。频率高的排前面，这构成了核心清单的候选范围。频率很低但偶尔关键的指标单独放到次要清单里。

排序之后砍一刀。核心清单建议控制在十个以内，超出的部分放入次要清单。清单太长会导致每个指标的口径都写不清楚，最后整体失效。宁可少而清，不要多而糊。

清单确定后建议挂上一个生效日期，从这天起所有新的报表和讨论都用这份清单里的口径。生效日期是让清单真正开始发挥作用的那条线，没有它，清单会一直停留在讨论稿的状态。

有一个实际的做法是从一场会开始。把团队里最常参与数据讨论的几个人叫上，各自写出自己认为最重要的五个指标，然后放在一起看交集。交集部分通常是真正的核心，分歧部分值得讨论。

这个做法的好处是它把隐性共识显性化了。很多人以为大家对核心指标有共识，写完才发现并不完全一致。这种不一致在平时不影响工作，但在紧急决策的时候会突然放大，提前发现比事后发现好。

清单确定之后建议给每个指标配一个别名说明。同一个指标可能有几种不同的叫法，把常用的几种叫法列在下面，避免因为称呼不同而误以为是两个指标。这在多人协作的团队里很实用。

还有一个细节是把清单和报表对应起来。每个核心指标标出它在哪几个报表里出现、哪个是主报表。有了这层对应关系，遇到数字不一致的时候，可以直接去查主报表，而不是在多个报表之间来回翻。

边界条件是清单要随业务变化调整。上了新渠道、开了新站点、换了新的推广方式，都可能引入新的核心指标。建议每季度看一次清单，把不再使用的删掉，把新出现的补上，保持清单和实际一致。

每个指标写清计算规则

写规则的第一条要求是具体到可以照着做。写清用哪个字段做分子、哪个字段做分母、按什么时间取数、包含哪些状态。含糊的表述比如按有效订单计算，因为有效这两个字没定义，等于什么都没写。

第二条要求是写清适用范围。同一个指标在不同场景下可能确实需要不同算法，那就把场景写进去。比如日常经营看一个口径，广告效果看另一个口径。写清场景之后，两种算法可以并存而不冲突。

第三条要求是给出一个算例。用一组具体数字走一遍计算过程，写出结果。算例的作用是验证规则本身有没有漏洞，很多时候写着写着就会发现某个环节的定义不清楚，算例能把这个不清楚暴露出来。

第四条要求是注明例外。比如大促期间某些字段的特殊处理、新站点的数据从什么时候开始有、某个历史时段的数据缺失。例外写清楚，规则在实际使用中才不会一遇到边界情况就被放弃。

写完之后建议让一个不了解背景的人照着算一遍。如果他算出来的结果和你一样，说明规则是可执行的。如果他算不出来或者算出了别的数，说明还有隐含的假设没写进文字里，需要补充。

写规则的时候有一个实用的检验方法：把它交给一个不熟悉的人，让他按规则算一遍再给你看结果。如果结果一致，规则是可用的。如果算不出来，说明还有隐含前提；如果算出了别的数，说明规则描述有歧义。

规则里的时间描述最容易产生歧义。写按天统计是不清楚的，要写清按订单创建的日期，从零点到二十四点。存量的字段还要写清取数时点，因为同一个字段在不同时刻可能是不同的值。

状态描述也需要具体。写排除无效订单是不够的，要写清取消的、退款的、未付款的各自算不算。状态类的定义最好列一个清单，把常用的状态名和对应的处理方式一一对应起来。

对于比率类指标，除了分子分母，还要写清分母为零时的处理方式。这个细节平时用不到，但在数据为空的时候会直接导致计算错误或者表格报错，属于必须写清楚的一项。

规则写完之后建议配上修改记录。写清这条规则是哪一天定的、改过几次、每次改了什么。修改记录能让后来的人理解规则的演变，也能在做历史对比的时候知道哪个时间段用哪一版。

有一个具体的规则写法示例。转化率写成：分母取去重后的商品访问人数，分子取这些访问者在访问后七天内付款的订单数，时间按订单创建时间归属到访问当天，取消和完全退款的订单不计入分子。

这样一句规则包含了分母定义、分子定义、归因窗口、时间归属、状态排除五项内容。任何一个人照着这句话都能算出一致的数。如果只写转化率等于付款数除以访问数，前面五项中的后四项全都缺失。

规则的写法可以统一成一个模板，按照分母、分子、时间、状态、例外五个部分依次写。模板的好处是写规则的人不会漏项，看规则的人也知道去哪里找信息，团队整体的一致性会明显提高。

还有一个容易被忽略的部分是精度。比率保留几位小数、金额是否四舍五入，这些细节在单个数据上看不出问题，但在加总的时候会产生差异。规则里写清精度处理方式，能避免这类末位差。

边界条件是规则也要写清不适用的场景。比如某个指标在活动期间需要特殊处理，那就直接写明活动期间不适用本标准。把不适用说清楚，比让规则勉强覆盖所有情况更实用。

跨人跨表怎么对齐

对齐的第一个动作是确认来源。两个人算出不同的数，先别比算法，先确认两边取数用的是同一个后台的同一个入口。很多时候差异只是因为在两个功能相似的页面里取的，那两个页面本身口径就不同。

第二个动作是比筛选条件。把两边的筛选条件逐项列出来对照，时间区间、订单状态、站点、商品范围，一项一项比。对照的过程很枯燥，但它能定位到具体的分歧点，比笼统讨论有效得多。

第三个动作是拿一个具体样本验证。选一笔双方都能看到的订单，看它在两边的表格里分别被算成了什么。从一笔订单出发比从总数出发容易得多，因为总数上任何差异都被混合在一起了。

第四个动作是把对好的结果固化。这次对平之后，把双方用的算法、筛选条件、取数时间写进文档，下次直接照着来。如果只是口头对平，下一次换人或者过一段时间，分歧会重新出现。

还有一个做法是建立交叉检查的习惯。定期让两个人分别算同一个指标，把结果放在一起比对。有差异就当场查清。这种检查的成本不高，但它能让口径的悄悄漂移被及时发现。

对齐的时候推荐一个顺序：先看总量，再看分项，最后看单据。总量对不上就先找分项，分项对不上就找单据。从大到小定位，比一上来就逐笔核对效率高得多，也更不容易在一开始就被细节带偏。

看总量的时候用相对差判断。算出差额占总量的比例，比例很小说明是个别数据的差异，比例较大说明是系统性的口径不同。前者去查具体几笔，后者去查口径本身，方向完全不同。

看分项的时候按维度拆。常见的维度有时间、商品类别、站点、渠道。逐个维度拆开看差额分布，差额集中在某个维度上的值，往往就指向了原因。分布均匀的话，问题更可能在口径上。

看单据的时候只挑有代表性的。不必逐笔核对全部，挑差异最大的几笔、金额最大的几笔、状态最特殊的几笔。这几笔查清之后，剩下的差异通常能被同一个原因解释。

对平之后一定要落文档。把对齐的双方、时间、结论、采用的算法写下来。下一次再遇到分歧，直接从这份文档开始，不用重新走一遍对齐的全过程。这是把一次性工作变成资产的做法。

有一个很典型的对齐案例。两个人的订单数差了三十单，从总量查起，发现差额集中在一个特定日期。再拆到分项，发现是那天的退款订单算不算的问题。最后一笔一笔查，确认是二十四笔退款加六笔取消。

这个过程的每一步都在缩小范围。从三十单的差额出发，如果一上来就逐笔翻一千多笔订单，可能要花半天。按总量、分项、单据的顺序走，实际只用了不到一小时就找到了原因。

对齐之后他们把结论写进了一份说明：退款和取消都计入订单列表，不计入销售统计。这句话后来被引用过很多次，每次有人问起数字为什么差，直接指向这份说明即可，不用重新查一遍。

还有一个细节是把对齐用的样本保留下来。把那笔关键订单的编号和截图存在文档里，以后再有类似争议，直接调出来看就行了。样本的存在让结论变得可以复核，而不是只有参与对齐的人才知道。

边界情况是两边的口径都对但确实不该比。比如一个是按自然月统计的月度数据，一个是按最近三十天统计的滚动数据，这两个数本来就不应该相等。识别出这种情况，就能避免去做无意义的对齐。

口径问题的代价主要不在当下，而在数据没法做长期比较

口径变更怎么通知到人

通知的难点在于不知道谁在用。解决办法是在文档里维护一份使用人清单，谁在哪个报表或者分析里用到这个指标，就记上谁。清单不需要很精确，能把主要使用者覆盖到就足够。

通知的内容应该包含三件事：改了什么、为什么改、从哪一天开始生效。只说改了什么，接收的人不知道怎么用；不写生效日期，他们就不知道历史数据要不要重算，最后往往变成两边都留着。

通知的时机建议提前。不要等改完再通知，而是讨论确定之后就发出去，留出过渡时间。过渡期内新旧口径可以并行一段时间，让相关的人有时间改表格和适应。突然切换容易出错。

通知发出去之后要确认回执。至少确认那几个最直接的使用者已经知道了。通知这件事最怕的不是被拒绝，而是被忽略，发在群里没人看就等于没通知。重要变更建议一对一确认一遍。

还有一个补充动作是把变更记录写在文档里。通知是给当下的人看的，变更记录是给以后的人看的。写明哪一天改过什么、当时为什么这样改，后来的人回看历史数据时才不会困惑。

通知渠道要选对。重要的口径变更不要只发在群里，群消息容易被刷掉。建议发在固定的位置，比如文档的更新日志里，然后在群里说一句指向那个位置。这样既不刷屏，也不会丢失。

通知里要写清变更影响。告诉接收的人变更之后哪些数会变、变化方向大概是什么。例如说明新口径会让转化率整体下移，这样他们看到数字变了不会误以为业务出了问题。

对于在用旧口径做报表的人，建议给一份对照说明。写清新的算法、旧算法、两者差异大概多少。有了对照，他们自己能快速判断手头的表需不需要改，改哪里，不需要再逐个来问。

建议设一个过渡期的统一日期。所有人从这一天起用新口径，之前的日报表保留旧口径并标注。统一日期能避免长期并存新旧两套数，并存时间越长，后续越难理清。

变更之后的两三周内，建议主动跟进一次。看看有没有人还在用旧口径，有没有人遇到算不出来的情况。主动跟进一次的收益很大，因为被动等反馈时，等问题暴露出来通常已经影响到决策了。

有一个具体的做法是把变更做成一份简短的说明，格式固定为三段：变更内容、生效日期、需要做什么。三段写清之后，接收的人能快速判断这件事和自己有没有关系，不用读完整段背景。

适用对象也要写明。是所有人还是只有做报表的人需要改，是只影响对外汇报还是也影响内部考核。把适用对象写清楚，可以避免无关的人被打扰，也避免相关的人以为是别人的事而错过。

变更说明建议保留在一个固定的位置，按时间倒序排列。这样无论什么时候，只要打开这个位置，就能看到这个指标历史上改过几次。历史变更记录是判断数据可比性的关键依据。

对于影响较大的变更，建议安排一次简短的同步。十几分钟，把变更内容口头讲一遍，回答几个问题。口头同步的价值在于能即时解决疑惑，书面通知做不到这一点，遇到复杂变更时差距很明显。

最后的确认动作是抽查。变更生效一段时间之后，找两三个人的表格看一眼，确认用的是新口径。抽查比统计有多少人已读有用得多，它检查的是实际行为，而不是通知有没有送到。

口径统一之后，讨论才能从数字对不对转向该怎么做

口径文档的维护方式

维护的第一个原则是让文档保持薄。一个指标写三五行就够，写成长篇说明反而没人看。文档的价值在于被查阅，不在于内容详尽。厚文档看起来专业，实际使用中往往是最先被废弃的那一种。

第二个原则是让更新变简单。如果改一次文档要经过好几道流程，实际上就不会有人去改，文档会慢慢和现实脱节。把编辑权限放开给几个负责人，改完在群里说一声，这种轻量方式更容易长期存活。

第三个原则是定期通读。建议每季度把文档从头看一遍，对照现在的实际操作检查有没有不一致。通读的时候重点关注那些很久没人提过的指标，它们最可能已经悄悄改变了做法而文档没跟上。

第四个原则是保留历史版本。每次修改之前留一份旧的，注明日期。这样当有人拿很久以前的分析来讨论时，你能查出当时用的是哪一版口径，而不是对着一个数字猜测。

最后一点是关于文档的位置。放在团队都容易找到的地方，并且把入口固定下来，不要今天放这里明天放那里。文档本身写得好不好是次要的，能不能被找到、是不是只此一份，才是它有没有用的前提。

维护要有人。每个核心指标指定一个负责人，职责包括回答口径问题、受理变更需求、更新文档。负责人不必是数据分析角色，任何熟悉这个指标的同事都可以担任，关键是有人认领。

维护要有触发条件。常见的触发有四种：业务模式变化、平台字段调整、出现新的用法、发现文档和实际操作不符。把这四种情形写进文档的说明里，让所有人都知道什么时候应该触发一次更新。

维护要留痕迹。每次修改都在文档末尾追加一行，写清日期、修改内容、修改人。这行记录不需要长，一句话就够，但它是判断历史数据可比性的唯一依据，缺了它很多旧数据就只能废弃。

维护要定期检查。每季度通读一遍，重点看两类内容：一类是很久没人提过的指标，一类是最近频繁被问到的指标。前者可能已经不用了，后者说明描述得不够清楚，两类都需要处理。

最后是把维护这件事的成本压到最低。文档不追求完整，只追求准确；更新不追求流程，只追求及时；版本不追求规范，只追求可追溯。三条都做到，这份文档就能长期用下去。

有一个实际情况值得注意：很多团队的文档不是没写，而是写了之后没人看。原因通常是位置不固定或者内容太厚。解决的办法是把最常用的部分放在最前面，把详细说明放在后面，让人一眼能看到要用的那几行。

另一个常见问题是文档由一个人维护，这个人一旦忙碌或者离职，文档就停更了。解决办法是给每个指标指定负责人，让维护分散到多个人身上。集中在一处的维护方式看起来很整齐，实际很脆弱。

还有一个细节是把文档和报表连接起来。在报表的说明页写上口径文档的位置，这样用报表的人自然会被引导到文档。反过来在文档里标出各指标对应的主报表，两边形成互相指认的关系。

边界情况是文档可能同时存在多个版本。有人本地存了一份、共享盘里有一份、群里发过一份，到底哪份是准的没人知道。遇到这种情况，先确定一个固定的位置，把其余的都删掉或者标注为过期。

最后是给文档设一个最低要求：任何一条口径规则，要能让一个没参与过讨论的人看懂并算出一致的数。这个要求不高，但它能挡掉大量含糊的表述，也是判断文档有没有实际价值的唯一标准。

常见问题（FAQ）