Here's the thing about: First-party tracking - Part 2: Product Marketing
In the first article, I told you that “Only 14% of organizations have achieved a 360-degree view of the customer. (Gartner)”.
Last week we tapped into the importance of staying in tune with your customer needs by utilizing first-party data to personalize communications with your customers.
With help from a Customer Data Platform (CDP) like Segment, Rudderstack, or Bloomreach, you too, can have a complete 360-degree view of your customer.
Once you develop a holistic understanding of your users and their behavior, you will be able to define an overall product strategy, build precisely the kind of product users want, reduce churn and grow retention and LTV, make changes to products and test how those changes impact user behaviors, segment users based on characteristics and behavior and more.
The thing is:
Event tracking will tell the story of how your app works or doesn’t work.
An “event” in the context of mobile app analytics is any action or activity that happens at a specific point in time while an app is being used.
When we are using an app, any app, we interact with the UI by tapping buttons, watching videos, creating accounts, liking a post, or publishing articles. Every time one of these interactions occurs, it is an “event” that will be “triggered” and collected into our data warehouse (and CDP). Each event can be meaningful based on how it represents our behaviors and expectations as we navigate the app.
As discussed in the previous post, an “event” doesn’t have to be a direct interaction. Anything can be an event. For example, you receive a message on Instagram while browsing your feed; this could be tagged as a “notification received” event. It was triggered by another user, but in this context, the event is tracked based on the experience of the current user, you.
There’s actually an additional crucial part of the “data pipeline” that I did not mention before, and that’s data analysis. Your beautifully orchestrated pipeline will only be beneficial when you implement tracking as part of your feature development and testing processes.
Needless to say, tracked events will allow you (the business) to make more informed decisions around getting better engagement rates for your features and improving the user journey that will lead them to those a-ha moments much sooner.
The other thing is:
How do you decide which events to track?
As a product marketer, you constantly seek answers to a slew of burning questions based on your objectives.
Behavioral analytics will help you form some of these questions. With this type of analytics technique, you would examine the “what’s” and “how’s” of customer behavioral data to inform the “why’s” of customer behavior.
Questions such as:
What are the paths that users take after signing up?
What are our users’ most favored features?
What features lead to the conversion of trial users to paid users?
What are the points of friction in the user journey?
What are the least used features?
With these questions in hand, you can begin associating actions performed when the user is experiencing the above in-product scenarios.
Actions a user must perform to reach the delightful moments.
Actions that indicate a user is ready to make a purchase or upgrade an account.
Actions that indicate a user is not deriving values from the product.
Actions that lead to user churning.
Actions that fuel user engagement which leads to retention.
In my experience, your set of “questions” will change about quarterly to accompany new goals and overall company objectives. Do not lose sight of your goals as questions beget questions; the more you ask, the more you’ll want to know about your users and their activities.
Are you seeking feature activations? Subscription upgrades? Moving stock of an overloaded item? Launching a new line of products?
Ask the right questions, and make sure that all your stakeholders are aligned with you before deploying new campaigns or altering your in-product journey in an effort to drive up different event activities.
Creating a Tracking Plan for each of your objectives will be required. I will write up a separate post as there is a LOT to unpack when it comes to all components of an event data. Everything from the event name, properties, entity types, where the event lives in the code base, why these events are essential to the business, etc.
The last thing I will mention today:
There are tradeoffs between Client-side vs. Server-side tracking.
It’s crucial to understand the difference between client-side and server-side events. While it is easier just to choose one path and track everything on either client or server, the reality is - it’s not that simple.
It’s true that some events will only be available to you client-side or on the front end, so you may feel inclined to tap into collecting these easy-to-access user-specific attributes such as cookies, device locations (IP address), and UTM parameters.
Client-side tracking will allow you to:
Send targeted marketing messages based on users’ locations.
Learn the breakdown of your users based on device types.
Determine marketing campaigns and drive traffic via UTM parameters.
However, on average, about 40% of US internet users utilize an ad blocker on any device, according to Blockthrough’s Adblock report.
This means your client-side tracking pixel will be blind to the traffic of over half of your potential user base.
Server-side tracking will allow you to track any “Offsite” or “Passive” events that are not tied to specific user behavior that occurs in the browsers on in-app, as well as any mission-critical events that cannot be jeopardized by ad blockers such as revenue events. Events that hat are required to trigger an email, push notification, or in-app message should be sent server side, so no one gets left out.
I personally would advise that you track server-side as much as possible for the sake of reliability and accuracy of your data. You will require a bit more engineering resources as the server-side events are not nearly as easily accessible. For example, if you’d like to track the UTM parameters on the server-sider, you’d need logic to capture said UTM parameters as they are received by the server and then have the server send it to your CDP.
To help you determine when you should track on the client vs. the server, you can ask yourself these basic questions that I tend to ask myself when requesting for a new event to be tracked:
Are you using an ad pixel? Client.
Are you using heat mapping or a session recording tool? Client.
Is this an “offsite (passive)” event? Server.
Does this event track revenue? Yes = Server.
Is this event mission-critical? Server.
Are UTMs important? Client, but make it Server-side if you have the resources.
Are the user’s locations important? Client.
Is the user’s device metadata important? Client.
That said, it all goes back to your objectives for tracking an event - ask yourself those 🔥 questions.
Next time, we will create a tracking plan to accompany you when crafting a new marketing or product strategy.
Have you ever created a tracking plan before?
Jello
