![\"Identity](\"/images/guides/customer-360/identity/identity-logs/identity-logs-1.png\")
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.
\nThis 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.
\nThe 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.
\nWhen mParticle receives an identity request through the mParticle SDK, the Events API, or an inbound feed, IDSync processes it using the following workflow:
\nNot every step applies to every call type, and the exact operations depend on the call type and your configured identity strategy.
\nEach 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.
\nIDSync 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.
\nThe identity call types shown in the logs correspond directly to the IDSync API endpoints:
\nTo access Identity Resolution Logs:
\nThe Identity Resolution Logs page provides an identifier type selector and a search bar. Select an identifier type, enter the identifier value, and click Search to find related identity resolution logs.
\n
You can search directly with an MPID or another supported identifier, such as an email address or Customer ID. Clickable MPID values in the logs table take you to the corresponding User Profile.
\n\nThe 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.
\n![\"Identity](\"/images/guides/customer-360/identity/identity-logs/identity-logs-2.png\")
Each column in the table below corresponds to a part of the resolution flow described above.
\n| Column | \nDescription | \n
|---|---|
| Timestamp (UTC) | \nThe date and time the identity call was received, displayed in UTC. | \n
| Source | \nThe platform or feed that sent the identity request (for example: Web, iOS, Android, or API). | \n
| ID Call | \nThe type of identity call that was made: Identify, Login, Logout, or Modify. | \n
| Identifiers | \nThe 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. | \n
| Value (of the Identifier) | \nThe 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. | \n
| Lookup Summary | \nThe 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. | \n
| Initial MPIDs | \nThe MPID(s) associated with the identifier before the operation was performed. A dash (–) indicates no prior association existed. | \n
| Resulting MPIDs | \nThe 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. | \n
| Resolved MPID | \nThe final MPID that IDSync resolved the identity call to. This is the MPID returned to the calling application or SDK. | \n
| MPID Status | \nWhether the resolved MPID represents a known user (authenticated, with login identifiers) or an anonymous user (device-only, no login identifiers). | \n
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.
\nIdentity Resolution Logs represent this with an expandable parent-child row structure:
\n![\"screenshot](\"/images/guides/customer-360/identity/identity-logs/identity-logs-3.png\")
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.
\nThe MPID Status column indicates whether the resolved MPID is known or anonymous:
\nFor more information on how IDSync handles known and anonymous users, see the IDSync documentation.
\nIdentity 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.
\n\n| Lookup operation | \nDescription | \n
|---|---|
| Create | \nA 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. | \n
| Update | \nAn 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. | \n
| Delete | \nAn MPID was removed from an identity lookup. This typically occurs during a Modify call when an identifier is explicitly removed from a user profile. | \n
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.
\n| ID Call | \nCommon lookup operations | \nDescription | \nExample | \n
|---|---|---|---|
| Identify | \nCreate, Update | \nReads lookups for provided identifiers to find candidate MPIDs, then creates or updates associations. | \nSDK initializes and sends device identifiers. IDSync reads existing lookups, finds no match, creates a new MPID and stores the association. | \n
| Login | \nCreate, Update | \nSimilar to Identify, but specifically handles the transition to an authenticated user state. | \nUser logs in with email. IDSync reads the email lookup, finds an existing MPID, and updates associations for device identifiers. | \n
| Logout | \nCreate | \nTypically creates a new anonymous MPID. This moves tracking to a fresh profile so post-logout activity is not attributed to the previously authenticated user. | \nUser logs out. IDSync creates a new MPID and associates the device identifier with it. | \n
| Modify | \nCreate, Update, Delete | \nExplicitly changes identity associations on an existing MPID. Can add new identifiers, update existing ones, or remove identifiers. | \nAPI call changes a user’s email. IDSync deletes the old email lookup association and creates a new one for the updated email. | \n
The Initial MPID(s) and Resulting MPID(s) columns together show the before-and-after state of each lookup operation:
\nUse the identifier type selector and search bar to find logs for a specific identifier. Select the identifier type, enter its value, and click Search to view associated identity resolution events.
\n\nMake sure the selected identifier type matches the value you enter. For example, select Email Address when searching for an email address. Selecting the wrong identifier type may return no results.
\nWhen 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.
\nTo narrow your results, click the Filters button to open the filter modal. All filters are multi-select, allowing you to combine criteria.
\n| Filter | \nDescription | \n
|---|---|
| Source | \nFilter 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. | \n
| ID Call | \nFilter by identity call type: Identify, Login, Logout, or Modify. | \n
| Identifier | \nFilter by identifier type. Options include: IDFV, MPID, Customer ID, Email, Roku ID, Android Device ID, Microsoft ID, Facebook ID, Fire Advertising ID, and others. | \n
| Lookup Status | \nFilter by the type of lookup operation: Create, Update, or Delete. | \n
| MPID Status | \nFilter by the resolved MPID status: Known or Anonymous. | \n
After selecting your desired filters, click Apply to update the results. Click Cancel to discard changes.
\nIf a search returns no results, there are a few possible reasons:
\nTry expanding the time range, or allow additional time for recent events to become available.
\nIdentity 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.
\nOne 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.
\nTo investigate, select the relevant identifier type and search for its value 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.
\nWhen 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, search Identity Resolution Logs using a known identifier, such as the user’s email address, Customer ID, MPID, or any other supported known identifier. 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.
\nIf 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.
\nA 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.
\nIdentity 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. Search for a known user by email address, Customer ID, MPID, or another supported identifier. Review the log entries to see how identity calls flow through the system, what lookup operations are produced, and how MPIDs are assigned.
\nThis 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.
\nKeep the following limitations in mind when using Identity Resolution Logs.
\nIdentity resolution logs are not available in real time. It can take up to 60 minutes after an identity event is processed before it appears in the logs. When investigating recent events, allow some time for logs to become available.
\nIdentity Resolution Logs capture events on a go-forward basis only. Events that occurred before March 27, 2026, are not available in the logs.
\nIdentity resolution logs are retained in accordance with your data retention policy. Logs older than your retention window will no longer be available for search.
\nIdentity 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.
\nIdentity 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.
","frontmatter":{"title":"Identity Resolution Log","order":3,"seoTitle":null,"seoDescription":null},"parent":{"__typename":"File","modifiedTime":"October 12, 2026"}}},"pageContext":{"slug":"/guides/customer-360/identity-resolution-log/"}},"staticQueryHashes":["2950460867"]}