Compare affected and successful customers

Your agent can compare the customers who hit an Issue with customers who completed the same workflow successfully. The comparison shows which recorded attributes differ between the two groups. It is evidence for the next question. It does not prove a cause.

Ask your agent

For issue ISSUE_ID, compare the customers who hit it yesterday morning with customers who completed checkout_completed in the same window. Which browser, release, or flag differs?

Job	MCP tool or action	CLI command
Compare affected customers with explicit-success controls	compare_issue_customers (a read action: discover it with list_read_actions, run it with execute_read_action)	anectico issues compare-customers
Read the Issue the comparison is about	get_issue	anectico issues view

The agent needs the Issue ID (group_id), the exact success event for the workflow, and a past window of at most seven days within your readable retention. An environment is optional. The key needs persons:read, errors:read and analytics:read. MCP calls also need mcp:read.

What your agent gets back

The result contains cohort counts, missing-value indicators, fractions, differences, the check time, and partial. It does not save a cohort, change an Issue, or trigger an action.

The affected cohort contains canonical people with an attributed occurrence of this Issue. The control cohort contains canonical people who recorded the success event and did not hit this Issue in the same window. A person who failed and later succeeded stays in the affected cohort. Anonymous aliases that have been linked to a person count once. Signals without an identity are excluded. Merged source Issues are not included automatically.

Open the proof

A comparison result has no page of its own. To check the affected group, open the Issue’s page from the url that get_issue returns. See Proof pages. The page is read-only.

Read the differences correctly

Each row shows a recorded attribute value, its count and fraction in each cohort, and the percentage-point difference. A fraction describes the composition of a cohort. It is not a failure probability. A difference is an association. It is not proof of cause, and it is not statistical significance. Use a comparable workflow and environment. Then inspect the trace, stack, or replay before you assign a cause.

The latest matching failure supplies each affected person’s attributes. The latest matching success supplies each control’s attributes. Supported dimensions are:

• browser.name
• os.name
• service.version
• device.model.name
• feature_flag.variant

Record failure dimensions as error tags and success dimensions as event properties. For example, an OTLP error span uses anectico.tag.browser.name=Safari, while the success event uses the property browser.name=Safari. An unprefixed OTLP span attribute is not automatically an error tag. Release comparison uses the error’s release and the success event’s service.version. A feature-flag variant should represent the same selected flag on both signals. This comparison does not combine arbitrary flag exposures, and it does not identify the responsible flag automatically.

Not recorded is a separate value, not an inferred default. If either cohort is empty, Anectico reports insufficient evidence instead of estimating differences. Reads are bounded at 5,000 canonical people and 100 difference rows. A partial result describes a subset: narrow the window before you draw conclusions. This is not a random sample.

CLI and API

anectico issues compare-customers --file comparison.json

{
  "group_id": "ISSUE_ID",
  "success_event": "checkout_completed",
  "environment": "production",
  "start_time": "2026-09-09T09:00:00Z",
  "end_time": "2026-09-09T12:00:00Z",
  "dimensions": ["browser.name", "service.version"]
}

Use current timestamps within your readable retention. The REST route is the read-only POST /api/v1/errors/customer-comparison?project_id=PROJECT_ID.