Selecting Events and Properties with Extensibility and Targeted Reporting in Mind

A Review of Best Practices

Introduction

Our philosophy here at Mixpanel is that your analytics should embody a scientific approach to solving your business problems. This all starts with planning out your data collection strategy. A little work upfront before your implementation can pay off tenfold when down the line you can instantly access the metrics you need.

The data that goes into Mixpanel is broken out into events and properties. Events represent meaningful interactions a user has with your website or mobile app, properties log any type of data that you might later want to associate with that event. Properties can be associated with a single event, or, in the case of super properties, with all events sent by a user.

Which Events to Track?

Separate signal from noise. Only track events that are important to your business. We’ve found that there is a temptation to make sure that every mouse click or tap should be recorded, especially when folks are just starting with analytics. What we recommend though, is that you just pick five or six meaningful events to start out with.

Begin by thinking about your business model, and the mission of your project. Which actions do users take on your site which affect the bottom line, which move your mission forward? Start with your pivotal events. These are generally easy to come up with. They are generally the same events that your board of directors is interested in! Hint: if you are a profit driven project, these are the events that affect the bottom line. Some examples of pivotal events for different kinds of web and mobile applications include:

• Account Created
• Order Completed
• App Downloaded
• Link Shared
• Photo Uploaded
• Email Opened

Once you have a list of pivotal events, imagine a few “funnels” for these events. Funnels are paths that users might take before completing the pivotal event. Here’s an example.

(1)Viewed item detail→(2)added item to cart→(3)viewed cart→(4)entered billing info→(5)order completed

This list of steps is a good starting point for the events that you should track.

Think about other reports that you would like to see. Which events would be required? Allow your reporting needs to drive your event tracking. If you are unfamiliar with Mixpanel’s reporting. Attend one of our Webinars, or reach out to us at support@mixpanel.com.

Naming Events vs Properties

Notice in the above example

(1)Viewed item detail→(2)added item to cart→(3)viewed cart→(4)entered billing info→(5)order completed

we have chosen names for these events which are pretty general. On the contrary, we could have listed:

(1)Viewed Product #248677 detail→(2)added item to cart→(3)entered coupon code→(4)viewed non-empty cart→(5)entered US billing info→(6)order completed (coupon)

Obviously, this is a little over the top, but our point is that in the second set of events we’re storing extra data in the event names. Doing this will cause problems when you try to scale, let alone hamper your agility when reporting. Keep your Mixpanel event names generalized. Store details in properties.

For example, if your users can download a file from your site, even if you have only one type of file users can download, call the event “initiated download” rather than “downloaded lolcat.gif”.

It’s better to store the details of what’s being downloaded in a property for that event. Then when your company expands and adds “potato_like_elvis.gif” you can easily keep tracking (and reporting to assess the success of your new content) without a hiccup! Keeping meta-data out of your events and in your properties where it belongs will keep your Mixpanel implementation scalable and maximize the value you get out of reporting.

To Super or not to Super

Many properties are static for a given user. Examples are:

• user-name
• gender (at least for the duration of the user’s session on your site)
• whether or not they’ve viewed the FAQ
• which A/B testing group they are part of

These are all prime candidates for being registered as super properties. This will save you time on your implementation because even a naked mixpanel.track(“this event”)will be tagged with any super properties already registered for a user.

Any piece of user specific meta-data that is dynamic should be included within the mixpanel.track call. Examples are:

• used coupon
• number of items in cart
• total photos in upload cue
• recipient of message

these dynamic elements are often event specific, like the filename of the file that was downloaded, the user-name of the person messaged, etc.

Getting Distinct

Issues often arise, especially when defining funnels in which not all the events are sent from the same place, due to a property called distinct_id. distinct_id is Mixpanel’s way of telling which user to attribute an event to.

By default, Mixpanel will assign users distinct_ids on the fly, and you could choose to use ours. However, if you want to send an event server-side, or when an email is opened, or across you web app and your android app, you’ll need to find a way to pass the value of distinct_id across those devices. Usually it is easier to register your own distinct_id through the identify function. Use something unique but easy for your app to find, like a user’s email or User ID. Being explicit about distinct_id will help keep your data attributed to the same user across devices.

Good Luck

Mixpanel is an incredible tool, and it’s getting better all the time. We’re really excited that you’re adding our tracking code to your site and the solutions team is here to help you get the most out of your data. Still feeling confused, drop us a line at support@mixpanel.com, or drop by the site during pacific business hours and catch us on IM.