{"id":3684,"date":"2021-04-08T22:03:13","date_gmt":"2021-04-08T16:33:13","guid":{"rendered":"https:\/\/dataled.academy\/?post_type=guides-new&p=3684"},"modified":"2022-03-02T18:01:41","modified_gmt":"2022-03-02T12:31:41","slug":"components-of-event-data","status":"publish","type":"guides","link":"https:\/\/dataled.academy\/guides\/components-of-event-data\/","title":{"rendered":"What are the Components of Event Data?"},"content":{"rendered":"\n
This is part 4 of the 5-part series on Customer Data. Here are parts 1,<\/a> 2,<\/a><\/em> 3,<\/a><\/em> and 5<\/a><\/em>.<\/em><\/p>\n\n\n\n Customer Data comprises Event Data and Entity Data \u2014 you already know that if you have gone through the previous parts of this series. <\/p>\n\n\n\n In this guide, you will learn about the components of event data, the preferred naming convention to define events, the categories of entity data, and the two main types of entities.<\/p>\n\n\n\n Since you have certainly bought stuff online, let\u2019s start with an ecommerce example.<\/p>\n\n\n\n When interacting with an ecommerce website or app, you typically buy a product by adding it to your cart, proceeding to checkout, and completing the payment. From the product\u2019s perspective, these are events that took place when you went through the process of buying an item. <\/p>\n\n\n\n Needless to say, there could be several other events that take place during the buying process such as:<\/p>\n\n\n\n And so on. <\/p>\n\n\n\n Events that come to mind immediately are Add to Cart, Proceed to Checkout,<\/em> and Make Payment. <\/em>However, in order to understand user behavior, you would also need to track other important events like the ones mentioned above.<\/p>\n\n\n\n Deciding which events to track and naming the events using a proper naming convention are the first two steps in the process of gathering event data.<\/p>\n\n\n\n What are the next two steps? Each event <\/em>is accompanied by event properties<\/em> (or event attributes<\/em>) that provide more context about an event. Deciding which properties <\/em>to associate with each event and naming those properties are the next two steps in the process of gathering event data. <\/p>\n\n\n\n When it comes to data, everything! A proper naming convention is what makes good data stand out from bad data, making it easy for all stakeholders to understand what they are looking at. Not maintaining a standardized taxonomy is one of the main causes that lead to data sets being skewed or bloated with redundancy. <\/p>\n\n\n\n Also, a good naming convention comes with strict casing guidelines. When working with customer data, not maintaining uniform casing when naming events and event properties is one of the biggest mistakes you can make \u2014 one that can have long-term ramifications. <\/p>\n\n\n\n Add to Cart, added_to_cart, productAdded, add to cart, Added to cart, Product Added <\/em>are different ways to define the same event. <\/p>\n\n\n\n There are no set rules or the right way when it comes to naming events and properties. However, there are best practices laid out by companies leading the customer data space. <\/p>\n\n\n\n Segment is one such company and it developed the object-action framework<\/strong> \u2014 a naming convention that has become the industry standard. Take a look at this short guide<\/a> explaining the framework and covering the best practices of naming conventions. <\/p>\n\n\n\n Entity data (such as user_id<\/em>) provides more information about who performs an event. In the absence of a unique identifier like user_id<\/em>, you can only have anonymous event data as there will be no way to know who performs an event. <\/p>\n\n\n\n However, when an event takes place, there are many other pieces of related information that can be gathered. Those additional pieces of information are gathered in the form of event properties.<\/em> Let\u2019s look at the event Product Added<\/em> \u2014 the name for Add to Cart<\/em> as per the object-action framework in the Proper Case \u2014 and assume that it was performed by a user on Jan 1, 2020, at 10 AM UTC. <\/em>The data gathered when the event took place includes the following:<\/p>\n\n\n\n As per this example, the properties associated with the event Product Added <\/em>are user_id, product_id, price, <\/em>and quantity<\/em>, each of which provides more information about the event. And to know when the event took place, the timestamp <\/em>is associated with it. You might have already noticed that the snake_case is being used to define event properties which makes it easy to distinguish event names from event properties. That said, remember, there is no right way and you should choose whatever works best for you and your team. <\/p>\n\n\n\n Here\u2019s a final look at the properties associated with the event Product Added and the data types of each of those properties:<\/p>\n\n\n\n Specifying the data type for each property ensures consistency of data and makes the instrumentation process easier.<\/p>\n\n\n\n Side note:<\/strong> It\u2019s good to keep in mind that user_id <\/em>is a user property (entity data) that acts as the identifier for an event and is therefore passed as an event property. Similarly, there can be other entity data that you might want to pass with certain events which is covered under Entity Data below.<\/p>\n\n\n\n It should now be clear that gathering event data comprises the following steps:<\/p>\n\n\n\n The next and the last part of this series covers the process of deciding which events to track and what data to gather.<\/p>\n\n\n\n However, you should have a good idea of what to expect when looking at event data (whether in a tracking plan before instrumentation or inside a data destination such as your product analytics tool). The process of creating a tracking plan is covered in extreme detail in the guide titled \u201cWhat the hell is a Tracking Plan and How Can I Create One?<\/a>\u201d <\/p>\n\n\n\n Before moving on, take a look at a few common events and properties that are tracked by most tech products.<\/p>\n\n\n\n It\u2019s time to take an in-depth look at different entities and their properties.<\/p>\n\n\n\nIntroduction<\/h2>\n\n\n\n
Event Data<\/h2>\n\n\n\n
Glad you asked! <\/p>\n\n\n\nWhat\u2019s In a Name?<\/h3>\n\n\n\n
Components of Event Data<\/h3>\n\n\n\n
For instance, when a product is purchased, besides knowing who <\/em>made the purchase, at the very least, you also need to know what product<\/em> was purchased at what price, <\/em>and when<\/em>.<\/p>\n\n\n\n
In the guide to Customer Data, it was mentioned that event data comprises three key elements: <\/p>\n\n\n\n
It is also useful to specify a name for the timestamp which is essentially an event property. It\u2019s not mandatory to do so as it is standard practice to associate the timestamp as timestamp<\/em> with every event when sending data to third-party tools.
However, specifying a distinct name for the property that stores the timestamp can be helpful in the long run when you need to work with historical event data.
The recommended taxonomy for timestamps is the event name followed by \u201cat\u201d \u2014 product_added_at <\/em>for the event Product Added. <\/p>\n\n\n\n
<\/figure><\/div>\n\n\n\nSome Common Events and Their Properties<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n\nEntity Types<\/h2>\n\n\n\n