一、先回答那个问题：到底哪家最好？

直接说答案没有意义，因为提问者嘴上问的是同一个问题，心里想的是三件完全不同的事。

第一类人只要自家的经营数据——订单、库存、自家 listing 表现、自家广告数据。这类需求没有第二个选择，官方 SP-API 是唯一合规来源，任何第三方都给不了你，说能给的要警惕。

第二类人要的是市场数据——竞品价格、搜索排名、评论、广告位。这类需求里各家差异巨大，但差异不在「有没有该功能」上，而在「返回的字段全不全、取不取得到值」上。

第三类人要的是历史与趋势——做模型训练、做回溯分析。这类需求本质上是买数据集，不是买接口，评估逻辑又不一样。

这三类需求的最优解往往不是同一个供应商，甚至不是同一类产品。所以「哪家最好」的正确回应是一个反问：你的字段契约是什么？

字段契约是你自己写的一张清单，列出业务真正依赖的字段。有了它，「哪家最好」就变成了一个可计算的问题：在同样的一批 ASIN 上，谁能以最低成本返回满足契约的记录。这个转化是本文全部内容的核心，后面所有方法都围绕它展开。

二、为什么「最佳 API」榜单几乎都是无效的

先说清楚这类内容为什么普遍不可信。不是道德问题，是结构问题——写榜单的人拿不到他需要的数据，于是只能退而求其次用能拿到的替代指标。

缺陷一：「支持」这个词是个信息黑洞

看任何一张对比表，「产品数据」那一列通常都是一排对勾。但对勾底下藏着什么？

我们拿同一个 ASIN 举例，两家都宣称支持产品数据。一家返回 12 个字段：ASIN、标题、主图、当前价、评分、评论数、类目排名、品牌、可用性、配送方式、卖家名、上架时间。另一家返回 58 个字段，除了上面这些，还包括历史价格区间、Coupon 金额与类型、Subscribe & Save 折扣、变体列表与每个变体的价格库存、BSR 多类目细分排名、A+ 内容标记、气候承诺标记、广告位标记与自然位次、促销标签、配送时效预估、卖家评分与履约方式。

在功能表上，这两家是同一个对勾。在你的报表里，这两家是能做和不能做的区别。

更麻烦的是，字段数量还不是全部。字段存在不等于字段有值。有些返回里 58 个字段全在，但其中 20 个常年是 null——字段契约上有，实际交付时取不到。这种情况比字段干脆不存在更难发现，因为 schema 校验通过了。

缺陷二：排序依据与真实成本几乎无关

榜单爱按起售价排。但亚马逊数据服务的计费口径有四种，彼此不可直接比较：

同一个任务，按请求计费的 A 家报价看起来只有按记录计费的 B 家的三分之一，但因为 A 家深页可用性差、需要多次重试，且失败请求照样计费，跑下来实际支出反而更高。这类反转在真实选型里很常见，而起售价对比永远看不到它。

唯一可比的口径是每千条可用记录成本：一段时间内总支出，除以同期进入下游且通过字段契约校验的记录数，再乘一千。这个数字需要你自己跑一趟才拿得到，任何榜单都不会给你。

缺陷三：写榜单的人自己就在名单里

这一点不用多说。数据采集这个品类里，几乎每家都发过自己的「Best Amazon Scraper API」。这类文章的价值不在于结论，而在于它无意中透露的自家能力边界——你可以从它没写什么里读出很多信息。比如一家从不提变体级数据的供应商，大概率在这块不行。

所以别再找榜单了。找一张清单不难，难的是判断清单上的每一家在你关心的字段上到底交付了什么。这件事只能自己测，好在它并不复杂——下一节开始给你方法。

三、先分类，再比较：四种供应商的结构边界

在比较任何两家之前，有个更前置的步骤：确认它们在同一个类别里。亚马逊数据服务商不是在同一条赛道上排名次，而是分布在四个结构不同的类别里，各自的失效条件是硬性的，跟供应商努力程度无关。

分类依据两条轴：数据授权来源（自家授权 vs 公开可见）与 schema 结构化程度（原始页面你自己解析 vs 结构化字段直接可用）。

类别一：官方渠道 API

以 SP-API 与 Advertising API 为代表。合法性来自你与平台之间的显式协议：开发者注册、卖家通过 Login with Amazon 授权、应用按角色拿到最小必要权限。涉及个人身份信息的字段需要单独申请受限角色并过审。

它必然能做好的：账户域的一切。订单、库存、履约、自家 listing、自家广告表现、买家消息（受限）。这些数据的准确性没有对手，因为源头就是平台自己。

它的硬性边界：授权范围严格绑定在卖家主动授权的账户上。你拿不到任何其他卖家的订单，拿不到市场级的搜索排名，拿不到竞品的价格历史。这不是「暂不支持」，是设计上就不提供。另外限流是按操作独立配的令牌桶，不同操作的配额不一样，实际吞吐规划要逐个操作算，不能按一个总 QPS 拍脑袋。

这条边界的底层原因——SP-API 的授权模型绑的是卖家账户而不是市场，所以竞品数据从头就不在授权范围内——我们单独拆过一次，见官方 API 为什么拿不到竞品数据。选型时把它当永久约束处理，比等一个永远不会来的更新划算得多。

类别二：通用网页采集 API

提供代理池、反爬对抗、JS 渲染，把页面抓回来给你，解析是你自己的事。这类产品的定位是基础设施，不是数据产品。

它必然能做好的：覆盖广度。只要是公开可见的页面，理论上都能拿到，不受供应商的 schema 设计限制。需要某个冷门字段时，只要页面上印着，你就能自己抠出来。

它的硬性边界：解析责任完全在你。页面改版意味着你的解析器失效，而且失效是静默的——解析器抛异常你还能报警，解析器返回了一堆 null 你未必发现。团队里得长期留人维护选择器，这笔人力成本几乎从不被计入选型预算，但它通常比 API 订阅费高一个数量级。反爬对抗也是持续的军备竞赛，你买的是当下的可用性，不保证下个季度。

类别三：垂直亚马逊数据 API

专门做亚马逊数据，返回结构化 schema，字段有明确定义。这是本文讨论的重点，也是「best Amazon data API」这个搜索词下绝大多数人真正要找的东西。

它必然能做好的：开箱即用。字段有名字、有类型、有文档，改版由供应商兜底，你不用养解析团队。接入成本从周级降到小时级。

它的硬性边界：你只能拿供应商设计好的那些字段。schema 之外的需求无解，只能提工单等排期。而且各家 schema 设计差异极大且没有公开基准——这一点是本文第三节之后要解决的核心问题。

类别四：离线数据集与批量交付

按类目或按市场交付历史数据快照，用于训练模型、做回溯分析、建基准线。

它必然能做好的：时间深度。三年价格曲线、历史评论全量，这些实时接口给不了（或者给得起但贵到不划算）。

它的硬性边界：时间衰减。快照交付那一刻就开始过期，且它无法回答「现在怎么样」。追热点、做实时监控、做动态定价，都不能只靠数据集。

分类的意义在于：跨类别比较是浪费时间。拿官方 SP-API 和垂直数据 API 比「谁更好」没有意义——一个给账户数据一个给市场数据，重叠接近于零。真正需要横向比较的是类别三内部的各家，而类别三恰恰是最缺公开基准的一类。

四、四类方案各自的真实痛点

上一节讲的是结构边界，这一节讲具体会踩的坑。这些都是生产环境里反复出现的，不是理论风险。

官方渠道：审批与配额的工程外成本

最大的痛点不在技术，在流程。SP-API 的应用审核、受限角色申请、卖家授权链路，一套走下来周期不短。对于只需要市场数据的团队，这套流程的性价比很低。

第二个痛点是配额规划复杂。限流是按操作独立配的令牌桶模型——不同 operation 有各自的 rate 与 quota，恢复速率也不一样。这意味着「我们每秒多少请求」这种粗放规划行不通，你得按操作类型分别算配额、分别做退避。很多团队在规模上量之后才第一次认真读限流文档，那时已经踩过一轮 429 了。

第三个是 PII 约束。涉及买家个人信息的字段需要受限角色，且审批标准严格。这直接决定了你能不能做买家维度的分析，很多业务设想在这一步就得砍掉。

通用采集 API：解析责任的隐性转移

买这类产品时，你买的不是数据，是「把页面拿回来的能力」。数据质量的责任从头到尾在你身上。三个后果：

• 改版即事故。亚马逊的页面结构变化频率远高于多数人的预期。选择器失效后，如果你的代码用 try-catch 兜住了异常，你会得到一堆结构完整的空记录，而不是报错。
• 字段漂移无人负责。同一个字段在不同类目、不同站点、不同页面模板下的位置不一样。你不可能穷举所有模板，只能接受一个不断衰减的填充率。
• 成本结构里有一大块是人力。一个中等规模的采集项目，维护解析器的工程师投入通常在 0.5 到 1 个人力。这一项几乎从不出现在选型的成本表上。

不是说这条路不能走。团队里有专职做这个、且需求确实超出任何现成 schema 时，自建是合理的。但把它当成「便宜的替代方案」来做成本对比，基本都会算错。

垂直数据 API：没有基准，所以只能信文案

这是本文最想解决的一类问题。垂直 API 之间差异巨大，但这种差异没有公开的、可对照的度量。结果就是：选型只能看官网文案，而所有官网文案都说自己全面、稳定、覆盖广。

具体表现为四种信息不对称：

其一，字段清单不公开到字段级。多数供应商给的是「我们提供商品数据、评论数据、搜索数据」这种对象级描述，不到字段级。你在签约前拿不到完整字段字典。

其二，填充率从不披露。覆盖率（schema 里有没有这个字段）和填充率（实际返回时这个字段有没有值）是两件事，但后者几乎无人披露。

其三，失败定义不统一。「成功率 99%」这句话在一家指 HTTP 200 的比例，在另一家指通过内部完整性校验的比例。两者可以差十几个百分点。

其四，深页与长尾的可用性不明。前两页大家都行，第 3 页往后差距极大，但这部分数据恰恰是竞争度判断的关键。

离线数据集：无法回答当下

时间衰减是主要问题，但还有个更少被提及的：数据集的字段往往与实时接口不一致。你在历史数据上训练的模型，接实时接口时发现字段对不上、口径对不上，特征工程要重做一遍。买之前一定要确认历史与实时是同一套 schema。

五、行业至今没有被解决的问题

上一节讲的是各方案的已知痛点。这一节讲的是更少被承认的部分——不是某个供应商做不好，而是整个行业目前普遍做不到、或者做到了也不说的事。这些空白决定了你能把项目做到什么程度。

空白一：字段完整度没有公开基准

这是最根本的一条。所有垂直数据供应商都说自己覆盖全面，但没有一家公开过「在我们的字段契约下，我们的可用记录率是多少」。没有基准，横向比较就只能停在对象级——而对象级比较已经被证明没有区分度（还记得那个 12 字段对 58 字段的例子吗）。

这个空白短期不会自己消失，因为公开字段级数据对供应商是有风险的——一旦披露，短板就暴露了。所以作为买方，你只能自己建基准。这正是第六节那套框架存在的理由。

空白二：深页搜索数据几乎无人稳定提供

搜索结果的前两页，各家都能给。第 3 页往后，可用性断崖式下跌。这个空白的后果比听起来严重：

竞争度判断依赖深页。一个关键词前三页全是强敌，和前三页全是弱旅，是完全不同的决策。只看到前两页，你会系统性地低估竞争强度——因为真正的威胁可能排在第 5 页但在快速增长，而你看不见。

更微妙的是，深页可用性本身就是一个结论。当你只能看到两页的时候，「这个市场竞争不激烈」这个判断其实是在描述你的观测能力，而不是描述市场。

空白三：广告位与自然位长期被混为一谈

绝大多数返回里没有 isSponsored 这类字段。于是你的排名监测里，广告位和自然位被放进同一个序列里排了序。

后果是排名这个指标系统性失真。举例：某团队监测到自家核心词的排名稳定在第 3 位，连续三个月没有变化，据此判断自然排名健康。补上广告位标记后才发现，真实情况是自然位第 1，但前面插了两个竞品的 Sponsored Brands 广告——自然表现其实在变好，可这个信号被广告位稀释掉了，团队还以为自己原地踏步。

反向的例子更常见：某个词监测到「排名很好」，实际是第 4 页，前三页铺满了竞品的 Sponsored Products，自然流量接近于零。

没有广告位字段，你连「我的排名是多少」这个最基础的问题都回答不准。

空白四：变体级归属缺失

评论、价格、库存，到底挂在父 ASIN 上还是子 ASIN 上？多数返回不做区分，或者只给一个聚合值。

这个缺失会让洞察不可执行。典型场景：评论分析跑出一条高置信结论「用户普遍抱怨续航不足」。这条洞察没法直接用——是产品的哪个规格续航不足？黑色版和白色版的续航抱怨比例一样吗？某个容量规格是不是问题集中点？不知道归属，应对方案只能是对整个产品线动手，成本高、见效慢。补上变体归属后定位到具体规格，应对成本能降一个数量级。

空白五：跨站点字段对齐被严重低估

同一个字段，在 US 站取得到，在 DE 站未必；在 JP 站的口径可能与 US 站不一致。供应商很少按站点披露字段可用性，通常只给一个笼统的「支持 20+ 站点」。

多站点运营的团队最容易在这里摔跤：国内测试一切正常，铺到欧洲站发现报表里少了一半维度，回头找供应商才知道某些字段在非美站点不提供。而这时架构已经按全字段设计好了。

空白六：静默失败无人度量

这是最贵的一条，因为它不产生告警。HTTP 200、结构完整、字段齐全，但关键字段是 null。你的监控看状态码，一片绿；你的报表看行数，一条不少；只有业务侧觉得「这个数最近不太对」，但说不清哪里不对。

静默失败的成本不体现在 API 账单上，体现在基于错误数据做出的决策上。这类损失没有上限，也没有账单可查。

空白七：字段变更没有通知机制

这一条几乎没人提，但它造成的返工量可能比前面几条加起来还多。亚马逊的页面在持续变化，供应商的 schema 必须跟着改——字段改名、类型从字符串改成对象、枚举值新增一种、某个字段被合并进另一个。

问题在于这类变更对下游是静默发生的。你的解析器不会报错，因为大部分字段还在；你的校验不会失败，除非你显式校验了那一个字段。等到报表里某个维度突然少了三个月数据，回头一查，才发现字段在两个月前就改名了。

行业里目前没有成熟解法。能做的只有三件事，都不完美，但都能显著降低损失：其一，在接入层对每个字段路径做存在性与类型的强校验，类型一变立刻抛错，而不是静默降级；其二，把供应商的变更日志（如果有的话）订阅进告警通道，没有日志就定期 diff 一份样本响应；其三，签约时把「字段变更提前通知」写进条款——哪怕对方只承诺尽力而为，有条款和没条款在出事时是两个结果。

还有一个实操建议值得单独说：给每个数据对象保存一份历史样本快照。不需要全量，每个对象存几十条有代表性的响应，按周归档。schema 出问题的时候，这份快照是你能做归因分析的唯一依据。

七个空白的共同点：它们都不出现在功能表里，也不出现在定价页上。发现它们的唯一方式是自己跑一遍度量。接下来给方法。

六、替代方案：一套可复现的盲测框架

这一节是全文最有用的部分。它不依赖任何供应商的自述，也不需要你去求人要字段字典——你只需要两天时间，就能把候选名单从「一堆都说自己全面的官网」变成「一张按你的业务排过序的表」。

核心思路一句话：先写你要什么，再看谁给得出。顺序不能反。大多数人是从供应商文档倒推需求，结果就是被文档牵着走，最后买回来一堆用不上的字段，真正需要的那个反而没有。

第一步：写字段契约，而不是读供应商文档

字段契约是你自己的需求清单，按数据对象分组，每个字段标注优先级。P0 是缺了这条记录就不能用，P1 是缺了会影响分析深度但不致命，P2 是锦上添花。

下面是一份产品对象的契约模板，可以直接拿去改。它覆盖了我们在实际项目里见过的高频需求，你可以按自己的业务增删。

完整的字段字典与类型定义另文给出。搜索对象和评论对象同样需要各写一份。搜索的关键字段是 page、items[].position（页面绝对位次）、items[].isSponsored、items[].adType、items[].organicRank——没有后三者，你的排名监测就是在把广告和自然结果混着排序。评论的关键字段是 reviewId、asin（子体）、parentAsin、variant（规格描述）、rating、title、body、date、verifiedPurchase、helpfulCount——variant 这一项决定了你的评论洞察能不能落到具体规格上。

第二步：设计样本集，别只用爆款 ASIN

样本集的设计直接决定结论的可信度。最常见的错误是拿十几个爆款 ASIN 去测——这类商品数据最全，测出来大家都是满分。

一份有区分度的样本集应当包含五类：

• 跨类目：至少 4 个一级类目。不同类目的页面模板差异很大，字段可用性也跟着变。
• 跨站点：至少 US 加两个非美站点。这一步专门用来测第五节提到的「空白五」。
• 含多变体：挑变体数 20 以上的商品，测变体级字段的深度。
• 含弱数据商品：新品无评论、长期缺货、无 Buy Box 的商品。这些是填充率的试金石。
• 含深页：搜索场景一定要测到第 5 页，不能只测前两页。

规模上，每家 200 到 500 条记录足够得出稳定结论。太少噪声大，太多浪费预算。

第三步：同口径执行

四条纪律，破坏了任何一条，数据就不可比：

同一批 ASIN、同一时间窗（尽量压缩在几小时内，避免价格与库存自然波动）、同一并发水平、同一重试策略。最后一条最容易被忽略——如果给 A 家配了三次重试而 B 家只跑一次，A 的可用率虚高，成本却是真实的三倍。

第四步：四个度量，把「支持」拆开

四个数字，缺一不可：

前两个度量的分工很关键：覆盖率回答「有没有这个字段」，填充率回答「取没取到值」。覆盖率 95% 但填充率 60% 的供应商，和覆盖率 70% 但填充率 98% 的供应商，后者对业务的价值通常更高——前者给你一堆 null，后者给你的每条记录都是实的。只看覆盖率会被严重误导。

下面这段脚本可以直接跑，把四个数字算出来。它把嵌套 JSON 拍平成字段路径，剔除空值，再按契约校验：

import json, statistics

CONTRACT = {
    "P0": ["asin", "title", "price.current", "availability.status",
           "rating.value", "rating.count", "bsr", "variants"],
    "P1": ["parentAsin", "brand", "price.original", "price.currency",
           "coupon", "seller.name", "offerCount", "images",
           "badges", "isSponsored", "categoryPath"],
}

def flatten(obj, prefix=""):
    """拍平成 a.b.c 路径；列表取前若干元素；空值不进入结果"""
    out = {}
    if isinstance(obj, dict):
        for k, v in obj.items():
            out.update(flatten(v, f"{prefix}.{k}" if prefix else k))
    elif isinstance(obj, list):
        for v in obj[:50]:
            out.update(flatten(v, f"{prefix}[]"))
    elif obj is not None and obj != "" :
        out[prefix] = obj          # 非空才计入 → 天然排除 null / ""
    return out

def evaluate(record, cov_threshold=0.8):
    flat = flatten(record)
    contract = CONTRACT["P0"] + CONTRACT["P1"]
    present = [f for f in contract if f in flat]
    coverage = len(present) / len(contract)
    p0_ok = all(f in flat for f in CONTRACT["P0"])   # P0 必须 100% 有值
    return {
        "coverage": round(coverage, 3),
        "usable": bool(p0_ok and coverage >= cov_threshold),
    }

def run(records, spend_usd):
    ev = [evaluate(r) for r in records]
    usable = [e for e in ev if e["usable"]]
    return {
        "样本数": len(ev),
        "可用记录率": round(len(usable) / len(ev), 4) if ev else 0,
        "平均覆盖率": round(statistics.mean(e["coverage"] for e in ev), 3),
        "每千条可用记录成本": round(spend_usd / len(usable) * 1000, 2)
                              if usable else None,
    }

把同一批 records 喂给每一家候选，spend_usd 填各自的实际支出，四家的 run() 输出放在一起，选型结论基本就出来了。这个过程不需要供应商配合，也不需要拿到对方的字段字典——你测的是交付结果，不是宣传材料。

第五步：把失败分成四类

可用记录率告诉你总体表现，但不告诉你怎么改进。所以要把失败拆开：

第三类是最需要警惕的。它不会报错、不会触发告警、不会引发账单争议，只会让你的报表慢慢失真。上面那段脚本里 p0_ok 那一行，作用就是专门抓它。

第六步：把回归做成常规动作

一次验收只能证明「现在能用」。供应商的覆盖能力是会漂移的——页面改版、策略调整、容量变化，都会让上个月的结论失效。

建议每周跑一次固定样本（50 到 100 条即可，成本很低），记录四个数字的趋势：中位延迟、p95 延迟、可用记录率、平均覆盖率。做成折线图，一旦出现趋势性下滑，你能在业务侧察觉之前发现问题。这件事的投入极小，但它是把「数据供应商」从黑盒变成可管理组件的唯一办法。

七、用这套框架看市场：差距究竟出现在哪里

我们不打算给一份供应商排名——那会让我们回到第二节批判的那个老问题上去。更有用的是告诉你：跑完这套框架之后，差距通常出现在哪几个位置。这能帮你在自己的测试里知道该重点看哪里。

先说一个反复观察到的现象：把同一批 ASIN 喂给不同供应商，返回会明显分成三种形态。下面是结构示意（字段名为真实命名习惯，数值为示例值）：

【形态 A｜薄】约 12–18 个字段
{
  "asin": "B0C7V9K2XQ", "title": "...", "brand": "...",
  "price": 49.99, "currency": "USD", "rating": 4.3,
  "reviewCount": 1284, "availability": "In Stock",
  "mainImage": "https://...", "bsr": 1842,
  "category": "Electronics", "url": "https://..."
}

【形态 B｜中等】约 30–40 个字段，含变体但无广告位标记
{
  "asin": "B0C7V9K2XQ", "parentAsin": "B0C7V90001",
  "title": "...", "brand": "...", "manufacturer": "...",
  "price": {"current": 49.99, "original": 69.99, "currency": "USD"},
  "coupon": {"amount": 5.00, "type": "percentage"},
  "availability": {"status": "In Stock", "deliveryEstimate": "..."},
  "rating": {"value": 4.3, "count": 1284,
             "histogram": {"5": 62, "4": 21, "3": 9, "2": 4, "1": 4}},
  "bsr": [{"category": "Electronics", "rank": 1842},
          {"category": "Portable Audio", "rank": 97}],
  "variants": [
    {"asin": "B0C7V9K2XQ", "attributes": {"color": "Black", "size": "256GB"},
     "price": 49.99, "availability": "In Stock"},
    {"asin": "B0C7V9K2XR", "attributes": {"color": "White", "size": "512GB"},
     "price": 79.99, "availability": "In Stock"}
  ],
  "seller": {"name": "...", "rating": 4.6, "isFulfilledByAmazon": true},
  "images": [{"url": "...", "variant": "MAIN"}, {"url": "...", "variant": "PT01"}],
  "badges": ["Amazon's Choice"]
}

【形态 C｜完整】含广告位标记、自然位次、变体深度与深页位次
{
  ... 形态 B 的全部字段 ...
  "variants": [
    {"asin": "B0C7V9K2XQ", "attributes": {"color": "Black", "size": "256GB"},
     "price": {"current": 49.99, "original": 69.99},
     "availability": "In Stock", "rating": {"value": 4.3, "count": 812},
     "isBuyBoxWinner": true, "offerCount": 7}
  ],
  "isSponsored": false, "organicPosition": 1,
  "searchContext": {"keyword": "...", "page": 1, "positionOnPage": 3,
                    "sponsoredCountAhead": 2,
                    "adTypesAhead": ["SB", "SP"]},
  "priceHistory": {"min90d": 44.99, "max90d": 69.99},
  "subscribeAndSave": {"discount": 5},
  "buyBoxWinner": {"seller": "...", "price": 49.99, "shipping": "FREE"}
}

在功能对比表上，这三种形态是同一个对勾。在你的报表上，形态 A 只能做价格监控，形态 B 能做选品与变体分析，形态 C 才能做排名归因与广告竞争分析。你买的不只是数据，是你能提什么问题。

差距最大的五个位置

跑过多轮之后，供应商之间的分化几乎总是集中在以下五处。你自己的测试如果时间有限，优先看这五个：

一、广告位标记与自然位次。这是区分度最高的一项。有 isSponsored 与 organicRank 的供应商是少数，多数返回里只有页面位次。缺了它，排名监测必然失真。

二、变体级字段深度。很多供应商的 variants 只有 ASIN 列表，没有每个变体的价格、库存、评分。这等于告诉了你「有五个变体」，但没告诉你哪个在卖、哪个缺货、哪个评分在掉。

三、搜索深页。前两页差距不大，第 3 页往后分化明显。有些供应商在第 3 页开始返回重复记录，有些直接返回空。

四、促销与优惠券。coupon、promotions、Subscribe & Save 折扣这几项，覆盖率普遍偏低，但对定价决策影响很大——只看标价会系统性高估竞品的实际成交价。

五、卖家与 Buy Box 信息。offerCount、buyBoxWinner、卖家评分这几项，在跟卖激烈的品类里是核心指标，但很多返回里完全没有。

四个案例：字段缺失是怎么变成业务损失的

抽象的数字不如具体场景。下面是四个真实结构的项目，为保护客户信息做了脱敏。

案例一：以为是第 3 名，其实是自然位第 1。某消费电子品牌监测核心词排名，连续四个月显示稳定在第 3 位，团队据此判断自然流量触顶，准备加大广告投放。补上 isSponsored 字段后重算，发现真实情况是自然位第 1，前面插了两个竞品的 Sponsored Brands 广告。自然表现其实一直在变好，这个信号被广告位稀释掉了。结论反转后，广告预算不增反减，季度投放效率提升明显。缺一个布尔字段，让一个季度的预算决策建立在相反的判断上。

案例二：排名第 4 页，报表里却很好看。反向的情形。某家居品牌的关键词监测显示排名「表现良好」，但流量持续下滑。拆解搜索返回后发现，前三页铺满了竞品的 Sponsored Products，该品牌的自然位实际在第 4 页——页面位次被广告挤到了看不见的地方，而旧的数据源把广告和自然结果混在一起排序，看起来自然位次还不错。

案例三：一条无法执行的评论洞察。某小家电团队的评论分析跑出高置信结论「用户普遍抱怨续航不足」。这条洞察没法落地：不知道是哪个规格续航不足，不知道黑色版和白色版的抱怨比例是否一致。整个产品线一起改，成本高、周期长。补上 variant 字段后定位到某一具体容量规格——问题集中在低配版，高配版几乎无抱怨。应对方案从「全产品线改电池」变成「调整低配版的规格描述与预期管理」，成本降了一个数量级。变体归属这个字段，把洞察从「有道理」变成「可执行」。

案例四：覆盖率很高，但填充率是灾难。某团队选型时看到某供应商 schema 里有 60 多个字段，覆盖率 92%，当场签了年约。上线三个月后发现报表里优惠券维度常年为空、配送时效常年为空——这两个字段在 schema 里存在，但实际填充率不到 15%。由于是年约，中途更换的成本很高。这个案例的教训是：签约前一定要跑填充率，不能只看字段清单。如果当时跑了第六节那段脚本，flatten 排除空值的那一行会立刻暴露问题。

八、Pangolinfo 在这套标准里处在什么位置

前面七节尽量保持了中立，因为方法论本身不该被供应商身份污染。这一节交代我们自己的位置，也交代我们做不到什么——后者同样重要。

用第六节的框架口径来陈述，我们把字段完整度的重心放在了行业普遍做不好的那几个位置上：

广告位识别是投入最重的方向。isSponsored、sponsoredType（区分 SP / SB / SD）、organicRank 这三个字段在我们的搜索与商品返回里是标准字段，不是可选项。支撑它的是跨 13 个市场的广告位采集能力——公开可查的整体采集率为 91.4%。这个数字的意义在于：它能让「排名」这个指标重新变得可信。案例一和案例二描述的失真，在我们这套返回里不会发生。

变体级数据是完整建模的，不是附带的。每个变体带自己的 ASIN、规格属性、价格、库存、评分、Buy Box 归属与报价数量。父 ASIN 与子 ASIN 同时返回，聚合与下钻都能做。案例三那种「洞察无法落到规格上」的问题，根因就在这里。

搜索结果提供到深页。前两页的数据在竞争度判断上的价值有限，我们的返回覆盖到更深的页码，且页面绝对位次与自然位次分别给出。

工程侧的两个数字供参考：中位延迟约 3 秒，成功率 99%。这两个数字建议你自己复测，不要直接采信——第六节那套框架就是为此准备的。

我们明确不覆盖的部分：账户域数据（订单、库存、自家 listing 表现）属于官方 SP-API 的授权范围，我们不提供，也不提供绕过方式；买家个人身份信息不采集；登录后才能看到的内容不采集。这些不是「暂不支持」，是设计上的边界。如果你的需求全部落在账户域，正确的做法是直连 SP-API，我们帮不上忙。

需要说明的一点是：我们同样建议你把这套盲测框架用在包括我们在内的每一家候选身上。字段完整度这件事，只有买方自己量过才有意义——供应商自己报的数字，无论谁报的，都该被验证。

九、按场景的推荐，而不是排名

最后一节给可执行的选择。不是「谁第一」，而是「什么情况走哪条路」。

第六行值得多说一句。Agent 取数和程序取数是两种工作流，不是同一个接口的两种包装。REST API 面向管道——批量、可重放、有明确的失败语义；MCP 面向对话——按需、单条、需要字段自带语义。共用同一套字段契约，两边的数据口径才对得上。

十、上线前验收清单

不管最后选了哪家，上线前把下面七项过一遍。它们的共同点是：都能在签约前完成，都能用第六节的脚本自动化。

1. 字段契约已落笔，P0 / P1 / P2 分级明确，且经过业务方确认——不是工程师拍脑袋写的。
2. 样本集覆盖五类商品：跨类目、跨站点、含多变体、含弱数据商品、含深页。
3. 四家以上跑完盲测，同口径执行（同 ASIN、同时间窗、同并发、同重试策略）。
4. 四个数字都拿到了：覆盖率、填充率、可用记录率、每千条可用记录成本。缺一个都不能比价。
5. 失败分过类，重点确认部分失败（P0 为 null）的比例——这是唯一需要专门脚本才能抓到的一类。
6. 配额与限流已建模，按操作类型分别算，并测过退避策略在真实配额下的表现。
7. 回归已排进周期，固定样本每周跑一次，四个数字做成趋势图。

第七项最容易被跳过，也最有用。一次性验收只能证明「现在能用」，每周回归才能证明「一直在用」。

外部参考：Amazon Selling Partner API 官方文档（授权模型与按操作限流）、Amazon 使用条款与 robots 说明、Pangolinfo 服务公开指标。