# How Anectico connects the story

> Understand what the SDK sends, how customer identity links signals, and where to begin in the product.

Canonical page: https://anectico.com/docs/start/how-anectico-works/


Anectico brings the evidence for one customer into one timeline. You still use familiar signals such as
errors, traces, logs, metrics, events, and replay; the difference is that a stable customer identity
connects them so you can move through the story without searching each tool separately.

## The short version

1. An SDK or OpenTelemetry exporter sends telemetry to one Anectico project.
2. Your application identifies a customer with a stable `distinct_id`.
3. Anectico resolves that ID across errors, traces, logs, events, replay, and AI activity.
4. **Customers** shows the evidence in time order. **Issues** groups failures by cause and impact.
5. **Investigate** can explain the evidence, with links back to the underlying records.

Metrics remain service-level measurements. Do not add customer IDs as metric labels. When a metric
changes, use the same service, environment, and time window to find the traces, logs, Issues, and
customers that explain it.

## What each signal answers

| Signal | Question it answers | Typical example |
| --- | --- | --- |
| Error / Issue | What failed, and who was affected? | Payment exception grouped across occurrences |
| Trace | What happened during one request or job? | Checkout request across API and payment services |
| Log | What detail did the application record? | Provider response or retry decision |
| Metric | When and where did system behavior change? | Error rate, queue depth, or latency distribution |
| Event | What meaningful action did the customer take? | Checkout started or onboarding completed |
| Replay | What did the customer see and do in the browser? | Clicks and UI state around a failure |
| AI call / agent run | How did an AI workflow behave and what did it cost? | Model call, tool use, tokens, and outcome |

No single signal is expected to explain the whole incident. Start from the customer or Issue, keep
the time window fixed, and follow the links between them.

## What the SDK does

The server SDKs configure OpenTelemetry export, add service and environment information, batch
telemetry, and provide helpers for errors, identity, and diagnostic events. Framework integrations
can create request spans and capture unhandled failures. Browser and mobile capabilities differ, so
check [Choose an integration](/docs/start/choose-integration) before assuming feature parity.

Your application still owns four decisions:

- call `identify` only after authentication, using a durable ID;
- call `reset` on logout in stateful clients;
- propagate trace and identity headers only to trusted application services; and
- flush or stop the SDK during graceful shutdown, especially in short-lived processes.

Anectico instrumentation should not replace your application's error handling. Capture the error, then
preserve the application's normal return, throw, retry, or crash behavior.

## The three scopes to check

When evidence looks missing or disconnected, confirm these before changing instrumentation:

- **Project** — the key and dashboard must point to the same project.
- **Environment and service** — use stable names such as `production` and `checkout-api`.
- **Customer identity** — the same stable `distinct_id` must reach every trusted service involved.

API-key permissions are separate from those scopes. Ingestion, diagnostic events, replay, reads,
and operational actions use different permissions so application keys can remain narrow.

## A safe first rollout

Start with one customer-facing journey and prove this path: identify a test customer, create one
trace and captured error, verify the customer timeline, then inspect the Issue. Add metrics, replay,
more services, and automation only after that path works.

- [See your first customer story](/docs/start/quickstart)
- [Verify your setup](/docs/start/verify-setup)
- [Identify customers correctly](/docs/instrument/identity)