The Role of Entities in Event Data

This guide is part 3 of a 5-part series titled Understanding First-party Data.

{{line}}

Event data is incredibly helpful to decipher what is going on inside a product or how something is being done. However, unless you know who is performing those events, there’s not much you can do in terms of segmentation and understanding user personas.

This is where entity data comes into play where 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 behavior by answering questions like:

• How many unique users performed the event Campaign Sent?
• Which users performed this event?
• What is the average number of events a user segment performed before performing the event Campaign Sent for the first time?
• Which events were performed by the user segment before this event?

That’s not all though. Associating events with the right entities is key to personalization—better onboarding via contextual in-app experiences, engagement and activation via lifecycle messaging, excluding customers from acquisition campaigns, and proactive outreach to the right users from accounts that are at-risk or expansion-ready.  

Let’s dig deeper.

One event, multiple entities

User is the primary entity associated with every event performed by a user. But when a user is part of a group or an account—organizations or workspaces in the context of B2B SaaS products—Account is also an entity that needs to be associated in order to provide more context about events and track user activity at an account (or group) level.

Since an account comprises multiple users, associating the right account with user events helps understand the overall health of an account and answer important questions such as:

• How many accounts are activated?
• What is the average number of users for active accounts?
• How many accounts contain X or more users?

It helps to keep in mind that the collective actions of users in an account often contribute towards activation rather than those of a single user.

Therefore, SaaS products that are used by multiple users collaboratively need to associate multiple entities—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 the user John Doe creates a new project inside a project management app used by an organization Acme Corp with 10 users, two important pieces of information are generated:

1. John Doe created a new project: John Doe performed the event Project Created
2. A new project was created inside the organization Acme Corp: The event Project Created took place inside the organization Acme Corp

Failure to associate the event with the organization will result in the 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 any specific user.

Whether such events take place automatically (the card on file couldn’t be charged) or as a result of a user action, it can be helpful to associate these organization-level events with all users in an organization. This ensures that you are not restricted to engaging only with the owner of the account and that other users in the account can be notified when such events take place.

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. Moreover, combining user events with the right organizations at a later time either won’t be possible or will be a huge pain for your data engineers.

And this problem exacerbates multifold if your product enables a user to be part of multiple accounts.

One user, multiple accounts

It is quite common for a user to be associated with multiple accounts in the context of SaaS tools. Notion, ClickUp, and Integromat are a few popular tools that allow a unique user to join or create multiple organizations or workspaces, each with a distinct subscription.  

This means that the same user performs events under multiple accounts but those events are unrelated as they don’t necessarily take place under the same account or organization.

For products that allow one user to be part of multiple organizations, to track account-level activity, for every user event, you’d need to know under which organization is the event being performed. In other words, the right organization_id will have to be associated with each event.

Failure to do so will result in a skewed data set where you’d be able to see all the events a user has performed across all accounts but with no way to know which event pertains to which account. This will eventually lead to poor business decisions as well as customer experiences powered by incorrect data, the outcome of which can be significantly detrimental.

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, which is key in the case of B2B SaaS.  

{{button}}

Not just an identifier

Entity data not only helps identify the user (who performs an event) or the organization (under which the event was performed), but also provides a lot more information about both the user and the organization.

It can be helpful to categorize entity data into the following buckets:

• Personally identifiable information such as name, email, and phone
• Demographics such as age, gender, and location
• Personas such as industry, job_role, and goal
• Preferences such as brands, genres, and product_categories
• Account data such as subscription_type, number_of_users, account_manager, and renewal_date

Specifying the entity properties is a crucial step in the process of setting up event tracking, which will be covered in a future guide.

Moving forward with entities and event data

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 move on to part 4 which covers the components of event data.

{{line}}

This is the latest version of this guide. The original version was published on Data-led Academy in 2020 and was updated and moved to the Amplitude blog in 2022. Please be aware that you might find plagiarized versions of this guide when searching for related keywords.