How long does it take to implement Mixpanel? A 3-step evaluation
Product teams evaluating Mixpanel often ask us: how long does it take to implement? And, what are my options for importing data? While there’s a short answer, which I’ve included below, the longer (better) answer boils down to three key decisions that product teams need to make about their implementation strategy.
In this article, I’ll walk you through a simple evaluation you can conduct to help answer this question.
First principles
Why would you want to implement Mixpanel in the first place?
Mixpanel is a best-in-class telemetry tool for product analytics. This means Mixpanel doesn’t add any new functionality to your product; it simply makes it possible (and easy) to measure how users interact with any application by collecting discrete user behaviors as data, and storing that data securely in the cloud. But getting the data (i.e. collection and storage) is only half of the equation. We also need a set of tools that are purpose-built to analyze that data.
After all, data is only meaningful if we can make sense of it!
Mixpanel’s reports and modules make it possible (and easy) to answer difficult questions about your end users’ behaviors in your product. And ultimately, that analysis will give you hard facts you can use to improve your user experience.
All this to say, before you can even begin implementation, you need to know which metrics, behaviors, and KPIs you’d like to measure. Figuring out what these are is the basis of any analytics strategy (“measuring everything”—often the battle-cry of codeless analytics solutions—is not an analytics strategy).
Most product teams come to us with a strong sense of their business goals and KPIs, even if they don’t yet know the metrics they’ll need to support those KPIs. Then, through strategy sessions with the Mixpanel team, they’ll uncover the important user behaviors they need to track for proper analysis.
For example, if a business has a KPI of maximizing user engagement on videos, we might leverage behaviors like ‘video start’, ‘video stop’, and ‘video complete’ combined with dimensions like ‘watch time’, ‘video category’, ‘video quality’, and ‘video id’—all of which bubble up to a more general KPI of ‘video engagement.’
A ‘video engagement’ KPI might look like this in Mixpanel:
(Note, we’ve defined our KPI of ‘video engagement’ by using smaller building blocks, which are based on metrics and dimensions derived from actions that the end user has taken.)
Now that we’ve covered the basics of adopting a product analytics solution along with a tangible strategy, let’s dive into the actual question you came to this article for: how long, really, does it take to implement?
The short, TL;DR answer
Once we have a strategy in place (i.e., a set of behaviors and metrics that we need to measure, along with the KPIs they bubble up to), we’re ready to start our implementation. We do this with some simple code, which is responsible for telling Mixpanel’s ingestion APIs when each behavior happens.
In the simplest possible terms, it takes about 30 minutes to implement a single tracked event in your product.
This includes writing code, verifying the data, passing stress tests, and merging that code to the next “branch” in your development environment. Since most of our customers send between 20 and 60 unique events to Mixpanel per product, a rough estimate of the total ‘dev hours’ required from your team’s engineering resources would range between 10 and 30 hours.
This implementation happens over a period of one to three weeks (usually broken out into several sprints or milestones) and is always preceded by a ‘what to track’ strategy session, which generally takes product teams between one to two weeks to complete.
Most of our customers have a clear roadmap for their Mixpanel implementation on or before day 10, and are finished by day 40.
The longer, better answer
While the short, TL;DR answer above offers a crude estimate, it doesn’t account for the complexity of every application and the scope of the systems involved, nor does it factor in any data strategies that are already in place. So let me give you a better answer.
When it comes to evaluating your Mixpanel implementation strategy, I like to walk teams through three key considerations:
- Do we already have the data, or do we need Mixpanel to collect it?
- Do we want Mixpanel to track behaviors on the client side, or server side?
- Do we want to use a Mixpanel SDK? Or do we want to use our own?
Let’s dive deeper into each.
1. Do we already have the data, or do we need Mixpanel to collect it?
Many companies come to us without a data strategy or schema in place. For these customers, Mixpanel provides value as the primary source of data ingestion, responsible for securely collecting, storing, and processing all the data that’s collected. This usually means customers will implement an SDK (Software Development Kit; detailed below), or set up real-time API calls that connect to Mixpanel’s data ingestion endpoints.
As a developer, if you’re using a Mixpanel SDK, it takes about an hour to get the SDK installed and learn all the relevant methods (less time if you’re familiar with implementations that use .track() and .identify() to send data to a third-party). After you’re familiar with the SDK, the ‘30 mins per event’ rule above is a fair estimate.
And when you’re done, you might have something that looks like this.
Other companies that come to us don’t need help collecting the data. They already have a data strategy that includes data warehouses, data lakes, batching/queuing/message-brokering, and other types of ETL-centric infrastructure. In these cases, we generally recommend using our data import APIs or Cloud Import APIs, which are built to quickly receive many messages (i.e. data points) all at once. Here, customers will send historical data into Mixpanel from their servers on-demand, based on a regular schedule.
These types of customers usually won’t implement an SDK, and therefore, their implementation is more focused on transforming existing data than adding code to their product.
As a data engineer, if you’re using Mixpanel’s import APIs, it takes about one to three hours to understand our API specification. Once you understand the requirements and data formats, you’ll be making API calls to batch-send data to Mixpanel that look something like this:
For those who have their data in a data warehouse, Mixpanel’s Cloud Import APIs can consume data in the storage bucket which will be retrieved at regular intervals (more on Cloud Import below).
And finally, there’s a third class of customers we see: those who have already invested in a Customer Data Platform, or CDP (like Segment, or mParticle) which acts as a central hub for all end-user data.
Mixpanel integrates seamlessly with most major CDPs, so in these cases, implementation takes about 15 minutes. You’ll simply plug your key, API secret, and token into the CDP and turn on the data connection with Mixpanel:
Configuring Mixpanel with a CDP does not require any specific technical expertise. However, the quality of the data that flows into Mixpanel is only as good as the quality of the data flowing into the CDP.
Note: most CDPs will require an implementation step that utilizes one of their SDKs and/or data import over an API (very similar to the two above-mentioned scenarios).
2. Do we want Mixpanel to track behaviors on the client side, or server side?
Most digital products have a front-end (‘client side’) and back-end (‘server side’). When we begin an implementation with a defined analytics strategy, it quickly becomes clear where Mixpanel needs to be added. For example:
If the KPIs and behaviors are related to things that an end user does within the interface or UI of an app (things like ‘filling out a form’, ‘watching a video’, or ‘scrolling on a page’), then we typically want Mixpanel to record behaviors on the client side. Front-end frameworks often provide ‘hooks’ and ‘handlers’ to make it easy for your product to signal to Mixpanel that the user just performed ‘x’. Therefore, adding Mixpanel to an existing front-end is a relatively simple development task, and our SDKs provide a streamlined interface for doing so (more on this below).
But if the KPIs and behaviors relate to actions taken on behalf of a user (things like ‘subscription charged’, or ‘password updated’), then we typically want Mixpanel to track behaviors on the server side. Because server-side applications can vary in complexity and size, it’s impossible to make a one-size-fits-all statement for the level of effort required.
However Mixpanel does maintain SDKs and software packages for common back-end languages, which make it easier and more enjoyable for developers to add Mixpanel to a server-side application.
Finally, it’s also perfectly acceptable to track behaviors on the client side and server side (many of our customers do). This can require more time as it adds to the overall ‘surface area’ of the analytics project, including the teams and people involved. Customers who take this hybrid approach will often track the majority of their events on the client side and a couple of events on the server side.
3. Do we want to use a Mixpanel SDK? Or do we want to build our own classes?
Mixpanel maintains SDKs that provide simple interfaces for tracking events and updating user profiles on many different platforms. They also provide helpful functionality like default properties, methods for managing user IDs, data binding, persistence, and much more.
Whether it’s front-end or back-end, these SDKs offer an easy-to-use interface for sending events to Mixpanel:
mixpanel.track('something happened!', {"and it": "was great!"})
If the engineering team is comfortable adding an SDK to their codebase, it’s definitely the simplest way to get the most amount of data with the least amount of time and effort.
However, not all companies are comfortable including third-party code in certain areas of their product (e.g. banks, financial exchanges, healthcare institutions, etc.). We certainly understand that concern, and for this reason, we expose and document all the API routes that Mixpanel uses to send data such that you can build your own classes and methods to track data however you see fit.
While this takes longer than using an SDK because it requires your team to build your own piping, it allows you to keep your codebase free of third-party packages, and for some customers that investment is worth it.
Here’s a quick example of what an implementation of track() with no dependencies might look like.
For companies using a cloud storage provider (like AWS, GCP, Snowflake, or Azure) to join many data sources together in one place as a “source of truth”, adding Mixpanel to their data stack through a feature called Cloud Import is a seamless way to self-serve answers to questions about users without the need for a data expert.
Of course, if you want to be more hands-off with your implementation, or don’t have the expertise (or bandwidth) on your team, there are qualified Mixpanel solutions partners that can help with any aspect of it.
Post-implementation
After you’ve completed your implementation, Mixpanel provides a number of resources to assist you in QA-ing the project, and ensure that you maintain data integrity over time.
For example, Live View lets you see the events sent to your Mixpanel project in real-time to verify they’re up to spec, and Lexicon allows you to add event and property descriptions (as well as other useful metadata) that will appear directly within the Mixpanel UI.
Ultimately, the best estimate for the amount of time and effort you should allocate for your Mixpanel implementation is a combination of these three decision points.
And we would love to help you scope it out. Get in touch with our team here. Ready to implement? Head to QBQ | The Mixpanel Community for a detailed implementation checklist.
