Privacy Policy

Last updated: September 23, 2026

Moonira Agency (“Moonira”, “we”, “us”) operates the website moonira.com. This policy explains what personal data we collect, why we collect it, how we use it, and what rights you have.

1. What we collect

a) Product analytics (PostHog)

We use PostHog to understand overall site traffic and how pages perform. It records page views and the engagement events listed in (d) below, tied to the visitor identifier described in (f). We use it in aggregate, to see which pages work and which do not.

PostHog also records replays of site sessions: the pages you view, your mouse movement, clicks and scrolling, and the text you type into our forms, including where you start filling a form and do not submit it. We use replays for two things: finding where pages and forms break, and reading back an enquiry that was started but never sent so we can respond to it. Password fields are never recorded, and we do not ask for payment details anywhere on this site. You can stop replay recording with a tracking blocker, and the site works normally without it.

b) Form submissions

When you fill out a qualification form, we collect the information you provide: name, email address, company website, team size, annual revenue band, when you are looking to start, and any message you write. We use this data to respond to your inquiry, assess fit, and provide our services. If you filled the form on one of the advertising landing pages named in 1(g), your name and your email address are also sent to Meta in hashed form, as described there.

While you are filling the qualification form in, your browser keeps a copy of what you have typed so far, so that you can come back and finish it. It is stored under the name moonira_contact_form, and it holds your name, email address, company website, the message you write, and an internal reference for the submission. It expires 7 days after it was last saved, and we clear it as soon as you complete the form. The short contact form in the sidebar of our insight and tool pages keeps its own copy, under the name moonira_sidebar_form, holding your name, email address and message. That one has no expiry date: it stays until you clear this site's data in your browser. Both copies sit in your own browser rather than being a separate record we hold, though the same details reach us once you submit.

c) Cal.com booking data

When you book a discovery call through our Cal.com integration, we receive your name, email, and scheduling details via a webhook. This data is stored alongside your form submission to connect your inquiry to the booked meeting. If you booked from one of the advertising landing pages named in 1(g), our server also sends Meta a Schedule event when Cal.com confirms the booking. It carries your name and email address in hashed form, the user agent string your browser sent when you filled in the form, and the two Meta cookies from the page where you booked or, failing that, from the form, as described in 1(g). It does not carry your IP address.

d) Engagement tracking

We collect engagement signals to understand how visitors interact with our site. This includes:

• Scroll depth (how far you scroll on a page)
• Time spent on page
• Which sections of a page you view
• CTA button clicks
• Form submission events

Your browser sends this data under a random session identifier stored in sessionStorage (not a cookie), generated fresh each visit. On our side the session is stored against the visitor ID described in (f), so these signals are not anonymous: if you submit a form, in this visit or a later one, we can connect them to the details you gave us.

e) UTM parameters

If you arrive via a marketing link, we capture campaign parameters (source, medium, campaign, term, content) to understand which outreach efforts are effective. These are stored in your browser: in sessionStorage for the visit itself, and in localStorage as well, so that if you come back later without clicking an advertisement we can still tell which campaign first brought you here. They are sent with your form submission. Personal information (email, name) is stripped from the URL immediately after capture.

f) Visitor and session identifiers

We generate random visitor and session IDs to connect page views and engagement events. The session ID lives in your browser's sessionStorage and is discarded when you close the tab. The visitor ID is stored in a cookie named _moonira_vid, set by our server and readable only by our server, and it lasts 400 days. It lets us tell a returning visitor from a new one. It contains no name, email address or other personal detail, and on its own it does not identify you. If you later submit a form, we connect that identifier to the details you gave us. On the advertising landing pages named in 1(g), we also send this identifier to Meta, unhashed, with the events described there.

On /get-started/brief1, /get-started/brief2 and any later page of that series, we read your approximate city from your IP address and print it on the page. For that, the city is stored in a cookie named mnr_loc on your device: a session cookie, which your browser normally deletes when it closes. The cookie itself is not recorded, stored on our servers or sent to anyone else; the Meta events described in 1(g) separately carry a hashed city derived from your IP address.

g) Advertising measurement (Meta Pixel and Conversions API)

Four of our paid-advertising landing pages, /get-started/recruiting, /get-started/apply, /get-started/brief1 and /get-started/brief2, run the Meta Pixel, a tool provided by Meta Platforms. It tells us which advertisements produced enquiries, so we can stop paying for the ones that do not work. It does not run on the rest of the site.

When it runs, Meta receives:

• The address of the page you are viewing, including any campaign parameters in it, and the page you arrived from
• Your IP address, browser type, device type and screen size
• Two identifiers stored in your browser as cookies: _fbp, set on this domain by Meta's script and valid for 90 days, and _fbc, which records which advertisement you clicked. Meta's script normally sets _fbc. If you arrive on one of the pages named above from a Meta advertisement with a click identifier in the address and Meta's script has not set the cookie, usually because a blocker stopped it, our own server sets _fbcinstead, in Meta's format, on this domain, valid for 90 days. A blocker that stops Meta's script does not stop this cookie.
• A PageViewevery time you open one of those pages, which Meta's script sends by itself as soon as it loads, and then five kinds of conversion event, and no others: InitiateCheckout when you enter your name and email address and continue to the next step, Lead if you complete the application and meet our qualification criteria, and Schedule if you book a call. We also send LeadDisqualified later, if a member of our team reviews your application in our internal system and records that you are not a fit, whether or not you qualified when you filled the form in, so that we stop showing you advertisements. We send Purchase if you go on to become a client, at the point a member of our team records the agreement as won in that same internal system. Each carries a short label naming which form it came from, or that the event came from our internal system. The Purchase event also carries the value of the agreement and its currency, which is what lets us tell which advertising produced revenue rather than only enquiries. Our own code attaches nothing else to any of them: no company details, no team size, not the revenue figures you give us on the form, and not the reason an application did not qualify.

Meta's script also reads our forms on its own. A Meta setting called Automatic Advanced Matching is switched on for this pixel. It is Meta's code doing this, not ours: the pixel script looks at the fields you fill in on those pages, hashes what it recognises with SHA-256 inside your browser, and attaches the result to every pixel event it sends. Meta currently reports it picking up your email address and your last name this way. We do not choose which fields it reads, and switching it off is a change in Meta's dashboard rather than in this website's code.

We also send our own copy of these events to Meta from our servers, so that a conversion is still counted when your browser blocks the pixel. On the pages named above, InitiateCheckout and Lead are sent from our server when you complete a step of the form, and Schedule is sent from our server when Cal.com confirms your booking. LeadDisqualified and Purchase are sent from our server only: neither has a browser copy at all, because nothing about a member of our team reviewing your application, or about your becoming a client, happens in your browser. A blocker in your browser does not stop these server-side events.

All of them carry your first name, your last name and your email address, hashed separately with SHA-256; the visitor identifier from 1(f), unhashed; the user agent string your browser sends; the two Meta cookies listed above; and the address of the page. We split the single name you type into a first and a last part in order to send it. If you enter one word, only a first name is sent. The two events we send while you are filling the form in also carry your IP address, and your country and city, and for visitors in the United States your state, each hashed with SHA-256. We do not collect these separately: our hosting provider derives them from the IP address we already send. The Schedule event carries no IP address and no location. Its user agent string is the one we recorded when you filled in the form, and its Meta cookies are the ones your browser held on the page where you booked or, if those are missing, the ones we recorded when you filled in the form. A LeadDisqualified or a Purchase sent later from our internal system carries no IP address and no location either, and its user agent string and Meta cookies are likewise the ones we recorded when you filled in the form. We do not send your phone number, your company details, your team size or the revenue figures you give us on the form on any of them, and we do not send the reason an application did not qualify. The only monetary figure we ever send is the value of a signed agreement, on the Purchase event described above.

Hashing is not anonymisation. Meta's purpose in receiving the hashes is to match them against the account of the person the name and address belong to, which is what makes them personal data under the GDPR. So your name and your email address are sent to Meta, in a form only Meta can match rather than read.

Meta acts as an independent controller for its own use of this data. We and Meta are joint controllers for the collection and transmission step. Meta describes its handling in its Business Tools Terms and Data Policy. We do not currently ask for consent before the pixel runs. Browser tracking protection and content blockers stop Meta's script and the events it sends from your browser, and using one does not affect your ability to use the site or submit a form. They do not stop the events our server sends, and they do not stop the _fbccookie our server sets when Meta's script could not.

2. Legal basis for processing (GDPR Art. 6)

• Consent (Art. 6(1)(a)): When you voluntarily submit a form or book a call, you consent to us processing that data to respond to your inquiry.
• Legitimate interest (Art. 6(1)(f)): Analytics and engagement tracking serve our legitimate interest in understanding site performance and improving user experience. This processing uses the identifiers described in 1(f). Session replay is covered by this basis only for diagnosing broken pages and forms; it can capture what you type into a form before you submit it, as described in 1(a). The advertising measurement described in 1(g) is separate and is not covered by this basis.
• Contract (Art. 6(1)(b)): If you engage us for services, we process data necessary to fulfill our contractual obligations.

3. What we do not do

• We do not sell your data to third parties.
• We do not share your information with data brokers.
• We do not run advertising technology on our content pages. The one exception is the paid-advertising landing pages named in 1(g), which run the Meta Pixel. Section 1(g) sets out exactly what that collects. Analytics and session replay, described in 1(a), do run across the site.
• We do send your name and your email address to Meta, hashed, with the events described in 1(g), along with a coarse location derived from your IP address, also hashed. We do not send your phone number, your company details, your team size or the revenue figures you give us on the form to any advertising platform. If you go on to become a client, we send Meta the value of the agreement, on the Purchase event described in 1(g).

4. Sub-processors and data sharing

We use the following services to operate moonira.com and to handle the enquiries it produces. All of them except Meta Platforms process data on our behalf and under our instruction. Meta is not our processor: as set out in 1(g), it acts as an independent controller for its own use of the advertising data it receives, and we are joint controllers with it for the collection and transmission step.

5. International data transfers

Some of our sub-processors are located in the United States. Where personal data is transferred outside the European Economic Area (EEA), we ensure appropriate safeguards are in place, including Standard Contractual Clauses (SCCs) adopted by the European Commission, or the service provider's participation in recognized data protection frameworks.

6. How we store and retain your data

Form submissions and associated attribution data are stored in Supabase (PostgreSQL), hosted in the United States. Data is retained for the duration of our business relationship and for up to 24 months afterward for follow-up and record-keeping purposes. After this period, data is deleted or anonymized.

Engagement data (scroll depth, time on page) is retained for up to 12 months for analytical purposes.

Session replays are stored by PostHog in the United States and are retained for up to 12 months. A replay recorded before you submitted a form can be linked to you once you do submit one, because we identify you to PostHog by email address at that point.

7. Your rights

Under the GDPR and applicable data protection laws, you have the following rights:

• Access: Request a copy of the personal data we hold about you.
• Rectification: Request correction of inaccurate or incomplete data.
• Erasure:Request deletion of your personal data (“right to be forgotten”).
• Restriction: Request that we restrict processing of your data in certain circumstances.
• Portability: Request your data in a structured, machine-readable format.
• Object: Object to processing based on legitimate interests.
• Withdraw consent: Where processing is based on consent, you may withdraw it at any time without affecting the lawfulness of prior processing.

To exercise any of these rights, contact us at privacy@moonira.com. We will respond within 30 days. If you are unsatisfied with our response, you have the right to lodge a complaint with your local data protection authority.

8. Data protection measures

We implement appropriate technical and organizational measures to protect your data, including encrypted connections (TLS/HTTPS), access controls, rate limiting on all endpoints, and input validation. Sensitive credentials are stored as encrypted environment variables and are never exposed to the client.

9. Data Processing Agreement

If you require a Data Processing Agreement (DPA) for your organization, contact us at privacy@moonira.com and we will provide one.

10. Changes to this policy

We may update this policy from time to time. Material changes will be noted with a revised “last updated” date at the top of this page. Continued use of the site after changes constitutes acceptance.

11. Contact

For privacy-related questions, reach out to privacy@moonira.com.