“最适合 Amazon 的网页抓取 API”这个问题没有单一答案,因为 Amazon 监控从来不是单一的工作。追踪五个市场上两千个 ASIN 的价格、审核自己的列表由谁占据 buy box、以及关注某个类目畅销榜的更替,这些都涉及 Amazon,但对 API 的要求各不相同。
因此,本指南不会给出一份供应商排名列表(这种列表不出一个季度就会过时,也说明不了你自己工作负载的情况),而是按类型对各选项进行分类,列出真正能区分优秀 Amazon API 与普通可用 API 的标准,并给出在正式采用前用你自己的 ASIN 测试候选方案的方法。
先排除不适用的选项
Amazon 自家的 API 是为使用自己账户的卖家和联盟会员设计的,有其自身的资格和使用条款。它们适合处理你自己的列表、订单和库存,但不适合监控整个目录中竞争对手的报价、价格或排名,而这正是本指南要解决的问题。
针对这项工作,有三类 API。
针对 Amazon 的三类 API
专用电商 API。 每个 Amazon 页面对应一个结构化端点:商品、搜索、畅销榜、促销、类目、卖家资料。你发送一个 ASIN 或查询,收到解析好的 JSON。无需选择器,无需维护解析器,当 Amazon 更改其标记结构时,由供应商吸收这一变化。
通用网页抓取 API。 你发送任意 URL,API 负责代理、渲染和重试,你收到的是根据你定义的提取规则生成的 HTML 或 JSON。更灵活,因为它适用于任何零售商和任何页面,但解析工作(包括标记结构变化时的维护)由你自己承担。
自行管理的代理。 你自己运行浏览器或 HTTP 客户端、解析器和重试逻辑,通过住宅代理路由。在超大规模下能获得最大控制权和最低单位成本,代价是最高的工程投入。相关方法在使用代理抓取 Amazon 商品数据一文中有介绍。
| 专用电商 API | 通用抓取 API | 自行管理的代理 | |
|---|---|---|---|
| 输出 | 按页面结构化 JSON | HTML,或通过你的规则生成 JSON | 由你自行构建 |
| 解析器维护 | 供应商 | 你 | 你 |
| 是否适用于 Amazon 以外 | 仅限支持的网站 | 任何网站 | 任何网站 |
| 工程投入 | 最低 | 中等 | 最高 |
| 最适合 | 大量 Amazon 数据,快速启动 | 混合零售商监控 | 超大规模、定制流程 |
大多数成熟的价格情报体系最终会同时使用不止一种:用专用 API 处理 Amazon,再用通用抓取 API 覆盖没有结构化端点的长尾零售商。
对 Amazon 真正重要的标准
功能列表看起来都大同小异。以下是决定数据是否可用的关键属性。
市场覆盖范围。 Amazon 是一系列各国站点的集合,同一个 ASIN 在不同站点有不同的价格、卖家和库存情况。要确认你所销售的每个市场都受支持,而不仅仅是美国。
页面覆盖范围。 价格情报通常需要的不只是商品页面:搜索排名、畅销榜变化、促销信息,以及用于识别竞争对手的卖家数据。列出你的工作流所需的页面类型,并逐一核实。
自然结果与推广结果的区分。 搜索结果混合了付费和自然排位。如果一个 API 将它们不加区分地返回在同一个列表中,会悄悄破坏任何排名分析。
设备一致性。 移动端和桌面端的结果排序可能不同。如果你的客户在移动端购物,你就需要移动端的结果。
输出稳定性。 结构化 API 只有在其 schema 保持稳定时才有价值。询问供应商如何通报破坏性变更,并在试用期间观察字段完整性,而不要仅凭一个样例响应做判断。
按成功计费。 为被拦截或失败的请求付费,会把一个不可靠的目标变成预算问题。优先选择只对成功响应计费的供应商,并弄清楚”成功”是如何定义的。
并发与数据新鲜度。 并发上限决定了你能多快刷新一份目录,进而决定了你的价格数据可以陈旧到什么程度。
每个 Amazon 数据管道都会遇到的一个细节
价格以市场自身格式的显示字符串形式返回,而货币符号本身并不能确定货币种类:$ 在 amazon.com、amazon.ca 和 amazon.com.au 上分别代表三种不同的货币。要结合符号和市场来解析 ISO 货币代码,并将原始字符串与解析出的金额一并存储。完整的加载方式见将网页抓取 API 数据导入 SQL。
buy box 是另一个需要注意的细节。哪个报价胜出可能取决于配送地址以及当时哪些卖家处于活跃状态,因此任何 API 返回的都是 buy box 的一个视图,而不是唯一的 buy box。要清楚你获取的是哪种视图,并在每次观测时记录市场和时间戳。
如何用你自己的数据评估候选方案
文档中的一个样例响应说明不了任何关于你目录的情况。要运行一次能真实反映实际工作的试用。
- 确定一个固定样本:选取你真实的几百个 ASIN,覆盖你关心的各个市场,并向最重要的产品倾斜。
- 按计划运行一周,采用你打算在生产环境中使用的频率。
- 按字段和市场分别测量字段完整性。如果某个价格字段在 8% 的德国商品上为空,这就是一个真实的发现。
- 抽样核实准确性,将返回价格的随机子集与同一时间的实时页面进行对比。
- 按市场分别记录成功率和延迟,而不是汇总记录,因为某个供应商可能在美国表现优秀,在其他地方却表现不佳。
- 计算每条可用记录的成本,即完整、准确、正确归属的记录,而不是每次请求的成本。
在同一周、以相同的频率,对每个候选方案运行同一个样本。在不同条件下测试供应商再进行比较,正是采购决策出错的常见原因,这也是我们在自己的基准测试中所遵循的原则。
Shifter 的定位
Shifter Amazon API 是一个专用电商 API。一个端点配合一个 type 参数,即可覆盖搜索、商品详情、畅销榜、今日促销、类目、卖家资料、卖家商品和卖家反馈,覆盖 19 个 Amazon 市场,支持桌面端或移动端结果,默认返回 JSON:
curl "https://ecom.shifter.io/v1?engine=amazon&api_key=YOUR_API_KEY&type=product&product_id=B08C1W5N87&domain=amazon.de"搜索响应将推广位置放在与自然结果分开的独立字段中,分页信息也会在响应中体现。Amazon 相关调用会占用 SERP API 套餐的配额,因此两者共用一个密钥池和一个套餐。端点和参数详见 Amazon API 文档,套餐信息见 SERP API 定价页面。
Shifter Web Scraping API 覆盖结构化端点未涉及的一切:其他零售商、品牌网站,以及任何你想自行提取的页面。它可按需渲染 JavaScript,通过提取规则返回 JSON,可为每次请求指定国家,支持分页流程的会话保持,自动重试失败的抓取,且仅对成功响应计费。详见 Web Scraping API 页面。
Shifter 住宅代理是自行管理的方案,适合希望完全掌控浏览器和解析器的团队。
将任务与工具相匹配
| 任务 | 最佳选择 |
|---|---|
| 针对固定 ASIN 列表跨市场追踪价格 | 专用 Amazon API |
| 搜索排名与货架份额监控 | 专用 Amazon API,区分推广与自然结果 |
| 跨 Amazon 和其他零售商的竞品定价 | Amazon API 加通用抓取 API |
| 针对自己列表的卖家识别 | 专用 API 的卖家端点 |
| 结构化端点未提供的定制流程 | 通用抓取 API 或自行管理的代理 |
| 拥有内部抓取工程能力的超大规模目录 | 自行管理的代理 |
下游应用场景详见构建实时竞品价格数据流、大规模执行 MAP 政策以及检测劫持你列表的第三方卖家。
常见问题
我可以使用 Amazon 自家的 API 来监控竞争对手的价格吗?
Amazon 的 API 是为使用自己账户的卖家和联盟会员按其自身条款设计的。若要监控更广泛的目录,团队通常使用专用电商 API、通用抓取 API 或代理。
专用 Amazon API 是否总是优于通用抓取 API?
对于它所支持的 Amazon 页面而言,通常集成更快、维护成本更低。当你还需要监控其他零售商,或需要结构化端点未覆盖的页面时,通用抓取 API 更有优势。
Amazon 价格应该多久刷新一次?
刷新频率应匹配你所在类目实际变化的速度,这一点可以在试用期间测量得出。许多团队会对优先监控清单每天刷新多次,对长尾商品则每天刷新一次。
采购 Amazon API 时最常见的错误是什么?
依据一个样例响应而非用你自己的 ASIN、在你自己的市场上、持续一周进行评估。美国以外市场的字段完整性,正是大多数方案差异最大的地方。
结论
不存在唯一”最佳”的 Amazon 网页抓取 API,只有最适合特定任务的方案。专用电商 API 是跨市场获取结构化 Amazon 数据的最快途径。通用抓取 API 能将同一套流程扩展到其他所有零售商。自行管理的代理则适合超大规模、高度定制的操作。
按市场和页面覆盖范围、自然结果与推广结果的区分、输出稳定性以及仅按成功计费来做选择,然后用你自己的 ASIN 试用一周来验证这个选择,再正式采用。更广泛的应用场景见价格情报页面。