先说结论
如果你打算基于 SCRAPR 做服务，最差的报价方式 就是“按次抓取收费”。
按次抓取看起来简单，但几乎把你所有长期价值都让掉了：
- 客户容易拿完数据就走
- 你得不断重新销售
- 真正费时间的维护工作没被定价进去
- 一旦页面变化，你还会被追着免费修
更适合的做法是把 SCRAPR 的能力拆成 4 层价值来卖：
- 配置价值
- 持续监控价值
- 异常修复价值
- 输出接入价值
SCRAPR 官方今天公开强调的也正是后 3 点：自动修复、metrics、alerts 和“pay only when it breaks”。这意味着底层产品已经在把“持续运行”作为核心价值，而不是只卖一次 API 调用。
先搞清楚你到底在卖什么
客户表面上买的是数据，实际上买的是 4 件事：
- 数据能不能持续拿到
- 页面改版后会不会断
- 断了以后多久恢复
- 结果能不能直接进入工作流
如果你只按“抓取次数”报价，就默认客户只在乎第一件事。
这通常不成立。
所以定价模型必须覆盖“运行与维护”，而不是只覆盖“第一次配置”。
模型一：单次配置费
适合场景：
- 一次性目录抓取
- 竞品库初始化
- 数据迁移前的临时采集
这档适合做首单切入，但不适合做核心业务。
怎么报价
通常按以下维度定价：
- 网站数量
- 字段数量
- 页面复杂度
- 是否需要登录 / 反爬处理 / 清洗
适合什么客户
- 只想先看一版样例的客户
- 预算低但有试错意愿的客户
- 不确定长期需求是否成立的团队
核心问题
这种模式的问题是复购弱。
如果你只交一份 CSV，客户很容易觉得“任务完成了”。
模型二：月度监控包
这是最值得优先卖的模型。
适合场景：
- 竞品价格 / 库存监控
- 活动页变化跟踪
- 招聘 / 榜单 / 目录更新跟踪
- 行业情报日报 / 周报
为什么月包更合理
因为客户真正依赖的是：
- 定时更新
- 异常告警
- 历史对比
- 你替他维护这套系统
这些价值都不是一次性交付，而是持续服务。
月包应该包含什么
最少应包含：
- 数据源数量上限
- 更新频率
- 报表 / 表格 / Slack / Email 输出
- 异常处理 SLA
- 每月字段微调次数
如果你不把这些写清楚，客户会默认“什么都包”，后面会把你拖进无上限维护。
模型三：API 托管包
适合技术团队或已有内部系统的客户。
这类客户通常不需要你发日报，而需要：
- 稳定接口
- 标准字段
- 可调用 URL
- 更新节奏和失败处理约定
怎么收费
更适合按 3 个维度收费：
- 数据源数量
- 更新频率
- SLA 等级
为什么这档利润可能更高
因为对方一旦把你的输出接进 BI、CRM、选品系统或内部自动化里，切换成本会变高。
这时你卖的不只是数据，而是“一个被业务依赖的数据节点”。
模型四：情报订阅与顾问包
这是最容易被低估的一档。
很多客户并不缺数据，而是缺解读。
如果你只是给他结构化字段，他未必知道该怎么用。
所以你可以在 SCRAPR 的数据之上再卖：
- 每周情报周报
- 价格变化解读
- 新页面趋势分析
- 竞品策略复盘
这种模式通常客单不一定最高，但毛利往往更好，因为核心交付变成“分析和判断”，而不是纯粹维护。
报价时最容易犯的 3 个错
1. 只按网站数量收费
网站数量只是复杂度的一部分。
有的网站 1 个页面比 20 个静态页面都难维护。真正影响你成本的是：
- 页面变化频率
- 结构复杂度
- 是否需要清洗
- 是否需要高频更新
2. 不给“修复和告警”定价
SCRAPR 的优势恰恰在于自愈和维护能力。
如果你报价时不把这部分讲清楚，客户只会把它当成免费附带。
3. 没有把客户分层
对轻量客户、运营客户、技术客户，你不能用同一套价格表。
不分层就会出现：
- 报太高，小客户进不来
- 报太低，大客户拿走太多服务
更务实的报价结构
可以用下面这套思路：
Entry：试点包
用于降低首次成交门槛。
Core：月度监控包
这是主力收入。
Pro：API 托管 / 多源监控包
用于高客单客户。
Add-on：报表、告警、分析、顾问
用于提高 ARPU，而不是重新做一个新服务。
你真正要卖的是“不断线的数据流”
SCRAPR 官方 FAQ 里很关键的一点是：只在系统需要介入修复时计入 auto-heal 配额，本质上是在把“不断线”本身定义为价值。
这也给服务商一个很清楚的启发：
报价不能只围绕抓取本身，必须围绕稳定交付本身。
最后判断
如果你只想做快速回款，可以先卖配置费。
如果你想做可持续业务，重点应该是：
- 月度监控
- API 托管
- 报表与告警
- 数据解读与顾问
这样你卖的就不是“这次帮你抓一下”，而是“把网页变化变成可持续使用的数据能力”。