Unexpected values in user counts

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.

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.

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.

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.

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.