For parents & caregivers
Privacy & data use at Mimble Moon.
Mimble Moon is a playful shapes activity for children ages 3–5 and the grown-ups who share it with them. This page describes the data handling shown in the current website flows, in plain language and without assumptions beyond that code.
Back to Mimble MoonA clear starting point
The sections below cover the parent account, contact form, updates signup, and the conditional visitor beacon. They describe what those flows accept, store, and try to send. They do not add claims about practices the inspected code does not establish.
01 · Parent accounts
What signup asks for
The parent-account signup form asks for a name, an email address, and a password. Mimble Moon uses Better Auth for this flow, and its database schema persists account and authentication records, including user, account, session, and verification records. The inspected schema includes a password field on the account record; it does not establish a password storage method, so this page does not make one up.
The verified-email flow can send a verification message to the account email after signup. A parent can also request a password-reset message at that email. Those messages contain the links used by the corresponding account flows.
02 · Contact
When you send a question
The public contact form accepts your name, email address, and message. When the submission is valid, the site stores a contact record containing those fields and a created timestamp.
After saving the record, the site attempts to forward the submission to the company dashboard. If that dashboard recording returns nothing or fails, the site makes a best-effort notification to the configured company inbox. The contact route does not promise a response time or state a retention period.
03 · Updates
When you join the updates list
The current updates form asks only for an email address. Before saving it, the site normalizes that address to lowercase. It then stores a unique waitlist record with the email address and a created timestamp.
After saving the record, the site attempts the same company-dashboard forwarding path. If that recording returns nothing or fails, it makes a best-effort notification to the configured company inbox. The current updates form does not request purchase or payment details.
04 · Visitor beacon
A conditional page-load request
When a deployment provides an analytics slug, a page load runs the visitor-beacon code. It creates or reuses a local-storage identifier named polsia_vidand requests a beacon pixel at the configured analytics base. In the code, that base defaults to https://polsia.com when no other base is supplied.
This behavior is conditional: when the deployment does not provide an analytics slug, the visitor-beacon component is not mounted. This page does not infer any additional tracking, profiling, cookie, or analytics practices from that code.
A deliberately limited description
What this page leaves unstated
The inspected website code does not establish retention or deletion schedules, legal bases or compliance status, security guarantees, other vendor practices, sale or advertising practices, or broader claims about information relating to children. Those topics are not described here as facts.
Have a question about the current forms? Contact Mimble Moon