{"id":9401,"date":"2026-08-12T18:00:00","date_gmt":"2026-08-12T16:00:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9401"},"modified":"2026-10-09T22:41:27","modified_gmt":"2026-10-09T20:41:27","slug":"bigquery-data-transfer-backfill-limit-and-google-signals-scope-two-ga4","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-analytics\/bigquery-data-transfer-backfill-limit-and-google-signals-scope-two-ga4\/","title":{"rendered":"BigQuery Data Transfer Backfill Limit and Google Signals Scope: Two GA4 Changes From June 2026"},"content":{"rendered":"\n
Two changes in the Google analytics stack became effective in June 2026. Both are documented, both are in force as of 10 August 2026, and neither announces itself while a pipeline runs. The first narrows what the BigQuery Data Transfer Service will fetch during a backfill. The second narrows what the Google Signals setting in the Analytics admin actually controls. What links them is not the subject matter but the mode of arrival: no failed job, no exception in a log, no line in a monitoring dashboard. The first surfaces when someone starts a backfill. The second surfaces when someone notices that a switch no longer produces the effect it produced before.<\/p>\n\n\n\n
1. Two changes that took effect in June without an error message<\/h2>\n\n\n\n
Most changes in a data stack announce themselves. A schema shifts and a query fails. An endpoint is retired and a client returns a status code. A quota tightens and a job stops. Those changes are noisy, and the noise is what makes them cheap to handle: the monitoring that already exists catches them, and someone reads the message.<\/p>\n\n\n\n
The two June changes belong to a different category. In both cases the system keeps working. Jobs complete, settings can still be toggled, dashboards still render. The change shows up only in the content of the data or in the meaning of a configuration value, and neither of those is covered by the usual alerting.<\/p>\n\n\n\n
\n
BigQuery Data Transfer Service:<\/strong> since 1 June 2026 the connectors for Google Ads, Search Ads 360 and Google Analytics 4 no longer populate backfill runs with data older than 37 months. The documentation states that such runs return incomplete or empty results and can overwrite existing complete history.<\/li>\n
Google Signals:<\/strong> from 15 June 2026 the Google Signals setting in the Analytics admin and the Google Signals API control only the association of Analytics data with information from signed-in users for behavioural reporting. Control over the data itself sits with Consent Mode, specifically with the ad_storage<\/code> parameter.<\/li>\n<\/ul>\n\n\n\n
The rest of this article treats them as two instances of the same operational problem: a documented change whose effect becomes visible only through a deliberate check. Section 2 to 4 cover the transfer limit and a guard that can be placed in front of a backfill. Sections 5 and 6 cover the Signals change and an inventory that records the current state before it is needed.<\/p>\n\n\n\n
2. The 37-month boundary in the BigQuery Data Transfer Service<\/h2>\n\n\n\n
The entry appeared in the BigQuery release notes on 6 May 2026 and took effect on 1 June 2026. It applies to three connectors of the BigQuery Data Transfer Service: Google Ads, Search Ads 360 and Google Analytics 4. Backfill runs on these connectors are no longer populated with data older than 37 months. The stated reason is a change to the retention rules on the Google Ads side.<\/p>\n\n\n\n
Two boundaries of the change matter for anyone maintaining a warehouse built on these transfers. Data already transferred remains untouched \u2014 as long as no backfill runs over it. The 37 months are a rolling window, not a fixed cut-off date, so a range that was still inside the boundary in June moves outside it as the months pass. A backfill definition stored in a runbook a year ago and left unchanged will therefore cross the boundary at some point without anything in the definition itself changing.<\/p>\n\n\n\n
The documentation leaves several details open: whether a run returns an error code or message, whether the Cloud console warns about a range beyond the boundary, and whether the operation can be reversed afterwards. None of these behaviors should be assumed. The guard therefore needs to check the requested range and the resulting rows rather than rely on an undocumented signal from the service.<\/p>\n\n\n\n
3. Why a backfill can replace complete history<\/h2>\n\n\n\n
The core of this change is not the boundary. A limit on how far back a connector reaches would be an inconvenience with an obvious workaround: keep the archive that already exists. The core is the second half of the documented behaviour \u2014 a run that returns incomplete or empty results can overwrite history that was complete.<\/p>\n\n\n\n
The sequence that leads there is an ordinary one. A warehouse holds four years of transfer data. A late correction, a schema adjustment or a suspected gap prompts a re-run for an older window. The backfill is scheduled with a date range that reaches back beyond 37 months, entirely or in part. The run completes. The partitions inside the window are rewritten with what the connector delivered, and what the connector delivered for the portion beyond the boundary is incomplete or empty. Nothing in that chain requires a mistake in the request itself; the same request would have worked in May.<\/p>\n\n\n\n
This is what makes a re-run different from a first load. A first load into an empty range can only add. A re-run over an existing range replaces, and replacement is only safe when the source is at least as complete as the target. Since 1 June that assumption no longer holds for the affected connectors beyond the 37-month mark, which turns a routine operation into one that needs a precondition attached to it.<\/p>\n\n\n\n
Because the documentation does not describe a reversal path, the practical consequence is that the check has to happen before the run, and a copy has to exist before the run. Recovery after the fact depends entirely on whatever the warehouse itself preserved.<\/p>\n\n\n\n\n\nThe boundary does not block the run; it changes what the run writes. Everything to the left of it comes back incomplete or empty, and it lands in the same rows that previously held the full history.<\/figcaption>\n<\/figure>\n\n\n\n
4. A guard before the run: check the boundary, count the rows, keep a copy<\/h2>\n\n\n\n
The guard has three parts, and each one is small enough to sit in front of an existing backfill step. All identifiers written in capitals below are placeholders for the project, dataset, table and date column of the warehouse the run touches; the column names are not prescribed by the service and follow whatever the target table already uses.<\/p>\n\n\n\n
The first part compares the requested range against the rolling boundary. It answers a single question \u2014 does any part of this window fall beyond 37 months \u2014 and it answers it from the calendar, not from a response the service may or may not send.<\/p>\n\n\nSQL<\/span>
![\"The](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/hand-backfill-en.png\")
\n