Missing or unexpected data

If a chart shows fewer events than you expect, more users than you expect, or a different number than another platform reports, these sections cover the common causes.

Missing data

Sometimes you want to use an event or property for an analysis but can't find it. Even if the data was successfully sent to Amplitude, there could be several reasons why it is not showing up. This article will discuss a few of these scenarios, including how best to troubleshoot for each one.

The instrumentation limit has been met

If your project's instrumentation limit has been met, data for any event types and event or user properties that exceed the limit cannot be queried from Amplitude. You'll only be able to access it by exporting raw data via a CSV file or Amplitude's Export API.

You can try to get back under the limit by deleting unneeded event types in Amplitude Data. Once you are under the limit, it will take approximately 24 hours for the new event types, event properties, and user properties to appear in Amplitude.

Data has been hidden, blocked, or deleted

The expected data may have been hidden, blocked, or deleted. Make sure you understand the differences between those actions from your main branch to ensure the data is ingested properly moving forward.

The data may also be named in a way you do not expect, or have a display name you're not familiar with. If you need to adjust the name, learn about making retroactive changes to your data in this help center article.

Hidden events

Sometimes an event may be visible in an event stream but not in a chart. This could be because of a filters, like a drop filter mentioned previously, or because the event was previously hidden from view via Amplitude Data, as seen in this image.

Schema doesn't include unplanned data

The missing data might be considered unplanned. This means the data conflicts with your current schema settings, and Amplitude doesn't know what to do with it. Double-check that your project's tracking plan is set up to receive unplanned events or properties. If it is not, Amplitude will not store the event or its properties.

Data ingestion or access is delayed

If you can see the event or property data for some users and not others, the ingestion of your data may be delayed. For example, if you are using a Mobile SDK to send data to Amplitude, there is no way to guarantee that the events appear as soon as they are logged - a user may not have been connected to the internet or the SDK's event upload threshold may not have been met.

Modified user properties

New or modified user properties sent via the Identity API.

Unexpected values in user counts

While grouping your events by an event or user property, you may have noticed that some of your results have been sorted into a group called (none). In Amplitude, (none) represents a null value.

But why do some of your users have null event or user property values?

This article answers some frequently asked questions about why your users have null and unexpected property values.

Why my event property being sorted into the (none) bucket?

Amplitude is an event based analytics platform, and all charts and cohorts query at the event level. Charts will return the event property value at the time of an event.

Because an event property is a component of an event, event property values can be unique at the event level. If you send an event with a null value at the time of the event, grouping by that event property will sort some events or users into the (none) bucket.

Here's an example. User A triggered Send Message once on January 1st and once on February 1st. The Audience event property was instrumented on January 15th, and thus was not available when the user triggered Send Message on January 1st. The Audience property can only have values equal to Default and Mentioned_Contacts. When User A fired Send Message on February 1st, it had an event property of Audience = Default.

Based on that information, how will User A be counted in the chart below?

User A will be counted once in the Default bucket and once in the (none) bucket. User A had Audience = Default at the time of the February 1st event, and Audience = (none) at the time of the January 1st event.

Events and users will be sorted according to the property value that was sent at the time of the event.

Why is my user property not showing an expected value?

Like event properties, charts will return the user property value at the time of an event.

User properties are stored in a separate table then applied to events. When a user's user property values update, the user property values attached to historical events will not change.

Why is my custom property showing a null value?

The custom user properties attached to your users' events will reflect the user property values present at the time of the event.

Here's another example. You've instrumented a user property type called Account_Type on January 15th. User A is a registered user who has an account type of Shopper, and she triggered Add Item to Cart once on January 1st and once on February 1st.

Based on that information, how will User A be counted in the chart below?

Because the Account_Type user property was not instrumented until January 15th, all events triggered prior to January 15th have a null value for Account_Type. User A will be counted once in the (none) bucket and once in the Shopper bucket.

When results are measured by Uniques, users are deduplicated within each unique bucket. This means that if User A triggered Add Item to Cart with their Shopper account type on February 1st and February 2nd, User A will still be counted only once in the Shopper bucket above.

This same logic holds when you send non-null user property values. Events and users will be sorted according to the property value that was applied at the time of the event.

We have this logic implemented because user attributes can change over time. City , for example, is an attribute that can change by the hour as users travel to different cities and trigger events there. Understanding where the user was located at the time of the event can be more valuable than understanding where the user was most recently located.

My location property shows a (none) value. How do I fix it?

Location user properties (such as [Amplitude] City, [Amplitude] DMA, [Amplitude] Region, and [Amplitude] Country) are determined by GeoIP. Amplitude uses the MaxMind database, which is widely accepted as the most reliable digital mapping source, to look up location information from the user's IP address.

For client-side events, location properties can have (none) values if MaxMind returns null for that IP address. Even through MaxMind is considered as the most reliable source, accuracy and availability of city/region information can vary by country (more info here).

For server-side events, location property values are determined either by GeoIP (which falls back on location_lat and location_long if unavailable), or explicitly defined in your API call. Amplitude's HTTP API allows you to send custom City , DMA , Region , and Country values with your events. If you choose to send these values, Amplitude will not modify them to reflect GeoIP. Please be sure to update all four fields together; setting any one of these fields will automatically reset all others.

Why is my device property showing a (none) value?

Amplitude determines [Amplitude] Device family and [Amplitude] Device type by grabbing device_brand, device_manufacturer, and device_model strings directly from your user's device and then mapping these strings to our repository of device types.

With each new phone model that comes out globally, there may be some device types that have not yet been mapped. In these cases, [Amplitude] Device type will be (none).

Outside of device mapping, server-side events may also have null device information if these fields (platform, os_name, os_version, device_brand, device_manufacturer, device_model, and carrier) were not updated together. Setting any of these fields will automatically reset all of the other property values to null if they are not also explicitly set for the same event.

User counts from past events

The user count for an earlier date can fluctuate as time goes by. When you view your data on different days, the number of users for an earlier date may increase or decrease.

The user count can increase when events that occurred in the past are ingested into Amplitude later. Most frequently, it happens for one of the following reasons:

• Amplitude's mobile SDKs batch events, with a threshold of every 30 seconds, or every 30 events. When users don't meet this threshold, their events may not be sent to Amplitude until they return to your product and trigger more events.
  • To resolve this, adjust the event upload frequency. For Android Kotlin SDK, configure flushIntervalMillis and/or flushQueueSize. For iOS SDK, configure eventUploadPeriodSeconds and/or eventUploadThreshold. See SDK documentation to learn more about configuring the threshold on other SDKs.
• Amplitude's Batch API/server-side integrations have inherent delays.
  • To resolve this, schedule batches more frequently.
• If the user's cellular or WiFi connection was not strong enough when they triggered events, those events will be held until the connection is stronger.
  • There is no remedy for this issue.

The user count can decrease when user records are merged.

Amplitude uses a system of user IDs, device IDs, and Amplitude IDs to track unique users. If some of your users don't have user IDs, or if you have a lot of anonymous events, these anonymous events are first assigned to an anonymous profile, and then later merged into a known profile.

Your data will eventually stabilize, as anonymous users come back and merge into existing profiles. The amount of time this takes depends on user behavior (how often they return to your product) as well as your settings (how often you batch events). Users who interact with your product every day will display shorter delays in merging, while those who return less frequently will have longer delays.

Data discrepancies with other platforms

Sometimes, Amplitude's numbers may differ from those provided by other vendors. This can happen for a number of different reasons.

Before you begin

This article assumes that you understand how Amplitude tracks users and sessions. If you don't feel confident in your understanding, check out our articles on tracking unique users and on the definition of a session in Amplitude before proceeding.

Data discrepancy checklist

This list of questions acts as a quick troubleshooting checklist for any data discrepancies you may be experiencing. If you can answer "yes" to a question, it's probably not the cause.

Do the time zones between Amplitude and the other platform align?

If not, align the time zones before comparing numbers. Amplitude timestamps the data it ingests in UTC, but you can customize the time zone within the Amplitude UI.

Do the events you currently track in Amplitude reflect what you're tracking in the other platform?

If not, then a discrepancy between your users and sessions numbers becomes more likely, as both are dependent on the events being tracked.

Do Amplitude and the other platform block the same web bots and scrapers?

If not, then a discrepancy between your users and sessions numbers becomes more likely.

Do the other platform and Amplitude both define the metric of interest the same way?

If not, then a discrepancy is more likely.

Does the other platform merge users like Amplitude does?

If not, then you may see a discrepancy between your users and sessions numbers, depending on the identifiers the other platform uses to merge its users.

Is the session timeout window the same between Amplitude and the other platform?

If not, you're more likely to see a discrepancy between your sessions numbers.

Sessions in Google Analytics

Though Google Analytics and Amplitude track sessions similarly, certain common events can cause a discrepancy in your session numbers.