平面文件自动化：跨多个 Amazon 站点管理商品信息

Amazon 的平面文件系统是批量管理大型产品目录中商品信息最全面的接口，但对多站点运营而言，也是文档最不完善的接口之一。不同站点采用不同模板版本、必填字段和校验规则，即使同一品类中的同一商品也不例外。要以同一套产品数据管理十个站点的商品信息，就必须系统处理模板差异、属性翻译，以及上传、校验和修正的循环。

本文介绍我们用于多站点产品目录管理的平面文件流程：模板有何差异、哪些环节最能通过自动化获益，以及哪些环节仍不可避免地需要人工介入。

什么是平面文件

平面文件是以制表符分隔的电子表格，Amazon 用它批量创建和更新商品信息。每行代表一个产品，每列代表一个属性。模板从 Seller Central 的“目录 > 通过上传添加商品”部分下载，规定哪些列必填、哪些可选，以及每个字段允许哪些值。

平面文件系统早于 SP-API Listings Items API，目前仍是 Seller Central 内主要的批量编辑接口。在 API 方面，Amazon 于 2024 年 3 月宣布弃用平面文件和 XML 格式的商品信息 Feed，计划于 2025 年 6 月 30 日移除，转而使用基于 JSON 的 Listings Items API 和 JSON_LISTINGS_FEED；通过 Seller Central 上传平面文件不受影响。对于在多个站点销售、SKU 超过几十个的卖家，批量工作流实际上是必需的，而在我们的系统中，平面文件是主要的产品目录管理接口。

实际上，Amazon 提供的平面文件文档零散，而且经常过时。任何模板的最新规范，就是针对当前站点和品类刚下载的模板本身。依赖缓存模板或六个月前的文档，很容易导致上传错误。

不同站点的模板差异

多数卖家初次尝试多站点运营时，都会低估模板之间的结构差异。它们并不是同一组字段的不同语言译本。

美国站某个品类的服装模板可能有五十个属性列，对应的德国站模板可能有六十个，包括美国站没有的字段，例如欧盟法规要求的特定化学品合规声明，或适用于某些产品类型的能效标签要求。日本站模板可能以不同方式组织尺码和颜色变体，所用变体主题名称也不一定被美国站版本识别。

即使字段名相同，允许的值也常因站点而异。item_type_keyword 字段在 .com 和 .co.uk 接受的字符串不同。color_name 会按站点专用列表校验：某个颜色名称在美国站通过校验，在德国站或日本站却可能因不在当地允许值集合中而被拒绝。错误报告并不总会明确说明原因；您可能只收到通用属性错误，而不是“该值不在允许列表中”的直接提示。

模板版本会在没有通知的情况下更新。Amazon 会定期发布某个品类的新模板，增加必填字段或弃用旧字段。如果使用的模板已不是当前版本，上传可能成功，但商品无法正确建立索引，或某些属性被忽略而没有提示。每次较大规模更新产品目录时，我们都会先下载最新模板，而不复用已保存的版本。

尺码体系转换

对于服装和鞋类，尺码体系转换是多站点产品目录管理中最耗费人力的环节之一。美国、欧盟、英国和日本的尺码体系并不直接对应，不同产品类型的换算表也不统一。

在常见换算表中，美码 8 号女鞋通常对应英码 6 号和欧码 39 号（品牌换算表可能相差半码），但美码 M 号女式上衣可能对应欧码 38 或 40，具体取决于品牌的尺码规则。不存在通用对照表。正确的方法是按产品类型和品牌维护主尺码映射，并对照具体制造商的尺码指南验证。

必须正确配合填写 Amazon 的 size_name 和 size_system 字段，商品才能在各站点的浏览筛选器中正确显示。如果在 size_name 中填入美码，却未声明 size_system，该值可能被当作未格式化的字符串；根据我们的经验，商品可能不会出现在按尺码筛选的搜索结果中。上传确认不一定能揭示问题：商品创建成功，但尺码筛选不起作用。

尤其在日本站，许多品类的尺码体系与欧美规则都不同。日本服装尺码使用独立的数字体系，鞋码则以厘米为基础。我们使用过的日本模板要求填写 size_map_unit_of_measure，美国和欧盟对应模板中却没有这个字段。当时跨市场复用模板时，缺少该字段曾导致处理失败而没有提示。字段名称因产品类型和模板版本而异，请以实际下载的模板中的列标题和有效值为准。

后台搜索词限制

后台搜索词，即填入 generic_keyword 字段的搜索词，在不同站点有不同的字符限制，限制的计量方式也不同。

Amazon.com 对 generic_keyword 字段的合计内容施加 249 字节限制。Amazon.de 也按字节限制，但德语文本比英语包含更多多字节字符，因此在英语中符合美国站字节限制的搜索词串，翻译后可能超出德国站的字节限制。Amazon.co.jp 的限制还受日语字符编码影响：一个汉字在 UTF-8 中占三字节，所以日语实际可容纳的搜索词数量，远低于按拉丁字符理解字节上限时的预期。

实际上，搜索词限制对多站点商品信息表现的影响相对较小。我们观察到，把后台搜索词精确填满字节上限的过度优化，收益递减；相比之下，根据自然语言搜索习惯优化可见标题、要点和描述更有效。字节上限是需要遵守的约束，而不是必须用满的性能杠杆。

实用的方法是为每个产品维护各站点专用的搜索词集合，控制在该市场限制内，并通过程序核验字节数，而不是目测。一个简单的 Python 函数，将搜索词串编码后计算字节长度，并与站点上限比较，就能在上传前发现截断问题。

自动化流程

平面文件自动化的核心认识是：站点间的差异主要在结构，而不在含义。产品相同，尺寸、材料、用途和关键特性都不变；变化的是这些信息必须如何呈现在各站点的模板中。

我们维护一份主产品数据表，以中立格式存储所有属性：尺寸使用公制，尺码使用制造商原有体系，搜索词使用源语言，品类映射到中立的内部分类体系。通过一层转换，处理各目标市场的结构差异，再从主表生成站点专用平面文件。

转换层是一个脚本，我们使用 Python 编写。它将主表属性映射到各站点对应的平面文件列，换算尺码，将品类分类映射到站点的浏览节点结构，并在生成输出文件前执行字段级校验。需要人工审查的字段，例如翻译文案、站点特定合规声明和各国监管属性，会在输出中标记，而不会自动填入。

下载、编辑和上传这一循环本身是半自动化的。下载通过 SP-API Reports API 脚本执行，该 API 提供 GET_FLAT_FILE_OPEN_LISTINGS_DATA 及相关报告类型。处理下载文件、与主表比较和生成上传文件均已自动化。上传以及审查上传处理报告仍由人工完成，并非无法自动化，而是大规模上传出错的代价足够高，需要在向 Amazon 提交文件之前进行人工审查。

常见故障模式

上传错误可分为三类：校验失败、处理失败，以及无报错的失败。

校验失败最容易处理：上传报告会明确返回错误信息，指出出错的行和字段。最常见原因包括受控词表字段（size_name、color_name、item_type_keyword）的值无效、缺少特定模板版本要求的必填字段，以及搜索词或描述字段超出字节上限。

处理失败是指上传通过校验，但商品信息未按预期更新。常见原因包括变体关系错误，例如提交子 ASIN 时没有匹配的父 ASIN，或父商品的变体主题与子商品属性不符；以及浏览节点冲突，即提交的节点与现有 ASIN 已有的分类不匹配。

无报错的失败最难发现：上传成功，处理报告没有错误，但商品表现不正常。例如尺码未出现在浏览筛选器中、搜索词未被索引，或后台有变体关系但前台显示不正确。发现这类问题需要通过 Catalog Items API，将线上商品属性与提交值比对，而不是目测网店前台。

防范这类无报错失败的实用方法是上传后核验：在上传后二十四小时内，通过 API 拉取每个受影响 ASIN 的线上商品数据，与提交值比较并标记差异。这一步并不复杂，却决定了产品目录管理流程是否可靠；缺少它，就需要不断人工审计，才能发现错误报告从未提示、原因不明的商品信息变化。