{"id":3682,"date":"2021-04-08T21:58:53","date_gmt":"2021-04-08T16:28:53","guid":{"rendered":"https:\/\/dataled.academy\/?post_type=guides-new&p=3682"},"modified":"2022-02-07T16:05:33","modified_gmt":"2022-02-07T10:35:33","slug":"entities-and-event-data","status":"publish","type":"guides","link":"https:\/\/dataled.academy\/guides\/entities-and-event-data\/","title":{"rendered":"What are Entities in the Context of Event Data?"},"content":{"rendered":"\n
This is part 3 of the 5-part series on Customer Data. Here are parts 1,<\/a> 2,<\/a><\/em> 4,<\/a><\/em> and 5<\/a><\/em>.<\/em> It is also highly recommended to go through part 1 (<\/em>What Is Customer Data?<\/em><\/a>) before this one.<\/em><\/p>\n\n\n\n Event data is incredibly helpful to decipher what <\/strong>is going on inside a product or how <\/strong>something is being done. However, unless you know who <\/strong>is performing those events, there\u2019s not much you can do in terms of segmentation and understanding user personas.<\/p>\n\n\n\n This is where entity data <\/em>comes into play where User <\/em>is the primary entity and user_id <\/em>is the key property that needs to be associated with every event. Doing so, enables you to understand user behavior by answering questions like: <\/p>\n\n\n\n Besides understanding user behavior, associating events with users enables you to send them relevant in-app messages and emails based on their actions.\u00a0<\/p>\n\n\n\n User <\/em>is the primary entity associated with every event performed by a user. But when a user is part of a group or an account \u2014 organizations <\/em>or workspaces <\/em>in the context of B2B SaaS products \u2014 Account <\/em>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.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Therefore, SaaS products that are used by multiple users collaboratively need to associate multiple entities \u2014 user <\/em>and account <\/em>\u2014 with every event. <\/p>\n\n\n\n If an account is referred to as an organization, on top of the user_id<\/em>, the organization_id<\/em> needs to be associated with events in order to know which user<\/em> performed an event, and under which organization.\u00a0<\/em><\/p>\n\n\n\n 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: <\/p>\n\n\n\n Besides associating the event Project Created <\/em>with the user<\/em>, failure to associate the event with the organization<\/em> will result in the loss of the second piece of information. <\/p>\n\n\n\n Additionally, subscription-related events such as Trial Started<\/em>, Trial Ended<\/em>, and Subscription Cancelled <\/em>take place at the organization level and do not pertain to any specific user. And this problem exacerbates multifold if your product enables a user to be part of multiple accounts.<\/p>\n\n\n\n In B2B SaaS, it is common for a user to be associated with multiple accounts or organizations. <\/p>\n\n\n\n Apps such as Notion, ClickUp, and Integromat allow a unique user to join or create multiple organizations. <\/p>\n\n\n\n This means that the same user performs events under multiple accounts. However, those events are unrelated as they don\u2019t take place under the same account or organization.<\/p>\n\n\n\n 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. If entities (user, organization, workspace, etc.)<\/em> 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. <\/p>\n\n\n\n Let\u2019s go back and assume the user to be the only entity for a product. <\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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<\/a>.<\/p>\n\n\n\n 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. 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. <\/p>\n\n\n\nIntroduction<\/h2>\n\n\n\n
One Event, Multiple Entities<\/h2>\n\n\n\n
Whether such events take place automatically (the card on file couldn\u2019t 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.
<\/em>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\u2019t be possible or will be a huge pain for your data engineers.<\/p>\n\n\n\nOne User, Multiple Accounts<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
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.<\/p>\n\n\n\nNot Just an Identifier<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
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? <\/p>\n\n\n\n