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.
Custom chart definitions
Section titled “Custom chart definitions”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.
Comparison windows
Section titled “Comparison windows”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 completedAnother 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.
Read-only dashboard sharing
Section titled “Read-only dashboard sharing”The dashboard creator can invite active members of the same app. Sharing is an explicit lifecycle, not an automatic workspace mutation:
- The recipient gets a pending invitation and can preview the dashboard read-only.
- 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.
- Dismissing rejects the pending invitation without affecting the creator or another recipient.
- An accepted recipient can later remove for me. This removes only that recipient’s shared copy from their workspace.
- The creator can revoke one recipient or delete for others, which revokes every shared copy while keeping the canonical dashboard.
- 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.
Dashboard API
Section titled “Dashboard API”GET /v1/sites/{siteId}/dashboardsPOST /v1/sites/{siteId}/dashboardsPOST /v1/sites/{siteId}/dashboards/previewGET /v1/sites/{siteId}/dashboard-invitesGET /v1/sites/{siteId}/dashboard-invites/{dashboardId}POST /v1/sites/{siteId}/dashboard-invites/{dashboardId}/acceptPOST /v1/sites/{siteId}/dashboard-invites/{dashboardId}/dismissGET /v1/sites/{siteId}/dashboards/{dashboardId}PUT /v1/sites/{siteId}/dashboards/{dashboardId}DELETE /v1/sites/{siteId}/dashboards/{dashboardId}GET /v1/sites/{siteId}/dashboards/{dashboardId}/sharesPOST /v1/sites/{siteId}/dashboards/{dashboardId}/sharesDELETE /v1/sites/{siteId}/dashboards/{dashboardId}/sharesDELETE /v1/sites/{siteId}/dashboards/{dashboardId}/shares/meDELETE /v1/sites/{siteId}/dashboards/{dashboardId}/shares/{userId}POST /v1/sites/{siteId}/dashboards/{dashboardId}/widgetsPUT /v1/sites/{siteId}/dashboards/{dashboardId}/widgets/{widgetId}DELETE /v1/sites/{siteId}/dashboards/{dashboardId}/widgets/{widgetId}POST /v1/sites/{siteId}/dashboards/{dashboardId}/widgets/previewOnly 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.