Cookie and Tracking Technologies Policy

Web cookies are small text files that a website can store in your browser. Websites and mobile apps can also use local storage, software development kits (SDKs), device or account identifiers, pixels and event records. Some of these are necessary to provide a feature you have requested; others, such as product analytics, are optional. Leo does not use any of these technologies for third-party advertising or to track you across other companies’ apps or websites.

As of the date above, the Leo website does not intentionally set analytics, advertising, personalisation or other optional cookies. We do not use pixels or browser local or session storage to track visitors. Because no non-essential browser tracking technology is currently deployed, the website does not display a cookie-consent banner. If this changes, we will update this policy and add the required consent mechanism before any optional cookie is set.

Vercel serves our static website and processes technical request metadata needed to deliver and protect it, such as IP address, browser or device information, the page requested and the request time. These server-side logs are not cookies placed on your device. If you join our early-access waitlist, Supabase receives the details you choose to submit through the form. The form does not create or persist a browser login session and does not require a cookie. See our Privacy Policy for more information about these providers and how they handle data.

The mobile app stores the Supabase authentication session on the device so you can remain signed in, and uses local storage and SQLite for preferences, cached views and offline queues. To avoid losing work, some account-scoped unsent food, workout and goal queues remain after sign-out so they can sync if the same account signs in again; account deletion attempts to clear Leo’s local queues and caches. If you enable notifications, Leo stores an installation identifier and the Expo push token needed to deliver and revoke them. On iOS builds where store subscriptions are enabled, RevenueCat uses the Leo account UUID and purchase or entitlement status to provide subscription access; Leo disables RevenueCat’s automatic advertising or attribution identifier collection and SDK diagnostics. These technologies support requested app functions and are not used by Leo for advertising.

Current beta builds with analytics configured use PostHog through its EU ingestion endpoint to understand onboarding, feature use and retention and to improve Leo. Product analytics is not necessary for the app’s core functions. The SDK stores anonymous, distinct or account and stable device identifiers, together with an unsent-event queue, on the device. After authentication, Leo links the analytics profile to the Supabase account UUID. PostHog automatically records app installation or update, app open and foreground or background state. It is also configured to attempt automatic screen or route-name capture; because Expo Router screen tracking is not manually wired, those records may be incomplete. Leo also sends defined feature events, such as onboarding steps, use of food, recipe, weight, workout and fasting features, paywall actions and support actions. Events include standard technical details such as app name, version, build and bundle, device type, locale or time zone, screen dimensions and SDK version. Limited feature details may include a logging source, meal category, fasting duration or workout category. Leo does not intentionally send chat text, photos, meal descriptions, custom workout text or exact weight values to PostHog. Session replay, touch recording and automatic crash or error capture are not enabled.

Leo uses mobile product analytics to measure whether the beta works, understand feature adoption and improve reliability and design—not for advertising, sale of personal data or cross-service profiling. Analytics is sent to PostHog’s EU endpoint. No fixed beta retention period is documented in Leo’s app or website code; the effective PostHog project setting and provider schedules still need to be verified. We will publish the approved production retention period before public launch. Exact provider security-log and backup schedules are separate from this policy and must be confirmed in the relevant provider account or contract.

You can use browser settings to view, block or delete browser cookies; the website has no Leo-specific optional-cookie preference because it deploys no optional cookies. Current mobile beta builds start product analytics automatically at app startup, including before the onboarding consent screen, and do not yet provide an in-app analytics switch. Signing out removes the account identifier from future analytics events but preserves the analytics device identifier and may preserve queued analytics events; it does not erase events already received by PostHog. Current account deletion also does not automatically erase that PostHog history. Before public release, Leo will implement the prior consent and subsequent withdrawal or opt-out controls required for non-essential analytics and update this policy. Beta testers can contact support@meetleo.app to request access to or deletion of analytics data; current builds cannot maintain an ongoing analytics opt-out while the app remains in use.

We may update this policy when the services, providers or applicable requirements change. We will post the revised date at the top of this page.