To effectively socialize an information hub in organizations and across different teams, the following practices work the best: 

It's essential to make the hub user-friendly, structured and relevant so anyone could use it without additional help. 

Education is very important to raise awareness: regularly educate people for whom the hub may be useful on what the possible use cases are, how it can be useful for them, and how to navigate there to find what they need. In this case a format of short workshops works well. 

Additionally, integrating the hub into the workflow by linking it with other commonly used tools can significantly increase its visibility and usage.

To ensure you’re tracking only the essential data, it’s important to start from the purpose of tracking in the first: measuring important metrics. The approach I usually recommend is to decide what data to track based on the metrics that are selected carefully and that are aligned with the execution of strategy and goals. When choosing metrics, always stop and ask yourself: “What questions do we need these metrics to answer for us to measure the journey towards realizing product strategy?” It’s important to do this exercise because it prevents you from falling into the “track everything” mindset. The point is that the metrics you choose to measure need to be associated with a question you need answered, not because it “seems like something we might want to track.” 

After the right metrics are defined, you can start defining what interactions to track in analytics. By this point, it’s already very clear what exactly is needed. This approach ensures that every data point you choose to collect is relevant and valuable, and that there is nothing extra.

When it comes to removing any potential noise in your data, there are a few things to keep in mind. First, regularly cross-check the historical trends in your data for anomalies. If metrics deviate significantly without a clear reason, they may be misleading. 

Second, if you have several sources of the same data, cross-check them regularly as well. If the metrics differ significantly across the sources, this is a signal that something is not correct in tracking in one of the sources and requires further investigation. 

Third, listen to the feedback from end-users or stakeholders. If the data contradicts their experience or expectations, it's a signal to check the correctness of data. 

Finally, keep in mind that any changes in how data is captured can lead to misleading trends. Regular audits and open communication channels for feedback are key to maintaining data integrity, and will help to ensure that data collection methodologies remain consistent.

Keeping product analytics documentation updated is always a challenge. In my experience, the best way is to keep it within the product team, owned by a product manager or a product analyst. We usually establish a process for our clients of updating the analytics documentation every time when the team starts the development of a new feature/iteration. If a team wants to be data-driven and measure the impact of the product initiatives they launch, I recommend making analytics implementation a part of the definition of “done” for every new iteration and never launching a release without updated and implemented analytics.

When defining the important metrics to measure a product’s success, we always start by thoroughly analyzing the product vision, strategy and goals. At Datamatterz, we prioritize metrics that are not vanity ones, but rather those that are actionable and directly reflect the product's core value. 

Our process involves a careful selection of key metrics for every stage of the user funnel (Acquisition, Activation, Retention, Revenue, and Referral), and which are aligned with the execution of strategy and goals. 

In short, our standard process is: Vision → Company & Product Strategy → Goals → Metrics

At Datamatterz, we usually use metrics trees to map the key product metrics. A metrics tree is a good visual tool that breaks down high-level objectives into more digestible, easily measurable metrics that are intended to help visualize the elements that contribute to an outcome. The root of the tree is a focus metric (North Star) and the branches are impact metrics.

Such visualization makes it easier for all stakeholders and team members, regardless of their technical expertise and role, to understand how their product’s success is measured on different stages of the funnel and how they personally can impact the overall goal through low level impact metrics they work with day to day. This understanding is an important part of establishing a data-driven culture across the company.

Sometimes we choose to focus on some part of the growth funnel more and track it more broadly; this depends on the company’s current goals and strategy. For instance, if a company's immediate goal is to enhance user activation and engagement, we concentrate our analytics efforts on these areas. Similarly, if acquisition metrics are not the immediate focus, we may not prioritize them and track as broadly. This doesn't mean they are neglected, but rather they are monitored in a more standard capacity, allowing us to focus more on the areas of activation and engagement. This selective focus helps ensure that the data we gather and analyze is most relevant to the company at the moment.

When naming events, we recommend establishing a consistent naming convention that uses: 

: Amplitude will capture [Song Played] and [song played] as two separate events, so this naming convention will help prevent messy data, especially when multiple teams are sending the same event. 

: Similarly, [Song Played] and [Played Song] will also be considered separate events. For example, a standard of [Noun] + [Past-Tense Verb] will make sure all your events are consistent. 

: Does [Message Sent] mean that the user sent a message or that we sent a message to the user? If all your events are always from the user's perspective, you'd know that this means the user sent a message. Our default events are Title Cased from the user's perspective, with a [Noun] + [Past Tense Verb]. 

You can establish your own convention if you wish, but the most important thing is that you remain consistent.

When deciding between first-, last-, and multi-touch attribution models, I would usually follow these steps to make the decision: 

Align the attribution model with your KPIs. If understanding which channels are most effective at initiating customer engagement and enhancing brand awareness is your goal, first-touch might be more relevant. If your goal is to refine closing strategies and understand which channels are best at closing sales, or you want to assess the immediate effectiveness of certain campaigns, last-touch attribution might be more appropriate. 

Consider your customer journey complexity. For simpler, quicker decisions, first- or last-touch might be enough. If a product or service typically involves a long decision-making process, multi-touch attribution might offer the most insights. This model is ideal for businesses with longer sales cycles and multiple interactions with customers, as it provides a comprehensive view of all interactions contributing to the final outcome. However, it is more challenging to implement and interpret, so it’s important to ensure you have the necessary tools and skills for that. 

Finally, test and refine. It's often beneficial to try out different models and adapt based on what you learn about how your customers interact with your marketing efforts.

This is a common mistake in a tracking set up, when events’ names include some part that should better be tracked as a property, leading to inconsistency and mess in the data and making analytics efforts more complex. For example, if we take a music app and an action of playing a song, a mistake would be to include the name of the song into the event name, e.g “Played Yellow Submarine”. Why is it a bad pattern? Because there can be thousands of songs and new ones added every week, so analytics will be flooded with thousands of different events like that, making it hard to navigate across them. When you want to see in the analytics platform what the top-played songs are, you’ll have to manually select all of the “played X” events just to find which have more occurrences—a simple task which will take too much effort. Instead, the right approach is to create an event name “Song Played” and put a song name as an event property, e.g. songName = “Yellow Submarine”. This approach will ease the navigation in collected data, remove mess, and allow you to quickly make breakdowns and find things like top played songs in a couple of clicks. In other words, the common principle is: avoid creating event and property names dynamically, put all dynamic values as property values.

Prior to registration there’s usually not much user data present in products. We analyze only the anonymized non-personal data which is provided by default in the analytics tool we use. After a user gets registered, we make sure to tie their earlier activity to their current profile, which allows our clients to see the whole user journey from the very beginning.

A common example is when a user upgrades from free to a paid plan in the product. Imagine you want to segment users by paying and not paying for analytics purposes. To have this data collected, you need to assign a user property, for example Paying = Yes/No. When a user has just registered and they are not paying yet, this user property is created for them with the value Paying = No. After some time, this user purchases a paid plan, in which case the existing user property value should be updated to become Paying = Yes.

The most common data types are integers, strings, and booleans. The data type of a property depends on which values you would like to put there and how you plan to use it in analysis. For example, if you want to have a user property which shows the total amount of purchases a user made, you might want to have it as an integer, in order to be able to apply filters with basic math equations (e.g. Purchases Count >= 2). String values allow you to apply filters by the expression that is included in values (e.g. Initial Referrer Page contains “My Website”).

Ksenia Khmelevskaya  

I created this to ease the creation and maintenance of tracking plans for product analytics.

. A place where all the setup data for your app's analytics is stored and managed. It can serve as 1) a reference for anyone in the team needing to know what product data you are collecting, 2) documentation for developers implementing the data tracking, and 3) a way to track the progress of implementation of this data in the product. Remember that you can customize any page or table in this workspace to fit your specific needs.

How should I approach this analytics setup?

💡 Here are all the things you need to successfully set up your product analytics. Start with defining metrics of your product in 📊

. This will help get an understanding of what data you’ll need and what’s important. 

Good data quality starts with a well thought out tracking plan. Plan and organize data you'll need to collect to get answers to all your questions: events in 🚀

After you have the data collected and charts built, you can come back to 📊

 and link metrics to the corresponding charts so you could have a full overview of your analytical taxonomy and navigate it easily and reliably. 

How to achieve the most quality of your analytical data? 

ℹ️ When creating a tracking plan it's important to make sure that the experience of querying, analyzing, and visualizing data is easy and understandable. An excellent experience has:  

Meaningful metrics: Start by understanding the needs, use cases, and key metrics for your product, so you can plan effectively. It should be clear what exactly is needed to be tracked and why.

 All data must be accurate and precise — achieved through iterative instrumentation and validation. Always test how your events perform before launching them live.

 Collect only meaningful, accurate metrics and actively eliminate cruft — misleading data, test data, duplicate events and properties, and deprecated items.

 1) keep analytics documentation clear and up-to-date, 2) name events and properties in an understandable manner, and 3) use consistent patterns and taxonomies. 

Why does my product need a list or metrics? 

The first step to creating a good tracking plan is brainstorming the key metrics that drive value for your product or the most likely questions about your product you'll be asking yourself in the future.

 With these things defined, it becomes much easier to define which user actions can help track those key metrics and answer questions. It will ensure you’re tracking everything you will need down the line and prevent you from collecting unnecessary data that will just bloat your analytics, and won’t help to get answers. This way, metrics can be then tied to the events in 🚀

When you have your charts and dashboards ready, you can link them to the corresponding metrics here to have easier and faster navigation over your analytics taxonomy.

At Datamatterz, we usually use metrics trees to map the key product metrics.

Sometimes we choose to focus on some part of the growth funnel more and track it more broadly; this depends on the company’s current goals and strategy.

Before your start, make sure you have a suitable naming convention for your events and properties. Edit the table below and write down a naming format of your choice so you could always refer to it when adding new events and properties.

What is a Naming Convention and why does my analytics need it

💡 It is crucial to get the naming of all your events consistent from the very beginning. This will not only make it easier to read your code and eliminate discrepancies, but it'll also mean that everyone at your company can easily find the events and understand what they mean. 

To come up with the naming convention for analytics that will be used in your company, define the following things:  

 It's recommended to follow one of the formats listed below for your event and property names. All of them have a good balance of consistency, human readability, and ease of parsing in code: 

[Object] + [Action in the past] + [optional: Context]: 

[Action in present] + [Object] + [optional: Context]: 

 The grammatical tense of the action in the event name. Typically these two: Past simple (e.g. 

pick a single naming standard for both events and properties and stick to it!

Here's the heart of your Tracking Plan - a list with events and their properties you intend to track in your app.

What are Events and why should we track them? 

💡 Events represent the actions users perform in your app. For example, you could send an “Order Submitted” event every time a user presses the Submit button for the order. Tracking actions your users make help you better understand what’s working for them and what’s not. 

In this table you can add, search and filter events, update implementation status and use this list as a documentation for developers or other teams. It's recommended to start with fewer events that are directly tied to one of your 📊

. Remember to align event and property names with the naming convention of your choice.

What is each column of the table used for? 

ℹ️ Meaning of columns in the Event List:       

 - name of your analytical event aligned with the naming convention of your choice. This name will further be displayed in analytical tools.

 - tie events to metrics and questions you've defined, so everyone could easily understand why this particular event should be tracked and that it's a part of a company goal.

 - represents important features or flows in the product an event belongs to.

 - detailed explanation of what the event means and when it is triggered.

 - extra pieces of information about the specific event. The values they contain are current for the moment at which the event was triggered. For example, the event 

, which defines the type of file that has been uploaded 

 of that event. Add new properties right from this table or choose ones from 🎨

 - specifies user properties from [redacted] which should be added or updated along with the event. It means that a call for setting user properties should be called together with the event.

 - defines which platforms the event should be collected on. Sometimes it's better to track events on server-side. Read more about the difference in tracking on server and on client in the next tip.

 - shows the status of event implementation on all sources.

Done {source}: event is implemented on a particular source/platform

To do: a request for event implementation to be done next

Updated: indicates that an existing event was changed and needs to be updated in the the code

Blocked: collection of this event's data is stopped but the event isn't removed from the schema

Deleted: event is removed from the schema and isn't collected any more

 - you can leave notes and comments you like next to events, to never forget important staff. 

How to define if an event should be tracked server-side or client-side? 

ℹ️ Below is a quick logic of when to track events on client or on server. Note, that it's also applicable for tracking user and group traits. 

 Good things to send from the client-side are things that you wouldn’t usually store in your database. Things like screen views, button clicks, mouse movements, social shares and likes. 

 If things like UTM tags, location, device type, or cookied data like returning visitors are important to you, they are all easiest to track client-side.

 This means events are triggered while user is not necessarily interacting with your site or app. An example of this could be an event of receiving an incoming transfer in a banking app, which usually happens without any user actions. 

 Charging customers often happens when they aren’t online, and accuracy for payments is important. Server-side tracking tends to be more accurate than user devices. 

 If you're using email or marketing automation tools that rely on events, it's best to keep these events on the server side. It would be a bummer to have a customer miss out on an important email due to ad block.

 Another good type of data to send server-side are things that need to be calculated in the database. This might be something like “Friend Count” if your site or app is a social network. 

 Sensitive information is also best kept out of browsers. Any data you don’t want exposed to users should be sent server-side. 

ℹ️ Regardless of format, here are some important notes to keep in mind:

 Avoid creating events that pull a dynamic value into the event name (ex. 

Don’t create events to track properties:

 Avoid adding values to event names that could be a property. Instead, add values as a property (ex. 

"blog_post_title":"Best Tracking Plans Ever"

Don’t create property keys dynamically:

 as these are ambiguous and very difficult to analyze

What are User Properties and why should we track them?  

💡 Identifying your users helps you answer the question - who is this user? When you “identify” your users, you should assign them a unique User ID and then attach to that user any meaningful attributes - called properties, like their email or plan. 

Identifying users is something you should do continuously. It is important to identify your users whenever they become known to you or when they change their information. More specifically, you should identify a user in the following cases:  

When user creates any significant change of state or information (for example: change of role, change of address/location, change of plan type, upgrade/downgrade/cancel, etc.)

Identify should be called at the same time as logging a specific event, to pass new or changed properties but they can also be updated independently if needed.

What's the difference between event properties and user properties? 

ℹ️ Both of them are attributes that provide additional context around your users and the events they trigger. But the context of these attributes differs: 

 User property is an attribute that describes a meaningful detail or state of the user. Property values can change through time and they can be applied to any event. Common user properties may include User ID, email and whether the user is a paying customer or not.

 Event properties are extra pieces of information about the events you track. The values they contain are current for the moment at which the event was triggered. For example, the event 

, which denotes the kind of file that has been uploaded by each user 

 of that event. Each event property belongs to one specific event and can't be applied to others. 

My analytical tool requires a User ID to be passed when setting user properties or tracking events. What should I do if my users don't have a User ID (as they haven't registered/logged in)?

 is a unique identifier of the user performing the actions. User ID is usually taken from your app's database and is consistent across a user’s lifetime. 

But there can be cases when users of your app don't have a User ID at all. For example, users may use your app without being registered or logged in or you want to track their actions right before the registration. 

If this is your case, most analytical tools have a User ID alternatives when you don't know who the user is but still want to track the actions — randomly generated identifiers, or sometimes they called anonymous IDs. They should be used instead of User IDs in calls for setting user properties or tracking events. 

Analytical tools generate their internal anonymous IDs automatically, so you don't have to worry about them. But the same Device ID (identifier of user‘s device) setup should then be maintained for the same user, interacting with the app, or they will be counted as 2 separate users. 

If users finally get their user IDs, analytical tools will tie the anonymous activity of these users with their new actions as registered users. 

The most common data types are integers, strings, and booleans. The data type of a property depends on which values you would like to put there and how you plan to use it in analysis.

What are Event Properties and why should we track them? 

 - extra pieces of context about the specific event, like where in your app they occur or what state the app is in when it occurred.. The values they contain are current for the moment at which the event was triggered. For example, the event 

, which denotes the kind of file that has been uploaded 

 of that event. You might want to collect event properties to have more details of user’s actions in your analytics.

Space for Product Analytics Tracking at Datamatterz

Analytics Setup

Sign up to see more