Privacy Policy

MyDietingApp ("we", "us", "our") provides a diet, fasting, and health-tracking application available at mydietingapp.com and through our Android app. This Privacy Policy explains what information we collect, how we use it, and the choices you have.

1. Information we collect

Account information. When you sign in, we receive a user ID, email address, and display name from the authentication provider (Replit Auth) so we can save your data to your account.

Health and diet data you enter. This includes food logs, weight, body measurements, progress photos, exercise, hydration, fasting sessions, sleep, mood, and goals. You provide this directly; we do not access health data from any other source.

Subscription data. If you subscribe, our payment processor (Stripe) collects payment information. We never see or store your full card number — only the subscription status, customer ID, and a limited card summary returned by Stripe.

Device & usage data. Operational request metadata may be handled transiently for security and reliability. Raw IP addresses and User-Agent values are not persisted in our product analytics or traffic-quality ledger. Push-notification subscriptions are stored if you opt in to notifications.

Product analytics. MyDietingApp records a small, first-party event ledger for the app owner’s product metrics: app_opened when the tracker is visible, trial_setup_opened when the free-trial setup form is shown, start_free_viewed when Start Free is opened, start_first_fast_clicked and log_first_meal_clicked when its actions are selected, fast_started after a fast is successfully started, meal_saved after a meal is successfully saved, login_started when sign-in is initiated, login_completed only after the authentication callback succeeds, login_failed after a failed callback, and account_created when the server auth upsert creates a new account, and trial_started when that new account receives its no-card trial. Sign-in events also carry a temporary random attempt key so starts, outcomes, and retries can be counted once. Events contain event name, server timestamp, and the existing pseudonymous browser ID from local storage; successful signed-in events also use the account ID from the server session. For a conservative browser-traffic quality breakdown, the server parses each analytics request's User-Agent transiently into only the allowlisted signals recognized_crawler and recognized_headless; the client may also send only the boolean navigator.webdriver indicator. We store those signal names, not raw User-Agent or IP addresses, browser fingerprints, typed contents, or health data. A successful fast start or meal save is the only likely-human signal; known automation evidence takes priority, and all other tracked browsers remain unknown. This is a browser-tracked estimate, not a count of people, and it cannot detect crawlers that never run the app's JavaScript. We do not send meal names, nutrition, health data, or free-form payloads to this ledger. We also record one best-effort site visit on each browser page load, including public landing and blog pages. A daily aggregate stores the pseudonymous browser ID, UTC day, visit count, and first-touch attribution. Referrers are reduced in the browser to hostname only (never a path, query, or full URL) and categorized as Google, Bing, social, other, or direct/unavailable. “Direct / unavailable” means no external referrer was available and does not prove that the address was typed directly. Only a short allowlist of campaign source and medium labels is accepted; we do not store campaign names, search terms, utm_term, or keywords. Internal navigation does not replace first-touch attribution. Site visit totals may include automated traffic, while the quality breakdown separately reports likely automated, likely human, and unknown browser IDs. These are browser estimates, not unique people, and site-level history begins when this tracking is enabled without backfilling older rows. Separately, a first-party blog article ledger records accepted article renders (including client navigation and same-day repeats), with only a published article slug, random retry-deduplication ID, pseudonymous browser ID, server time, and a source category based on the site’s first observed attribution where available. Signed-in records may also contain the server account ID. It stores no article URL, raw referrer, IP, User-Agent, fingerprint, or typed content. Admin reports show views and distinct browser IDs over the last 7 or 30 UTC calendar days, including today. A tried-app reader is a browser with a successful fast start or meal save after an article view in the same window; this is assisted overlap, not proof the article caused that action or last-touch attribution. Counts may include automated traffic; there is no historical backfill.

App screens and active time. For guests and signed-in browsers, we also record allowlisted app screen names, random session and retry identifiers, and short timestamped intervals of active use. Signed-in identity comes from the server session. Active time pauses when the page is hidden or after 60 seconds without interaction; a new session begins after 30 minutes without activity. Concurrent tabs are coordinated and overlapping intervals are not counted twice. These measurements are best-effort browser estimates, not proof that a person is present. We do not record keystrokes, pointer positions, screen recordings, food entries, or other health content. Activity listeners determine only whether the idle timer should reset. Duration and guest screen history begin when this collection is enabled; older duration is not reconstructed. Previous signed-in feature counts remain lifetime aggregates where dated events were not collected.

Optional Replit-hosted website analytics. If analytics is enabled in the site’s Replit Publishing settings, Replit’s injected tracker automatically records website pageviews. On the website, we also send only the custom event names app_opened, fast_started, meal_saved, and sign_in_started when eligible actions occur; these custom calls include no event properties, typed contents, account IDs, or health data. This is separate from our first-party event ledger and does not apply to the Android app. Our admin exclusion for custom events does not control Replit’s automatic pageviews.

2. How we use your data

• Provide the core tracking, analytics, and coaching features.
• Sync your data across your devices.
• Generate personalized recommendations and AI coaching responses (the AI processes only the data needed for that response).
• Process subscription payments and prevent fraud.
• Send push notifications you've opted in to.
• Improve reliability and fix bugs.

3. What we do NOT do

• We do not sell your personal or health data.
• We do not share your health data with advertisers.
• We do not use your health data to train third-party AI models.

4. Service providers we use

We share the minimum data needed with the following providers, who are contractually required to protect it:

• Replit — hosting, authentication, database, and optional published-website analytics.
• Stripe — subscription billing.
• OpenAI — powers AI coaching and Smart Food Entry. Requests are not used to train OpenAI's models per their API terms.

5. Your choices

• Access & export. You can view all your data inside the app at any time.
• Delete your account. Email support@mydietingapp.com and we will permanently delete your account and associated health data within 30 days.
• Cancel subscription. Cancel anytime from the subscription page or from your Stripe receipt.
• Notifications. Disable push notifications from your browser or device settings at any time.
• First-party product analytics. Clearing the app’s local browser ID stops future first-party events from being associated with that ID; it does not erase events already stored or disable Replit-hosted website analytics. Contact us to request access to or deletion of analytics records.

6. Data retention

Product analytics records may be retained while needed for cumulative product metrics; we do not promise a fixed automatic deletion period. If you delete your account, we delete your health data within 30 days, except where we are required to retain limited billing records by law. Contact us with privacy requests.

7. Children

MyDietingApp is not directed to children under 13 (or under 16 in the EU/UK). We do not knowingly collect information from children. If you believe a child has provided us data, contact us and we will delete it.

8. Security

We use TLS encryption in transit and standard server security practices. No system is perfectly secure, but we take reasonable steps to protect your data.

9. International users

Our servers may be located in the United States. By using the service, you consent to the transfer of your data to the United States and other countries where our service providers operate.

10. Changes to this policy

We may update this Privacy Policy from time to time. We will update the "Last updated" date above. Material changes will be announced inside the app.

11. Contact us

Questions about privacy? Email support@mydietingapp.com.