Compare affected and successful customers

Open an Issue's Compare customers tab. Enter the exact success event for the workflow, an optional environment, and a past time window of at most seven days within your readable retention. Select Compare customers.

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 remains 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 automatically included.

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, not proof of cause or statistical significance. Use a comparable workflow and environment, then inspect the trace, stack or replay before assigning 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 view does not combine arbitrary flag exposures or 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 explicitly describes a subset: narrow the window before drawing conclusions. This is not a random sample.

MCP, CLI and API

Requires persons:read, errors:read, and analytics:read. MCP also requires mcp:read. Discover compare_issue_customers with list_read_actions and invoke it through execute_read_action. The response includes cohort counts, missing-value indicators, fractions, differences, the check time, and partial.

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. It does not save a cohort, change an Issue, or trigger an action.