Product analytics should end in a question, not a report queue

The usual analytics stack collects an event, moves it through two vendors, and leaves a person to translate a product question into a report. twoHelixes now keeps those steps in one loop: collect the event, ask the question, produce a chart, and keep the assumptions visible.

One event model, five wire formats

The native browser tracker, GA4 Measurement Protocol, Segment Tracking API, Mixpanel event/profile APIs, and Amplitude HTTP V2 all land in the same event model. Existing applications can keep their gtag, analytics.track, or legacy trackEvent calls while the storage and reporting stay first party. Unknown write keys are discarded, and every reporting read checks the site owner or team membership.

Sampling begins only when volume earns it

Ordinary traffic is unsampled. When a client or SDK starts emitting faster than its configured ceiling, low-value streams are sampled with an inverse weight. Purchase, identity, sign-up, refund, login, and error events remain intact. Decisions stay stable across a short session slice so the retained data still describes a path rather than unrelated points.

That distinction matters: dropping every tenth event saves writes but corrupts funnels. Keeping a weighted slice of a burst lets event and page-view totals remain estimable, while the API reports both observed and estimated session counts instead of pretending they are the same.

Upstream and server probabilities compose into one stored weight. The collector never draws a second time against a probability the browser already applied. That small detail is the difference between a weighted estimate and silently undercounting a 10% sample by another 90%.

The chart agent can query the event stream

An owned analytics site is now a data source for the normal chart endpoint. A question such as “which pages lead to completed sign-ins?” loads the bounded event window, exposes event properties as columns, and returns the same editable Plotly figure as a warehouse or uploaded file. No export-and-reimport ceremony is required.

A schema catalog discovers arbitrary custom event names, property types, protocol sources, and observed versus estimated counts. Identify mappings resolve anonymous history to a person, while typed group profiles keep accounts and organisations separate from user traits.

Path discovery groups the journeys sessions actually took, while revenue reporting stays separated by currency. There is no implicit exchange rate hiding inside a total.

A terminal is a real rendering target

twohelixes-cli is a standalone, standard-library Go module. It triggers graph generation, prints summaries and recent events, discovers custom-event schemas, builds ordered funnels, asks questions of analytics data, exports a Segment-shaped batch, and renders Plotly bar, line, scatter, and pie traces as Unicode terminal charts.

twohelixes-cli analytics funnel --site netwrck.com \
  --steps page_view,sign_in_started,sign_in_completed

twohelixes-cli analytics ask --site netwrck.com \
  "where do people leave the sign-in flow?"

twohelixes-cli track --protocol amplitude --site thw_... \
  workspace_exported --props @event.json

twohelixes-cli analytics paths --site netwrck.com --days 30
twohelixes-cli analytics revenue --site netwrck.com --days 30

It has no third-party Go dependencies, so it can move into its own public repository without dragging the private service with it. The API key authorises reads; a separate site write key is enough to send events.

What production taught us first

The public Netwrck, eBank, and twoHelixes health paths were all healthy during this pass. The more important finding was release drift: production had already moved to password authentication while the inspected checkout still described email-only sign-in. We did not bypass that boundary to inspect a named account. The CLI therefore uses the stable API-key path, and deployment verification now has to prove the auth and collector contracts it is actually shipping.