ToolsThatRank / measured data
Field reference, checked against the vendor doc
Search Console dataState: why today's numbers still move
dataState all returns fresh data that is still being processed, so recent rows can change. final returns completed data only, and it is the default when the field is omitted. hourly_all adds an hourly breakdown and marks it as partial.
Updated 2026-10-28
A Search Console date range in the middle of today will not match the same range tomorrow. The API has a field for that, and most exports leave it out. This page explains the three values, what the response metadata adds, and which value to use for a report that must not move.
By Michael Lip, who builds and runs ToolsThatRank.
The three dataState values
The field is optional. The vendor text below is quoted from the Search Analytics query reference, read 2026-10-28.
| VALUE | WHAT THE RESPONSE CONTAINS | USE IT FOR |
|---|---|---|
| all | Includes fresh data. Some rows may still be collected and processed. | Today's numbers, when you accept that they will change. |
| final | Only finalized data. This is also the behaviour when you omit the field. | Reports, comparisons and any figure you publish. |
| hourly_all | An hourly breakdown, which includes partial data. Valid when you group by the HOUR dimension. | Same-day monitoring only. |
The reference states it in one sentence: if the value is all, "data will include fresh data".
If it is final, or if the parameter is omitted, "the returned data will include only finalized data".
What the metadata object adds
When you ask for fresh data, the response can carry a metadata object that tells you where the
unstable part starts. One field matters for a date-grouped report: first_incomplete_date.
The reference defines it as "the first date for which the data is still being collected and processed".
It is populated only when dataState is all, the request groups by date, and the
range contains incomplete data. The doc adds that "all values after the
first_incomplete_date may still change noticeably".
All dates and times in that object are in the America/Los_Angeles time zone. A report built
in another zone can therefore look one day out at the boundary. Group by date and read the field, and you
know exactly which tail of the series is still moving.
Which value belongs in a published figure
Use final for anything a reader can quote. It removes the moving tail, and it is the default,
so an export that never sets the field is already final.
Use all only when the question is about today. Keep the response metadata with the export, or
the next run cannot tell a real change from a row that finished processing overnight.
Do not mix the two in one series. A chart that joins a final history to an all tail shows a
fall at the join that no page earned.
The request body
The field sits at the top level of the request, beside startDate and dimensions.
{"startDate": "2026-09-01", "endDate": "2026-09-28", "dimensions": ["date"], "dataState": "final", "rowLimit": 25000}
Change the value to all and the same request returns the moving tail. The row limit does not
change the state of the data. See the row limit planner for the
request count and the daily cap.
How we apply it
The device CTR study on this site reports a harvest with dataState final and a closed window, so every figure in it is repeatable. Read the desktop and mobile CTR study to see the stamp that records those conditions.
What this page cannot tell you
- It does not measure how long Google takes to finalize a row. That varies by property and by day.
- It does not replace the vendor reference. The quotes above are from that page, read 2026-10-28.
- It cannot make an
allexport stable. Onlyfinalremoves the moving tail.
