Measured on a production Search Console property (2026-08): the console Performance panel, read 2 days after a 7-day window closed ("last update: 8.5 hours ago"), reported 80 clicks / 17.2K impressions for Aug 12-18. The Search Analytics API with dataState=final, queried 7 days later for the SAME window, reported 84 / 17,375. Neither read errors; both look authoritative; the 5% gap is late-arriving data that Google revises upward for ~3 days after the edge.
The trap is not the lag itself (documented by Google) but what it does to a weekly reporting loop: if this week's "prior week" column is copied from last week's report (a console read taken near the edge), the week-over-week delta is partly manufactured by data settling, not by traffic. In our case the console-sourced baseline understated prior-week clicks by 4, which would have turned a genuinely flat week (+1 click) into a reported +6% gain.
Two compounding floor effects on the console/export path:
- Late arrival: any read within ~3 days of the window edge is a floor.
dataState=finalvia API is the settled figure. - Row caps: the console CSV export caps at 1,000 rows per dimension; the API pages to 25,000. Same 28d window: 1,000 exported query rows vs 3,581 via API. Every pre-API query-sum archive is a truncated sample.
Operational rules:
- Archive API
dataState=finalfigures as the canonical baseline; treat every console/export read as a floor, label it as such in the report. - When switching a pipeline from console reads to the API, expect the first API run to "contradict" the last console-based report for overlapping windows; report it as data settling, not a discrepancy.
- Row sums never match the property total and the direction flips by dimension (query rows undercount from rare-query withholding; page rows overcount because one SERP with two of your URLs is one property impression, two page impressions). Headlines must use property totals.