The operating model

The checkout in chapter 6 is a finished design. Teams still fail after that, usually in operations: tracing on in development and off in production, a second analytics tool “just for marketing,” minLevel left at debug, no one named the events, no one owns the funnel. This chapter is the practice around the calls.

The checklist

Run this when you add a project, and again after every quarter.

1. One project for the storefront and the API that must join — or two projects only when the teams and the inboxes truly split. This example uses one so traceparent is enough.
2. API keys scoped for the signals you send. Default app keys include eventsWrite, spansWrite, replaysWrite, and analyticsWrite. Do not paste a key into a public repo; the browser key is still a project key.
3. Analytics enabled in Project settings only when you intend to collect, then optIn() behind consent. Privacy and consent.
4. Tracing on in Project settings, staging first, then production. The traces sample rate is the one you can say out loud (default 10% success; errors always). Sampling and metering.
5. minLevel at warning or error in production. Named loggers for the one module that must be louder.
6. Same release string on every process you ship together. Release health is otherwise fiction.
7. Replay: keep the error-triggered default until you have a reason and a budget to retain more.
8. Two alert rules before you call it done: new/reopened issues, and a RED threshold on the money route. Alerts.
9. A funnel on the core action — three events minimum — with a name someone else will understand in six months.

Write the names down

Put a page in the repo. Not a wiki novel. A table of event names, transaction names, and the two or three tags you allow. A checkout fits on one screen:

A pull request that adds track('Click') without updating this page is incomplete. Typos become new event names; there is no server-side rename.

A weekly hour

• Issues — anything new or reopened in production. Resolve what shipped. Ignore the rest on purpose.
• Performance — p95 and error rate on the money route. Open one slow waterfall. If N+1 showed up, it is a ticket, not a mystery.
• Analytics — the core funnel. If a step’s drop-off moved, pick three people and walk the incident loop once.
• Volume — accepted events and retained replays against the plan. A sudden info-event spike is a bad logger, not growth.

Definition of done

A team is done instrumenting a surface when:

• The decision table in chapter 2 has been applied to the new code, and leftover info events were deleted.
• The core action has three analytics events and a funnel, with server-side completion where the browser can lie.
• The money route is a named transaction with the children you would actually read.
• A staging throw produces one issue with View trace (and View replay on the web).
• Two alerts exist, release matches the deploy, and the naming page is in the repo.

That is a finished Talaria setup. It is smaller than most teams expect. The course exists so you do not make it larger.