Data Product Management: Your Data Is A Product (Part 2)

Data Product Management: How You Collect It

Data is the foundation for all business decisions. Specifically, it guides your long-term strategy, call-to-action development and A/B testing. Building the data foundations of your company – as an under-10 person startup or a company ready for scale – is easy to do as a reactive process. However, it doesn’t involve the same strategic prioritization you would normally apply to a product roadmap. Data is a product – which at its best will help you make the best decisions for your customers.

Data as a product has two key components: what you collect, and how you collect it.  Failing at either of these components makes your data more than useless – it will become dangerous.

What You Collect

Setting a data product strategy involves working with business stakeholders to ensure everyone is clear on the *purpose* of the data collection. For example, you need alignment across the product, marketing, & business teams (what are we trying to learn here?). Plus, you need to identify KPIs that each stakeholder needs to track and have answers to on the other side of the launch of a new feature or product.

Let’s say you are launching a major new feature to a product.  As the owner of this feature, you need to devise a data strategy for this feature. Whether you are a 10-person startup or a 100-person startup, you can’t assume all your stakeholders are aligning on post-launch topics that will need answers. Ideally, you need to address the following topics from your business stakeholders:

1. Company goal that this feature drives for overall success.
2. Purpose of this feature.
3. KPIs associated with the new feature. (Consider each area of your product funnel that is affected by this feature).
4. Post-launch questions about your feature’s performance.

Most analytics platforms have a concept of an “event,” and a “property” associated with that event.  

For example, the event “Viewed Content” would contain a property of “Content Name”. “Content Name” would have a value equal to the name of that piece of content.  The property represents the nature of the event at the time the event takes place.

A “user property” or “user attribute” is a property that aligns with every event.  These properties are macro descriptors of your users and their behavior. They could include personal information like age or email address, attribution information about what channel this user came from, or numerical information about how many pieces of content this user has ever viewed.  

User properties can be helpful to understand the events triggered by users who have “ever” done a thing or have done that thing a whole lot. User properties can also be set from a server-to-server call from your backend to the analytics provider. This is often essential to understanding data about your users that is not sent from the client application based on user actions, such as how many months they have been paying for a subscription to your service.

A couple of essential best practices are necessary for collecting high fidelity, actionable data.

Beyond interviewing all your stakeholders well prior to launch (like, early!), you should develop a consistent naming scheme for your data.  It will make it so much easier down the road. Whether you use camelCase, or you love_underscores, make a decision and have all your data collected the same way. For example, look at a variety of third-party providers and see what kind of restrictions they might have. Google Firebase, for example, does not allow event strings starting with a number.

Another important best practice when collecting events is balancing event abstraction.   For example, events like “Viewed Content Muppets” would not be abstract enough for an event name (rather you want “Viewed Content” with a property of “Content Name” being “Muppets”).  It’s critical to think about how your stakeholder is going to view the data once collected. Different analytics providers have different feature sets for how data is crunched and displayed.  

While larger teams may be able to afford an analytics expert sifting through tons of raw data, you want to make sure you can get at the answers you need using the tools that you have. Consider the actual dashboard and reports you are going to be creating to get the answers the stakeholders have requested.  Sometimes you have to use a combination of event properties and user properties to get what you need. I find often that having an event for actions, as well as a user property for the number of times the user has done that action, will get me the coverage I need to get the answers I want. It might appear redundant, but can get at answers like, how many times on average does a free user view content before paying?

And the work is never over.  

As the data product manager, you need to build processes to ensure that data fidelity is maintained every release.

Click here for Part 1

Looking for more blog posts? Click here to view