> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/operate-and-monitor/explore-a-user-profile.md).

# Explore a user profile

Look one user up and read what the platform actually holds about them.

## Your goal

Open a single user and read their raw data - to check that collection works as designed, to investigate a support question, or to answer an access request.

## Expected outcome

You can see a user's identifiers, profiles, activities, segments, and choices, and compare them against what you expected to collect.

## Why this is the fastest debugging tool you have

Aggregate reports tell you that something is wrong; one user tells you **what**. A property landing at the wrong path, an identifier that never arrives, an event rule doing something unexpected, an activity analyzer stripping a field - all of these are visible in seconds on a real UserPoint, and invisible in a count.

## Open the User lookup screen

In the Navigator, open **User lookup**, under the **Audience** section. It gives you a 360° view of one [UserPoint](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/userpoint-and-identity-graph.md), gathering everything the platform holds about that user.

By default, the screen shows the UserPoint associated with the user agent ID - the vector ID - from your own browser. In other words, it shows you.

### Look up someone else

Use the **User lookup** button at the top right of the view. You can find a UserPoint by any of these:

| Search on           | Notes                                                                                                                                  |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **User Account ID** | The identifier of a registered user, in one of your compartments.                                                                      |
| **User Agent ID**   | The vector ID.                                                                                                                         |
| **Email hash**      | The hashed form of the user's email address.                                                                                           |
| **UserPoint ID**    | The identifier the platform created for that user, shown at the top of the screen, for example `ab8e2bba-6b6a-46ab-bd6a-a212063b8e10`. |

### What each block shows

<table data-search="false"><thead><tr><th width="200">Block</th><th>What it holds</th></tr></thead><tbody><tr><td><strong>Profile</strong></td><td>Everything on the UserPoint's profiles: data captured from a CRM such as name or birth date, and computed data such as scores. Which fields exist is decided by your datamart <a href="/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md">schema</a>, and <a href="/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-compartments.md">compartments</a> keep profiles from different sources apart.</td></tr><tr><td><strong>Segments</strong></td><td>Every segment the UserPoint belongs to.</td></tr><tr><td><strong>Timeline</strong></td><td>The user's activities and events, newest first.</td></tr><tr><td><strong>User Account Id</strong></td><td>The UserAccount information. A user can hold several account IDs when your datamart has several compartments.</td></tr><tr><td><strong>User Device</strong></td><td>Every UserDevice known for the user, with the UserDeviceTechnicalIds attached to each: mediarithmics cookie ID, mobile ID, network ID, and so on.</td></tr><tr><td><strong>User Email</strong></td><td>The UserEmail: the hash, and the raw email where it is available.</td></tr><tr><td><strong>User Choices</strong></td><td>What the user has accepted or refused, per processing activity.</td></tr></tbody></table>

### Read the timeline

The timeline represents all of the user's [activities and events](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time.md#the-useractivity-object), from the most recent to the oldest.

Each block on it is an **activity**, gathering the events of one user session. Browsing an e-commerce site, for instance, produces events such as product pages, basket views and purchase actions, all grouped into the activity for that visit.

Click **Details** on an event and expand it to see everything attached to it - item, category, price, and any other property. Which properties exist is decided by your tag integration, so this is the fastest way to check that the tracking plan you agreed on is the one actually running.

You can also view **the complete JSON for each activity**. That raw JSON is the point: it shows the activity **as stored**, after event rules and activity analyzers have run - which is what your queries and your schema see.

### Switch to the technical timeline

A switcher turns the activity timeline into the **technical timeline**, which shows the identifier lifecycle of the UserPoint: when an identifier was added, when UserPoints merged, and when an identifier was removed. Four event types exist:

<table data-search="false"><thead><tr><th width="220">Event</th><th width="250">Triggered when</th><th>Fields</th></tr></thead><tbody><tr><td><strong>Add identifier</strong></td><td>An identifier is added to the UserPoint.</td><td>Subject UserPoint - normally the one you are looking at; the identifier type; the identifier itself; optionally the cause type and the activity that triggered it.</td></tr><tr><td><strong>Merge UserPoint</strong></td><td>The UserPoint is merged with one or more others.</td><td>Target UserPoint - the one kept after the merge; the list of merged UserPoints; optionally the cause type and the activity that triggered it.</td></tr><tr><td><strong>Remove identifier</strong></td><td>An identifier is removed from the UserPoint.</td><td>Subject UserPoint; the identifier type; the identifier itself; optionally the cause type and the activity that triggered it.</td></tr><tr><td><strong>No merge UserPoint</strong></td><td>The UserPoint should have merged with one or more others, and did not, because of a specific cause or a technical rule.</td><td>Target UserPoint; the UserPoints that were not merged; optionally the cause type and the activity that triggered it.</td></tr></tbody></table>

{% hint style="info" %}
**When to reach for it.** The technical timeline is the answer to "why are these two users still separate?" and "where did this cookie ID come from?". A `No merge UserPoint` event is the explicit trace of a merge the platform decided against - see [Resolve identities](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/resolve-identities.md).
{% endhint %}

## Look a user up by API

Any identifier can select the UserPoint, and any document type can be read from it.

```
/v1/datamarts/<DATAMART_ID>/user_points/<USER_POINT_SELECTOR>/<DOCUMENT_TYPE>/<DOCUMENT_SELECTOR>
```

{% tabs %}
{% tab title="Selecting the user" %}

| Selector      | Form                                                                |
| ------------- | ------------------------------------------------------------------- |
| UserPoint ID  | `<USER_POINT_ID>` or `user_point_id=<USER_POINT_ID>`                |
| User agent ID | `user_agent_id=<USER_AGENT_ID>`                                     |
| Account       | `compartment_id=<COMPARTMENT_ID>,user_account_id=<USER_ACCOUNT_ID>` |
| Email hash    | `email_hash=<EMAIL_HASH>`                                           |
| {% endtab %}  |                                                                     |

{% tab title="Choosing the data" %}
`<DOCUMENT_TYPE>` designates what you read:

* `user_identifiers`
* `user_profiles`
* `user_activities`
* `user_choices`
* `user_scenarios`
* `user_segments`
  {% endtab %}

{% tab title="Narrowing to one document" %}
`<DOCUMENT_SELECTOR>` is **optional** - use it to get, update, or delete one particular document. Which selector applies depends on the document type:

```
user_profiles/compartment_id=<COMPARTMENT_ID>
user_profiles/compartment_id=<COMPARTMENT_ID>/user_account_id=<USER_ACCOUNT_ID>
user_choices/processing_id=<PROCESSING_ID>
user_scenarios/scenario_id=<SCENARIO_ID>
user_segments/audience_segment_id=<SEGMENT_ID>
```

{% endtab %}
{% endtabs %}

The UserPoint API allows you to **retrieve, create, update, or delete** all data related to a single UserPoint - so the same endpoints serve investigation and correction.

{% hint style="info" %}
For a single request returning several document types at once, use [GraphQL](/setup-and-monitor/operate-and-monitor/query-your-datamart/graphql-queries.md) instead - bearing in mind its 100-activity limit.
{% endhint %}

## What to check, and what it tells you

| Look at                                          | It tells you                                                                                                                                                                             |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **The identifiers on the UserPoint**             | Whether your tag and imports send what you think. A missing account ID explains an unconsolidated user.                                                                                  |
| **The number of UserPoints for one real person** | Whether identity resolution is working. See [Resolve identities](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/resolve-identities.md). |
| **The raw activity JSON**                        | Whether properties are where the schema expects them, and whether event rules and analyzers did what you intended.                                                                       |
| **Event names**                                  | Whether predefined names are used, and whether `$page_view` events are being relied on - they are dropped at session close.                                                              |
| **The profiles, per compartment**                | Whether imports landed in the right compartment, and whether `$user_account_id` was filled inside the profile object.                                                                    |
| **The user choices**                             | Whether consent exists for the processing activities you are about to enforce.                                                                                                           |
| **The segments**                                 | Whether membership matches what the segment's query should produce.                                                                                                                      |

## Use it in these situations

{% stepper %}
{% step %}

### After implementing tracking

Take one known test user and read their activities. Faster and more conclusive than any aggregate.
{% endstep %}

{% step %}

### When a query returns nothing

Check whether the data is absent, or present but not where the query looks. This distinguishes a collection problem from a schema problem.
{% endstep %}

{% step %}

### Before writing a computed field

The activities a plugin receives are **raw data** - you cannot rely on your schema's structure to know their shape. Read a real activity first. See [Build a computed field](/setup-and-monitor/extend-the-platform/build-a-computed-field.md).
{% endstep %}

{% step %}

### When answering an access request

Retrieve **before** any erasure, and look the person up by every identifier they gave you. See [Exercise rights of the user](/setup-and-monitor/ensure-privacy-and-compliance/exercise-rights-of-the-user.md).
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
A UserPoint in [quarantine](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/userpoint-and-identity-graph.md#quarantine) can still be looked up, but nothing more is added to it. If a user's data stops updating and they look otherwise healthy, check for quarantine and for the hyper-point flag.
{% endhint %}

## Related pages

<table data-view="cards" data-search="false"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Retrieve user data using GraphQL API</strong></td><td>The same job in one request.</td><td><a href="/setup-and-monitor/operate-and-monitor/query-your-datamart/retrieve-user-data-using-graphql-api.md">Retrieve user data using GraphQL API</a></td></tr><tr><td><strong>Data planning and quality</strong></td><td>The checks this belongs to.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/data-planning-and-quality.md">Data planning and quality</a></td></tr><tr><td><strong>Delete user data</strong></td><td>Acting on what you found.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/clean-and-delete-data/delete-user-data.md">Delete user data</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mediarithmics.io/setup-and-monitor/operate-and-monitor/explore-a-user-profile.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.