You find the official documentation for the API here: https://mixpanel.com/docs/api-documentation/exporting-raw-data-you-inserted-into-mixpanel

Here are some useful examples of ways you can use this to your advantage:

• If you’re advertising on mobile, you can export and analyze all the UDIDs that advertisers are claiming they got for you. This helps you with attribution and de-duplication if you’re working with multiple advertisers.
• If you saw a spike of 10,000 events but noticed only a few unique users contributed to it, you can now dive a bit deeper to determine what exactly happened.
• If there’s a particular feature Mixpanel can’t do (we’d love to hear about what that case is by the way: support@mixpanel.com), you can always feel safe knowing there’s a way to get it. You can avoid having to store the data on your side manually from now on.

Feature highlight

One feature we would like to highlight is the ability to filter on a property or segment. Not only can you say “I want all the data from this date to this date” but you can also say “I want all this data from this date to this date where my property source = google.” Check out the “where” parameter in the documentation which can handle all kinds of expressions.

As always, please let us know if you run into any problems by emailing support@mixpanel.com.

Testing is an essential part of life. We touch the water with our toes before we jump in. We taste a piece of new food before we eat the entire meal. We test drive cars and skis before we buy them. In general, we try to collect information when it is available to make future decisions about larger investments. In some ways, measuring cause and effect is easy: When you can hold “everything else constant”, its easy to determine that a new pair of sneakers gave you blisters and a shampoo you used gave you dry scalp and not the other way around. But in other cases it is more difficult: was it the coffee or the wine or the soda you drank yesterday (or a combination of all three) that gave you a stomach ache last night?

When building software that is used by many customers the same problem presents itself. Was it the new algorithm or the new module that generated an increase in average engagement for users? Did the new user tutorial or the coupon offer drive a higher conversion rate? One way to isolate the effects from these potential sources is to introduce them one at a time and see what measures change. But this is not realistic: other businesses who don’t test this way will move much faster and a subset of these will beat their competition. Also, pushing new features out one at a time does not account for hourly, weekly or seasonal effects.

What do you do then when you need visibility on the impact of product features and insight on where to take the next steps? The answer: experiments. Experiments are actually ideally suited for rapid development in the web and software industries that are filled with a large number of fluid users. Why?

1) It is easy to segment users randomly based on a numerical identifier (by taking the modulus of that identifier for example).

2) Software and particular features are easy to execute on those segments (if id meets a condition then show new feature).

3) It is easy to measure results and compare segments if you are logging raw data of user behavior.

Employing the scientific method ensures the credibility of the experiment. This means forming a hypothesis, implementing a control group and collecting the right data to make the measurements you need to draw conclusions. However, in competitive markets, there is not much room for retesting and verifying results as the scientific method encourages. In other words, a compromise between experimental verification and intuition is a far more successful strategy for business than intuition alone.

We are very proud of the accuracy of our data, and are extremely sorry that this error occurred. We know that you make key business decisions based on the data you see in Mixpanel, and even though the miscounting only lasted for twenty minutes, we wanted to make you immediately aware of it. The rest of this blog post will discuss the full details of this error and possible ramifications for your decision-making.

The over-counting impacts all reports on Mixpanel.com or any API calls that request a total count for any event and include 6pm PST on 1/16/12 within the time period of the query. However, this over counting does not impact queries for unique event counts. This means that the Funnels report and the Retention report, which are entirely based on uniques, are completely unaffected. In addition, any queries in the Segmenation or Trends report in uniques mode are not impacted either.

How can I adjust my data to account for this?
In most cases, we do not recommend trying to adjust your data to account for this error. For daily reports, the difference will be trivial. For the day of January 16th total event counts will be roughly 5% higher than they were in actuality. For monthly reports, the total event counts will only be 0.1% higher than they were in actuality. The only case where you might want to adjust the data coming out of Mixpanel is in the case of hourly reports. If you are basing a decision on an hourly report, then divide the count for your total events that happened during the hour of 6 PM by 2. The result will be very close to the true event count for that hour.

Will I be billed for these data points?
Absolutely not. You will not be charged for any overages to your plan caused by this error.

I’m a geek – tell me what really happened
First, it’s necessary to describe a small part of our infrastructure. When a user sends an event to Mixpanel, we do a small amount of validation — mostly checking for syntactical correctness — and then immediately put the event on a queue. Under normal circumstances, the number of items on the queue stays very close to zero, meaning that within seconds of sending an event it should show up in your reports. However, decoupling receiving events from processing them allows us to easily perform server maintenance that would otherwise require significant downtime.

For a long time now, we’ve had multiple queue servers so we aren’t reliant on a single machine, but we haven’t had automated failover. In practical terms, that means that if a queue server goes down in the middle of the day we can do a manual failover within minutes, but if it goes down in the middle of the night, it could be quite a bit longer before we can switch everything over. The change we pushed out Monday was intended to remedy this situation. Basically, when an event comes in, we try each queue server that we currently think is up one at a time until we successfully enqueue an item. Unfortunately, our code to check whether putting an item on a queue was successful or not was incorrect and consequently each event was added to each queue server (currently, there are four). We noticed the problem almost immediately and had the fix within 20 minutes.

What we are doing to keep this from happening again
Unfortunately, although we have queueing related tests, in our test environment there is only one queue server and so none of our tests caught this particular problem. That particular hole will be fixed in the coming days.

Once again, our most sincere apologies and regrets for this error. If you have any questions please do not hesitate to reach out to us at support@mixpanel.com.

Today we are rolling out our new retention tracking system. Now, instead of choosing a user’s cohort on an event-by-event basis (the first time the event was fired) you tell Mixpanel their cohort by sending a $signup event (in fact, this event can be called anything, the key is that you only send it once per distinct_id. If you call it $signup there will be a slight improvement in performance for your report). Usually you would send this event when they first make an account, but a lot of our customers have been asking us about their existing users. How can you tell Mixpanel which cohort to put your current users in?

You can do this, but there are a couple prerequisites:

• You must be already be using mpq.identify() or distinct_id to keep track of your users within Mixpanel
• You must have an existing record tying the identify() or distict_id value you have been sending to Mixpanel with a date you want to use as a user’s birthday. For example: a users table in your database with user_id and date_created fields.

If you meet those prerequisites, you can write a one-off script to send the $signup event to Mixpanel for all your users (each request will count as a Mixpanel data point for billing purposes). To do this, for every user in your database you would make a GET request that looks like this:

This request is very similar to our standard HTTP API (documented here). The data parameter is a Base64 encoded JSON array with the event you are importing ($signup) and the associated properties. By decoding the Base64 data parameter from the above request you can see this:

{u'event': u'$signup',
 u'properties': {u'distinct_id': 481,
                 u'time': 1321499371,
                 u'token': u'13fe3ddc86eb6f90c4ee7d0d47563150'}}

• The event is $signup
• The ‘distinct_id‘ property is the user ID you have been sending to Mixpanel up to this point for that user. For Javascript Library users – this is the value you put in mpq.identify()
• The time property determines which cohort the user will be in. It is in Unix Epoch format (seconds since 1970). Times should be GMT. The above example, 1321499371, represents November 17th at 3:09 AM GMT.
• The token property is your Mixpanel project token.

There are three differences between this import method and the regular HTTP API:

• this method lets you import events older than 48 hours
• the endpoint is /import/ instead of /track/
• as an added level of security, you must include your API key as a parameter outside the Base64

The /import endpoint works for any events you would like to import – not just the $signup event.

You can download a sample PHP script that you can modify with your own data, token and API key to send $signup events to Mixpanel.

If you have trouble importing $signup events for your current users, please reach out to support@mixpanel.com.

To our existing customers, the biggest change is in the way cohort groups are determined. In the past, you could only select a single event for retention analysis, now you can select two – one for determining the cohort (usually you would pick a signup or $born event for this) and one to look at the retention for. This is explained in detail on our documentation page, and in the video below the fold.

You may be wondering: “what happened to compounded retention?” Now all retention is compounded retention – when you pick the first event, we will include all users in the cohort who fired that event, not just those who fired it the first time. To see birth retention, you need to fire an event that will only be sent once and determine the birthday for each user. This event can be called whatever you want, but we recommend calling it $born or $signup. To learn how to properly send a $born or $signup event, read this blog post. To learn how to import these events for your existing users, we have a blog post about that as well!

If you have any questions about new retention, we will be hosting a Live Q&A Webinar tomorrow at 11 AM PST. To tune in visit http://www.mixpanel.com/webinar then.

Thanks to everyone who participated, the recording is available below (click on “more…” if you don’t see it).

Click on “More” to view the whole video.

Update: We swapped the video with one from a more recent version of Mixpanel 101 that is higher resolution and easier to view.

Numbers
Let’s say you were instrumenting a music sharing site, and you sent a property with every “song played” event called “length” that was a number – the length of the song in seconds. If you send the property as an integer or decimal (122 or 3.45) Mixpanel will detect it as a number, and will build a histogram showing what song lengths people typically listened to in the segmentation report:

Code Sample:
mpq.track("Song Played", {"Length" : 122 });

Chart in Mixpanel:

In the above case, 60 – 90 second movies were clearly the favorite! You can also build segments with greater than and less than operators on numeric data. This would let you examine the 60-90 second songs in more detail:

It looks like 77 and 78 second songs are the most popular within this segment.

Sometimes a histogram isn’t enough though – you just want an average. If your data is a number, and you’ve set at least one filter on it, you can have Mixpanel perform the following mathematical calculations on it for a given time frame:

• Average
• Sum
• Minimum Value
• Maximum Value

The average song length for songs between 60 and 90 long hovers around 75 seconds:

If you don’t want to put a filter around it and calculate the overall averages or sums, just choose a filter that wouldn’t eliminate any results. In this case “length is greater than 0” will do the trick. However, most of the time you will want to filter to eliminate extremes that represent bad data that will skew your averages.

If you are sending an event as a number but Mixpanel is not detecting it as a number, you can type cast it by hovering your mouse over the property in the segmentation report, moving it to the right, and selecting the “number” variable type. This will actually work for any property type:

Dates
You can also send dates to Mixpanel. Let’s say you wanted to break down your song plays only to videos that had been uploaded to your site in the past week. If you send a property formatted like a date, Mixpanel will automatically treat it as such, and let you build segments based on date logic.

Code Sample:
mpq.track("Song Played", {"Date Added" : '2011-10-27'});

Segment Example:

The above example would limit your report to plays of new songs that were added in the past month.

Mixpanel accepts a wide variety of date formats. If any of the following appear in a property value, Mixpanel will treat that value as a date:

• yyyy-mm-dd
• dd-mm-yyyy
• yyyy/mm/dd
• dd/mm/yyyy
• a three letter month like Jan,Feb,Dec etc
• a three letter day like Mon,Tue,Wed, etc

You can also include a time after the date, so “yyy-mm-dd HH:MM:SS.” If you are including time, please use UTC time.

Lists
Often you might want to set a property with more than one value. Some examples might be:

• Products purchased in a “Order Placed” event
• Multiple authors in an “Article Viewed” event
• Different genre tags in a “Song Played” event.

If you send a JSON array as a property value, Mixpanel will know that it is a list, and allow you to build segments that query for individual list items.

Code Sample:
mpq.track("Song Played", {"Mood Tags" : ['happy','exciting','romantic'] });

Segmentation Sample:

You can type in any item in the Segmentation report, and it will return the number of times the event was sent with that item as a member of the list.

Feel free to ask follow-up questions in the comments. I’ll answer every single one!

Now you can send Mixpanel a date and we’ll let you manipulate your data. You can find this in the segmentation report.

Examples

• Last time a user logged in
• The date that a user signed up
• The date of a specific action: photo upload, tweet, etc.

Integration

Integration is very intuitive. All you have to do is pass a property with a date formed as: “YYYY-MM-DD” (2011-01-01). You can also give us up to the second granularity if you’d like: “2011-01-02 03:34:21.” We will automatically interpret data that looks like this as a date.

Keep in mind, that you should send us dates that are in UTC format if they have granularity beyond a day level. If you send us data on a day granularity then we’ll simply take that and not convert it to UTC as it would be ambiguous.

How to use it

You may have noticed the new Formulas icon already on the left.

Clicking on it brings up the Formulas creation interface.

At the top, you can enter a name to save your formula to view later.

In the body, you can select the events that you want to use in your formula. Selecting an event will also bring up its properties, on which you can filter further. You can also choose whether you want to count the total number of events, or count only unique events (counted once per user that sends the event).

Initially, you can only compute the ratio between two events. Hitting the tab on the right will expand your view, where you can then add, subtract, or multiply two events.

Hitting continue will save this formula for you and display the trend.

An example formula

Here’s an example of a formula that we use at Mixpanel:

In our Streams product, we have two tabs, Streams and Users. We send these respective events anytime a new user goes to view one of these tabs. This formula lets us view the percentage of unique people that view the Streams tab. We simply take the #streams event, and divide it by the sum of #users and #streams events.

We hope formulas will help you understand your data even more. As always, feel free to contact us at support@mixpanel.com if you have any questions!