User Measurement & Calculation Details
In-depth details on how we calculate important user measurements -- like installs, activity, retention rate, and LTV to help AdLibertas customers understand the subtleties of the platform.
Unique users
To tie users across datasets AdLibertas uses the most commonly available pervasive ID to identify unique users.
For iOS, this is the IDFV, "The value of this property is the same for apps that come from the same vendor running on the same device." (documentation).
For Android, this is the GAID. "The advertising ID is a unique, user-resettable ID for advertising, provided by Google Play services." (documentation).
Note: for Google, users who opt out of GAID tracking have a shared ID. This can cause confusion with reporting, read more in Excluding GAID tracking opt-outs.
This may differ from Firebase: by default Firebase users a user_pseudo_id to track individual users, this number is re-generated every time a user re-installs the app and therefore may differ from the centralized IDs depending on user activity.
Installs
By default, we opt to use the Firebase user_first_touch_timestamp which is defined as a measurement of when a user has first opened the app or visited the site.
This may differ from Firebase reporting: by default, Firebase uses the first_open event to tie attribution to installs. However, this event is also known to fire on app updates.
Active Users
By default, both us and Firebase consider a user “active” when they’ve fired at least one “engagement event” a day. For Firebase users, this is the user_engagement event. Defined by Google as “when the app is in the foreground…for at least one second.”
However, for some apps, we have seen users who don’t have a user_engagement event, but do show other activity; either because this event hadn't had time to fire or developers have modified this event behavior.
For this reason, we offer the ability to also consider a user active when they fire a session_start event, defined as “when a user engages the app.”
For customers who opt into this additional metric to consider a user "active"– and who have users that are firing a session_start event but not firing a user_engagement_event—you’ll see a higher number of installs and active users on a daily basis. Depending on how many additional users this includes, you’ll see a decreased LTV. This is because all revenue will be shared across more active users.
Why would counts differ across platforms & vendors?
The deeper you delve into install rates & unique users, the more complicated you'll find the topic. There's a reason the mobile analytics market is worth over $10B.
Succinctly put, there are many reasons user counts may differ across analytics platforms, here are some examples:
Retention rates may differ between different reporting technologies if they are using different events to measure installs & active users. As hinted at above, even Firebase can show different times between a
first_openevent anduser_first_touch_timestamp. Across different vendors, each may have a unique way of measuring a user's first and subsequent visits. If your users exhibit a large discrepancy between any of these measurements, retention may vary.Using different IDs: Depending on how the platform is counting users, there could be multiple methods to measure unique users: advertising IDs reset or can be obfuscated, Vendor IDs may not be reset upon reinstall (IDFVs). Certain vendors might have IDs that reset more often (e.g. Firebase as described above)
Duplicate Counts: user re-installs, resetting Ad-IDs, or ad platforms self-attributing networks may lead to multiple counts for a single user's install.
Firebase Installs may differ because the user has installed but has not generated a
first_openevent. We've seen this happen with pre-load or other low-quality install sources.DAU may differ if users don't trigger a user_engagement event.
Firebase unique users may differ if users re-install and reset their firebase pseudo id
Retention Rate
Retention rate is defined as:
A retention rate gives a number to the percentage of users who still use an app a certain number of days after install. It is calculated by counting unique users that trigger at least one session in one day, then dividing this by total installs within a given cohort.
While retention rate is a widely used metric for tracking app performance, there are details that are important to understand when you dive into how the metric is calculated. For most high-level performance measurements, this won't be a concern but for users buying traffic, any changes to retention can alter your LTV calculations, which can skew your performance measurements.
One such detail in the wording above is "trigger at least one session in one day." Meaning if a user isn't active on their day of installation, they will not be considered in subsequent "retention rates." Or put another way: if a user shows up as active on day two, are they really "retained?"
Understanding "Retention Rate" in the dashboard
In the AdLibertas dashboard there are 3 important metrics in the retention section:
Retention Rate - measures users that have returned on a given day, having also visited on day 0. This percentage is calculated by the number of active users on a given day divided by the number of users eligible for retention. For instance, users who installed 29 days ago aren't considered eligible for day 30 retention.
Daily Active Users - the number of users who were active on the given day.
Audience Representation - the number of active users divided by the entire audience size. This is to provide guidance on when you're making major decisions based on the activity of a small number of users.
Relative Reports vs Retention (lifecycle) Reports.
The eagle-eyed report builder may come across a situation where day-30 of a relative report has more users than exist in the retention report. This is because a relative report includes users based on their activity since day-0, whereas a retention rate will only include users who were active on day-30 AND we're active on day-0.
Lifetime Value (LTV) calculation
Lifetime user value is one of the most powerful metrics offered by AdLibertas User-Level Audience Reporting. Simply put this measures the (estimated) revenue on a per-user basis for your defined cohort of users. More details are available in the article below:
AdLibertas calculates LTV by taking the actual earned revenue (both impression-level ad revenue and in-app purchase revenue) of the cohort and multiplying it by the inverse of the retention rate.
Related: forecasting LTVs
This means the two factors that impact your LTV are your chort retention and earned revenue. Some hyper-casual apps -- or other apps with high user turn-over-- face potential challenges in measuring accurate retention rates (users who don't engage on day of installation). For that reason, many marketing teams use cumulative revenue earned divided by day-0 users as an alternative measurement for ROI calculation.
Lifecycle reports factor in user eligibility, whereas relative reports do not.
If you choose to use cumulative revevenue earned be aware: LTV calculations include users who have reached the appropriate age, whereas cumulative relative reports only report on the total earned to date. You may inadvertently lessen your user metrics by not letting your cohort mature.
For instance, if on March 30th, you're running a 30d performance report starting on March 1st, your LTV report will use retention rates and earnings only for the users who've aged 30d (those who installed March 1). A cumulative report's day 30 will include revenue from users who've installed on March 1st but will not have revenue from cohorts <30d old (March 2nd-March 30th). Therefore will be lower.
Last updated
