旅行是最难准确采集的定价垂直领域，而且遥遥领先。零售商品页上的一个价格，多多少少是个事实：它对一个给定市场里的所有人都一样，而且变得很慢。一张机票票价则一样都不是。同一趟航班上的同一个座位，可能因你从哪里购物、你用哪种货币、你之前是否搜索过，以及航空公司的收益系统在过去几分钟里作了什么决定，而被报出不同的价格。酒店房价的行为也类似。
对一支票价聚合或旅行情报团队而言，整个问题就是一句话：一个购买者看到的票价，取决于供应商认为他是谁、在哪里。 从一个办公室 IP 去采集这些数据，你得到的不只是一幅片面的图景，你得到的是错误的票价，报给了一个你并不身处的市场。这是对为什么旅行票价聚合需要代理所涉内容的一次更深入处理，聚焦于让住宅代理成为机票与酒店数据正确访问层的那些机制。
你在采集什么
旅行数据采集横跨几个相关的界面：
- 机票票价 —— 按航线、日期、舱位和票价等级的价格，加上可得性、票价规则和附加服务（行李、座位），覆盖各航空公司以及转售它们的 OTA 和元搜索引擎。
- 酒店房价 —— 按物业、日期、房型和入住人数的每晚价格，加上可得性和取消条款。
- 租车与套餐 —— 同样的形态，按地点和日期定价。
共同的主线是，这里的每一项，都是在一个特定时刻、报给一个特定市场里的一个特定购买者的，这正是它是一个访问问题的原因。
为什么旅行以一种独特的方式成为一个代理问题
零售抓取只有一个地理维度。旅行有四个会叠加的特性，而这四个都落在代理层上。
1. 票价是按销售点（POS）定价的。 这是它的决定性特征。航空公司和 OTA 会按销售点，即购买者从哪个市场预订，对同一条行程给出不同的价格。一趟纽约往返伦敦，从美国销售点预订，与从英国或印度销售点预订相比，可能带着不同的票价、以不同的货币计。这不是一个边角情形；它是这门生意的核心，也是跨市场票价比较之所以存在的原因。要捕获一个购买者在某个给定市场里真正看到的票价，你必须看起来身处那个市场，也就意味着一个位于那里的住宅 IP（国家与城市级定位）。
2. 票价是基于会话的。 一次票价搜索不是一个请求，而是一个流程：搜索、结果、选择行程、确认价格。供应商在那个会话内报价并锁价，而一次流程中途的身份切换，看起来完全不像一个真实购买者。这正是为什么粘性会话对旅行而言并非可有可无，而不像在别处仅仅是方便（粘性 vs 轮换）：整个票价流程必须来自一个一致的身份。
3. 票价是易逝的。 收益管理系统在不停地重新定价，而可得性是实时的，所以你一个小时前采到的一张票价，可能已经错了。新鲜度是一项一等的要求，这意味着持续的、高容量的采集，而不是周期性的扫荡。
4. 旅行防守极其激进。 航空公司盯着它们的”看转订比”（look-to-book），即每一次真实预订所对应的搜索次数，并把高容量、不转化的搜索流量当作一项成本和一种威胁。GDS 系统、OTA 和元搜索引擎，都跑着严肃的反机器人。一个数据中心 IP 会被很快标记，得到一个 CAPTCHA、一次封锁，或者最糟的：一个不同的票价，于是你记录到的是一个没有任何真实旅客会被报到的价格（为什么爬虫会被封）。
合在一起看：要准确地采集旅行数据，你需要看起来像一个真实购买者、身处正确的市场、守着一个一致的会话、在规模上、持续地。这就是一个形如住宅代理的问题。
住宅代理在哪里契合
住宅代理把你的请求经由真实的消费者 IP 路由，于是旅行供应商给你报价的方式，就如同给一个真正的本地购买者报价。具体而言：
真正的销售点票价。 借助定位到你所需国家的地理定位，你以一个真正从那个销售点预订的购买者身份去采集票价，美国的票价来自美国，德国的票价来自德国，每一份都按市场标注。你的跨市场比较，终于建立在真实的按销售点价格之上，而不是一个被外推的单一位置。
真实的票价，而非机器人版本。 住宅 IP 带着真实用户的信任，所以你捕获的是真实报出的价格和可得性，而不是给可疑流量的那个降级、被封或加了 CAPTCHA 的响应。对旅行而言，“机器人票价”可能是一个确实不同的数字，所以这就是可用数据与噪声之间的区别。
会话一致的采集。 在一个票价流程的时长内保持一个粘性会话，好让搜索、选择和价格都来自一个身份，这既是供应商所期待的，也是让报价保持连贯的前提。在搜索之间轮换到一个新鲜身份，而不是在一次搜索之内。
完整、新鲜的覆盖。 一个庞大的轮换池，让你可以持续地跑众多航线、日期和市场，而不会有少数几个 IP 触发速率限制，这正是让易逝的票价数据保持最新、而非过时的关键（与用于数据采集的住宅代理中相同的采集质量原则）。
它是如何运作的
在 Shifter gateway 上，你通过把国家编码进代理用户名来定位一个销售点，一个端点，没有 IP 列表：
# 以一个从美国预订的购买者身份采集票价curl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://fare-source.example
# 同一条航线，从英国销售点定价curl -x customer-USERNAME-country-gb:PASSWORD@p.shifter.io:443 https://fare-source.example有两条旅行特有的实践，比这套机制本身更要紧。第一，让语言环境和货币与销售点对齐，一个英国销售点的请求，却发一个美国语言环境或要求 USD，是一个会产出错误或被封结果的不一致；把 Accept-Language 和站点的货币选择，都与那个市场相匹配。第二，在整个票价流程中保持一个粘性会话，做法是在用户名里加上 -sid-<id>-ttl-<秒>，好让这一多步搜索留在一个 IP 上。持续（而非偶尔）的封锁，指向的是 IP 质量或请求行为，见如何避免被封；而池的质量塑造着你被报到什么（IP 信誉）。
先考虑经许可的来源，并负责任地采集
在旅行领域，有两件事尤其值得强调。
在官方渠道够用的地方就用它。 许多航空公司、酒店集团和 OTA 提供 API、联盟数据源（affiliate feeds）或 GDS 接入。在一个经许可的数据源能覆盖你需求的地方，它就是更好的第一站，稳定、结构化、且被允许。代理用于这些渠道之外的公开票价数据，或用于单一数据源给不了你的、跨市场和跨供应商的广度。在 API 够用的地方从 API 开始，只是更好的做法。
留意看转订比。 旅行供应商对不转化的搜索量异常敏感，因为每一次搜索对他们都有真实成本。以合理的节奏采集、别猛击某个供应商、遵守条款和速率限制，并采集公开的票价数据、而不是任何在认证之后的东西。这既是良好公民行为，也是自我保全：激进的采集，正是会让一个来源升级其防御的东西。彻底远离个人数据，并对任何不确定的事项获取法律意见（网络抓取合法吗）。代理改变的是一个请求从哪个 IP 发出，而不是你是否应该发出它；我们的可接受使用政策是 Shifter 上何为允许的权威依据。
常见问题
我为什么需要代理来获取机票和酒店数据？ 因为票价是按销售点定价的，同一条行程会因你从哪个市场预订而花不同的钱，而供应商对自动化访问严防死守。从一个位置出发，你看到的是一个市场的票价，往往还是机器人版本。住宅代理让你采集到每个市场里一个购买者真正被报到的真实票价。
什么是按销售点定价？ 航空公司和 OTA 会按购买者从哪个市场预订，即销售点，对同一趟航班给出不同的价格。这正是为什么同一个座位从美国和从英国出发，会花不同的钱（且以不同的货币计），也是为什么准确的票价数据必须按市场采集。
旅行数据我需要粘性会话吗？ 通常需要。一次票价搜索是一个多步流程（搜索、选择、价格），而供应商在一个会话内报价，所以这个流程应当来自一个一致的 IP。为流程使用一个粘性会话，并在搜索之间轮换，而不是在一次搜索之内。
我该改用航空公司或 OTA 的 API 吗？ 在一个经许可的 API、联盟数据源或 GDS 接入能覆盖你需求的地方，该用，它稳定且被允许。代理用于这些渠道之外的公开票价数据，或用于单一数据源提供不了的跨市场广度。在 API 够用的地方从 API 开始。
旅行票价该用住宅代理还是数据中心代理？ 住宅。旅行供应商会激进地检测并封锁数据中心 IP，还可能给它们报一个不同的票价，所以数据中心给你的是一个错误或被封的结果。住宅 IP 看到的是一个真实购买者会看到的、真实且按销售点精准的票价。
底线
旅行票价数据之所以独特地难，是因为它同时是按销售点定价的、基于会话的、易逝的，且受到重重防守。一个票价聚合产品的准确度，完全取决于你是否以一个从那个市场预订的真实购买者身份、守着一个连贯的会话、以数据所要求的新鲜度，去采集每一个市场的票价。在经许可的数据源合适的地方用它，其余的经由与销售点相匹配的住宅 IP 路由，让语言环境和货币对齐，并在每一个票价流程中保持一个粘性会话。
做到这些，你拿到的就是旅客真正被报到的票价，按市场分列，而不是一个不描述任何真实预订的混合数字。一个优质的住宅代理网络，就是让这份采集按销售点精准且完整的关键；定价页面有按 GB 计费的套餐，可以拿它对着你产品所依赖的航线、物业和市场试用。