Cookie Policy
Last updated: 14 May 2026
Scope: emese.care and commons.emese.care (public websites). The mobile app does not use cookies. It uses native device storage covered by our Privacy Policy.
1. What this policy covers
This Cookie Policy explains what we store on your device when you visit our public websites, why we store it, and how you can control it.
"Cookies" in this policy means more than just HTTP cookies. It covers every kind of persistent or semi-persistent identifier we write to your browser, including:
- Classic HTTP cookies (set by us or by Google).
localStorageentries (persist until you clear them).sessionStorageentries (cleared automatically when the browser tab closes).
Under EU ePrivacy law (the Cookie Law), all three categories trigger the same consent obligations as HTTP cookies if they are not strictly necessary for the service you asked for. We have grouped them honestly below rather than relying on the technical distinction.
2. Consent banner, first-party essentials
The following identifier is set the moment you choose an option in our cookie banner. It is strictly necessary under ePrivacy Art. 5(3) and does not require consent in itself. Without it we have no way to remember what you chose.
| Identifier | Type | Storage | Duration | Purpose |
|---|---|---|---|---|
emese_analytics_consent | First-party | localStorage | Persistent until you clear browser data | Stores your consent decision (granted / denied). Without it, the banner would re-prompt on every page load. |
If you clear your browser's local storage for emese.care or commons.emese.care, the banner reappears on your next visit.
3. Public-form metadata bundle (set on form interaction)
When you interact with any public form on our sites (registration, pre-register, helper signup, employer enquiry, feedback popup, commons contributor application), we set two identifiers on your device to keep the form workflow coherent across multiple interactions.
The user-facing explanation of what this metadata is used for is in our Privacy Policy, Section 2.7. This section discloses the storage mechanism so the cookie banner can be honest about what lands on your device.
| Identifier | Type | Storage | Duration | Purpose | Consent gate |
|---|---|---|---|---|---|
emese_session_id | First-party | sessionStorage | Until tab closes | Lets us treat your two-step feedback action (smiley click then free-text follow-up) as one record, not two. Also correlates a multi-page form session before submission. | Strictly necessary under ePrivacy Art. 5(3). Equivalent to the classic "session cookie" carve-out. Not gated on the analytics banner. |
emese_session_started_at | First-party | sessionStorage | Until tab closes | Records when this tab's session began, so we can measure time-on-site on submissions. | Strictly necessary (see above). |
emese_session_landing_url / emese_session_landing_path | First-party | sessionStorage | Until tab closes | Remembers the first page you opened in this session, so a submission on page 4 can still be attributed to the landing page. | Strictly necessary (see above). |
emese_session_referrer | First-party | sessionStorage | Until tab closes | Remembers the referring site for the session. | Strictly necessary (see above). |
emese_session_page_count | First-party | sessionStorage | Until tab closes | Counts pages visited in this session. An engagement-quality signal on submissions. | Strictly necessary (see above). |
emese_visitor_id | First-party | localStorage | Persistent until you clear browser data | Recognises a returning visitor across sessions. Lets us tell whether someone who submitted feedback last month is now applying for the program. | Consent-gated. Only created when emese_analytics_consent === "granted". If you have declined or have not yet answered the banner, this identifier is never written to your device and is never sent to our backend. |
emese_visitor_first_visit_at | First-party | localStorage | Persistent until you clear browser data | Records the first time the consent-gated visitor identifier was created. | Same consent gate as emese_visitor_id. |
Cross-reference: the same emese_visitor_idis also used by the website-side product analytics, but the writing of the value is gated on the same consent flag in both contexts. Withdrawing analytics consent stops new writes; existing values can be removed by clearing your browser's local storage for our domains.
4. Google Analytics 4 (optional)
If you choose "Accept all" in the cookie banner, we enable Google Analytics 4 (GA4) to help us understand how visitors use the site at an aggregate level. GA4 sets its own cookies on your device.
| Cookie | Type | Storage | Duration | Purpose |
|---|---|---|---|---|
_ga | First-party (set by Google) | HTTP cookie | 2 years | Distinguishes unique visitors. |
_ga_* (suffixed with our GA4 property ID) | First-party (set by Google) | HTTP cookie | 2 years | Maintains session state for GA4. |
Consent gate: GA4 runs under Google Consent Mode v2 in denied mode by default. When you reject analytics cookies, GA4 does not set any cookies and does not collect identifiable data. No data leaves your browser for Google until you explicitly consent.
What GA4 receives:anonymous, aggregated behavioural data: page views, sessions, time-on-page, country (city-level location stripped). We do not use GA4 to identify individual users. See also Google's own Privacy Policy.
5. Server-side persisted identifiers (set on form submission)
This section discloses identifiers that are notstored on your device, but that we generate from your browser's network identity at the moment you submit a form and persist server-side. We disclose them here for completeness. Strict reading of EU ePrivacy treats them as out-of-scope for cookie consent, but EDPB Opinion 9/2014 makes clear that "fingerprinting techniques" trigger the same Art. 5(3) obligations whether the identifier is stored on the device or on a server.
| Identifier | Where stored | Lawful basis |
|---|---|---|
ip_hash (SHA-256 of your IP address, truncated to first 32 hex chars / 128 bits, unsalted today) | Server-side on the Firestore record of the form submission. Raw IP is never stored. | Legitimate interest (Art. 6(1)(f)), abuse / spam detection. Treated as pseudonymisation under GDPR Art. 4(5), not anonymisation. |
server.user_agent_header (your browser's User-Agent string as received by our server) | Server-side on the Firestore record of the form submission. | Legitimate interest (Art. 6(1)(f)), bug triage, abuse detection. |
Retention for both: bound to the parent record. When you request deletion of your data (DELETE /me for account-bound records; manual purge for anonymous public-form records), these fields are deleted with it.
6. Where these identifiers are read
Identifiers in Sections 1 to 3 above stay on your device unless and until you submit a form. When you submit:
- The values are sent to our backend (Cloud Run, europe-west1 / Belgium) and persisted on the Firestore record of your submission.
- If your submission triggers an internal follow-up task (employer leads, user feedback, commons contributor applications), the bundle is also rendered into a ClickUp task description so our team can follow up. See Privacy Policy Section 4 for the full ClickUp processor disclosure. ClickUp is US-hosted under EU SCCs.
- The bundle is never forwarded to GA4. The GA4 path is a separate, server-side pipeline gated by its own consent check.
Identifiers in Section 4 (GA4 cookies) are read by Google directly from your browser, with our backend not involved.
Identifiers in Section 5 are computed server-side from network headers; your browser does not store them.
7. How you can control these identifiers
- Cookie banner: On your first visit, you choose "Accept all" (essential + analytics) or "Essential only" (essential only). Your choice is stored in
emese_analytics_consentand respected on every subsequent page load. - Change your mind later: Clear your browser's local storage for
emese.careorcommons.emese.careand refresh the page. The banner reappears. (A "Change cookie preferences" UI is planned but not yet shipped.) - Browser-level controls: All modern browsers let you block or delete cookies and clear
localStorage/sessionStorageper-site. Note that blocking the strictly-necessary identifiers (Section 2) will cause the cookie banner to reappear every visit. Blocking the strictly-necessary session identifiers (Section 3) may break the two-step feedback flow. - Delete your data: If you have submitted a form, you can request deletion via hello@emese.care (or
DELETE /mefor authenticated mobile users). The server-side identifiers in Section 5 are deleted alongside the parent record. The on-device identifiers in Sections 1 to 3 are cleared by clearing your browser's storage for our domains.
8. Third-party storage
We do not use:
- Advertising cookies.
- Social media tracking pixels (no Facebook Pixel, no LinkedIn Insight Tag, no TikTok Pixel).
- Cross-site tracking partners.
- Session replay or heatmap tools.
The only third-party identifier we set is the GA4 cookie pair in Section 4, and only with your explicit consent. All other persistent identifiers are first-party.
9. Updates to this policy
We will update this Cookie Policy when our practices change. For example, when we add a new persistent identifier, a new third-party processor, or change the consent gate on an existing identifier. The "What changed?" panel at the top of this page lists every version and what changed in each.
10. Contact
If you have questions about cookies or any persistent identifier on our sites, contact us at:
- General: hello@emese.care
- Privacy / data subject requests: hello@emese.care
For the full picture of how we handle your data, see our Privacy Policy.