移动代理零售数据
零售数据是商业领域中始终未脱离实体世界的一部分：即今天某家特定商店货架上实际陈列的商品及其具体价格。其中绝大多数数据都受限于邮政编码和本地访客的限制。
- 库存数量按门店计算，而非按网站计算 — 库存查询接口的响应结果针对具体分店，且必须指定具体门店位置才能返回结果。
- 邮政编码是查询内容的一部分——如果没有邮政编码，大多数杂货店和连锁店都不会显示任何有用的信息。
- 促销活动具有区域性 ——同一连锁品牌在同一国家的不同地区会推出不同的优惠活动。
- “每日”才是合适的节奏 ——货架每天都会变动，而门店终端并非为持续轮询而设计。
像附近的顾客那样查询库存情况。
查看仅在零售商应用程序中才有的库存和优惠。
网站之外的零售数据
零售数据是商业领域中从未转向线上的部分。它描述的是实体商店：特定分店货架上今天摆放着哪些商品，价格是多少。其分析单位是门店而非商品目录，而且几乎所有有价值的信息都与具体门店位置紧密相关。
这便形成了一种特定的访问模式。可用性端点、“点击自提”时段和本地定价均取决于具体门店，因此零售商在提供任何信息前，都会先询问您的位置。 如果提供国外地址的邮政编码，往往只能得到不完整的回答或被拒绝，这就是为什么本地出口和本地邮政编码必须配合使用——单独使用其中任何一项，通常都会产生看似正确但实际上有误的数据。
| 各门店情况各不相同 | 为什么 |
|---|---|
| 库存与供货情况 | 实物库存存放在一栋大楼里，而不是在网站上 |
| 价格 | 当地竞争、店铺业态和区域成本都会影响这一结果 |
| 促销活动 | 连锁企业开展的地区性宣传活动从未在全国范围内亮相 |
| 范围 | 店铺规模决定了其销售的商品种类 |
| 收纳格 | 容量按分支计算，且会随一天中的时间变化 |
首先查找商店标识符
每个门店级端点都需要一个 store_id，而零售商自有的门店定位器通常是唯一能将邮政编码映射到 store_id 的地方。定位器查询通常接受邮政编码或经纬度坐标对以及半径参数，并返回该半径范围内的分店及其内部标识符。 在开始任何库存或价格采集之前，必须先在同一市场内部执行一次该调用，因为门店会随着时间推移而新增、关闭或重新编号——过时的 store_id 会导致查询结果显示“门店不存在”而非“缺货”，这种故障模式很容易被误认为是商品本身已下架。
门店库存与供货情况
零售数据中最有价值的指标，恰恰是零售商们从未公开过的：某款产品在特定门店实际缺货了多长时间。库存状况快照虽司空见惯，却几乎毫无参考价值。 缺货时长才能真正反映供应可靠性、分销环节的失误以及需求激增的情况——就像房地产领域的“在市时间”一样，只有通过持续的数据收集，才能获得这一指标。
store_id … postcode_area … product_id … in_stock true | false | limited observed_at 2026-08-24T09:14:02Z market GB price … # per store, not per chain promotion … # regional campaigns show up here
数据采集应保持每日一次的频率。库存状况和促销活动正是按照这种节奏更新的，而过快的采集反而会增加“噪音”而非“有效信息”——比如某款商品在11点缺货、3点又补货，这种情况根本无法让人做出有效反应。此外，门店级终端设备相对脆弱，原本就未设计用于持续轮询，这也是在此情境下保持耐心大有裨益的第二个原因。
用假股票代替大宗交易
检测到机器人的门店端点并不总会返回403状态码。有些端点会悄然返回缓存或默认响应——通常是各分店均有库存的状态——因为这种响应最不容易引发客服工单。这比直接封禁更糟糕，因为数据收集仍在继续，系统表面看起来运行正常，而背后的数据却毫无意义。 关键线索在于数据波动：如果某个地区的每家门店库存状态都永久显示为“有货”，且没有任何分店显示“库存有限”或“缺货”，这更可能是系统检测后的响应，而非真实的零售运营状况。通过抽查几家分店，并与用户在应用中实际看到的库存情况进行比对，是及早发现此类问题的唯一可靠方法。
网站与应用程序的端点
一些连锁店仅通过移动应用的API（而非公开网站）来查询库存和“点击自提”的时段可用性。 由于通常假设只有零售商自家的应用会调用该接口，因此应用端点的安全防护往往较弱，但它期望收到符合移动端特征的响应信号：移动用户代理、应用版本标头，以及源自运营商IP而非数据中心IP范围的流量。 将应用API视为一个独立的、并行的数据源，而非网站的备用方案，通常是一种更有效的思路，因为即使对于同一家商店在同一天的情况，这两者的数据也未必一致。
当地价格与促销活动
在许多市场中，同一连锁品牌旗下不同门店的价格确实存在差异，这也是零售数据分析所揭示的较为有趣的现象之一。便利店和加油站便利店的价格往往远高于该连锁品牌的超市，这是一种刻意采取的策略，而非失误。从该品牌的全国官网上完全无法看出这一点。
区域性促销活动也是如此。某连锁企业可能会在该国某地开展一项促销活动以应对当地竞争对手，而其全国官网上却丝毫看不出相关迹象。正是通过按地区而非按连锁企业进行数据收集，才揭示了这一现象，而这一发现通常能向出资方证明该项目的价值。
MAP 监测
对同一数据的一种相关但不同的应用是最低广告价监控，该监控由品牌方而非零售商的竞争对手负责实施。 为产品设定最低广告价的制造商需要掌握各门店货架边或应用程序中实际显示价格的证据，因为全国统一的建议零售价无法反映个别特许经营店或折扣店是否违反了协议。 所需的记录内容与竞争对手价格追踪完全一致——包括门店、产品、价格和时间戳——但数据的使用对象以及后续的执法行动却有所不同，这一点应在数据收集方案设计之前而非之后就加以明确。
零售收款业务的规模化
人们往往会忍不住想要覆盖每一家门店。但这种做法几乎总是错误的。一个精心挑选的样本——每个地区选取几家分店，涵盖该连锁店经营的所有业态——只需极小一部分的样本量，就能捕捉到关键的差异；而且，较小的抽样范围也大大降低了引起那些原本并非为此而建的终端设备注意的可能性。
- 列举示例商店，不要逐一列举 — 差异源于地区和销售形式，而非门店数量。
- 将商店作为密钥的一部分保留 — 链级聚合恰恰会消除你原本收集的那些差异。
- 将本地出口与本地邮政编码进行配对 — 无论单独使用哪一种，生成的答案看起来虽然完整，但实际上并不完整。
- 也要留意该应用的动态 — 有些连锁店会在其应用程序中展示网站上从未显示过的库存和优惠信息。
- 关于收款状况的提醒 — 一个开始返回空结果的存储端点，看起来与库存为零的存储完全一样。
申请各门店预算
合理的访问频率应将数据采集限制为每天每家门店仅进行少量请求——一次用于库存查询，一次用于价格查询，或许再进行一次促销活动的抽查——而不是持续进行轮询。 门店级端点的设计初衷是服务于定位小工具或单个购物者的会话，而非用于每隔几分钟就检查同一分店的脚本；而异常规律的访问间隔本身就是一种信号，与邮政编码或退出IP地址无关。 将请求不均匀地分散在一天中，并改变每次拉取的确切分钟，可以消除这种原本很容易被察觉的模式。
关于同一问题的在线部分，请参见 电子商务数据，以及用于持续关注价格， 价格监控.
像本地购物者那样查询商品
PXM2实时位置——选择您正在追踪的连锁店所在的国家，并从每个国家/地区内部收集门店级数据：
法国
新加坡
印度
常见问题解答
零售数据与电子商务数据有何不同？
电子商务数据指的是提供全国配送服务的网站。零售数据则指实体店铺，其分析单位是分店而非产品目录。这一点彻底改变了局面：库存按分店计算，同一连锁品牌下不同分店的售价可能存在差异，促销活动按地区开展，而真正有意义的问题是“特定顾客附近的货架上有什么商品”，而非“零售商原则上销售什么商品”。
为什么涉及邮政编码？
因为如果没有邮编，门店级别的服务端无法提供答复。库存情况、“线上下单、门店自提”的时段以及当地价格都与具体分店相关，因此零售商在提供任何信息之前，都会先询问您的所在地。 如果提供国外地址的邮政编码，通常会导致回复不完整或被拒绝，因此将本地出口与本地邮政编码配对才是真正有效的组合。
同一连锁店的不同分店之间，价格真的会有差异吗？
在许多市场确实如此，这也是零售数据所揭示的较为有趣的现象之一。连锁企业会根据当地竞争状况、门店业态和区域成本进行调整，而这些差异在全国官网上是看不出来的。尤其是便利店和加油站便利店，其定价往往远高于同一连锁企业的超市，这是一种刻意采取的策略，而非失误。
货架数据需要什么样的更新频率？
“每日”这一频率在库存情况和促销活动方面恰到好处，因为这两者都遵循这种更新节奏。更新频率过高反而会增加“噪音”而非“有价值的信息”——例如，某款产品上午11点缺货、下午3点又补货，这种信息并不能为你提供任何可付诸行动的参考。此外，门店级终端相对不稳定，且原本就不是为持续轮询而设计的，这也是在此情况下保持耐心会有所回报的另一个原因。
记录什么最有帮助？
各门店的缺货情况及其持续时间。库存状况快照很常见；但某款产品在特定分店实际缺货了多长时间却不常见，而正是这个数据能反映出供应可靠性、分销问题和需求激增的情况。就像房地产中的“在市时间”一样，只有持续收集数据，才能获得这一数据。
相关移动代理指南
零售是商业的实体部分；线上部分和定价部分则紧邻其旁。