大多数关于 XML Feed 的文章都假定您在卖 T 恤。
十年前，当“商品 Feed”仅仅意味着一个 Google Shopping 文件时，这种假设是合理的。但如今已不再成立。汽车经销商、招聘网站、酒店集团、房产门户和博彩平台如今都在运行 Feed 驱动的广告，而它们都不会提交 size 或 gtin。它们提交的是 VIN、IATA 代码、卧室数量、雇佣类型和开球时间。
底层机制完全相同，参数却各不相同。
本指南涵盖这两方面：适用于所有 XML Feed（无论属于哪个垂直领域）的结构规则，以及每种主要 Feed 类型的具体属性集——零售、本地库存、车辆、旅游、房产、招聘，以及赛事、活动和放映场次等有时效性的库存。每种类型都附有可用的 XML 示例。
1. XML Feed 究竟是什么
XML Feed 是一种结构化文件，以机器无需人工解读即可使用的方式描述库存。平台按计划抓取文件、进行解析，并根据其中的内容创建商品信息、广告或搜索结果。
格式本身并没有大多数人想象的那么重要。重要的是约定：每个目标渠道都会发布一份规范，说明它要求哪些字段、哪些值是合法的，以及当值错误时它会如何处理。Feed 是您这一方对该约定的履行。
由此产生两个后果，而它们正是 Feed 比看上去更难的原因：
约定因目标渠道而异。Google 的商品规范、Meta 的商品目录规范和 Indeed 的招聘 XML 几乎没有相同的字段名称。同一个源商品目录必须针对每个渠道进行不同的转换。
违规大多会静默失败。格式错误的字段很少会导致整个文件出错。它只会让某一件商品被拒登、某一条商品信息被降级，或让广告中丢失某个属性——而您的广告系列仪表板上不会有任何提示。
2. 文件的构成
大多数广告 XML Feed 使用带有命名空间扩展的 RSS 2.0。其结构始终是相同的三层：
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
<channel>
<title>Example Store — Product Feed</title>
<link>https://example.com</link>
<description>Full catalogue, updated hourly</description>
<item>
<!-- one inventory item -->
</item>
</channel>
</rss>- XML 声明用于设置编码。实际上它必须是
UTF-8；任何其他编码都会导致非英语商品目录中的字符乱码，这也是土耳其语、德语和捷克语商品标题出现乱码的最常见原因。 - 命名空间声明（
xmlns:g="..."）让<g:price>成为合法元素。如果省略，所有带前缀的元素都会被静默忽略——Feed 可以被解析，但几乎没有任何内容会被导入。 <channel>包含 Feed 级别的元数据。<item>是一个库存单位。“一个单位”的含义是一个需要做出的决定，而不是既定的：一个 SKU、一个变体、一辆车、一个职位空缺、一家酒店、一场赛事。
并非每个垂直领域都使用这种结构。招聘 Feed 使用 <source><job>，一些电商平台则完全定义了自己的根元素。但“文档、容器、重复条目”这一三层逻辑始终成立。
3. 通用核心字段
有七个参数几乎出现在迄今为止编写的每一份 Feed 规范中，只是名称不同。理解了这些，您就能读懂任何规范。
| 概念 | Google Shopping | Meta 商品目录 | Indeed 招聘 | 用途 |
|---|---|---|---|---|
| 唯一 ID | id | id / vehicle_id / home_listing_id | referencenumber | 跨同步保持身份一致 |
| 名称 | title | title / name | title | 它是什么 |
| 详情 | description | description | description | 它为什么重要 |
| 目标 URL | link | url | url | 在哪里转化 |
| 图片 | image_link | image[0].url | — | 它长什么样 |
| 价格 | price | price | salary | 它的价格 |
| 状态 | availability | availability | （是否存在于 Feed 中） | 它是否在线 |
关于 ID，有三条普遍适用的规则，而违反它们所造成的损害比任何其他单个字段都大：
- 它必须稳定。如果您的 ID 在导出时重新生成——基于行顺序、时间戳或不断变化的内容的哈希值——每次同步都会抹去该商品积累的效果历史，让它从零开始。
- 它必须唯一。重复的 ID 会导致后面的行被丢弃，且不会有任何错误提示。商品就这样消失了。
- 它必须与您的像素或代码发送的值一致。Meta 的商品目录匹配、Google 的动态再营销以及所有再营销产品，都依赖于 Feed ID 与网站事件 ID 是相同的字符串。这是动态再营销“不起作用”的最常见原因。
4. 零售/电商参数
这是文档最完善的规范，也是大多数其他垂直领域借鉴的基础。
必填项
| 属性 | 说明 |
|---|---|
id | 最多 50 个字符。稳定、唯一，与像素事件一致。 |
title | 最多 150 个字符。把品牌和人们实际搜索的词放在前面。 |
description | 最多 5,000 个字符。纯文本；不得包含促销文案或 HTML。 |
link | 商品页面，而不是类目页或搜索结果页。必须可被抓取。 |
image_link | 主图。根据 2026 年规范，最小为 500x500（见下文）。 |
availability | in_stock、out_of_stock、preorder、backorder。 |
price | 数值加 ISO 货币代码：899.90 TRY。必须与着陆页完全一致。 |
标识符
brand、gtin、mpn 和 identifier_exists。GTIN 决定了您的商品能否与 Google 的商品知识图谱匹配——因此也决定了它是否会出现在比价和 AI 购物版面上。无论规范怎么说，它在实践中都不是可选项。
变体
item_group_id、item_group_title、color、size、size_type、size_system、material、pattern、gender、age_group。
变体本身就是一个专题；简而言之，item_group_id 在一个组内必须完全相同，并且源自稳定的源数据；gender 和 age_group 在组内保持不变，而 color 和 size 则不然。
分类
google_product_category（Google 的分类体系，ID 或完整路径），product_type（您自己的分类体系——正是这个字段让广告系列结构成为可能，而且它是自由格式的，所以请善加利用）。
商业属性
sale_price、sale_price_effective_date、unit_pricing_measure、unit_pricing_base_measure、installment、subscription_cost、loyalty_program。
物流
shipping、shipping_weight、shipping_length / _width / _height、shipping_label、transit_time_label、min_handling_time、max_handling_time、tax。
广告系列控制
excluded_destination、included_destination、ads_redirect、custom_label_0 至 custom_label_4。
五个自定义标签是整个规范中最未被充分利用的字段。它们对 Google 没有任何含义——它们存在的唯一目的就是让您进行细分。利润区间、库存深度、季节性、商品上架时长、GA4 效果层级。如果您的广告系列结构无法表达某条业务规则，原因通常就在这里。
媒体
additional_image_link、lifestyle_image_link、virtual_model_link、video_link。
一个精简但完整的零售商品示例
<item>
<g:id>KRC-4210-BLK</g:id>
<g:title>Karaca Fine Pearl 6-Person Dinner Set — Black</g:title>
<g:description>26-piece porcelain dinner set for six. Dishwasher and microwave safe.</g:description>
<g:link>https://example.com/urun/fine-pearl-6-kisilik</g:link>
<g:image_link>https://cdn.example.com/krc-4210-blk-01.jpg</g:image_link>
<g:additional_image_link>https://cdn.example.com/krc-4210-blk-02.jpg</g:additional_image_link>
<g:video_link>https://cdn.example.com/video/krc-4210.mp4</g:video_link>
<g:availability>in_stock</g:availability>
<g:price>4299.00 TRY</g:price>
<g:sale_price>3499.00 TRY</g:sale_price>
<g:sale_price_effective_date>2026-11-24T00:00+0300/2026-12-01T23:59+0300</g:sale_price_effective_date>
<g:brand>Karaca</g:brand>
<g:gtin>8680150042109</g:gtin>
<g:condition>new</g:condition>
<g:google_product_category>672</g:google_product_category>
<g:product_type>Home & Kitchen > Dinnerware > Dinner Sets</g:product_type>
<g:custom_label_0>high-margin</g:custom_label_0>
<g:custom_label_1>bf-2026</g:custom_label_1>
</item>请注意 product_type 中的 & 和 >。URL 和类目路径中未转义的 & 字符，是 XML 文件完全无法解析的最常见原因。
5. 2026 年有哪些变化
Google 商品数据规范中有三项变化，值得现在就着手应对，而不是等到截止日期。
image_link 和 additional_image_link 的最低图片分辨率现为 500x500 像素，适用于所有类目和营销方式。Merchant Center 自 2026 年 4 月起开始显示警告；强制执行将于 2027 年 1 月 31 日开始。Google 可能会自动放大部分较小的图片，但将此视为解决方案是错误的——放大后的图片看起来就是放大过的，而图片质量是影响点击率的变量之一。
video_link 已上线并开始投放。通过该属性提交的视频自 2026 年 6 月 30 日起具备投放资格，并附带政策和质量验证。错误只会屏蔽视频而不会影响商品本身，这意味着填写这个字段的风险很低。大多数商品目录中的大部分 SKU 都没有商品视频，正因如此，基于 Feed 数据大规模生成视频如今已成为一种竞争差距，而不再是锦上添花。
商品级配送控制得到扩展。handling_cutoff_time 设定每日订单处理截止时间，minimum_order_value 指定配送的最低消费金额。shipping 属性还新增了 loyalty_program_label 和 loyalty_tier_label 子属性，用于会员专属的配送权益。
发展方向是一致的：Google 不断将过去在账户层级设置的细节下放到商品层级。任何按商品表达的内容，Feed 层都可以自动化处理，而手动流程则无法做到。
6. 垂直领域地图
零售只是这张表中的一行，而不是整张表。
| 垂直领域 | Google 目标渠道 | Meta 商品目录类型 | 其他常见渠道 |
|---|---|---|---|
| 零售/电商 | Shopping 广告、免费商品信息 | 商品（电商） | 电商平台、比价引擎、联盟网络 |
| 实体店零售 | 本地库存广告 | 带本地库存状态的商品 | 本地搜索平台 |
| 汽车 | 车辆广告、车辆信息 | 车辆/车辆优惠 | 分类信息门户、汽车电商平台 |
| 酒店与住宿 | 酒店广告（Hotel Center） | 酒店 | OTA、元搜索 |
| 航班 | Google Flights | 航班 | 元搜索 |
| 目的地与套餐 | — | 目的地 | 旅游联盟 |
| 房产 | — | 房源信息 | 房产门户、房产聚合平台 |
| 招聘 | 职位结构化数据（JobPosting） | — | 招聘网站、ATS 分发、职位聚合平台 |
| 活动、赛事、放映场次 | 商品（建模） | 商品（建模） | 票务平台、DSP |
在构建任何东西之前，有两条结构性规则值得牢记：
一个 Meta 商品目录只能容纳一种库存类型。您不能把酒店和商品混在一起。如果两者都卖，就需要两个商品目录。
Google 在数据源层面区分垂直领域。车辆数据源只能用于车辆广告。将车辆提交到 Shopping 数据源只会导致拒登，而不会生成商品信息——而且车辆数据源不应包含零配件或配饰，这些应放在普通的商品 Feed 中。
7. 车辆 Feed
汽车是“直接套用零售规范”失败得最明显的垂直领域。一辆车是一个拥有合法标识符的独特实物，而不是一个有库存深度的 SKU。
Google 的车辆属性建立在通用核心字段之上：
| 属性 | 说明 |
|---|---|
vin | 车辆的合法身份标识。VIN 格式错误以及 VIN 与年份不符是最常见的拒登原因。 |
year、model、trim | 配置（trim）是让一条车辆信息区别于同一车型的竞争对手的关键。 |
body_style | 枚举值。 |
mileage | 数值加单位（miles 或 km）。必须与着陆页一致。超出该年款合理范围的数值会被标记。 |
condition | 新车、二手车、认证二手车。 |
certified_pre-owned | 单独的标记。 |
engine、fuel_consumption、energy_consumption、co2_emissions、emissions_standard | 在欧盟市场越来越重要。 |
electric_range、fuel_consumption_discharged_battery | 电动车和混合动力车专用。 |
date_first_registered | 首次登记的月份和年份。 |
vehicle_msrp、vehicle_price_type | 标价与优惠价。 |
vehicle_fulfillment | 车辆是在店内、可调配还是可送达。带有 store_code 子属性的组属性。 |
store_code | 车辆所在的实体门店。 |
<item>
<g:id>STK-88214</g:id>
<g:title>2023 Volkswagen Passat 1.5 TSI Business DSG</g:title>
<g:description>Single owner, full service history, no accident record.</g:description>
<g:link>https://example.com/ilan/88214</g:link>
<g:image_link>https://cdn.example.com/88214-01.jpg</g:image_link>
<g:price>1450000.00 TRY</g:price>
<g:condition>used</g:condition>
<g:brand>Volkswagen</g:brand>
<g:model>Passat</g:model>
<g:trim>1.5 TSI Business DSG</g:trim>
<g:year>2023</g:year>
<g:vin>WVWZZZ3CZPE000000</g:vin>
<g:mileage>
<g:value>42500</g:value>
<g:unit>km</g:unit>
</g:mileage>
<g:body_style>sedan</g:body_style>
<g:color>Grey</g:color>
<g:vehicle_fulfillment>
<g:option>in_store</g:option>
<g:store_code>IST-01</g:store_code>
</g:vehicle_fulfillment>
</item>车辆 Feed 在运营上的不同之处：
- 库存只有一件。每个条目都是单独的一辆车。一旦售出，就必须立即从 Feed 中移除——而不是等到明天的同步。过时的车辆信息会把高 CPC 的点击浪费在已经不存在的车上，并损害账户质量。
- 刷新频率决定一切。在汽车行业，四小时一次的刷新周期是标准做法，而不是一种优化。
- 着陆页一致性受到强制检查。Feed 中的价格和里程必须与车辆详情页完全一致。经销商范围内的价格调整如果只更新了网站而没有更新 Feed，几小时内就会引发一波拒登。
- Meta 的汽车库存广告使用一套单独的字段词汇——
state_of_vehicle、exterior_color、transmission、drivetrain、dealer_id——因此同一份源数据需要针对每个渠道进行不同的转换。
8. 旅游 Feed
旅游分为三种不同的商品目录类型，常见的错误是把它们当作一种。
酒店
酒店物业 Feed 相对静态：名称、描述、地址、坐标、星级、图片、起价。变化的是可订情况和房价，这就是为什么酒店设置通常会将静态的物业 Feed 与动态的房型和价格 Feed 搭配使用。
核心参数：hotel_id、name、description、brand、url、image、latitude、longitude、address（包括 city、region、country、postal_code）、base_price、currency、star_rating、neighborhood、phone、guest_ratings。
<item>
<g:hotel_id>HTL-BDR-114</g:hotel_id>
<g:name>Blue Bay Resort Bodrum</g:name>
<g:description>Seafront resort with private beach, three restaurants and a spa.</g:description>
<g:url>https://example.com/otel/blue-bay-bodrum</g:url>
<g:image>https://cdn.example.com/htl-114-01.jpg</g:image>
<g:latitude>37.0344</g:latitude>
<g:longitude>27.4305</g:longitude>
<g:address>Yalıkavak Mah. Sahil Cad. 12, Bodrum, Muğla, TR, 48990</g:address>
<g:base_price>4200.00 TRY</g:base_price>
<g:star_rating>5</g:star_rating>
<g:neighborhood>Yalıkavak</g:neighborhood>
</item>航班
条目是一条航线，而不是一个座位。其身份由出发地–目的地组合确定：以 IATA 代码表示的 origin_airport 和 destination_airport，加上 price、url、image、description。价格通常是“起价”，而且不断变化，这使得更新频率成为关键的约束条件。
目的地
条目是您销售旅游产品的目的地：destination_id、name、address、neighborhood、types、price、url、image。适用于漏斗上层的潜在客户开发，此时旅行者有出行意向，但心中还没有具体的住宿选择。
旅游领域反复出现的问题在于价格和可订情况是计算出来的，而不是存储的。酒店的“价格”取决于日期、入住人数和入住时长；航班的价格则取决于您询价的那一刻。而 Feed 需要的是一个单一数字。选择哪个数字——未来 30 天内的最低可订价、即将到来的周末的最低价、平均价——是一项悄然决定广告效果的商业决策，值得有意识地做出，而不是默认使用导出结果中的任意数字。
9. 房产 Feed
在结构上与车辆类似：独特的实物资产、只有一件的库存、每次点击的价值高，而且房源一旦被订走就必须立即消失。
核心参数：home_listing_id、name、description、address、latitude、longitude、url、image、price、currency、property_type（公寓、住宅、土地、商业）、listing_type（出售、出租、新建）、num_beds、num_baths、area_size、area_unit、year_built、availability、agent_name、agent_phone。
<item>
<g:home_listing_id>EMK-2291</g:home_listing_id>
<g:name>3+1 Apartment with Sea View — Kadıköy</g:name>
<g:description>Renovated 3+1 apartment, 4th floor, elevator, closed parking.</g:description>
<g:address>Caferağa Mah., Kadıköy, İstanbul, TR</g:address>
<g:latitude>40.9862</g:latitude>
<g:longitude>29.0299</g:longitude>
<g:url>https://example.com/ilan/2291</g:url>
<g:image>https://cdn.example.com/emk-2291-01.jpg</g:image>
<g:price>12500000.00 TRY</g:price>
<g:property_type>apartment</g:property_type>
<g:listing_type>for_sale</g:listing_type>
<g:num_beds>3</g:num_beds>
<g:num_baths>2</g:num_baths>
<g:area_size>135</g:area_size>
<g:area_unit>sq_m</g:area_unit>
<g:availability>available</g:availability>
</item>有一件事不是 Feed 问题，却会让您的广告系列停摆：住房在 Meta 上属于受限广告类别。推广房源信息的广告系列必须声明为住房特殊广告类别，这会限制定向选项。即使商品目录完美无缺，如果没有进行这项设置，广告系列仍然会失败。
10. 招聘 Feed
招聘使用完全不同的文档结构——<source> 和 <job>，而不是 <rss> 和 <item>——值得一看，因为它表明“XML Feed”是一种模式，而不是单一的架构。
<?xml version="1.0" encoding="UTF-8"?>
<source>
<publisher>Example Company</publisher>
<publisherurl>https://example.com</publisherurl>
<lastBuildDate>Wed, 12 Aug 2026 09:00:00 GMT</lastBuildDate>
<job>
<title><![CDATA[Senior Backend Engineer]]></title>
<date><![CDATA[Mon, 10 Aug 2026 08:00:00 GMT]]></date>
<referencenumber><![CDATA[ENG-4471]]></referencenumber>
<url><![CDATA[https://example.com/careers/eng-4471]]></url>
<company><![CDATA[Example Company]]></company>
<city><![CDATA[İstanbul]]></city>
<state><![CDATA[İstanbul]]></state>
<country><![CDATA[TR]]></country>
<postalcode><![CDATA[34394]]></postalcode>
<description><![CDATA[<p>We are hiring a senior backend engineer to work on our data pipeline...</p>]]></description>
<salary><![CDATA[120000 - 160000 TRY monthly]]></salary>
<jobtype><![CDATA[fulltime]]></jobtype>
<category><![CDATA[Engineering]]></category>
<experience><![CDATA[5+ years]]></experience>
</job>
</source>招聘 Feed 特有的四条规则：
CDATA是常态，而不是例外。职位描述中包含 HTML、& 符号和撇号。将每个字段包裹在<![CDATA[...]]>中，可以避免一整类解析失败。- 地点至少需要城市、州/省和国家。如果省略，该职位默认会在主要聚合平台上失去自然曝光。
- 已招满的职位必须删除，而不是标记为已关闭。没有与
availability对应的字段。是否存在于 Feed 中就是可用性信号，聚合平台会惩罚包含过时职位的 Feed。 - 一种语言，一个职位条目。以两种语言发布的职位需要两个独立的条目，并使用不同的参考编号。
除 Feed 之外，招聘页面上以 JSON-LD 形式提供的 JobPosting 结构化数据，才是让职位有资格出现在搜索结果的职位列表中的关键。两者相辅相成：Feed 负责向聚合平台分发，结构化数据负责自然搜索。大多数招聘团队只做了其中一项。
11. 有时效性的库存
最有意思的 Feed 类别并没有官方规范，因为平台从未预料到它的存在：其决定性属性是何时而不是何物的库存。
足球比赛。演唱会。电影放映场次。航班起飞。拍卖拍品。餐厅预订时段。配送时间窗口。
它们具备商品的所有属性——身份、价格、图片、着陆页——还多了一项零售规范中没有对应字段的属性：以小时计算的保质期。一场已经开球的比赛不是“缺货”，而是毫无意义。
行之有效的方法是将它们建模为标准的目录商品，并将时间维度编码到平台已经理解的字段中：
<item>
<g:id>MTC-2026-08-16-GS-FB</g:id>
<g:title>Galatasaray - Fenerbahçe | Super League, Week 2</g:title>
<g:description>Saturday 16 August, 19:00. Live odds and in-play betting.</g:description>
<g:link>https://example.com/mac/2026-08-16-gs-fb</g:link>
<g:image_link>https://cdn.example.com/creatives/mtc-2026-08-16-gs-fb.jpg</g:image_link>
<g:availability>in_stock</g:availability>
<g:price>1.00 TRY</g:price>
<g:product_type>Football > Super League > Week 2</g:product_type>
<g:custom_label_0>2026-08-16</g:custom_label_0>
<g:custom_label_1>derby</g:custom_label_1>
<g:custom_label_2>ms1-2.10</g:custom_label_2>
<g:expiration_date>2026-08-16T19:00+0300</g:expiration_date>
</item>有三点让这种方法奏效：
expiration_date或等效的移除规则，让条目在开球时离开商品目录，而不是等到下一次计划同步。- 承载时间维度的自定义标签，让广告系列可以围绕“本周末”“德比战”或“赔率高于 2.0”来构建。
- 每个条目一张创意。这通常是该方法停滞不前的地方。每周数百场比赛的赛程表需要数百张图片，每张都包含球队、日期、时间和当前赔率。没有哪个设计团队能产出这么多。根据 Feed 行生成创意是唯一能跟上节奏的方法——这正是 Bilyoner 首次投放目录广告 并将 ROAS 提升 49% 的方式。
如果您的库存有开始时间，它就应该放进商品目录。障碍几乎总是格式，而不是概念。
12. 本地库存 Feed
本地库存介于零售和垂直领域之间：同样的商品，按每个实体门店进行描述。
参数：id、store_code、quantity、price、sale_price、sale_price_effective_date、availability、pickup_method（购买、预订、配送到店、不支持）、pickup_sla（当天、次日、多日）。
结构上的要点是，本地 Feed 是一种补充，而不是替代。它通过 id 引用主商品 Feed 中的商品，并添加每个门店的具体信息。一件商品、多个门店、多行数据。
值得一提的 2026 年变化：同一商品的线上版本和店内版本如果价格或库存状态不同，现在需要使用不同的商品 ID，而不能合并为一个。曾经将其合并的 Feed 正被要求拆分。
13. 格式规则
这些规则适用于本文中的每种 Feed 类型，彻底失败的 Feed 绝大多数都与它们有关。
编码。始终使用 UTF-8，在 XML 声明中声明，并以匹配的 Content-Type 标头提供。声明的编码与实际编码不一致会破坏每一个非 ASCII 字符。
转义。在 XML 内容中必须转义五个字符：& → &、< → <、> → >、" → "、' → '。跟踪 URL 中未转义的 & 符号是 Feed 无法解析的头号原因。另一种选择是 CDATA，它在招聘 Feed 中是标准做法，在描述中包含标记的任何地方也都很有用。
日期。使用带有明确时区偏移的 ISO 8601 格式。写 2026-08-16T19:00+0300，而不是 16.08.2026 19:00。从一个不含时区的数据源为多个市场提供服务的 Feed，会产生提前或延后数小时过期的条目。
价格。数值加 ISO 4217 货币代码，使用小数点而非逗号，不使用千位分隔符。4299.00 TRY。而且 Feed 中的价格必须与着陆页一致——大多数平台会通过抓取来强制检查这一点。
枚举值区分大小写和格式，而且因平台而异。Google 期望 in_stock；Meta 期望 in stock。这一个差异导致的商品目录导入失败比其他任何问题都多。永远不要假设枚举值可以在不同目标渠道之间通用。
文件交付。大文件使用 Gzip 压缩，使用稳定的 HTTPS URL，除非平台明确支持，否则不要设置身份验证屏障，并且服务器要在平台的超时时间内响应。受 Cloudflare 机器人防护保护的 Feed URL，就是一个不会被抓取的 Feed URL。
更新频率应根据底层数据的波动性而定，而不是遵循惯例：赔率、机票价格和快速变动的零售库存需要每小时或更频繁地更新；车辆和房产每隔几小时更新一次；稳定的商品目录每天更新一次。
14. XML、CSV、JSON 与 API 对比
| 格式 | 最适合 | 注意事项 |
|---|---|---|
| XML | 嵌套和重复结构——按地区配送、多张图片、组属性 | 冗长；转义错误会导致整个文件失效 |
| CSV | 简单的扁平商品目录、快速手动编辑 | 标题和描述中的逗号；引号处理错误 |
| TSV | 同上，但更安全 | 几乎没有——制表符很少出现在商品数据中 |
| JSON | 现代 API、开发者构建的数据管道 | 并非所有目标渠道都接受 |
| API | 实时更新、超大型商品目录、部分更新 | 工程成本；速率限制 |
对于任何有嵌套结构的数据，XML 仍然是默认选择，这就是为什么车辆、旅游和配送信息繁多的零售 Feed 往往使用 XML，而简单的时尚商品目录常常使用 TSV。还要注意，一些主要的目标渠道正在转向以 API 为主的数据接收方式，因此把文件视为唯一的集成途径是一种中期风险。
如果您的标题中包含逗号——而包含颜色和尺码的标题几乎总是如此——请使用 TSV 而不是 CSV。一整类解析错误会随之消失。
15. 上线前检查清单
- [ ] 在接近任何平台之前，文件已通过 XML 验证器解析
- [ ] 已正确声明并提供
UTF-8；非 ASCII 字符正常显示 - [ ] 每个 URL 中的每个
&都已转义，或字段已包裹在CDATA中 - [ ] ID 唯一、在各次同步中保持稳定，并与您的像素或代码事件一致
- [ ] 目标渠道的所有必填属性都已提供——依据该渠道的规范而非通用规范进行核对
- [ ] 枚举值已按目标渠道进行转换，而不是直接复制
- [ ] 价格与着陆页完全一致，包括货币和任何税务处理
- [ ] 日期采用带时区偏移的 ISO 8601 格式
- [ ] 图片满足 500x500 的最低要求，且可通过 HTTPS 直接访问，无重定向
- [ ] 已售出、已招满、已过期或已出发的条目会按正确的时间表离开 Feed
- [ ] 更新频率与底层数据的实际变化速度相匹配
- [ ] Feed URL 可公开访问，且未被机器人防护阻止
- [ ] 已设置针对条目数量异常变化的监控规则
16. 常见问题
2026 年 XML 仍然是合适的格式吗？
对于任何包含嵌套数据的内容，是的。对于扁平的商品目录，TSV 更简单、更不容易出错。对于实时需求，API 集成胜过任何文件。格式应该由数据决定，而不是由习惯决定。
我可以为所有平台使用一个 Feed 吗？
一个数据源可以，一个文件不行。字段名称、枚举值、字符限制和必填属性因目标渠道而异，而且这些差异并非无关紧要。可行的架构是一个统一的规范商品目录，在导出时按渠道应用转换。
如果我的库存不是商品怎么办？
那么您需要的是所在垂直领域的规范，而不是零售规范。车辆、酒店、航班、目的地、房产和职位都有各自的规范。如果您的库存是任何平台都没有规范的东西——赛事、放映场次、时段、拍品——就将其建模为商品，并将缺失的维度编码到现有字段中。
Feed 应该多久更新一次？
底层数据发生实质性变化的频率有多高，就多久更新一次。一辆上午已经售出、下午仍在投放广告的车，是在把钱花在毫无意义的地方。
我需要 GTIN 吗？
对于零售来说，实际上需要。GTIN 将您的商品与平台的商品知识连接起来，而这越来越多地决定了您是否会出现在比价版面和 AI 驱动的购物结果中。对于车辆、房产和职位，对应的身份字段分别是 vin、房源 ID 和参考编号。
难点在哪里
本文中的每一条规则单独来看都不难。难点在于它们有数百条之多，因目标渠道而异，会在没有预警的情况下变化，而且违反它们时会静默失败。
将一个商品目录导出到 Google、Meta、TikTok 和三个电商平台，意味着要从同一个可信数据源同时满足六份不同的约定。手动完成这项工作，意味着要维护六个文件，并在每次商品目录变化时进行核对。
这正是 Feedance 所要承担的那一层——用 Feed 规则 在源头规范化属性，用 渠道导出 为 200 多个目标渠道分别应用正确的转换而不改动您的源数据，用 Feed Protection 在平台发现之前捕获缺失的属性和异常的条目数量变化，并用 Creative Suite 为每个 Feed 行生成图片或 视频，服务于那些手动制作从来就不现实的商品目录。
它将非零售垂直领域视为一等公民，而不是事后补充——带有实时价格的 旅游 库存、带有赛事时间数据的 博彩 商品目录，以及汽车、房产和招聘分发渠道。
如果您想在做出任何改动之前了解当前 Feed 的状况，我们的 免费 Feed 审核工具 可以免费从完整性、数据质量和技术健康度三个方面为其打分。或者 预约 15 分钟的演示，我们一起来看看。
最后审核：2026 年 8 月。平台规范经常变化；在实施之前，请对照各目标渠道的官方文档核实最新要求。
Feedance 联合创始人，凭借计算机工程师与营销人的双重背景推动数据分析洞察。他专注于将数据转化为可落地的策略，致力于帮助品牌在数字化领域实现显著增长。
LinkedIn