九市场零售商如何压降价格采集的住宅流量成本

一家中型欧洲零售商带着九个橱窗、18 万 SKU，以及两个季度翻倍的住宅流量账单来找我们。价格采集仍然经常错过竞品真正调价的那个小时，结账探测只要出口地址一变就会丢购物车。这篇案例记录的是那次重建：他们不再把每一条 URL 都当成隐蔽性问题。

价格采集为什么会越做越贵

三种任务挤在同一条住宅池上。

公开目录价的清单扫描。只需要本地税和币种的未登录橱窗核对。必须从商品页一直粘到支付页的结账探测。

住宅出口适合第三种。前两种用它当默认，太贵。团队还对所有请求轮换 IP，包括那些需要亲和性的路径，于是购物车频繁丢失，住宅流量占到了请求量的 78%。

第一个迭代改了什么

按页面真正需要的能力拆，而不是套一个统一的「隐身」预设。

目录走数据中心。 没有会员价的公开列表改走数据中心出口，按主机名限速，只有遇到 403 或质询页才升级到 ISP。这部分量从住宅池里拿掉了。

橱窗观测走 ISP。 可对比的价格序列——同一国家、同一设备类型、同一未登录状态——改从钉在橱窗城市的 ISP 地址出去。记录里保留出口城市、币种、含税标记和促销标签。此前把慕尼黑桌面读数混进柏林移动序列，制造过好几次误报。

结账走住宅粘滞会话。 购物车和支付路径在一次探测内钉住同一个住宅出口，结束后丢掉 cookie 罐。把那个罐拿到另一次、另一个 IP 的访问上复用，正是两家市场封禁他们的原因。

拆法与住宅代理和数据中心代理怎么选、价格监控的配置一致。如何做出可对比的价格管道写的是观测字段；这篇案例写的是账单。

六周后的数字

指标	之前	之后
住宅请求占比	78%	22%
每周住宅流量	410 GB	96 GB
结账探测丢车比例	18%	3%
每周价格误报	40–50	8–12
单次可对比观测成本	基准 100%	39%

目录没有缩。热集的回采节奏仍是两到四小时一次。变的是哪类出口为哪类页面付钱。

两个副作用比发票更重要。定价团队重新信任德法序列，因为观测点稳住了。结账路径上的市场封禁不再成簇出现，变成零星 403，换一条新的粘滞会话重试通常就能过。

我们拒绝做的事

零售商两次要求「为了保险」把全站改回住宅爬取。我们拒绝了。列表页的安全来自规范的请求和对 429 的退避，不是来自家庭 IP。再买住宅流量只会把会话问题再藏一个季度。

我们也拒绝让 cookie 罐跨天存活。会员价是另一类产品：需要账号、稳定指纹和合法依据。公开目录价不需要这些。

可以照搬的做法

如果你自己的价格采集长成这样：

1. 给每条 URL 标任务：目录、橱窗观测，还是结账探测。
2. 先钉观测点再选出入口。国家、设备类型和登录态写进记录，不要写在注释里。
3. 只有 IP 一变就会丢状态的路径，才用住宅粘滞会话。
4. 热集短间隔回采，长尾不要按同样成本打。
5. 在固定观测点上对变化告警，不要对混源的绝对价位告警。

他们仍然跑着九个市场。住宅池现在是稀缺工具，只给真正需要家庭出口的页面用，目录变大时账单才压得住。