Understand one customer’s 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.

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.

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.

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.