Goals, funnels, and experiments

Three weeks ago I said goals, funnels, and custom events were "in various states of polish." This week they've converged into something coherent, so here's how conversion tracking actually works in Tracely — and how it stays aggregate-first the whole way down.

Goals are just named events

A goal is a name plus an event name. If your site fires a trial_started event, you create a goal pointing at it and the Goals screen shows total conversions, unique converters (distinct visitors), a conversion rate against the period's visitor count, and revenue when the event carries revenue metadata. Each goal card also gets a delta against the equal-length window right before the selected period, and a small trend chart — daily counts rolled up into at most 42 buckets, so a 12-month range stays readable instead of becoming 365 slivers.

Two small things I like here. First, there's a template gallery, so common goals are one click. Second, the create form suggests event names from what your site actually sent in the last 30 days — the fastest way to kill the classic "zero conversions because of a case-sensitive typo" bug is to never type the name at all.

Funnels count sessions, step by step

A funnel is an ordered list of steps, and each step is either a pageview path or an event name. For each step, Tracely counts distinct sessions that matched it within the date range. The display shows step-to-step drop-off percentages, and each bar is labeled with cumulative conversion relative to step one. A summary line picks out the worst drop — the step where you lost the most sessions — and compares overall conversion against the previous equal-length window.

One honest caveat, which the UI reflects: steps are counted independently, so a later step can exceed an earlier one (people can enter mid-funnel). A big red bar is a visual cue, not a statistical test.

Experiments layer on top

If you send an Experiment exposure event with experiment and variant properties — or attach those properties to your own events — two things light up.

On the Funnels screen you can filter the whole funnel to sessions that saw a given experiment (and optionally a specific variant), or check Compare all variants to get a per-variant matrix, up to 16 variants side by side. These cohort settings can be saved as named presets, so a recurring readout is one click instead of re-typing keys.

The Experiments screen goes further: exposure tables per experiment and variant, CTA impression breakdowns, and a conversion-by-variant table for whichever event you treat as the conversion. It auto-picks the site's most frequent conversion-ish event so the page works with zero typing, and you can override it. For the largest experiments by exposed visitors, it builds scorecards that join exposed visitors against converting visitors per variant and runs the comparison math for you.

Aggregate-first, still

Everything above is computed with grouped queries over pageviews and events — counts, distinct visitors, distinct sessions. There's no per-person timeline being assembled to answer "did variant B convert better," and no session replay backing any of it. That constraint is the product: the questions that matter ("which step leaks," "which variant wins," "did the launch move signups") are all answerable from aggregates, and answering them that way means there's nothing creepy sitting in the database.

If you're curious what else is in the box, the features page has the full list. More funnels polish is coming — step editing shipped this week, and I want better handling for path patterns next.