For marketing teams, maintaining high-quality data is critical. Just one mistake can mean data ends up doing more harm than good. So, marketers need to be careful when pulling all their metrics together into a report.
One common trap that often catches marketers out however is non-aggregatable (nonag) metrics, which can’t be added or summed. Advertising platforms often offer up nonag metrics for reporting, and if marketers don’t understand how to deal with these they risk their data quality. This blog will look at best practices for working with one of the most common nonag metrics: reach.
To find out more about what nonag metrics are, check out this blog.
Reach is defined as the unique number of people exposed to an advertisement. This is not the same as the impressions number, which counts how many times an ad has been viewed, and is always equal to or greater than the reach.
This metric comes under many different names across different sources, including:
- Reach
- Unique impressions
- Cookie impressions
While there may be instances where you can count the number of unique IDs in two groups in order to calculate a sum of reach across those two groups, many platforms hide this information in order to comply with privacy regulations like GDPR.
The Facebook Ads API, for example, is walled garden, which means it doesn’t allow the fetching of user-level granularity data. Therefore reach should be treated as nonag metric.
Let’s take the following scenario:
Day 1: 3 people are exposed to a Facebook advertisement
Day 2: 5 people are exposed to a Facebook advertisement
So, what’s the total number of people exposed to the ad? At least 5, potentially up to 8, most likely somewhere in between.
This happens because there might be an overlap between the two groups of people. In other words, someone might have been exposed to the advertisement twice, or more.
If we had the granular data that showed the list of people exposed per day, we’d be able to count their unique IDs and calculate the total number, such as in the chart below.
Day 1 |
Day 2 |
Day 1 and 2 |
Maisie |
Anna |
Maisie |
Marcus |
Maisie |
Marcus |
Charlie |
Matt |
Charlie |
James |
Anna |
|
Charlie |
Matt |
|
James |
||
Reach = 3 |
Reach = 5 |
Reach = 6 |
However, without this information, we need to fetch additional data that gives us more context in order to deliver accurate data.
So, here's what we can do with reach metrics if we don’t have access to unique IDs:
Overcounting happens when fetching nonag metrics alongside "normal" performance metrics, which can be aggregated, like clicks and costs. It’s best practice to fetch these kinds of normal metrics at a low granularity, i.e. day > device > platform.
In this way, you can do the more complex drilling down once data has been loaded to your chosen BI. If you do intend to fetch reach alongside normal metrics in a report, you’ll need to plot reach at this same very granular level, which will likely make your reporting overly complex, or even unreadable. This is why you need to fetch reach separately from the performance metrics, in another data stream.
As a consequence of the above, you'll probably end up having more than one datastream fetching reach, therefore it is recommended to name each reach differently, e.g. reach_daily, reach_campaign_daily, and so on. Without proper names for reach metrics coming from different data streams, reporting maintenance will become more complex, as you'll have to employ a complicated filter system to find such metrics and make sure you’re not using reach coming from multiple data streams.
Adding or averaging nonag metrics like reach will give false results, so it’s important that marketers understand which metrics can’t be aggregated. Anyone dealing with data, from marketers to analysts, needs to beware of particular metrics that can’t be added or summed — or risk the credibility of their data.
The safest way to work with nonag metrics is to understand exactly which metrics can’t be added and why, and to make sure where possible that you fetch the data behind your nonag metrics, so that your BI tool has all the relevant context it needs to calculate metrics more broadly.