Skip to content

Pro View charts and funnels

Pro View is the customizable layer above Overview. It stores chart and funnel definitions in SQLite while querying analytics facts from ClickHouse. A dashboard belongs to its creator, who can edit it or share a read-only view with other members of the same app. Editing a definition does not mutate the underlying events or give a recipient control of the creator’s dashboard.

A chart chooses a tracked event, tracking rule, or future event definition as its source. Supported visualizations are line, bar, donut, pie, scatter, and map. A map source must actually carry location data; the API refuses a decorative map of nowhere.

Widgets have ordered compact or wide display sizes. Free-form drag coordinates and arbitrary resizing are not part of the current contract, which keeps the responsive layout predictable.

The preview endpoint queries real event facts for line, bar, donut, pie, scatter, and country-map views. A future-event source is useful when preparing a dashboard before an event ships; its preview stays honestly empty until that event is captured. Live query failures and empty results are never replaced with invented browser data.

Pro View accepts three matched comparisons:

Comparison Buckets Meaning
Today versus yesterday Hourly Today from midnight versus the previous day
Last 7 versus previous 7 Daily Rolling seven days versus the seven before
Last 30 versus previous 30 Daily Rolling 30 days versus the 30 immediately before

There is deliberately no yearly comparison. Matching adjacent windows makes changes easier to interpret and avoids pretending that a young app has ancient wisdom.

Funnels are ordered journeys, not a signup template

Section titled “Funnels are ordered journeys, not a signup template”

An OwlEye funnel is any ordered sequence of two to ten page, event, or rule conditions. For example, a marketing team could model:

campaign landing page
→ product detail viewed
→ pricing CTA clicked
→ checkout started
→ purchase completed

Another team could model documentation adoption, an onboarding checklist, a content campaign, or a renewal flow. The funnel engine does not reserve special meaning for signup.

Campaign attribution is explicit rather than a side door for arbitrary query parameters. The SDK excludes query strings by default. Prefer captureCampaigns: true when an app needs attribution: it sends only bounded utm_source, utm_medium, and utm_campaign values while arbitrary parameters and the URL fragment stay excluded. Full captureQuery is a broader, separate opt-in. Without one of those choices, funnels can still use page paths and explicit events, but UTM summaries will not appear by magic.

Each step can use an exact or starts_with condition and optional property filters. Property groups support and or or; filters support equals, not_equals, contains, and exists.

Funnel controls include:

  • Closed entry: a cohort must start at the first step. This is the supported query mode today. The UI shows open entry as coming next because correct open funnels must let a person enter at their first qualifying step and then preserve sequence; unrelated per-step totals are not a valid substitute.
  • Ordered: unrelated events may occur between steps. Exact: the next matching event must be the immediately following event in the sequence.
  • Conversion window: same session, one hour, one day, seven days, or 30 days.

Same-session funnels use the pseudonymous session cohort. Longer funnels use the site-scoped visitor cohort. Preview results include step counts, step and overall conversion, drop-off counts and rates, plus average and median time to the next completed step when available.

Draft charts and funnels can be previewed before a dashboard exists. The draft endpoint is read-only: previewing never creates a dashboard as a side effect.

The dashboard creator can invite active members of the same app. Sharing is an explicit lifecycle, not an automatic workspace mutation:

  1. The recipient gets a pending invitation and can preview the dashboard read-only.
  2. Accepting adds the shared dashboard to the recipient’s Pro View picker. It remains read-only; only the creator can edit its name, widgets, or recipients.
  3. Dismissing rejects the pending invitation without affecting the creator or another recipient.
  4. An accepted recipient can later remove for me. This removes only that recipient’s shared copy from their workspace.
  5. The creator can revoke one recipient or delete for others, which revokes every shared copy while keeping the canonical dashboard.
  6. Delete for all removes the creator’s canonical dashboard, its widgets, and access for every recipient.

Pending, accepted, dismissed, and revoked share states are persisted in SQLite. Dashboard list and detail responses include server-derived capability flags, so clients can present only the actions the signed-in member is allowed to perform. The API remains the enforcement boundary.

GET /v1/sites/{siteId}/dashboards
POST /v1/sites/{siteId}/dashboards
POST /v1/sites/{siteId}/dashboards/preview
GET /v1/sites/{siteId}/dashboard-invites
GET /v1/sites/{siteId}/dashboard-invites/{dashboardId}
POST /v1/sites/{siteId}/dashboard-invites/{dashboardId}/accept
POST /v1/sites/{siteId}/dashboard-invites/{dashboardId}/dismiss
GET /v1/sites/{siteId}/dashboards/{dashboardId}
PUT /v1/sites/{siteId}/dashboards/{dashboardId}
DELETE /v1/sites/{siteId}/dashboards/{dashboardId}
GET /v1/sites/{siteId}/dashboards/{dashboardId}/shares
POST /v1/sites/{siteId}/dashboards/{dashboardId}/shares
DELETE /v1/sites/{siteId}/dashboards/{dashboardId}/shares
DELETE /v1/sites/{siteId}/dashboards/{dashboardId}/shares/me
DELETE /v1/sites/{siteId}/dashboards/{dashboardId}/shares/{userId}
POST /v1/sites/{siteId}/dashboards/{dashboardId}/widgets
PUT /v1/sites/{siteId}/dashboards/{dashboardId}/widgets/{widgetId}
DELETE /v1/sites/{siteId}/dashboards/{dashboardId}/widgets/{widgetId}
POST /v1/sites/{siteId}/dashboards/{dashboardId}/widgets/preview

Only the creator can use the share-management routes. Invitation preview, accept, dismiss, and shares/me act on the signed-in recipient’s own share state. All routes resolve the app in the path and verify current membership before reading or changing a dashboard.