How Anectico connects the story

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 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
• Verify your setup
• Identify customers correctly