One example of something that bit us was that the mixpanel servers modify the time stamp from a client if it is in the future. It turns out this happens quite regularly with mobile devices (especially Android). Consequently a batch of data coming in would all have the same time stamp destroying the ability to see what happened over time.
Another example is that Mixpanel will add country information to incoming data, but refuse to add to regional information so the only thing you know about US users is that they were in the US.
I also got bitten by their handling of timestamp.
e.g. - scenario:
Your users create bookings (which are normally done in the future).
How do you approach this? Well you submit a date field in the document you send to Mixpanel. But then you figure out that ONLY time axis supported by Mixpanel is their timestamp. Which could make sense for an off the shelf service, since you probably really don't want to build indexes against random user data.
Ok, take 2 - so I only have one X axis available (the Mixpanel Timestamp), however you soon figure out that Mixpanel just silently prunes your future timestamp to @now.
The worst part for me was Mixpanel teams total bewilderment as to why anybody would want either additional time axes OR future timestamps.
Guys your service really shows promise for building a fast and simple to use analytics. I really don't want to roll my own analytics service just to show simple activity timelines to my customers. I also don't want to maintain and support the infrastructure necesary - at least not at this time. Please realize that there are other cases for real time analytics besides funneling users towards "Buy now!" or "Signup now!" pages.
Are there any similar alternatives (I searched quite a bit but found nothing) or on the other hand if there are not - would there be anybody interested in joining up with me to build a service.
1) More intelligent marketing spend. If you know you have a higher LTV for females for your app between the ages of 18-34 and you do a portion of your advertising on Facebook, it would be good to target just those users.
2) Insights into broad customer engagement. Let's say your 18-34 female users return to your application more often than male users in the same demographic, it'd be helpful to know what friction points cause these users to drop off.
3) Insights into spending users. Being able to segment all your user actions by those who are free and those who spend money would help you optimize your paying funnel.
4) Bug reporting. Knowing where your users are located can help illuminate whether you have server and localization problems.
I can't think of any reasons why you'd use this information to voluntarily contact users other than support-related issues. If Netflix sent me an email that said "We think you'd like these movies because other males liked these movies" I'd probably de-activate immediately.
If we were physically interacting with our users (i.e. we ran a shop or a community centre) we'd be using thousands of signals to determine who needed help, who was afraid, who was ready to purchase more and who was making trouble.
As developers we try to cultivate online social environments, socially-engaged shops, games which envelop the user and collaborative business tools but with absolutely none of these emotional cues. That's hard.
Imagine trying to design an amusement park if all you had was an anonymous ping each time someone went on a ride. The value to all of us (and to the users) in these new wave of analytics is to take us closer to the user and let us feel what they feel and service them where they need to be serviced.
Asking why one should do that is about the same as asking why you'd need to watch people queuing for the rides in an amusement park in order to improve the queues. Because if you don't you won't know what the user feels, wants or needs.
(Side note: what mixpanel is doing is incredible and they really are a pleasure to use. There is a Zen quality to their product and the way it gives you great power from great simplicity (although a custom dash would be great, ty! ))
My point is, it doesn't help you to measure something that isn't actionable. And my list above was just the four that I can think of where gender, age, and location details actually helped across many of the applications I've studied.
I agree with you that the goal of analytics is the help improve your products, but its easy to be misled to the wrong conclusions. Sometimes, too much data may actually be harmful to your business.
We're were doing something similar with mixpanel, except (in mixpanel client-side parlance this is called super properties) we have to send all attributes such as "number of pages viewed", "amount of money paid" with all our events in order to segment by that data.
And sending emails based on analytics is incredible! I've always wanted to build that for my app but didn't have the resources to. Is it horrible to gloss over the privacy concerns?
Also, if you're interested in automating emails based on analytics you should checkout http://getvero.com (disclaimer: I'm a founder). We're working on a Mixpanel integration as I type so we should pick up right where Mixpanel leaves off :).
That said, as a customer, I felt that Mixpanel could have been a little more transparent with their roadmap.
It would have been _A LOT_ much better for customers like us to know that was in the pipeline for rolling out and would have saved us a lot of unnecessary headaches and pains.
If you want to see the power of how useful this really is, you should look at :
https://mixpanel.com/docs/people-analytics/javascript
I think that the "Sales Page" doesn't do this new service justice. It's quite staggering how useful this is. It basically allows you to segment your users and keep in touch with users of whom you have identified might be power users, or users who might fall into your "danger cohort". For example, you might notice a trend that users who don't "do event X" within the last 7 days, are most likely not going to return.
Tracking the events in your application and then identifying these events as originating from a particular user, allows you to then find these users.
This is of course just one example.
Look at the documentation on People Analytics for more ideas...
Btw - We've avoided this in past using Google Analytics as in the TOS they mention (http://www.google.com/analytics/tos.html).
7. PRIVACY . You will not (and will not allow any third party to) use the Service to track or collect personally identifiable information of Internet users, nor will You (or will You allow any third party to) associate any data gathered from Your website(s) (or such third parties' website(s)) with any personally identifying information from any source as part of Your use (or such third parties' use) of the Service. You will have and abide by an appropriate privacy policy and will comply with all applicable laws relating to the collection of information from visitors to Your websites. You must post a privacy policy and that policy must provide notice of your use of a cookie that collects anonymous traffic data.
Hadn't heard of https://www.intercom.io/ - thanks for sharing @reustle.
In most cases, companies are tracking all of this data, just in multiple different systems and not bothering to pull it together (i.e. why do I get emails about product features I already use?) to use to make my life better.
On privacy, companies need to make sure they are being open with users. For most of these so-called "people analytics" companies can choose whether to include personally identifiable info. Companies need to be intentional, and should choose to anonymize customer data when they can (but should still treat people uniquely based on their past interactions, even if they can't put a name on someone).
Even so, all analytics services are basically privacy atrocities, and as such I don't think Mixpanel should receive a disproportionate amount of resentment.
User information utility and privacy are mutually exclusive.
On privacy, we designed in an inability to correlate user data across our customers. So, for example, we cannot know that an end user of Apptegic Customer A is also the same end user of Apptegic Customer B. With this in place, the data is used only for our customers to understand and better serve their customers.
It seems like at the very least it should support server-side validation of user ids based on their cookie or something, so a user can only screw with their own stats.
