Implementing Mixpanel: an engineer’s perspective
This is a guest post from Jonathan Kressaty, a founder and the CEO of Levers, a predictive analytics platform. Kressaty’s startup business includes SMS marketing, software consulting and digital marketing.
When we started working on admin tools for Levers, we realized that there were a large number of questions we wanted to answer. Many of these requests from our team focused on event-based actions, and we knew that Mixpanel would be a great way to handle tracking that data. Our previous post here talked a lot about how we’ve built marketing processes around Mixpanel functionality; this post outlines some of the processes we went through to get Mixpanel implemented technically. This is by no means the only way to go about this, but it ended up being a very efficient process for us and has continued to allow us to iterate on our Mixpanel installation.
Before you start: keep in mind that you may need to improve on your Mixpanel implementation as you develop. You may want to track additional events or you may find that you’ve tracked events that are less useful than they initially seemed. It’s helpful to come up with a list of questions you want to answer first and then come up with an implementation spec that identifies the events and properties you need to track to answer these questions.
Here’s how we recommend designing a Mixpanel implementation:
- Start off by making a list of all the actions you want to track.
- Take time to think about any events that can be tracked by a simple page view — we track an event of “summary opened” when that page is viewed by a user.
- Map everything out with index cards — we used sticky-back index cards and wrote each, single event or property we wanted to track on them, and then wrote out our observers on a whiteboard.
We then put all the cards under each observer and had dev and marketing teams meet.
For backend tracking: If you’re using a framework in your language of choice, take a look and see if it makes sense to create “observers” easily. In Laravel, there is a fantastic observer class that is tightly integrated with the ORM, allowing us to easily listen for creates, updates, and other events. We can then fire Mixpanel code server-side with very little additional code. Obviously, your engineering team may choose to go about this in a different way, but the big message is to make this easy and accessible — changes will happen.
With our product, Levers, we have a concept of accounts that have many users. We push users into Mixpanel as people, but mark account owners as such with a flag, and also push global account data into that person’s profile. This allows us to easily filter by those properties to only see “Accounts” through the Mixpanel People view.
As mentioned in Emily’s post we use Mixpanel to fire a large number of automated emails for both marketing and app purposes. We use properties on “people” heavily — usually in the form of a count (how many times a user has done something, for example, so we can test “has user created more than 2 simulations” or by setting a date “first simulation created after 2-14-2014”).
Ship it! At this point, you’re ready to test and iterate. Work through any implementation issues, and wait a day or two. Check your data, build some funnels, and make sure you can answer the questions you need to answer. Change some things.
Finally, some last minute tips for engineers while implementing:
- Utilize the raw data export functionality of Mixpanel. It will allow you to retrieve individual JSON objects as they were sent to Mixpanel, so you can make sure it’s receiving data exactly as you intend.
- Use Runscope in the Mixpanel request URL to track your HTTP request. The PHP library provided by Mixpanel allows us to easily change the root URL of any request, and the others should, too.
- Set up three different Mixpanel projects: One for local development, one for your staging environment, and one for production. This allows you to test changes without polluting production data.
- Your marketing team may ask for things to be tracked on a “person.” That sounds crazy! Ask them to manually edit a single person in the testing project to look exactly how they’d like it to look. You can then replicate this in your code implementation.
At Levers, we’re constantly changing things, tracking new features we add, and updating how we perform certain actions. We’d love to hear any questions you have about our implementation, so feel free to email us at email@example.com or contact Mixpanel support at firstname.lastname@example.org.