每个 SEO 平台在技术栈底层都有同样的依赖:对大量关键词、大量地区、每天都可靠供应的搜索结果。而每一位构建此类平台的创始人也都面临同样的早期决策:这种供应能力应该自建,还是采购。
这个决策通常被当作成本比较问题来考虑,而这是错误的思路。真正的问题是,数据采集是否属于你产品的一部分,而对几乎所有 SEO 平台而言,诚实的答案是否定的。客户付费购买的是分析、工作流程、报表和界面。从来没有客户因为供应商擅长解析结果页面而续约。
你实际购买的是什么
在你列举出自行运行数据采集所涉及的一切之前,SERP API 看起来只是一种便利。
解析维护。 结果页面布局会毫无预警地变化,每次变化都会在你这一侧引发一次无声的数据质量事故。这是让团队感到意外的持续性成本,因为它永远不会结束,而且总是在不合时宜的时候出现。
地理覆盖。 本地化结果需要从每个市场内部发出请求,这意味着要么使用具备国家和城市定位能力的住宅网络,要么使用能够处理这一切的 API。其中的原理详见为什么精准排名跟踪需要住宅代理。
吞吐量与节奏控制。 搜索引擎会进行限速,因此吞吐量取决于分布和请求节奏的把控,而非你运行了多少个工作节点。
不受你控制的正常运行时间。 如果你的产品承诺每日更新,你的数据采集层就继承了这份承诺。
购买 SERP API 会把这一切都转化为一次请求和一次响应。而自建则会把这一切转化为团队的持续责任。两种做法都有其合理性;但只有当数据采集对你而言真正具有差异化价值时,后者才是正确选择,而对于以销售洞察为核心的平台来说,通常并非如此。
决定商业模式的单位经济学
无论你选择哪条路,决定你业务走向的数字都是每次关键词检查的成本,因为它会与一切相乘。
不妨明确算一算。一位客户跟踪 500 个关键词,每天在两个地区、两种设备上进行检查,那就是每天 2,000 次检查,每月 60,000 次,这还只是一个账户。如果有一百个这种规模的账户,你每月就要处理六百万次检查,哪怕只是零点几美分的差异,也会成为决定你毛利率的一项关键支出。
这样的算法驱动着三个大多数创始人默默做出、但本应审慎决定的产品决策。
你的套餐层级实际计量的是什么。 跟踪的关键词数量是自然的销售单位,但你的成本是由检查次数驱动的,即关键词数乘以地区数、设备数和频率。按关键词收费却允许无限地区数的套餐,恰恰会在使用产品最多的客户身上颠覆你的利润结构。
默认检查频率。 每日检查是客户的期望,但相当一部分被跟踪的关键词几乎没有变动,而自适应频率——对波动大的关键词检查更频繁、对稳定的关键词检查更少——能大幅降低成本,而客户在重要指标上却察觉不到差异。识别波动性需要完整的结果集,这正是检测 SERP 波动性一文的论点。
跨租户去重。 多个客户经常会在同一地区跟踪同一个关键词。如果你的架构按关键词、地区和设备(而非按客户)来存储结果,一次检查就能服务所有这些客户。在规模化之后,这往往是可获得的最大一项成本节约,而且极难事后补救,这就是为什么它应该在第一版架构设计中就纳入考虑,而不是等到第三版。
能经受住增长考验的架构
行之有效的架构形态朴实无华,但值得在早期就把它做对。
将数据采集层与客户层分离。采集以测量单元为键,即关键词加地区加设备加时间戳;客户订阅的是测量结果。正是这种分离使得去重成为可能,也使得速率限制成为一个全局性问题,而非按客户单独处理的问题。
存储完整的结果集,而不仅仅是每位客户自己的排名位置。竞争对手的变动正是让客户自身排名变动具有可解释性的关键,像 AI 概览这样的功能会改变某个排名位置的价值,而你无法回头找回上周二的 SERP 数据。存储很便宜;缺失的历史记录却不然。
采用新鲜度分层调度,而非单一的每日任务。企业账户可能需要早晨交付,自助服务层级可以分散在一天中进行,而这种分散本身就是免费获得的吞吐能力。
明确记录失败情况,因为在多租户产品中,一次数据缺口就会变成一张工单。看起来与稳定日毫无二致的缺失日,是让客户对你自己的数据失去信任的最快方式,相关的管道模式详见自动化每日关键词排名监控。
规模化后真正会出问题的地方
创始人反映的大多数痛点,都源于四种故障模式。
某个市场的无声退化。 某个国家的数据采集停止工作,而仪表盘显示的却是持平的排名,而非错误提示。应通过按市场划分的成功率监控,以及验证抓取到的页面确实是真实的结果页面来加以防范,详见检测被屏蔽或伪造内容。
测量漂移。 默认地区、设备或时间的变化会让所有客户同时出现排名变动,而客服团队无法将其与真实的排名事件区分开来。应将这些参数固定为常量并进行版本管理,详见精准测量关键词排名。
单个账户带来的成本意外。 一位企业客户在二十个地区新增数千个关键词,一天之内就可能让你的采集账单翻倍。应在检查级别进行计量,并对账户级别的增长设置告警。
因分歧引发的客服负担。 客户会将你的数据与另一款工具的数据进行对比,然后开一张工单。解决方案是将你的测量约定文档化,这也正是让你的数据具有可辩护性的关键:明确说明你所使用的地区、设备、语言和个性化模型,因为两款测量方式不同的工具本就应该产生分歧。
应该在哪里竞争
如果数据采集是一个成本中心,那么差异化就存在于它之上的一切:将排名位置转化为洞察的分析能力、声量份额与竞争对手动态、与客户其他技术栈的集成、人们真正愿意发给客户的报表,以及能告诉用户下一步该做什么的工作流程。这些正是客户在解释他们为何留下时会提到的东西,而这些都不会因为自己拥有一个解析器而得到改善。
只有当你产品的价值主张确实包含通用 API 无法做到的事情时,才应该自建数据采集:非常规的数据来源、在采集端进行专有的后处理,或是达到某种规模后经济账会发生逆转。这些情况确实存在,但比”自建冲动”所暗示的要罕见得多。
结论
对于一个以洞察为产品的平台而言,搜索数据是一种输入,而非差异化因素,因此自建还是采购的问题,取决于数据采集是否属于你所销售的内容的一部分。采购能把解析维护、地理覆盖、节奏控制和正常运行时间转化为一次 API 调用;自建则会让这些成为团队的永久责任。无论如何,都应该按每次检查而非每个关键词来核算成本,因为地区数、设备数和频率才是决定你利润率的乘数因子,而且应该在第一版架构中就设计好跨租户去重机制,因为这是可获得的最大节约,也是最难事后补救的部分。将数据采集与客户分离,存储完整的结果集,明确记录失败情况,并将你的测量约定文档化,这样与其他工具之间的分歧就能得到解释,而不至于令人尴尬。
如果采购是答案,SERP API 能提供已解析好的结果,地理覆盖问题也已妥善处理。如果自建是答案,底层的数据采集层就是具备国家和城市定位能力的住宅代理,按每 GB 计费,让你的单位经济模型保持清晰可控。