Identity Logs

Identity Resolution Logs show you how incoming requests are processed by IDSync, mParticle’s identity resolution system. Each log entry records the identity call that was made, which identifiers were involved, what lookup operations occurred, and which MPID was ultimately resolved.

This visibility makes it possible to answer questions that were previously difficult or impossible to investigate, such as: why did this email address stop resolving to the expected MPID? What caused an identifier to move from one MPID to another? Identity Resolution Logs are designed to help debug identity resolution behavior, understand how profiles are created and linked, and build confidence in how IDSync is handling your users’ data.

The following section provides an overview of how IDSync processes identity requests and how that maps to what you see in the logs. If you’re already familiar with IDSync’s resolution flow, you can skip ahead to Accessing Identity Resolution Logs.

How identity resolution works

When mParticle receives an identity request through the mParticle SDK, the Events API, or an inbound feed, IDSync processes it using the following workflow:

1. Read: IDSync reads the identity lookups for each identifier value provided in the request (such as an email address, customer ID, or device ID) to find candidate MPIDs that are already associated with those values.
2. Select: Based on your identity strategy, IDSync selects an MPID from the candidates, or creates a new one if no valid candidate exists.
3. Write: IDSync writes associations back to the identity lookups so that future requests containing the same identifier values will resolve consistently.

Not every step applies to every call type, and the exact operations depend on the call type and your configured identity strategy.

Each step in this flow produces the lookup operations (Create, Update, and Delete) that you see in Identity Resolution Logs. While IDSync reads existing lookups as part of the resolution process, only operations that modify the lookup table are recorded in the logs. Each identity lookup maps a single identifier value to one or more MPIDs, and each lookup is processed independently and sequentially.

IDSync stores a collection of mappings from individual identity values to an MPID over time. This is why the logs show individual operations per identifier rather than a holistic view of a profile. When a login call includes both a customer ID and an email, IDSync processes each identifier’s lookup independently, and the logs reflect that with separate rows for each.

The identity call types shown in the logs correspond directly to the IDSync API endpoints:

• Identify (can be called with any identifier) resolves the user to an MPID.
• Login (can only be called with login identifiers) resolves the user to an MPID. Login is used when transitioning a user to an authenticated state.
• Logout transitions to an unauthenticated state, often creating a new anonymous MPID.
• Modify explicitly changes identity associations on an existing MPID.

Accessing Identity Resolution Logs

To access Identity Resolution Logs:

1. Log in to your mParticle account.
2. In the left-hand navigation, go to Customer 360 > Identity Resolution Logs.

The Identity Resolution Logs page provides a search bar where you can enter an MPID to look for identity resolution logs related to that ID.

You can navigate between Identity Resolution Logs and a user’s User Profile page. If you’re starting from an identifier like an email address or Customer ID, look up the associated MPID on the User Profile page, then use that MPID to search in Identity Resolution Logs. Clickable MPID values in the logs table will take you to the corresponding User Profile.

Viewing Identity Resolution Logs

The Identity Resolution Logs table displays identity events sorted from most recent to least recent. Each row represents either a top-level identity call or an individual lookup operation within that call.

Each column in the table below corresponds to a part of the resolution flow described above.

Log table columns

Column	Description
Timestamp (UTC)	The date and time the identity call was received, displayed in UTC.
Source	The platform or feed that sent the identity request (for example: Web, iOS, Android, or API).
ID Call	The type of identity call that was made: Identify, Login, Logout, or Modify.
Identifiers	The type of identifier involved in the lookup operation (for example: IDFV, Email, or Customer ID). For parent rows, this shows the total number of identifiers in the call.
Value (of the Identifier)	The value of the identifier used in the lookup operation (for example: an email address or device ID). Values may be truncated in the table for long strings.
Lookup Summary	The lookup operations that occurred as a result of the identity call. Parent rows show a summary count. For example: Create (2), Update (1). Child rows show the specific operation for each identifier.
Initial MPIDs	The MPID(s) associated with the identifier before the operation was performed. A dash (–) indicates no prior association existed.
Resulting MPIDs	The MPID(s) associated with the identifier after the operation. “No change” indicates the operation did not modify the existing association. “Null” indicates the association was removed.
Resolved MPID	The final MPID that IDSync resolved the identity call to. This is the MPID returned to the calling application or SDK.
MPID Status	Whether the resolved MPID represents a known user (authenticated, with login identifiers) or an anonymous user (device-only, no login identifiers).

Understanding parent and child rows

A single identity call to IDSync often produces multiple lookup operations. For example, a Login call that includes both a customer ID and an email address will trigger separate lookup operations for each identifier.

Identity Resolution Logs represent this with an expandable parent-child row structure:

• Parent rows represent the overall identity call. They display the timestamp, source, ID call type, a count of identifiers involved, a summary of lookup operations (for example: “Create (2), Update (1)”), and the resolved MPID and status.
• Child rows represent individual lookup operations within the call. Expand a parent row to see the specific identifier type, identifier value, lookup operation, and before/after MPID state for each operation.

Parent rows that can be expanded are indicated by an expand icon on the left side of the row. Not all rows have child rows; if an identity call includes only a single identifier, the parent row contains all relevant information.

MPID Status

The MPID Status column indicates whether the resolved MPID is known or anonymous:

• Known: The MPID is associated with at least one login identifier (such as a customer ID or email address configured as a login ID). This typically represents an authenticated user.
• Anonymous: The MPID is associated only with device-level identifiers (such as IDFV or device application stamp) and has no login identifiers. This typically represents an unauthenticated user or device.

For more information on how IDSync handles known and anonymous users, see the IDSync documentation.

Understanding lookup operations

Identity Resolution Logs record the operations that IDSync performs on its internal identity lookup table, the storage layer that maps identifier values to MPIDs. Each log entry captures the before and after state of these lookups, giving you a clear view of what changed and why.

Lookup operation types

Lookup operation	Description
Create	A new identity lookup was created. This means an identifier value was associated with an MPID for the first time. For example, when a new user signs up and their email is stored against a newly created MPID.
Update	An existing identity lookup was modified. This can mean an MPID was added to or removed from the lookup. For example, when a unique identifier migrates from one MPID to another, the lookup is updated to point to the new MPID.
Delete	An MPID was removed from an identity lookup. This typically occurs during a Modify call when an identifier is explicitly removed from a user profile.

How identity calls map to lookup operations

Each type of identity call typically produces a characteristic set of lookup operations. The following table shows the most common patterns, though actual results vary depending on your identity strategy configuration and the data present at the time of the call.

ID Call	Common lookup operations	Description	Example
Identify	Create, Update	Reads lookups for provided identifiers to find candidate MPIDs, then creates or updates associations.	SDK initializes and sends device identifiers. IDSync reads existing lookups, finds no match, creates a new MPID and stores the association.
Login	Create, Update	Similar to Identify, but specifically handles the transition to an authenticated user state.	User logs in with email. IDSync reads the email lookup, finds an existing MPID, and updates associations for device identifiers.
Logout	Create	Typically creates a new anonymous MPID. This moves tracking to a fresh profile so post-logout activity is not attributed to the previously authenticated user.	User logs out. IDSync creates a new MPID and associates the device identifier with it.
Modify	Create, Update, Delete	Explicitly changes identity associations on an existing MPID. Can add new identifiers, update existing ones, or remove identifiers.	API call changes a user’s email. IDSync deletes the old email lookup association and creates a new one for the updated email.

Reading the Initial and Resulting MPID columns

The Initial MPID(s) and Resulting MPID(s) columns together show the before-and-after state of each lookup operation:

• A dash (–) in the Initial MPID(s) column means the identifier had no prior association. This is a brand new lookup.
• “No change” in the Resulting MPID(s) column means the operation did not modify the existing association.
• “Null” in the Resulting MPID(s) column means the association was removed entirely.
• When both columns show MPID values but they differ, this indicates a migration where the identifier moved from one MPID to another.

Searching and filtering logs

Search

Use the search bar to find logs for a specific MPID. Enter the MPID and click Enter to view all identity resolution events associated with that user. If you’re starting from an identifier like an email address or customer ID, you can find the associated MPID by looking it up on the user’s User Profile page.

Time range

When viewing search results, you can adjust the time range using the date selector at the top left of the results table. This controls how far back the search results will go. By default, logs are shown for the last 7 days.

Filters

To narrow your results, click the Filters button to open the filter modal. All filters are multi-select, allowing you to combine criteria.

Filter	Description
Source	Filter by the platform or feed that originated the identity call. Options include platforms (iOS, Android, Web, tvOS, Roku, Alexa, SmartTV, FireTV, Xbox) and any feeds configured in your workspace.
ID Call	Filter by identity call type: Identify, Login, Logout, or Modify.
Identifier	Filter by identifier type. Options include: IDFV, MPID, Customer ID, Email, Roku ID, Android Device ID, Microsoft ID, Facebook ID, Fire Advertising ID, and others.
Lookup Status	Filter by the type of lookup operation: Create, Update, or Delete.
MPID Status	Filter by the resolved MPID status: Known or Anonymous.

After selecting your desired filters, click Apply to update the results. Click Cancel to discard changes.

No results found

If a search returns no results, there are a few possible reasons:

• The event may not have been ingested yet due to data latency.
• The event may have occurred outside your selected time range or beyond your data retention window.
• The MPID may not have been involved in any identity calls during the selected period.
• Identity Resolution Logs only capture events that occurred after the feature was enabled for your workspace, so earlier activity will not appear.

Try expanding the time range, or allow additional time for recent events to become available.

Use cases and examples

Identity Resolution Logs are most useful when something unexpected happens and you need to understand why. The following examples walk through common scenarios you might encounter, what to look for in the logs, and how to interpret what you find.

Debugging an unexpected MPID change

One of the most common reasons an identifier stops resolving to the expected MPID is a unique identity migration. If an identifier type is configured as unique (meaning it can only belong to one MPID at a time), and a new MPID claims that identifier, the previous MPID automatically loses its association. For example, if “joe@example.com” is unique and a Modify call assigns it to MPID 456, it is removed from MPID 123.

To investigate, search for the user’s MPID in Identity Resolution Logs. Look for Update operations where the Initial and Resulting MPIDs differ. The parent row will show you what identity call triggered the change, and expanding it will reveal the other identifiers that were involved in the request.

Tracing an identity merge

When a user logs in for the first time on a new device, IDSync may link their device identifiers to an existing MPID. To understand how identifiers were merged, look up the user’s MPID on their User Profile page and search for it in Identity Resolution Logs. Expand the Login call’s parent row to see the individual lookup operations. You’ll typically see Create operations that associated the new device identifiers with the existing MPID.

Investigating a profile split

If a user appears to have two separate profiles, look for Logout calls in the logs. Most identity strategies create a new anonymous MPID on logout so that subsequent activity is not attributed to the previously authenticated user. The logs will show a Create operation under the Logout call with a new Resolved MPID, and you can trace which device identifiers were associated with that new profile.

A related scenario occurs when a Modify call explicitly removes an identifier from an MPID by setting its value to null. This appears as a Delete operation in the logs. If the MPID has no remaining identifiers that can resolve to it, it effectively becomes orphaned.

Verifying identity strategy behavior

Identity Resolution Logs aren’t only useful when something goes wrong. You can also use them to build a baseline understanding of how IDSync handles your data under normal conditions. Look up a known user’s MPID on their User Profile page and search for it in Identity Resolution Logs. Review the log entries to see how identity calls flow through the system, what lookup operations are produced, and how MPIDs are assigned.

This is especially valuable after changing your identity strategy configuration. Walk through the log entries for a test user to verify that lookup operations, MPID selection, and Known/Anonymous status all match your expectations.

Limitations

Keep the following limitations in mind when using Identity Resolution Logs.

Data latency

Identity resolution logs are not available in real time. There is a short delay between when an identity event is processed and when it appears in the logs. When investigating recent events, allow some time for logs to become available.

Data recency

Identity Resolution Logs capture events on a go-forward basis only. Events that occurred before the feature was enabled for your workspace are not available in the logs.

Retention

Identity resolution logs are retained in accordance with your data retention policy. Logs older than your retention window will no longer be available for search.

Mutation operations only

Identity Resolution Logs currently show mutation operations (Create, Update, Delete) that modify the identity lookup table. Read operations, which show how IDSync queried existing lookups to find candidate MPIDs, are not currently shown.

Identity Resolution Logs should be used as a debugging tool

Identity Resolution Logs are designed as a debugging and observability tool, not as an audit log. While the system captures the vast majority of events, a small number of events may not be recorded in rare edge cases.