商品比价工具：功能亮点、使用场景与 API 依赖

商品详情页只能告诉你一家店的价格。判断折扣是不是真的、供应商报价是否合理、自己的售价处在什么位置时，真正有用的问题是：这件商品此刻在整个市场里卖多少钱？

SandBase 商品比价工具把这个问题压缩成两个输入：商品名称或型号，以及目标市场。工具读取 Google Shopping 的实时商家报价，适合消费者、电商运营、采购、选品和市场研究人员快速了解当前价格区间，不必先打开十几个店铺标签页。

先说结论

输入商品名称或精确型号，即可查询 Google Shopping 实时商家报价。

当前支持美国、英国、加拿大、澳大利亚、德国和法国六个市场。

每次运行消耗 1 次电商 API 调用，由用户的 SandBase 账户计费。

底层依赖是 google-shopping/search，可通过 SandBase Platform API 单独调用。

它适合做价格研究，不会自动证明两个相似标题一定是同一 SKU，也不能代替结账前的税费、运费与库存确认。

SandBase 商品比价工具，右侧包含商品查询框和市场选择器工具只要求商品名称或型号与目标市场。页面明确说明：一次运行使用 1 次实时电商 API 调用，并计入用户的 SandBase 账户。截图时间：2026 年 10 月 31 日。

这个商品比价工具做什么

界面只保留了两个决策：查什么、查哪里。你可以输入宽泛的商品名，但精确型号通常更可靠。“Sony 耳机”会混入不同代际和形态；“Sony WH-1000XM6”更接近一个可比较的商品身份。

市场选择器覆盖美国、英国、加拿大、澳大利亚、德国和法国。这个筛选并非装饰：不同国家的商家覆盖、币种、配送、促销和库存都不同。即使商品名完全一致，也不应拿美国结果直接代表德国市场。

提交后，工具向 Google Shopping 搜索依赖发送一次请求。页面给出的定位是：跨商家比较实时 offer、识别促销价格、理解当前价格范围。底层 API 在上游结果提供相应信息时，可读取商品标题、现价、原价、店铺、评分、评论数、配送信息和商品 ID。

它最有价值的地方不是“又多了一个搜索框”，而是把视角从单条 listing 拉回市场。一家店的异常低价不再等于“市场价”，而是一个需要继续核验的样本。

功能亮点

两个字段，先解决是否值得继续查

无需配置爬虫、整理表格或逐店搜索。输入查询词、选择国家、运行即可。对早期判断很实用：眼前这个价格是否大致合理？这个折扣是否值得继续研究？

简单也意味着边界。没有写进查询词的容量、颜色、套装、成色、地区版本、保修和年份，工具无法替你补全。变体很多的商品，应该把决定 SKU 的属性写清楚。

实时商家报价，不是静态参考价

页面把数据源标成 Google Shopping live data。面对促销、缺货或价格快速变化时，它比人工维护的“常见价格表”更有参考价值。

但 live 不等于永久、完整或结账价保证。商家可能在查询后改价、下架或调整配送。正确理解是：这是请求发出时，上游电商页面的一次快照。

六个国家市场分开查

跨国家混合结果很容易制造假结论。六国选择器给查询加上明确边界，适合分别回答“美国当前报价区间是什么”“法国是否存在明显溢价”等问题。

跨国比较时仍要统一币种，并把税费、配送和进口成本算进去。标价低，不等于落地成本低。

同时看到促销与商家上下文

Google Shopping 依赖说明中包含现价、原价、店铺、评分、评论与配送等字段（以实际返回为准）。这些信息能帮助你判断所谓折扣是否有上下文，也能看出最低价来自哪类商家。

评分和评论数只是辅助信号，不是商家风险结论。真假货、保修、退货政策与支付保障仍需在商家页面核实。

用户场景：它在哪些决策里有用

消费者验证大促价格

大促下单前，用精确型号和购买国家跑一次。如果某店宣称“历史低价”，但多数实时 offer 都在相近水平，这个折扣可能没有海报写得那么稀缺。

高价商品最好记录查询时间，再打开候选商家页面确认库存和最终价。比价是核验的起点，不是付款环节。

电商运营检查价格位置

商家可以用固定查询词观察自己的公开售价处在可见价格带的下方、中间还是上方。适合用在活动前、平台 listing 调整后，或转化率突然变化时。

它不是自动调价器。真实定价还要考虑毛利、库存、投放成本、平台费用和品牌定位。盲目追最低价，可能是在跟不同套装、翻新品或不可靠商家竞争。

采购与供应链做报价合理性检查

采购人员可以把供应商报价与公开零售 offer 放在一起看。所谓“批发价”如果已经接近普通零售价，就值得继续追问。想直接看批发端报价，可以参考 1688 Product Finder 使用指南，对比 1688 上的供货价和起订量。六国市场也能暴露同一商品在不同区域的价差。

公开零售搜索看不到 MOQ、交期、Incoterms、税务、真伪与售后条件，因此只能做 reasonableness check，不能替代完整的落地成本模型。

市场研究追踪促销

研究人员可以在固定时间重复相同查询，并把观察结果保存到自己的系统。要让趋势可解释，商品身份、国家、查询词和采集频率应保持一致，否则查询口径变化会被误判为价格变化。

如果要长期跟踪大量商品，直接调用 API 更合适：输入、时间戳、筛选规则都能审计，也便于增加变体匹配与告警逻辑。

开发者搭建电商 Agent

Lab 工具展示了一个最小可用流程：查询词、市场、一次 API 调用、可用于决策的报价结果。开发者可以沿用同一依赖，再加商品标准化、汇率换算、阈值、数据库或通知。

如果目标是同时匹配 Google、Amazon 和 TikTok Shop，而不是查看 Google Shopping 快照，可以继续读跨平台比价 Agent 教程。前者强调快速交互式检查，后者解决更麻烦的跨来源商品身份匹配。

工具背后的 API 依赖

工具依赖 SandBase Google Shopping API 目录中的唯一端点：google-shopping/search。目录将其描述为按关键词搜索商品标题、现价、原价、店铺、评分、评论、配送和商品 ID，并支持价格、排序与位置筛选。

SandBase Google Shopping API 目录，展示唯一的搜索端点 Google Shopping 目录列出一个已验证的搜索端点及其生产路由。价格属于时效信息，批量使用前应查看实时页面。截图时间：2026 年 10 月 31 日。

直接实现页面是 Google Shopping Search，文档化的生产路由为：

POST https://api.sandbase.ai/v1/api/google-shopping/search

认证方式为 SandBase Bearer API key。页面列出 1 个必填参数 q，以及国家 gl、语言 hl、设备、仅促销、价格排序、最低/最高价、免邮、Google 域名、小商家等可选控制项。

端点页确认了在线 POST 路由、Async JSON、1 个必填参数和 15 个可选参数。截图时规格卡显示每次 $0.01，而目录与 Run 按钮显示 $0.015；应以实际调用时的实时计费值为准。截图时间：2026 年 10 月 31 日。

这个可见的价格差异，正好说明文章不应把某个数字写成永久承诺。同一页面区域出现 $0.01 / call，目录与 Run 控件则显示 $0.015。本文保留观察结果，不替系统选择一个“正确价格”；预算前请在当前账户流程中确认。

API 调用方式

平台数据 API 使用 POST /v1/api/<model>，不要套用图片/视频模型的 /v1/run。最小请求如下：

curl --fail-with-body --silent \
  -X POST "https://api.sandbase.ai/v1/api/google-shopping/search" \
  -H "Authorization: Bearer $SANDBASE_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"q":"Sony WH-1000XM6","gl":"us","hl":"en"}'

完成态响应的业务数据位于 outputs[0].data。生产代码在状态异常或 output 缺失时应明确报错：

import os
import requests

response = requests.post(
    "https://api.sandbase.ai/v1/api/google-shopping/search",
    headers={"Authorization": f"Bearer {os.environ['SANDBASE_API_KEY']}"},
    json={"q": "Sony WH-1000XM6", "gl": "us", "hl": "en"},
    timeout=90,
)
response.raise_for_status()
body = response.json()
outputs = body.get("outputs") or []
if body.get("status") != "completed" or not outputs:
    raise RuntimeError(
        f"SandBase call did not complete: {body.get('status')} {body.get('error')}"
    )
data = outputs[0].get("data") or {}

响应信封路径是文档化契约；Google Shopping 内层业务字段仍应防御式读取，因为上游结构可能演进。本文没有执行付费商品查询，因此不声称某种固定内层结构或结果数量。

怎样查得更准

优先输入厂商与精确型号。
补上容量、尺寸、代际或套装等决定 SKU 的属性。
选择实际购买发生的国家市场。
比较店铺和配送上下文，不只看数字。
把异常低价当成待核查记录，而不是自动赢家。
最终回到商家页面确认库存、税费、配送、成色、保修和退货。
如果结果影响业务决策，保存查询词与时间戳。

比价最常见的错误通常不是算错，而是把不同商品当成同一件。翻新品、跨区版、仅配件、旧一代或不同套装，都可能被宽泛文本查询混在一起。

必须知道的限制

Google Shopping 不等于整个市场。 某些商家和区域门店不会出现。
相似标题不保证同一变体。 宽泛查询无法保证 SKU 等价。
标价不一定是落地价。 税、运费、关税、会员、优惠券和结账变化都会影响总价。
实时数据有时效。 结果是运行时观察，不是长期报价。
评分只是上下文。 不能直接证明商家可靠或商品为正品。
工具会消耗账户调用。 批量自动化前应确认当前价格与免费调用政策。

这些限制不是让人放弃工具，而是界定它的职责：先快速定位市场和异常点，再做深度核验。

常见问题

搜索框里应该填什么？

尽量使用品牌与精确型号。尺寸、容量、颜色、代际或套装会改变商品时，也应一并写入。

当前支持哪些国家？

截至 2026 年 10 月 31 日，页面选择器显示美国、英国、加拿大、澳大利亚、德国和法国。

工具会直接搜索多个电商平台吗？

当前页面明确标注数据源为 Google Shopping merchant offers。Google Shopping 会聚合多家商店的 offer，但这不等于逐一调用每家零售商自己的 API。

对应的 API 是哪一个？

依赖是 google-shopping/search，通过 SandBase Platform API 的 POST /v1/api/google-shopping/search 调用。

最低价一定是最佳购买选项吗？

不一定。还要核对变体、成色、商家、配送、税费、保修、退货和结账总价。极低报价首先是一个核查信号，而不是自动购买建议。

结语

商品比价工具最适合回答一个边界清晰的问题：这件商品在这个国家的 Google Shopping 实时报价，大致落在哪个范围？ 两字段流程省掉准备工作，国家筛选避免明显的跨市场混淆，直接 API 又给开发者留下了自动化空间。

用它验证大促、检查售价位置、质疑供应商报价或启动选品研究都很合适。但不要跳过 SKU 匹配和结账核验。真正有价值的结论不是“最低价赢了”，而是你终于看清了此刻市场的大致位置。