文件上传集成
ACP的Product Feed文件上传采用SFTP推送模式(push-based)。商家主动将商品数据文件推送到OpenAI指定的SFTP服务器,而非由OpenAI来拉取。3.1 SFTP推送模式
3.2 支持的文件格式
| 格式 | 压缩 | 推荐度 | 说明 |
|---|---|---|---|
| Parquet | zstd | 推荐 | 列式存储,压缩效率最高 |
| jsonl.gz | gzip | 可选 | JSON Lines格式,每行一条记录 |
| csv.gz | gzip | 可选 | 逗号分隔,需UTF-8编码 |
| tsv.gz | gzip | 可选 | Tab分隔,需UTF-8编码 |
- 列式存储天然支持高效的字段级读取
- zstd压缩比高于gzip,解压速度更快
- 内置schema信息,减少类型歧义
3.3 快照类型:全量覆盖
ACP文件上传采用**全量快照(Full Catalog)**模式,而非增量模式(delta)。 每次上传的文件代表商品目录的完整真实状态(complete source of truth)。这意味着:- 上传文件包含所有在售商品的完整信息
- 每次上传会完全覆盖上一次的数据
- 不需要标记”新增”、“修改”、“删除”等操作类型
- 如果某个商品不在最新快照中,它会被视为已下架
3.4 分片策略
大型商品目录需要分片上传。分片规则:| 参数 | 建议值 |
|---|---|
| 每个分片最大商品数 | 500,000条 |
| 单个文件目标大小 | 500MB以下 |
3.5 上传频率
| 策略 | 频率 | 用途 |
|---|---|---|
| SFTP全量快照 | 至少每天一次 | 商品目录基线同步 |
| REST API增量 | 全天实时 | 价格、库存、促销等变化 |
- 全量快照提供数据一致性的基线
- API增量更新保证数据时效性
- 即使API出现短暂问题,全量快照也能在次日修正
3.6 文件命名规则
使用稳定一致的文件名。每次上传同名文件会覆盖上次的内容。3.7 商品下架处理
在全量快照模式下,有两种方式下架商品: 方式1: 从快照中省略 最简单的方式。下次上传的快照中不包含该商品,它就自然消失。 方式2: 设置is_eligible_search 为 false
在快照中保留商品记录,但将 is_eligible_search 字段设为 false。商品数据仍然存在,但不会在ChatGPT的商品发现中出现。
3.8 Feed Header
每个上传文件必须包含Feed Header信息,标识数据来源和目标:| 字段 | 类型 | 说明 |
|---|---|---|
feed_id | string | 数据源唯一标识 |
account_id | string | 商家账户ID |
target_merchant | string | 目标商家标识 |
target_country | string | 目标国家(ISO 3166-1 alpha-2) |
3.9 最佳实践清单
| 实践 | 说明 |
|---|---|
| 使用Parquet + zstd | 压缩效率最高,解析最快 |
| 保持UTF-8编码 | 避免字符集问题 |
| 每日全量 + API增量 | 双通道确保数据新鲜度 |
| 固定文件名覆盖 | 不要追加带时间戳的文件 |
| 单分片不超过50万条 | 保持处理效率 |
| 单文件不超过500MB | 避免上传超时 |
| 完整商品在同一分片 | Product和Variant不跨文件 |
| 监控上传状态 | 确认SFTP传输成功完成 |
下一章: 第4章:REST API集成 — Product Feed REST API完整参考