I recently worked on an iOS app where we implemented the Mixpanel analytics platform. Since the app had a defined user base, analytics were key in showing us what features we should iterate on and what would provide the most value.
5 things we learned about Mixpanel:
- When you're unsure about which events to send, err on the side of sending over general events with many properties.
- Simple and clear naming of events will make it easier in the long run. Use a test project as a sandbox and try creating reports to see if the names make sense.
- When something fails in the app (ex. Network request) send the failed event with as many properites as you can. This will help debug errors in the app later on.
- Mixpanel has great segmentation filters. In order to get their full benefit, be sure to use the correct data types when sending over properties. String, Number, BOOL etc.
- Use People properties liberally. Calls to 'increment' & 'people.set' are "free". They don't count against your total events.
5 Mistakes we made.
- We didn't call 'alias' when creating a new user. If you only call 'identify', your funnel data will be incomplete!
- We separate projects for different parts of the app (admin & user, mobile & web). This separates the data and makes it impossible to search across everything. Use properties and segment the data by platform, usertype etc.
- We didn't use super properties. These are properties that are sent over with each event & to the people api.
- We used email addresses for distinct IDs. If a user changes this you will need to alias the new email as the new distinct_id.
- We didn't contact the Mixpanel folks until after we finished development. They are very helpful & give great advice.
The Mixpanel iOS library is available as a Cocoapod so integration is very easy. I would recommend having a development project where you can experiment with event & property naming. Once the app is live, you should change the names of your events.
With analytics there is a tendency to wait till the development is finished & then shoehorn it in. What usually ends up happening this way is that they are not well thought out & might not even make it into the production release due to time constraints. We ended up adding analytics data while we worked on a feature and added them to our stories. Constantly thinking about what might be a good thing to measure brought to light things that ended up being very insightful.
Mixpanel has some best practices for sending events, here are some additional things we picked up.
Knowing what and how many events to track is difficult when faced with everything that happens in the app. Mixpanel recommends focusing on a certain area to optimize and send over fewer events. This advice is great if you know in advance what areas you want to focus your attention on. In our case, we weren't 100% sure which parts of the app the users would find most useful, so we ended up sending over every major event that happened.
Proper naming of events can get tricky. When viewing reports, all the events are listed in a single dropdown. If you prefix your event names with the subject of the event, when you search or scroll you will easily see all the events attached to that subject. For example: User Login, User Logout, Photo Uploaded, Photo Deleted, Photo Viewed etc.
What you can go crazy with is the properties that you send over with each event. You should send over as much data as you can about each event since the segmentation tools make filtering on these properties very easy. We created a 'analyticsProperties' method on our models so we wouldn't have to build up the properties hash each time we sent an event.
If you choose to use the People Plan, you should send over properties with both the 'event.track' & 'people.set'. We found that using the 'people.increment' was very good for keeping track of how many times a user completed a given action.
When a user opens the app, we track both:
[mixpanel.track event:@"App Opened"]; [mixpanel.people increment:@"App Opens" by:1];
Since searching across people & event data is not possible, having this data in both places is very useful.
If you are creating a user with the people API, be sure to call 'alias' when creating a new user. Any consecutive logins should call 'identify'. If you take one thing away from this post, let it be this!
Registration: (void)createAlias:(NSString *)alias forDistinctID:(NSString *)distinctID; Login: (void)identify:(NSString *)distinctId;
Setup a new project for production and only send over events when you have your taxonomy figured out. If you do need to rename something in production, you have to go to Settings -> Data Management -> 'Hide Event from dropdown'.
Mixpanel Reporting Views Tips and Tricks
- This is the only way to see average times between events, if you aren't sending elapsed time over as a property.
- When thinking about naming events, think about how they would all look in a funnel.
- If you haven't called 'alias' correctly, the funnels will be incomplete.
- Only a single event can be segmented at a time.
- Properties can be added as filters as many times as needed.
- The more properties you have on an event, the better the segmentation will be.
- If you have a big range of data, add the property again to segment the data further (like this).
- The last 60 events are shown here.
- You can filter this list on any property sent to your events.
- The events are sent in batches from the iOS app. Sometimes you have to wait for another event or a set threshold of time before the events show up here.
- Any properties that you have sent with 'set' or 'increment' can be used as a filter here.
- Proper formatting of properties will make filtering much easier. Integers as NSNumbers, IDs as strings so they are unique.
Mixpanel is a very powerful tool for analyzing how people are using your app. If you take the time to think about the event structure and naming conventions, it will save you time as well as provide the best answers to what you should build next.