Plan your event tracking
Learn about the different types of events in Singular and how to measure them.
-
You can also quickstart with Standard Events, which are easy event presets in Singular.
- If anything remains unclear or you run into issues, see the Events FAQ.
| Guide for | Marketing and User Acquisition Teams |
| Prerequisites |
Use Singular as your attribution partner (MMP). |
Based on your business needs, you will want to analyze user behavior and in-app events differently. This article shows you what properties to assign your events so you can analyze them in Singular.
Cohort vs. Actual Analysis
Watch a video tutorial:
| Cohort Analysis | Actual Date Analysis | |
|---|---|---|
|
What is it? |
A cohort is a group of users that installed your app on the same day. Often, this is a group of new users you've targeted with an ad campaign. Studying how these users interact with your app1 is cohort analysis. |
Measuring events data for specific dates, outside of the context of user lifecycle, is called actual date analysis or actual analysis. Actual analysis helps you understand the performance of your business as a whole as on a particular date. |
| What users are you looking at? | Your dataset is a cohort of new or re-engaged2 users with a shared conversion date. | Your dataset is your entire user base, regardless of the conversion date. |
|
What does the report date range mean? |
The date range of your report represents the install dates of the cohort. Since you're measuring a specific group of users, your report may show you events that occurred outside of the date range3 of the report. |
The date range of your report represents the dates on which the events occurred3. Since you're measuring by dates, your events cannot occur outside of the date range of your report. |
Additional Knowledge
All app users have a lifetime from install to uninstall. To get users to perform desirable events in your app (such as purchases), you establish a user flow of events. Each event can then be measured.
Cohort analysis is studying how quickly and reliably users follow your defined flow of events.
In addition to installs, there's another type of conversion called re-engagement. This affects cohort analysis because when a user is re-engaged:
- A new process of attribution is triggered.
- The user's conversion date is the date of re-engagement, not the date of the original install.
- The network that triggered the re-engagement is attributed with the conversion and any subsequent in-app activity, including revenue.
Let's say you're building a report with a date range of Jan 1 - Jan 3. If you're looking for data on all the events that happened during those 3 days, use the "Actual" cohort period in your report.
If you're looking for insights into user behavior of new users acquired during those 3 days, select any other cohort periods.
These cohort periods are rolling dates relative to the install event, rather than the actual calendar dates. A 1d cohort period represents 24 hours after install, e.g., if a user installed your app at 3pm on Jan 1, then their Day 1 (d1) events are those events that occurred between Jan 1, 3pm and Jan 2, 3pm.
Cohort periods are also cumulative. A 3d cohort period contains all the events that happened on d1, d2, and d3 of that user's journey.
This is an excerpt from the full example below. This user installed the app on Jan 1, and made 2 purchases on Jan 3.
| User | Install Date | d1 (24 hours post-install) | d2 (48 hours post-install) | d3 (72 hours post-install) |
|---|---|---|---|---|
| User 2 | Jan 1, 3pm | Purchase $5 Jan 3, 11am |
Purchase $5 Jan 3, 6pm |
- Rolling date: If you measure the 2d cohort, revenue from this user is $5, despite the event happening on Jan 3.
- Cumulative: If you measure the 3d cohort, revenue from this user is $10.
Let's say these are the events that occur from a cohort of 5 users who installed the app between Jan 1 and Jan 5.
| User | Install Date | d1 (24 hours post-install) | d2 (48 hours post-install) | d3 (72 hours post-install) |
|---|---|---|---|---|
| User 1 | Jan 1, 3pm | Purchase $5 Jan 2, 2pm |
||
| User 2 | Jan 1, 3pm | Purchase $5 Jan 3, 11am |
Purchase $5 Jan 3, 6pm |
|
| User 3 | Jan 2, 3pm | Purchase $5 Jan 4, 2pm |
||
| User 4 | Jan 3, 3pm | Purchase $5 Jan 6, 9am |
||
| User 5 | Jan 5, 3pm | Purchase $5 Jan 6, 9am |
Here are some example insights using both cohort and actual analysis.
| Report Date | Cohort Period | Metric | Value | Explanation |
|---|---|---|---|---|
| Jan 1-5 | N/A | Installs | 5 | There were 5 installs between Jan 1 to Jan 5. |
| Jan 2 | Actual | Revenue | $5 | User 1 made a purchase worth $5 on Jan 2. |
| Jan 6 | Actual | Revenue | $10 |
User 4 and 5 made purchases with a total worth of $10 on Jan 6. |
| Jan 1-5 | 3d | Revenue | $30 | From the users who installed between Jan 1 to Jan 5, there were 6 revenue events within 3 days of install with a total worth of $30. |
| Jan 1-5 | Actual | Revenue | $20 | Between Jan 1 and Jan 5, there were 4 revenue events with a total worth of $20. |
Unique Cohorts and Unique Actuals
When you want to measure the number of users who performed an event, instead of the number of events performed, you use unique events, i.e. how many distinct users made a purchase (unique event) vs. how many purchases were made (non-unique event; a single user may have multiple purchase events).
| Unique Cohort Events | Unique Actual Events | |
|---|---|---|
|
What are you measuring? |
You're measuring how many unique users out of a given cohort performed an event within the given cohort period. You may also think of this as how many users performed an event at least once within the given cohort period. |
You're measuring how many users performed an event within the given report period. Tip: To measure Unique actual events, legacy accounts will need to contact Singular. Accounts created after June 7th, 2023 can measure unique actual events by default2. |
|
Example |
"Of the users who installed the app between Jan 1 - Jan 5, how many users made a purchase event within 3 days of installing the app?" Here, your report date range is Jan 1 - Jan 5, your cohort period is 3d, and you're measuring unique purchase events1. |
"How many users made a purchase event between Jan 1 - Jan 5 regardless of their install date" When selecting multiple days in the date range (for example Jan 1 to Jan 5) - the report will return the average number per day. For example - if in the 5 days between Jan 1 and Jan 5 the number of users that made a purchase was 1,2,2,3,2 then the report will return 2 which is the average across those days. |
Additional Knowledge
In the Singular platform, when you go to Settings > Events and create a New Event, there's a toggle to filter unique events. Go to 2. How to Track Events.
The Daily Active Users (DAU) metric is a ratio calculation of the number of unique users who had at least one session in the day. For periods of more than one day, the DAU is the average of the daily active users for the selected days.
For legacy accounts, DAU is calculated using rolling days since the user's time of attribution. For new accounts (created after June 7th, 2023) or accounts where Unique Actuals have been enabled - DAU is calculated using actual calendar dates.
Let's say these are the events that occur from a cohort of 5 users who installed the app between Jan 1 and Jan 5.
| User | Install Date | d1 (24 hours post-install) | d2 (48 hours post-install) | d3 (72 hours post-install) |
|---|---|---|---|---|
| User 1 | Jan 1, 3pm | Purchase $5 Jan 2, 2pm |
||
| User 2 | Jan 1, 3pm | Purchase $5 Jan 3, 11am |
Purchase $5 Jan 3, 6pm |
|
| User 3 | Jan 2, 3pm | Purchase $5 Jan 4, 2pm |
||
| User 4 | Jan 3, 3pm | Purchase $5 Jan 6, 9am |
||
| User 5 | Jan 5, 3pm | Purchase $5 Jan 6, 9am |
||
| User 6 | Jan 5, 5pm |
Here are some example insights using both cohort and actual analysis.
| Report Date | Unique | Cohort Period | Metric | Value | Explanation |
|---|---|---|---|---|---|
| Jan 1-5 | N/A | N/A | Installs | 5 | There were 5 installs between Jan 1 to Jan 5. |
| Jan 1-5 | 🚫 | 3d | Revenue | $30 |
Non-unique Cohort: From the 6 users who installed between Jan 1 and Jan 5, there were 6 revenue events within 3 days of install, for a total worth of $30. |
| Jan 6 | 🚫 | Actual | Revenue | $20 |
Non-unique Actual: Between Jan 1 and Jan 5, there were 4 revenue events for a total worth of $20. |
| Jan 1-5 | ✅ | 3d | Revenue | 5 | Unique Cohort: Out of the 6 users who installed between Jan 1 and Jan 5, there were 5 unique users who triggered revenue events within 3 days of install. |
| Jan 2-4 | ✅ | Actual | Revenue | 3 | Unique Actual: Between Jan 1 and Jan 5, there were on average 1 unique users who triggered at least one revenue event. In the table above you can see that there was one user that made a purchase event on Jan 2, one that made a purchase on Jan 3 , and one that made a purchase on Jan 4. The report will return the average of those values |
First Events
When you want to measure how many new users performed an event for the first time, you use first events.
| First Cohort events |
|---|
|
Since cohort events are in the context of the lifetime of a new user, first cohort events (first-time users) are the same as unique cohort events (unique users). Set up a unique event in your SDK and aggregate it on the Settings > Events page. See 2. How to Track Events. |