There are two ways to spend your post-product-release time.

One: You could spend a bunch of time and effort bugging your data experts to let you in on what your data is telling them, and then struggle to use that information to improve your product (slowly).

Two: You can quickly glean valuable insights from your data yourself and get started on the next cutting-edge feature release to delight your users.

Which would you prefer? Our 💰 is on option two.

Well, picking good events and properties is the key to ensuring that your post-release hours are spent celebrating your successes, not lamenting a lack of clarity in your product performance.

To really capture data-driven success, you and your team should pick your tracking-plan events and properties during your pre-release purpose meeting. Each of them should be mapped directly to your goals and metrics.

Here’s how to do it:

When to start looking at your events and properties

When it comes to designing and setting up your tracking-plan events and properties, the earlier you can sit down with your team, the better. Ideally, companies should set their events and properties during their pre-release purpose meeting.

We define a purpose meeting as a 30-minute get-together that includes all of your product’s main stakeholders and is held before every major release.

This meeting should include the following people:

• An engineer from each platform
• A product manager
• A designer
• A data specialist

You should use this time to align on the purpose of your product release and map out your highest-impact, lowest-effort tracking design to understand your release success.

Start the meeting off by aligning on your overall business goals and committing to the metrics you’ll use to measure success. Then, you can get to work on designing the events and properties that will feed into those metrics.

By picking your events and properties during this early stage, you reduce the chance of needing to refactor analytics down the road. This not only saves time and money but also preserves your sanity.

What to look at when choosing your events and properties

To collect good data, choose events and properties that support your goals and metrics. Good data is the kind that gives you insight into user interactions and the context around them (versus bad data, which is information you collect just because you might need it someday).

Your events and properties should fill in the blanks between the metrics you want to track and the way they connect to your customer behavior.

‍

Each new layer of your tracking plan—from product goals to metrics to events to properties—will uncover a new layer of information about your product and your users. As you move down your data funnel, from the highest level to the most granular tracking, you should stop to ask questions to further break down the information you’re looking for.

To start selecting your events and properties, you can ask yourself and your stakeholders the following questions to understand the reason for your release (it’s good to start with the basics):

• What are we trying to help users do?
• What problem are we trying to solve?
• Who are we solving it for?
• What does success look like?

Then, once you have a framework to understand your product mission and its success, you can dig a little deeper to set your metrics (which will inform your events and properties). Here are some additional questions you can ask to arrive at your metrics:

• How will we know when we’re successful?
• What steps do users need to take to achieve this success?
• Are there any points of dead ends or user drop-off that we want to keep an eye on?
• Should we compare cohorts of users and A/B test the release?
• Is our conversion achieved through a set of steps, a total count of something, or a rate?
• How do we visualize and compare these metrics (e.g., time series, bar chart, bar per group, line per group)?

Once you have answers to these preliminary questions—and, as a result, know your goals and metrics—you can begin to identify your individual events and properties.

How to choose your events

To choose events, identify the questions that you most want to be answered about your product or features. Your answers to these questions will point you toward your events.

You can start at a high level with these questions by breaking down the steps that each user must take in order to count toward your success metric. From there, you can narrow it down to more specific queries to identify each action a user must take in order to impact your identified metric.

Let’s say you’re launching a new paid plan for a music streaming service. 🎵 If one of your main metrics and KPIs is to increase upgrades for the new paid tier from existing free users, you could ask the following questions to identify your first batch of events:

• What is the first action a user has to take to begin the free sign-up process?
• What is the last action a user has to take to complete the free sign-up process?
• What is the first action a user has to take to upgrade their plan?
• What is the last action a user has to take to upgrade their plan?
• What are important milestones between the first and last action?
• What actions could the user take to show us that they’ve dropped out of the funnel or hit a dead end?

The answers to the first five questions, respectively, would tell you that you need to track when a user views the plans page, when they submit account info for a free plan, when they log in, and when they submit payment information. For the last item on the list, the user would exit out of the site without completing payment.

Your events reflect specific actions your users take (or things that happen to them) along their full user journey within your product. Look at the metrics you’ve decided on, and start asking questions to drill down on what users have to do in order to count toward improving the metric (in the case of our example, the metric would be “increased upgrades to paid user”).

Once you have identified the events that support your higher-level metrics, you can dive deeper into the properties that support them.

How to choose your properties

Once you’ve set your events, you can begin to identify further insights you need and then figure out how you’ll segment your data with properties by mapping out the specific parts of each page and feature users interact with on their way to converting.

Properties are the dimensions (metadata) you’ll use to filter and group your events (they’ll help you clarify and get context on higher-level events). Off the bat, start with the questions about user segments you know you need (you can always add properties later when specific questions arise). This helps you reduce the noise from a bunch of data.

Building on our streaming example from before, let’s break down our events—view page, complete registration, log in, change plan, and abandon session—into their supporting properties. First, you should talk to your designers and programmers to identify each of the on-page elements the user must interact with to move further down the funnel. You’ll build a plan to track three categories of properties:

1. Event properties that are specific to the action the user performed. Example: "Game Mode" on the "Game Started" event or "Authentication Method" on the "Signup Completed" event.
2. User properties that are associated with the user and can be used for cohorting (analyzing a certain group of users). Example: "Games Count", "User Name" or "Subscription Status."
3. System properties that are sent with all events and don’t change during a user session. Example: "Platform" and "App Version."

For example, when our users log in, we want to track when they click the login button, when they enter their email address, and when they’re successfully authenticated. Then, when they’re ready to upgrade, we’ll want to track properties for payment type and payment validation.

To further understand where our users are coming from and what experiences they’re having, we also would want to track a number of system properties that span events (i.e., we collect the information at multiple points throughout our tracking). These properties include things like what platform (web versus mobile ) or browser type (Chrome versus Firefox) they’re using.

Now, with a robust combination of goals, metrics, events, and properties included in your tracking plan, you’ll be able to gain valuable insights into your product and user experience throughout your funnel and directly connect this data to your overall business goals.

What to do once you select your events and properties

Once you’ve designed your data by choosing events and properties that tie into your metrics and goals, it’s time to ship! 🥑 Well, almost.

Before you take everything live, you’ll need a document that’s your single source of data truth. This can be a spreadsheet (like this awesome tracking-plan template 😉) or a JSON file hosted on GitHub that outlines your events and properties. You’ll want to test your analytics before your full release to make sure no human errors snuck through during implementation.

Or, if you’d like to save yourself and your team some time (and make it easier to implement tracking analytics), you can use a tool like Avo. Avo replaces your old-school spreadsheet to give you a modern, single source of data truth that you can collaborate on with your team and tie into each platform you use. Plus, there’s no need to triple-check for human errors, because Avo handles the formatting of code—and sends instructions directly to developers—for you.

Get started on creating a better, easier data future by trying out Avo today.