一、先说结论：报价的单位和你要的单位差五个乘数

亚马逊数据 API 的定价页给的是一个单价，单位可能是调用、结果、积分、流量或速率额度。你的预算要的是一个总量，单位是你库里能用的记录数。两者之间不是一个除法，是五个乘数相乘：

五个乘数都吃掉一部分预算，只有一个出现在定价页上。剩下的四个，两个藏在合同里（失败计费口径、结果页条数定义），两个藏在你自己的架构里（重试策略、轮询节奏）。这也是为什么两家公司用同一个供应商、同一个单价，月度成本能差两倍。

一句话口径：别问「每千次调用多少钱」，问「每千条通过我质量门的记录，我要为它付多少钱，其中包含多少不在发票上的工时」。

二、搜「亚马逊数据 API 定价」的人，实际在问三件事

这个词表面是询价，实际是三拨不同处境的人在同一页找答案。他们的需求不一样，但缺的东西是同一个：一个能把报价换算成自己账单的口径。

第一拨：手里有供应商报价，要做预算的人

他们已经拿到两份报价，一份按调用、一份按结果，价格看着差三倍，不知道怎么比。他们要的不是「哪家便宜」，是一个能自己填参数、算出可比数字的公式。这类人拿到公式就能走，不需要被说服。

第二拨：账单已经超预期，要找原因的人

他们的系统上线三个月，账单从预估的两千涨到五千，请求量没变。这类人的问题几乎从不在单价上，而在重试放大和轮询节奏上：客户端重试了三次，服务端也自动重试了一次，失败的那几次还计费。他们需要的是一张排查清单，按乘数逐项定位。

第三拨：在为明年选供应商的人

他们手上还没有数据，正在写选型文档。这类人最容易被定价页的起步价误导——起步价对应的是最简单的端点、最低的倍率、单市场、无渲染。他们需要的是一份「定价页不写但你必须在签约前问清」的条款清单。

三拨人的共同点是：他们都不缺一张价格对比表，缺的是把价格表上的数字变成自己账单的能力。本页只解决成本口径这一件事；更靠前的全局选型问题在 亚马逊数据采集 API：全局选型与成本结构，那篇给的是完整图景。所以本文不列供应商价格对比——那类表格三个月就过期，而且没有你的失败率和可用率，谁也填不出你要的那个数。本文给的是换算方法，你把参数填进去，用自己的数字得出结论。

三、为什么有的报价便宜到不合理：账单被拆成了四层

同一批数据，两份报价能差一倍以上，而贵的那家既没有多给字段，也没有更好的服务承诺。差别多半不在单价，在「这个价格包含什么」。把必选项拆成加价项之后，报价页上的数字降下来了，账单上那几项你一样也少不了。

最容易踩到这个岔路的是入口类数据。近几个季度，我们接触的几家头部卖家在做同一件事：把 Alexa 这条流量线当成和关键词平等的入口单独优化——盯推荐位次、盯自己出现在哪些 ASIN 的关联位、盯这条流量线带来的转化。这类数据恰好命中下面四层，也是不少供应商报价表里找不到的那类。我们的对应端点在 Amazon Alexa API。

3.1 第一层：JS 渲染

静态 HTML 请求是把服务器返回的字节取回来。JS 渲染要先用无头浏览器把页面执行一遍，等异步请求把内容填上再取。后者的成本结构是 CPU 时间与内存占用，不是带宽，所以它贵。

这一层值多少钱可以直接查。以 Oxylabs 公开定价页的同一档为例：Amazon 结果不带 JS 渲染为 0.50 美元/千条，带 JS 渲染为 1.35 美元/千条，倍率 2.7 倍（2026 年 9 月取自其定价页，价格随档位与合同变动）。同一个套餐里并排列着两个价格，说明渲染在他们的定价里是一个开关，不在基础价里。

3.2 第二层：IP 等级

机房 IP 与轮换住宅 IP 的成本差，代理商的公开报价就能看出来，差距是按倍数计的，不是百分比。Amazon 对自动化请求有一套识别标准：IP 质量、浏览器指纹、请求节奏、会话连续性。被识别之后的返回结果有两种，一种是挡在外面，另一种是给你一份缺了一部分的页面。后者麻烦，它返回 200，字段看着齐，只是头部广告位没了、某几个模块没有加载。

这一层不会出现在调用报价里。它通常在另一条产品线上结算——住宅代理、轮换代理单独计价，你需要自己把它和调用成本加到一起。

3.3 第三层：登录会话与账号

有些数据在会话之外就不下发：Alexa 的部分模块、部分评论的完整内容都属于这一类。供应商要维持登录态，就得养账号池、接风控、处理验证码，还要承担账号失效之后的补充成本。这笔账要么落在账号维护费上，要么摊进该端点的倍率，两种写法都不会出现在「基础调用价」那一栏。

3.4 第四层：按端点不可关闭的倍率

前三层加完还要问一句：能不能只对需要渲染的端点开渲染。若只能全局开关，这一项在账单里是常数，不是可以调优的变量。多市场与邮区级定位同理，判断方法见第九节 9.5。

3.5 三类数据的加价对照

把三者混在一个每月 100 万条的计划里，按定价页口径估出来的数只落在第一行。三层加价压在第二行和第三行上，谁也不碰第一行。所以「起步价便宜」这句话，对必须拿全 SP 广告位或 Alexa 模块的团队没有参考价值，他们要买的那几项从来不在起步价里。

3.6 加价之外，还有一个不在报价单上的变量

上面三层都付了钱，还有一个数任何报价单都不写：同样开了渲染、同样用了高等级 IP，不同供应商取回来的东西一样吗。SP 广告位采集率是最直观的检验入口，它是搜索结果里最难拿的那部分，也几乎是唯一能按数字对比的部分。我们在跨 13 个市场的公开对比里，SP 广告位采集率是 91.4%，多数供应商不承诺这个数。

它对成本的影响在这里：广告位缺失的那部分结果照样返回 200。你的质量门若不检查，它按可用记录入了库，把账面单条成本拉低；质量门若把它挑出来丢掉，它就只有成本没有产出。两种处理方式之下，报价便宜的与报价贵的排序可能翻转。

3.7 全包报价：把必选项放回默认项

另一种做法是不拆：渲染默认开着，IP 等级默认取到满足采集要求的那一档，不为渲染与代理再开一条产品线。报价形式上它表现为单价偏高，我们把带渲染与高等级轮换 IP 的成本摊进了各端点的积分倍率，因此定价页上没有「渲染开关」这一项。

给买家的结果是：比价初期看到的价格偏高，但你不必在接下来两个月里逐项发现报价里不含什么，留给你的动作只剩填自己那五个参数。要不要为这层确定性付溢价，取决于你的数据有多少落在上面表格的第二行和第三行；静态字段占九成的团队，拆项报价确实更省。

四、六种计费单位，以及它们为什么不能直接比

亚马逊数据服务的计费口径大概能归成六类。它们不是六种价格，是六种「你在为什么付钱」的定义。比价之前必须先把它们归一到同一个分母上，否则你比的是六个不同的东西。

4.1 按每次尝试计费

只要请求发出去就算钱，无论返回什么。这是最不利于你的一类，因为失败、超时、被拦截的尝试都由你承担。它的好处是单价通常最低——供应商把风险转移给了你，用价格补偿。判断这类报价的真实水平，你必须先测出自己在目标站点上的尝试成功率，再算 1 / 成功率 这个放大系数。成功率 95% 是 1.05 倍，成功率 80% 是 1.25 倍，成功率 60% 是 1.67 倍，而且曲线是凸的：每掉一个点，代价比上一个点更大。

4.2 按成功请求计费

只对返回成功响应的调用计费。听起来对买方友好，但关键在「成功」由谁定义。多数计费系统把 HTTP 200 记为成功，而一个带着空字段、占位符或验证码页面的 200，对你来说是失败，对计费系统是收入。签约前要确认的是：返回 200 但业务字段为空，算不算成功？返回值里包含「商品不存在」这类有效空响应，算不算成功？这两个问题的答案，通常决定你账单的 10% 到 20%。

4.3 按每千条结果计费（CPM）

按返回的结果条数计费，电商类目标常见的公开区间在每千条 0.45 到 1.6 美元之间，具体取决于目标站点难度和输出格式。这类口径的失真点在「结果」的定义：结果是一张页面，还是页面里的一条商品记录？搜索类接口通常按页计费，一页的条数受分页参数控制；如果文档里写的是「每页最多 N 条」而不是「每页 N 条」，你要按实测的平均条数折算，不是按上限折算。

4.4 按积分计费

每个端点有积分倍率，难度越高倍率越高：静态页 1 积分，需要渲染的页面、住宅代理、指定邮区、强防护域名可能 5 到 25 倍。这类口径的好处是灵活，坏处是透明度依赖文档完整度。评估时做三件事：拉一遍你要用的每个端点的倍率表；确认倍率能否按端点单独关闭（比如只对搜索开启渲染，商品详情走静态）；用你自己的真实端点组合加权算一次，不要用起步价对应的那一个端点外推。

4.5 按流量计费

按传输字节收费，常见于代理型产品。这里最大的变量不是单价，是单页体积。公开的代理成本测算普遍给出两个区间：优化过的采集约每页 100 到 300 KB，未优化、走完整浏览器渲染的采集约每页 1 到 3 MB，同一批数据差一个数量级。如果你的供应商按流量计费，而你的采集方式依赖渲染，那么压体积的收益会比谈单价大得多——关掉图片与字体加载、复用连接、开启压缩，都是直接落在账单上的动作。

4.6 按速率额度计费

按每分钟令牌数或并发数卖额度，令牌按固定速率补充，未用完的令牌在一段时间后作废。这类口径的陷阱是月度总量与瞬时速率脱节：某档位每月生成 892,800 个令牌，看着能覆盖你的月度需求，但它的补充速率是每分钟 20 个，桶容量上限是 1,200 个。一个需要在两小时内跑完 50 万条任务的夜间批处理，会被这个速率卡住，而你为整月的额度付了钱。

4.7 一张换算表：六种单位归一到「每千条可用记录」

下表列出每种口径要换算成同一个分母，你还缺哪些参数。缺的参数没有行不行，只能自己测。

数据来源：各类口径的定义与公开区间取自供应商公开定价文档与 2026 年行业公开评测的汇总；单页体积区间取自公开的代理成本测算。本文不点名供应商，也不引用任何一家的具体报价。

4.8 为什么定价页不写这些

不是因为供应商想隐瞒，而是因为那四个参数在供应商这一侧测不出来。尝试成功率取决于你的目标站点、你的并发节奏和你的重试策略；可用率取决于你的质量门和业务字段清单；每次调用的记录数取决于你的分页参数与去重规则；额度浪费取决于你的调度窗口。这些都在你这一侧，供应商能给的只有可复算的单价和倍率表——那也正是你在定价页上应该要求看到的东西。

所以评估一份报价的正确顺序是：先在定价页上确认单价与倍率是否公开可查，再用自己的系统把四个参数测出来，最后代进公式。跳过第二步直接比价格表，得到的排序没有任何意义。

五、从一次调用到一条可用记录：五个乘数

这一节把五个乘数逐个拆开。每个乘数都给一个可直接套用的算法，以及它在什么量级上改变你的账单。

5.1 乘数一：尝试次数

设单次尝试成功率为 s，你重试到成功为止，那么为得到一次成功响应，平均尝试次数是 1/s。失败的那部分尝试是否计入账单，用系数 β 表示：β=0 表示失败不计费（或自动退款），β=1 表示失败按全价计费。账单上多出来的比例就是 β·(1−s)/s。

下表用同一组参数（可用率 0.9、额度浪费 0.1）展示失败计费口径的差别，单价按每积分 0.0015375 美元、每千条 1.5375 美元计：

结论是：失败计费这件事，在成功率高的档位不值一提，在成功率低的时候能单独改变选型结论。而亚马逊是防护强度排在前列的站点，你的成功率多数不在 99% 那一档。拿自己的日志统计一周，比在合同里争论这一条更快。

5.2 乘数二：账单上的成功，不等于你的可用

这是五个乘数里最贵、也最少被写进预算表的那个。供应商的计费系统判「成功」，用的是 HTTP 状态码和响应结构；你判「可用」，用的是自己的质量门。二者之间那段距离，就是可用率 v。

举一个具体形态：某商品页的价格字段供应商确实返回了，但值是占位符（比如父变体的价格而非当前变体），类型合法、格式正确、schema 校验放行，你的仓库里多了一条价格错误的记录。或者评论接口返回了 200 和一页结构完整的 JSON，但 reviews 数组是空的——这个 ASIN 当天没抓到，计费系统记一次成功。

v 对成本的放大是 1/v，同样是凸曲线：

可用率低于 70% 的方案，单价再低也很难赢。而可用率恰恰是定价页上永远不会出现的数字——它不在供应商的义务里，在你的质量门里。怎么把可用率测出来，见 亚马逊数据管道：外包采集之后，甩不掉的是数据治理 里的质量门四数字。

5.3 乘数三：一次调用不等于一条记录

商品详情接口通常是一条记录一次调用，但搜索、榜单、评论这三类接口按「页」返回。这里有三个折损点：分页上限——文档写「每页最多 N 条」，实际返回常少于 N；跨页重复——同一个 ASIN 出现在相邻两页，去重后净条数下降；广告位混入——搜索结果页里付费位占一部分，你要的是自然位时，一页里能用的条数更少。

换算方式只有一种：拿你自己的真实查询跑 200 次，统计「净入库条数 ÷ 调用次数」，得到实测的 r。用文档里的上限值外推，是预算表里最常见的错误来源，误差能到 1.5 倍。

5.4 乘数四：轮询节奏相对变化率的冗余

你轮询是为了发现变化，但你付钱买的是调用次数，不是变化次数。二者的比值就是冗余系数 ρ = 每日轮询次数 ÷ 日均变化次数。

注意：这个冗余不是为了省而省的对象——你不轮询就不知道它变了。可以优化的是它的分布：分层轮询（P0 字段每 4 小时、P1 每天、P2 每周）和变化驱动（用降价与榜单变动类端点替代全量重扫）。前者把高频预算集中到对时效敏感的字段，后者把「检测变化」这件事的成本从全量降到增量。两种手段叠加，通常能砍掉一半以上的无效调用，且不损失检测时效。

5.5 乘数五：买得下、用不掉的额度

额度浪费系数 w 有三种来源。速率整形：月度额度够，每分钟补充速率不够，批处理窗口内跑不完。额度过期：令牌在生成后 60 分钟作废，夜间批处理用不完的额度不会滚存到白天。并发上限：你买的是高吞吐档位，但客户端并发没调上去，一个月里有一半额度没用。

三者的共同表现是：月度账单按额度付，入库记录数按实际消费算，两者比值持续大于 1。这个数每个月都应该被统计一次，它是唯一一个「供应商没做错任何事、你损失了钱」的乘数，也是最容易通过调度优化拿回来的那部分。

六、完整公式：把六种单位归一成一个数

把五个乘数合起来，得到从报价单价到每千条可用记录成本的一个式子。

6.1 变量定义

6.2 公式

每千条可用记录的数据成本

    C = 1000 · p · m · [ 1 + β·(1 − s)/s ]
        ───────────────────────────────────
              r · v · (1 − w)

含工程成本的真实单条成本

    C_tco = C + 1000 · E / U

    U = 每月需要的可用记录数

式子里只有 p 和 m 来自定价页，其余五个参数全部来自你自己的系统。这正是定价页无法回答「到底要花多少钱」的原因——它只提供了七个参数里的两个。拆项报价的供应商还要在 m 上乘进第三节的四个加价项，这几项不落在 p 里，所以定价页上看不到。

6.3 可运行的计算器

把下面这段存成 unit_cost.py，填上你自己的参数即可。它同时输出数据成本、工程成本和工程占比。

def cost_per_1k(p, m=1.0, s=1.0, v=1.0, r=1.0, beta=0.0, w=0.0):
    """每千条可用记录的数据成本。
    p    报价单价（每计费单位）
    m    端点倍率加权值
    s    单次尝试成功率
    v    成功响应中的可用率
    r    每次成功调用净入库记录数
    beta 失败尝试的计费比例，0 为不计费
    w    买下却用不掉的额度比例
    """
    attempts = 1 + beta * (1 - s) / s          # 尝试次数带来的放大
    usable_per_call = r * v * (1 - w)          # 每次调用净得可用记录
    return 1000.0 * p * m * attempts / usable_per_call


def tco_per_1k(p, monthly_records, engineering_cost, **kw):
    """含工程成本的真实单条成本。"""
    c = cost_per_1k(p, **kw)
    return c + 1000.0 * engineering_cost / monthly_records


if __name__ == "__main__":
    # Pangolinfo 公开档位示例：Expert $369 / 240,000 积分
    P = 369 / 240_000                     # $0.0015375 / 积分
    U = 500_000                           # 每月需要 50 万条可用记录
    E = 30 * 90                           # 每月 30 小时工程，加载后时薪 $90

    ideal = cost_per_1k(P)
    real  = cost_per_1k(P, m=1.0, s=0.95, v=0.88, r=1.0, beta=1.0, w=0.12)
    tco   = tco_per_1k(P, U, E, m=1.0, s=0.95, v=0.88, r=1.0, beta=1.0, w=0.12)

    print("定价页口径    $%.4f / 千条   月账单 $%.2f" % (ideal, ideal * U / 1000))
    print("五个乘数后    $%.4f / 千条   月账单 $%.2f" % (real, real * U / 1000))
    print("含工程成本    $%.4f / 千条   月账单 $%.2f" % (tco, tco * U / 1000))
    print("工程成本占比  %.0f%%" % (100 * E / (tco * U / 1000)))

运行结果：

定价页口径    $1.5375 / 千条   月账单 $768.75
五个乘数后    $2.0899 / 千条   月账单 $1044.95
含工程成本    $7.4899 / 千条   月账单 $3744.95
工程成本占比  72%

三行数字之间差了 4.9 倍，而它们描述的是同一个供应商、同一个单价、同一个月。差的部分全在口径里。

6.4 三行数字各自用在哪儿

第一行（定价页口径）只用于横向比价：在参数还没测出来的选型初期，用它筛掉量级不符的方案，可以，但不要写进预算。第二行（五个乘数后）用于做预算和对账：这是你下个月账单的期望值，偏差应该在 15% 以内；超过这个范围说明有参数没测准，通常是 v 或 w。第三行（含工程成本）用于做决策：只有这一行能回答「自建还是采购」「换不换供应商」，因为前两行都在比较发票，而决策要比的是总成本。

把三行数字并排写进选型文档，还有一个附带好处：它让评审会上的争论从「这个供应商贵不贵」转向「我们的可用率为什么只有 0.85」，后者才是有答案的问题。

七、三档用量情景：5 万、50 万、500 万条

下面三档用量的参数取自常见的亚马逊数据项目形态，不是任何供应商的报价。单价统一用 Pangolinfo Expert 档的公开价格（$369 / 240,000 积分 = 每积分 $0.0015375），这样每个数字你都能自己复算。

7.1 情景 A：每月 5 万条，单市场单品类

形态：一个市场、一个品类的价格与 BSR 监控，每天跑一次全量。参数：r=1（商品详情，一条一次调用）、m=1（结构化 JSON）、s=0.97、v=0.95、β=1、w=0.05、每月 8 小时工程。

这一档里，数据账单占总成本的 11%，工程成本占 89%。你在这时候花三周去谈单价，收益上限是每月 11 美元；把失败重试策略写对、把质量门自动化，收益是每月几百美元。小用量阶段，优化的对象不是单价，是工时。

7.2 情景 B：每月 50 万条，5 个市场

形态：5 个市场、价格与 BSR 监控，每天两次。参数：r=1、m=1、s=0.95、v=0.88、β=1、w=0.12、每月 30 小时工程。

五个乘数让数据成本上升 36%，工程成本仍占 72%。这一档最值得做的两件事：把 w 从 0.12 压到 0.05（调度与并发优化，可省 $73/月），把 v 从 0.88 提到 0.95（质量门前移，可省 $78/月）。两项合计每月 151 美元，超过这一档任何一档位差价的量级。

7.3 情景 C：每月 500 万条，13 个市场含评论

形态：13 个市场，60% 商品详情 + 40% 评论，近实时监控。加权倍率 m = 0.6×1.0 + 0.4×(5/8) = 0.85（评论端点每页 5 积分，按每页 8 条折算）。参数：s=0.94、v=0.85、β=1、w=0.18、每月 90 小时工程。

这一档数据成本首次超过工程成本，单价谈判开始有意义，但顺序仍然不能反：先把 w 从 0.18 压到 0.05（每月省 $1,365），再谈档位。谈判拿到的折扣作用于已经优化过的分母，收益才留得住。

7.4 三档对比：优化对象的迁移

三档的关键差异不是金额，是杠杆落点。A 档谈单价的收益上限是每月 11 美元，压工时的收益是每月数百美元；C 档反过来，单价与倍率每降 10% 就是每月近千美元。把 A 档的打法用在 C 档，或者把 C 档的打法用在 A 档，都是在用错杠杆。

表里三档的工程量级（8 / 30 / 90 小时每月）来自常见项目形态，加载后时薪按 90 美元计。替换成你自己的数字，结论可能落在不同的档位区间——这正是要把公式而不是结论带走的理由。

八、发票外的成本：解析、QA 与维护工时

前面三档情景里，工程成本占月度总成本的 45% 到 89%。这部分不上任何一张发票，却是决定方案生死的那一半。

8.1 三项工程成本，以及各自怎么估

初始集成与字段映射：把接口返回的字段映射到你的数据模型，处理嵌套结构、单位换算、多语言字符、变体关系。这部分是一次性的，量级取决于字段数与 schema 稳定度——字段越多、契约越松，映射越贵。估法：按字段数估人天，每个需要特殊处理的字段（价格、排名、评论时间、变体维度）单独计。

每周维护与故障排查：目标站点改版、解析器失效、字段静默变空、告警误报、运营来问「这个数为什么变了」。公开的运维统计里，团队在中等规模采集上每周要花 5 到 10 小时做维护性工作。估法：把过去八周花在这件事上的小时数除以八，得到周均维护工时，乘 4.3 得到月度工时。这个数字是所有成本讨论里最该先算的那个。

质量门与监控的建设：覆盖率、填充率、新鲜度、分布漂移这四个数字的自动统计，以及它们触发告警之后的处置流程。见 亚马逊数据管道 第五节的四个数字与阈值建议。

8.2 加载后时薪怎么定

不要用基本工资除以 2,080，那会低估 25% 到 40%。加载后时薪要包含社保与福利、工具与云资源分摊、管理开销，以及招聘与培养的摊销。行业通行做法是在直接薪资上乘 1.25 到 1.4。做内部对比时用同一个系数即可，不需要精确到小数点。

8.3 一个判据：什么时候该停止优化单价

把每月工程工时乘以加载后时薪，得到 E；把数据账单记为 S。若 E > S，你这一阶段的优化对象是工时不是单价——把维护从每周 10 小时压到每周 3 小时，收益远超任何档位折扣。若 S > 2E，说明用量已经到了规模区间，此时才值得投入谈判与架构重构去压单价。三档情景对应的正好是这三个区间的过渡：A 档 E 远大于 S，B 档 E 约为 S 的 2.6 倍，C 档 S 首次超过 E。

九、价格表之外的五个条款，决定你第二年付多少

定价页决定你第一个月付多少，合同条款决定你第二年付多少。下面五条不在定价页上，但它们对第二年的影响普遍大于档位差价。

9.1 失败怎么定义，由谁定义

要求供应商书面给出「一次成功调用」的定义，并明确三类响应归属：返回 200 但业务字段为空；返回 200 但内容是占位符或验证码页；返回有效空结果（商品确实下架）。第一类最常见，也最容易在合同里被含糊过去。你要的是一句可写进验收标准的话，不是一句承诺。

9.2 失败是否计费，重试算几次

三个问题分开问：失败尝试是否计费；供应商服务端自动重试的那几次是否计费；客户端重试是否计费。有的供应商服务端自动重试且合并计费，有的每一次都单独计。这一条的差别在成功率 90% 时是 11%，在 80% 时是 25%（见 5.1 表格）。

9.3 超量单价与阶梯是否自动回落

超出套餐之后的单价，普遍高于套餐内的折算单价，幅度在 1.5 到 3 倍之间。要确认三件事：超量后的每单位价格；阶梯是自动回落还是要重新签约；超量时服务是否中断。第三点最致命——有的方案超量即限流，你的夜间批处理在月底跑不完。

9.4 降级、退款与承诺期

常见的限制是：降级每月只允许一次，且差额以账户余额形式返还而非现金退款；年付方案中途不退款；企业方案有 12 个月承诺期。签之前把「如果我三个月后要把用量砍一半，会发生什么」问清楚。这条在你选错档位时值一个月的账单。

9.5 多市场、邮区与渲染的倍率，能否按端点关闭

多市场不是简单的乘以市场数——不同市场的目标站点难度不同，倍率可能不同。邮区级定位（指定 ZIP 取本地价格与库存）通常单独计倍率。渲染也一样：如果只有搜索端点需要渲染，而商品详情走静态即可，能否只对搜索开启？能否按端点分别配置？这个问题的答案，决定了你账单里倍率这一项是一个常数还是一个可以调优的变量。

十、三个常见误判：账单没错，是口径错了

10.1 「按成功请求计费」不等于「按可用数据计费」

某团队用按成功请求计费的方案，成功率仪表盘长期显示 99%，成本却持续高于预算。查下来是：接口返回 200 且结构合法，但价格字段有 18% 为空——供应商把它记为成功，计费系统照收，团队的质量门在三天后才发现。修法：把「可用率」从「成功率」里拆出来单独统计，并把可用率写进对账口径。

10.2 按结果页计费，却按商品条数做预算

某团队按「每次调用返回 20 条」做预算，实测是每次调用净入库 12 条：分页只返回 16 条，跨页重复 3 条，广告位占位 1 条。预算差 1.67 倍。修法：用 200 次真实查询实测 r，不要用文档上限值外推。

10.3 月度额度算得过来，分钟速率算不过来

某团队买了月度 200 万额度的档位，实际每月只用 120 万，月底作废。原因是令牌补充速率对应每小时 5 万，而他们的夜间批处理窗口只有 4 小时，跑不完 20 万。修法：把批处理改成滚动窗口，或把额度拆成「常驻低频 + 按需突发」两部分。这一项在该团队是每月 1,200 美元。

十一、签约前必须书面确认的 7 个问题

下面 7 条发给供应商，要求书面回复。能逐条答上来的方案，成本可预期；答不上来的，把答案缺席本身当作一条负面信号。

第 4 条常被忽略，但它对成本的影响不亚于单价：如果你每 4 小时轮询一次，而供应商缓存 TTL 是 6 小时，你有一半调用买回的是别人已经取过的数据，却按全价付费。反过来，如果你能指定跳过缓存，你就是在为一个明确的时效承诺付费，而不是为一个概率付费。

十二、Pangolinfo 在这套口径下的位置

前面十节与供应商无关，适用于任何方案，包括我们的。这一节说我们自己的口径，以及我们做不了什么。

12.1 我们的计费单位与公开价格

我们用统一的积分单位，各端点倍率在 定价页 的计算器里公开可调：商品详情每页 1 积分，评论每页 5 积分，利基数据每页 2 积分，AI Overview 每页 2 积分；原始 HTML 输出为结构化 JSON 的 75%（跳过解析环节）。档位为 Starter $19 / 9,600 积分、Professional $99 / 60,000 积分、Expert $369 / 240,000 积分，超出 Expert 之后自动进入阶梯用量计费，年付比月付低 20%。按 Expert 档折算，结构化 JSON 的商品数据每千条 1.54 美元，HTML 输出每千条 1.15 美元，年付 1.23 美元。

顺带回答一个常被问到的问题：为什么我们的单价不是最低的。原因是默认项与多数同业不同——JS 渲染默认开，IP 等级默认取到能保住 SP 广告位那一档，这两项的成本摊进了各端点的积分倍率，不在报价之后再叠一层。我们不在销售材料里强调这两项，是因为对取到数据而言它们是前置条件，不是可选配置。要做同等对比，请把对方的基础价乘以第三节的四个加价项，或者让对方按你实际跑的那套端点组合，出具一份含加价项的每千条可用记录成本。

把这些数字代进第六节公式，你自己就能算出成本——这正是我们把它公开的原因：单价是七个参数里最容易比较的那个，藏起来没有意义，能复算才谈得上信任。

12.2 我们不做的三件事

不按「尽力而为」的口径报成功率。我们公布的指标是中位延迟约 3 秒、成功率 99%、日调用量 3,000 万次以上，SP 广告位在跨 13 个市场的公开对比中采集率 91.4%。这些是公开可查的口径，不是销售话术。

不把字段覆盖率当作字段可用率。字段在契约上和字段有值是两件事。我们宁可把某个市场某个字段的填充率告诉你，也不在功能表里打一个对勾。字段级怎么验，见 亚马逊数据 API 选型：字段级对比。

不承诺零维护。接上 API 之后，质量门、监控、契约测试仍然在你这侧。我们能做的是把需要你维护的部分从「解析器 + 代理池 + 反爬」压缩到「质量门 + 业务规则」。这部分压缩不掉，见 亚马逊数据管道。

12.3 三种不该用我们的场景

只要历史价格曲线。你要的是多年跨度的价格与 BSR 时序，那类产品是数据库查询而不是实时采集，成本结构比我们低一个量级。

只取自有账户的数据。你的需求落在自己卖家账户范围内，官方销售伙伴 API 的配额足够，那是最省的路径。

每月几百条、一次性的调研。这个量级用人工加表格更快，接 API 的集成成本高于数据成本。

12.4 90 分钟：算出你自己的真实单条成本

如果你在这一步发现某个参数测不出来，那本身就是结论：你现在的供应商没有给你足够的可见性。字段级可见性怎么验，见 ；刷新频率与时效承诺怎么定，见 。

需要原始 HTML 自己解析，还是直接要结构化 JSON，取决于你的团队有没有解析能力——这两种输出在 亚马逊数据采集 API 里是同一个接口的两个参数，倍率差 25%。需要接入 Agent 的团队可以用 Amazon Data MCP，19 个工具、远程 HTTP 零安装，计费口径与 REST 一致。

十三、常见问题