电商 CRM 系统搭建最容易踩的坑，不是少买了一个功能，而是先买系统、后问业务要解决什么。结果往往是会员标签越来越多，短信、企微、站内信各自能发，团队却仍说不清同一个用户是谁、为什么收到这条消息，以及这次触达有没有带来增量。本篇从业务链路出发，拆解私域触达系统的搭建顺序、数据基础、规则设计和验证方法。
我判断一套电商私域触达系统是否搭得合理，通常不先看功能菜单，而是沿着一条业务链路检查：用户从哪里来，系统如何识别他处于什么状态，什么条件触发动作，动作通过哪个渠道执行，触达结果如何回流，团队根据什么决定继续、调整或停止。
如果这条链路有一个关键环节断开，系统就容易退化成“消息发送器”。例如，用户买过什么无法准确关联，运营只能按最近一次点击打标签；触达后没有反馈数据，团队便用发送量和点击量代替经营结果；用户已经退订，名单却没及时同步，后续还可能再次被触达。
因此，私域触达系统的核心不是增加触达次数，而是提高“在合适的时间，对合适的人，执行合适动作”的可控性。 CRM、会员系统、营销自动化和数据分析工具可能由不同产品承担，但业务上必须形成闭环。
我建议按“流程，数据，规则，渠道，复盘，扩展”的顺序推进。先确认要解决的业务问题，再确定需要哪些数据和规则，最后评估现有系统能否支持。这个顺序看起来比直接采购慢，但能减少把预算花在暂时用不到的功能上。
这里有一个容易被忽略的判断：“系统里有这个功能”不等于“业务已经具备这个能力”。一个自动化流程看起来只需要几步配置，但如果身份匹配、退订同步、订单状态回传或责任分工没有定义，流程只是把不确定性自动化。
上线前可以用六个问题做快速检查：用户是谁，数据从哪里来，触达为什么发生，消息由哪个渠道执行，用户发生什么反应，团队如何据此调整。六个问题都能找到明确答案，才说明系统具备了最基本的运营闭环。
反过来，如果团队只能回答“我们能发短信”“系统支持标签”“可以做自动化”，却无法说明用户进入和退出流程的条件，这套系统就还没有形成可管理的触达能力。
设想一家同时经营电商平台店铺、自有商城和社交渠道的商家。用户可能在店铺下单，在社交渠道咨询，在会员中心领取权益，又在售后渠道发起服务请求。每个系统都保存了一部分记录，但这些记录未必能可靠地拼成同一个用户。
运营看到的可能是三条记录：一个有订单的账号、一个留过手机号的会员、一个咨询过的社交账号。它们也许属于同一个人，也可能不是。若系统直接把相似手机号、昵称或设备信息当作确定身份，错误合并会把甲用户的订单和乙用户的触达规则混在一起；若完全不做关联，团队又会把同一个人当成三个人重复运营。
这说明数据整合不是“字段越多越好”，而是要管理匹配依据和匹配置信度。确定性身份可以按业务规则建立关联；无法确认的身份应保留为未匹配或待核验状态，不应为了让报表好看而强行合并。
短信、邮件、站内消息、社交渠道私信和客服跟进，可能承担不同任务。有些渠道适合服务通知，有些用于活动提醒，有些适合一对一沟通。系统搭建时不能只问“支持哪些渠道”，还要问每个渠道能识别谁、能回传什么、能否停止触达、失败后如何处理。
渠道越多，越需要统一编排。否则，同一个用户可能在一天内收到多个渠道的相似消息，而各渠道运营人员都认为自己只发了一次。频次控制应当尽量从用户维度统筹，而不是只在单个活动或单个渠道里设置。
不少团队一听“数据打通”，就把目标设成全渠道、全字段、实时同步。这可能让项目周期和维护成本迅速上升，但并不一定改善最先要解决的业务问题。对一个刚开始搭建复购运营的团队来说，先把订单状态、购买时间、商品类别、用户授权和退订状态定义清楚，可能比接入大量浏览行为更有价值。
数据建设的优先级，应由决策价值决定，而不是由“能不能接进来”决定。如果某个字段不会改变人群判断、触达内容或停止条件，就应该先问清楚为什么要收集、谁维护、多久更新一次，再决定是否接入。
以“购后服务提醒”为例，输入不只是订单日期，还可能包括订单是否付款、是否取消、是否发货、是否退款、商品类型、用户是否已收到服务通知，以及用户当前是否允许接收该类信息。触发条件应按业务实际定义，不能只用“下单后第七天”这种单一时间条件。
如果订单已取消，提醒应停止；如果用户已经发起售后，自动化流程可能需要暂停并交由服务团队接管；如果订单状态尚未同步，系统需要有等待或异常处理机制。这样的边界设计，往往比消息文案本身更能决定用户体验。
系统演示通常会展示标签、自动化画布、报表和渠道接入，容易让人以为功能越多，落地越快。但如果采购前没有定义场景，团队可能买到很多“看起来以后会用”的能力，却仍然不知道首个流程由谁维护、数据异常由谁处理。
采购前建议把需求分成三类：必须能力、可后置能力和暂不需要能力。必须能力必须对应正在解决的业务问题；可后置能力可以在试点成功后评估；暂不需要能力则不应成为当前选型的主要加分项。
标签数量多不等于判断质量高。一个“高意向用户”标签，如果没有定义来源、更新时间、有效期和退出条件，就会变成长期不更新的静态标记。用户的偏好、购买周期和服务状态都可能变化，过期标签不仅降低判断准确度，还会让团队误以为系统掌握了更多信息。
我更重视标签能否改变动作。每个标签都可以追问四件事：它由什么数据生成，多久更新，谁能修正，命中后对应什么运营决策。如果答不出来，先不要把它加入核心人群规则。
自动化适合处理明确、重复、可验证的规则，例如某个订单状态变化后更新用户状态，或在满足条件后创建待执行任务。但涉及投诉、复杂售后、敏感偏好或身份不确定的情况，通常需要人工判断或明确的暂停机制。
更稳妥的做法是先列出自动化流程的异常分支：数据缺失怎么办，状态冲突怎么办，用户重复进入怎么办，渠道发送失败怎么办，用户中途退订怎么办。没有异常分支的自动化流程，不是简洁，而是把风险留到了线上。
用户看到消息后下单，不一定意味着消息创造了这笔订单。用户可能本来就准备购买，也可能受到价格、促销、季节性需求或其他渠道影响。把触达后的所有成交都算作系统带来的增量，会高估效果，也会让后续预算决策失真。
至少要分清三种口径：归因成交，即在既定归因规则下与触达相关的成交；观察到的成交，即触达后窗口内发生的购买；增量成交，即与合理对照相比多出来的部分。三者回答的问题不同，不能混为一个“转化率”。
打开和点击是过程信号，不代表用户体验良好。若团队只优化点击率，可能倾向于更强刺激的标题、更频繁的提醒，却忽略退订、投诉、客服压力和长期复购变化。
每个触达场景都应同时观察正向结果和风险信号。特别是当某项指标短期上涨时，要检查它是否伴随着退订增长、负面反馈增加或其他渠道转化下降。单项指标改善不一定代表整体经营变好。
实时同步并非所有场景的必要条件。对即时服务通知、库存变化或订单状态驱动的动作，延迟可能影响体验；对月度复购分析、长期人群观察，较低频更新也许已足够。同步频率需要与业务时效、数据成本和故障恢复能力匹配。
如果团队没有处理重复事件、乱序事件和同步失败的机制，单纯追求实时，反而会让问题更快地传递到触达端。先定义可接受的数据延迟和异常告警，再决定技术方案。
私域触达至少涉及用户、账号、订单、商品、事件、渠道授权和触达任务等对象。它们之间有关联，但不是同一类数据。把所有信息都塞进一张用户表，初期看似方便，后续却容易出现一人多单、一单多商品、状态更新覆盖和来源无法追溯等问题。
每个核心字段建议记录定义、来源、更新频率、责任人和使用场景。例如，“最近购买时间”要说明是支付时间、完成时间还是签收时间；“可触达状态”要说明按哪个渠道、哪种用途判断；“活跃用户”则必须有明确的行为窗口和事件范围。
| 数据对象 | 需要回答的问题 | 常见字段示例 | 设计重点 |
|---|---|---|---|
| 用户与身份 | 这条记录对应谁，匹配依据是什么？ | 内部用户编号、渠道账号、会员编号 | 保留身份来源和匹配状态，不确定时不要强行合并 |
| 订单与商品 | 发生了什么交易，当前处于什么状态？ | 订单编号、商品类别、支付时间、退款状态 | 明确状态口径，避免取消、退款和完成订单混用 |
| 行为事件 | 用户做了什么，行为发生在何时？ | 浏览、收藏、咨询、加购、下单 | 区分事件发生时间、采集时间和回传时间 |
| 渠道与授权 | 能否通过此渠道执行特定触达？ | 渠道状态、授权记录、退订状态 | 按渠道和用途管理，状态变化要能及时生效 |
| 触达任务 | 为什么发送，发送给谁，结果如何？ | 规则编号、渠道、发送时间、回执结果 | 保留决策记录，支持追查重复发送和异常任务 |
身份匹配可以分成确定关联、规则推定和未知三类。确定关联来自经过确认的账号关系或业务主键；规则推定需要说明依据和置信边界；未知则应保留为独立记录，直到有足够依据再关联。
团队还要定义合并与拆分机制。误合并发生后，能否撤销关联、恢复原记录、追溯受影响的触达任务？如果答案是否定的，身份匹配就不能仅靠后台自动合并来解决。关键不是追求用户数更少，而是让错误关联的风险可控。
一条可执行规则至少应包括人群条件、触发事件、排除条件、渠道条件、执行动作、频次限制和退出条件。用自然语言写清楚后，再转换成系统配置，可以减少业务人员和技术人员对“符合条件”的不同理解。
例如，“近一段时间买过某类商品的用户”还不够完整。需要继续明确时间窗口、订单状态、商品分类口径、是否排除退款用户、是否排除已进入售后流程的用户，以及触达后用户何时退出该人群。
触达系统不是单靠运营团队维护。数据团队可能负责字段质量和同步，技术团队负责接口与任务稳定性，运营负责业务规则和内容，客服负责服务承接，管理者则负责目标与风险边界。职责没有落到人，异常就容易在团队之间来回转交。
建议为每个重点流程设一个业务负责人，并为关键字段指定维护责任人。系统出现身份冲突、授权状态延迟或订单事件重复时，团队需要知道谁有权暂停流程、谁负责排查、谁决定恢复。
适合优先自动化的任务，通常同时具备三个特点：触发条件明确、处理步骤重复、错误后果可控。例如标准化的订单状态同步和任务提醒，通常比需要理解用户复杂诉求的营销判断更容易自动化。
如果误触达可能造成投诉、隐私风险或较大服务成本，就应提高人工审核、灰度发布或暂停机制的要求。自动化程度不是越高越先进，而是要与规则可解释性和风险承受能力匹配。
下面是一个情景模拟，用于说明如何设计试点，不代表真实客户数据，也不代表行业平均水平。假设一家经营日常消费品的电商团队，订单、会员和社交渠道数据分散，运营希望评估“购后复购提醒”是否值得自动化。
团队没有一开始接入所有行为数据，而是先选定一个可解释的场景：对符合条件的已完成订单用户，在约定观察窗口内检查是否再次购买；若用户符合触达条件且没有退订、投诉或未结服务问题，再进入提醒流程。具体时间窗口应结合商品消费周期和业务数据验证，不应直接套用行业通用天数。
试点假设不是“自动化能提升复购”，而应写成可以被验证的判断。例如：对符合条件的用户，在购后某个时间窗口提供与购买品类相关的提醒，相比未触达的相似用户，是否带来更高的增量购买，同时不会让退订或投诉明显恶化。
这里至少要预先约定观察窗口、目标人群、排除条件、对照方式、成交定义和风险指标。若活动价格、优惠券或大促节点发生变化，也要记录下来，避免把外部因素带来的变化误算成流程贡献。
假设进入试点的人群有8,000人，其中4,000人符合触达组条件，另外4,000人作为对照组。情景模拟设定：触达组有3,600人成功送达，观察窗口内购买160人；对照组中有150人购买。触达组的购买率约为4%，对照组约为3.75%，差值为0.25个百分点。
这个差值不能直接证明系统创造了确定的增量。还要检查分组是否可比、样本是否随机、是否存在其他促销影响、购买归因窗口是否一致，以及这个差异是否超过数据波动范围。若试点规模小、购买事件少，结果可能不足以支撑扩量决策。
更重要的是，试点不仅要看购买。假设触达组同时发生退订、投诉或客服咨询增加，就要把这些成本放进判断。即使短期购买率略高，如果用户体验或服务成本明显变差，也未必值得复制。
试点复盘要拆开看：符合条件的人群是否准确，授权与排除规则是否正确，消息是否成功送达，送达后有没有互动，互动后是否发生业务行为。若结果不理想，不能一律归因于文案，也不能因为系统发送成功就认为流程有效。
例如，符合条件人群偏少，可能是订单状态口径或排除规则过严；送达率偏低，可能是渠道数据质量问题；互动较多但没有购买，可能是商品、时机或优惠策略不匹配；购买变化存在但退订增加，则需要评估长期代价。
试点数据需要能按人群、时间、渠道和订单状态切片查看，并能追溯指标口径。团队可以根据现有技术环境选择数据分析工具、报表系统或自建分析流程。比如，可以将 九数云作为评估数据分析方案时的一个候选对象，重点核对其当前产品能力、数据源接入方式、权限管理和费用是否符合实际需求；具体功能与适用范围应以官方最新资料及实际验证为准。
分析工具不能代替 CRM 的身份判断、授权管理和触达执行，也不能自动解决指标口径不一致。它更适合帮助团队把数据来源、计算逻辑和结果变化看清楚。选型时，建议用一份真实但脱敏的试点数据验证接入、刷新、权限、筛选和导出能力，而不是只看演示报表。
试点的结果不只有“成功扩量”或“失败停止”两种。若人群定义准确但效果不确定，可以延长观察或扩大样本；若渠道送达差但用户价值明确，可以先修复渠道和身份数据；若正向结果有限而风险指标变差，应修改频次、内容或触发窗口；若关键数据无法稳定回传，则先补数据治理，不要急着增加自动化流程。
最有价值的试点不是证明某个工具一定有效，而是尽早识别链路中最值得修复的环节。
如果团队连同一个用户在不同系统中如何识别都说不清，优先建立身份映射规则和数据来源清单。先确认哪些身份可以确定关联，哪些只能推定，哪些保持未知。不要为了追求“全量用户视图”而把不可靠的数据硬合并。
短期内可以先选一个数据相对完整的业务入口做试点，同时建立匹配异常的人工核验流程。身份质量达到基本可控后，再扩大跨渠道触达范围。
如果会员身份和订单状态基本可用，但运营仍靠表格导出、人工筛选、手动发送，可以先梳理重复频率高、规则稳定、错误后果可控的任务。自动化优先解决重复劳动和漏执行，不必一上来覆盖所有营销场景。
先选一个低风险流程，保留人工复核和暂停能力。上线后重点观察任务执行是否稳定、名单是否重复、异常是否可追溯，再决定是否扩大自动化范围。
如果用户已经会从多个渠道接收信息，新增渠道未必是第一优先级。先盘点渠道之间是否共享用户标识、频次记录和退订状态，明确同一用户在不同渠道触发时如何排序、合并或抑制。
还要为用户退出流程设置可验证机制。退订、投诉、售后处理中或授权状态变化时，系统是否能及时停止相应触达？能否查到停止发生的时间和依据？这比再增加一个发送入口更值得优先解决。
选型时不要只比较功能列表。让供应方围绕一个真实业务场景演示：如何接入订单状态，如何判断用户身份，如何处理退订和重复进入，如何记录发送与回执，如何暂停异常流程，如何复算结果。
同时确认数据迁移、接口维护、权限设置、审计记录、服务支持、合同范围和后续费用。对于关键能力，应通过试用、概念验证或书面确认核实，不要把口头承诺直接当成已具备能力。
规模小、技术资源有限的团队，适合从字段少、流程短、责任清晰的方案起步。重点是确保名单来源可靠、触达有授权依据、结果能复盘。系统复杂度若超过团队维护能力，流程很容易在人员变动后失效。
可以把维护成本写进评估：每个流程每月需要多少人工检查，数据异常由谁处理，规则变更需要多久，报表口径由谁负责。维护成本不是上线后的附属问题，而是系统总成本的一部分。
当多团队、多渠道和多个业务场景同时运行时，分散规则会逐渐产生冲突。这时需要更明确的统一用户视图、规则治理、权限分工和跨渠道频次管理，但依然要避免把“集中化”误解为所有数据必须实时、所有规则必须放在同一平台。
扩展阶段要优先统一标准和责任，再决定系统是否集中。数据架构可以分层建设，触达执行也可以由不同系统承担，但用户状态、指标口径和治理规则应当尽量可解释、可追踪。
全渠道打通的优势是理论上能形成更完整的用户视图，但实施周期、接口协调和数据治理成本通常更高。单场景验证速度快、问题边界清晰，但只能回答有限问题，不能据此宣称整个私域体系已经成熟。
如果业务问题明确、数据来源有限，先做单场景验证更稳妥；如果跨渠道重复触达已经造成明显体验问题，且团队具备数据治理能力，就应优先处理关键身份和频次协调，而不是继续扩展孤立流程。
细分人群有机会让内容更贴近用户，但每增加一种分层，都会增加字段依赖、内容版本、效果评估和规则维护成本。分群是否值得，不取决于它是否“更精细”，而取决于它能否改变下一步行动，并且带来可验证的收益。
建议先从少量业务状态开始，再根据数据表现增加细分。若两个群体的策略完全相同，或者团队无法解释它们之间的差异，就没有必要为了看起来精细而把它们拆成两套流程。
高时效场景需要更快的数据回传，但实时链路也会增加故障监控、重试和重复事件处理的要求。低时效场景可以接受批量更新，以换取较低复杂度和更易维护的流程。
决策时应先定义业务允许的延迟范围。例如，服务状态提醒与长期复购分析对时效的要求就可能不同。没有明确时效目标时，不建议把实时同步作为默认采购条件。
自动化可以降低重复操作，但规则越复杂，错误可能传播得越快。高频、稳定、低风险任务适合提高自动化程度；涉及身份不确定、敏感信息、投诉或复杂售后的流程，应保留人工审核、暂停开关和操作记录。
真正成熟的系统不是把人工全部移除，而是让人工把时间放在需要判断的地方，同时让系统可靠地处理重复、可定义的步骤。
自建方案的控制力较强，适合有稳定技术团队、明确数据架构和持续维护能力的组织；采购方案可能更快启动，但要评估接口、权限、数据可迁移性和服务边界；组合使用则可能适合已有多个系统、希望逐步整合的团队，但必须先约定主数据来源和指标口径。
不要只比较一次性采购价格。还要考虑接口改造、培训、数据治理、流程维护、人员变动后的交接，以及未来迁移成本。对很多团队来说，最贵的并不是买了功能，而是买了之后没人能稳定维护。
| 决策维度 | 偏向快速启动 | 偏向高控制力 | 需要警惕 |
|---|---|---|---|
| 业务需求 | 先做一个明确场景 | 跨团队统一编排 | 场景尚未定义就建设全量平台 |
| 数据能力 | 使用现有稳定数据 | 统一身份和多源治理 | 数据质量未验证就做复杂分群 |
| 技术资源 | 配置化流程与有限接口 | 可持续维护的自建或组合架构 | 把长期维护负担留给单一人员 |
| 风险控制 | 人工复核与小范围试点 | 完善权限、审计和自动拦截 | 自动化上线后没有暂停和回滚机制 |
| 效果验证 | 先建立基线和过程指标 | 开展对照与长期增量评估 | 把归因成交直接等同于增量成交 |
涉及个人信息处理、营销授权和平台规则时，应根据业务所在地、数据类型和实际流程核对现行法律法规及平台要求。本文提供的是系统设计检查思路，不构成法律意见；具体义务应由企业法务或专业人士结合实际业务确认。
上线前最好留下一份版本记录：规则何时修改、修改了什么、由谁确认、预期影响是什么。这样，当指标出现变化时，团队能追溯是用户行为变化、活动策略变化，还是系统规则变化导致的。
我认为，电商 CRM 私域触达建设最值得记住的一条原则是：系统不是把用户数据和消息渠道堆在一起，而是把一次运营决策变成可解释、可执行、可评估、可纠正的流程。
真正决定效果的，往往不是某个标签有多精细，也不是自动化画布有多少节点，而是身份是否可靠、状态是否及时、规则是否能解释、用户是否可以退出、结果是否能和对照基线比较。
如果你正在从零搭建，可以先用一周时间完成三件事：选定一个明确场景，整理该场景必须的数据字段，画出触发、排除、执行和退出流程。先让运营、数据、技术和客服对同一条链路达成一致，再决定是否采购或改造系统。
如果已经有系统但效果不清楚，不要先加更多人群和消息。先核对身份匹配、指标分母、授权状态和对照基线，再找出链路中最薄弱的节点。必要时暂停效果无法解释、风险无法控制的流程。
如果团队准备扩展到多渠道和多场景，应先建立统一口径、责任分工和异常处理机制，再逐步增加自动化。系统搭建不是一次性交付，而是持续验证业务假设的过程；最好的起点不是功能最多，而是第一个能安全运行、结果可复盘的场景。
我在筹备私域运营时，团队里有人主张先采购系统，也有人认为先把流程和数据理清。预算有限的情况下，我该怎么排顺序，才能避免买完系统才发现业务需求没想清楚？
建议先梳理业务流程，再选系统。CRM 解决的是记录、管理和执行问题；如果团队还没明确用户从哪里来、什么情况下触达、触达后由谁承接，系统只会把原本模糊的规则自动化。可以先画一条最小链路：用户进入，身份识别，状态判断，触达，承接，结果记录。
以新客欢迎为例，先写清触发条件、发送内容、客服承接人和停止条件，再评估系统能否支持这些动作。采购前做一张需求表，列出业务场景、所需数据、执行角色、系统能力和验收方式。优先验证一个高价值场景，不要一开始就为尚未证实的需求购买复杂功能。
我手里有订单、会员和客服咨询等不同来源的数据，但字段名称和用户标识并不一致。我担心一上来接太多数据会拖慢项目，也怕数据合并错了，应该从哪些字段开始？
先收集能支持一个具体运营动作的数据，而不是追求字段数量。基础盘点可包括：用户标识及来源、订单状态与时间、会员状态、关键行为、授权或退订状态；每个字段都要注明来源、更新频率、使用目的和维护责任人。身份合并尤其要谨慎。
手机号、账号、设备或订单信息不一定能证明是同一个人，无法可靠匹配时应保留为未确认身份，避免把两位用户的购买记录和触达状态合到一起。建议先选一个场景做小范围核对：抽查一批记录，比较系统中的用户身份、订单和会员状态是否与来源系统一致。通过核对再扩展数据范围，并确认平台接口实际可提供哪些字段。
我想用自动化做新客欢迎、购后提醒和复购沟通，但担心不同流程同时命中同一个人，造成短时间内重复收到消息。我应该怎样设计规则，才能兼顾运营效率和用户体验？
不要只按单个活动分别设频次，要增加一个跨流程的触达协调规则。每个流程至少写清触发事件、适用用户、渠道、发送时间、停止条件和异常处理；同时检查用户是否已退订、是否已完成目标动作，以及近期是否已收到其他营销消息。例如，购后服务消息可以在订单完成后触发；
如果用户已退款或已进入人工售后处理，就应暂停营销流程。复购提醒则应根据商品使用周期和订单状态判断，而不是仅凭固定天数对所有用户发送。上线初期先小范围测试，检查重复触达、错发和退订是否能正确处理。具体频次和发送规则还要核对所用渠道的平台规范及适用法规，不能把某个固定次数当成适合所有业务的标准。
我过去主要看消息发送量和点击率，但这些数字好看时，订单不一定增加，退订和投诉也可能被忽略。我想判断系统是否真的帮助业务，应该怎样设置指标和复盘方法？
把指标分成三层看：执行层检查是否成功触达、是否重复或失败；用户层关注互动、退订和投诉；业务层观察咨询、下单或复购等结果。单看发送量或点击率，只能说明部分过程表现，不能证明经营结果改善。复盘时要先固定统计口径和观察窗口，并把活动、价格、库存、季节等影响因素记下来。
条件允许时，可以为符合条件的用户设置未触达对照组，比较两组在相同时间内的业务结果；样本和条件不一致时，不要把差异直接归因于 CRM。上线验收可先问三个问题：规则是否按预期执行，用户负面反馈是否增加，目标业务行为是否出现可解释的变化。
若结果不理想，先排查数据质量、触发逻辑和承接流程，再决定是否扩大投放。
读者评论
按“流程、数据、规则、渠道、复盘”的顺序搭建很实用，尤其是先用单一场景试点，能避免采购后才发现业务条件没定义清楚。
身份匹配和退订状态确实容易被忽略。无法确认的记录保留待核验，比为了报表完整强行合并更稳妥。
把归因成交和增量成交分开讲很有必要。只看点击或触达后的订单，确实容易高估营销效果，也可能忽视退订和投诉。