bi 平台工作指南：用中小商家解决自助分析问题
中小商家上了 BI，最容易出现的反常识结果不是“看不到数据”，而是看板越来越多，经营问题还是要靠人重新导表、对口径、问运营。我的核心判断是：BI 平台的价值不在于做出多少张图，而在于让一个高频经营问题，能被同一套口径稳定地回答，并且有人根据答案采取行动。这篇指南从中小商家的实际约束出发，说明如何选问题、理数据、做看板、验证结果，以及什么时候不该急着买工具。
BI 平台通常承担数据连接、整理、计算、筛选、可视化和共享等工作。它能减少重复搬运数据的劳动，也能让业务人员更快地查看指标；但它不会天然知道商家最关心的问题，更不会自动判断一次销售变化究竟由流量、价格、库存、促销还是退款造成。
因此，我不会用“报表上线了”作为 BI 项目的完成标准。我会追问三个问题：谁在什么场景下使用它？看完之后要做什么决定？如果指标异常，谁负责核查和跟进？这三个问题没有答案，做出的看板很可能只是把旧报表换了一个展示方式。
没有专职数据团队的商家，往往同时面临人手有限、数据分散、系统更换频繁和业务节奏快等限制。此时，不宜一开始就做覆盖销售、营销、商品、库存、财务、会员的“大而全驾驶舱”。范围越大，字段映射、指标定义、权限维护和验证工作就越多，项目容易卡在数据准备阶段。
更稳妥的起点，是挑一个每周都会遇到、答案会影响经营动作、数据又相对容易拿到的问题。例如：“活动期间销售增长，是否伴随利润改善？”或者“哪些商品的补货优先级需要调整？”先让一个问题的分析路径跑通，再判断是否复制到其他场景。
我建议把 BI 成效拆成四段：数据能否按时到达、指标能否按统一口径计算、业务人员能否独立找到信息、团队是否根据结果采取行动。任何一段断掉，最终业务价值都会受限。比如数据每天更新，但关键商品的退款字段缺失，营销人员仍可能误判活动收益。
试点阶段可以记录一些朴素指标：一次周报从取数到完成花了多少小时；同一指标在不同报表中的数值差异有多大；业务人员从提出问题到找到可核对的数据需要多久；发现异常后，是否有人留下核查结论。它们不一定是全行业统一的考核标准，却能让商家判断试点是否真的改善了工作方式。
以线上零售为例，订单可能在电商后台，广告花费在投放平台，库存记录在进销存系统，会员信息在客户管理系统，退款又可能滞后于订单发生。每天看各自系统的数字并不难，困难通常出现在跨系统回答问题时：某个活动带来的销售增长，扣除退款、折扣和广告成本后是否仍然值得继续？
手工表格的优势是启动快、可随时调整，问题在于复制粘贴、筛选条件和公式可能由不同的人维护。一个同事把取消订单排除，另一个同事却把它算进订单量；一个报表按下单日期统计，另一个按支付日期统计。数值都可能是“对的”，但回答的并不是同一个问题。
销售额下降，并不直接等于需求下降。它可能来自访客减少、转化率降低、平均订单金额变小、热门商品缺货，也可能是退款集中增加。若只在看板上放一张销售额趋势图，商家能看到结果，却无法确定下一步该查哪一段。
因此，我更愿意把一个经营问题拆成“结果指标、过程指标、解释维度、可行动作”。例如，结果看净销售额；过程看访客、转化和客单价；解释维度按商品、渠道、日期或活动拆分；动作则可能是检查投放词、调整库存或复核活动优惠。拆分并不是为了堆指标，而是为了让指标之间存在可验证的分析路径。
启动时可以访谈实际使用报表的人，而不只问负责人想看什么。让使用者拿出最近一次“为了回答问题而手工处理数据”的记录，复盘他当时下载了哪些文件、改了哪些列、向谁确认口径、最后做了什么决定。这个过程往往比直接收集“想要的看板清单”更容易发现真实需求。
我会把候选问题按三个维度筛选：出现频率、决策影响、数据可得性。高频但不影响决策的问题，自动化收益可能有限；影响大但数据完全缺失的问题，可能需要先补采集；数据容易拿但从不影响动作的问题，则不一定值得优先投入。起步时优先选择三项都不差的场景。
| 筛选维度 | 需要回答的问题 | 适合优先试点的表现 | 暂缓的信号 |
|---|---|---|---|
| 出现频率 | 团队多久需要回答一次？ | 每天、每周或每次活动后重复出现 | 一年偶尔讨论一次，且没有明确负责人 |
| 决策影响 | 答案会改变什么经营动作？ | 影响补货、预算、定价或活动调整 | 只用于展示，没人因结果采取行动 |
| 数据可得性 | 关键字段是否能稳定取得并核对？ | 主要系统可导出，字段有责任人 | 关键环节依赖临时手工记录且长期缺失 |
订单数据重复、商品编码不一致、退款状态更新滞后，这些首先是数据治理问题，不是换一套可视化工具就会自动消失。工具可以帮助把规则固定下来，也可能提供清洗和关联能力，但规则仍要由业务方确认。比如商品编码映射谁来维护、历史退款如何归属、跨店铺商品如何识别，都需要明确责任。
如果团队现在连同一笔订单的唯一识别方式都没有，先把关键字段、业务定义和数据责任人整理出来，通常比急着搭十几张看板更划算。BI 项目并非必须等到数据“完美”才开始，但必须知道哪些字段可信、哪些字段存在缺口，以及缺口会怎样影响判断。
自助分析的重点不是让每个人都能随意改出一张图，而是让业务人员在可理解、可控的模型和口径下，独立回答常见问题。若销售额定义没有统一，给每个人更自由的字段组合，只会更快地产生多个版本的销售额。
合理的自助能力需要边界：核心指标由负责人确认，常用维度经过命名和说明，敏感数据按角色授权，业务人员可以在边界内筛选、下钻和组合。越是小团队，越需要简单清晰的规则，避免把“自由”变成无人维护。
连接成功只证明系统之间能传递数据，不代表字段含义一致。订单时间可能有创建、支付、发货和完成多个时间点；销售额可能含税、不含税、扣退款或未扣退款；广告平台归因销售额也不必然等于财务确认收入。若数据模型没有明确选择，图表能正常显示，结果仍可能答错问题。
我会把每个核心指标都写成一条能复核的定义：名称、计算方式、统计时间、包含和排除条件、更新频率、责任人。例如“净销售额”必须明确是按支付日期还是完成日期、是否扣除退款、优惠如何处理。定义不必写成复杂文档，但必须让两个使用者能够按同一规则复算。
图表多，往往意味着有更多内容可以浏览，不一定意味着决策更快。首页塞入几十个数字后，使用者可能仍然不知道哪一个变化值得追查。判断看板是否有效，我更关注它是否能回答一个具体问题、是否能定位异常发生在哪个商品或渠道、是否能缩短重复取数和核对时间。
一个实用的看板可以从少量核心指标开始，再根据复盘中出现的具体疑问增加细分内容。每新增一张图，都应能说清楚它回答什么问题、由谁使用、使用后可能触发什么动作。如果只能解释“这个图看起来有用”，先不要把它放进关键页面。
广告投入上升、销售额也上升，并不能单独证明增加预算带来了全部销售增长。同期可能有大促、价格调整、自然流量变化或库存恢复。看板能够提示时间上的共同变化，因果判断还需要结合活动记录、对照组、分渠道表现或其他业务证据。
对中小商家来说，不一定每次都要建立复杂的实验体系，但至少要避免把“同期发生”写成“因为某项动作所以增长”。复盘记录应区分观测事实、推测原因和已验证结论。例如：“活动期间净销售额上升”是观测；“活动带来增长”是解释；只有经过对照或进一步核查，才更接近验证后的结论。
商品新增、促销规则变化、平台字段调整、组织人员更换，都会让原有报表逐渐失真。若没有人检查数据延迟、空值、异常跳变和口径变更，团队可能在数周后才发现看板已不再反映业务现状。
轻量维护也需要有人负责。试点期间可以约定每周抽查关键指标，每月确认数据源和口径变更；遇到字段改动时，记录影响范围和修复时间。维护并不意味着必须建立庞大的数据治理部门，而是让“谁发现、谁确认、谁修复”有明确去向。
“我想更了解生意”不是一个可直接交付给 BI 的问题。更好的问题应包含对象、变化和决策方向，例如：“过去四周哪些商品的退款后销售额下降，是否需要调整补货或投放？”这句话把分析对象、时间范围、指标口径和可能动作都摆了出来。
如果一句话里包含太多目标，就拆成多个问题。比如同时问销售额、利润、用户复购、库存风险，可能需要完全不同的数据源和分析节奏。试点先选最紧急的一项，避免把数据准备任务扩张成无边界项目。
我建议用简单流程记录问题如何从数据走到动作：原始数据来自哪里，哪些字段需要清洗，核心指标如何计算，按什么维度拆解，最后由谁查看并采取什么行动。流程画出来后，团队通常能更早发现缺字段、重复口径和责任空白。
以活动复盘为例，结果层可以看退款后的销售额或毛利；过程层可以看访客、转化率和客单价；解释层可以按渠道、商品、活动时段拆分；动作层则记录预算是否调整、哪些商品补货或哪些优惠规则需要检查。层次清楚，团队才不会把一张总趋势图当成完整答案。
尤其要谨慎处理“效率指标”。如果商家只看销售额，可能忽略广告支出、优惠和退款；如果只看广告平台归因回报，也可能忽略自然销售与归因窗口差异。指标必须服务于决策，并且能与业务事实交叉验证。
中小团队不必一开始建设复杂的数据仓库，但要先统一常用的实体标识，例如订单编号、商品编码、渠道名称、日期和店铺标识。一个商品在不同系统里的名称可能不同，最好有可维护的映射关系，而不是每次靠名称模糊匹配。
核心指标也要有简明说明。下面是一个概念性定义示例，重点不是某个特定工具的语法，而是展示“净销售额”需要把退款处理规则说清楚。正式计算时还要结合商家的订单状态和财务口径。
净销售额 = 已支付商品金额
已确认退款金额
按业务规则处理的取消金额
订单转化率 = 支付订单数 / 有效访客数
平均订单金额 = 净销售额 / 支付订单数
如果“有效访客数”无法稳定取得，或退款金额归属时间没有统一，这些公式就只能作为讨论起点，不能直接当成跨团队标准。模型的目标不是追求技术复杂，而是让计算规则可以解释、抽查和维护。
看板第一次完成后，应挑一段确定的时间范围，随机抽查若干订单或商品，逐项对照源系统和计算规则。抽样不是统计学意义上的全面审计，但能发现常见问题，例如重复订单、退款时间错位、商品编码映射遗漏和筛选条件不一致。
试点还要验证不同角色是否能独立完成任务。让实际使用者从一个常见问题开始，不提供逐步代操作，观察他能否找到正确指标、调整时间范围、下钻到必要维度，并解释结果。若必须由搭建者坐在旁边才能完成，就说明模型说明、界面设计或培训仍需改进。
选 BI 平台时，我会把评估拆成数据接入、指标维护、业务使用、权限安全、实施支持和持续成本。功能演示中能做出的图表，不一定适合真实系统的数据结构；产品写明支持某类连接，也不等于商家的具体账号、字段和权限一定无需处理。
以九数云这类面向数据分析的平台作为候选进行评估时，我会先拿自家的一小段真实数据做验证，而不是仅凭产品介绍判断适配度。可通过九数云官网了解其公开信息，再逐项确认数据源是否覆盖、更新频率是否满足要求、指标能否按业务口径维护、普通运营人员是否能独立使用，以及实际费用是否包含必要的实施和维护工作。
| 评估项 | 建议现场验证 | 需要警惕的情况 |
|---|---|---|
| 数据接入 | 用真实账号和一段实际数据检查字段、更新和异常处理 | 只展示演示数据，无法说明真实连接限制 |
| 口径维护 | 尝试创建或修改一个业务指标，并检查权限与版本管理 | 关键指标只能由少数人临时手工维护，缺少说明 |
| 业务使用 | 让运营人员独立完成筛选、下钻和导出等常用任务 | 每次查看都要依赖实施人员代操作 |
| 成本与支持 | 询问软件、实施、培训、维护和扩展的费用边界 | 只比较基础报价，忽略数据整理和长期维护投入 |
| 权限安全 | 核对角色、数据范围、导出能力和企业内部要求 | 权限配置无法满足实际岗位隔离需要 |
下面以一家经营多个商品的线上小店为例，比较活动前后各14天的数据。数据全部是情景模拟，用来演示如何拆解指标，不代表真实客户业绩、行业平均水平或任何平台的效果。实际商家应以自己的源系统、财务口径和业务记录为准。
假设活动前14天，退款后净销售额为15.6万元，支付订单1260笔，访客4.2万人，广告花费2.1万元。活动后14天，退款后净销售额为16.6万元，支付订单1400笔，访客5.6万人，广告花费3万元。仅看销售额，活动后增加了1万元；但仅凭这个结果，还不能判断活动值不值得继续。
活动前订单转化率约为1260除以42000，即3.0%；活动后约为1400除以56000，即2.5%。访客增加约三分之一，订单只增加约一成，说明新增流量没有按原有比例转成订单。平均订单金额则从15.6万元除以1260，约123.8元，降至16.6万元除以1400，约118.6元。
这并不自动证明活动失败。促销可能带来较低客单价但扩大新客规模，也可能是流量质量变化、商品组合变化或库存结构变化造成的。它说明下一步应该分渠道、商品和活动时段检查，而不是只盯着销售额总数。
假设广告平台记录的归因销售额从8.4万元增至10.5万元，那么简单计算的归因销售额与广告花费之比，从4.0降至3.5。投放成本增加约42.9%，归因销售额增加25%。这个比值可以提示需要进一步核查，但它仍不是利润率，也不能单独证明增加预算造成了多少净新增销售。
归因规则可能包含不同时间窗口和触点，广告平台归因数据也未必与商家财务确认的净销售额完全一致。因此我会把两类数字并列展示：一类是店铺经营口径的净销售额、订单和退款；另一类是投放平台的花费与归因表现。先解释两套口径，再讨论预算调整。
这组模拟数据支持的事实只有：访客和订单上升，净销售额小幅上升，转化率、平均订单金额和简单投放比值下降。它不能直接支持“活动带来了利润增长”或“广告预算应该减少”这样的结论。下一步还要看退款率、毛利、商品缺货、渠道构成、活动折扣和自然流量变化。
如果活动中某个主推商品出现缺货，转化率下降可能与供给有关；如果新增访客集中在低意向渠道，问题可能在投放定向；如果平均订单金额变低，可能是折扣组合改变了购买结构。每一种解释都需要对应数据或业务记录核对，不能只凭一张总览图推断。
我会先挑出访客增长最多的两个渠道，再对照它们的转化率、退款率和订单金额；然后查看销售额变化最大的商品，确认库存、价格和活动规则是否发生变化；最后将调整预算的决定与实际毛利、净销售额和新客质量一起复盘。每一步都只追一个可验证问题，避免把分析变成无穷无尽的下钻。
如果样本量很小，单日数据波动大，就不要因为一天的异常马上调整预算。可以按周或按完整活动周期观察，并在看板中保留活动开始、价格调整和库存变化等注释。时间范围选得是否合适，往往比图表类型更影响结论。
若主要系统都能导出订单、商品、广告或库存数据，但需要人工拼接，可以先选一个高频问题，限定一家店铺、一段时间和少数核心指标。先整理字段字典和商品映射，再把取数、口径核验和看板制作串成固定流程。
这个阶段不需要一次性连接所有系统。优先验证数据接入是否稳定、刷新周期是否够用、业务人员能否复现分析步骤。如果每周复盘一次就足够，未必需要追求实时刷新；更新越频繁，通常也意味着更多连接和维护要求。
如果销售额、订单数和退款率在不同报表中经常对不上，应先暂停扩展看板，集中统一核心指标。选择一个业务负责人确认定义，记录统计时间、过滤条件和数据责任人，再用历史样本抽查是否一致。
在口径尚未统一时，可以把不同来源的数字并列展示并明确标注来源，暂时不要合并成看似统一的“总指标”。承认差异并追查原因，通常比强行拼成一个数字更安全。指标规则稳定后，再把确认过的定义沉淀到平台和业务文档里。
若缺少商品编码、退款状态、渠道标识或库存变更记录，BI 只能展示有限结果。此时应先判断缺失数据是否可通过系统导出、流程调整或人工登记补齐，并明确由谁维护。对于影响决策的关键字段，先把采集流程建立起来，往往比购买更多可视化功能重要。
可以把不可用字段标记为“暂缺”或“待核验”，避免用户误把空值当成零。还可以约定数据质量检查，例如每周检查新增商品是否进入映射表、退款记录是否及时更新、关键数据源是否按约定日期刷新。规则简单但持续执行，比一次性清洗更有效。
管理者的看板通常需要快速回答经营结果是否偏离预期、哪些问题需要关注；运营人员则需要按渠道、商品、时间和活动拆解原因。把所有细节都放在一个页面，会让管理者难以抓重点，也会让运营人员缺少必要的下钻路径。
可以用一个简洁的总览呈现少量核心结果，再为业务岗位提供围绕具体问题的分析页面。权限设计也应匹配岗位需要，尤其涉及客户、员工或财务数据时，不应默认所有人都需要看到原始明细。
预算有限时，选择功能最多的平台不一定合适。要评估数据准备需要谁做、指标变化谁维护、系统升级后谁排查、业务人员要花多久学习。平台订阅只是总成本的一部分，持续投入的人力往往也要计算。
如果团队每月只做少量固定报表，普通表格和明确的模板可能暂时够用；如果同一问题每周重复取数、多个岗位反复核对，或管理决策需要更细的交叉分析，BI 的自动化和共享能力才更可能带来持续收益。适合的工具取决于工作负担，不取决于同行是否已经购买。
无论评估九数云还是其他 BI 平台，都建议用一项真实业务任务进行验证：导入或连接一段真实数据，按企业口径算出核心指标，让实际使用者独立完成筛选与下钻，并抽查结果是否能回到源数据核对。测试过程应记录哪些步骤需要供应商支持、哪些步骤团队可以自行维护。
验收不应只问“图能不能做出来”，还要问数据更新失败是否可发现、字段变化如何处理、权限能否按岗位配置、指标说明如何共享、费用是否随用户数或数据规模变化。具体合同、服务和功能以供应方当前说明为准，发布前或采购前应直接核实，不要把营销页面当作项目承诺。
如果商家做的是每日经营复盘，数据每天更新一次或每天固定时段更新，可能已经够用；若要根据库存变化即时调整广告或补货，延迟就可能影响决策。先问“晚几个小时会造成什么损失”，再决定是否需要更高频刷新。不要把实时当成不需论证的默认需求。
更新频率越高，数据源稳定性、接口限制、异常告警和运维要求也可能增加。若供应链和业务流程本身每天只更新一次，追求分钟级刷新并不能弥补源数据的滞后，反而会制造错误的精确感。
试点时不需要先把企业所有历史字段都整理完，但影响经营结论的核心指标必须有明确口径。对暂时不能统一的边缘字段，可以标注来源和限制，先在小范围内使用，后续再根据需求决定是否标准化。
例如，净销售额和退款处理规则直接影响活动判断，优先统一；某些低频商品分类的历史映射，若当前不影响决策，可以暂列待办。取舍的原则不是“先做完所有数据治理”，而是“先保证当前决策不会被关键口径误导”。
业务人员需要灵活筛选和下钻，但自由度越高，误用字段、泄露明细或产生不同口径的风险也越大。试点初期可以开放常用维度和经过说明的指标；等团队理解口径、知道如何核验后，再逐步增加自定义分析能力。
对于客户信息、员工信息、财务数据等敏感内容，应先明确谁有查看和导出的必要性。分析便利不能替代权限治理，尤其当看板可以共享或导出时，更要确认权限规则是否覆盖实际使用场景。
继续用表格并不天然落后。数据源少、报表频率低、公式稳定、使用者很少时，结构清楚的表格模板可能是最经济的方案。问题在于，若每周都要重复下载多个文件、手动合并、反复核对，且不同岗位各自维护版本，隐性工作量会逐渐超过工具投入。
采购平台适合需要持续连接多源数据、稳定共享分析结果、让业务人员重复使用分析模型的团队；若关键数据质量很差、业务规则频繁变化且没人负责维护，采购后可能只是把混乱搬到新系统。自建方案则更依赖技术维护能力，也应把后续升级、权限和人员交接考虑在内。
| 当前状态 | 较合适的做法 | 主要收益 | 主要代价或风险 |
|---|---|---|---|
| 报表少、口径稳定、手工工作量低 | 使用规范化表格模板，先统一字段和责任人 | 启动快，新增工具成本低 | 跨系统分析和多人协作能力有限 |
| 重复取数频繁、多个系统需要关联 | 选择一个场景试点 BI，验证数据连接与维护成本 | 减少重复整理，分析流程可复用 | 前期要投入数据整理、建模和培训 |
| 核心口径混乱、关键字段缺失 | 先治理指标定义和数据采集，再扩展自动化 | 降低错误分析风险，明确数据责任 | 短期内可视化成果较少，需要业务配合 |
| 数据量大、权限要求复杂、已有技术团队 | 评估采购、自建或混合方案，并做真实任务验证 | 有机会适配复杂流程和内部要求 | 架构、运维、权限和持续投入更复杂 |
我建议把项目拆成几个可停止、可调整的阶段。第一阶段确认问题与数据来源；第二阶段完成口径和样本核对；第三阶段让业务人员实际使用；第四阶段评估是否扩大范围。每一阶段都设定“继续、调整或暂停”的条件，而不是默认项目必须把最初设想全部实现。
例如，若两周后仍无法稳定取得关键数据，先暂停看板扩展，解决数据责任问题；若指标可信但业务人员无法独立使用，优先改说明和流程；若使用频率低且没有决策动作，应重新评估问题是否值得自动化。及时停止低价值工作，是资源有限团队的重要能力。
找出最近反复出现的一项经营问题，把它写成一句可回答的问题，并指定实际使用者和决策负责人。验收标准不必复杂，可以包括：关键指标定义已确认、历史数据通过抽样核对、使用者能独立完成一次分析、复盘结论有人负责跟进。
同时确认这项问题的决策频率和业务窗口。如果商家每月才做一次活动复盘，试点周期就应覆盖一次完整复盘；如果要处理每日库存预警，则需要验证数据更新节奏和异常处理能力。周期应匹配业务，而不是为了赶项目日期随便设定。
把来源系统、字段名称、统计时间、过滤规则和数据负责人记录下来。对于关键字段，选择真实样本回源核对；对于暂时缺失的数据，明确其影响，避免在结果中悄悄忽略。这个阶段的产出不是一张漂亮的仪表盘，而是一份团队认可的最小数据说明。
需要特别检查时间字段、订单状态、退款、优惠、商品编码和渠道名称。它们常常决定销售额、转化率、退款率和投放表现是否可以比较。若不同来源的时间定义不同，应在看板和说明中明确，不要把不同口径的曲线直接拼成连续趋势。
围绕问题保留必要指标和维度，先让真实使用者完成一次任务。观察他是否知道从哪里开始、筛选条件是否清晰、指标说明是否看得懂、遇到异常是否知道回到哪里核验。记录卡点并优先修复实际阻碍，而不是在试用阶段不断增加装饰性图表。
若评估九数云或其他候选平台，可以在这一阶段用相同的数据、相同的指标定义和相同的任务流程比较，而不是一个平台用真实场景、另一个平台只看演示。把连接、计算、核对、使用和维护所需的时间都记下来，比较才有意义。
检查数据刷新是否稳定、指标差异是否已解释、业务人员是否实际使用、分析是否带来明确行动。若只缩短了取数时间，却没有改变任何决策，也不必立即否定项目；要判断这是不是该场景的合理价值，还是问题本身不值得进一步投入。
若结果可靠且重复需求明确，再扩展到相邻场景，例如从活动复盘扩展到商品表现，或从销售总览扩展到库存周转。扩展时复用已验证的数据模型和维护规则，而不是重新复制一套各自为政的报表。
我认为，对中小商家而言，自助分析成熟的标志不是每个员工都能随时拖拽字段，也不是管理层拥有一块实时跳动的大屏。更实际的标志是：重复问题不再每次从零取数，关键指标能被不同岗位用同一口径解释，异常发生后知道先查什么、由谁核验，以及结论如何转成行动。
因此，下一步不必先列出一份庞大的 BI 功能清单。先挑一个每周都会困扰团队的问题，写下需要的数据、定义、使用者和决策动作；再用真实样本核对一次。如果这条链路可以稳定重复，才值得把它沉淀到平台并逐步推广。如果链路仍然断在数据缺失或没人负责，先修补那一段，往往比继续加图表更有价值。
读者评论
先从高频且会影响经营动作的问题入手，比一开始搭建覆盖所有业务的大看板更适合人手有限的商家。
文中强调统一指标定义很关键，尤其是统计时间、退款和取消订单的处理规则，否则不同报表即使都能出数，也未必能相互比较。
漏斗图和数据质量分类都注明是情景模拟，这一点很重要；实际试点仍应抽样核对源数据，并跟踪分析结果是否形成后续动作。