电商价格监控的指纹保护
为什么零售商可能按地区、设备和访问历史展示不同价格，以及按上下文隔离的身份如何让监控到的价格保持可比。
为什么不同监控会话看到的价格会变
价格监控团队从零售商处收集公开价格，用来比较不同市场、跟踪促销，并长期核对广告价格政策。只有清楚一个数字代表什么，收集到的价格才有用。从德国网络连接、用桌面浏览器看到的价格，描述的是那个市场和那一类设备，并不代表所有购物者。同一个商品页在两次运行中显示了不同金额时，团队必须判断：是市场变了，是设备类别变了，还是监控会话自身发生了漂移。
零售商调整展示内容通常有几类原因。地理位置最直观：同一商品可能因为访问看起来来自哪个国家，而出现不同的价格、币种、税费处理或运费估算。这些是常见做法，并不是任何具体零售商一定会有的行为，具体采用哪些由零售商自己决定。作为运营方，你的任务不是猜测规则，而是让自己能控制的输入保持稳定，这样观察到的差异才能追溯到原因。
设备类别是第二个输入。有些零售商会向手机和桌面电脑展示不同的版式、促销或仅限应用的优惠，操作系统和屏幕尺寸也可能改变展示内容。如果一次监控在一个地区使用桌面身份，在另一个地区使用移动身份，即使其他设置都正确，得到的数字也无法比较。
访问历史是第三个输入。Cookie 和本地存储让网站能认出回访的访客。视零售商而定，被认出的访客可能看到保存的购物车、会员价、上次访问时选定的地区横幅，或者跳转到上次选择的国家站点。如果一个监控会话在多个零售商或多个地区之间复用存储，在一个市场做出的选择就可能泄漏到下一个市场，悄悄改变收集到的价格。
当会话发送的各项信号互不一致时，也可能被限制或拦截。浏览器报告某国的时区和语言，而流量却从另一个国家出口，这种不一致网站是能注意到的，网站可能的反应包括挑战页、精简页面或直接拦截。与零售商之间的约定不由你改写，这里也不介绍对抗任何防护厂商的方法。实际目标更小：发送彼此一致的信号，让每个被监控的市场保持稳定，并接受零售商给出的结果。
下面的内容都假定你监控的是公开价格，并遵守各站点的服务条款、robots 政策以及适用于你的法律。如果某个零售商禁止自动化采集，正确的做法是申请数据源或放弃该站点，而不是绕着规则设计方案。
每个市场必须保持一致的信号
把一个被监控的市场看作一组应当一起变化的信号。这一组信号只定义一次，并在每次运行中复用，两次运行之间的价格变化才有意义。如果这组信号的一部分在运行之间发生变化，价格的变化可能只是这组信号变化的反映。
- 地区：网络线路的出口位置，以及来自该地的访客通常会有的时区、区域设置和语言列表。
- 设备：浏览器配置文件，它决定网站看到的操作系统、屏幕和硬件身份。
- 历史：会话携带的 Cookie 和存储，应在每次运行开始时为空，或按零售商和地区分别保存。
- 节奏：页面被请求的频率和顺序，这一项由你控制，并受零售商限速的约束。
大多数漂移从地区开始。出口在荷兰的线路、写着纽约的时区、以日语开头的语言列表，在同一个请求里描述的是三个不同的访客。会比较这些信号的网站可能把会话视为异常；不比较的网站也可能只根据其中一个信号来本地化页面，于是你无法知道价格是由哪个信号造成的。解决办法是让时区、区域设置和语言都来自流量实际使用的那个出口，并且对你监控的每个地区分别这样做。
设备遵循同样的规则。有意识地为每个地区选择配置文件，并为该地区一直使用。如果你想知道某个零售商在手机上是否显示不同价格，就为同一个地区另做一次标注清楚的、使用移动配置文件的采集，再比较两条记录，而不是让设备在运行之间意外发生变化。
语言和币种值得在计划中单独列出一行。零售商可能根据浏览器发送的语言列表选择显示语言，也可能根据配送国家或连接所在地区选择币种。如果语言列表说的是一个国家，而出口说的是另一个国家，你可能收到一种语言的页面却配着另一种币种的价格，这会让提取变得脆弱，也让比较失去公平性。为每个市场记录预期币种，遇到意料之外的币种时，先检查线路和地理设置，再决定是否存储。
稳定和正确同样重要。一个身份某次运行匹配得很好，下一次又换成另一种匹配，你得到的两个数据点就无法比较。让每个市场的配置文件、线路和地理设置在运行之间保持固定，想测试某一项的影响时，一次只改一项。改了之后，要把改动记下来。
代理的选择与这些信号相邻，但在你的浏览器配置之外。出口地址的质量和信誉、提供它的服务商，以及有多少其他客户共用它，都会影响零售商如何对待这些流量。BotBrowser 不负责选择或审查代理。请与服务商一起选择并测试线路，并把反复遇到挑战的线路当作需要排查的线路问题，而不是需要调整的浏览器设置。
每个零售商和地区使用一个独立上下文
浏览器上下文是同一个浏览器内部相互独立、类似无痕模式的会话。Playwright 把它描述为拥有自己的 Cookie 和本地存储的隔离环境，因此一个浏览器可以承载许多互不看到对方状态的独立会话。对价格监控来说，这种隔离正是你想要的：德国零售商 A 的上下文看不到日本零售商 B 的 Cookie，在一个上下文中保存的地区选择也不会改变另一个上下文收集到的价格。
存储的隔离本身并不会隔离网络身份。共用同一条代理线路的两个上下文仍从同一个地址出口，共用同一个配置文件的两个上下文仍呈现同一个设备。BotBrowser 的按上下文代理支持弥补了这个缺口。每个上下文可以有自己的代理线路，BotBrowser 会根据该上下文代理的出口，独立推导出该上下文的时区、区域设置和语言。经由德国出口的上下文得到德国的地理设置，同一浏览器中经由日本出口的另一个上下文得到日本的设置，彼此互不泄漏。
const client = await browser.target().createCDPSession();
const ctx = await browser.createBrowserContext({ proxyServer: region.proxy });
await client.send('BotBrowser.setBrowserContextFlags', {
browserContextId: ctx._contextId,
botbrowserFlags: ['--bot-profile=' + region.profile],
});
const page = await ctx.newPage();
await page.goto(region.url);
操作顺序很重要。创建上下文时设置代理线路，在第一个页面出现之前应用按上下文的标志，并等待代理和地理设置更新完成之后再让页面导航。过早启动的页面可能先用启动时的设置，这样你记录下的第一个价格就属于错误的身份。如果你已经知道某条线路的出口地址，并用 --proxy-ip 声明它，请按按上下文代理文档的说明，在创建上下文时与代理线路一起提供。
没有自己代理线路的上下文，会继承启动时的线路和启动时的地理身份。这对单市场运行很方便，对多市场运行却是个陷阱，因为忘记设置的线路会悄悄沿用另一个地区的身份。为每个被监控的地区指定明确的线路，并核对记录中列出的线路标签是否就是你分配给每个上下文的那一个。
你显式设置的地理参数会针对每个上下文、每个设置分别解析，保持自动的设置会继续跟随该上下文的代理出口。实际操作中，当出口已经与市场一致时，让时区、区域设置和语言保持自动；只有在有理由时才显式设置其中一项，例如某个市场的购物者使用的语言不同于出口国的默认语言。把显式设置的值写入记录，方便以后的读者知道这是有意为之。
每个上下文还可以在自己的代理之外加载自己的配置文件。用它让每个市场的设备类别保持稳定，并在记录中保留配置文件名。按上下文代理属于 ENT Tier3 许可的功能，因此在围绕它设计监控布局之前，请先确认你的许可涵盖它。如果没有，就改为每个地区运行一个浏览器实例，这样资源开销更大，但同样能保持隔离。
相关配置可参阅：按浏览器上下文分配代理：独立工作的路由归属说明如何把线路分配给上下文，时区、区域设置和语言指纹指南说明地理设置如何推导与覆盖。
记录按地区收集的价格
没有采集设置的价格，是一个无法为之辩护的数字。请在每个观察到的价格旁边保存产生它的设置。这样，两个地区之间的差异可以归因于地区或设备，同一地区两次运行之间的差异可以归因于零售商，而不是你自己会话的漂移。
{
"region": "de",
"retailer": "retailer-a",
"profile": "profile-windows-de",
"proxyRoute": "route-de-01",
"timezone": "Europe/Berlin",
"locale": "de-DE",
"languages": "de-DE,de,en-US,en",
"finalUrl": "https://retailer-a.example/de/product/123",
"collectedAt": "2026-10-02T09:00:00Z",
"currency": "EUR",
"observedPrice": "49,90"
}
记录使用线路和配置文件的标签，而不是代理地址和凭据。把地址和密钥放在你的密钥库中，并通过标签引用，这样共享的价格表就不会带着密码。同时记录币种和最终页面地址：区域跳转把会话带到另一个国家的站点，是出现意外数字最常见的原因之一，只有保留最终地址才看得出来。
使用这些记录时，要拿同类比较，并且一次只改变一个变量。
- 用同一个配置文件，从同一个地区两次采集同一商品，并确认两条记录一致。如果不一致，先排查线路或零售商，再下任何地区性的结论。
- 用同一个配置文件，从两个地区采集同一商品，在第一项检查稳定之后，把差异归因于地区。
- 在同一个地区用两个配置文件采集同一商品，把差异归因于设备类别。
- 在配置文件更新、线路变更或浏览器版本更新之后重复每项检查，并保留更早的记录用于比较。
留意每一步控制了什么。第二步保持配置文件不变，只有地区不同；第三步保持线路不变，只有设备不同。如果采集计划同时改变两者，就无法把结果归因于任何一个。当一个数字看起来不对时，记录会告诉你应该先隔离哪个变量。
要像购物者那样，从渲染后的页面读取价格；如果之后可能需要审计，就把截图和记录放在一起。有些价格在首次显示之后才加载，有些页面要求购物者先选择尺码、款式或配送国家才显示价格。请等待价格元素出现，而不是在首个加载事件触发时就读取页面，并记录选中的款式和配送国家，因为某个款式的价格不等于该商品的价格。
保持适度而稳定的计划。零售商有自己的限速，短时间内发出大量请求的采集，无论浏览器身份看起来如何，都会招来你想避免的对待。从能回答你问题的最低频率开始，把请求分散到不同时间，只有在零售商公开的政策允许时才提高频率。变化快的品类和促销期可能需要更频繁的检查，平稳的品类则很少需要。
扩大布局时，记录也要随之扩大。监控多个零售商、多个地区的部署，应当每次运行为每个上下文生成一条记录，并由同一段代码写入，使表格保持统一。监控任务本身的容器化部署，请参阅Docker 浏览器自动化：部署与扩展指南。
BotBrowser 能做什么，不能做什么
BotBrowser 支持为每个浏览器上下文使用独立的代理线路，并根据各上下文代理的出口独立推导时区、区域设置和语言，使每个被监控的零售商或地区都能保持隔离且地理一致的身份。对价格监控团队而言，这意味着一个市场的地理和设备信号不会混入另一个市场，记录中的价格差异可以追溯到地区或设备，而不是监控会话的漂移。BotBrowser 不能保证零售商展示真实购物者看到的价格或允许访问，不能选择或审查代理质量和 IP 信誉，也不能替代行为、限速和服务条款方面的合规。
一致的身份和隔离，提高的是你收集到的价格的可比性。它们并不保证零售商展示与真实购物者相同的价格，不保证你的会话不被拦截，也不保证验证码或机器人管理服务不会出现。如果零售商决定挑战某个会话，这个决定属于零售商；把挑战当作要击败的障碍的团队，会把时间花在错误的问题上。把挑战当作信息：放慢速度，检查线路，并考虑该站点是否根本不希望被自动访问。
代理质量、IP 信誉、请求频率和行为，都在 BotBrowser 的控制之外。由运营方选择服务商，验证出口地址确实位于目标国家，并决定每条线路承载多少请求。新线路在支撑正式计划之前，先用少量无害的低频采集测试，并在记录中保留线路标签，这样出现问题时可以追溯到某个服务商或某条线路。
合规与配置是两个独立的步骤。监控某个零售商之前，先阅读它的服务条款和 robots 政策，核对适用于你的采集行为和数据使用的法律，并保留这一决定的记录。条款禁止自动化采集时，请申请许可或数据源。技术上一致的身份不会让被禁止的采集变得被允许，这里的任何配置也不会改变这一点。
准备落地时，从最小可用的版本开始：一个零售商、两个地区、一个配置文件，以及上面所示的记录。确认两个地区的记录只在零售商确实有差异的地方不同，然后一次增加一个零售商或一个地区。线路设置和凭据格式请参阅浏览器代理配置：SOCKS5、HTTP 和 HTTPS 指南。