大多数代理机构的代理配置都是偶然形成的。SEO 团队为排名追踪购买了一种工具。付费媒体团队为检查广告又找了另一种工具。某位策略师为提案拉取竞争对手定价,注册了第三种工具。三家供应商,三套集成,三套位置代码,三份账单,却无法回答一个简单的客户问题:当我们的 SEO 报告和广告报告都写着”马德里”时,它们指的是同一个地方吗?
这正是整合到单一网络的理由。不是因为这样更便宜(虽然通常确实如此),而是因为这三类工作本质上在问同一个潜在问题:这个市场中的真实用户看到了什么,而它们理应以相同的方式来回答这个问题。
三种工作负载,三种流量形态
这三类工作都需要本地落地点,但在几乎其他所有方面都有所不同。理解这些差异,正是让单一网络能够同时服务三者的关键。
SEO 监测是高频量、轻负载的。大量独立查询,每次请求都很小,都需要精确的位置和设备画像,并且彼此独立。它需要每次请求都轮换 IP,以及城市级别的定向,因为本地结果的变化粒度比国家级别更精细。具体机制见面向本地 SEO 的地理定向 SERP API。
广告验证是低频量、重负载的。检查次数较少,但每次都是从展示到落地页的多步骤流程,通常需要在浏览器中渲染,并且从头到尾都需要一致的地区信号。它需要粘性会话,以及连贯一致的设备和语言设置。具体项目设计见大规模验证广告投放。
竞争情报介于两者之间。类目浏览、分页结果集、落地页和优惠信息,每一步都需要在一系列请求中保持内部一致性。它需要按浏览路径保持粘性会话,以及适度、稳定的请求节奏。详见竞争性广告情报监测。
| 工作负载 | 会话模式 | 单次检查负载 | 关键定向维度 |
|---|---|---|---|
| SEO 监测 | 每次请求轮换 | 轻量 | 城市与设备 |
| 广告验证 | 按流程粘性 | 重量级,常需渲染 | 国家、城市、地区一致性 |
| 竞争情报 | 按浏览路径粘性 | 中等 | 国家,有时含城市 |
为什么单一网络优于三个网络
统一的定向模型。 当三类工作都以相同方式表达位置信息时,关于马德里某客户的发现在 SEO 报告、广告报告和竞争情报简报中就意味着同一件事。而使用三家供应商时,你需要协调三种可能并不一致的”马德里”定义,一旦客户察觉,就会追问原因。
只需维护一套集成。 每家供应商都意味着一种凭证格式、一套错误术语、一组定向代码和一份支持关系。整合消除了这些无人买单的额外工作。
可比的落地点。 当 SEO 团队发现某本地竞争对手崛起,而付费团队也发现同一个竞争对手在同一座城市加大竞价力度时,这两项观察来自可比的出口节点,因此可以并列对照,而不必各执一词。
集中掌握支出情况。 住宅带宽是成本的主要驱动因素,当三类工作都以同一单位在同一个仪表盘上衡量时,预测起来要容易得多。具体方法见住宅代理带宽预测。
借助 Shifter 网关,三类工作负载都使用同一个端点 p.shifter.io:443,它们之间的差异完全通过凭证来表达:
# SEO:每次请求轮换,城市级别
customer-USERNAME-country-es-city-madrid:PASSWORD
# 广告验证:整个流程使用同一个出口
customer-USERNAME-country-es-city-madrid-sid-adv-221-ttl-600:PASSWORD
# 竞争情报:每次类目浏览使用同一个出口
customer-USERNAME-country-es-sid-ci-walk-09-ttl-600:PASSWORD
# 以上任意一种,计入共享套餐下某一客户的用量
customer-USERNAME-subaccount-acme-country-es-city-madrid:PASSWORD省略 sid 即为每次请求轮换 IP。添加 sid 则保持同一出口,而 ttl 设定保持时长。正是这一个差异,让单一网络无需三套配置就能服务这三种流量形态。subaccount 标签紧跟在用户名之后,用于告知面板该流量属于哪个客户。
对于 SEO 这项工作而言,值得考虑用 SERP API 作为自行管理请求的替代方案,因为它返回的结构化结果已经处理好了位置和设备信息。
区分客户
整合工作负载是对的。但把客户不加区分地混入同一个池子里则不然,原因有三。
成本归属。 客户是按工作量计费的。如果每个客户的采集工作都运行在同一个套餐下,却没有任何标识区分客户,你就无法说清每个客户的实际成本,按客户核算利润也就成了猜测。在共享套餐下为每个客户设置子账户即可解决这一问题:面板和 API 会分别报告每个客户的流量。
预算控制。 一个客户的活动流量激增,不应消耗另一个客户报告工作所依赖的额度。子账户会追踪流量但不会设置上限,因此流量较大或不可预测的客户应该拥有自己独立的套餐。
干净利落的下线流程。 当某个客户离开时,其访问权限、套餐和历史记录应随之一并移除,不影响其他任何人。
在 Shifter 上,每个客户可以拥有自己独立的套餐,也可以在共享套餐下拥有自己的子账户。如果某客户需要独立计费,或希望查看自己的用量,还可以为其建立独立的工作区,拥有自己的套餐、钱包和账单,而代理机构的账户负责人可以作为成员加入该工作区,使用同一个登录账号,并通过侧边栏的切换器进行切换。套餐永远不会跨工作区共享。具体设置流程见面向多客户的子账户与用量追踪。
在每份客户交付物中记录落地点信息
单一网络的实际价值只有在报告中体现出来才算真正落地。每一条呈现给客户简报的观察结果,都应标注市场、相关城市(如适用)、设备画像和时间戳。这样一来,三个专业领域的数据就可以在同一场对话中相互印证,一旦某个数据有争议,也能准确追溯到其观察的具体来源。
这也是能”展示数据”的代理机构与能”捍卫数据”的代理机构之间的区别。当客户问”你们是在哪里看到这个的?”时,应该能在几秒钟内给出答案。
常见问题
某个客户的高强度爬取会影响另一个客户的结果吗?
出口节点是在整个池中轮换分配的,而非固定分配给某个客户,因此不存在某个客户可以用尽的固定地址集合。真正共享的是行为方式:一个被过度使用的地址,对下一个使用到它的人来说情况会更糟,因此应保持每个客户的请求频率处于正常水平。预算是另一项共享资源,这也是为什么每个客户都应拥有自己独立套餐的原因。
单一网络足以覆盖每个市场的每个客户吗?
对大多数代理机构而言,是的,前提是该网络覆盖了你客户所在的国家和城市,并达到你 SEO 工作所需的粒度。在整合之前,请先核实你主要市场中的城市级别覆盖情况。
SEO 团队应该使用代理还是 SERP API?
如果团队想要结构化结果且无需管理请求,选择 SERP API。如果需要观察 API 未覆盖的页面,或者希望拥有完全控制权,则选择代理。许多代理机构两者都会使用。
我们该如何对客户的采集工作计费?
为每个客户设置独立套餐,或在共享套餐下设置独立子账户,并据此用量计费。面板和 API 会按套餐和按子账户分别报告用量,这正是实现客户级别成本归属清晰化的关键。
结论
代理机构同时运行着三类采集工作负载,它们在会话模式、负载量和定向方式上各不相同,却共享同一个问题:这个市场中的真实用户看到了什么。用单一网络和统一的定向模型来回答这个问题,能让这三个专业领域具备可比性,减少两套集成的维护负担,并将支出统一到同一个计量单位之下。
整合工作负载,而非整合客户。让每个客户拥有各自的套餐或子账户,并在计费需要时拥有各自的工作区,在每份交付物中记录落地点信息,让凭证本身(而非供应商)来表达 SEO 检查与广告流程之间的差异。产品详情见住宅代理页面,费率信息见定价页面。