Goals & funnels

Conversions your
backend can vouch for.

Four predefined goal types with visible denominators, custom events with a strict scrubbed schema, server-to-server conversions over an HMAC-token endpoint, and multi-step funnels computed live over the 24 h event window. Conversion truth that survives an audit — because the backend can sign it.

Predefined goals

Four goal types, zero vanity rates.

Goals get predefined ids — page-based, event-based, duration and scroll-depth — and every conversion rate ships with its denominator visible. No percentage without the count it came from.

Goal typeFires whenExample goal id
Page-baseda path (or path pattern) is viewedreach_checkout
Event-baseda custom event arrivesplan_selected
Durationengaged time crosses a thresholdengaged_3min
Scroll-deptha depth band is reachedscroll_75
Conversions · last 24 h · denominators visibleexact counts
GoalConversionsDenominatorRate
reach_checkout · page1,4863,412 sessions43.6%
plan_selected · event9213,412 sessions27.0%
scroll_75 · scroll-depth5,10312,887 views39.6%
engaged_3min · duration2,21412,887 views17.2%
The denominator is always on the table — sessions or views, exact counts, k-anonymity n ≥ 5 enforced like everywhere else.

Trusted conversions

Your backend signs the truth.

Browser events can be lost to ad blockers and dead zones. So Observer ships server-to-server events: your backend POSTs conversions to the collector's /s2s endpoint with a per-site HMAC token, and they land with the same integrity as browser ones. The same path serves the public API's POST events — build conversion recording into CI if you want.

HMAC-token auth

One token per site, issued in the dashboard. Requests without a valid signature are refused at the collector — no token, no conversion.

Backend-graded

Payment confirmed, subscription started, order shipped — events your server knows for certain, attributed to the same cookie-less identity model.

server-to-server conversion
# from your backend — HMAC token, per site
POST /s2s
{ "name": "subscription_started" }

Client side, custom events follow a strict schema: observer('event', 'signup_click', {plan:'pro'}) — at most 10 properties, scrubbed server-side, allowed only if the event name is on the site's allowlist.

Multi-step funnels

Find the step where they leave.

Build ordered funnels of 2–8 steps — page paths or custom event names — and Observer computes them live over the 24 h event window: sessions at each step, conversion-from-start and drop-off % at every stage, rendered as funnel bars whose width is the volume, red past a 50% drop.

Computed live

Sessions are counted at each step from the 24 h event horizon — conversion-from-start and drop-off at every step, not a stale nightly batch.

Paths or events

Mix page paths and event names freely: visit /pricing, fire plan_selected, reach /signup — a funnel is whatever order your conversion actually takes.

Who touches funnels

Every change, on the record.

Funnels live in the control plane under role-based access: analysts build, owners and admins delete — and every mutation is written to the append-only audit log, so "who changed what when" always has an answer.

ActionMinimum roleTrail
Create a funnelanalyst and upaudit-logged
View funnel resultsevery dashboard roleread-only
Delete a funnelowner or adminaudit-logged
Tier & policy changesowner onlyaudit-logged

Role checks run server-side on every request with per-query tenant scoping — the UI hides what your role may not do, and the API refuses it regardless of what the UI shows.

Count what matters,
with the denominator shown.

Goals, custom events and funnels ship in the default tier — no consent banner. Access is granted after an NDA; we deploy together with your DevOps team so the s2s path is wired into your backend, not bolted on.