电商商品CSV怎么核对？两行变体、字段映射与草稿验收

01从两条完整来源记录开始，先分清售价和成本

下载supplier.csv或复制本节全部内容。每行是一种SKU/颜色组合，不是一个订单。price为售价，cost为供应商单位成本；同为金额也不能映射到同一含义。material用于观察未映射字段的去向，所有商品与数字均为虚构。

1. 1
   保留原始文件、确认币种与字段含义；使用supplier.csv跟做，不先把cost改成售价。
2. 2
   先处理两行小样本，检查变体、售价、遗漏字段和失败恢复。
3. 3
   下载实际输出后逐行核对，再按目标平台的当前规范审阅；文件通过不代表店铺已执行。

sku,handle,title,brand,price,currency,option1Name,option1Value,cost,material
CUP-B,cup-01,Demo travel cup,Demo,19.90,USD,Color,Blue,8.00,Steel
CUP-W,cup-01,Demo travel cup,Demo,21.90,USD,Color,White,9.00,Steel

02本例先走商品准备，再按需要转换字段

这次完整案例使用Shopify商品准备和跨平台字段转换。下列其他入口分别处理报告、假设和行动，不应把同一份两行商品表当成广告、结算或库存记录。

• 映射 Amazon 商品文件: 按所选平台模板核对必填表头、父子行与单位，再导出审核文件。
• 准备 Shopify 商品导入: 检查 handle、变体组合与图片字段，导入前将导出 CSV 与当前 Shopify 规范比较。
• 转换跨平台字段: 保留明确的源字段到目标字段映射，对不支持字段进行检查而不是静默丢弃。
• 核对利润与结算假设: 输入已核实成本、费用与币种，检查结算差异并比较情景；结果取决于输入假设，不构成财务建议。
• 核对广告导出: 确认归因周期与指标映射，检查否词候选和预算进度，将出价预演视为仍需账号端审核的情景。
• 比较选品样本: 保留竞品样本日期、采购报价假设与评价证据；小规模导入样本不代表完整市场调查。
• 核对库存情景: 声明需求与交货周期假设，批准补货前检查库龄、装箱与异常清单。
• 整理售后证据: 用已核实事实检查退货记录、资料有效期与工单编号；请求清单不等于已发送消息或平台批准。
• 规划经营行动: 将流量或转化异常关联到证据，分配审核人，并在工作区外行动前保留批准状态。

03完整操作：读入、映射、确认，再导出两行草稿

打开Shopify商品准备，上传supplier.csv或粘贴后点击“读取数据”。检查原始行数为2。字段应对应sku、handle、title、brand、price、currency、option1Name、option1Value；特别确认price没有误选cost。

1. 1
   确认handle都是cup-01，title与选项名称Color一致，Blue/White分别对应CUP-B/CUP-W。
2. 2
   店铺币种填USD，勾选币种和导入预览确认。没有检查问题后下载CSV；另外点击“下载原始数据”保存source-products.json。
3. 3
   用CSV解析器或按文本列导入下载件，核对两条SKU、Price原文19.90/21.90、Option1 value为Blue/White。Status应为draft，Published on online store为false。
4. 4
   检查导出列没有cost/material，同时原始JSON仍保留8.00/9.00和Steel。没有进入目标文件的字段不等于已完成迁移；真实目标需要它们时应另行按规范处理。

Shopify商品CSV文档说明了字段依赖与导入选项。真实导入需检查当前格式、变体和覆盖选项；本例不连接店铺，也不执行导入。

04故意重复Blue，为什么换SKU也不能解决？

duplicate-option.csv只把CUP-W的White改成Blue，其他来源不变。在Shopify准备中重新读入，应定位到第3行（包含表头计数）的同一商品变体组合重复。两个SKU不同，仍不能把同一handle下两个Color/Blue当成不同选项。

本练习已确认CUP-W应为White，因此重新加载supplier.csv、复核映射与币种确认，再导出。真实业务先确认颜色事实；不为了消除提示新造handle或颜色。更改输入后不要继续交付上一份下载件。

若目标只需要三列，可转到跨平台字段转换，读入同一源表，目标表头填本节内容并读取，再分别映射sku、title、price。确认后下载mapped-products.csv。这个文件只是三列映射练习，不是可直接提交的Amazon模板。

item_sku,item_name,standard_price

需要真实多行工作簿时，继续按字段编码行与模板映射定位区域；父子关系另按变体表检查核对。以下利润与期间段落是另一个自编算术场景，不使用这里的两行商品价格或成本。

05把利润结论拆成输入假设，而非只看绿色百分比

下面是纯粹自编的算术场景，所有金额都是同一币种的单位金额，也不是 Amazon 的实际费率：售价 100，货品成本 35，平台相关费用 15，履约运输 8，分摊广告 12，退货预留 5。此定义下的单件剩余为 100−35−15−8−12−5＝25，占售价 25%。它不包含尚未列入的其他费用，因此不能直接叫作经审定的净利润。

若广告分摊变成 20，其他输入不变，剩余为 17，比例 17%；若另有遗漏的单件费用 6，则在这个新场景下只剩 11，比例 11%。把每个费用的来源文件、期间和分摊单位留在结果旁边，比只给出“25%”更容易发现遗漏。缺失费用应标为待确认，不能默认零。

06报告期间不一致时，先暂停行动建议

自编广告记录花费 120，而同一统计定义下归因销售额为 600，花费除以归因销售额是 20%。如果误拿另一个更长期间的销售额 1000 作分母，就会得到 12%，看似显著改善，实际上只是两个期间混用了。先固定站点、币种、开始结束日期与归因口径，再讨论候选排除或预算调整。这里的比例只演示分母变化，不提供投放建议。

同样，库存文件中的 40 件、每周假设需求 10 件可构成 4 周的简单覆盖场景，但不代表已确认未来销量或到货时间。导出运营行动时，在任务中写清“依据某期文件，待账户侧核实”，并保留批准和执行记录；不要把文件分析结果描述成已经同步到账户。

07把原件、草稿和待确认项一起交付

交付时保留supplier.csv、source-products.json、Shopify草稿CSV或mapped-products.csv及本轮核对记录。原始字段、目标字段和人工待处理项应能相互对应，不把草稿下载当作上架或批准证据。