Event data is incredibly helpful to decipher what is going on inside a product or how something is being done. However, without knowing who is performing those events, you cannot get a grip on your user personas and create user cohorts.
This is where entity data comes into play. User is the primary entity and user_id is the key property that needs to be associated with every event. Doing so, enables you to understand user behaviour by answering questions like:
- How many users performed the event Campaign Sent?
- Who are the users who performed the event Campaign Sent?
- How many events did a particular user perform before the event Campaign Sent?
- Which events did a particular user perform before the event Campaign Sent?
Besides understanding user behaviour, associating events with users enables you to send them relevant in-app messages and emails based on their actions.
One Event, Multiple Entities
While User is the primary entity, secondary entities like Account or Product can also be associated with events in order to provide more context. This was covered briefly in part 1 of this series, but now is a good time to dive deeper.
Ecommerce stores and ride-hailing services generally offer more than one product, in which case product becomes a core entity that is associated with most events.
In many cases, especially for SaaS products, it is essential to track user activity or events at an account (or group) level. This is due to the fact that an account can have multiple users and their collective actions indicate what’s going on within that account.
Thus, you need to associate multiple entities — typically user and account — with every event.
If an account is referred to as an organization, on top of the user_id, the organization_id needs to be associated with events in order to know which user performed an event, and under which organization.
For instance, if a user (X) creates a new project inside a project management app used by an organization (Y) with 10 users, two important pieces of information is generated:
- X created a new project or X performed the event Project Created
- A new project was created inside organization Y or the event Project Created took place in organization Y
Besides associating the event Project Created with the user, failure to associate the event with the organization will result in a loss of the second piece of information.
Additionally, subscription-related events such as Trial Started, Trial Ended, and Subscription Cancelled take place at the organization level and do not pertain to a user. Irrespective of whether such events take place automatically or as a result of a user action, it can be helpful to associate them with all the users in the organization. Doing so ensures that you are not restricted to engaging only the owner of the account.
Failure to associate events with accounts will hinder analysis and engagement efforts as you will only have data pertaining to the actions of individual users; combining that data with organization data will be a huge pain.
The problem only exacerbates if your product enables a user to be part of multiple accounts.
One User, Multiple Accounts
In B2B SaaS, it is common for a user to be associated with multiple accounts or organizations.
Apps such as Notion, ClickUp, and Integromat allow a unique user to join or create multiple organizations.
This means that the same user performs events under multiple accounts. However, those events are unrelated as they don’t take place under the same account or organization.
For products that allow one user to be part of multiple organizations, it is paramount to know under which organization did a user perform an event in order to track account-level activity.
In conclusion, when one user is part of multiple accounts, you need to isolate user activity that takes place under each account to understand what is going on at an account-level.
If entities (user, organization, workspace, etc.) are not associated with events correctly, your data set can get heavily skewed. Not being aware of such issues can lead to business decisions being taken on incorrect data, the outcome of which can be significantly detrimental.
Not Just an Identifier
Let’s go back and assume the user to be the only entity for a product.
Entity data not only helps identify the user who performs an event, but also tells you a lot more about that user. It is a good practice to categorize entity data into the following buckets:
- Personally identifiable information such as name, email, and phone
- Demographics such as age, gender, and location
- Persona such as industry, job role, and goal
- Preferences such as brands, genres, and product categories
- Product-specific data such as products purchased, apps used, time spent, and subscription type
Specifying the entity properties is a crucial step in the process of setting up event-tracking, and is covered in detail in the tracking plan guide.
Thinking about entity properties (that help in segmenting users) might spark new ideas or bring up queries related to user segmentation such as what data is gathered when a user signs up for your product.
Are you asking the right questions and providing users with relevant options? Do you need to modify those questions or ask new ones to better understand user personas? What about the naming convention of the properties or the data type of each property?
While it might seem a bit much to mull over all those minute details, it is important to ask those questions sooner rather than later to ensure that you collect clean data, that is easy to analyze and act upon.
You now know the role entity data plays in the process of gathering event data which means it’s a good time to see what events and entities look like and learn how to define them properly.