价格
两条产品线各自的计价方式、我们拒绝收费的部分，以及日本买家为何向海外厂商多付 10%。
两条产品线
| 你买的是什么 | 面向谁 | |
|---|---|---|
| 监测线 | 答案 —— 每天早上自动运行，结果送到 | 不写 API 的电商、市场与采购团队 |
| API 线 | 连接 —— POST /v1/extract 与 Browser API | 开发者、数据团队、代理机构 |
两者在同一个平台上，共享一把密钥、一份账单、一条审计轨迹。
监测线按什么计价
| 轴 | 为什么是这个轴 |
|---|---|
| 监测的商品数 | 与业务思考的单位一致。「500 个商品」能写进审批单，「1,000 个 URL」不能 |
| 来源数量 | 不收费。 对来源收费会让客户削减来源，比较的样本变薄，答案就会失真 |
| 采集频率 | 每日、每日两次、每日四次 —— 在各来源允许的范围内 |
| 历史保留期 | 商品何时消失的记录。运行越久越有价值 |
接入新来源是一次性费用，不计入月费 —— 因为那本来就是一次性的工作。
API 线按什么计价
只按成功的请求数。
- 失败不计费。 5xx、超时，以及因
robots.txt禁止而未抓取的，都不收费 - 没有倍率。 JavaScript 渲染和浏览器会话，都算同样的一次请求
- LLM 层只在它真正产出价值时计费。 没有到达该层的请求不产生模型费用
为什么不用倍率
这个市场里较大的厂商按「积分」计费，一次请求可能消耗 1 到 125 个积分。 单价要等账单来了才确定。
这不是假设。某厂商的一位客户公开写道：「我醒来发现账单是预期的 40 倍」，以及「他们宣传可以设置支出上限，但根本没有这个选项」。
一个拒绝发布无法验算的数字的产品，不能让自己的价格事后才确定。
为什么不按请求计价
一个列表页一次就能取到五十条，而便宜的层不调用语言模型。 数据量增加六倍，成本并不会变成六倍 —— 不到两倍。
按请求收费，是给几乎不花钱的部分定价，并且会给你减少检查次数的理由。 而减少检查次数，与这个产品存在的目的正好相反。
日本消费税的实际处理
从海外购买服务，并不会自动让日本买家多付 10%。 适用哪条规则取决于卖方。
| 机制 | 实际成本 | |
|---|---|---|
| 面向企业的服务（条款表明只卖给企业） | 反向征收 —— 由买方申报 | 买方应税销售比例在 95% 以上时，目前反向征收根本不适用 |
| 面向消费者的服务（任何人都能注册） | 由海外卖方申报 | 卖方若已登记为合格发票开具方，可以抵扣；未登记则不能 |
所以请查卖方的登记号，而不是假设。日本国税厅提供查询页面。
Kansoku 由日本法人株式会社FID运营，开具合格发票。 登记号是 T4011101061208 ―― 可在日本国税厅公示页面核对。也不存在归入哪一类的问题。
支付方式
| 信用卡 | 由 Stripe 处理。卡信息不经过我们的服务器，我们也不保存 |
| 凭发票银行转账 | 较高的套餐支持。 日本 B2B 支付中，转账与代扣合计占六成以上 |
| 报价单 | 可应要求出具，格式适合附在内部审批中 |
| 币种 | 日本客户以日元结算，因此不产生 3〜4% 的境外交易手续费 |
年度总额会标在月费旁边。日本的职务权限规程会把用途相同的支出合并计为一笔， 所以按月计价并不会降低审批层级 —— 藏起来没有意义。
价格
测试期暂定价格，可能变动。 所有金额均为不含税。 日本客户按加收 10% 消费税结算。 在测试期签约的客户保留签约时的价格。 如需上调，提前 30 天通知。
监测线
| Starter | Standard | Pro | Enterprise | |
|---|---|---|---|---|
| 月费（不含税） | ¥14,800 | ¥49,800 | ¥128,000 | 面谈 |
| 年费（不含税，省两个月） | ¥148,000 | ¥498,000 | ¥1,280,000 | 面谈 |
| 监测的商品数 | 100 | 500 | 2,000 | 面谈 |
| 每个商品的来源数 | 不限 | 不限 | 不限 | 不限 |
| 频率 | 每日 | 每日 | 每日 | 每日多次 |
| 历史保存 | 90 天 | 1 年 | 2 年 | 面谈 |
| CSV 与每日邮件 | ✓ | ✓ | ✓ | ✓ |
| Webhook | ✓ | ✓ | ✓ | ✓ |
| 账单支付 | — | ✓ | ✓ | ✓ |
| 商品匹配协助 | — | — | ✓ | ✓ |
| 数据存放地、SLA | — | — | — | ✓ |
最多 5 件商品，免费试用，无需信用卡。 注册后即可开始监视，第二天早上就会收到一封真实的结果邮件，历史保留 14 天 —— 没有人应该为一个还没见过它运转的工具去走审批。
来源不计费。 一个商品盯三个站还是三十个站，价格相同 —— 对来源计费会让客户主动砍掉来源，比较的样本随之变薄，答案也就歪了。
实务上的参考是每个商品约十个来源。远超这个规模请与我们联系。我们不会切断服务，而是先告知、一起商量。
API 线
| 免费额度 | 每月 1,000 次请求，每月重置，无需信用卡。 2 并发、每分钟 10 次 |
| 计量 | 每 1,000 次请求 ¥62（不含税），仅计成功的 |
| 支出上限 | 以金额设置，达到即停止 |
没有倍率。 JavaScript 渲染与浏览器会话都算同一次请求。LLM 层只对该层实际完成的抽取计费。
怎么选
想知道哪家公司卖多少钱 → 监测线，不用写代码。
想接进自己的系统 → API 线。
接近监测线上限时 → API 线对您更划算，我们会主动告知。 没有理由把只需要用量的客户继续留在监测线上。
为什么是这个价格
监测线卖的不是抓取次数，而是商品匹配、换算为不含税金额、每个数字的来源记录、失败与「本来就没有」的区分，以及每天早上会送到。
本页不写与他家的对比。 要诚实地比较，必须把税务处理、汇率基准日、计费周期以及实际包含的内容（商品数、来源数、频率、历史长度）全部对齐。草率对齐的数字，总是对我们有利。 一个不事后撤回数字的产品，也不能事后撤回对比。
如果您正在评估其他厂商，我们可以按对齐后的条件替您做这份对比表。
最后更新