Inspect events and customer cohorts

Anectico’s Events and Cohorts views are supporting investigation tools. Use them to establish behavioral context around a customer problem, not as the default starting point for application analytics.

Inspect an event

Open Explore → Events, choose an event name, and review its recent volume and identified customers. If an event is missing, confirm the SDK sent it after identity was established and that the current project and time window are correct.

Open a customer from the triggerer list to compare the event with their errors, traces, replay, releases, and AI calls. Anectico labels each triggerer with the recognizable identifier used for the event while keeping the canonical person behind the link; internal person UUIDs are not customer display names. Event volume alone does not explain an outcome.

Create a cohort

Open Explore → Cohorts and create a reusable customer group. Anectico supports behavioral, property-based, and static definitions. Use a stable name that describes membership rather than the campaign that first needed it.

Choose Refresh after changing upstream data or when current membership is required immediately. Open the cohort’s members to validate representative customers before using it in a feature rollout or watched alert.

For a behavioral or property cohort, choose Preview current matches before saving. Preview is a point-in-time, non-mutating evaluation: Anectico shows the complete matching count, a bounded sample of people, the evaluation time, and the definition hash. Saving or editing a definition does not make an older preview current; run preview again after every definition change.

Static cohorts use explicit full-list replacement. Choose Replace members, supply the complete desired list of person UUIDs or project-scoped distinct IDs, and review the warning before submitting. The operation never appends. An empty submission intentionally clears the cohort. Anectico fences the write with the generation that was current when the dialog opened, so a concurrent refresh or edit is rejected instead of overwriting newer membership.

After a static create or replacement, keep the resolution summary with the change record. It reports:

• input values received;
• inputs that resolved to a known person;
• unique canonical people written;
• duplicate inputs that collapsed to an already-resolved person; and
• unresolved inputs, including the exact unknown values to correct.

Unknown values are skipped; they are never treated as new people. The summary remains visible in the cohort workflow so a successful request with unresolved inputs cannot be mistaken for a lossless import.

Audit membership generations

Choose History on a cohort to inspect immutable materialization generations. The current and retained states are explicit, along with total members, added and removed counts, refresh reason, actor, materialization time, definition snapshot and hash, and Alert-targeting delivery status. Choose Open generation to inspect the exact member list for a retained historical generation. Generations marked Not retained keep their audit metadata but no longer expose a member list.

The Alert-targeting badge describes whether the current generation has reached the audience mirror used by alert evaluation:

• Syncing — delivery is pending;
• Retrying — a retry is in progress or queued;
• Failed — the generation is not available to Alert targeting; and
• Synced — Alert targeting is evaluating this generation.

Do not assume an updated cohort is active for Alerts until the badge reads Synced. Retry a failed refresh or contact an administrator if delivery does not converge.

Cohort reads are available to principals with cohort read access. Creating, editing, refreshing, replacing membership, and deleting also require an organisation owner or admin role plus the corresponding write or delete permission. The UI remains inspectable but removes mutation controls when either side of that gate is missing.

Deleting a cohort is destructive. Feature flags that target it stop matching those members, so remove or replace those dependencies first.

Keep definitions trustworthy

• Prefer stable identity and normalized properties.

• Avoid static lists when a behavioral or property definition expresses the rule.

• Sample members after creation and after significant instrumentation changes.

• Record why a cohort exists in its name or team runbook.

• Send diagnostic events

• Identify customers

• Check rollout health