动态定价常被当作一个算法问题来讨论。选一个弹性模型，设置一些护栏，让它自行优化。
但在实践中，出问题的很少是算法本身。出问题的是算法下面的数据源。一个基于陈旧数字、错配商品或从错误市场采集来的观测值运作的调价器，会做出一个自信、快速、但错误的决策，而且它会在每个周期都重复这个错误，直到有人注意到利润率的变化。
因此，思考一个竞品价格数据源的正确方式，不是把它当成一个填表格的抓取任务。而应把它看作一个测量系统，带有新鲜度保证、置信度评分，以及一个安全层，用来决定定价引擎何时才被允许据此采取行动。
“实时”实际上应该意味着什么
“实时”是一个营销词汇。真正的运营问题更具体：一个观测值可以陈旧到什么程度，才不再适合用于定价？
这个数字并不是通用的。它取决于你的竞争对手实际移动的速度有多快，而这是可以测量的，不需要靠猜。在变化缓慢的品类中，竞争对手的价格可能维持数周不变，此时每日一次的数据源实际上就已经足够”实时”。而在双方都使用自动调价器的激烈竞争品类中，一个四小时前的观测值可能已经失效。
由此得出两点。
按波动性而非按营收给你的商品目录分层。 直觉上会倾向于最频繁地刷新畅销商品。但正确的规则是刷新变化最频繁的商品，这与畅销商品有重叠，但并非同一集合。一个变化缓慢的高营收商品不需要每小时采集一次。
存储观测时间，让使用方自行判断。 数据源中的每一行都应携带其被观测的时间。定价引擎应用自己的陈旧度阈值，而不是相信表中的一切都是最新的。这一个决定就能防止延迟采集所造成的大部分损害。
按顺序排列的处理流程
match -> collect -> validate -> normalise -> score -> serve人们常常跳过的阶段是 validate（校验）和 score（评分），而正是这两个阶段让数据源变得安全。
匹配先于一切
一个把不同商品错误匹配在一起的价格数据源，比完全没有数据源产生的决策更糟，因为它是带着自信做出这些错误决策的。
优先使用标准标识符进行匹配，如存在的话，GTIN、UPC、EAN 或 MPN，其次是标准化后的品牌与型号，再其次是属性。包装规格是典型的陷阱：一个六件装和单件商品几乎共享所有属性，通常标题也相同，如果对错了对象进行定价，会让你的价格朝着完全错误的方向移动。
每一对匹配结果都应携带一个置信度评分，低置信度的匹配对即使足够用于人工查看的仪表盘，也应被排除在自动调价之外。关于匹配问题更完整的讨论见 竞品品类与目录缺口分析。
采集完整的报价，而不仅仅是数字
展示出来的价格只是一个更大报价中的一个字段，仅凭它来定价，往往会导致你去压低一个实际上从未真正更便宜的竞争对手的价格。
要采集价格、任何划线价或参考价、配送费用和门槛、库存状态、卖家身份，以及任何标签或促销文案。一个价格相同但包邮的竞争对手，实际上更便宜。一个缺货的竞争对手，这一小时内根本不算竞争对手。一个第三方市场卖家，通常也不是你的定价委员会所指的那个竞争对手。
促销活动值得单独处理，因为大多数改变顾客实际支付金额的机制，根本不会体现在价格字段中。这部分内容详见 追踪竞争对手促销与折扣周期。
在进入数据源之前校验，而不是之后
每一条观测值在被允许进入表格之前，都应通过一组低成本的检查：
- 页面是否渲染为商品页面，而不是验证页面、跳转页面或软 404？
- 请求是否从该行所声称的市场出口？
- 该价格相对于该商品近期历史是否处于合理区间内？
- 货币是否与市场相符？
- 页面上的商品标识符是否就是我们所请求的那个？
区间检查能捕获代价最高的一类错误。一夜之间波动 60% 的价格，偶尔是真实的，但通常是解析失败、货币混淆或捆绑套装页面所致。应标记这类数据，将其排除在自动定价之外，交由人工确认。
评分置信度，然后再提供服务
数据源与定价引擎之间的约定应当明确：这是价格，这是它被观测的时间，这是市场，这是我们对它的置信程度，这是你是否可以据此自动采取行动。
对大多数团队而言，一个简单的三态信号就足够了：自动执行、提交人工查看，或忽略。置信度综合了匹配质量、观测时长、校验结果以及该商品近期的波动性。
地理位置是价格的一部分
同一个竞争对手的页面，在不同市场可能显示不同的价格、不同的配送选项和不同的库存状态。一个从单一视角采集、却被用于多个市场定价的数据源，实际上是在悄悄地把一个国家的竞争格局，套用到所有市场中。
这正是采集层不再只是实现细节的地方。带国家定向功能的 住宅代理 可以让每个市场的数据源真正来自该市场。使用 Shifter 网关时，定向与会话信息写在针对 p.shifter.io:443 的凭据中：
customer-USERNAME-country-de-sid-feed-de-08-ttl-600:PASSWORDcountry-de 设定市场，sid-feed-de-08 在一次品类遍历过程中保持同一个出口，使单次快照内的价格彼此保持一致，ttl-600 则让该地址保持十分钟。在抓取过程中途轮换，正是两个市场的价格混入同一份快照的原因。
保持适度的并发量，遇到错误时应回退，而不是硬闯，做法参见 速率限制与请求节流。一个会触发防护机制的数据源，最终会变成一个带有缺口的数据源，而定价数据源中的缺口并非中立的：它们会系统性地偏向那些最难采集的商品和时段。
安全层
自动定价需要独立于模型之外的刹车机制，因为模型的合理性完全取决于其输入数据的合理性。
每件商品的价格上下限。 成本加成的下限与最大折扣上限，应在模型之外强制执行，而不是在模型内部。
变动幅度限制。 限定价格在一个周期内和一天内可移动的最大幅度。由一个有问题的数据源驱动的、看似正确的一连串小幅调整，仍然可能构成一场逐底竞争。
覆盖率门槛。 如果本周期内返回有效观测值的被追踪竞争对手比例低于设定阈值，则不应调价。基于稀薄样本进行调价，比按兵不动更糟。
一个熔断开关，以及一个明确的责任人。 自动定价的故障会迅速累积放大。能够一键冻结所有自动调价动作，并且有一个明确指定的负责人，这不是可选项。
需要注意的是，覆盖率门槛依赖于对你自身采集情况的测量，而不仅仅是价格本身。应使用 测试代理速度、成功率与地理位置准确性 中的方法，逐竞争对手、逐周期地追踪成功率，并与数据源本身一并监控。当利润率发生变化时，第一个要问的问题是市场变了，还是你的覆盖率变了。
上线后应监控什么
一个价格数据源会悄无声息地退化。以下四项指标能及早发现问题：
| 指标 | 它告诉你什么 |
|---|---|
| 新鲜度分布 | 各市场中，落在其陈旧度阈值内的商品目录比例 |
| 采集成功率 | 按竞争对手和市场划分，使单个失败目标可见 |
| 匹配置信度分布 | 低置信度匹配对的比例是否正在上升 |
| 校验拒绝率 | 拒绝率上升通常意味着某个网站改变了其页面标记，而不是价格出现了异常 |
应对变化幅度（delta）而非绝对水平设置告警。一夜之间翻倍的校验拒绝率，是一个你希望在定价引擎对通过校验的数据采取行动之前就了解到的解析器问题。
常见问题
竞品价格数据源应该多久刷新一次？
应比你的竞争对手在重要商品上的变动速度更快，而这一点应通过测量而非假设来确定。按观测到的波动性对商品目录分层，并将采集预算投入其中。
第三方市场卖家应该纳入数据源吗？
应追踪他们，但将其作为单独的一个系列保留，并有意识地决定是否将其纳入定价逻辑。将自营与第三方市场的报价混在一起，会产生一个实际上没有人在与之竞争的”竞争”图景。
导致自动定价出错最常见的原因是什么？
商品错配，其次是把陈旧的观测值当作最新数据处理。这两者都可以通过数据源本应携带的字段来防止：匹配置信度和观测时间戳。
我需要为每个国家单独建立一个数据源吗？
按市场划分，是的，且应从该市场本地采集。一个在多个市场间复用的数据源，只在其采集所在的国家是准确的，在其他地方会逐渐失真。
结论
一个动态定价系统，本质上是一个附加了决策层的测量系统，而它的大多数故障都出在测量这一半。先匹配再采集，采集完整的报价而不仅仅是数字，在每条观测值落地之前进行校验，为每一行数据附加新鲜度和置信度，并让定价引擎在数据源不足以支撑决策时拒绝采取行动。
从每个市场本地采集该市场的数据，在一次快照中保持会话的一致性，并像监控竞争对手一样密切监控你自身的覆盖率。这项工作的产品视角见 用于价格监控的住宅代理 页面，费率见 定价页面。