如何在 Google 表格中翻新亚马逊 Listing（新 ASIN、同一 SKU 与 FBA 库存）
把亚马逊 listing 迁移到全新的 ASIN，无需移库或换标——保留 SKU 和 FBA 库存，重置 listing，全部在 Google 表格中完成。
速览
- 备份：在 Listing Snapshot 里双重备份——按 SKU 拉取你提交的版本，按 ASIN 拉取亚马逊目录的版本。
- 创建：在 Publish Queue 用临时 SKU + 全新 UPC（或 GTIN 豁免），修改部分标题、五点、描述等文案后创建新 ASIN，其余属性全部沿用；同批的 DELETE 行删掉旧 listing。
- 重建：把原版文案写回新 ASIN，再把新 ASIN 作为 externally_assigned_product_identifier，把原 SKU 重建到新 ASIN 上。
- 搬库存：开一个一句话的 case，客服把 FBA 库存映射过去。商品、库存、SKU 全部不动，变的只有 ASIN。
前言
翻新 listing，指把一个在售 FBA 商品整体迁移到一个全新的 ASIN 上——SKU、FNSKU 标签、以及所有已经躺在亚马逊仓库里的库存都保持原样。卖家用它让 listing 从零开始、重新获得新品期的流量，而完全不碰实体库存。
整个玩法就四步：
- 原来：你有 SKU1 → ASIN1（老 listing）。
- 新建：用临时 SKU2，修改部分标题、五点、描述等文案后创建新品——其余属性沿用旧 listing——亚马逊分配全新的 ASIN2。
- 换家：删掉旧 listing，再用 SKU1 重建、直接指向 ASIN2。从此 SKU1 → ASIN2。
- 搬库存：FBA 库存还认 ASIN1，开一个 case，客服把库存映射到 ASIN2。搞定。
在卖家平台手工做这件事意味着和批量模板、类目表格、库存加载器缠斗。而在 SellerSheet 的 Catalog 表格里，整个流程只用两个标签页：Listing Snapshot（备份与验证，既有你提交的版本，也有亚马逊目录的版本）和 Publish Queue（所有创建／更新／删除提交）。
全文变量约定
- SKU1：原 SKU，最终要保留的——如
SKU-001。 - ASIN1：要甩掉的旧 ASIN——如
B0XXXXXXX1。 - SKU2：用来创建新 ASIN 的临时 SKU——如
SKU-001-08141030（SKU1 + 时间戳）。 - ASIN2：全新 ASIN，listing 的新家——如
B0XXXXXXX2。
前置条件
- 店铺已授权：亚马逊店铺已连接 SellerSheet 且有写权限——在 sellersheetai.com 登录，于 设置 → 店铺与市场 连接店铺。
- 一个不会撞回 ASIN1 的商品标识符：一枚 全新未用过的 UPC，或品类有 GTIN 豁免（标识符留空）。
- Catalog 表格 及其 Listing Snapshot、Publish Queue 标签页（由 SellerSheet 侧边栏创建——见 Catalogs）。
- 仅变体子体：动手前先记下父体 SKU、变体主题（variation theme）和主题属性值——最后一步要恢复变体关系。
绝对不能复用旧 UPC
亚马逊匹配 GTIN 的优先级 高于 标题。SKU2 若带着 ASIN1 的旧 UPC 提交，会直接挂回 ASIN1——新 ASIN 根本不会产生。这一个失误是整个流程失败的头号原因。
侧边栏使用技巧
四个习惯让整个流程“自带说明书”：
- 侧边栏菜单必须与当前标签页一致。每个分组（Listing Snapshot、Publish Queue……）都是标签页专属的——侧边栏上写着 “active tab must match”。按钮点了没反应，先看表格底部当前激活的是哪个标签页。
- 悬停任意按钮 即可看到它的功能说明，点之前先看一眼。
- 看单元格备注（cell note）。表头单元格带有备注（角上的小标记），说明这一列怎么用、接受什么值、有什么示例——悬停即可阅读。
- Publish Queue 的表头就是内置手册。每一列属性的第 4 行是格式提示和示例，第 6 行是列的显示名（如 Externally Assigned Product Identifier），隐藏的第 5 行是服务端读取的代码键。你的 listing 从第 7 行开始。
阶段一：先把一切备份好
痛点：这个流程会主动删除一条在售 listing。如果出了岔子而你没提前把每个属性都留底，你就得凭记忆重建 listing——标题、五点、尺寸、合规字段，全部。
1a. 备份“你提交过的”版本（按 SKU）
打开 Listing Snapshot 标签页，Store 列填店铺（如 myStore-US）、SKU 列填 SKU1，点侧边栏 Listing Snapshot → Fetch by SKU。该行填充后，JSON 列以 JSON 格式完整备份了这条 listing 的所有属性，这就是你的还原底稿。同时记下 ASIN 列的值，即 ASIN1。
1b. 备份“亚马逊实际接受的”版本（按 ASIN）
在 Listing Snapshot 的新一行填店铺和 ASIN1、SKU 留空，点侧边栏 Listing Snapshot → Fetch by ASIN。这一份是亚马逊目录端的规范化数据（买家所见）——既能看出亚马逊改写了你的哪些字段，也是之后开 case 的证据。
Fetch by SKU 和 Fetch by ASIN 只处理 JSON 单元格为空的行。后文需要再次拉取某个 SKU 时，请用新的一行，或清空该行的 JSON 单元格。
阶段二：创建新 ASIN
痛点：你没法直接“向亚马逊要一个新 ASIN”——目录系统的存在就是为了防重复。原样提交同一个商品，亚马逊会把新 SKU 直接绑回你正想逃离的那个旧 ASIN。
这一阶段要走的是一个平衡。新 listing 必须与 旧 ASIN 属性一致，因为阶段四开 case 的前提就是两个 ASIN 是同一个产品。但如果提交得完全一致，亚马逊会判定这个产品已经存在，把新 SKU 绑到旧 ASIN 上；如果区别太大，创建后再改回去有时会改不成功。
所以做法是：沿用旧 listing 的所有属性，只对 Item Name、Item Highlight、Bullet Point、Product Description 四个文案字段做部分修改，让亚马逊以为是一个新产品。等新 ASIN 创建成功后，再把这四项改回与旧 ASIN 完全相同的内容（阶段三第 1 步）。
1. 把商品载入 Publish Queue
切到 Publish Queue 标签页，按侧边栏的编号分组操作：
- 第 3 行填 Store 和 Listing Locale（如 en_US）。
- 数据行 productType 列填入 Listing Snapshot 备份里的 Product Type（如
HEADPHONES）。 - 点 Get Template——按这个类目加载全部属性列，相当于在后台下载对应类目的 Excel 批量模板，但直接在表格里。
- sku 列填 SKU1，点 Fetch by SKU——整行属性被拉入。
Publish Queue 工作流——Template → Fill rows → Validate → Publish，全部在侧边栏完成。
2. 把这一行改造成“新品”（SKU2）
| 列 | 改成 |
|---|---|
| sku | SKU2——如 SKU-001-08141030（SKU1 + 时间戳） |
| operationType | UPDATE |
| externally_assigned_product_identifier#1.value | 新 UPC——GTIN 豁免则 留空 |
| externally_assigned_product_identifier#1.type | upc——GTIN 豁免则 留空 |
| supplier_declared_has_product_identifier_exemption | GTIN 豁免填 true；否则留空 |
| product_site_launch_date | 若为旧 listing 的历史上架日期则 清空 |
| item_name / title_differentiation / bullet_point / product_description | 部分修改（见下） |
为什么新建也用 UPDATE？UPDATE 提交的是整条 listing：SKU 不存在时就是创建，SKU 已存在时就是覆盖更新。所以这里不需要单独的“创建”操作，SKU2 填 UPDATE 即可。
三列关键标识——type、value 和 merchant_suggested_asin（后者留到阶段三才用）。
部分修改，不要推倒重写。只动这四个文案字段，幅度够让查重认为是新品即可——标题换结构、亮点换说法、五点和描述换措辞。改得太少，SKU2 会被合并回 ASIN1；改得远超这四个字段，后面把原文改回去有时会失败。其余属性与旧 listing 保持完全一致。
如果 SKU1 是 变体子体，同时清空 parentage_level、child_parent_sku_relationship、variation_theme 和主题属性（如颜色／尺寸）——先以独立品创建，变体最后再恢复。
继续右滚可见 GTIN 豁免开关（豁免时填 TRUE）和变体列（子体翻新时清空）。
3. 同批加一行 SKU1 的 DELETE
在下一空行，sku 列填 SKU1，operationType 选 DELETE。删除行只需要这两格。创建 SKU2 的同时删除旧 listing，腾出 SKU1，阶段三才能用它重建到新 ASIN2 上。
两行一批——SKU2（UPDATE）创建新品；SKU1（DELETE）删除旧 listing。
4. 校验并提交
点 Validate (Preview)，到 Submission Log 标签页确认无 ERROR 级问题——校验只是预览，不会发布任何东西（DELETE 行没有预校验，会被跳过）。干净之后点 Create/Replace/Del. 提交（≤20 行即时生效、按每行 operationType 分发；更大批量用 Submit Feed）。
5. 验证 ASIN2 诞生
等 10–15 分钟。在 Listing Snapshot 拉取 SKU2，读 ASIN 列，那就是 ASIN2。关键校验：ASIN2 ≠ ASIN1。也可以在卖家平台交叉确认。
拿回来的还是旧 ASIN？
如果 SKU2 返回的是 ASIN1，说明被亚马逊合并了——四个文案字段的差异不够（或者标识符撞了）。删掉 SKU2，加大这四个字段的修改幅度，重新提交。
阶段三：把你的 SKU 重建到新 ASIN 上
痛点：ASIN2 有了，但它挂在一个一次性 SKU 上、顶着占位文案。你真正的 SKU——FBA 库存、广告、运营全都围着它转的那个——已被删除、无家可归。而且如果两个 ASIN 看起来不像同一个商品，客服会拒绝帮你搬库存。
1. 先把原版文案写回 SKU2
重建 SKU1 之前，先把阶段一 Listing Snapshot 备份里的 原版 文案复制回 SKU2 行，以 operationType UPDATE 提交。列名对应关系：
| 备份（显示名） | Publish Queue（代码键） |
|---|---|
| Item Name | item_name |
| Item Highlight | title_differentiation |
| Bullet Point | bullet_point |
| Product Description | product_description |
Publish Queue 第 6 行是显示名，隐藏的第 5 行是代码键。
为什么重要：这一步让 ASIN2 的属性与 ASIN1 完全一致。阶段四开 case 时，客服就没法以“两个 ASIN 属性不一致、代表不同产品”为由拒绝映射。提交后再到 Listing Snapshot 拉一次 SKU2，确认仍然是 ASIN2。
同一次提交里，把标识符锁定到新 ASIN——确保之后的每次更新都落在新建的 ASIN 上（identifier 留空时，亚马逊有时可能再新建一个 listing）：
| 列 | 填 |
|---|---|
| externally_assigned_product_identifier#1.value | ASIN2 |
| externally_assigned_product_identifier#1.type | asin |
| merchant_suggested_asin | ASIN2 |
| operationType | UPDATE（必须） |
标识符与 GTIN 豁免只能二选一：若创建 SKU2 时豁免列填了 TRUE（supplier_declared_has_product_identifier_exemption），这里必须先把 TRUE 删掉——它不能与 externally_assigned_product_identifier 同时存在。
2. 用 SKU1 和 ASIN2 重建
回到 Publish Queue：
- 这一行属性与 SKU1 完全一致，标识符也已在上一步指向 ASIN2——只需把 sku 改为 SKU1，operationType 为
UPDATE。 - 确认 SKU1 已删除干净——在 Listing Snapshot 用 SKU1 拉取，已找不到该 SKU（原因写在该行的 Image 列）即已删除；还能拉到就多等一会儿再查。
- Validate (Preview) → Create/Replace/Del.
3. 验证重建结果
- Listing Snapshot——拉取 SKU1：ASIN 列应显示 ASIN2。
- 卖家平台——Manage All Inventory 显示 SKU1 / ASIN2；Fix Stranded Inventory 显示 SKU1 / ASIN1。stranded（库存滞留）条目是 预期现象——FBA 库存要到阶段四才会跟过来。
提交成功 ≠ listing 存在
亚马逊会“成功”接受对不存在 SKU 的操作。永远以 Listing Snapshot 拉取结果或卖家平台实查为准——绝不能只看 feed 状态。
阶段四：搬 FBA 库存并收尾
痛点：listing 已经住进 ASIN2，但仓库里的每一件货还挂在 ASIN1 上——处于 stranded（库存滞留）状态、卖不了。走移除订单再重新发货，要花几周时间和真金白银。
1. 开 case
路径：卖家平台 → Help → Get support → Selling on Amazon → Products and inventory → Fix a product page。case 正文建议用英文提交，直接用这句（换成你自己的 SKU1 和 ASIN2）：
Hello team, please remap SKU: SKU-001 to ASIN: B0XXXXXXX2.
They represent the same product. Thanks!如客服要证据，提供 Manage All Inventory 截图和阶段一 Listing Snapshot 的按 ASIN 备份，证明两个 ASIN 是同一商品。处理完成后 stranded 条目清零，库存在 ASIN2 下可售——不换标、不发新货件。
2. 收尾
- 删除 SKU2——库存映射完成后它只是 ASIN2 上多余的空 offer，会干扰定价和购物车。在 Publish Queue 加一行 DELETE 清掉。
- 恢复变体（仅子体）——补回 parentage_level = child、child_parent_sku_relationship、variation_theme 和一个不与兄弟 SKU 冲突的主题属性值。
- 归档 备份行、case ID 和时间线。
常见坑
| 坑 | 后果 | 规避 |
|---|---|---|
| SKU2 复用旧 UPC | 直接挂回 ASIN1——不产生新 ASIN | 新 UPC，或 GTIN 豁免且标识符留空 |
| 文案修改太保守 | 查重把 SKU2 合并进 ASIN1 | 四个文案字段做部分修改；永远验证 ASIN2 ≠ ASIN1 |
| SKU1 未释放就重建 | SKU 可能挂回旧目录数据 | 先确认 SKU1 已查不到；merchant_suggested_asin 必填 ASIN2 |
| 只信 feed 状态 | listing 可能实际没建上 | 以 Listing Snapshot 或卖家平台实查为准 |
| 忘删 SKU2 | 同一 ASIN 上的重复 offer | 阶段四库存映射完成后清理 |
| 子体没先剥离变体属性 | 创建报错，或子体重新挂回父体 | 阶段二清空变体列；阶段四恢复 |
常见问题
需要换标或移动 FBA 库存吗？
不需要。FBA 库存绑定的是 FNSKU，整个流程中它从未改变。SKU 重建到新 ASIN 后，一个简短的 case 即可让亚马逊把现有库存重新映射——不走移除订单、不换标、不发新货件。
为什么临时 SKU 必须用新 UPC 或 GTIN 豁免？
亚马逊先按 GTIN 匹配，之后才看标题。临时 SKU 带着旧 UPC 提交会直接挂回旧 ASIN，新 ASIN 根本不会产生。用一枚未使用过的 UPC，或在品类允许时留空标识符并勾选 GTIN 豁免。
临时 SKU 拿回来的是旧 ASIN——哪里出错了？
要么标识符撞了（同一个 UPC），要么修改后的四个文案字段仍太相似，被亚马逊查重合并进了现有 ASIN。删掉临时 SKU，加大这四个字段的修改幅度，重新提交。
为什么 Fix Stranded Inventory 里显示我的 SKU 和旧 ASIN？
这是流程中段的预期现象。Manage All Inventory 显示 SKU 已在新 ASIN 上，而 FBA 库存在 case 处理前仍引用旧 ASIN。case 处理完成后 stranded 条目清零，库存在新 ASIN 下可售。
变体子体能翻新吗？
能。先记下父体 SKU、变体主题和主题属性值；创建临时 SKU 时清空变体列；最后把重建好的 SKU 重新挂回父体——主题属性值不要与现有兄弟 SKU 冲突。
为什么重建 SKU 前要先恢复原版文案？
case 能否通过，取决于两个 ASIN 是否明显是同一个商品。恢复原版标题、五点和描述后，新 ASIN 的属性与旧 ASIN 完全一致，客服就没有“是不同产品”的理由拒绝映射。