Unique Metrics
Metrics that cannot be aggregated on our side.
Aggregation meaning that we can combine the data into “rolled up” data.
Why can’t they be aggregated?
The data is based on data points that we don’t have. Typically uniquely identifying a person.
Example:
Daily Data:
Joe has 1 visit on January 1 (Daily: 1 impression, 1 unique impression)
Joe has 2 visits on January 2 (Daily: 2 impressions, 1 unique impression)
Joe has 10 visits on January 15 (Daily: 10 impressions, 1 unique impression)
Joe & Colin each visit twice on January 31 (Daily: 4 impressions, 2 unique impressions)
Monthly Data: January - 17 Impressions, 2 unique impressions.
Monthly Data if we aggregate: 17 impressions, 5 unique impressions
Unique data (Date range within the last 2 days) is kept for 2 days then discarded.
Dashboards only cache the initial loaded date range for unique metrics
Real time data calls for accuracy
We can’t calculate these metrics on our side so we always go to the API.
Data is stored in its date range explicitly and can only be reused for the specific date range calculated.
Data (Date range within the last 2 days) is kept for 2 days then discarded.
Filters make the data inaccurate as to use a filter we have to segment the data and then aggregate it again, rendering it incorrect. This is why we have a warning in the system.
Not properly supported in Datasets (it will aggregate and produce inaccurate data)
Estimated Metrics
Metrics that are calculated on our side based on incomplete data or for performance reasons (avoiding real-time API calls).
We do our best to find a way to calculate the metrics based on the data available.
The raw metrics for the calculations are aggregatable and used in the calculations to handle different scenarios that can’t easily be handled with unique metrics.
Currently supported by Bing, Google Ads and Google Analytics 4
Example: Bing & Google Ads - Search Impression Share
Calculation: Total Impressions / Total Eligible Impressions
Missing data: Total Eligible Impressions
Replacement Metric: Impressions / Impression Share Percent = Eligible Impressions (Estimated).
Estimated Calculation: Total Impressions / Eligible Impressions (Estimated)
Accuracy issues: Impression Share Percent is a rounded metric missing values between 0-10% and 90-100%. This means that any precision is lost and any values between 0-10% and 90-100% will be more inaccurate. The percentage of inaccuracy will be based on amount of lost precision and how many values are between 0-10% and 90-100%.
Google Ads:
We do the same thing for:
Search (Absolute Top) Impression Share,
Absolute Impressions On Top (Estimated) / Eligible Impression on Top (Estimated)
Impressions (Absolute Top) %,
Absolute Impressions On Top (Estimated) / Impressions
Search (Top) Impression Share
Impressions On Top (Estimated) / Eligible Impression on Top (Estimated)
Impr. (Top) %
Impressions On Top (Estimated) / Impressions
Google Analytics 4:
These are based on performance and not accuracy.
Active Users, Engaged Sessions, Event Count and Sessions have unique and estimated versions. The estimated versions are NOT calculated or derived, they are just the same value but we allow aggregation.
All Calculated metrics (like Bounce Rate, Engagement Rate or Events per Sessions) have a unique version and a non-unique version.
Unique version calculate is treated like a unique metric and requires real time API calls.
Non-unique version just aggregates non-aggregatable metrics and does a calculation.
Unlike Bing / Google Ads, we don’t have a baseline aggregatable metric like Impressions to use to help us make better calculations.