Reporting

Advanced reporting: numbers computed in SQL, narrative added afterwards

Most reporting dashboards fail one of two tests: the numbers cannot be reconciled with anything, or nobody can say what to do about them. We try to pass both, and the way we do it is boring on purpose.

Every figure is computed in the database from stored events. Interpretation is layered on top and is explicitly forbidden from producing numbers of its own.

GoGee feature series · 27 of 33

How it's actually built

Source data: Stored visitor, session and replay events in Postgres
Aggregation: SQL functions and views, not client-side maths
Attribution: UTM parameters and click identifiers captured with first and last touch
Session metrics: Volume, average duration, top paths over a rolling window
Funnels: Step counts, drop-off from previous step and percentages computed in SQL
AI layer: Clusters issues and writes narrative; every figure substituted from SQL

Reporting pipeline

01Input
Stored events
Visitor, session and replay records
02Database
SQL aggregation
Volume, duration, sources, funnel step counts
03AI
Narrative layer
Clusters issues, assigns funnel step and metric
04Deterministic
Figure substitution
Computed numbers inserted by code
05Output
Report
Dashboards and branded PDFs

Guardrails and fallbacks

The model outputs no numbers at all
Visitor addresses hashed; replay inputs masked

Advanced reporting, data flow, generated from the shared GoGee feature diagram template.

What is measured

Visitor and session records carry the things you need to explain performance rather than just report it: entry and exit URL, referrer, campaign parameters and click identifiers, device, browser and operating system family, viewport, duration and event counts, with the visitor address hashed rather than stored raw.

From those rows the reporting surfaces derive session volume, average duration, top paths, source and campaign breakdowns, and per-visitor history so a lead can be traced back to the campaign that produced it.

First-touch and last-touch source per visitor
UTM and click-identifier capture on landing
Rolling-window session volume, duration and top paths
Device, browser and viewport breakdowns

Funnels are SQL, not vibes

Funnel analysis asks how many sessions reached each step, how many dropped from the previous step, and what those figures are as percentages. All three are computed by database functions over the stored event data.

Comparison and diagnostic views sit alongside so a step can be examined across periods, and replay sessions matching a funnel step can be opened directly to see the friction rather than inferring it.

Where AI is allowed to help, and where it is not

For a single session, an assessment model returns schema-validated JSON: headline, friction points, likely intent, suggested changes and a severity. Across many sessions, the model clusters issues and assigns each to a funnel step and a computed metric.

It is instructed not to output any number at all. The real figures are substituted into its output by code after the fact. That is what makes a report forwardable to a client: the narrative is generated, the arithmetic is the database.

Schema-validated output, stored once per session and read many times
Severity levels so a team reviews the worst sessions first
No model-generated statistics anywhere in the output

Operational reporting around it

Beyond traffic, the same approach covers the commercial side of a build: orders, catalogue and stock positions, credit and AI usage with pending counters, and email delivery and engagement where campaigns are in use.

Reports can be produced as branded PDFs from the same data, which is usually how they reach the people who never log in.

Questions we get asked

Can the AI get the numbers wrong?

It never produces them. Counts, drop-offs and percentages are computed in SQL and substituted into the AI narrative by code.

Can we see where a specific lead came from?

Yes. Campaign parameters and click identifiers are captured per visitor with first and last touch, alongside their session history.

Is visitor data stored raw?

Visitor addresses are hashed, inputs in replays are masked by default, and retention is a setting.