The Looker Studio dashboard refreshes every Monday at 9am the way it always has. This week the revenue tile reads about $40,000 lower than the number sitting in Shopify. Nobody touched the report. No tag broke. GTM Preview shows the purchase event still firing clean. The instinct is to go looking for a tracking bug that does not exist, because the actual cause is not a bug, it is GA4's own connector doing exactly what it is built to do once a report crosses a threshold nobody put on the dashboard.
That threshold problem has a name, GA4 Looker Studio connector limits, and it is really two separate failure modes wearing one label. One throws a visible error. The other does not, and it is the one that costs more, because it changes the numbers a founder is making budget decisions against without telling anyone it happened.
In this piece:
- The difference between a quota error and silent sampling, and why they get confused
- The actual token numbers, sourced from Google's own API documentation
- Why Looker Studio gives you no warning when a chart is sampled
- A decision frame for when the native connector is fine and when BigQuery export is the real fix
Two different limits, one confusing symptom
The GA4 connector in Looker Studio pulls data through the GA4 Data API, and that API enforces a hard quota measured in tokens, not requests. According to Google's own API quota reference, a standard GA4 property gets 40,000 tokens per hour and 200,000 per day, with at most 10 concurrent requests. GA4 360 properties get ten times the hourly and daily allowance and 50 concurrent requests.
Token cost is not fixed per request. It scales with row count, the number of dimensions and metrics pulled, filter complexity, and how wide the date range is. A dashboard with ten charts, each making a moderately complex request, can exhaust an hourly quota after only a handful of refreshes, especially if several people on the team have that dashboard open and Looker Studio is auto-refreshing it in the background. When the quota runs out, every chart on the page shows a visible error. That failure mode is annoying, but it is honest: everyone can see something broke.
Sampling is the one that does not tell you it happened
GA4 applies data sampling once an event-level query crosses 10 million events for a standard property, a limit Google's own documentation ties to Explore reports in the GA4 UI. Looker Studio does not build its charts from those pre-aggregated standard reports, though. Per Google's Looker Studio connector documentation, every chart fires an ad hoc request against the same Data API that powers Explore, so it inherits the same sampling rules, and the same 10 million event ceiling, on a live basis.
Here is the part most guides gloss over: Google's own documentation for the connector states directly that Looker Studio does not indicate when a chart's data is sampled. That is a meaningfully different situation from the GA4 interface itself, where Explore reports show a visible sampling icon the moment a query gets thresholded. A founder or campaign manager reading a Looker Studio tile has no in-product signal that the number in front of them is a statistical estimate rather than an exact count.
The practical effect shows up as drift that has no obvious cause. Widen a date range, add a secondary dimension, or pull in a segment with high cardinality, and a chart that used to match GA4's own UI exactly starts reporting a slightly different total every time it refreshes. In one delivered tracking audit, a client's summed platform-reported revenue exceeded the actual store revenue by roughly 40 percent in the same reconciliation window, and while that particular gap traced back to duplicate order IDs across two ad platforms rather than GA4 sampling specifically, the diagnostic lesson carries over directly: any dashboard number that cannot be reconciled against a ground-truth source, whether that is Shopify order data or a raw BigQuery export, is a number nobody should be making spend decisions against.
Why the quota runs out faster than a report count suggests
It is tempting to assume quota problems only hit large accounts, but the token math punishes report design more than traffic volume. Google's guidance on managing API quota is explicit that filters, high dimension cardinality, and wide date ranges all multiply token cost per request, independent of how many total sessions the property actually has. A mid-size store with a dashboard built around week-over-week comparisons, multiple audience segments, and a handful of custom dimensions can burn through an hourly quota faster than a much larger store running a simpler, well-scoped report.
That means the fix for a quota problem is frequently a report-design problem, not an infrastructure problem:
- Reduce the number of charts that query live on every page load, and cache what can be cached.
- Avoid stacking comparison date ranges and multiple high-cardinality dimensions on the same chart.
- Split a single dense dashboard into fewer charts per page rather than one page trying to answer every question at once. A Looker Studio dashboard scoped to the five views a founder actually opens weekly burns a fraction of the quota that a fifteen-chart everything-dashboard does.
When the native connector is fine, and when it genuinely is not
Not every store needs to abandon the native GA4 connector. The decision comes down to three questions:
Does the dashboard query near or above the 10 million event threshold in a typical reporting window? If sessions are modest and reports stick to standard date ranges, sampling is unlikely to bite, and the native connector is the right level of complexity for the job.
Does the business make five- or six-figure spend decisions off a number the dashboard cannot independently verify? If a campaign manager is scaling ad budget based on a revenue or ROAS figure from a Looker Studio tile, the cost of that number being quietly wrong is higher than the cost of building a more durable pipeline.
Is the property multi-brand, multi-domain, or running consistently near the quota ceiling regardless of report design? That is the pattern where BigQuery export stops being an optimization and becomes the only reliable option, since BigQuery export returns every event at the row level with no sampling threshold and no per-property token quota to exhaust.
The one detail worth planning around before it becomes urgent: GA4's BigQuery linking has no backfill. Data only starts flowing from the day the property gets linked forward, so a store that expects to need BigQuery-backed reporting eventually is better off linking it early and letting the export accumulate quietly in the background, rather than linking it the week the native connector's limits finally become the blocker. Linking itself is free; the cost lives in query volume against the exported data, and BigQuery's on-demand pricing includes 1 TiB of query processing free every month before the $6.25-per-TiB rate kicks in, which is usually enough for a single-brand store running scheduled or pre-aggregated queries instead of ad hoc ones on every dashboard refresh.
What to check before you rebuild anything
Before assuming the fix is BigQuery, confirm the numbers are actually wrong and not just unfamiliar. Pull the same metric, same date range, directly from the GA4 interface and compare it against the Looker Studio tile. If they match, the dashboard is fine and the discrepancy is somewhere else, likely a UTM or attribution issue rather than a connector limit. If they do not match, check whether the report is running a wide date range with multiple dimensions, which is the fastest route to sampling, and simplify it before concluding you need new infrastructure.
If the dashboard checks out clean but the underlying tracking config is the thing you are not confident in, that is a separate question from the connector, and a GA4 audit checklist is the more direct way to verify the events feeding the dashboard are correct before worrying about how the dashboard queries them.
For a store that has confirmed the pattern, is spending real budget against dashboard numbers, and is not ready to build a BigQuery-backed reporting layer alone, that is exactly the gap a dashboard and reporting build closes, and a tracking setup that links BigQuery export from day one avoids the no-backfill problem entirely instead of hitting it retroactively.
