Reports and explorations both provide actionable insights into your web and app data. Usually, you'll see the same data in both areas. There are times, however, when you may see differences in the data shown in each area. These differences are expected, and are explained below.
In this article:Reports and explorations support different fields
By design, reports and explorations give you different views of your data, at different levels of granularity. For example, some dimensions and metrics available in reports aren't supported in explorations. When you open a report in explorations that includes unsupported fields, those fields are dropped from the exploration. If the report displayed a visualization based on the unsupported fields (for example, a line chart showing an unsupported metric), that visualization won't appear in the resulting exploration.
Differences between segments and comparisons
Comparisons in reports can use fields that aren't supported in explorations. Comparisons present in a report you open in explorations are converted into segments, and any unsupported metrics or dimensions in the comparison won't be included in the resulting segment in explorations. This can change the data included or excluded from the segment.
Date differences
Date ranges in explorations are limited to your property's data retention settings. If you create a report with a date range outside the user and event level data retention settings, and then open it in explorations, data prior to that range won't be included.
Large amounts of data
When your property collects a large amount of data, Analytics uses different methodologies in reports and explorations to scale at a reasonable cost and performance. The different methodologies can cause inconsistencies between reports and explorations.
Explorations
Explorations query raw event and user-level data. When a query needs to process more events than the quota limit, Analytics uses a sample of the available data. The quota limit is 10M events for users of the free Google Analytics product and 1B events for users of the paid product. To see the current sampling rate, hover over the data-quality icon in the upper right of your explorations.
When working with sampled data, the ratio between the size of the overall population compared to the sample size can affect the accuracy of your query results. In general, the bigger the sample size (as a percentage of the population), the higher the accuracy of your results.
If the sample size for an exploration is too small, try adjusting the population. For example, shortening the date range of an exploration can reduce the size of the population to which sampling is applied, resulting in higher accuracy.
Reports
Rather than querying raw event and user-level data, reports rely on daily aggregated tables with certain system limits. If a property collects data with a higher cardinality than the system limits for that table, any data beyond the limits aggregates under an (other) row.
High cardinality affects reports differently depending on the type of report. All default reports are served from smaller tables, which rarely go beyond the 50k row system limits. Custom reports and default reports with secondary dimensions, comparisons, and filters are served by larger aggregated tables with higher row limits. The row limit under these circumstances is 2M. These reports have a higher likelihood of data being grouped under the (other) row because of the many high-cardinality dimensions in those tables.
When a report is served from a table that has some data under the (other) row, you might see an (other) row in the results. Any dimensions that you apply to the report, even if the report results omit the (other) row, can be approximated to a lower value when some of that data is included under the (other) row.
What to use
Depending on the amount and type of data that your property collects, these approximations can affect your results differently and generate inconsistent results between a report and an exploration. Typically, when both these approximations occur, Exploration results tend to be more accurate.
Differences when using behavioral modeling
If behavioral modeling for consent mode is enabled you may see minor differences in the data between standard reports and explorations. Behavioral modeling uses machine learning to model the behavior of users who decline analytics cookies based on the behavior of similar users who consent to analytics cookies. When behavioral modeling is enabled, the machine learning algorithm processes two different data sets - aggregated tables for reports and raw event and user-level data for explorations. Structural differences in the two data sets can result in slight differences in modeled data between reports and explorations. The probability of a discrepancy increases with the number of users represented in the data who declined consent for analytics cookies.
Processing time differences
The data in Analytics comes from a number of different systems, and may be processed at different times. You may notice slightly different results when running queries for the past 48 hours, due to processing time differences.