去年黑五前一周，我一个做家居品类的朋友遇到一件很典型的事：他们同时在 Amazon 美国站、TikTok Shop 美区、Temu 半托管、SHEIN 四个渠道铺了同一批新品，大促当天四个平台同时出单，仓库按 ERP 里的"可售库存"扣减，结果三天后 Temu 出了超卖，Amazon 那边两个 SKU 被降权，SHEIN 因为图片不合规被驳回下架。事后开会复盘，运营说库存不准，库存说运营没锁量，财务说利润算不出来。
真正的问题是：他们的 ERP 记录了订单、记录了库存、记录了物流，却几乎没有记录"刊登"这件事本身，哪个批次、哪个人、什么时候提交、被驳回几次、驳回原因是什么、哪个平台的刊登质量最差。刊登没有被当成数据资产来记录，复盘自然无从下手。这篇内容我想把这件事讲透：如果要用 ERP 支撑多平台刊登的数据复盘，能力清单到底应该覆盖哪些事项、哪些字段、哪些指标口径。
先给结论，避免你在中间绕圈。多平台刊登的数据复盘，能不能做起来，90% 取决于 ERP 在"刊登"这个环节到底落了多少结构化字段，而不是取决于它接了多少个平台。这句话我在至少七八个跨境团队的实施现场反复验证过：平台数量是商务问题，字段粒度是复盘问题，两者经常被混为一谈。
大部分 ERP 的刊登模块只有一个最终状态字段：成功或者失败。但真实的刊登是一条有先后依赖的状态链，每一个状态节点都可能成为复盘时的断点。
只有这六个状态都被独立记录，你才能回答"这批货为什么没卖出去"这种问题。否则你只能看到"上架成功但没单"，中间到底是审核卡了三天，还是上架后两小时就被系统降权，完全查不到。
我见过太多团队只做到"平台 + 日期"这一层。这种粒度下，你能看到"TikTok 这个月上架了 300 个新品"，但看不到"这 300 个里有多少是同一个运营批量提交的、有多少用的是同一套图片模板、有多少被同一个错误码驳回"。没有批次维度，就没有归因能力。
批次维度是刊登复盘里被低估最严重的一层。它把"人、时间、模板、资料源、平台"绑定在一起，一旦某个批次的驳回率异常高，你能立刻定位到是模板问题还是资料源问题，而不是笼统地说"最近审核严了"。
这里要说一个我自己的判断，可能和很多人的直觉不一样：不要指望 ERP 自带的报表模块承担完整的刊登复盘职责。ERP 的报表设计目标是"作业监控"，今天有多少单没发、有多少库存不足、有多少刊登失败待处理。它的字段组织和查询性能都是为实时操作服务的，而不是为跨平台、跨店铺、跨月的多维分析服务的。
真正能做到字段级归因的做法是两段式：ERP 产出结构化的刊登明细数据，再由专门的数据分析层做汇聚、建模、看板。这是我认为目前最务实的架构判断。
下面这三个场景，是我在 실제 实施和陪跑中遇到频率最高的。它们的共同点不是"ERP 不好用"，而是"关键字段没被落到可分析的形态"。
库存超卖的经典归因链是：多平台共享库存 → 某个平台订单回传延迟 → 本地可用库存没有及时扣减 → 另一个平台继续卖出 → 超卖。这条链上，ERP 通常能告诉你"超卖了几单"，但很难告诉你"是哪个平台的回传延迟了多少秒、延迟发生在哪个时间段、当时的安全库存阈值是多少"。
我的经验是，可复盘的库存口径至少要包含五个字段：平台、仓库、SKU、同步时间戳、同步结果状态。少了时间戳和结果状态，你就无法区分"同步慢"和"同步失败"这两种完全不同的问题，前者要调频率，后者要修接口。
平台驳回文案通常是自然语言，比如"图片包含促销水印""类目与商品不匹配""缺少必要的安全标识"。这些文案如果只是原样存进一个文本字段，你最多能搜索关键词，做不了统计分析。
要在 ERP 里做复盘，驳回原因必须被归一化成错误码 + 错误分类两层结构。错误码是平台原生的，错误分类是你们自己定义的（例如：图片类、类目类、合规类、属性类、价格类、账号类）。只有做了这一层归一化，"这个月驳回率上升"才能拆成"图片类驳回上升 6 个百分点，集中在某一个图片模板"。这是我强烈建议在上线 ERP 时就一次性做好的配置，后期补做成本极高。
这是最隐蔽的一类问题。财务能给出月度利润，运营能看到各平台 GMV，但没有人能回答"哪一批刊登的 SKU 利润贡献最高、哪一批是负毛利"。原因很简单：刊登批次 ID 没有传递到订单、没有传递到利润表。
当刊登记录和订单记录之间缺少一条稳定的关联主键时，所有"从刊登质量追到利润结果"的分析都无法成立。这也是我在做刊登复盘方案时，第一个要检查的技术细节。
订单量是结果，不是刊登质量的度量。一个 SKU 出单多，可能只是因为它是老品、有历史权重、有广告投放，和这次刊登的质量毫无关系。用订单量评估刊登效果，等于用最终成绩评估一次考试的复习方法。
更合理的做法是分层：刊登质量用通过率、驳回率、审核时长、属性完整度衡量；刊登效果用上架后 7 天曝光、点击率、转化率衡量；利润贡献放到更长的周期看。三者不要混在一张表里讲。
我自己做过一次内部对比：两个 ERP 都能对接主流平台，但 A 系统的刊登接口只做了"能提交"，B 系统做了"能提交 + 错误码归一化 + 重试 + 草稿版本"，实际运营效率差了不止一倍。支持平台数是商务参数，字段深度才是运营参数。
同一个商品在 Amazon、TikTok Shop、Temu、SHEIN、Shopee 上的必填属性差异极大。用一套模板硬套，短期能省事，长期一定在审核环节付出代价。正确做法是平台字段映射表 + 统一指标字典两层架构：映射表负责"每个平台要什么"，指标字典负责"我们统一怎么算"。
汇总利润会掩盖结构性问题。我见过一个团队整体毛利率 22% 看起来健康，拆到店铺层发现有一个站点实际是负毛利，只是被另一个站点的爆款盖住了。刊登复盘如果不落到店铺和 SKU，这类问题永远不会浮出来。
很多 ERP 的刊登记录是"覆盖式更新"的，改了标题，旧标题就没了。这导致一个严重后果：你无法回答"这个 SKU 上架时是什么样，现在是什么样，中间改过几次"。而平台判定违规时，恰恰就是看历史版本的。没有快照，就只能被动接受判罚。
这一节是全文的方法论核心。我在实际项目里不再按"功能模块"讲 ERP 能力，而是按这五列来梳理，因为运营真正需要的是"看到什么、判断什么、做什么"，而不是"这个模块叫什么名字"。
| 事项 | ERP 应记录字段 | 复盘指标 | 常见异常 | 复盘动作 |
|---|---|---|---|---|
| 类目与属性映射 | 平台、站点、类目 ID、属性字典、必填项、映射版本 | 属性缺失率、类目错放率、映射失败次数 | 类目错放导致流量不匹配 | 批量修正并回溯受影响 SKU 的历史表现 |
| 价格与币种 | 站点币种、税率、原价、促销价、最低价阈值、生效时间 | 价格同步失败率、币种错误数、最低价预警次数 | 促销冲突、汇率导致负毛利 | 按平台重新校验价格规则，设置阈值告警 |
| 库存同步 | SKU、仓库、可用库存、锁定库存、同步时间戳、同步结果 | 同步延迟秒数、超卖次数、缺货下架数 | 回传延迟引发的超卖 | 调整安全库存与同步频率，修接口重试策略 |
| 刊登任务 | 批次 ID、操作人、提交时间、状态、错误码、重试次数 | 刊登成功率、平均审核时长、人工干预率 | 批量任务部分失败未被发现 | 按错误分类优化模板，建立失败日报 |
| 订单归因 | 刊登批次 ID、店铺、平台 SKU、订单号、利润明细 | 批次利润贡献、归因断裂率 | 利润无法回溯到刊登批次 | 补齐映射主键，重建归因链路 |
这张表可以直接当成你们内部的配置检查表。我的建议是把每一行都指派一个责任人，因为刊登复盘失败最常见的原因是"大家都以为别人在管"。
"刊登成功率"这四个字，在不同团队那里能算出三个不同的数字。所以我要求所有指标都要写清四个属性：统计范围、时间窗口、分母定义、失败判定标准。
这四条一旦写进指标字典，跨部门的口径争议会减少一大半。我自己的经验是，指标口径文档比看板本身更值钱，因为看板会过时，口径不会。
我把刊登相关指标分成七类，从效率到财务，形成一个递进关系。前四类是执行层，后三类是结果层。
下面这份清单，是我把这些年踩过的坑和做过的配置项归拢出来的版本。你可以直接拿它去做 ERP 选型的对照表，也可以拿它去自查现有系统到底缺哪几块。
要看的不是"能不能映射"，而是"映射关系能不能版本化"。平台类目和属性字典是会被平台单方面修改的，如果映射关系没有版本记录，你无法解释"为什么上个月还好好的类目，这个月全部错放"。
复盘要看：属性缺失率、类目错放率、映射失败次数、映射版本变更记录。
多平台刊登最容易被忽略的是币种与税率的组合爆炸。同一个 SKU 在美区是美元含税展示、在欧区是欧元含 VAT、在东南亚是本地币种不含税，价格规则完全不同。ERP 需要记录的是每个站点生效的价格规则，而不只是一个最终价格数字。
复盘要看：价格同步失败率、币种错误数、税率配置错误数、促销冲突次数、最低价预警触发次数。这里我特别建议对"最低价"单独设一条监控，因为它同时影响利润和平台合规。
素材问题导致的驳回，是最容易批量修复也最容易批量触发的一类。我的做法是把素材和合规标签绑定：每张主图、附图、视频都记录它对应的模板 ID、合规标签、审核结果。这样一旦某一类素材集中被驳回，能立刻定位到是哪个模板。
复盘要看：图片驳回率、素材模板驳回集中度、合规缺失项分布。
父子变体、平台变体、组合 SKU、赠品 SKU，这四种关系如果混在一起管理，库存扣减必然出问题。ERP 至少要能区分"平台侧的变体结构"和"内部侧的 SKU 结构"，并且记录两者的对应关系。
复盘要看：变体错配次数、因变体结构导致的库存错扣次数、订单归因失败率。
物流模板的影响经常被低估。运费模板配置错误，会直接导致某些区域订单变成负毛利。ERP 需要记录每个 SKU 在哪些站点关联了哪个物流模板，以及模板变更的时间点。
复盘要看：运费配置异常数、时效承诺超期率、物流模板变更后的利润波动。
禁售、限售、认证、EPR、标签要求，这些规则在不同平台、不同站点完全不同，而且平台会更新。ERP 的价值在于能不能在提交前做一次前置校验，把问题拦在审核之前。
复盘要看：规则触发次数、禁售下架数、合规驳回占比、规则更新后的驳回率变化。
这一块决定了刊登的效率上限。我关注三个具体能力：批量任务能不能部分成功、定时刊登能不能按站点时区执行、失败任务能不能自动重试并记录重试次数。
复盘要看：刊登任务成功率、平均任务耗时、人工干预率、自动重试成功率。
刊登不等于结束。价格、库存、订单、评价、禁售状态、下架、重新上架，这些后置动作才是长期占用运营精力的部分。
复盘要看：同步延迟分布、超卖次数、缺货自动下架次数、重复刊登数、重新上架后的恢复销量周期。
上一节讲的是 ERP 该有什么。这一节讲的是：假设 ERP 已经产出了这些数据，怎么把它变成能看、能追、能决策的东西。我在这里以数跨境为例说明，因为它的定位恰好是"承接 ERP 数据、做多平台分析"这一层，官网在 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys ，你可以对照着理解这套思路。
我的判断逻辑很简单：ERP 的数据库是为"事务处理"优化的，一次刊登提交涉及几十张表的写入和更新；而刊登复盘需要的是"跨期、跨平台、跨店铺的宽表聚合"。这两种负载放在同一个系统里，必然有一方要让步，通常是分析让位于事务。
所以更现实的做法是：ERP 保证数据被完整落库，分析层负责把落库的数据重组成可归因的宽表。这个分工一旦确定，排期和责任人也就清晰了。
我自己做接入的顺序通常是：刊登任务表 → 刊登明细表 → 错误码字典 → 平台类目映射表 → 订单表 → 利润明细表。前四张解决"刊登质量"问题，后两张解决"刊登价值"问题。
不要一上来就把所有表都接进来。我吃过这个亏：接了三十多张表，结果字段口径没对齐，看板做出来没人信。先接六张，把口径对齐，比接三十张更有效。
下面这段是刊登兑现率（刊登批次 → 利润贡献）的查询骨架，我把它简化成了通用形式。核心思路是先用刊登批次作为主键，把刊登明细、订单、利润三段数据串起来。
-- 刊登批次利润归因骨架（字段名请按自家 ERP 实际结构替换） WITH listing_batch AS ( SELECT batch_id, -- 刊登批次主键 platform_code, -- 平台 shop_id, -- 店铺 platform_sku, -- 平台 SKU submit_time, -- 提交时间 audit_status, -- 审核状态 error_code_norm, -- 归一化错误码 retry_count -- 重试次数 FROM erp_listing_detail WHERE submit_time >= '2025-10-01' ), order_agg AS ( SELECT platform_sku, shop_id, COUNT(DISTINCT order_id) AS order_cnt, SUM(gmv_local) AS gmv_local, SUM(commission_local) AS commission_local, SUM(logistics_cost_local) AS logistics_cost_local, SUM(refund_local) AS refund_local FROM erp_order_detail WHERE order_time >= '2025-10-01' GROUP BY platform_sku, shop_id ) SELECT b.platform_code, b.batch_id, COUNT(DISTINCT b.platform_sku) AS listed_sku_cnt, AVG(b.retry_count) AS avg_retry, SUM(CASE WHEN b.audit_status = 'REJECTED' THEN 1 ELSE 0 END) AS rejected_cnt, SUM(COALESCE(o.order_cnt, 0)) AS total_orders, SUM(COALESCE(o.gmv_local, 0)) AS total_gmv, SUM(COALESCE(o.gmv_local, 0) COALESCE(o.commission_local, 0) COALESCE(o.logistics_cost_local, 0) COALESCE(o.refund_local, 0)) AS gross_profit FROM listing_batch b LEFT JOIN order_agg o ON b.platform_sku = o.platform_sku AND b.shop_id = o.shop_id GROUP BY b.platform_code, b.batch_id ORDER BY gross_profit DESC;
这个结构的价值在于：它把"刊登质量"和"利润结果"放在了同一行里。你第一次能看到"驳回率高的批次是不是利润也低"，而这种相关性一旦被验证，运营优化就有了明确方向。
| 层级 | 核心内容 | 主要使用者 | 更新频率 |
|---|---|---|---|
| 日报 | 刊登失败清单、库存同步异常、价格异常预警 | 运营、客服 | 每日 09:00 |
| 周报 | 驳回原因分布、类目错放率、店铺刊登质量排名 | 运营主管 | 每周一 |
| 月报 | 平台利润归因、刊登批次产出比、异常闭环率 | 负责人、财务 | 每月 3 日 |
我强烈建议日报只放"需要今天动手"的事。我看过太多看板，日报里塞了四十个指标，结果没人看。日报的价值在于驱动动作，不在于信息完整。
很多团队止步于毛利，但刊登决策真正要看的是净利。这条扣减链上，每一项都和多平台刊登质量相关：刊登结构错误导致退款率上升、类目错放导致广告效率下降、合规问题导致下架损失。
上周三早上，日报提示 SHEIN 站点有 17 个 SKU 库存同步延迟超过 300 秒。顺着批次 ID 查下去，发现这 17 个 SKU 都属于同一个运营在前一天下午批量提交的批次，而这些 SKU 在另一个平台同时在做促销，库存消耗速度是平日的 4 倍。
修复动作有三步：把这个批次的 SKU 统一调高安全库存阈值；把该平台的同步频率从 15 分钟改成 5 分钟；在日报里加一条"高动销 SKU 同步延迟"的专项提示。整个过程用了 40 分钟，如果没有批次 ID 和同步时间戳，这个定位过程至少要半天。
这就是我一直强调的观点：刊登复盘的价值不在于"知道发生了什么"，而在于"多快能定位到原因并改掉"。闭环速度才是真正的运营指标。
不要上复杂看板。你的第一优先级是保证 ERP 记录了三样东西：刊登失败原因、库存同步时间戳、刊登历史快照。这三样东西的配置成本最低，但对后续所有复盘的支撑作用最大。
指标上只看三个：刊登成功率、驳回率、超卖次数。每周看一次就够，不需要日报。
这个阶段最该做的是把错误码归一化和平台字段映射表建起来。我建议用一个专门的配置表管理"平台，类目，属性，必填项"，并且指定一个人负责维护。
同时开始做批次维度统计。每周出一张"驳回原因 Top 5 + 对应批次"的表，坚持两个月，驳回率通常会下降 30% 以上。
到这个规模，ERP 自带的报表基本不够用了。建议把刊登明细数据同步到独立的分析层（比如前面提到的数跨境这类定位），做统一指标字典、分层看板和归因建模。
这个阶段的重点是治理而不是建设：定义清楚谁对哪个指标负责，异常从发现到闭环的 SLA 是多少，跨部门口径争议由谁裁决。
这是成本最低的窗口期。我强烈建议在做实施配置时就把"刊登明细字段清单"和"错误码归一化规则"作为交付物写进合同或验收单。上线后再补这两样，成本至少翻三倍。
具体要确认的：刊登明细表能不能按批次导出、能不能保留历史快照、错误码能不能自定义分类、库存同步能不能记录时间戳。
财务牵头的好处是口径清晰，风险是容易忽略刊登执行层。我建议财务看两条线：一条是"刊登批次 → 利润"的归因链是否完整，一条是"退款率与刊登属性完整度"的相关性。这两条线能把财务视角和运营视角连起来。
字段越细，复盘越准，但录入和维护成本也越高。我的取舍原则是：凡是能自动采集的，一律做细；凡是需要人工填的，一律做粗。时间戳、状态码、错误码这些都是系统自动产生的，做细没有额外成本；而像"本次刊登的运营目标"这类需要人工填的字段，填三天就会荒废。
库存同步频率越高，超卖风险越低，但平台 API 配额是有限资源。我的取舍逻辑是分层同步：高动销 SKU 用高频同步（5 分钟），中低动销 SKU 用低频（30 分钟），滞销 SKU 只在库存变动时触发同步。这样比全局提升频率更省配额，效果也更集中。
统一口径便于横向比较，平台特性保留则更贴近真实运营。我的做法是双轨：分析层用统一口径做跨平台对比，执行层保留平台原生字段做精细操作。两套并存会带来一点冗余，但能避免"为了统一而失真"。
自建的自由度高，但维护成本高、起步慢；采购工具起步快，但字段扩展受产品路线限制。我的判断标准是：如果你们有稳定的数据工程人力（至少 1 人专职），自建可行；如果没有，采购成熟的跨境数据分析工具更快见效，把人力放在口径治理上更划算。
这是最容易被忽略的取舍。我的原则是：一个看板如果没有明确的使用者和使用频率，就不要做。做了没人看的看板不仅浪费资源，还会稀释真正有用的看板的注意力。
下面这 20 个问题，是我在做 ERP 评估时实际会问的。建议你在选型会议上逐条问，把回答记录下来，作为后续验收依据。
这 20 条里，如果有一半以上答案是"不支持"或"需要定制开发"，基本可以判断这家 ERP 更适合做订单和库存管理，而不是做刊登复盘。这不是说它不好，而是定位不同。
最后回到开头那个朋友的问题。他们后来做了一件很朴素的事：在 ERP 里把"刊登批次 ID"和"错误码分类"两个字段补上，然后在分析层做了一张只有六列的批次复盘表。三个月后，驳回率从 24% 降到 11%，超卖从每月十几单降到两单以内，最重要的是他们第一次能回答"哪一批刊登真正赚到了钱"。
我的独特判断是：多平台刊登复核的本质，不是把 ERP 的功能清单打勾，而是把"刊登"这件事从操作日志升级成可归因的数据资产。平台数量、卖家规模、AI 功能这些都是商务语言；批次、时间戳、错误码、归因主键才是复盘语言。你在选型时问的是哪一套语言，决定了你两年后能不能做复盘。
如果让我给一个今天就能做的动作，我会说：打开你现在的 ERP，找一条三周前被平台驳回的刊登记录，看看你能不能在五分钟内回答四个问题，谁提交的、什么时间提交的、错误码是什么、这个 SKU 现在的利润是多少。四个问题只要有一个答不上来，你缺的就是这篇文章里说的某个字段。
把这篇内容里的五列表模型和 20 问清单存下来。它们不是理论框架，是我在真实项目里反复用过、改过、验证过的清单。你不需要一次全做完，但你需要知道自己的下一步该补哪一块。
我们做了三年多平台，店铺从 5 个涨到 40 多个，可每次开复盘会还是只能拿订单量和 GMV 说事，老板一问“是哪个平台、哪个环节出的问题”就答不上来。我以前一直以为刊登就是上架那一下，直到库存对不上、价格改错了，才发现根本不是这么回事。
把刊登当成一条会产生数据的状态链来记，至少分四层。第一层是平台、站点、店铺，记平台 ID、站点、店铺账号、币种、语言、税率、结算周期，用来区分平台差异、店铺表现和区域合规。第二层是商品、SKU、变体，记主 SKU、平台 SKU、父子变体关系、类目、属性、认证，用来定位属性缺失、类目错放和变体错配。
第三层是刊登任务、批次和草稿，记批次号、操作人、提交时间、审核状态、失败原因、重试次数，用来衡量刊登效率和质量。第四层是订单、库存和利润归因，记刊登记录怎么关联到订单、库存扣减、物流成本、平台佣金、退款和广告归因。
判断标准很简单：一个问题你能不能顺着“平台，店铺，商品，SKU，订单，利润”这条链路定位到具体环节，能定位就说明覆盖够了，只能定位到“这个月订单少”，就是字段缺了。还要记住刊登不是一次动作，审核反馈、价格库存同步、下架、禁售、重新上架这些状态变化同样要留痕。
我们上一套系统就是被销售一句“支持多平台刊登”打动的，上线后想导一份店铺维度的刊登失败明细都导不出来，更别提错误码和历史快照了。现在我再选型，都会先把复盘必需的字段列出来，再逐条让对方现场演示。
别问“支持不支持多平台刊登”，直接问能不能按平台、店铺、批次、SKU 四个维度导出刊登明细，导出的字段里有没有刊登状态、失败原因和错误码、重试次数、操作人和操作时间。第二问历史快照：标题、价格、库存、类目属性改过之后，旧版本还能不能查，因为复盘要还原“当时是什么状态”。
第三问同步监控：价格、库存、订单的同步延迟能不能看到，失败有没有自动重试和告警。第四问利润归因：能不能从刊登记录一路追到订单，再追到平台佣金、物流成本和退款。第五问权限和审计日志是否完整，谁改了价格、谁批量下架有没有记录。这五个问题都要求现场跑一遍，而不是看后台截图或功能清单。
如果对方只能给你看 PPT，不能当场演示导出和留痕，就先打个问号。
我们运营、财务、供应链三方对“刊登成功率”的理解完全不一样，运营算的是提交成功的比例，财务关心的是最后真正能卖出去的比例，供应链只看库存有没有同步上。每次月度复盘会都在吵口径，吵到最后指标就没人用了。
先把指标分成六类，再统一口径。效率类看刊登成功率、平均审核时长、批量任务耗时；质量类看驳回率、属性缺失率、图片或文案不合规率、类目错放率；库存类看库存同步延迟、超卖次数、缺货下架次数、海外仓库存差异；价格类看价格同步失败数、币种或税率错误、促销冲突、最低价预警；
异常类看错误码分布、重试次数、人工干预次数；利润类看平台佣金、物流成本、退款、广告费、汇率和结算周期。口径必须写死在文档里：分子分母分别是什么，按什么维度统计（平台、店铺、批次还是 SKU），时间窗是自然日还是平台结算周期，失败后重试成功算不算成功，这些都要提前约定。
落地节奏上，日报看刊登失败和同步异常，周报看驳回原因归类和店铺刊登质量，月报看平台维度、店铺维度的利润归因。指标数量可以少，但每一个都要有明确负责人和对应的修复动作，否则看板只是装饰。
我们同时做几个主流平台，同一个 SKU 在不同平台的类目和必填属性完全不同，一开始想用一套字段管所有平台，结果映射错乱、驳回一堆。后来才想明白，统一和差异化得分开处理，不能混在一起谈。
分两张表来处理。第一张是平台字段映射表，横向列平台，纵向列字段，写清每个平台的类目模板、必填属性、图片规格、禁售与合规要求，以及它们在 ERP 里对应的字段和映射规则，平台规则一更新就同步更新这张表。
第二张是统一指标字典，只统一统计口径，不强制统一业务字段，比如驳回率在所有平台都用同一个公式算，但驳回原因允许按各平台自己的错误码归类。判断依据是：跨平台复盘时要对比的是指标和趋势，不是原始字段本身，字段可以各平台各样，指标必须一套口径。
同时要避开一个常见误区，把“接入平台数量多”当成“多平台刊登能力强”，真正决定复盘能力的是类目属性映射、失败重试、历史快照和同步延迟监控这几件事。平台规则变更导致历史数据不可比的部分，要在报表里单独标注，别硬拼成一条趋势线。
读者评论
我们公司就是正文说的情况，ERP里刊登只有一个成功/失败状态，大促超卖后复盘连哪个批次、哪个运营提交的都查不到。文章把刊登拆成六状态、四层粒度这个思路很对，但现实中让ERP厂商补字段往往要等排期，落地比想象中慢。
驳回原因归一化成错误码加错误分类，这点说到痛处了。我们之前驳回文案就是原样存文本，月度总结只能靠人工翻，根本没法统计图片类占了多大比例。不过配置错误分类本身也是体力活，平台多的时候维护成本不低。
支持平台数量不等于刊登能力，这个判断我认同。选型时销售都拿平台清单说事，实际用起来字段深度才是关键。但文章假设ERP能产出结构化明细再外挂分析层，对小团队来说多一套数据链路也是成本，不一定划算。