# Understand one customer’s story

> Use the customer timeline to follow errors, traces, logs, replay, events, and AI activity in order.

Canonical page: https://anectico.com/docs/investigate/customer-story/


When a customer reports a problem, begin with the customer rather than guessing which signal to
search first.

## Find the customer

Open **Customers** and search using a stable ID, email, or another identifying property. Anectico returns
the canonical customer and the aliases that have been connected to them.

The customer title uses email or name when those properties exist. Otherwise, it prefers a stable,
recognizable distinct ID over a generated UUID-like anonymous ID while keeping every linked ID in
the alias list below the title.

The **Properties** card lists the canonical profile one key at a time in stable key order. JSON
`null` is a stored value and appears as `null`; an empty string appears as `""`; `false`, `0`,
arrays, and objects keep their JSON meaning. An explicitly unset property is removed from the card
entirely, so absence is never presented as an empty or null value.

If you find separate profiles for the same person, stop and fix instrumentation before trusting the
timeline. See [Customer activity is not connecting](/docs/help/identity-not-linking).

## Set the investigation window

Select the relevant project and use the header's global time-range selector. Changing the range
reloads Activity from the first page inside that window, so start slightly before the customer
noticed the problem and include the lead-up. **Load more** remains inside the selected window.
Use the environment selector on supporting signal pages when you follow timeline links.

The customer summary shows signal counts, **replay sessions**, and LLM spend. The replay-session
count is the number of stored recordings, not a count of every session ID seen on other signals.
Use these totals to decide where to look, but use the timeline for sequence.

## Read the timeline in order

Filter the activity kinds and platform values when the story is noisy. Platform chips use metadata
stored on each signal: explicit `platform` or `$platform` event properties, authenticated SDK
context for errors, and emitting resource metadata for traces and logs. **Unknown** means that
signal has no authoritative platform metadata; it does not mean the activity came from a separate
unknown device. Replay sessions and agent runs currently appear as Unknown rather than inheriting a
platform from nearby activity.

An agent run appears on a customer's timeline when any step of that run recorded their identity, and
the card reports the whole run — every step, tool call, token and unit of cost — not only the steps
that carried the identity.

The project boundary remains the dashboard's active-project selector. Customer identity is
project-scoped, so changing projects loads that project's customer profile and timeline instead of
merging one identity across projects.

Copied customer links are tenant-confined. If a UUID is neither a customer nor a mapped identity in
the selected project, the page shows the same **Customer not found** state whether that UUID belongs
to another project, belongs to another organization, or does not exist. It does not echo the UUID or
reveal which case occurred. UUID-shaped application-install aliases continue to work after the
selected project has mapped them through normal ingestion.

Each row has two deliberately separate clocks when Anectico knows both:

- the time at the right is when the activity **occurred** and determines its position in the
  timeline; and
- **Received** is the server-captured time when Anectico accepted the telemetry.

If receipt is at least five minutes after occurrence, the row shows a **Delayed** badge with the
delay. This is expected for offline mobile, vessel, edge, and buffered exporters: the row remains at
its original occurrence position instead of jumping to the top when it uploads. Older trace/log
rows may have no trustworthy receipt time; those rows omit **Received** and are never labelled
delayed. Use the received time to diagnose upload lag, not to reconstruct causal order.

For a diagnostic event, select **Event payload** to inspect the captured properties without leaving
the timeline. Valid JSON is formatted as text, including nested values and `null`; it is never
executed as HTML. Empty payloads and malformed JSON are identified explicitly, malformed data is
shown as raw text, and very large payloads are scrollable and visibly truncated after 20,000
characters.

A productive investigation usually follows:

1. the customer action or diagnostic event;
2. the browser or mobile error;
3. the session replay around that moment;
4. the distributed trace;
5. correlated backend logs; and
6. the release or flag exposure that changed behavior.

Open evidence in place, then return to the same point on the customer timeline. The customer remains
the investigation anchor even when you temporarily inspect a trace or Issue.

## Compare sessions and application installs

Use **Session & application-install context** above the activity list to compare the context carried
by the loaded rows. Each row groups one `distinct_id` and `session_id` pair, shows the source
platforms, and can be included or excluded with its checkbox. The activity rows also show and let
you copy their full IDs. **Load more** still fetches the next normal timeline page; comparison and
filtering do not change server pagination or sort order.

A persisted anonymous `distinct_id` from a mobile SDK is an **application-install alias**. It can
change after an uninstall/reinstall or an SDK identity reset, and after `identify` the signal may
instead carry an application account ID. It is not a phone, tablet, advertising, serial, or other
hardware identifier. Anectico does not collect a hardware ID for this comparison.

`session_id` identifies the application session attached by the emitting SDK. A row can legitimately
show **No session ID** when the signal was emitted without session context, and **Unattributed** when
it has no `distinct_id`. Anectico shows those values honestly instead of borrowing context from a nearby
row.

## Ask for an explanation

Select **Explain this person** and ask a specific question:

> Why did this customer's checkout fail after the latest release?

Review the citations before acting. A useful answer should point to the exact Issue, trace, logs,
replay, or release supporting each conclusion.

## Follow the account behind a customer

Use [Accounts and watched segments](/docs/investigate/accounts-and-segments) when you need to
investigate a company or group of customers rather than one person.

## Watch a high-value customer

Select **Watch this customer** to create an alert for future customer-impacting activity. Choose a
notification channel and keep the rule narrow enough to avoid alert fatigue.