Important: As of May 21, 2024, this page will no longer be actively maintained. Please refer to the current version of this content here.
Events in the Query Builder can be modified by introducing filters or by grouping results into different breakouts. These features make use of properties, which are typically sent along with the event data to describe characteristics of the events or the users who performed them.
When building queries, it’s important to keep in mind that Analytics will process the results very differently depending on the type of property used. This article is intended to illustrate the differences between event and user properties to help efficiently build queries that give the most accurate results.
Event Properties
When an event property is used in an analysis, Analytics will look at each individual event’s payload and reference the property associated with each event. The event property has the query ask “what was the value of the property at the time of the event?”, which is the most common scenario for most analyses.
- For rows set to display the “total count of” events, the results will include all of the events seen as long as they meet the query parameters, even if they were performed by the same user multiple times.
- For “users who performed” rows, event properties will still filter or group based on each time that the event was seen, but the results will represent user counts instead of raw event counts.
User Properties
User Properties are the properties associated with the user performing an event, such as demographic factors, an email address, or the marketing channel through which the user was originally acquired. While event properties can differ from event to event, user properties are associated with every event performed by a given user.
In order to enable user properties for use in queries, the Attribution Mode under Manage Data must be set to either first or last.
Consider the example table of events below:
- ‘First’ will store the first value seen for a property for each user across any event that they fire. From the image above, user 1’s first value for this property will be NULL, user 2’s will be Social, and user 3’s will be Search.
- ‘Last’ will store the last value seen for a property for each user across any event that they fire. From the image above, user 1’s last value for this property will be Search, user 2’s will be Social, and user 3’s will be Search.
- Because user properties are stored at the user level, the scope of the analysis does not impact what value is stored at the user level. For example, if an analysis was looking at events that occurred between 8/18-8/20 from the example above, user 1’’s value for the property will still be NULL if this user property was configured for First attribution mode.
Thus, user properties are selected to view results from users who performed a particular action, even if their first or last actions are beyond the scope of the analysis that has been created.
Building Your Query
In the Analytics app, events can be filtered by event or user properties, grouped by those properties, or both:
In the finished analysis, the query row will indicate which type of property was used.
When to Use Event vs. User Properties
To better illustrate the differences between event and user properties in Analytics, consider the example of a query set to view the event BannerImpression with the property Channel, where the date range is equal to 8/17 - 8/20.
Here, filtering by “events’ Channel equals Search”, for example, would essentially pose this question: “Give me the total count of events performed between 8/17 and 8/20 where the property Channel is equal to Search.
The results, filtered by event property, would show one event.
Let’s say that the user property for Channel is set to ‘Last Seen’. If the filter is set to “users’ Channel equals Search, the query instead asks: “Give me the total count of any events performed between 8/17 and 8/20 where the user who performed them had a last-seen value of Search.
In this case, the results, when filtered by user property, would show five events: four performed by userID = 1, and one performed by userID = 5. userID = 1 shows up four times because they performed the BannerImpression event within the time window, while having a last-seen value of Search.
Because user properties focus more on the individual users than on the events, they can be useful for cases focusing on the user journey. Questions that might benefit from filtering or grouping by user properties might be:
- What does a funnel look like for users who became a subscriber, vs. users who did not?
- What types of banner impressions were seen by users who started by viewing the blog?
- What is the most effective first or last channel (When grouping by users’ first or last seen channel)?
A/B Testing Best Practices
When setting up A/B tests in Analytics, the best practice is to set up the data to use event properties, for several reasons:
- User properties will show whether the users are in an experiment or not, but will not take into account the time that they performed the event, as discussed in the above sections. Event properties will take into account the time of the event, as well as when the user entered or exited the experiment.
- Typically, users are placed into experiments based on their user ID, which means the variant will remain constant through the experiment. However, in experiments that use cookie ID, there is a risk that aliasing will combine users with different cookie IDs under the same user ID, making event properties a more accurate method for tracking these variants.