820条之后，Zillow藏了什么
一位在Apify上维护Zillow爬虫的开发者，用真实运行日志揭示了41×20=820的结果上限、售卖与租赁两套字段分裂的Schema，以及totalResultCount主动公布的真实匹配数。这组数字背后，是数据行业被低估的真相：数据可得性的边界，由源平台的产品逻辑写死。
一个爬虫工程师盯着 Zillow 搜索页测了几个月，得出的结论浓缩成两个数字：41 和 20。相乘得 820——任何一次搜索，最多只能拿回 820 条结果。这不是技术瓶颈，而是产品决策。它背后是数据行业一个被严重低估的事实：数据可得性的边界，从来不是爬虫技术决定的，而是源平台的产品逻辑写死的。
🧱 820 不是 bug，是产品
故事的主人公很特别：他在巴厘岛经营一家签证中介，与签证无关的那半份工作，是在 Apify 上维护一个读取 Zillow 的爬虫 Actor，覆盖在售房源、出租房源、近期成交三大场景。他的原话很有味道——这个 Actor 上他花时间去测量的时间，比写代码的时间还多，因为 Zillow 的数据从外面看远比实际统一。
一切的起点是一个三行代码：
`python
RESULTS_PER_PAGE = 41
MAX_PAGES = 20
RESULT_CAP = RESULTS_PER_PAGE MAX_PAGES # 820
`
41 条一页，最多翻 20 页，820 条封顶。这不是接口报错，也不是反爬拦截——是搜索产品本身的结构性设计。做海外房产数据的朋友私下都认这个理：用户不会翻到第 20 页，平台也就没有理由给你更多。
产业逻辑在这里浮现：任何把 Zillow 搜索当数据源的人，拿到的天然是一个被截断的样本。820 不是你的爬虫差，是产品层写死的硬顶。数据工程的第一个动作，不是写抓取代码，而是先搞清楚源平台的边界在哪里。测量的价值，此时大于编码。
📐 一套 Schema，两种生意
金句先行：数据产品“看起来统一”，往往是最贵的一种错觉。
作者的第二个核心发现是标题里那句话——One Schema and Two Datasets。在售房源页和租赁房源页，走的是同一套数据结构，但填充的字段几乎完全是两套：售卖场景关心挂牌价、成交历史；租赁场景关心月租、租期。同一个搜索接口、同一份 Schema，下游拿到的其实是两个形态迥异的数据集。
对工程侧的冲击是实打实的：宽表里大量列只对一半数据有意义，ETL 里全是“如果是在售走 A 分支、如果是租赁走 B 分支”的条件逻辑，任何一个新接手的分析师生病都会踩在稀疏列上。
判断很直白：单一 Schema 是源平台的产品选择，不是下游的好运气。第三方数据团队必须按业务域拆分数据集，而不是相信源头的“统一外观”。凡是把两个生意塞进一个 Schema 的源，下游必然要付一次拆解的工程成本——这笔成本在立项时几乎没人算进去。
🔍 页面会诚实地告诉你藏了多少
820 上限最狠的地方在于：它同时把“真实总数”摆在你面前。
搜索页的 searchPageState.cat1.searchList.totalResultCount 字段，存的是真实匹配数量。作者在奥斯汀（Austin, TX）跑了三个搜索，直接从运行日志里数出来——每次都能看到页面上实际给的条数，和这个字段公布的真实总数之间的巨大落差。用他的话说：页面会诚实地告诉你，它对你隐藏了多少房子。
这是一个值得单独致敬的接口设计。它意味着两件工程上的事：
第一，你可以度量覆盖率。抓回来的 820 条占总匹配的百分之几，一目了然，数据质量不再靠感觉。
第二，你可以验证分片策略。把一个大搜索按地理网格、价格区间切成若干个子搜索，每个子搜索的真实总数低于 820，就说明切片干净了；否则继续切。这是绕开上限的标准打法，而 totalResultCount 就是唯一的验收标准。
| 参数 | 数值 | 含义 |
|---|---|---|
| 每页结果数 | 41 | 搜索页固定返回条数 |
| 最大翻页数 | 20 | 产品层硬性限制 |
| 单次搜索上限 | 820 | 41 × 20，任何搜索不可突破 |
| totalResultCount | 动态 | 页面公布的真实匹配总数 |
产业判断：数据质量的度量，正在从“抓到了多少”转向“漏了多少”。公开真实计数的数据源，天然比黑盒数据源更适合做严肃数据产品——这一点，很多数据采购者在选型时根本没意识到。
💰 长尾数据供给者的生意经
最后看人。签证中介、兼职爬虫开发者、把 Actor 挂在 Apify 市场上卖——这是一张典型的长尾数据供给者画像。他们不掌握独家数据，拼的是对源端约束的理解深度：知道 820 的存在，知道两套字段的差别，知道用 totalResultCount 验收分片。同一个公开数据源，懂约束的人交付的数据集，和不懂约束的人交付的，是两种商品。
把这类玩家放进市场坐标系，格局会清晰很多：售卖页直抓门槛低但价值尚可，租赁页抓取两低，地理分片采集站在中间偏上，而官方数据接口（如 MLS 类数据供给）则是高门槛高价值的第一象限。分片采集这类“工程密集型”路线，正是长尾供给者往上走的那条梯子。
对数据要素流通的启示也在这里：数据产品的定价与可靠性，本质上是源端约束理解的定价。平台每收紧一次产品逻辑，长尾供给者就重新测一轮、改一轮管道——这种持续投入不体现在任何报价单上，却是第三方数据真实成本的大头。采购方评估数据供应商时，与其看样例数据多干净，不如问一句：源端的结果上限是多少，你怎么处理分片的？答不上来的，大概率交付的是结构性残缺的样本。
小结
41、20、820、一个 totalResultCount、一套分裂的 Schema——五个细节，讲完了第三方数据工程的全套功课：先测边界，再拆字段，用真实计数验收覆盖，最后把对约束的理解变成产品。数据行业的护城河，往往不在算法里，而在这些没人愿意花时间测量的数字里。随着平台产品逻辑持续演进，源端边界只会有更多、不会有更少——对约束的测量能力，就是下一代数据供给者的核心竞争力。