Build & deploy · 4 min read

Analytics & privacy

Turn product analytics on (OpenPanel, Mixpanel, PostHog) or off, and let people opt out.

BraveDay ships with an optional analytics layer so you can understand how people use your instance. It is OFF by default and provider-agnostic: nothing loads and nothing is captured until you wire up at least one provider. Local dev and privacy-first deployments run analytics-free without doing anything.

OpenPanel is the native platform provider and can run entirely on your own infrastructure. Mixpanel and PostHog remain optional. Host-owned GA4/GTM pixels on public booking pages are separate and remain available.

Turn analytics on

For OpenPanel, create a client and set NEXT_PUBLIC_OPENPANEL_CLIENT_ID to its public id. If you run OpenPanel yourself, also point NEXT_PUBLIC_OPENPANEL_API_URL and NEXT_PUBLIC_OPENPANEL_SDK_URL at your analytics domain. Never expose the OpenPanel client secret as NEXT_PUBLIC_*.
Mixpanel and PostHog remain available through NEXT_PUBLIC_MIXPANEL_TOKEN and NEXT_PUBLIC_POSTHOG_KEY.
Rebuild and redeploy the web app - these are NEXT_PUBLIC (browser) variables, so they're baked in at build time, not read at runtime.
That's it. The chosen SDKs load, page views are reported on route changes, and product events flow to every configured provider.

Note

Because the keys are NEXT_PUBLIC, changing them requires a fresh build - a running server won't pick them up. Set them before you build your image or run `next build`.

Turn analytics off

Remove (or leave blank) every provider key and rebuild. With no keys set, the analytics code is inert - no SDK is loaded and no network calls are made.

Let people opt out

Even when a provider is configured, every visitor can turn analytics off for themselves under Settings → Preferences → Analytics & privacy. The choice is stored per-browser and takes effect immediately - existing capture stops and no new events are sent from that browser. Signing out also clears the analytics identity.

What's captured

Page views on navigation, and meaningful product events (flow completions, key actions) - not keystrokes or form contents.
On sign-in, OpenPanel receives only the stable internal user id - no email, name, calendar contents, event titles, or attendee details. Public booking events are anonymous.
Analytics can never break the app: every provider call is wrapped, so an outage or blocker just means the event is dropped.

Tip

The Ravefox deployment points OpenPanel at its own analytics server, so product-event data stays in the same infrastructure.

Related guides

Running your own deployment

How a BraveDay instance is deployed on your own cloud server, and what it runs.

Developer: API, webhooks & embed

Keys and REST endpoints, signed booking events, and the embeddable widget.

Ready to try it? Get started free, or browse all guides.

Turn analytics on

For OpenPanel, create a client and set NEXT_PUBLIC_OPENPANEL_CLIENT_ID to its public id. If you run OpenPanel yourself, also point NEXT_PUBLIC_OPENPANEL_API_URL and NEXT_PUBLIC_OPENPANEL_SDK_URL at your analytics domain. Never expose the OpenPanel client secret as NEXT_PUBLIC_*.

Mixpanel and PostHog remain available through NEXT_PUBLIC_MIXPANEL_TOKEN and NEXT_PUBLIC_POSTHOG_KEY.

Rebuild and redeploy the web app - these are NEXT_PUBLIC (browser) variables, so they're baked in at build time, not read at runtime.

That's it. The chosen SDKs load, page views are reported on route changes, and product events flow to every configured provider.

Let people opt out

What's captured

Page views on navigation, and meaningful product events (flow completions, key actions) - not keystrokes or form contents.

On sign-in, OpenPanel receives only the stable internal user id - no email, name, calendar contents, event titles, or attendee details. Public booking events are anonymous.

Analytics can never break the app: every provider call is wrapped, so an outage or blocker just means the event is dropped.