What product analytics actually is

Most teams carry two blind spots at once. They know the checkout throws a null pointer 40 times a day, because error tracking told them. They do not know that 3,000 people put something in a cart last week and only 700 paid, because nothing told them. The first is a bug. The second is the business.

Product analytics is the record of what people did — named actions, in order, tied to a person. That is all it is. The rest is querying.

The problem

Named actions live on one session with errors, traces, and replay. When 22% of carts never reach checkout, you open the people who stopped, the replay of them leaving, and the exception thirty seconds earlier — not a second SDK, a second consent story, and a join by timestamp.

So you sit with two tabs open and try to join them by hand, on timestamp and a hunch.

What it is

Four concepts carry almost everything:

• Event — one named thing someone did. add_to_cart, invite_sent, plan_upgraded. You choose the names.
• Visitor — a durable id for a browser or device, created on first contact, before anyone logs in.
• Session — one continuous visit. It ends when the person goes quiet for a while, and a new one starts when they come back.
• Funnel — a sequence of events you expect in order, so you can see which step loses people.

Everything a dashboard shows you is one of those four counted or grouped. Pageviews are events of kind page. Unique users are distinct visitors, collapsed onto a person once they sign in. Top pages is a group-by on the path. There is no fifth magic concept.

How it differs from the tools next to it

• Error tracking answers “what broke, how often, and for whom”. It is triggered by failure. Analytics is triggered by intent — most analytics events are successes.
• Traffic counters (the classic pageview tools) answer “how many people came and from where”. They usually stop at the page boundary and cannot describe plan_upgraded.
• APM answers “how long did the work take and where”. See SDK-native APM. It measures the machine, not the motive.

How Talaria does it

The SDK you already installed for errors also has an analytics API. Turn it on, and calls to track, page, screen, and identify batch up and POST to analytics/ingestBatch. The server sanitizes them and writes to ClickHouse, next to your spans.

Because the SDK already knows the current replay id, trace id, and release, every analytics event carries them. That is the whole trick: correlation is a field on the row, not a join you have to invent later.

The dashboard gives you three surfaces:

• Overview — events, unique people, pageviews, a uniques-by-day chart, top pages, top events, and campaigns.
• Events — the raw stream, filterable by name, kind, user, visitor, or session.
• Funnels — saved step sequences you can evaluate over any window, with the people who dropped.

The overview reports events, uniques, and pageviews — crawlers and automation are excluded by default — plus top pages, top events, UTM campaigns, devices, browsers, operating systems, countries, and traffic class. Country and region come from a GeoIP lookup at ingest, and the IP itself is never stored.

Turn it on

Analytics is off in three places until you turn it on: the organization, the project, and the SDK. That is deliberate — it means nobody ships tracking by accident, and you can put the SDK opt-in behind a consent banner. See Privacy and consent for the reasoning, or the setup guide for the steps.