Privacy Policy

Last updated: 2026-09-03  ·  Русская версия

The short version

1. Who processes your data

Contact us: @lunnaya_care on Telegram.

2. What we collect and where it lives

There are three different answers to "where is my data", and the difference matters.

We never see or store card numbers: payment happens on the payment provider's or the app store's side.

2.1. When we start writing to you less often

If over 90 days we have sent you five or more messages — in the bot, by push or by email — and in all that time there has been no action from you, we record the moment from which we lower the frequency of our own messages. This is not an unsubscribe and not a block: from that moment you receive at most one message a month, and only from a short list — a rare personal cycle event, the metaphoric card, your birthday, an invitation to come back. About money and access we never go quiet: payment confirmation, a card problem, the heads-up before a renewal charge, auto-renewal switched off, an unfinished checkout, the notice that your accounts were merged, and anything the founder writes to you personally arrive as they always did. Paid content is not touched either: while a subscription or trial is active, the morning recommendation and the other paid messages keep coming. Notices about the tracker itself are not quieted either — for instance that it was paused after 180 days without a mark: that is not a mailing but a change in what we hold about you, and we do not keep quiet about it.

What counts as an action: a click on a link in an email, anything you do in the bot, the app or the web version, and a payment. Opening an email does not count. Mail clients open emails on their own, without you, and for someone who reads with images switched off an "open" never happens at all — so opens play no part in this calculation, although our email service does report them to us alongside clicks.

This marker collects nothing new about you: it is derived from our own delivery logs — what we sent and when — and from the absence of a reply. It is cleared by your very first action, at the next check, and from then on we write as before. If we cannot be sure that email clicks reach us at all (for instance, their intake is broken), the quieting is applied to no one: we would rather err on the side of one message too many than of silence. The legal basis is our legitimate interest (GDPR Art. 6(1)(f)) in not writing into silence to someone who does not respond; it does not override your rights — one action restores the previous frequency, and your notification settings and email unsubscribe work as they did.

2.2. One question after you cancel a subscription

When you switch auto-renewal off, we ask — after the cancellation has already gone through — one question: what led to it. The answer is one tap on one of five options: "not tracking my cycle right now", "too expensive", "not much use for me", "something didn't work", "other". The "Skip" button is an equal choice: a skip is not recorded at all, and the cancellation has already happened and does not depend on your answer. The question is asked both in the Telegram bot and in the web app — the same one, with the same five options and the same skip button.

If you answered, we store: which option, which payment method the subscription ran on, where you answered and when. There is no free text in the question, so there is none to store. None of the options asks about your body: "not tracking my cycle right now" is about how you use the app, not about what is happening to you, and why the cycle is not being tracked is something we do not ask. One answer per cancellation: if you answer differently within two days, the new answer replaces the old one.

Why we ask: to see why people leave, and not to say too much on the way out — to someone not tracking her cycle right now we do not write "your daily tips will fall silent" or "the tips will keep coming". The legal basis is our legitimate interest (GDPR Art. 6(1)(f)); it does not override your rights: the question can be skipped, and the answer is erased outright together with the account (section 12). The answer does not go to advertising or analytics services.

3. Health and intimate life

Cycle data, symptoms and Apple Health measurements are health data. Intimacy markers are data about your sex life. Both are special categories under Russian law (Art. 10 of Federal Law 152-FZ), which permits processing them only with your consent.

If you are reading this in the EU or the UK, the law that governs your data is not that one. Both categories are special categories under the GDPR as well, and the requirements it places on consent to them are its own. We name the Russian statute here because it is the one whose text we have verified word for word; the GDPR text could not be retrieved while this revision was written, so nothing in this document should be read as a statement of what the GDPR requires.

We say this plainly instead of hiding intimacy markers inside "cycle data": they are separate, they are special-category, and they do reach the Lunar Oracle's context — as "intimacy — today / yesterday", for the last two days only. If you would rather they did not, do not place the marker.

The tracker pause — what we keep about it, and what we do not ask. When the tracker is paused, we record the moment of the pause and, if you paused it yourself from the delay check-in (the message about a delay that carries a "pause the tracker" button), that fact too: your choice must not be confused with the automation, which pauses the tracker on its own when no menstruation has been marked for 180 days. Why there is no cycle we neither ask nor store — not pregnancy, not menopause, not treatment, nothing: no screen and no message in the app needs it. The origin of the pause is part of your cycle data, derived from the delay you had already marked, and is covered by the same consent to processing of health data (section 1). It lives exactly as long as that pause: the moment you mark your cycle again the note is erased, and a pause set by the automation does not inherit it — otherwise six months later our own record would be saying something untrue about you.

How that consent is taken — door by door, with no generalising.

• The web app. The consent screen before your first conversation with the Oracle is live: what goes to the model, links to the documents it covers, one tick, and an "I accept" button. The consent is indivisible — the three legal bases are accepted together, in a single gesture; there are no separate switches for parts of it. Either you agree and use the Oracle, or the Oracle is not available to you. Without "I accept" there is no conversation, and there is no in-between state in which the screen is shown but lets you through.
• The iPhone app. The consent screen is not there yet: it arrives only with the next build through the App Store, and that timing is not entirely ours. Until then the Oracle in the app runs on the general consent you gave at registration and on this document.
• Registration. A separate consent checkbox at registration is shown only in the English Telegram bot; the Russian-language surfaces have no such step at all.

Withdrawal works differently, and this matters: it is server-side. Withdraw in the web app and the Oracle closes everywhere, including on the iPhone where the consent screen does not exist yet. A button that does not reach the next door is not a withdrawal; it is the appearance of one.

4. Apple Health — exactly what we read

Today, if you use an iPhone and connect Apple Health, the app asks for access to one data type — menstrual flow. Nothing else.

Once the next iPhone build ships, the list becomes this, and only this:

• menstrual flow,
• sleep,
• heart rate variability,
• resting heart rate,
• wrist temperature during sleep,
• cycle symptoms.

When that build ships, this six-type list will be identical in three places: the system permission prompt, our App Review notes, and here. It is the list of what the app reads from Apple Health.

On the consent screen before the Oracle the list is a different one, shorter by a single item. That is not an oversight — they are two different things. The "body signals" checkbox in that screen covers five signals: sleep, heart rate variability, resting heart rate, wrist temperature during sleep, and cycle symptoms. Menstrual flow is not among them.

Because the checkbox answers exactly one question: does this signal travel with my message to the Oracle. Those five are computed on the phone itself and travel with one specific question; we do not store them, and with the checkbox off nothing travels at all. Menstrual flow takes a different route: it syncs with the calendar and is stored on our server as a cycle event (retention is in section 8), because the tracker itself is built from it. Putting it inside that checkbox would promise control the checkbox does not have there: switching it off would not remove the flow from the server.

So it is governed by other levers, and they are real ones: read access — by the iPhone's own settings (Settings → Privacy & Security → Health → WooMoon), and cycle events already stored — by deleting your data (section 11 "Your rights" and section 12).

How it works

• Menstrual flow syncs with our server: it becomes a cycle event so that the app's calendar matches your system tracker. We write back to Apple Health only what you marked yourself, and we delete only the entries we authored — other apps' entries are untouched.
• Everything else — sleep, heart rate variability, resting heart rate, wrist temperature, symptoms — is not uploaded, not written and not read by us (a historical table from the earlier design still exists, see section 8). These measurements are computed on the phone and travel with one specific question to the Oracle, so it can say "you slept less than usual" instead of guessing.
• What reaches the conversation is not instrument readings but a comparison with your own recent baseline: "lower than usual for her", "slightly higher". Milliseconds, beats per minute and degrees are not sent to the model. The only number spoken aloud is sleep duration.
• A measurement older than three days is not used at all: a stale signal is worse than none.
• If you did not grant a particular type, Apple Health returns nothing for it — and the body section is simply not assembled. The Oracle works without it. One caveat that matters right now: Apple Health returns emptiness identically whether there is no data or the access was never requested, and the app cannot tell the two apart. Until the build described above ships, five of the six types are never requested — so nothing arrives for them.

What we never do with this data

We do not use it for advertising or marketing. We do not build ad-targeting profiles from it. We do not sell it and do not pass it to anyone for their own purposes. It never goes to web analytics or ad measurement. The only purpose is to help you understand your own state better.

You can revoke access at any time in iOS: Settings → Privacy & Security → Health → WooMoon. The app keeps working, just without that part.

5. What is sent to Google (Gemini)

The texts the app writes for you are generated by a Google language model — Gemini. It is an external processor, and here is exactly what it receives.

5.1. The daily recommendation and other generated texts

This covers the daily recommendation, lunar-day hints and calendar day descriptions. What is sent:

• your cycle day number and cycle length, the phase name and its description,
• the number of delay days, if you recorded a delay,
• the day's lunar data: lunar day, constellation, weekday and their descriptions.

No name, no city, no date of birth, no email. No body signals either: since 25 August 2026 Apple Health data is available to the Lunar Oracle only and does not reach the morning recommendation.

5.2. The Lunar Oracle

A conversation works differently: the Oracle has to know who it is speaking with. With every message you send, the model receives:

• the text of your message;
• recent turns of this same conversation — up to the newest fifty, from your device;
• a short memory digest (up to 600 characters), also stored on your device;
• your name and city, as you entered them;
• your age in years; the date of birth itself is not sent;
• where you are in your cycle: phase, day, cycle length, recent intervals, date of the last period;
• body signals from Apple Health, if you granted access (see section 4);
• intimacy markers for yesterday and today, if any;
• derived values from your natal chart: nakshatra, rashi, birth lunar day, yogas, current period;
• the full text of today's recommendation, the one you already received;
• library article titles, the weekly forecast, special days, your archetype description;
• the kind and date of messages we sent you over the past week — without their text.

One question of yours may cost two calls to the model: one for the reply, one to rebuild that memory digest.

What of this you can switch off, and what you cannot. Nothing separately: the consent is indivisible. Everything on the list above travels every time you use the Oracle — cycle data, Apple Health signals and intimacy markers included, and so are your name, city, age in years and the derived natal-chart values. There is no separate "do not send my name" toggle, and we will not pretend there is.

There are no per-part switches, and that is a decision rather than an omission. Either you agree and use the Oracle, or the Oracle is not available to you; the whole consent is withdrawn by one button, and withdrawing it closes the Oracle. The natal chart is the thing a woman comes to a Lunar Oracle for — switching it off would switch off the product — and a partial consent would mean answering with a context you were told we would not read. We do not hide any of this behind a checkbox that could never be unticked: we name what is sent here, and in the shield you see before your first conversation.

5.2.1. Chart calculations when you ask for them

If you ask the Oracle to look at your chart, the model can request a calculation from us and receive your full natal chart and dasha periods — that is, more than the derived values listed above — as well as current transits, or a reading cast for the moment you asked the question. Your birth details do not leave our server for this: the calculation runs on our own service on the same host, and only its short result reaches the model.

As this revision is published, the mechanism is off and runs in no environment. We describe it here ahead of time because the code ships in this same release, while switching it on is a separate decision: we do not want a new data flow to start working one day under an old text. When we do switch it on, this paragraph will say "on" and give the date.

What is never sent to the model: email address, phone number, Telegram id, payment data and subscription status, exact date and time of birth, birth coordinates, login codes.

5.3. What Google does with it

We have to be precise here, because "Google does not store it" would be untrue. Under the Gemini API terms (section "Paid Services → How Google Uses Your Data"):

Verbatim (the bracketed ellipses are our omissions; everything else is Google's text unchanged):

Current terms: ai.google.dev/gemini-api/terms.

5.4. Why we do not say "we anonymise it"

Because that claim proves nothing: it cannot be checked from outside, which makes it indistinguishable from a promise. Instead we list what is actually sent, above, and work to keep that list accurate.

6. Who else receives data

• Telegram — if you use the bot. Telegram receives your chat id and the full text of every bot message, including recommendations.
• Apple — push delivery (device token and the notification text, which may contain your name), App Store purchases, and Apple Search Ads install measurement.
• Brevo — our email service: the recipient address and the letter's contents. Letters can carry cycle-derived content, e.g. the daily recommendation with a cycle-phase image.
• Prodamus — card payments for the Russian audience. We do not pass it your name, phone or email; its payment notification returns the payer's email and phone to us, and those end up in our payment log.
• AppsFlyer, Google Analytics, Meta, Google Ads — advertising and funnel measurement. Cycle, body, intimacy data and the content of Oracle conversations are never sent there — this is enforced by a filter in the code, not only by policy. What does go, by recipient:
  • From our server — commerce events only (registration, trial, purchase) and an opaque identifier. No name, email, phone or internal account number is in that payload.
  • Meta additionally receives your IP address and browser user-agent string, in the clear, plus the fbc and fbp advertising cookies where you have them. "An opaque identifier" does not cover that, and we will not pretend it does.
  • Google Analytics receives more than our server sends it: the web app also runs Google's counter inside your browser — see sections 10 and 14.
  • From the marketing landing page (not from the app), page views go to Google and Meta straight from your browser — that page runs Google Tag Manager, Google Analytics and the Meta pixel. The details, and the difference between the Russian and English versions, are in section 14.
• Astrological calculations run on our own service on the same server — birth data does not leave the host for that step.
• Hosting and an outbound relay. All outbound traffic from our servers passes through an intermediate node, so calls to Google, Brevo and Apple travel through it.

We do not sell personal data.

7. Transfers outside your country

Sending a message to Google (Gemini) is a cross-border transfer. The list of countries is not fixed in advance: under Google's terms data may be cached in any country where it has facilities. Email (Brevo), push delivery (Apple) and ad measurement also route through foreign services.

8. How long we keep things

• Profile, cycle data, intimacy markers, natal chart, inbox messages — until you delete your account. There is no age-based deletion for them, and we will not print retention periods that do not exist in the code.
• Oracle conversations — until you erase them yourself. We do not hold them at all. Records that a message was sent (when, from which surface, never its text) live in the event log — see section 12.
• Apple Health measurements — neither written nor read. The table from the earlier design, where they used to be written, still exists on the server: we stopped writing to it on 25 August 2026 and will drop it once we have measured in production what remains in it. While it exists, account deletion clears it.
• Server file logs — 10 days, then overwritten. Container logs are capped by size, not by age.
• Your data export archive — 72 hours, then deleted.
• Deleted-account marker — an irreversible hash, kept indefinitely: it holds no personal data and exists so a free trial cannot be claimed twice.
• Financial records (that a payment happened, its dates and transaction ids) — retained after account deletion, detached from your name and contacts.
• Your answer to the question after cancelling a subscription — until you delete your account; there is no age-based deletion for it.
• The "writing less often" marker — until your first action, which clears it; in any case no longer than the account exists.

9. If a message looks like a crisis

If a message to the Oracle is recognised as being about self-harm, it is handled separately: you receive a pre-written reply with helpline contacts, without any call to the language model. Such a message does not consume your daily allowance and is never blocked by limits.

We count how many such messages arrive, so that an abnormal volume (for example an automated attack) can be noticed. The counter counts occurrences, not content. We are not doctors and not a crisis service, and the Oracle does not diagnose.

10. Analytics

We keep our own log of interface events to understand where the app is awkward. It has a filter that forbids storing anything about cycle, symptoms, pregnancy, fertility, ovulation, mood, diary entries, sex, date of birth, email or phone — by field name, enforced in code. The "period marked" event is recorded with no properties at all.

From our server, external web analytics (Google Analytics) receives even less: funnel steps and purchases only, against a strict allowlist in the code. Events about the cycle, recommendations, meditations and the Oracle are not forwarded there — an event that is not on the list never leaves at all.

But that is not the whole story, and it is fairer to say so. Alongside the server-side forwarding, the web app runs Google's counter directly in your browser. It loads as soon as the page opens and sends Google a page view together with the page's full address. Navigating inside the web app changes that address — ?page=oracle, ?page=archetype, ?page=subscription — so the addresses reveal which screens you opened, the Oracle screen included. And, as with any website, Google sees your IP address in the process. None of this contains conversation content, cycle data or body data — but it does contain the name of the screen you opened.

The advertising half of that counter is switched off in the code: ad storage, ad identifiers and ad personalisation are denied and Google Signals is off. The analytics half is on — for the cookie it sets, see section 14.

11. Your rights

• Get a copy of your data. The app has an export: we build an archive and email it to you. Your account needs an email address on file for this.
• Correct it. Profile and cycle data are editable in the app.
• Delete it. There is a delete-my-data button in the app — see section 12.
• Withdraw consent. In the web app — Settings → "Consents". There is one button, "Withdraw": the consent is indivisible, so it is withdrawn whole, and withdrawing it closes the Oracle. Accepting again is a single tap with no follow-up question — giving must never be cheaper than taking back. Withdrawal is server-side: made in the web app, it also closes the Oracle on the iPhone, which has no withdrawal screen of its own yet — that arrives with the next build. To withdraw wholesale, deleting your data works (see section 12). Withdrawal does not make prior processing unlawful.
• Object to processing and complain to a supervisory authority.

12. What account deletion does, and what it does not

Deleted: cycle data and cycle events, intimacy markers, cycle history, natal chart and birth details, inbox messages, notification tokens, registration state, texts generated for you, and your answers to the question after cancelling a subscription. Profile fields are cleared — the "writing less often" marker and the tracker-pause marks with them.

Retained but unlinked from you: here the row is not deleted — the account number in it is replaced with nothing and the direct identifiers are scrubbed out. That is what happens to subscription and payment records, to payment and webhook logs (email, phone and IP address scrubbed), to the record that consent was given — and to part of the analytics records: the row saying "on this day this event happened" stays, its IP address and session id are scrubbed, and the link to you is gone. Separately, the irreversible deleted-account hash is kept.

But not to all of the analytics, and the difference is in your favour. We keep two counters, and the second, more detailed one is erased outright on account deletion rather than unlinked. That is where everything about the Lunar Oracle lives: that a message was sent, whether it carried the "astrological question" mark, that you were shown the consent screen. A previous edition of this paragraph described analytics with the single word "unlinked" — that was exactly half right.

What deletion does not do today, stated plainly:

• Your address, once added to the contact list of our email service (Brevo), is not removed from there automatically. Write to us and we will remove it by hand. We are working on making it automatic.
• We do not send automated deletion requests to other recipients — delivery platforms, ad measurement services or the language model. What has already been sent cannot be recalled.
• Deletion does not rewrite database backups. What was erased remains in backups already taken, until those are overwritten or destroyed. Their retention period is not defined here — we say so in section 8 and again here, because staying silent about it in the section on deletion would be a deception.

13. Age

There is no single threshold right now: it differs by the door you came through. Stated as it is:

• Telegram bot, Russian version — registration succeeds from age 12 (and fails above 60). The "minor" flag that blocks subscription purchases is not set here: it is set only by registration through the app and the web app. So for a 13–15 year old who registered in the Russian bot, subscription purchase is not blocked.
• Telegram bot, English version — refused under 16.
• iPhone app and web app — registration is not possible under 13; at 13–15 the account is created with the "minor" flag, and subscription purchase is closed for it, and with it the Lunar Oracle, which is subscription-only.

14. Cookies and on-device storage

The web app sets two kinds of cookie, and the previous edition of this section named only the first.

• An essential session cookie (mt_webapp_session) for sign-in. The app does not work without it.
• An analytics cookie (_ga and its relatives), set by the Google Analytics counter that loads in your browser when the web app opens. It is set by default, without asking: there is no consent banner and no analytics opt-out in the interface today. Technically it is written on our own domain, but it belongs to a third-party counter, and we call it a third-party analytics cookie rather than an "essential" one. Advertising cookies the web app itself does not set: ad storage, ad identifiers and ad personalisation are denied in its code.

But the marketing landing page, where most people first meet us, is a different story, and we will not pass over it. That page — on the same domain — runs Google Tag Manager, Google Analytics and the Meta pixel, which brings the _fbp advertising cookie with it (lifetime up to 90 days, domain .woomoon.app). On the Russian-language version of that page all of it is enabled by default, with no banner and no question asked — analytics and advertising alike. On the English version everything is denied by default and turns on only after explicit consent. So the strict variant exists and works in our code; it is simply not applied to the Russian audience.

Why the two behave differently. Russian data-protection law does not require a cookie consent banner; the duty to ask before the counters load comes from the European rules, and those are the rules that apply to you if you are reading this version. So the strict regime stays on the English version, and the Russian one runs without a banner. The difference is a deliberate match to which law governs which audience, not an unfinished piece of work.

Oracle conversations in the web app live in browser storage. That has a downside we would rather say up front: Safari clears site storage after roughly a week without visits, "clear site data" erases the conversation irreversibly, and a private window keeps nothing. We hold no copy, so there is nowhere to restore it from.

15. The mobile app — what it adds

• An install identifier — a random value the app generates for itself to tell devices apart. It is not linked to any advertising identifier.
• A notification token — needed to deliver the reminders you opted into. Kept until you uninstall, turn notifications off, or delete your account.
• App Store purchase receipts — to activate and restore your subscription.
• Install attribution — Apple Search Ads and AppsFlyer. We do not collect the advertising identifier (IDFA) and show no tracking prompt, because there is nothing for us to track. Health and cycle data are never shared with attribution vendors.

We do not collect: background precise location, camera, microphone, contacts or photos. And we do not collect crash reports: a previous edition of this document mentioned Sentry — the app does not include it.

16. Security

Connections are encrypted (HTTPS). Server access is restricted. Logs mask name, city, coordinates and timezone, and are kept for 10 days. We do not treat logs as anonymised and do not rely on them being so.

No method of transmission or storage is 100% secure.

17. Government and law enforcement requests

For a cycle tracker this is not an idle question, so we answer it directly rather than by silence.

What we can say about today: there is no special procedure, no automated interface and no standing access for authorities — neither in the code nor in anyone's credentials. No mechanism for handing over data exists beyond our own administrators' ordinary access to the database.

What matters about the scope: we do not have your Oracle conversations — they cannot be handed over in response to a request, because they are physically not in the database or in the backups. But cycle data, intimacy markers, your profile, your email, payment history and the records of when you used the Oracle we do have. We will not promise that we will "never give anything to anyone": a controller cannot ignore a lawful demand from a competent authority, and promising otherwise would be empty. On exactly what grounds and by what procedure that could happen is a question we have not worked out yet — and we say so plainly rather than filling the gap with a pleasant sentence.

18. If data is breached

No method of protection is 100% secure — that is in section 16, and it is not a figure of speech. A breach of cycle and intimate-life data is exactly the case where silence is worse than the breach.

Honestly, about today: the procedure for a breach — whom we notify and within what deadline, how we determine which data was affected, who decides — is not written down. We will not print a deadline in hours that does not exist in any internal rule of ours, nor make a promise with no one assigned to keep it.

19. Changes

We update this document when what it describes changes; the date at the top changes with it. If a new kind of data appears, we will ask for consent again rather than silently widening the old one.