Cookie Policy

Version 1.12 — effective 25 August 2026

This policy explains when Emblemry stores information on your device or reads it again, and what it measures while storing nothing at all. It covers cookies and similar browser storage.

The short version

• Emblemry measures how the service is used. By default that measurement stores nothing on your device and reads nothing from it.
• You can allow analytics to keep a cookie and browser storage as well. Allowing it also switches on session replay, page-speed scores, and error reports. That is optional, and refusing it changes nothing about the service.
• Refusing stops the analytics cookie and the persistent identifier, and none of the replay, scores, or reports run. It does not stop the storage-free measurement, which this choice does not control.
• Measurement requests go to this site's own /relay address, and Emblemry forwards them to PostHog's EU Cloud. Your browser never talks to PostHog directly.
• Emblemry keeps a few things of its own: your sign-in session and a marker that you are signed in, your answer so the storage question is not asked again, a note of where you had scrolled so going back puts you where you were, a list of the badges you made on this browser before signing in, each with a reference to the brief it was made from, so they can be moved to your account, a set you are composing until its first samples are paid for, an expansion you are writing until you start it, a replacement you are writing for one badge until you start it, and — in this tab only — a brief you were writing when sign-in or checkout interrupted it. None measures anything.
• Emblemry does not identify visitors, build profiles of them, or use advertising trackers or automatic event capture. Session replay runs only after you allow storage, and everything you type is replaced with asterisks in your browser before a recording leaves it.
• An infrastructure provider can still use storage that is strictly necessary to deliver or protect the site.

1. Measurement that stores nothing

Emblemry uses PostHog on its EU Cloud to count how the service is used. That counting starts with your first page view — before you have answered anything, and equally after you have refused — and in both cases it sets no cookie, writes no local-storage or session-storage entry, and reads nothing that is already on your device. PostHog counts the events against a hash it computes on its own servers, rotates daily, and never sends to your browser.

Besides page views and the product steps in section 3, the counting notes how long each page stayed open before you left it, how far down each page you scrolled, and, when you arrive through a link Emblemry itself published with campaign tags, the five utm_ values written into that link.

Requests do not go to PostHog directly. The browser sends every measurement request to this site's own /relay address, and Emblemry's server forwards it to PostHog's EU Cloud, passing along the network address the request came from — that address is what the daily hash is computed from, and the PostHog project is configured to discard it once received.

Section 25 TDDDG governs storing information on, and gaining access to information already stored in, your device. Measurement in this state does neither, so Emblemry does not treat it as requiring your consent. The processing itself rests on Article 6(1)(f) GDPR: Emblemry's interest in knowing whether the service works, weighed against events that carry no identifier, no brief text, no image, and no address beyond the name of a page.

You can object to that processing under Article 21(1) GDPR through the contact page. Because nothing about it is stored in your browser, the immediate and complete way to stop it on this device is to block requests to this site's /relay path — every measurement request leaves your browser through it, and nothing else uses it.

The daily free pool is unaffected either way. It is global; it is not an address-based or per-browser quota.

2. Optional storage, and the measurement it switches on

If you choose Allow storage, PostHog starts differently on your next page load: it sets a cookie and browser-storage entries on this domain holding a random identifier it generates for itself. That is what lets a second visit be counted as a second visit rather than as a new one. The identifier is PostHog's own; it is not linked to a name, an email address, a badge, or anything you typed, and Emblemry creates no person profile from it.

Three further kinds of measurement also start, and only then:

• Session replay. Your visit is recorded and can be watched back by Emblemry. The recording shows the pages as you saw them — including the content and address of any badge page you viewed — and how you moved through them. Everything you type is replaced with asterisks in your browser before the recording leaves it, so no typed brief text, form value, or search entry is ever transmitted.
• Page-speed scores. Four standard timing scores per page — largest paint, layout shift, first paint, responsiveness — each a bare number attached to the page's name.
• Error reports. When something on a page breaks, the error's message, type, severity, and the place in Emblemry's own code it came from, so it can be fixed.

The events in section 3's first list stay exactly the same, whichever way you answer.

This is everything PostHog then keeps on your device. The names below were read off the deployed site in a clean browser profile with a recording running, not copied from documentation, because PostHog splits this storage across several keys and the names move with the software. <project key> stands for the public identifier of Emblemry's PostHog project, which appears in full in each real key name.

None of it is linked to a name, an email address, a badge, or anything you typed. Withdrawing removes every one of these entries, as section 6 describes.

3. What is measured

In both states, this short list is recorded and nothing else:

A page view and a page left also carry how far the page before them was scrolled — that page named from the same fixed list — as four percentages: the furthest point reached and the point it was left at, each measured against the page's full length and against the part that was on screen.

After you allow storage, three more join it:

The page name can only be one of nine fixed values: the composer, the gallery, a badge page, the contact page, and the five legal pages. A badge page is always reported as /b/[slug]. The real address of the badge, which is derived from text a visitor wrote, is never sent, and neither is any query string or fragment.

Every event also carries a short, fixed list of technical context. Emblemry does not remove unwanted fields from what PostHog assembles; it builds each event from a named list instead, so a field is sent only if it appears below and anything the analytics software starts adding in a future version arrives nowhere until that list is changed.

The last two are the host name alone and the name of the engine alone. The full referring address is not sent, and neither is anything you typed into a search box.

Deliberately not sent, although the analytics software offers them: the page title, which on a badge page is the title someone wrote; the address of the previous page and of the page a visit started on, which are the same slug by another name; the raw browser identification string; screen and window dimensions; the scroll positions in pixels, from which the window's height can be worked out; and, of the twenty-four advertising and campaign parameters the software reads, the nineteen advertising click identifiers such as gclid and fbclid — only the five utm_ tags that Emblemry itself wrote into a link are sent. Emblemry's PostHog project is also configured to discard the network address the request arrived from once the daily hash is computed.

Never sent as event fields: brief titles, subjects, motifs, avoid entries, direction notes, images, badge identifiers or slugs, page titles, form values, report contents, contact details, provider errors, search queries, and arbitrary addresses.

A session recording is different in kind from an event field, which is why it needs your consent: it shows the pages of your visit as they appeared, and on a badge page that includes the badge's content and its real address. What it never contains is anything you typed — that is masked in your browser before sending, as section 2 describes.

4. Your answer, and the site's own storage

Emblemry keeps the entries below of its own. None measures anything. The two cookies travel to Emblemry with every request — the session is what authenticates them, and the signed-in marker is a single yes that only the page itself reads. The other entries stay in your browser unless you act. A brief, a set, an expansion, or a replacement held in one of them is sent only if you go on to submit it, the same as if it had never been stored, and the list of badges made on this browser is sent once, when you sign in, to move those badges to your account.

Closing the banner or the panel without answering stores nothing beyond the scroll positions above. The question then returns on your next visit.

Version 1.12 listed emblemry_expansion_draft, which the site now writes while you add members to a settled set, so that a reload or a trip to buy credits does not lose what you typed. It falls under the strictly necessary exception in section 7, holds no identifier and measures nothing, and what allowing storage buys is unchanged — so an answer given under version 1.11 still stands, and the question is not asked again.

Version 1.11 replaces the previous checkout provider's storage description with Polar's privacy notice. It does not change Emblemry's storage or what allowing analytics storage buys, so an answer given under version 1.10 still stands, and the question is not asked again.

Version 1.10 changed what emblemry_made_badges holds. Beside each badge's address it now keeps a reference to the brief that badge was made from. The address on its own proved nothing: a badge made without an account is public, so anyone reading the gallery could name one and ask for it. The reference is the part only the browser that made the badge was given, and asking for it is how the site tells your badge from a stranger's. It remains strictly necessary under section 7 — it exists only to move your badges to the account you sign in to, it points at a badge rather than at a person, and it measures nothing. Nothing about analytics changes, and what allowing storage buys is unchanged — so an answer given under version 1.9 still stands, and the question is not asked again.

Version 1.9 listed emblemry_replacement_draft, which the site now writes while you rewrite one badge in a set, so that leaving to buy credits does not lose what you typed. It falls under the strictly necessary exception in section 7, holds no identifier and measures nothing, and what allowing storage buys is unchanged — so an answer given under version 1.8 still stands, and the question is not asked again.

Version 1.8 listed emblemry_set_draft, which the site now writes while you compose a set, so that a reload or a trip through sign-in or checkout does not lose what you typed. It falls under the strictly necessary exception in section 7, holds no identifier and measures nothing, and what allowing storage buys is unchanged — so an answer given under version 1.7 still stands, and the question is not asked again.

Version 1.7 listed emblemry_made_badges, which the site now writes when you make a badge without an account, so that signing in can move that badge to you. It falls under the strictly necessary exception in section 7, holds no identifier and measures nothing, and what allowing storage buys is unchanged — so an answer given under version 1.6 still stands, and the question is not asked again.

Version 1.6 added the signed-in marker, which signing in now sets beside the session, and named the three tab-local entries that carry a return page and an unfinished brief across sign-in and checkout, which the site already wrote and this policy had not listed. All of them fall under the strictly necessary exception in section 7, none is analytics storage, and what allowing storage buys is unchanged — so an answer given under version 1.5 still stands, and the question is not asked again.

Version 1.4 published the list of PostHog's storage keys in section 2, read from the deployed site, and listed the scroll-position entries in this section, which the site has always written and this policy had not named. Neither addition changed what is stored or what allowing storage buys, so an answer given under version 1.3 still stands, and the question is not asked again.

Version 1.3 added scroll depth to the storage-free measurement in section 1. It runs whichever way you answer, stores nothing on your device, and did not change what allowing storage buys — so an answer given under version 1.2 still stands, and the question is not asked again.

Version 1.2 changed what allowing storage buys — it now also switches on the replay, scores, and reports in section 2 — so an answer given under version 1.1 counts as no answer, and the question is asked again.

5. Strictly necessary infrastructure storage

Cloudflare or another infrastructure provider may use a strictly necessary security mechanism when it is needed to transmit traffic, resist abuse, or provide a feature you requested. Its lifetime is set by that provider. This kind of storage does not require consent, because it serves only transmission, security, or a feature you expressly requested.

Cloudflare can also set storage on its own domains while you interact with its service. Its notice governs storage on those domains.

Firebase, Google, Apple, and Polar can set storage on their own domains on the pages where you sign in or use checkout. Their notices govern that provider-domain storage. Polar's Privacy Policy explains how it handles checkout data and related storage.

Before publication and after a material deployment change, Emblemry checks the site in a clean browser profile, because provider-set storage may not appear in the application source.

6. Your choice, and changing it

The first ask is a banner at the foot of the page. It offers Allow storage and Don't allow storage with the same prominence and one action each, blocks nothing while it is open, and closing it unanswered stores nothing. Nothing is preselected, and Details leads here without answering on your behalf.

You can reopen the choice from Cookie settings in the footer of every page — a panel with the same two answers, your current setting, and the full description — and change it in either direction. Withdrawing removes PostHog's identifiers from this browser and reloads the page into the storage-free state described in section 1, which ends replay, scores, and reports with it; it does not affect processing that was lawful before you withdrew.

Clearing your browser's site data removes both your answer and PostHog's storage, and brings the panel back.

7. Legal basis

Section 25 TDDDG requires consent for storing information on, or reading information from, a device unless a narrow exception applies. Emblemry relies on:

• your consent under section 25(1) TDDDG, and Article 6(1)(a) GDPR for the processing that follows, for the optional analytics cookie and storage in section 2 and for the session replay, page-speed scores, and error reports that the same consent switches on;
• the strictly necessary exception in section 25(2) TDDDG for the session cookie in section 4, which provides the signed-in service you requested, for the signed-in marker beside it, which only lets the page show that signed-in state without waiting on a request, for the record of your answer in the same section, which exists only to carry that answer out, for the scroll positions there, which deliver page-to-page navigation you asked for, for the tab entries that return you and an unfinished brief to where sign-in or checkout interrupted, for the list of badges made on this browser, which exists only to deliver the moving of those badges to the account you sign in to, for the set you are composing, which exists only to keep that composition through the reload, sign-in, or checkout that would otherwise lose it, for the expansion and replacement you are writing, which exist only to keep those edits through the trip to buy credits that would otherwise lose them, and for the infrastructure security storage in section 5; and
• no device permission at all for the measurement in section 1, which neither stores nor reads anything. Section 1 states the GDPR basis that processing rests on and how to object to it.

8. Retention

Analytics events are kept for 12 months and then deleted. Session recordings are kept for 30 days and then deleted, on a schedule separate from the 12 months for events. Your own answer stays in this browser until you change it or clear site data. The Privacy Policy lists retention for everything else.

9. New storage and tracking

A new non-essential cookie, SDK, event, replay feature, or advertising use requires an updated policy and your consent before it starts.

10. Contact and changes

Questions about storage or consent can be sent through the contact page. Personal-data rights are explained in the Privacy Policy.

The version and effective date appear at the top. Emblemry updates this policy before changing a storage purpose, provider, consent category, or material retention period.