Build & self-host · 4 min read

Analytics & privacy

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

DayOtter 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 self-hosters run analytics-free without doing anything.

Three providers are supported and fully independent - enable one, two, or all three: Mixpanel, Google Analytics 4, and PostHog.

Turn analytics on

Set the provider key(s) in your environment: NEXT_PUBLIC_MIXPANEL_TOKEN, NEXT_PUBLIC_GA_ID, and/or NEXT_PUBLIC_POSTHOG_KEY (with NEXT_PUBLIC_POSTHOG_HOST if you self-host PostHog or use the EU region).
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) all three provider keys and rebuild. With no keys set, the analytics code is inert - no SDK is loaded and no network calls are made. There's no separate 'disable' switch to remember; absence of keys is the off state.

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, the signed-in user id is associated so sessions stitch together; DayOtter never sends calendar contents, event titles, or attendee details to analytics.
Analytics can never break the app: every provider call is wrapped, so an outage or blocker just means the event is dropped.

Tip

Works the same on the hosted product and self-hosted. Self-hosters point the keys at their own Mixpanel/GA/PostHog projects and own 100% of the data.

Related guides

Self-hosting DayOtter

Run the whole platform on your own infrastructure, with every feature unlocked.

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

Set the provider key(s) in your environment: NEXT_PUBLIC_MIXPANEL_TOKEN, NEXT_PUBLIC_GA_ID, and/or NEXT_PUBLIC_POSTHOG_KEY (with NEXT_PUBLIC_POSTHOG_HOST if you self-host PostHog or use the EU region).

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, the signed-in user id is associated so sessions stitch together; DayOtter never sends calendar contents, event titles, or attendee details to analytics.

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