Feature Update - May 2015

New on Amplitude: Creating Custom Events, Optimizely Integration, Inequalities for Event Properties, Handling “Merged Users”

New integration: Optimizely

We’re excited to announce that our iOS integration with Optimizely is up and running! Now you can track Optimizely experiments and variation names directly in Amplitude to see how your experiments affect funnels, retention, and more. Setup is quick and easy – learn more here.


Creating Custom Events from Existing Events

You can now create your own event from other events and properties and view them in our graphs retroactively. Uniques will show users who did those events as an OR, totals will show the sum as an AND. One use case is being able to see users who did either event A OR event B in funnels or retention and still count them as converted.

You can create a custom event by going to the “manage app” menu (the gear next to the app on the settings page or in the top right menu when you’re inside an app). Only app admins can create custom events.

You can now create custom events in Amplitude. You can create a custom event by going to the "manage app" menu (the gear next to the app on the settings page or in the top right menu when you're inside an app). Only app admins can create custom events.

Inequalities for Event Properties

You can now use inequality operators when selecting on event properties in the dashboard. This will make analysis on ranges of data much easier.

You can now use inequality operators when selecting on event properties in the dashboard. This will make analysis on ranges of data much easier.

Solution for Counting “Merged Users”

The “merged users” problem is highlighted in example #5 in our unique user calculation in our docs.

In short, the problem arises when an anonymous user (only had device_id) becomes a recognized user (user_id) which already exists in our system. One example is when a user gets a new device — when opening  your app they log events anonymously before signing in. What happens is that these anonymous events get seen first as if they came from a new user, so they get mapped to a new amplitude_id. However, when the user logs into their existing account, events going forward get mapped to their existing amplitude_id. A couple problems arise from this:
1) the user is counted twice in active and new user counts
2) events while the user was anonymous are “lost” in that they won’t be attributed to the true amplitude_id

Our engineers have worked hard at constructing a solution! Now, at the time you query on the dashboard, we will cross reference the list of amplitude_ids from a query with a mapping of amplitude_ids have been “merged” into another. A deeper explanation with examples will be posted in our documentation shortly. We are confident this solution will give you an extremely accurate insight into your user counts.

How will this affect your data? On average, we’ve seen an average change of about 5% in DAU numbers for our users with higher than average change for web data. 

When will we push the solution? We plan to push the solution this Friday May 15th.

SDK Updates

SDK Updates
We highly recommend that you update your SDKs to the latest versions:

Amplitude-Android 1.6.3
1.6.3 adds support for offline mode and synchronous logging
1.6.0 fixed three minor crashes

Amplitude-iOS 2.4.0
2.4.0 now handles tracking push notifications. Before, a user session would be started for each received notification whether or not the user opened the app. Now, a user is only started when the notification displays an alert and the user opens the notification. See the iOS demo app for an example of notification tracking.

Amplitude-JavaScript 2.2.0 
– The snippet in 2.2.0 now defaults to using the gzipped version of the library to reduce download bandwidth and latency. All modern browsers support gzip.
– The user agent parser has been upgraded and fixes some small errors with Android detection. Here is a list of the changes:
1) The default Android browser on older versions of Android (not Chrome) will now correctly be marked as “Android Browser” on “Android” instead of “Safari” on “Linux”
2) Chrome on Android is always reported as “Chrome” on “Android” and not “Chrome” on “Linux”. This was incorrect in some cases.
3) “Windows Phone” is now distinguished from “Windows”
4) Browser versions are being quantized more granularly, e.g. Opera 10 instead of Opera 10.61
5) A variety of long tail browsers are now correctly identified, e.g. Swiftfox is identified separately from Firefox 

Other

You can now use our Dashboard REST API to programatically pull event data for specific users.