Understand one customer’s story

When a customer reports a problem, begin with the customer. Do not guess which signal to search first. Your agent finds the customer and reads their timeline. You open the person page that the agent links to, and you check the story yourself.

Choose an investigation

Question	Guide
What happened to one person?	Continue with the timeline workflow below.
What does a support requester encounter?	Support stories and recorded contacts
Which customers or accounts have slow or failed observed requests?	Customer request reliability
Which declared account value is associated with failures?	Declared account value
Does a configuration declaration match received evidence?	Coverage map
Was the requested history readable, and did recorded input settle?	Read coverage and intake completeness
What did product events measure?	Product analytics
Can this result be shown in my chat host?	Charts in your conversation

Ask your agent

Find the customer with the ID user_8842. Show me what happened to them in the two hours before they reported the checkout problem. Give me a link I can open.

Job	MCP tool or action	CLI command
Find a customer by ID, by name, or by another property stored in the clear	search_persons	anectico persons search
Turn any identity key into the one canonical customer and its aliases	resolve_person	anectico persons get (accepts a person ID or a distinct ID)
Read the identity card: properties, first and last seen, signal counts	get_person_profile	anectico persons get, anectico persons stats
Read the timeline	get_person_timeline	anectico persons timeline
Count resolved people and unattributed errors for a service or issue	get_error_impact through the read gateway	anectico issues impact --service <service>
Read the timeline of the business account behind the customer	get_account_timeline	anectico accounts timeline
Read the exact business account's profile and optional retained event activity	get_account_profile through the read gateway	anectico accounts get <type> <key> --include-stats
Find the customer’s complete current traces	search_traces with person_id and one project	anectico traces search --person PERSON_UUID --project PROJECT_UUID
Narrow the customer’s traces to an exact span attribute, such as a route	search_traces with attributes	anectico traces search --person PERSON_UUID --project PROJECT_UUID --attribute KEY=VALUE
Find the customer’s logs	search_logs	anectico logs query --distinct-id <id>
Find the customers who are having a bad time, when nobody has reported yet	find_struggling_people	anectico persons struggling
Find the customers who hit a failure and have no matching report	find_silent_people	anectico persons silent

For an error-attribution question with an absolute interval, use anectico issues impact --service <service> --since <start> --until <end> -o json. The MCP action accepts a relative since, such as 24h, or absolute since and until together. Impact needs errors:read. Keep resolved identified people, resolved anonymous people and unattributed error occurrences separate. A raw sender identifier that spells a real person's ID does not establish an identity mapping. Read that person's counted timeline for their own errors and the windowed service issue inventory for all retained error traffic. An issue's affected-people read is unwindowed. The application's identification remains the attribution boundary; the intake key does not authenticate an end user.

search_persons, resolve_person and get_person_timeline need persons:read. get_person_profile needs persons:profile:read. get_account_profile and get_account_timeline need groups:read. find_struggling_people needs persons:read, and each signal it measures needs the read scope of its own data (see Find who is having a bad time). find_silent_people needs persons:read too, and each report source it checks needs its own read scope (see Find who hit a problem and has no report). MCP calls also need mcp:read.

What your agent gets back

• search_persons returns up to 25 customers per page. Each match has the canonical person ID, whether the customer is identified, a sample of the linked aliases, and its own link to the person page. data.count is the number shown on this page. data.total, when present, is the matching count reported by the service; an absent total means it was not counted. A page is not the whole audience. When pagination.has_more is true, pass pagination.next_cursor as cursor with the same search and limit. In the CLI, use anectico persons search <text> --cursor <next_cursor>. Table output prints the matching count and next cursor; JSON retains the service's pagination. The collection can change between requests, so paging a search does not create a frozen audience.
• resolve_person returns the canonical person ID, the aliases (with their total count), and the link. An ID that maps to no customer is a normal answer, not an error.
• get_person_profile returns the identity card, its activity counts and first or last-seen times, and the link together for the person named in the response. Continue with the returned person_id. An alias can move during an identity correction, so separate requests using the same alias may name different people.
• get_person_timeline answers not_found, with no link, for an ID that no customer has and that no activity carries. The CLI command exits with the not-found code. An ID in a project your credential cannot read gets the same answer. An empty result with a link means the customer exists and has no activity in the window.
• get_person_timeline returns up to 30 rows per page, newest first, merged across product events, errors, traces, logs, agent runs, and sessions. Each row has its kind, the time it occurred, a one-line summary, and the IDs to follow next (trace_id, error_group_id, agent_run_id, session_id, distinct_id). The result has a partial flag. It is true when one of the six signals did not answer: what is shown is true, and what is missing is unknown. A next_cursor continues the same window. The result carries a person proof link only when both canonical person and project were returned.

Pass signal_filter (event, error, trace, log, agent_run or session) to read one kind only. Pass since and until to set the window: a relative age such as 24h, or an RFC 3339 timestamp. until defaults to now. With the CLI, --since and --until take RFC 3339 timestamps, and each needs the other.

Open the proof

Open the link from the result. It opens the person page at /view/person/:id, with the project in the address. The page is read-only. It names its project, and its one action is Copy link. See Proof pages for what every proof page has in common.

Customer identity belongs to one project. A copied link is confined to its project. If an ID is neither a customer nor a mapped identity in that project, the page shows the same Customer not found state. It looks the same whether the ID belongs to another project, belongs to another organization, or does not exist. It does not repeat the ID and does not say which case it is. An application-install alias that looks like a UUID works once ingestion has mapped it in the project.

The page prefers a name when one is available, with email as secondary context. When there is no name, it uses email. Otherwise it prefers a stable, recognizable distinct ID over a generated UUID-like anonymous ID. Every linked ID stays visible under Identity & aliases.

If you find separate profiles for the same person, stop and fix instrumentation before you trust the timeline. See Customer activity is not connecting.

Find who is having a bad time

Use this when no customer has reported anything yet and you want to know who to look at first. The other reads on this page start from a customer you name. This one finds the customers for you. It measures one project over one window and returns the people who crossed a threshold, in order, each with the evidence that put them there.

Ask your agent

Who is having a bad time in the shop project in the last 24 hours? Tell me why each person is on the list, how many people you looked at, and what you could not measure.

Job	MCP tool	CLI command
Find the people having a bad time, with the evidence	find_struggling_people	anectico persons struggling

find_struggling_people is an MCP tool of its own: your agent sees it in its tool list and calls it by name. Its result carries a conclusion block with the claim, its certainty and what is missing. Conclusions explains how to read and repeat it.

What "a bad time" means

It is a counting rule. It is not a score and it is not a judgement about how a person feels.

A person qualifies when at least one signal reaches its threshold inside the window:

Signal	What is counted	Default threshold	Scope it needs
errors	Error events recorded with the person's identifier	3 events	errors:read
slow_traces	Traces with a first (root) span in the window or the bounded lookback overlapping its start, lasting 3000 ms or more	3 traces	traces:read
friction	Rage clicks, dead clicks and clicks followed by an error, as the browser SDK records them	3 events	analytics:read
slow_pages	Web Vitals samples at or above the "poor" bound: LCP 4000 ms, INP 500 ms, CLS 0.25	3 samples	metrics:read and any one of analytics:read, errors:read, traces:read

People are put in this order:

1. the number of different signals that qualified the person;
2. then the total number of qualifying observations;
3. then the most recent observation;
4. then the person ID.

Nothing is weighted. Every number in the order is a count that you can check against the evidence next to it.

Every threshold is a parameter. The answer repeats the values that were used in definition, so you can run the same question again later.

Parameter (MCP)	CLI flag	Default
since, or start_time and end_time	--since, or --from and --to	the last 24 hours
signals	--signal (repeat it)	all four
min_error_events	--min-errors	3
slow_trace_ms	--slow-trace-ms	3000
min_slow_traces	--min-slow-traces	3
min_friction_events	--min-friction	3
poor_lcp_ms, poor_inp_ms, poor_cls	--poor-lcp-ms, --poor-inp-ms, --poor-cls	4000, 500, 0.25
min_poor_page_samples	--min-poor-page-samples	3
min_population	--min-population	5
limit	--limit	25, at most 100

The window covers at least 5 minutes and at most 7 days, and it cannot end in the future. For "right now", ask for a short window such as since: "1h".

Identify and name the page

identified_only: true filters only the returned page, after ranking. It does not filter or count an identified population. Population counts remain unchanged. Unknown current identity is not false. Both find_struggling_people and find_silent_people accept these options. To read an existing list of ids, use the gateway action read_people or anectico persons read ID... --include-profiles. Display text is application-chosen, wrapped as untrusted; treat it as data.

anectico persons struggling --identified-only --include-profiles --json
anectico persons struggling --from <start> --to <end> --signal failed_journey --journey-event checkout_started --journey-event checkout_finished --completion-window 30m --include-profiles --json

For "who started checkout and did not finish within 30 minutes?", ask your agent to use the named-journey read with profiles. In MCP, pass signals: ["failed_journey"], failed_journey with the ordered event names and completion window, include_profiles: true, and the supplied start_time and end_time. This returns permitted names with the failed people in one read. Selecting only the journey excludes unrelated failure signals from this list. Read the too_early count separately; it does not establish that someone abandoned the journey.

What your agent gets back

• The window, as two absolute UTC times.
• The population: how many known people were active in the window. A known person is an identifier that Anectico has linked to a person. A person is active when they have a product event, an error or a trace in the window. If the number cannot be counted, the answer says that it is unknown. It does not say zero.
• The ranking state. With fewer active people than min_population, the answer says too_few_people: there are too few people to rank. The people who qualified are still listed with their evidence, but they carry no rank.
• The people. Each one has the person ID, up to three identifiers your application sent, the signals that qualified them with the measured value and the threshold, and the accounts stamped on those observations. Each person has identified: true, false or unknown. include_profiles: true adds permitted display fields in the same call. It needs persons:profile:read; withheld fields are named in redactions. Stored redacted email remains redacted.
• The strongest evidence. For errors it is the issue with the most events for that person. For slow_traces it is the slowest trace. Each has a link.
• What each signal measured, in signals. Read state before any number:

State	Meaning
measured	The signal was read over the whole window. Its counts are exact.
withheld	The credential lacks a scope. missing_scopes names it. Nothing of the signal was read.
not_requested	You did not ask for this signal.
scan_limit	The signal exceeds its row or people bound and is excluded in full. Ask for a shorter window.
time_limit	The signal exceeded three seconds. Its counts are unknown.
outside_history	The window is older than the history your plan can read.
not_available	Anectico has no source for this signal.

A signal that is not measured has no counts. That is not the same as zero, and it is not a good experience.

• What could not be given to a person. Each measured signal counts its observations that belong to nobody: without_identifier (no identifier was recorded) and unresolved_identifier (the identifier is linked to no person). These observations are counted and never dropped. unattributed_observations is their sum over the measured signals.

Browser samples carry a session, not a person

A Web Vitals sample knows its browser session. It does not know the person. Anectico gives a sample to a person only when the permitted product events, errors and traces of that session name exactly one known person. It looks at observations from 24 hours before the window to the end of the window. The rest is counted in three groups: without_session, session_without_person and ambiguous_session (the session names more than one person). Nothing is guessed.

Limits to keep in mind

• Missing scopes withhold a signal. They do not refuse the read. persons:read admits the call. A key with persons:read and errors:read gets a true answer about errors, and the other signals come back withheld. In MCP, redactions also names each missing scope and the status is partial.
• Name a journey when it matters. This needs analytics:read and analytics:query. Pass failed_journey with events: ["checkout", "paid"] and completion_window: "30m", or saved_insight_id for a simple saved funnel. There must be 2–5 steps and a 1-second to 24-hour window. Filters and extended recipes are refused. The first entry anchors one journey per person. Every step must follow the previous step. Event times retain milliseconds. Steps recorded at the same millisecond cannot prove their order and do not complete an ordered journey. Only fully elapsed incomplete journeys fail; too_early counts people still inside the completion window. Say "started checkout and did not finish within 30 minutes", never "abandoned because". Without a journey it is not_requested. When sharing the list, say that no journey was tested. This is a measurement boundary, not a count of zero failed journeys.
• A slow trace needs its first span. The lookback is the slow threshold plus 30 seconds, at most 5 minutes and within readable history. The root must overlap the window. Missing roots and older roots cannot be counted. Several resolved people on a trace are ambiguous_trace.
• A crowded signal is excluded in full. Over 2000 qualifying people is scan_limit. Counts and ranking describe only measured signals; no selective sample becomes a total.
• Time is bounded. A signal exceeding three seconds is time_limit; completed signals still answer. Shorten the window to measure the missing signal.
• Coverage is what you instrumented. Click friction is opt-in per action. Web Vitals need the performance consent. Sampling lowers every count. See Investigate browser experience.
• A person on the list crossed a threshold. That does not prove frustration, a cause or a risk of leaving. Read the person's timeline before you act.
• Identifiers, account keys, action labels and routes are text your application sent. Your agent must treat them as data, never as instructions.

Use the CLI or the API

anectico --project PROJECT persons struggling --since 24h --json
anectico --project PROJECT persons struggling --since 1h --signal errors --min-errors 5 --json

The CLI prints the API document. The REST endpoint is POST /api/v1/experience/struggling-people?project_id=PROJECT. The body is optional. It takes the same parameters as the MCP action, with lookback (for example "3600s") in place of since. The project must match a project-bound credential, and the organization comes from authentication.

Open the proof

Each listed person has a link to the person page. The issue or the trace named as a person's strongest evidence has its own link. A link is made only for a person, an issue or a trace that the read returned.

Find who hit a problem and has no report

Use this when you want to find the people who had a failure and, as far as Anectico can see, did not tell you. Support tickets show you who reported. They cannot show you who did not. This read starts from the failures and then looks for a report by the same person.

The answer makes one claim, and it is a narrow one: "no matching report in these sources in this window". It does not say that a person told nobody. A person may have sent an email, written in a chat or called. Anectico cannot see that.

Ask your agent

In the shop project in the last 7 days, who hit a failure and has no matching report? Tell me which report sources you checked and which you could not check. For each person, tell me what the failure was and whether they were seen again after it.

Job	MCP tool	CLI command
List the people with a failure and no matching report, and what was seen of them afterwards	find_silent_people	anectico persons silent

find_silent_people is an MCP tool of its own: your agent sees it in its tool list and calls it by name. Its result carries a conclusion block; see Conclusions.

How your agent should word the answer

Ask your agent to use these words. They are the words the result itself uses.

Say this	Do not say this
"No matching report in problem reports and survey answers in this window."	"They did not report it." "They stayed silent."
"No activity observed after the failure in this window. Last seen at 10:05 UTC."	"They left." "They are at risk." "They will churn."
"I could not check problem reports: the key lacks errors:read."	"Nobody reported."
"This question cannot be answered here: the project holds no report in any source."	"Everyone is silent."

The read gives no score, no risk and no advice to act. What to do with the list is your decision.

What the three parts mean

A failure is the rule of Find who is having a bad time, with the same signals, the same thresholds and the same defaults. A person has a failure when at least one of errors, slow_traces, friction or slow_pages reaches its threshold in the window. The first and the last observation of those signals mark the failure in time.

A matching report is a report whose author is the same person and whose time is at or after the person's first failure observation minus clock_tolerance. The default is five seconds, maximum sixty; zero disables it. The answer counts matches that relied on that allowance in tolerance_matches and tolerance_people. Linked identifiers match the same person. Reports earlier than that allowance are counted in earlier_reports and do not remove the person. The first failure is the first observation of a qualifying signal, not when its threshold was reached.

Anectico never reads what a report says for this answer, and never returns it. A report appears only as a fact: its source, its ID and its time. To read a report, use problem reports with the permission that read needs.

Later activity is an observation of the person at least return_gap_minutes after their last failure observation, inside the window. The default is 30 minutes, so the end of the same visit is not read as a return. The states are:

State	Meaning
active_after_failure	The person was observed again, at least return_gap_minutes after the failure.
no_activity_observed	No activity observed after the failure in this window. last_seen_at says when the person was last seen.
too_early_to_say	The failure is closer to the end of the window than return_gap_minutes. Nothing later could be seen yet.
not_measured	The credential could not read any activity data, or the window holds too much to scan.

The report sources

Source	What it holds	State you will see	Scope it needs
problem_reports	Reports a person sent from your application. They are kept for seven days.	checked when the project holds reports	errors:read
survey_answers	Answers a person gave to an in-product survey	checked when answers exist, or published surveys exist with no answer in the window	analytics:read; surveys:read for scales or empty-source availability
support_complaints	Technical contacts selectively recorded by your agent, kept 30 days from contact time	checked only after complete fact and current identity checks; an empty ledger is unavailable	errors:read and persons:read
tickets	Engineering tickets linked to an issue	always no_person_on_record: a ticket names an issue, not a person	none

The survey rule defaults to any_answer. Use survey_report_rule: {"mode":"low_score","threshold":3} when only ratings of three or below should count. It reads a stored numeric score on the question's known scale, never free text. A rating of nine out of ten then does not count as a report. Unknown scores or scales are unclassified_answers; that source cannot establish an absence. High ratings are counted separately in excluded_high_scores. If you want only problem reports, pass report_sources.

With published surveys and no answer, the source is checked, empty_checked: true and zero records. That strengthens another checked source. When it is the only checked source, people remain undetermined and nobody is listed. No published survey and no answer means not_available. If the credential cannot check survey availability, the answer names surveys:read; it never claims that no surveys exist.

The default checks problem reports, survey answers and recorded support complaints. To select only recorded contacts, use report_sources:["support_complaints"] in MCP or anectico persons silent --report-source support_complaints --since 24h -o json.

Support matching uses the actual reported_at contact time; recorded_at says when the fact was recorded. A later contact in an old ticket needs its own contact ID. References use the Anectico fact UUID, never a provider ticket ID. Both lists count earlier_reports separately.

report_sources[].support states capture_basis: agent_recorded and external_source_complete: false, the recording cutoff, observation revision, final validation clocks, retention floor, identity outcome, nullable unresolved remainder and read limits. The platform has no complete support-desk history. No matching recorded complaint means only that none matched in these checked facts. Refused, unrecorded, withdrawn, expired or erased contacts remain outside that claim. A contact whose recorded identity changed is never counted against either person. An unresolved remainder or incomplete identity check makes the support split unknown. Other checked sources can still support their own qualified conclusion.

A support read permits 10,000 facts in twenty 500-row pages and a separate complete identity verification bound of 250,000 keys and 32 MiB. More facts, malformed or changed pages, unavailable validation or timeout exclude the whole source. An empty manual ledger is not_available; with no other checked source, no_report_source lists nobody and leaves the split unknown.

Read the state of each source before any number:

State	Meaning
checked	The source was read for the window. Its counts are exact.
withheld	The credential lacks a scope. missing_scopes names it. Nothing was read.
not_available	The project holds no record in this source. The absence of a report there says nothing.
no_person_on_record	The source exists, but its records do not name a person.
not_requested	You did not ask for this source.
read_limit	A record, time or scale-verification bound cut the source. It cannot establish an absence.
outside_retention	The window is older than what the source keeps.
failed	The source could not be read or validated. Its classification is unknown.
identity_unverified	Complete current identity agreement could not be established.
source_changed	The recorded contacts changed before final validation. Nothing from that source establishes the split.

Only checked is evidence. A person is never listed because a source was not checked.

What your agent gets back

• The window, as two absolute UTC times.
• answer. answered means the list is real. no_report_source means no report source could be checked or none holds a record. no_failure_signal means no failure signal was measured. In the last two cases the question cannot be answered here. Nobody is listed, and that is not the same as "nobody".
• conclusion.claim. One sentence that says what the answer supports and names the sources that were checked and not checked. The same block gives the certainty of its number: counted, lower_bound when a failure signal was not measured, estimated when a report source was not checked, and insufficient_evidence when the question cannot be answered.
• The population. How many known people had a failure. Of them: how many have a matching report, how many have none, and how many are not determined (their first failure is older than what the checked sources cover). Then the people with no matching report, split by later activity. A number that could not be counted is null. It is not zero.
• The people with no matching report. Each one has the person ID, up to three identifiers your application sent, the time of the first and the last failure observation, the signals with the measured value and the threshold, the strongest issue or trace with a link, no_matching_report_in (the sources that were checked for this person), earlier_reports, the later-activity state and last_seen_at. Use include_profiles to attach allowed display fields; identified_only filters only the returned page. Counts stay over the population.
• The people with a matching report, in reported_people: the person, the first matching report (source, ID and time), how many matched and how many needed the clock tolerance.
• What each failure signal measured, in signals, with the same states as find_struggling_people.
• What is tied to nobody. Failure observations with no identifier or with an identifier that is linked to no person are counted per signal. Reports whose author is linked to no person are counted per source. They are counted and never dropped.

Parameter (MCP)	CLI flag	Default
since, or start_time and end_time	--since, or --from and --to	the last 24 hours
signals and the failure thresholds	--signal and the same flags as persons struggling	as for find_struggling_people
report_sources	--report-source (repeat it)	problem_reports, survey_answers and support_complaints
return_gap_minutes	--return-gap-minutes	30, at most 1440
clock_tolerance	--clock-tolerance	5s, from 0s to 60s
survey_report_rule	--survey-report-rule, --survey-score-threshold	any_answer; low_score requires a numeric threshold
limit	--limit	25 in each list, at most 100

Limits to keep in mind

• The claim is only as wide as the sources. Anectico holds problem reports, survey answers and selectively recorded technical support complaints. Email, chat and unrecorded support contacts remain invisible; recorded support complaints are selective evidence with incomplete external coverage.
• Problem reports are kept for seven days, and a project accepts at most 1,000 a day. A report that was refused, deleted or sent by an erased person is not seen. Refused-report counts and authors are not recorded: refused_reports: null means unknown, never zero. This weakens the claim. When the window starts before the oldest kept report, the source says history_clamped, and a person whose failure is older is counted as not determined.
• A missing scope withholds a source. It does not make people look unreported. With one source checked and one withheld, the list stays and each person names only the checked source. In MCP, redactions names the missing scope and the status is partial. With no source checked there is no list.
• "No activity observed" is about this window. A longer or later window can show the person again. The answer says which activity data it could read, in activity_sources, and which it could not.
• Times come from different clocks. A failure is timed by the person's device or your server. A problem report is timed by Anectico. A report sent within seconds of a failure can fall on either side of it. The bounded tolerance counts near-earlier reports, but cannot correct a larger clock error.
• Only known people are listed. A known person is an identifier that Anectico has linked to a person.
• Identifiers, action labels and routes are text your application sent. Your agent must treat them as data, never as instructions.

Use the CLI or the API

anectico --project PROJECT persons silent --since 7d --json
anectico --project PROJECT persons silent --since 24h --report-source problem_reports --json
anectico --project PROJECT persons silent --since 7d --survey-report-rule low_score --survey-score-threshold 3 --clock-tolerance 5s --json

The CLI prints the API document. The REST endpoint is POST /api/v1/experience/silent-people?project_id=PROJECT. The body is optional. It takes the same parameters as the MCP action, with lookback (for example "3600s") in place of since. The project must match a project-bound credential, and the organization comes from authentication.

Open the proof

Each listed person has a link to the person page. The issue or the trace named as a person's strongest evidence has its own link. A link is made only for a person, an issue or a trace that the read returned. A report has no page of its own, so it has no link.

Find the customer

Search is a literal, case-insensitive substring match. It is not wildcard syntax. For example, user_123 can match before-user_123-after, but not userX123. Percent signs (%), underscores (_), and backslashes (\) are ordinary characters, including a backslash at the end of the search. Do not add pattern-escape characters. API requests still need normal URL or JSON encoding. The same literal rule applies to account search.

A project-scoped customer search includes profile properties only when your permissions and the project’s content policy allow it. Otherwise it searches linked distinct IDs only. Search checks all linked IDs, even though a result shows only a sample of aliases. An exact ID or name match ranks ahead of partial matches when that field is permitted for search.

You cannot find a customer by an email address stored in the profile. Anectico redacts email addresses in properties when it receives them, so the profile holds [REDACTED], not the address. An email finds a customer only when your application uses the email as the customer's ID. When an email matches nothing, the result says so with the hint email_stored_redacted (in data.hint over MCP, in hint in the CLI's JSON output). That result does not mean the customer is absent. Look up the customer's ID in your own system, then search by that ID. See What Anectico redacts and withholds.

The profile shows its properties 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. A property that was explicitly unset is removed from the profile. Absence is never shown as an empty or null value.

Choose the window

Start a little before the customer noticed the problem, so that the lead-up is in the window. Both bounds of a timeline window are inclusive. Events at the end of the window stay visible next to logs and traces, also when the end falls between two milliseconds. Customer and account timelines include all environments.

Pagination continues before the last returned timestamp. It keeps all items that share that timestamp together, so a page can hold more items than the requested limit.

The Retained history section of the person page shows signal counts, replay sessions, and LLM spend across all retained history. It does not depend on the window of the timeline rows. A missing total is Unavailable. A known zero is shown as zero. The replay-session count is the number of stored recordings. It is not a count of every session ID seen on other signals. get_person_profile returns the same per-signal counts. Use these totals to decide where to look. Use the timeline for the sequence. Issues in loaded activity counts only the error occurrences that are already loaded, so loading more rows can change those counts.

Read the timeline in order

You can hide kinds and platforms of the loaded rows on the person page when the story is noisy. This changes only what you see. Platform labels use metadata stored on each signal: an explicit platform or $platform event property, authenticated SDK context for errors, and emitting resource metadata for traces and logs. Unknown means that the signal has no authoritative platform metadata. It does not mean the activity came from a separate unknown device. Replay sessions and agent runs currently show as Unknown. They do not inherit a platform from nearby activity.

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

Each row has two clocks that are kept apart when Anectico knows both:

• The time on the right is when the activity occurred. It decides the position in the timeline.
• Received, under the row’s Details, is the server 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 apps, vessels, edge devices, and buffered exporters. The row stays at its original occurrence position. It does not jump to the top when it uploads. Older trace and log rows may have no trustworthy receipt time. These rows have no Received value and are never called delayed. Use the received time to diagnose upload lag. Do not use it to rebuild causal order. The MCP timeline rows carry the occurrence time only.

For a diagnostic event, select Event payload to read the captured properties in place. Valid JSON is formatted as text, including nested values and null. It is never run as HTML. Empty payloads and malformed JSON are named. Malformed data is shown as raw text. A very large payload scrolls and is visibly cut after 20,000 characters. Each captured event keeps its own Event payload and Details open state, even when several events share the same name, time, and payload.

A good investigation usually follows these steps:

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. the correlated backend logs; and
6. the release or flag exposure that changed behavior.

Each row points to the next page in that chain: the issue, trace, replay, or agent run. Open it from the person page. The customer stays the anchor. Browser Back returns you to the person page with its filters and scroll position. To read the same evidence through your agent, give it the IDs from the row. It can call get_issue, get_trace, get_recording or get_agent_run.

To go beyond one customer and ask what usually happens right before or after one event across many sessions, for example what follows checkout_started, see Measure bounded session paths.

Check recording scope and wider impact

After the person's story, your agent states whether a recording is available and which visit it covers, using the returned session ID and recorded start and end when available. A bounded recording list is not every visit, and recording metadata does not mean playback was read. Missing or withheld recording evidence does not establish that no visit happened.

For each relevant issue, your agent reads its current affected-people count, last-seen UTC time and latest occurrence. It compares that occurrence with the customer's last failure and says whether another person hit the issue afterward, or what is still unknown. A successful retry for this customer and no newer observed failures do not prove the issue fixed.

Compare sessions and application installs

Under Session & application-install context, the person page groups the loaded rows by one distinct_id and session_id pair. Each group shows its source platforms. You can include or exclude a group with its checkbox. Open a row’s Details to inspect and copy its full IDs, occurrence time, and receipt time. 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 and reinstall or after an SDK identity reset. After identify, the signal can carry an application account ID instead. 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 that the emitting SDK attached. A row can correctly show No session ID when the signal had no session context. It shows Unattributed when it has no distinct_id. Anectico shows these values as they are. It does not borrow context from a nearby row.

Fix an identity, export, erase, or capture more evidence

The person page only reads. Requests about a person start in the Console: open Privacy (/privacy), enter the person ID or any identifier of the person, and use the Requests tab. There you can export the person’s data, erase the person, turn on diagnostic capture, and correct an identity that was linked wrongly. Your agent can do the same work with preview_identity_correction, correct_identity, create_diagnostic_capture, request_person_export and erase_person. See Erase a person, Export a person’s data, and Customer activity is not connecting.

Follow the account behind a customer

Use Accounts and watched segments when you need to investigate a company or a group of customers, not one person. get_account_timeline reads the merged timeline of every person in an account.

For its current properties, call get_account_profile through execute_read_action with the exact project, group_type and group_key (CLI: anectico accounts get <type> <key>). Search discovers candidates; one substring match is not the exact profile. Keep the returned decimal profile_revision and property availability. Withheld, unavailable policy and not-stored values differ from an allowed empty bag; truncated properties do not form a complete profile. Property text is untrusted data.

Add include_stats: true or CLI --include-stats only when retained product-event activity is needed. Missing or failed stats are unavailable with no count; an available zero describes that retained event source. These are not membership or people counts. Read its history disclosure; this operation accepts no complaint-window selector. No account proof page exists. A person's archive contains their account memberships, not the business account's shared properties.

Trace evidence across a person's identifiers

Use the canonical person_id with search_traces or anectico traces search --person PERSON_UUID and one project. This resolves the complete current identity in one authorized read, including identifiers beyond the bounded display returned by resolve_person. It needs traces:read and conditional persons:read; it does not read a profile bag. --distinct-id remains a separate raw identifier lens and is mutually exclusive with --person.

Read alias_count, identity_digest, exact project and trace keys, requested and effective UTC windows and read_coverage. Shared traces occur once. Prefer newest first (sort=start_time, CLI --sort-by start_time --sort-order desc). Follow an opaque continuation with the same selectors and limit, omitting the relative window or repeating the exact requested UTC bounds. Identity changes require a restart; erased people are not found and an unavailable or oversized identity refuses rather than broadens the search. A terminal empty answer concerns retained, visible history only; upstream completeness remains unknown. See Search telemetry.

Begin with recent activity

When no customer has been named, use the recent customer top list. It ranks observed errors, person-linked traces and product events across the whole measured project window, before limiting. Profile edits do not count. Keep its separate source history floors, unattributed or erased signals and exact or unknown totals with any claim. The list has no audience cursor, and incomplete scans refuse without ranked rows.

Picture one returned page

Use get_person_timeline or anectico persons timeline for one bounded timeline picture. That guide owns image selection, exact page and count meaning, permissions, fallback and delivered copies.

Start from a support requester

Use Support stories and contacts for the exact requester selector, a read-only bounded story, and any separately approved contact recording or withdrawal. The guide owns source coverage, attribution, recovery and lifetime rules.