How a row limit works
Every connection between a reporting tool and a platform has a ceiling on how much it will hand over in one go. Ask for keyword performance across a large account and the platform does not refuse — it returns rows up to the ceiling, ordered by whatever the query happened to sort on, and stops. The report draws a chart from what arrived, with nothing on screen to say that anything was left behind.
The limit can live in several places at once. The platform’s reporting interface has one, the connector that pulls from it has another, the spreadsheet or table receiving the data has a third, and the chart itself may only render a set number of rows. The tightest of them wins, and it is not always the one you were thinking about.
Detail is what decides whether you hit it. A report showing spend by campaign and month has few rows. The same report broken down by keyword, device, day and location multiplies out into an enormous table, because every combination becomes a row of its own.
Why row limits matter
Because the failure is silent and it lands on the total. A truncated table does not show an error; it shows a smaller number. Spend looks lower than the ad account says, conversions look lower than the CRM says, and the reconciliation that follows blames tracking rather than the connector.
It also skews conclusions in a predictable direction. When rows are cut off after sorting, what gets dropped is the long tail — the small keywords, the minor cities, the rarely bought products. Anyone reading the report concludes that the tail does not exist and stops looking for opportunity there.
Where row limits go wrong
The commonest mistake is building the most detailed possible view first, on the reasoning that detail can always be filtered later. That is the view most likely to be truncated, and it truncates before any filter is applied.
The second is comparing a truncated report to a platform screen and treating the gap as a tracking discrepancy. The third is trusting a report that once matched: an account that grows, adds keywords or expands into new locations will eventually cross a limit it was comfortably under when the report was built.
How to act on it
Check the totals against the platform before a report goes to anyone, and repeat that check when the account grows. Pull data at the coarsest level that answers the question and add detail only where it is needed, rather than pulling everything and filtering afterwards. Where the detail is genuinely required, split the pull by date range or by campaign so each request stays under the ceiling, or move the heavy lifting to a warehouse such as BigQuery and report from there. Add a row that shows the total to the report itself, so a truncation announces itself the next time it happens instead of quietly changing the answer.