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.

Why an event or property is missing

Even when you successfully send data to Amplitude, the event or property may not appear in analysis. The following sections cover common causes.

The instrumentation limit has been met

If your project hits its instrumentation limit, Amplitude can't query data for any event types and event or user properties that exceed the limit. You can only access this data by exporting raw data through a CSV file or Amplitude's Export API.

To get back under the limit, delete unneeded event types in Amplitude Data. After you're under the limit, the new event types, event properties, and user properties take approximately 24 hours to appear in Amplitude.

Data has been hidden, blocked, or deleted

Someone may have hidden, blocked, or deleted the expected data. Review the differences between those actions from your main branch so Amplitude ingests the data properly.

The data may also have a name you don't expect, or have a display name you're not familiar with. To adjust the name, refer to the article on making retroactive changes to your data.

Hidden events

An event may appear in an event stream but not in a chart. The cause is usually a filter (such as a drop filter) or someone hiding the event from view in Amplitude Data.

Schema doesn't include unplanned data

The missing data might count as unplanned. Unplanned data conflicts with your current schema settings, so Amplitude doesn't know how to handle it. Verify that your project's tracking plan accepts unplanned events or properties. If it doesn't, Amplitude doesn't store the event or its properties.

Data ingestion or access is delayed

If event or property data appears for some users but not others, ingestion may be delayed. For example, when a Mobile SDK sends data to Amplitude, events may not appear immediately. The user may not have an internet connection, or the SDK may not have reached its event upload threshold.

New or modified user properties sent through the Identity API can also experience ingestion delays.

Unexpected values in user counts

When you group events by an event or user property, some results may appear in a group called (none). In Amplitude, (none) represents a null value.

The following sections explain why users have null or unexpected property values.

Why does my event property appear in the (none) bucket?

Amplitude is an event-based analytics platform, and all charts and cohorts query at the event level. Charts 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 places some events or users in the (none) bucket.

For example, User A triggered Send Message once on January 1st and once on February 1st. You instrumented the Audience event property on January 15th, so the property wasn't available when User A triggered Send Message on January 1st. The Audience property accepts only Default and Mentioned_Contacts. When User A sent Send Message on February 1st, the event had Audience = Default.

Amplitude counts User A 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.

Amplitude sorts events and users according to the property value sent at the time of the event.

Why doesn't my user property show an expected value?

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

Amplitude stores user properties in a separate table, then applies them to events. When a user's property values update, the user property values attached to historical events don't change.

Why does my custom property show a null value?

Custom user properties attached to events reflect the user property values present at the time of the event.

For example, you instrumented a user property called Account_Type on January 15th. User A is a registered user with an account type of Shopper. User A triggered Add Item to Cart once on January 1st and once on February 1st.

Because you didn't instrument Account_Type until January 15th, all events triggered before January 15th have a null value for Account_Type. Amplitude counts User A once in the (none) bucket and once in the Shopper bucket.

When measuring Uniques, Amplitude deduplicates users within each unique bucket. If User A triggered Add Item to Cart with their Shopper account type on both February 1st and February 2nd, Amplitude still counts User A only once in the Shopper bucket.

The same logic applies for non-null user property values. Amplitude sorts events and users by the property value applied at the time of the event.

Amplitude uses this logic because user attributes can change over time. City, for example, can change by the hour as users travel and send events from different cities. Knowing where the user was at the time of the event can be more valuable than knowing where the user is now.

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

Amplitude determines location user properties (such as [Amplitude] City, [Amplitude] DMA, [Amplitude] Region, and [Amplitude] Country) by GeoIP. Amplitude uses the MaxMind database to look up location information from the user's IP address.

For client-side events, location properties can have (none) values when MaxMind returns null for that IP address. The accuracy and availability of city and region information varies by country. For details, refer to MaxMind's accuracy comparison.

For server-side events, Amplitude determines location property values either by GeoIP (which falls back on location_lat and location_long if unavailable) or by explicit definition in your API call. Amplitude's HTTP API lets you send custom City, DMA, Region, and Country values with your events. Amplitude doesn't modify these values to reflect GeoIP. Update all four fields together: setting any one of these fields automatically resets all others.

Why does my device property show a (none) value?

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

When a new phone model launches, some device types may not yet be mapped. In these cases, [Amplitude] Device type is (none).

Server-side events can also have null device information when these fields aren't updated together: platform, os_name, os_version, device_brand, device_manufacturer, device_model, and carrier. Setting any of these fields resets all other property values to null unless you set them explicitly for the same event.

User counts from past events

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

The user count can increase when Amplitude later ingests events that occurred in the past. Common reasons:

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

The user count can decrease when Amplitude merges user records.

Amplitude uses a system of user IDs, device IDs, and Amplitude IDs to track unique users. If some users don't have user IDs, or if you have many anonymous events, Amplitude first assigns these anonymous events to an anonymous profile, then later merges them into a known profile.

Your data stabilizes over time as anonymous users return and merge into existing profiles. The time this takes depends on user behavior (how often they return to your product) and your settings (how often you batch events). Users who interact with your product every day have shorter merge delays. Users who return less frequently have longer delays.

Data discrepancies with other platforms

Amplitude's numbers may differ from those reported by other vendors. The cause can vary.

Before you compare numbers, review how Amplitude tracks users and sessions. Refer to tracking unique users and the definition of a session in Amplitude.

Data discrepancy checklist

Use the following questions as a troubleshooting checklist for data discrepancies. If you can answer "yes" to a question, that factor is 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 match what you're tracking in the other platform?

If not, a discrepancy in users and sessions numbers becomes more likely, because both depend on the events tracked.

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

If not, a discrepancy in users and sessions numbers becomes more likely.

Do both platforms define the metric of interest the same way?

If not, a discrepancy is more likely.

Does the other platform merge users the way Amplitude does?

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

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

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

Sessions in Google Analytics

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