The world's most developer-friendly analytics. Questions? Contact us.
As former app developers, we know what it's like to work with analytics services that are difficult to integrate, slow, and untrustworthy. That's why we created Amplitude -- to help app developers make data-driven decisions by creating a comprehensive, transparent, and easy-to-use mobile analytics platform. Come to us with a question about your users and we'll give you the answer.
View integration documentation for our open source SDKs on Github:
For advice on how to get the most out of your data, please take a look at our implementation best practices guide.
You can send data to our endpoint directly. You can find documentation for our HTTP API here: HTTP API
You can modify user properties for a particular user without sending a separate event. These API calls will not count towards your event counts and will apply only to a user's events going forward, not retroactively. You can find documentation for our Identify API here: Identify API
Attribution analytics providers can send data directly to our endpoint so that you can link users to specific ad sources and campaigns. You can find documentation for our Attribution API here: Attribution API
Any data that can be viewed on the dashboard graphs can also be downloaded as JSON via HTML commands (e.g. using curl). You can find documentation for our Export API here: Export API
Here are some key terms that will help you as you're using Amplitude:
Amplitude organizes apps and users in "organizations". If you're the first person in your company to sign up for an account, you should create an organization using your company name. If your organization already exists, wait for an admin to add you so you can access your company's apps.
Next you can add an app by typing in the name and clicking the "add app" button. For each app your company produces we recommend making two apps on Amplitude -- one for testing (MyApp Test) and one for production (MyApp Production).
You can manage user access, rename/delete the app, and export the raw data logs by clicking on the gear icon if you have the appropriate permissions (see 'User Permissions' below).
You can add users to access the organization's apps. If a user has already created their own Amplitude account, you can simply add them to your organization. If they haven't yet made an account, you can send them an email invite, which will add them to the organization upon account creation.
You can add users to teams within the organization. Teams are groups of users who can edit or view a set of reports saved in the team's folder. Only users in each team can see the reports in the team folder.
Lastly, you'll want to set user permissions. You can set permissions at the organization, app, and team levels independent of one another. The roles you can set at each level are the admin, collaborator, and viewer roles. A detailed explanation of each role within each level is provided in the chart below.
Segments are a powerful tool that you can use to compare different groups of users. You can define these user groups based on user properties such as Country, Language, and Version. Properties that Amplitude automatically collects are marked as '[Amplitude] Country'. You can also segment your users based on custom user properties that you define.
Segmentation is available in the Overview, Events, Funnels, Retention, and Revenue tabs. In each of these tabs, Segments are in a locked sidebar on the right side of the screen:
To create a segment of users, click on the 'Add segment' button. A drop down will appear that allows you to select which property you want to filter on. By default, this new segment is called 'All users', indicating that you haven't applied any filters yet.
Once you choose a property to filter on, you have 4 choices: 'is', 'is not', 'contains', and 'does not contain'.
'is' and 'is not': The 'is' and 'is not' options allow you to include or exclude specific value(s) from your segment definition. For example, you could define a segment that only includes users in the United States as 'Amplitude [Country] is United States'.
'contains' and 'does not contain': The 'contains' and 'does not contain' options allow substring matching. In the example below, the segment being created is: users for whom [Amplitude] OS contains android 4. This segment includes users whose OS name substring match 'android 4', i.e. android 4.0.1, android 4.0.2, android 4.0.3, etc. Conversely, if you wanted to exclude all users on any version of the Android 4.x OS, you would use 'does not contain'.
Filtering on multiple values of the same property (using 'OR'): To filter on multiple values of the same property, you can select all the values you want, as shown:
The resulting filter will match ANY of the chosen values. In other words, the multi-select operates as an 'OR' clause: the segment will include users who are using Spanish OR English OR Chinese.
Filtering on multiple properties using 'AND': You can define your segment by additional user properties by clicking 'Add filter'. Adding a filter adds an 'AND' clause to your segment definition. In the example below, the segment is users who are in the United States AND using Spanish.
Another way to make different groups, or segments, of your users is to use the 'Group By' function. Instead of having to manually create segments of users to look at, the Group By function will divide up your users into groups based on a particular user property. You can use the Group By function twice in the same computation to view the user breakdown by two category groups. The Group By dropdown box is located right beneath Segments.
You can apply 'Group By' to all of your users (no filter), or you can use 'Group By' within a single segment. For example, you could first make a segment of users in the United States, and then group those users by [Amplitude] Version or some other user property. You can't apply 'Group By' to more than one segment.
Once you select the property you'd like to use to group your users, the dashboard will visualize the five most frequent segments within the chosen property. In the example below, we grouped by [Amplitude] Device, and the dashboard automatically shows us the number of daily active users in the past 30 days who were on the 5 most commonly used devices: the Samsung Galaxy Phone, LG Phone, Motorola Phone, HTC Phone, and Samsung Galaxy Note.
You can see more than just the top 5 values by switching the graph view in the upper right corner of the graph (highlighted above). By switching to the Table View, you can see all of the devices being used by your users. You can also easily export a CSV of the data.
The overview tab provides you with a macro look at your users. All the metrics on this page are tracked automatically by Amplitude when you call
initializeApiKey in your app.
The overview tab contains 3 sub-tabs: Users, Composition, and Sessions. Each tab shows you different metrics about your users.
The users section displays daily, weekly, and monthly active and new users. The default display is a graph which shows daily active users over the last 30 days. You can change the view to new users in the toolbar. You can change the date range of the data by clicking on the calendar dropdown.
You can compare the number of active and new users across different groups of users. To define segment properties or use the group by feature, use the Segments sidebar on the right side of the screen (see Segmentation for more info).
The composition section displays user composition of active users over the last 7 days. Amplitude automatically pulls carrier, country, region, city, device, language, platform, OS, and current app version from a user's device. We also display the start app version and the percentage of paying users. You can also set custom user properties by calling
setUserProperties. To change the data type you're viewing, use the dropdown menu in the toolbar. Segmentation is not supported for composition.
The sessions section displays three different views on session information. First is a histogram that shows the distribution of session lengths. The second view is a graph of the average session length. The third view is a graph of the average number of sessions per user per day. Segmentation is not supported for sessions.
The events tab tells you what actions users are taking in your app. Call
logEvent in your app wherever you want to track an event.
The events tab contains 4 sub-tabs: Summary, Properties, Segmentation, and Flows. Each tab offers a different way of analyzing your events.
By default, the Summary view shows data on your top 5 events over the last 30 days. You can view Totals, Uniques, Average, or % DAU.
Below the graph is the Event List, which is a table containing more detailed information about all of your events. The top 5 events, which are currently in the graph view, are highlighted. You can add or remove these events from the graph view simply by clicking on the event name. You can select as many or as few events as you want.
In the Event List, the icons under 'Analysis' allow you to easily click over to the Properties (1st icon) or Segmentation (2nd icon) tabs to analyze the chosen event.
The Properties tab allows you to view information about your event properties. Event properties are key-value pairs that you can attach to an event when you call
logEvent. You can choose to graph a distribution of the event properties, or you can graph the histogram, sum or average for numerical event properties.
In the next dropdown, select which event you want to view, and then select the event property. In the example below, we're looking at the 'stage' property of the 'Cancel' event. Making this selection immediately groups instances of the 'Cancel' event by stage and shows the totals for each value.
You can see the different stages (ASK_CONTACT, NONE, STOPPED, etc.) in the graph legend. As with the events summary tab, there is a clickable Properties list below the graph that allows you to add and remove whichever values you would like from the graph.
You can use this tab to compare different groups of unique users who complete certain events. To define segment properties or use the group by feature, use the Segments sidebar on the right side of the screen (see Segmentation for more info).
Event flows show you the most popular paths that users are taking inside your app. We measure event flows within sessions.
You can view both outgoing and incoming flows. To look at actions that users take after a given event, select 'Outgoing' in the dropdown menu, and then select your starting, or root, event.
Conversely, to look at paths that users take before arriving at a given event, select 'Incoming' in the dropdown menu.
To see the next steps that users take from an event, just click on the box containing the event name. This will display the top 5 most common next events for outgoing flows, and the top 5 most common previous events for incoming flows. All remaining events are grouped in 'Other'.
You can continue to click on an event at each level to display another layer of events, up to a maximum of 5 layers. The percentage shown in the connecting lines displays the percentage between that node and the previous node, while the total cumulative percentage for the selected event path is show in the top left corner.
Hovering over the path between two events will display the average time elapsed between those steps.
Event flow examples
For event flows, you can choose to look at flows by total counts, by sessions, or by users. We'll walk through a few examples to illustrate how each of these are calculated.
Say we have 2 users: Amplidude and Amplidudette. We have tracked 3 sessions from these users: 2 sessions from Amplidude (S1 and S2), and 1 session from Amplidudette (S1). The event timeline for each session is shown. For the examples below, we'll use 'prompt' as our root event.
Event Flows: Totals
To calculate totals, we simply count the total number of times that a given event was done. It doesn't matter how many users there were, or how many sessions per user. Let's look at the outgoing flow first. As shown in the user timelines, the 'prompt' event was triggered a total of 4 times. The 'prompt' event was followed either by 'received message' (3 times: twice in Amplidude S1, and once in Amplidude S2) or 'compose msg' (once in Amplidudette S1).
Now let's look at the incoming event flow starting from the 'prompt' event. You can see that twice, 'prompt' is preceded by 'start session' (in Amplidude S1 and Amplidudette S1). 'Prompt' is also preceded by 'received msg' once (in Amplidude S1) and 'open' once (in Amplidude S2).
Event Flows: Sessions
For event flows by sessions, we will count each session that contains 'prompt': 3 sessions total. We then see that in 1 session, 'prompt' is followed by 'compose msg' (in Amplidudette S1), while in 2 sessions, 'prompt' is followed by 'received msg' (in Amplidude S1 and S2). In the highlighted event flow below, only 1 session (Amplidude S1) takes the path of prompt -> received msg -> prompt -> received msg -> end session.
Event Flows: Users
To calculate the event flow values for users, we only count an event once per unique user. In this case, we only have 2 users: Amplidude and Amplidudette. Both of them triggered the 'prompt' event, so we start with a count of 2 in the root node. After 'prompt', 1 user (Amplidudette) did 'compose msg', while 1 user (Amplidude) did 'received msg'.
It's important to note that for Sessions and Users, the percentages won't necessarily add up at each level, since a single user or a single session usually contains more than one occurence of a given event. For Totals, all of the counts and percentages will add up correctly.
Since event flows are tracked within sessions, to view event flows for your app you must either send [Amplitude] Start Session and [Amplitude] End Session events via the Amplitude SDK, or send session_id via HTTP API.
By default, our system will remove an event from the dashboard if it has not been collected in the last 30 days. You can hide events from appearing in the dashboard by clicking on the 'Manage' App link in the top right corner of the dashboard or on the gear icon next to the app on the settings page.
The user activity tab lets you understand user behavior on an individual basis. When a user logs an event in your app, it shows up in the user activity tab in a few seconds.
The user activity tab contains 2 sub-tabs: Realtime Activity and User Search.
User Activity: once a user logs an event, a blue dot representing them appears on the map (only if you've enabled location tracking). Hovering over a dot will show the user ID. Clicking on the dot will bring up the user's timeline view.
Activity Details: below the map is a list of recent events and User ID's, with the most recent at the top. You can filter this list by typing into the Search box. For example, you could only look at the event 'Received Message', or filter for users in Canada.
You can learn how a user is engaging with your app on an individual basis through the user timeline. To view a user's timeline, you can either click on their dot or username in the realtime view, or you can navigate to the 'User Search' sub-tab and type in a specific user ID or device ID into the search box.
Summary and details: searching for a user or device ID will bring up information on the user, including user properties.
Event stream: below the summary and details section, the event stream section displays the entire event history of a user, grouped by session. The most recent activity appears at the top of the list. Clicking on an event will give you detailed information about it, including event properties.
Funnels help you understand how users are successfully navigating through your app and where they're having problems. A funnel is a series of events that a user goes through to successfully do something in your app. We count a funnel step as completed if a user performs the event on the same day or later than the previous step.
Creating a Funnel: you can create a new funnel by clicking on the 'New Funnel' button. Choose your timeframe in the upper right corner. Name your funnel so that you can save it for later use. You can define whether you want the funnel to look at new users or active users, and add funnel steps using the 'Select event' dropdown.
Saving a Funnel: once you've defined your funnel, you can click the 'Save' button. This will save only the funnel steps you've defined for easy access in the future. All saved funnels are viewable in the dropdown when you first open the Funnels tab. If you want to save both the steps and segments you compare, you must use the bookmark tool.
Once your funnel steps and dates are set, click the 'Compute' button to show the results. Results will show up in a few seconds with realtime data. Because our funnels are retroactive, you can explore different funnels across all of your data without having to wait or plan in advance.
Understanding Funnel Results
The final conversion rate is shown at the top of the graph -- this is the percentage of users who successfully completed the entire funnel. This is calculated by dividing the number of users who successfully exited the funnel by the number of users who entered the funnel. In the example above, the final conversion rate is 53.7% -- 1,247 out of 2,322 users successfully completed the funnel.
The bar graph shows each step in the funnel and the number of users who converted at each step. The solid regions represent the users who converted to that step whereas the striped regions represent the users who dropped out at that step. In the example above, 2,322 users entered the funnel with the OPEN step. 2,106 of them successfully made it to the PROMPT step (represented by the solid region). The remaining 216 users never made it to the PROMPT step and have dropped out (represented by the striped region).
Hovering over each step in the funnel will display information about that section of the funnel as it compares to the entire set of users who entered the funnel. For example, hovering over the striped section of the PROMPT step shows that 216 users dropped out, which represents 9.3% of all the users who entered the funnel.
The Funnel details module displays funnel conversion rates over time as well as event property distributions for funnel steps.
Conversion over time: The conversion rate graph answers the question: out out of users who entered the funnel on that day, what percentage went on to complete the funnel at some time? In addition to looking at overall conversion rate, this graph can display the conversion rate between funnel steps. In the example below, the graph is showing the conversion rate between the 'OPEN' step and the 'PROMPT' step, for users who entered the funnel on a given day.
Event property distributions: The 'Funnel Details' section also shows you the distribution of event properties by funnel step. In the example below, you see the distribution of 'stage' property values for users who did the 'PROMPT' event while in the defined funnel. The counts include any 'PROMPT' events that were done on the day that the user completed this funnel step.
Individual User Samples in Funnels: to better understand why your users are dropping out of your funnel, we show you a sample of users and their event timelines from any step in the funnel. To get this list of users, click on the section of the funnel you want to focus on. For example, if you want to see users who dropped out at the PROMPT step in our funnel below, you would click on the striped section of the PROMPT step to generate the user list. The user list shows event timelines from their last session.
You can compare the funnels of different groups of users by setting the parameters on the segmentation bar (see Segmentation for more info).
Understanding your retention is a powerful way to see if your app is sticky or if people are downloading once and never returning. With our retention chart, you can visually see if users are coming back to your app.
Retention data is organized around the start date of new users or the date of a user action.
The breakdown of data is based on days after each cohort's start date. For example, 'Day 1' means one day after a cohort's start date and 'Day 3' means three days after a cohort's start date. If we use a new user cohort with an August 29 start date as an example, 'Day 1' refers to August 30 and 'Day 3' refers to September 1. 'Day 0' refers to the same day as the cohort's start date/action date.
The bar graph averages all of the Nth day retention number from the user cohorts within the selected timeframe. By default, the graph will show the retention of new users who returned any event.
The table shows a detailed breakdown of the data by each user cohort and more granular day buckets. In the example below, on September 8 there were 2,253 new users. The Day 1 retention is 35.2%, meaning that 793 out of the 2,253 users came back and did any event on September 9. The Day 2 retention is 25.3%, meaning that 570 out of the 2,253 users came back and did any event on September 10.
Days with incomplete data will have an asterisk.
Instead of using the default settings of looking at new users who return and perform any event, you can specify the starting action and the returning action. This is helpful if you want to define a retained user in a specific way. In the example below, the starting action is the 'Prompt' (and the event property of 'Prompt' is 'CONFIRM_MESSAGE') event and the returning action is 'Compose Message' event.
Referring to the data below, on January 20, 1,129 users did the 'Prompt' event. The Day 0 retention is 34.1%, meaning that 385 out of the 1,129 users who did the 'Prompt' event also did the 'Compose Message' event on January 20. The Day 1 retention is 16.7%, meaning that 189 out of the 1,129 users who did the 'Prompt' event on January 20 came back and did the 'Compose Message' event on January 21.
The revenue tab tells you how well you are monetizing your users. In order for data to show up on this chart, you need to call
logRevenue in your app. If you're tracking IAPs, we recommend using our revenue authentication system.
Currently revenue tracking is only available in our mobile SDKs. If you'd like to track revenue in a web app, we recommend that you use our HTTP API to do so.
The revenue tab contains 2 sub-tabs: Summary and Lifetime Value.
The summary tab shows you your total revenue and your total number of paying users over time based on the revenue events you have sent to Amplitude.
Revenue data in this section is organized around the start date of new users.
The breakdown of data is based on days after each cohort's start date. For example, '1 Day' means one day after a cohort's start date and '5 Day' means five days after a cohort's start date. If we use a new user cohort with an August 22 start date as an example, '1 Day' refers to August 23 and '5 Day' refers to August 27.
The bar graph averages all of the Nth day metrics from the new user cohorts within the selected timeframe. The example below shows that the average 3 day ARPU for new users from August 20 to August 27 is just over $0.05.
The table shows a detailed breakdown of the data by each start date cohort and more granular day buckets.
The metrics you can measure are:
The cohorts tab is available only to enterprise customers who have uploaded their data to Amazon Redshift. With custom cohorts you can create cohorts based on behavior and/or properties and view them as a segment on our graphs like funnels and retention.
When you click on the cohorts tab, you will see your saved cohorts and be able to edit them. Clicking on the new cohort button will let you name and set the parameters of the cohort by adding AND clauses and OR clauses.
In the example below, we create a cohort of users called "Engaged Users in US" and define this set of users as those who have performed the SENT_TEXT event 7 or more times from Jan 1 to Jan 22 and are from the United States. For the most accurate results, we recommend putting a date range around a user property if you include one.
When you save your cohort, our systems will go through your data on Redshift to compute the set of users in the cohort. This will take anywhere from a few seconds to a few minutes depending on the volume of data that needs to be scanned.
When the cohort is created, it will be stamped with the last time the set was computed. You can re-compute the cohort at any time by pressing the refresh icon. You can also download the complete list of users and their properties as a CSV file by clicking export.
To use the cohort in any of our graphs (Overview, Events Segmentation, Retention, etc.), add a segment and select [Amplitude] Cohort to choose the appropriate cohort.
The query tab is available only to enterprise customers who have uploaded their data to Amazon Redshift. The controls on the page are wrappers around the Amazon Redshift PostgreSQL prompt and allow you to construct simple queries without having to write the SQL itself. The controls allow you to filter based on user behavior and a date range and does a SELECT on users, events, or sessions that satisfy multiple WHERE clauses with an option of including a GROUP BY.
The example below filters on users who have logged an event between August 25 and August 29 and have spent at least $1 on the app (this could be a proxy for whales during a media blitz) and groups unique users who have had at least 5 sessions (highly engaged users) by country.
The result gives you various graphic visuals and the data in a table which you can download.
The query tab is not meant to replace the full capabilities of Redshift but to act as a UI for simple queries or for users who might not have a lot of experience writing SQL. For more complex queries and questions, connect to your Redshift database directly.
User properties are attached to users and apply to all events. Properties intrinsic to the user, such as age or gender, should be set as user properties. Event properties are attached to events and only apply to a specific event. Properties that only make sense in the context of the event, such as current level or server response time, should be set as event properties.
When a user property changes all events going forward will be associated with the new user property. On the day a user property changes, the user will be counted as having been in both the old user property category and new user property category (thus counting twice for that day). For example, on July 1 a user logs into your game app version 1.0 and plays a few games. On the same day he updates the app to version 2.0 and plays some more. If you segment the daily active user graph by version and compare version 1.0 and 2.0, that particular user would appear as a user in both segments. However, on July 2 and onwards he would only appear in the version 2.0 segment until he updates to a newer version.
[Amplitude] will appear next to user properties that our SDK tracks automatically. Custom user properties that you choose to track will not have [Amplitude] next to them.
Users have 30 days from the last date in the timeframe selected to complete the events in a funnel. For example, if your funnel analyzes new users from April 1 to April 3, those users have until May 3 to complete the steps in the funnel.
Events are saved locally and are batch uploaded every 30 seconds, 30 events, and on app close. After calling
logEvent in your app, you will see data appear on the Amplitude website within a few minutes. Events are uploaded on a separate thread so there is a minimal impact on app performance. If you want to change the frequency at which events are uploaded, you can make that change yourself in our open-source SDK.
When a user is offline, we store their most recent 1000 events (max 500kb) by default and then upload them once the user is online again.
Amplitude's SDK will grab the location of the user only if location permissions are set. Amplitude will never prompt for location permissions itself -- this must be done by your app. For iOS, Amplitude only polls for a location once on startup of the app, once on each app open, and once when the permission is first granted. There is no continuous tracking of location. For Android, Amplitude will not poll for a new location. Pins will automatically appear on the realtime map if location permissions are granted. See our integration section for more details.
[Amplitude] Country is a user property that is pulled from the GeoIP. If GeoIP information is unavailable, we pull the information from the phone's latitude and longitude coordinates. If that is also unavailable, we use the phone's locale.
For iOS devices, call
disableLocationListening at any point.
Amplitude uses UTC and currently you cannot change it. When events are uploaded, the time is automatically adjusted to UTC in our database. All data and graphs displayed on Amplitude reflect the UTC time an event was uploaded. For example, if a user uploads an event at 10:00PM PST on September 1, it would show up on our platform as 5:00AM UTC on September 2.
Yes, we deduplicate your data to make sure that a unique event isn't being logged multiple times. We check every event's event_id, client_event_time, and device_id to see if it has already been written on our database. If the unique event doesn't exist in our database, we write it, otherwise we drop it.
[Amplitude] Start Session and [Amplitude] End Session are the two events we track automatically on mobile apps -- they mark the beginning and end of a session (a collection of events that occurred within the same timespan). A Start Session event is called every time a user opens the app/brings it to the foreground and an End Session is called every time the app is closed/sent to the background. Sessions that occur within 10 seconds of each other are merged into the same session and the intermediary End Session and Start Session events are discarded. Removing the automatic Start Session and End Session code from your app will cause inaccurate session data to show up on graphs.
Events that do not occur in a session have a session_id of -1. These events are normally server-side events sent to Amplitude.
We manage the entire Extract, Transform, and Load (ETL) process for Redshift, saving your analysts the pain of having to deal with reoccurring headaches and making them more productive writing queries and exploring your data. Some of the optimizations we do are:
Try extracting the file from the command line. It should look something like: unzip -a FILENAME.zip
For iOS devices, the device column shows the hardware string of the device. The mapping to the product name can be found here: iOS Device Types
We use different timestamps to ensure that your data is being reported accurately.
Daily exported files are based on server_upload_time and all dashboards are based on event_time. We recommend that queries on raw data use event_time.
Unique users are identified by amplitude_id. More information as to how we count unique users can be found below.
We use a system of identifiers to keep track of unique users. Unique users are identified by amplitude_id, which then populates all of our dashboards. Setting the amplitude_id involves gathering the device_id and user_id information first.
setUserId:@"USER_ID_HERE"at any time or as an argument to the initializeApiKey call
The general rule is that an amplitude_id will be assigned to an event by prioritizing user_id over device_id. Examples of how we assign amplitude_id to count unique users are below:
If no User ID is associated with an event, we will automatically populate that field with the Device ID instead of putting a null. Our back-end however, will still recognize this as an anonymous user.
The discrepancy between reports in the app store and Amplitude can be attributed to factors like time zone differences, event generation bugs, or even piracy.
If the discrepancy is minor and consistent on a day-to-day basis, the likely cause is the difference in time zone reporting between the app store and Amplitude. Because Amplitude uses UTC, a purchase event uploaded on a certain day according to Amplitude may be reported by the app store as occurring on a different day if the app store is using a different time zone, and vice versa. No data are being lost.
Major discrepancies can be the result of client side errors such as the store purchase callback getting called multiple times for a single purchase. A good practice is to only call these events upon return from a successful store purchase. An example call, which tracks the event property and revenue amount, is:
Another cause for major discrepancies is piracy. A user can circumvent the app store and make purchases that don't show up in the app store reports. To avoid seeing pirated revenue events in your data, we recommend using our revenue verification way to track revenue events. If you suspect your data are being skewed heavily because of piracy, contact us and we'll be happy to look into it.