Sometimes, you may look at your Supermetrics report and realize that there's something off in your Reach or User metrics compared to the data source user interface. Why is that? In this article, we explain why this can happen.
In simple terms, there are two types of metrics that can be pulled to your report: aggregatable and non-aggregatable. These two data types behave very differently, and you can manipulate them in different ways:
- Aggregatable metrics behave normally as numbers do, so to speak - you can add, subtract, get averages, and so on.
- With non-aggregatable data, the values usually can't be summed or aggregated to a higher level, and doing so creates either errors or misleading results in your report.
Non-aggregatable metrics
Reach and Users, for example, are so-called non-aggregatable metrics (NAM). Those are metrics that — as the name suggests — can't be further summed up in your reports — for example, in Google Sheets or your data warehouse — after you have run your query or transfer. Basically, NAMs are already aggregated and final when they come from the original data source into your report.
NAM are usually metrics that are calculated by counting the number of unique User IDs broken down by whatever other dimensions you have included in the query. This calculation happens directly in the data source, such as in Facebook Ads or Google Analytics 4. As those sources usually don't allow us to access the User IDs, we can't calculate NAM in our data source connectors or provide them to you so that you could calculate NAM based on your reporting needs.
Also, when the calculation in the data source involves dividing one metric by another, that calculated metric is no longer aggregatable. This means that all sorts of rates and ratios are non-aggregatable.
Common examples of NAM include:
- Reach
- Frequency
- Users
- Followers
- Total budget
- Rates and ratios, such as Engagement Rate, CTR, CPC, CPM, ROAS, or Conversion Rate
- All percentage metrics
For example, if you query for reach data between January 1, 2023, and January 7, 2023, as a result, you get one week's reach (one number).
| January 1 - January 7 | |
| Account name | Reach |
| Demo account | 1609753 |
If you query the same data with the same time frame with the date breakdown (and this is what you normally have if you store data in a data warehouse), you'll have 7 rows of data with reach for each day.
This is where the granularity of data comes into play. The level of granularity depends on what breakdown dimensions you include in your query. For example, if you include the date dimension in your query, you're looking at your data on a "daily grain". If you include the date and campaign in your query, you're looking at your data at an even more detailed grain (also known as a lower grain). The lower the grain (such as daily), the more likely you're to see highly inflated for your NAMs if you sum them up to a higher grain (such as weekly).
Now, if you would use the below table of daily reach data as a source to get your weekly reach (NAM), the sum of seven separate day's daily reach likely is a much bigger number than the actual reach for the 7 days, as these 7 days with daily breakdown only remove the duplicates that happen inside one day.
| Account name | Date | Reach |
| Demo account | 2023-01-01 | 134023 |
| Demo account | 2023-01-02 | 249543 |
| Demo account | 2023-01-03 | 756223 |
| Demo account | 2023-01-04 | 565125 |
| Demo account | 2023-01-05 | 382806 |
| Demo account | 2023-01-06 | 189987 |
| Demo account | 2023-01-07 | 202307 |
| Sum of reach | 2408014 | |
So, if you're looking to get weekly reach data, it's best to query for the weekly data in the first place instead of summing up individual days.
Practical examples: Why does this happen?
Example 1: Reach
Let's dive into specific examples here, using the Reach metric, which counts the number of individuals that you have reached with an ad or campaign.
Now, if you have reached the same individual multiple times during a given time frame (such as 1 week as in the table above), it was still only one person you reached.
For example, if Monica saw your ad on Monday, Tuesday, and also on Friday, she generated 3 impressions — times your ad was shown to her — but you reached only one person.
Summing up reach would imply that you reached 3 Monicas instead of one, which isn't the case.
Please note that further breakdowns added to the query make the situation even more complex and misleading. For example, let's say you break down the Reach data by date and campaign. If Monica saw your ads for two separate campaigns within a single day, and you sum up Reach for that day (across all campaigns), you'd see a Reach of 2 even though you only reached 1 person.
We've written a support article about the Reach metric and what to pay attention to when using it. Take a look in case you want to dive a bit deeper into this particular metric.
Example 2: Users
Another example could be a metric that counts users. The same principle applies: If Monica used your app 5 times last week, she still counts as just one user.
But when you break down your Users metric by date and then sum up the daily Users to get the weekly Users, you'll be counting Monica's user 5 times instead of once.
Aggregatable metrics
In comparison, aggregatable data refers to data that has been combined from several measurements into a summary or statistical format. This data can be manipulated, calculated, combined, and made into various types of tables and charts to show what the data means to the metrics that are being tracked.
Common examples of aggregatable metrics include:
- Impressions
- Clicks
- Sessions
- Cost
One example of aggregated data is your ad impressions. Those you can easily break down into a very low grain (such as by date, campaign, ad, or device) and still be able to aggregate them into a higher grain. If you apply the example from the table above on impressions, you should see matching data.
The following table shows the weekly impression data.
| January 1 - January 7 | |
| Account name | Impressions |
| Demo account | 1000 |
If we pull data per day and sum it up, it still matches the weekly data.
| Account name | Date | Impressions |
| Demo account | 2023-01-01 | 50 |
| Demo account | 2023-01-02 | 200 |
| Demo account | 2023-01-03 | 30 |
| Demo account | 2023-01-04 | 70 |
| Demo account | 2023-01-05 | 400 |
| Demo account | 2023-01-06 | 100 |
| Demo account | 2023-01-07 | 150 |
| Sum of impressions | 1000 | |
Using non-aggregatable metrics in Supermetrics
In our data source field documentation, we mark most of the NAM metrics, such as Reach in Facebook Ads. The aggregation details for NAM mention if the metric is non-aggregatable.
Remember also that because all kinds of rates, ratios, and percentage metrics are calculated in the data source, they're non-aggregatable after they're pulled into your report.
In conclusion, the number you see for the NAM should be considered "locked" after you have run your query. If you need a higher level of aggregation for that NAM, you need to create an additional query. For example, if you have a query that shows you Reach per date, and you want to see the weekly Reach, you must not sum up the reach from the Reach per date query. Instead, create an additional query that retrieves Reach per week for you.
The golden rule: Don't sum up non-aggregatable metrics — it will lead to incorrect results that won't match with what you see in the data source's platform.