Privacy Policy

Last updated: 2026-10-09

The short version

1. Who processes your data

The controller is PT. TECHNO CAPITAL INDONESIA, Jalan Sunset Road No. 99D, Desa/Kelurahan Kuta, Kec. Kuta, Kab. Badung, Provinsi Bali, 80361, Indonesia; tax identification number (NPWP) 40.174.113.7-905.000.

For data protection matters, write to [email protected], on Telegram to @lunnaya_care, or by post to the address above.

This policy applies to accounts registered outside Russia: which controller serves an account is decided by the country of registration, not by the interface language. Accounts registered in Russia are served by a different controller under Russian law and its own documents.

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 data concerning health. Intimacy markers are data concerning your sex life. Both are special categories of personal data under the GDPR (Art. 9), and we process them only on your explicit consent (Art. 9(2)(a)).

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.

That consent is different for the two parts of the product.

• The calendar and the morning recommendation — the health data consent. It also covers sending cycle data for the morning recommendation to the AI recipients in section 5.
• The Lunar Oracle — a separate consent made of three documents: processing and transfer to the model, international transfer, and processing of special categories.

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

• The consent screen before the Oracle — in the web app, and in the iPhone app from version 1.0.28: what goes to the model, links to the three documents, 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.
• Older versions of the iPhone app. Version 1.0.27 has the earlier form of the consent screen, with separate switches; versions before 1.0.27 have no consent screen at all, and there the Oracle answers without it until you update the app.
• Registration. From 25 September 2026, at the last step of registration — in the Telegram bot, the web app and the iPhone app — you accept the documents with two separate ticks: the Terms of Service with this policy, and the health data consent. Which documents are shown is decided by the country of registration, not by the interface language; we record the time of consent. Nothing changes for accounts registered earlier, and we do not ask again: back then separate ticks existed only in the English-language versions, and for anyone who registered in Russian we will not invoke a tick that was never given.

Withdrawal is server-side: Settings → Consents (in the iPhone app and in the web app). Withdraw in one place and the Oracle closes everywhere, including older app versions without the consent screen. 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

If you use an iPhone and connect Apple Health, the app reads six data types, and only these:

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

This six-type list is 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.

The iPhone asks about it in two separate prompts, and they are two different things. Menstrual flow is requested when you connect Apple Health: 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. The other five signals — sleep, heart rate variability, resting heart rate, wrist temperature during sleep and cycle symptoms — are a separate system prompt, shown once, after you accept the Lunar Oracle consent. Declining it closes nothing — neither the Oracle nor anything you paid for. There is no "body signals" checkbox on the consent screen: the iPhone's own permission governs them.

The levers 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 not granted, and the app cannot tell the two apart.

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. It never goes to web analytics or ad measurement. The only purpose is to help you understand your own state better. One caveat, and an important one: the comparisons that travel with your question to the Oracle reach the AI recipients in section 5 — we pass them only to produce the reply, but kie.ai and DeepSeek work without a contract with us and may process what they receive for their own purposes as independent controllers, and we assume DeepSeek may use it to train its models (section 5.3).

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 the language models

The texts the app writes for you — the morning recommendation and the Lunar Oracle's replies alike — are generated by the language model of an external recipient. There are three recipients, named here:

Recipients as of edition 5 (2026-09-25): primary recipient — kie.ai → DeepSeek; reserve, used when the primary is unavailable — Google. Within this list and on these terms the model provider may change without a new consent; a new recipient or new processing terms require a new consent.

• NEXUSAI SERVICES LLC (kie.ai) — the kie.ai API aggregator: receives the request, processes it with the DeepSeek model and returns the reply. Address: 118 Krameria St, Denver, CO 80220, USA. Country of processing: the United States of America — kie.ai does not disclose where exactly the model runs; by its public statements, on servers in the USA. Training on data: the kie.ai privacy policy does not say whether the content of API requests is used to train models. Retention: not disclosed — the kie.ai privacy policy does not state how long request content is kept. Data processing agreement: not confirmed — we have no separate agreement with kie.ai. Capacity: if it uses the data beyond relaying it to the model, it processes it for its own purposes as an independent controller, not on the controller's behalf; there is no contract with kie.ai.
• Hangzhou DeepSeek Artificial Intelligence Co., Ltd. (DeepSeek) — developer of the DeepSeek model that writes the primary recipient's reply; a possible recipient: kie.ai does not disclose where exactly the model runs, and it cannot be ruled out that request content is passed to DeepSeek in the PRC, so the controller assumes the worst case. Address: Room 1201, Building West 1, Huijin International Mansion, No. 169 Huancheng North Road, Gongshu District, Hangzhou, Zhejiang, People's Republic of China. Country of processing: possibly the People's Republic of China — if request content is passed to DeepSeek. Training on data: DeepSeek's Open Platform terms do not describe the use of data received for training; the controller assumes that DeepSeek may use it to train its models, and this cannot be opted out of through the app. Retention: not disclosed — DeepSeek's Open Platform terms do not describe how long data is kept. Data processing agreement: not confirmed — we have no separate agreement with DeepSeek. Capacity: may process the data it receives for its own purposes as an independent controller, not only on the controller's behalf; there is no contract with DeepSeek.
• Google LLC (Google) — owner of the Gemini model that writes the reply (paid Gemini API tier). Address: 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA. Country of processing: the United States of America and any other country where Google operates capacity: Google processes and may temporarily cache data wherever its infrastructure runs. Training on data: under the paid Gemini API terms Google does not use prompts and replies to train models or improve its products, and does not have them reviewed by people for that purpose. Retention: prompts and replies are logged for a limited period — solely to detect policy violations and for legally required disclosures. Data processing agreement: confirmed by the controller on 19 September 2026 (Gemini API Paid Services terms). Capacity: processes the data on the controller's behalf under the paid Gemini API terms.

The history of this list is on the AI recipients page.

Below is exactly what they receive.

5.1. The daily recommendation and other generated texts

This covers the daily recommendation, lunar-day hints and calendar day descriptions. They are written by the model of the same recipients listed above. 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 date of birth, no email. No body signals or intimacy markers either: Apple Health data is available to the Lunar Oracle only and does not reach the morning recommendation. This transfer, including outside your country, rests on the health data consent (see section 7 of this policy).

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, as you entered it;
• 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 allowed the iPhone to share them (see section 4): sleep, heart rate variability, resting heart rate, wrist temperature during sleep and cycle symptoms — as a comparison against your own usual picture, not instrument readings;
• intimacy markers for yesterday and today, if any;
• the positions of your natal chart from the calculation stored on our side: the ascendant (lagna); the sign of each of the twelve houses and its lord; the sign and house of each of the nine planets with its dignity, retrograde status and combustion; aspects between planets; the Moon's nakshatra with its pada, lord, deity, symbol and its span in signs; the yogas in the chart with a description of how they formed, and the classical yogas that are not in the chart, with the reason; the yoga karaka; natural and functional (for your ascendant) benefic, malefic and neutral planets, and the planets that, per the classical text (BPHS), give a yoga for your ascendant, planets of mixed or conditional nature, and pairs of planets that do not form a yoga, with the explanation from the text; the current mahadasha and antardasha — without their start and end dates. Your date, time and place of birth and the degrees are not passed on, but together with your age these positions make it possible to work out your date and approximate time of birth fairly precisely;
• the full text of today's recommendation, the one you already received;
• library article titles, the weekly forecast, special days, your archetype: natal nakshatra, natal rashi and natal lunar day;
• a note on which birth details are filled in on your profile — date, time, place — without the values themselves;
• the kind and date of messages we sent you over the past week — without their text.

One question of yours may cost several calls to the model: for the reply (and, if the model asks for a chart calculation, one more carrying its result — see section 5.2.1) and 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 if you allowed them and intimacy markers included, and so are your name, age in years and the natal-chart positions. 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. Further calculations when you ask for them

If you yourself ask for a reading of your chart, the model can request a calculation from us — and receive more than the chart positions listed above, which are always sent. The mechanism is on in the web app and in the iPhone app. What the model can receive, item by item:

• natal chart details: the navamsha;
• dasha periods: the current mahadasha and antardasha with their start and end dates, and the next period or the sequence of mahadashas;
• current transits: the positions of the planets relative to your natal Moon, how they are assessed, and special transits;
• a reading for the moment of your question (prashna): the chart of the moment you asked, its conclusions and score; for it the model names the category of your question.

The model requests a calculation only when you yourself ask about your chart. Your birth details — date, time and place — and your current coordinates do not leave our server for this: the calculation runs on our own service on the same host, and only its result reaches the model. To be plain: the dasha period dates allow your date and time of birth to be reconstructed even more precisely than the chart positions do.

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 the recipients do with it

The recipients' terms differ, and we have to be precise, because "they do not store it" would be untrue.

Google. 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.

kie.ai (NEXUSAI SERVICES LLC) is the primary recipient: an API aggregator that processes the request with the DeepSeek model. kie.ai does not disclose where exactly the model runs; by its public statements, on servers in the USA. Its privacy policy does not say how long the content of API requests is kept or whether it is used for training. We have no data processing contract with kie.ai: if it uses the data beyond relaying it to the model, it does so for its own purposes as an independent controller.

DeepSeek (Hangzhou DeepSeek Artificial Intelligence Co., Ltd., PRC) is a possible recipient: it cannot be ruled out that kie.ai passes request content to DeepSeek in China, and we assume this worst case. DeepSeek's privacy policy does not apply to such data; DeepSeek's Open Platform terms apply, and they describe neither how long data is kept nor whether data received is used for training. We assume such use is possible, and it cannot be opted out of through the app. We have no contract with DeepSeek, and DeepSeek may process the data for its own purposes as an independent controller.

Google is the reserve, used when the primary recipient is unavailable. Within the list in section 5 the model provider may change without a new consent; a new recipient or new processing terms require a new consent.

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. Your name, email and phone are not sent there either, and your account number never goes in plain form. What does go, by recipient:
  • Google Analytics, from our server — funnel and purchase events from a fixed list in the code (for example: app opened, sign-up, paywall shown, checkout, trial, purchase, renewal, cancellation), with the plan, price and currency. They are tied to the _ga cookie id of your browser when there is one, and otherwise to a hash of your account number with a secret salt. That is a pseudonymous identifier, not an anonymous one. Google Analytics also receives what its counter in the web app sends from your browser — see sections 10 and 14.
  • Meta, from our server — only if you came to us from a Meta ad: the event (registration, trial, purchase, subscription, a tap on a button on our landing page, or a calculation on the panchang page), its value, currency and time, the page address without its query string, and two Meta identifiers — the ad click id (fbc) and Meta's browser cookie id (fbp), where you have it. Our server does not send Meta your IP address, browser data (user-agent), email, phone or account number. We no longer store the IP address and browser data of site visitors for advertising, and the earlier records kept for that purpose were deleted on 9 October 2026. Our server logs still record IP addresses and browser data, as any web server does (section 16). Meta's own pixel on our site is a separate matter: it sends Meta your IP address and browser data directly from your browser — see below and section 14.
  • Google Ads, from our server — only if you came to us from a Google ad: the ad click id (gclid, gbraid or wbraid), the event (registration, trial, purchase, subscription, a tap on a button on our landing page, or a calculation on the panchang page), its time, value and currency, and a hashed event number that stops it being counted twice. No IP address, browser data, name, email or phone.
  • AppsFlyer (the iPhone app) — install attribution and in-app events: paywall shown, checkout started, trial started, purchase (with the plan, price and currency). The AppsFlyer SDK in the app does not collect the advertising identifier (IDFA), but it does receive the device's vendor identifier (IDFV), your IP address, device model and system version, and its own install id; after sign-in the app also gives it a hash of your account number. That hash has no secret salt, so anyone who already knows the number can match it: it is a pseudonymous identifier, not an anonymous one. AppsFlyer passes these events on to Meta and Google, where we advertise, together with its own device id and its campaign attribution, so that they can measure our campaigns. Our server can additionally send AppsFlyer subscription events (trial, purchase, subscription start, renewal, cancellation, expiry, refund) with only AppsFlyer's install id and the same hash; at the time of writing that channel is switched off.
  • From our website (the landing page, the panchang page and the collaborations page; not from the app), page views and other page events (for example, watching the video guide) go to Google and Meta straight from your browser — these pages run Google Tag Manager, Google Analytics and the Meta pixel, and like any code running in your browser they receive your IP address, browser data and their own cookies. After a calculation on the panchang page, the pixel also sends Meta the city you chose. The App Store button on the landing page goes through an AppsFlyer link: when you tap it, AppsFlyer receives your IP address, browser data and the page's campaign tags (where you came from and the campaign name). 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 the AI recipients (Google, kie.ai), Brevo and Apple travel through it.

We do not sell personal data.

7. Transfers outside your country

Sending a message to a language model is a cross-border transfer: to the United States (kie.ai and Google — Google may also cache data in any country where it has facilities) and possibly to the People's Republic of China (DeepSeek). For Google LLC the transfer relies on the EU-US Data Privacy Framework, under which Google LLC is certified. For kie.ai and DeepSeek there is no adequacy decision and no standard contractual clauses or data processing agreement, so the transfer to them rests on your explicit consent (GDPR Art. 49(1)(a)), given with the risks explained: for the morning recommendation, the cycle data goes to the same recipients on the basis of the health data consent, which covers this transfer as well; for the Lunar Oracle, on the basis of the separate consent to international transfer, accepted by the same tick as the rest of the Oracle consent. 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.
• Questionnaire answers — until you delete your account; deleted with the account in full. Not passed to the AI recipients; read only by the WooMoon team, to improve the product.

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.

What this means for you in the web app. The web app has no switch that turns this counter off. By using the web app you understand that this analytics runs: we use it to develop the app and improve how it works, and to see where people come to it from. Its advertising signals are switched off. Google receives the _ga cookie id and, as with any website, your IP address (according to Google, Google Analytics 4 does not store IP addresses). We do not give it your account number or a user id, and when the web app opens, the counter is set up to leave out the part of the address after #, where Telegram passes your sign-in data.

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. The Lunar Oracle consent — Settings → Consents (in the iPhone app and in the web app). 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 one place, it closes the Oracle everywhere, including older iPhone versions without the consent screen. To stop the processing of your health data altogether — for the calendar and recommendations too — deleting your data works (see section 12). Withdrawal does not make prior processing unlawful.
• Object to processing — write to the address in section 1.
• Complain to a supervisory authority — in the EU/EEA, in the member state of your habitual residence, place of work or place of the alleged infringement (GDPR Art. 77); in the United Kingdom, to the Information Commissioner's Office.

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 AI recipients. 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

WooMoon is for people aged 16 and over. The threshold is the same at every door: the Telegram bot (Russian and English versions), the web app and the iPhone app do not let you register under 16, and the check is made on our server. If you are younger, please do not use WooMoon. If you are a parent or guardian and believe your child has registered, write to us at the address in section 1 and we will delete the account.

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. The panchang and collaborations pages on the same site work the same way. One exception applies to both versions: the App Store button goes through an AppsFlyer link for every visitor, with or without consent, and AppsFlyer sees the tap (section 6).

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. AppsFlyer still receives the device's vendor identifier (IDFV), your IP address, device model and system version, its own install id and a hash of your account number — section 6 lists what it receives and why. 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. Server logs record the IP address and browser data of requests; they 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.