Analytics Dashboard

Each quiz has a Metrics tab in the Builder that turns the session-event firehose into a funnel and an A/B comparison. This page walks through what’s in the tab today, what the numbers measure, and how to read them.

[SCREENSHOT: The Metrics tab on a quiz with the funnel on the left and the A/B comparison on the right.]

What you see

The Metrics tab is divided into two panels:

• Funnel. A step-by-step breakdown — quiz views, question views, question completions, recommendation views, lead captures.
• A/B variants. If the quiz has more than one variant, a side-by-side comparison of the same funnel for each variant, plus a point estimate of the lift on the headline metric.

Both panels honour a date-range filter at the top of the tab.

The headline stats

At the top of the funnel, four stat tiles:

Stat	What it measures
Quiz views	Distinct sessions that bootstrapped the quiz. Counted once per session.
Completions	Sessions that reached the recommendation step.
Completion rate	Completions ÷ Quiz views.
Lead capture rate	Leads captured ÷ Completions (only shown when lead capture is enabled).

The dates the stats are scoped to are shown next to the filter.

The funnel

The funnel is one row per step in the flow — typically:

1. Quiz view. A shopper rendered the quiz bootstrap.
2. Question 1 view … through each question.
3. Recommendation view. The results panel rendered.
4. Lead captured. If enabled, the lead form was submitted.

Each row shows the count and the drop-off percentage to the next step. Wide drop-offs are a signal to look at — is one question too long, is the question text confusing, is the image-choice grid too dense?

Look at the steepest drop-off, not the average

A 60% completion rate with one 25% drop-off at question 4 is usually fixable. A 60% completion rate with even drop-offs across every question is the harder problem — the quiz is just a few questions too long.

A/B variant comparison

If the quiz has more than one active variant, the right-hand panel splits the funnel by variant. Each variant gets its own column. The last row of the comparison panel shows a lift estimate on the headline metric (completion rate, or lead-capture rate when relevant).

The lift today is a point estimate, not a full confidence interval — the default PointEstimateStatistics engine returns the point estimate with CI bounds null. The interface is wired for a v2 swap that returns proper intervals; until then, the comparison is “which variant won by how much” without a “by how much, with how much certainty” reading.

Sample-size verdicts are conservative in 0.1.0

The Statistics engine returns a SampleSizeVerdict enum with cases insufficient, marginal, sufficient — but with the point-estimate engine, the v1 thresholds are conservative and small samples will read insufficient. The honest reading: don’t declare winners on small samples; the wiring exists for a future Statistics engine that fills in real intervals.

Date-range filtering

The filter at the top of the tab supports:

• Last 7 days (default), 30 days, 90 days.
• Custom range — start and end date pickers.

The filter rewrites the funnel and the variant comparison consistently. The headline stat tiles also update.

How events flow into the dashboard

Storefront events (POST /storefront/sessions/{sid}/events) are batched on the client and buffered in dd_events_scratch. A scheduled job flushes new events every 30 seconds. A nightly rollup pre-aggregates them into dd_daily_stats so the dashboard reads are fast.

So the dashboard is near-real-time, not live — fresh events show up within a minute or so, and the daily aggregate is finalised after the nightly rollup.

What’s not yet shipped

Per the Beta gap list:

• Sankey / flow-map analytics. The current Metrics tab is funnel-style. A Sankey flow visualisation is in the roadmap; the underlying SankeyBuilder class exists but isn’t yet wired into the admin UI.
• Flow + Coverage analytics sub-tabs per quiz. Today the Metrics tab carries the Dashboard A1 KPIs and the A/B compare; the deeper per-flow drill-downs are planned.
• Analytics CSV export. No /analytics/export.csv endpoint today.

Honest caveats

• Storefront events are batched and best-effort. If a shopper closes the tab before the next batch flush, the last few events can be lost. This is by design — we don’t block the cart hot path on analytics writes.
• The dashboard doesn’t pretend to be a full session-replay or product-analytics tool. If you want event-level analysis, push the events to your own analytics pipeline via the dino_discover_lead_captured action plus a custom event listener.

What’s next

• Performance Monitoring — the timing budget on storefront and engines.
• Recommendation Rules — improve the conversion rate the dashboard measures.
• Question Builder — fix questions that drop off heavily.
• Engine Interfaces — the Statistics engine you can swap for proper intervals.