我给一家做家居品类的卖家做过一次 ERP 选型陪跑。他们递给我的第一版对比表有 27 行：支持平台数、SKU 上限、订单处理速度、客服工单、财务对账、物流对接、报表数量……每一项都打了勾，有的还打了双勾。三周后他们把工具退掉了。原因不是功能不够，而是把 1800 个 SKU 从 Amazon 铺到 Shopee 和 Lazada 时，第一周就有 400 多个 listing 卡在「类目属性缺失」和「变体关系错误」上，运营每天手工补字段补到晚上十点，比不用工具还慢。
这几乎是刊登环节最经典的翻车方式：对比表上每一行都成立，但没有一行回答了「我的商品数据能不能被这个工具吃下去」。这篇文章不讲十大 ERP 排名，只讲一件事，在多平台刊登这个环节，工具对比到底该比什么、怎么验证、哪些坑一旦踩了就要花三个月爬出来。
结论我先摆出来，后面的篇幅都是用来证明它、拆解它、以及告诉你具体怎么落地的。
绝大多数卖家选型时问的第一个问题是「支持哪些平台」，但真正决定项目成败的是反向问题：你手上的商品数据，粒度够不够、字段全不全、关系清不清，能不能被这个工具按它的规则吃进去？
我见过太多项目死在起跑线上：Excel 里商品主数据是一张平表，颜色尺码揉在一个单元格里，类目靠人工备注，图片命名毫无规律。这种数据丢给任何 ERP，工具再强也只能生成一堆「部分成功」的记录。
这两者差得非常远。一个工具说支持 30 个平台，但拆到站点、类目、账号类型这一层，可能只剩 12 个能真正走完刊登流程。很多工具对某些平台只做了订单和库存同步，刊登要么不支持，要么只支持部分类目。
所以我在任何一次选型里都会要求供应商书面确认一件事：针对我的目标平台、目标站点、目标类目、我的账号类型，刊登链路上每个环节的权限边界是什么。这句话必须落在邮件或合同附件里，不能停留在销售的嘴里。
正常流程谁都能演示。10 个 SKU，图片规整，类目标准，点一下按钮，全部上架成功。这段演示没有任何信息量。
真正有信息量的场景是：1000 个 SKU 批量提交，300 个失败，其中 80 个失败原因是平台返回的一串英文错误码。这时候工具能不能告诉你是哪个字段的问题？能不能只重试失败的那 300 个？能不能回滚已经成功但你想撤回的部分？异常处理能力是区分「演示好看」和「实际好用」的唯一分水岭，而它恰恰是最难在售前验证的。
这是我最想强调的反常识观点。很多团队把刊登失败归因于「工具不行」，换了一个工具，问题照旧。因为根因在工具之外，商品主数据没治理、平台规则没沉淀、内部没人对刊登结果负责。
下面这张图是我在三个项目里做的归因观察，它揭示了一个很刺眼的错位：卖家选型时最看重的维度，和上线后真正出问题的维度，几乎不重叠。
要理解刊登为什么难，最好的方式是把一个 SKU 的完整旅程摊开看。下面这段流程我几乎在每个项目里都要给运营团队讲一遍，讲完之后大家才会明白为什么「一键铺货」这个词有多误导人。
假设你有一款折叠收纳箱，准备上 Amazon 美国站、Amazon 德国站、Shopee 马来站、Lazada 泰国站、TikTok Shop 印尼站。这件事拆开来看至少包含下面这些动作：
九个动作，其中第 2、3、4 项是绝对的重灾区。而大多数 ERP 的演示，只演示了第 1 项和第 8 项。
卖家口中说的「刊登」，其实是四件性质完全不同的事，混在一起谈就会得出错误结论。
很多工具在「批量上传」上做得不错，在「多平台映射」上用一套固定模板硬套，在「持续同步」上靠定时任务勉强支撑，在「异常处理」上基本等于没有。这类工具在售前演示里表现得完美无缺。
因为前两个月你在做「新增刊登」，第三个月你才开始面对「存量维护」。
新增刊登时，SKU 数量有限，人工兜底还能撑住。等到存量 SKU 积累到几千个，平台规则更新一次、旺季价格调整一次、仓库切换一次，同步链路的问题就会集中爆发。这时候你才发现，工具在批量上传上省下来的时间，全部在存量维护上还了回去。
下面这张漏斗图展示了这个流失过程有多残酷。它是我在三个项目里观察到的 SKU 存活路径的平均值。
我习惯用一段结构化的映射定义来给团队解释「映射层」到底是什么。下面这个例子是把一份内部商品主数据翻译成两个平台所需的刊登字段。注意看，同一个内部字段在两个平台上的处理逻辑完全不同。
{
"internal_sku": "STORAGE-BOX-A",
"master_data": {
"title_base": "Foldable Storage Box with Lid",
"color": ["Gray", "Beige", "Navy"],
"size": ["S", "M", "L"],
"material": "Oxford Fabric + PP Board",
"package_weight_kg": 1.25
},
"platform_mapping": {
"amazon_us": {
"category_node": "Home & Kitchen > Storage & Organization",
"required_attrs": [
"item_type_keyword",
"material",
"color_map",
"size_map",
"unit_count",
"special_features"
],
"variation_theme": "SizeColor",
"color_value_rule": "must_use_platform_color_map",
"title_max_chars": 200,
"image_rule": "main_image_pure_white_rgb_255"
},
"shopee_my": {
"category_node": "Home & Living > Storage",
"required_attrs": [
"material",
"colour_family",
"dimension",
"weight"
],
"variation_rule": "two_tier_variation_supported",
"title_max_chars": 120,
"image_rule": "main_image_min_500px_no_watermark"
}
}
}
这段结构看起来简单，但它暴露了一个关键判断：「颜色」这个字段在 A 平台必须走平台的官方色号映射表，不能直接用自己写的 "Gray"；在 B 平台则只需要归到「色系」这一层。如果你的工具不支持这种「同一字段、不同平台、不同映射策略」的配置，那么每一次刊登都要靠人工改，SKU 一多必然崩盘。
下面这六个误区，是我在选型陪跑里见到频率最高的。每一个我都能对应到具体的翻车项目。
这是最普遍也最致命的一个。
供应商说「我们支持 Amazon、eBay、Shopee、Lazada、TikTok Shop」，这句话在当前语境下几乎没有任何约束力。你需要追问的是四层：
我建议的做法是：写一张「目标平台 × 站点 × 类目 × 账号类型」的四维矩阵，逐个格子让供应商书面确认。这个动作看起来笨，但它能挡掉 80% 的后期扯皮。
很多人把类目映射当成「上线时配一次就完事」的活。实际上平台类目树每年都在调整，新类目上线、旧类目合并、必填属性增加，这些变化会持续发生在你的经营周期里。
所以真正要验证的不是「能不能映射」，而是「类目树更新后，映射关系能不能被批量感知和批量修复」。如果工具没有「映射失效预警」这类机制，那么每次平台调整你都会在审核驳回里被动发现。
几乎所有演示都只跑 happy path。我要求团队做选型测试时，一定要主动制造失败：
这五条里任何一条不通过，就要在评估表里大幅扣分。因为上线后你每天都在跟这五条打交道。
「库存同步每 5 分钟一次」听起来很快，但如果这 5 分钟里发生的是多平台同时出单，而你只有一份库存，那么超卖依然会发生。
真正要问清楚的是同步的完整逻辑：
最后一条经常被忽略，但它决定了问题是「被系统自动兜住」还是「被客户投诉发现」。
ERP 的计费口径非常混乱，我见过的至少有这些：按 SKU 数量、按店铺数量、按订单量、按渠道数、按 API 调用次数、按存储容量、按坐席数。有的还会把「刊登功能」单独作为增值模块收费。
你需要一份完整的费用清单，至少包含：
最后一条几乎没人问。但我在一个项目里真实遇到过：卖家想换工具，供应商要求按 SKU 数量收取数据导出服务费，最后这笔钱比半年的订阅费还高。
刊登环节涉及大量账号授权：平台店铺授权、物流商授权、支付授权、供应商授权。这些授权是否可细分到角色？运营离职后能不能一键回收？所有刊登操作是否有审计日志？
这些问题在选型阶段看起来遥远，但一旦出问题就是大问题。我建议至少在合同里明确：数据所有权归卖家、支持全量导出为通用格式、支持按需撤销任意层级授权。
下面这张图是我从真实工单里归因出来的刊登失败分布。它解释了为什么「类目属性」和「变体关系」值得你在选型时花最多时间。
前面讲了误区和现象，现在讲方法。我把刊登工具的评估拆成四层，从下往上层层递进。这个方法我在多个项目里迭代过，目前是最好用的一版。
这一层要回答的问题是：你的商品数据能不能被表达成「实体 + 字段 + 关系」的形式。
验证动作很简单：把你的真实商品数据导出，尝试按目标工具的数据模型填进去。如果填不进去，或者需要大量人工拆列，说明你还没准备好，或者工具不合适。
这一层常见的失败信号有三个：
这一层看的是工具能不能表达「同一字段、不同平台、不同处理策略」。
具体要验证的能力包括：
第 5 条是我认为最被低估的能力。它决定了平台规则变化时，你是主动应对还是被动救火。
这一层是日常稳定性所在。我会重点看四个指标：
其中「部分成功处理」是我判断工具成熟度的核心标志。因为真实业务里，全成功和全失败都是少数，绝大多数情况是部分成功。
这一层决定长期可控性。要能回答：谁在什么时候改了什么、改完效果如何、出问题能不能定位到具体操作。
我在项目里会要求工具至少提供三类日志：刊登操作日志、字段变更日志、授权变更日志。没有审计能力的工具，一旦出现批量错价或者批量违规，你根本无法定位范围和责任。
四层不能只靠感觉判断，要能打分。我在项目里会用 1-10 分给每一层打分，再按业务权重加权。下面这张雷达图展示了三类工具在这四层上的典型能力轮廓。
为什么要花这么多精力在验证上？因为刊登失败的成本远高于大多数人的预估。下面这张瀑布图是我在一个 3000 SKU 批次刊登失败后记录的人工修复耗时拆解。
前面讲了很多方法论。这一节我拿一个具体的工具来落地说明，讲清楚它在刊登链路里应该放在什么位置、解决什么问题、边界在哪里。这里我用「数跨境」作为例子，官网是 https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys。
在做刊登工具对比之前，我会先问一个问题：你现在的刊登效果，能不能被量化？
大多数卖家的答案是不能。他们知道「最近上架有点慢」「好像驳回挺多的」，但说不出驳回率是多少、驳回原因前三位是什么、平均上架周期几天、哪个平台的类目属性缺失最严重。
在这种状态下做工具对比，本质上是在比「谁的销售讲得好」。因为你没有基准线，也就无法判断换工具之后到底是变好了还是没变好。
我在项目里把数跨境放在刊登链路的上游和下游两个位置，它不替代刊登 ERP，而是让刊登这件事变得可观测、可复盘。
上游位置：把各平台的商品主数据、类目属性要求、字段差异沉淀成统一的底表。在正式导入刊登 ERP 之前，先把「一份商品数据 vs 多个平台要求」的差异看清楚，把字段缺口的范围量化出来。这一步做完，选型的时候你就知道该重点验证哪些能力。
下游位置：把刊登结果回收成指标。刊登成功率、审核驳回率、驳回原因分布、平均上架时效、类目属性完整率、变体关系正确率，这些指标一旦能按批次、按平台、按类目、按运营人员拆开看，刊登就从一门「手艺」变成一条可管理的流水线。
我在一个项目里用这套思路做过一次完整的字段治理，过程大致是这样：
整个过程最难的不是技术，而是第 3 步，确定「标准值域」需要业务判断，不是数据工具能替你决定的。比如「折叠收纳箱」的材质到底算 Oxford Fabric 还是 Polyester，这需要一个懂产品的人拍板。数跨境这类工具的价值在于把差异暴露出来并固化规则，而不是替你判断哪个规则对。
下面这组数据是我在项目里记录下来的治理前后对比，可以作为你自己项目的一个参考基准。
这一点我必须说清楚，避免误导。数跨境这类数据底座解决的是「数据标准化、效果可视化、问题可追溯」，它不负责把商品推送到平台、不处理平台账号授权、不做订单和物流的实时对接。
刊登动作本身依然要靠 ERP 或平台后台完成。数据底座的价值是让刊登这件事从「凭感觉优化」变成「按指标优化」，它是刊登链路的前置条件和反馈回路，不是替代品。
另外要提醒的是，任何第三方数据工具的效果都取决于你接入的数据质量。如果你自己内部的数据本来就是乱的，接入进来只会把混乱复制一遍。所以顺序永远是：先统一内部口径，再引入工具，最后才是优化指标。
我经常被问「我这规模需不需要上数据层」。下面这张气泡图给出一个经验性参考，横轴是 SKU 规模，纵轴是年工具预算，气泡大小代表月新增刊登量。
方法论讲完了，下面是按业务规模分类的具体建议。你可以直接对照自己的情况取用。
这个阶段我不建议你在 ERP 上花太多钱，也不建议引入数据层。
优先级排序应该是：
这个阶段最容易犯的错是「过度选型」，为了未来的可能性买一套用不上的复杂系统，结果团队没人会用。
这是最典型的「开始痛」的阶段。建议的做法是：
这个阶段开始，「谁对刊登结果负责」这个问题必须有人回答。我见过太多团队把刊登挂在运营、IT、供应链三个部门的缝隙里，最后没人管。
到了这个规模，单一工具已经无法同时满足治理和执行两类需求。建议分离两层：
两层的接口就是「标准化的商品底表」和「标准化的刊登结果数据」。这个接口定义清楚了，未来换任何一层都不会推倒重来。
如果你们有研发团队，我不建议一开始就自研刊登系统。自研的真实成本远高于预期：平台 API 会变、限流策略会变、审核规则会变，你需要长期维护一支团队跟着平台跑。
更务实的路径是：用现成工具做执行层，把自研能力集中在数据层和业务规则层。因为平台适配是「变化的复杂度」，你的业务规则才是「核心资产」。把有限的自研资源放在核心资产上。
选型本质上是一系列取舍。没有全赢的选项，只有适合当前阶段的组合。下面四组取舍是我在项目里被问得最多的。
有些 ERP 号称打通了从刊登到财务的全链路，有些工具只专注刊登一个环节。怎么选？
我的判断标准是：如果你的刊登环节目前是最大瓶颈，就选单点做深的；如果刊登已经跑顺，只是各环节数据割裂，再考虑全覆盖。
原因很简单：全链路工具在每个单点的深度通常不如专精工具，而刊登恰恰是一个「细节决定成败」的环节。用一个样样通样样松的工具去解决最痛的环节，往往是最差的选择。
自研的优势是贴合度，劣势是长期维护成本。我做过的粗略测算里，一个支持 5 个平台的中等复杂度刊登系统，自研的一次性投入通常在几十万量级，后续每年的维护投入在一次性投入的 30%-50%。
而平台 API 的变更频率，往往比你的迭代速度快。所以我的一般建议是：自研只做「平台无关」的部分，平台相关的适配交给工具。
这是一个典型的「鸡生蛋」问题。数据乱，工具用不起来；不上工具，数据治理没有抓手。
我的实际经验是：并行推进，但顺序上先做一轮最小规模的字段盘点。不用等到数据完全干净才选工具，但至少要知道自己的数据缺口在哪，否则选型时你无法提出正确的问题。
一轮最小字段盘点的成本很低，通常 1-2 人天就能完成。它会显著改变你在选型会议上的提问质量。
这是一个成本结构的选择。低价工具省了订阅费，但把成本转移到了人工；高价工具贵在订阅费，但可能通过流程自动化把人力省下来。
算这笔账的关键是把人工成本显性化。如果一个工具每年帮你省下 300 个人时，按人力成本折算，往往就已经覆盖了价格差异。很多卖家在算这笔账时，只算订阅费，不算自己团队的时间成本。
下面这张图对比了三条典型路线的成本结构。注意看第二年的变化趋势，它往往比首年投入更能说明问题。
前面讲了很多判断标准，但真正能帮你避坑的，是一次小规模的实操验证。我把它压缩成七天，投入约 6.5 人天，可以在不签合同的前提下跑完。
从你现有商品里挑 30 个 SKU，要求覆盖至少 3 个类目、包含至少 2 种变体结构、包含至少 1 个你已知会出问题的商品。
同时整理一份目标平台的规则清单：目标站点、目标类目、必填属性、变体规则、图片规格。这份清单不需要完美，但要真实。
产出物：字段清单与平台规则表。
把 30 个 SKU 的数据按目标工具的数据模型填入，建立类目映射和属性映射。这一步会暴露大量问题：字段无处安放、值域不匹配、变体无法表达。
产出物：映射模板与问题清单。
正式提交这 30 个 SKU，然后重点观察三件事：
产出物：成功率数据与驳回原因清单。
这一天专门做破坏性测试：
产出物：异常处理路径记录。
最后一天不谈功能，只谈钱和退出。要求供应商提供完整报价单，逐项确认计费口径，并明确数据导出的格式和费用。
产出物：合同风险清单。
七天跑完，你应该能回答下面这张表里的问题。任何一栏答不上来，都说明验证还不够充分。
| 验证环节 | 通过标准 | 不通过的典型信号 |
|---|---|---|
| 字段标准化 | 30 个 SKU 全部能无损导入，无需手工拆列 | 需要把属性拼进一个字段，或变体无法表达 |
| 类目映射 | 3 个类目的必填属性可配置、可校验 | 只能靠人工逐个补，没有缺失提示 |
| 刊登成功率 | 首次提交成功率不低于 85% | 成功率低于 70%，且失败原因不可读 |
| 异常处理 | 可只重试失败项，报错定位到具体字段 | 只能整批重来，报错是平台原始错误码 |
| 并发与限流 | 触发限流后自动退避，任务最终完成 | 直接失败或静默丢弃 |
| 数据导出 | 可导出为通用格式，字段完整 | 导出受限、需额外付费、字段缺失 |
回到最开始那个退掉工具的项目。后来他们做了什么？三件事。
第一件，花了两周把 1800 个 SKU 的商品数据重新拆字段、建变体关系、定标准值域。这个过程没有任何工具参与，就是业务和运营一起把表理顺。
第二件，把各平台每个目标类目的必填属性和变体规则整理成一份内部规则文档，并且在数据层里固化成映射模板。
第三件，重新做了一次选型，但这次的评估表只有 9 行，而且每一行都带着「验证问题」和「通过标准」。他们最终选了一个功能没有那么全、但在异常处理上做得很扎实的工具，上线三个月，驳回率从 30% 多降到 15% 以下。
这个案例的核心不是哪个工具更好，而是选型这件事的胜负手，从来不在工具那一侧，而在你自己这一侧。你对自己数据的理解程度、对平台规则的沉淀程度、对异常场景的准备程度，决定了工具能发挥出多少价值。
所以我给这套方法起个名字：先治理，再映射，后执行，最后才是比工具。
如果你现在正准备做刊登工具对比，我建议你的下一步不是去要三份产品报价，而是先做两件事：
这两件事加起来不到 3 人天，但它能让你的下一次选型会议，从「你们支持哪些平台」变成「你们怎么处理这 30 个 SKU 里的第 7 个变体问题」。后一种提问方式，才是真正能避坑的方式。
工具会换，平台规则会变，但你对商品数据的管理能力、对刊登链路的理解深度，是可以持续复用的资产。把时间投在这里，回报率永远最高。
我之前选型时吃过一次亏，销售口头说支持好几个新兴平台，结果签完才发现只能拉订单和扣库存，刊登还是要回平台后台一条条传。后来我做多平台运营，只要涉及新平台上线，第一件事就是确认刊登能力到底覆盖到哪一层。
判断的核心是看开放平台授权范围和实际闭环动作，不是看官网的功能图标。先问清楚它调的是平台的商品接口还是仅订单/库存接口，有没有创建、修改、下架商品（listing/product）的权限，很多工具所谓支持某平台，其实只拿了订单和库存授权。
然后要求现场演示，并且用你自己的目标站点、目标类目、目标账号类型操作，因为同一平台不同站点、不同类目的接口权限差异很大。
更硬的办法是拿10个真实SKU做小批量测试，覆盖一个全新上架、一个老品改价、一个下架重上，看能不能完成新建，改价，下架，重上，删除这个五步闭环，同时确认刊登成功后会回写平台商品ID并建立SKU映射。
再看批量刊登时的排队和重试机制，平台接口都有调用频次限制，一次传500条被限流后，工具是自动排队重试还是直接报错中断，这一点决定了它能不能真正承担日常刊登量。能跑通闭环、有映射回写、有限流重试，才算支持刊登；只做到其中一两项，就是订单工具冒充刊登工具。
同一个SKU要上Amazon、Shopee、Lazada，每个平台的类目不同、必填属性不同、变体维度也不一样，我们以前是人工一个平台一个平台填，运营填到怀疑人生。所以我现在看工具，重点就看它能不能把这件事标准化并复用。
先看它有没有可维护的映射库。理想状态是能按平台+站点+类目保存一套字段映射模板，下次同类商品直接复用，而不是每次重新填。再看变体处理能力，能不能做父子关系转换，比如你内部是颜色加尺码的二维变体，某平台只允许单维变体，工具是要能自动拆分或者按规则合并的。
第三个关键点是刊登前的前置校验，必填项、字符长度、图片尺寸这些能不能在提交前就标出来，而不是等平台驳回才知道。第四个是驳回后的修复路径，能不能定位到具体是哪个字段出问题，并且在工具里直接改完重新提交，如果还要回平台后台单独改，那多平台刊登的效率优势基本就没了。
验证方法很直接：准备三个测试SKU，一个单变体、一个二维变体、一个多包装组合，跑一遍首次刊登，统计首次审核通过率和修复一条驳回所需的时间。我的口径是首登通过率尽量做到80%以上，单条驳回修复控制在5分钟内，达不到说明映射和校验能力不够，后面运营成本会成倍放大。
我们有一次两个平台几乎同时出单，A平台扣了库存但B平台没及时扣，结果超卖被投诉还赔了运费。从那以后我看任何ERP的同步能力，都不再听‘实时同步’这种说法，一定要拿到具体数字。
要问清楚的第一个问题是同步方向和触发机制，是平台事件推送还是定时轮询。很多标榜实时的工具，本质是5到15分钟轮询一次，大促期间这个延迟就足以造成超卖。第二个是多仓和多店铺的库存池逻辑，能不能设安全库存或缓冲库存，能不能按店铺单独分配可售量，多仓库时优先级怎么算。
第三是订单回传扣减库存是不是事务性的，扣减失败会不会自动重试并告警，还是静默丢单。第四是平台接口限流或断网时的处理，积压的同步任务恢复后能不能补同步，而不是从当前状态直接覆盖。判断依据很简单，让对方给出明确的同步延迟秒数、轮询频率和失败重试次数，给不出来就按最坏情况估计。
验证办法是在两个平台对同一SKU同时下单，看两边库存在一分钟内是否都完成扣减，再模拟网络中断几分钟，看恢复后数据是否一致。价格同理，重点看改价后有没有回写确认和失败告警，价格错误带来的损失往往比超卖更直接。
我见过按店铺数报价很便宜、结果SKU一超量单价翻倍的，也见过想换系统时发现商品主数据和映射关系导不出来，只能一条条重建。吃过这些亏之后，我现在把费用和退出条款当成选型的一等大事。
先厘清计费口径，按店铺、按SKU、按订单量、按渠道数、按API调用量还是按存储量，这几者的成本曲线完全不同，超额部分的单价必须写进合同。再列清楚哪些算增值项，新平台对接、定制字段、专属模板、实施培训、专属客服往往都不含在基础套餐里，上线第二年才冒出来的费用最伤人。
合同层面要看期限、续费涨价条款、能否按年退出。数据这块是重中之重，要确认商品主数据、平台字段映射、历史订单能否完整导出，导出格式是标准CSV还是只能在界面里看，API导出是否额外收费，服务商能不能以技术理由拒绝导出。
我的操作习惯是要求对方书面提供三张清单：包含项、超额项、退出与数据归属条款，并作为合同附件。算账方式是把当前和未来12个月预计的店铺数、SKU数、月订单量代入报价，算12个月总拥有成本再横向比较，只看首年单价容易误判。
最后做一个迁移测试，签合同前就要求导出一次真实样例数据，能顺利导出的，退出风险才可控。
读者评论
文章说“数据能不能进去”太对了。我们铺Shopee时颜色尺码混在一个单元格，ERP批量上传后大量类目属性缺失，人工补到崩溃。选型真该拿自己最脏的SKU去测。
支持平台数”确实很虚。供应商说支持十几个平台，但按目标站点、类目、账号类型一拆，刊登未必走得通。最好让销售书面确认权限边界，别只听演示。
映射层那个例子很关键，同一颜色字段在不同平台策略完全不同。如果工具不能按平台配置映射和失败重试，SKU一多就只能靠人工，存量维护阶段必爆。
漏斗图那组流失很真实。刊登不是一次性动作，第三个月做存量维护才见真章。选型只看功能勾选表没用，还要问数据导出、异常回滚和归因责任。