Cookie policy
Effective 2026-10-26
What we use cookies and storage for
A cookie is a small file a site keeps in your browser. Local storage and session storage do the same job by another route. This page says “storage” for all three, because what matters is the same in each case: something has been left on your device.
We use it for four things. Keeping you signed in. Checking that an enquiry form is being sent by a person rather than a script. Remembering choices you made yourself in the signed-in app, like your colour theme and how you like a page laid out. And, if you agree to it, measuring which pages get read and which paths people take through the product. None of it is used for advertising.
Strictly necessary storage, and analytics storage
Some storage is strictly necessary: without it the thing you asked for doesn’t work. Signing in is the plain case — your session has to be held somewhere, or every page would ask for your password again. The bot check on our enquiry forms is the other: it sets its own storage to tell a person from a script, and it loads only on a page that is showing one of those forms, not on every page. Storage in this category is set without asking, because asking would not be a real choice — decline it and the page cannot do what you came for.
Analytics storage is not like that. It is useful to us and not needed by you, so it is set only if you accept. Before you answer, and after you decline, no analytics cookie and no analytics storage is written. One of our analytics providers still counts page views without cookies during that time: it sees the page, your browser type and your IP address, and it uses them without storing anything on your device. After you decline, our other analytics provider counts visits the same way, using a code that changes every day, so it cannot follow you from one day to the next. Accepting turns the cookies on. Declining writes one thing: a note that you declined.
Two smaller cases sit in between. The record of your own answer to the banner, which we keep so you aren’t asked again on the next page. And the settings you pick inside the app — theme, which layout you prefer, which project you had open. Those are there because you chose them.
One thing happens whatever you answer, and it is worth naming: each page request writes a line to our own server log recording whether consent was accepted, declined or not yet given, and which page was asked for. It carries nothing that identifies you.
Everything we store, item by item
Below is the full inventory: what each item is called, who sets it, what it does and how long it lasts. Names appear there and nowhere else on this page, so the table stays the one place to check.
One row cannot be more exact than it is. The provider that runs our bot check does not publish the names or lifetimes of the storage its widget uses — its own privacy addendum declines to enumerate them. We would rather that row read as vague and true than fill it with key names we made up.
| Name | Set by | Purpose | Expires |
|---|---|---|---|
| signal_analytics_consent | Adduce | Remembers whether you accepted or declined analytics cookies and, in the app, which account made the choice | 180 days |
| signal_analytics_consent_synced | Adduce | Remembers that your consent choice has been saved to your account in the app, so it is not sent again | Until you clear site data |
| ph_* (PostHog) | PostHog | Analytics identity and event queue. Only written after you accept | 12 months |
| __ph_opt_in_out_* (PostHog) | PostHog | Records your analytics opt-in or opt-out so it is not asked again | Until you clear site data |
| _ga | Google Analytics | Tells one visitor's visits apart. Only written after you accept | 2 years |
| _ga_<container-id> | Google Analytics | Keeps the current visit together. Only written after you accept | 2 years |
| _gcl_ls | Google Analytics | Remembers which advert, if any, brought you to the site. Only written after you accept | Until you clear site data |
| Turnstile challenge storage | Cloudflare Turnstile | Bot protection on the lead-capture forms (contact, scale enquiry, design-partner application). Loaded only when a form is shown. Strictly necessary | Set by Cloudflare; not enumerated in their published documentation |
| sidebar_state, settings_rail_collapsed, chat_rail_collapsed, signal_active_project | Adduce | Remembers your layout and last open project in the app so the first page render is correct. Strictly necessary | 7 days |
| theme, signal:sources-view | Adduce | Remembers your colour theme and list layout preferences | Until you clear site data |
| signal:org-create-wizard | Adduce | Keeps your place in the create-organisation steps while you are sent to the payment provider and back | Until the browser tab is closed |
How to accept or decline
On your first visit a banner appears at the foot of the page with two buttons, Accept and Decline. While it sits there unanswered, no analytics cookie is written, though page views are still counted without cookies, as described above. Accept turns analytics cookies on. Decline keeps them off, and visits are then only counted without cookies.
Your answer is kept in a cookie on this site for 180 days. The signed-in app asks separately: an answer given here doesn’t carry over to it, and an answer given there doesn’t carry back.
How to withdraw consent later
Choose Cookie preferences in the footer of any page. It reopens the same banner with the same two buttons, so you can give a different answer. There is no separate form to fill in and no request to send — you withdraw consent the same way you gave it, and you can do it as often as you like.
Withdrawing stops analytics cookies from that point on, and visits are then only counted without cookies. It doesn’t reach back and undo what was collected while consent was in place; if you want that removed too, our privacy policy explains how to ask.
Clearing cookies and site data in your browser works as well, with one catch: it also clears the record of your answer, so the banner will ask you again on the next visit.
What declining leaves in place
Declining keeps analytics cookies off. It does not empty your browser. The strictly necessary items stay — the session that keeps you signed in, the bot check on the forms, and the record of the decline itself, which has to be stored or the banner would ask again on the next page. That record is kept in two places: our own cookie, and a note the analytics provider keeps so it only counts without cookies.
The settings you picked in the app stay too. You set them, and throwing them away would be losing your preferences, not protecting your privacy.
We log technical errors either way
Whatever you answer, when something breaks we send a diagnostic report to our error monitoring provider: what the error was, where in the code it happened, and — if you’re signed in — the identifiers for your account and organisation. Not your email address, not your cookies, not your IP address. That is how the product gets fixed, so it doesn’t wait for consent. It writes nothing to your browser, on this site or in the signed-in app.
Session recording in the signed-in app
The signed-in app records no sessions: no replay of the pages as they appeared to you is made, whichever answer you give, and error reports carry no recording either.
The public site you are reading now records no sessions at all, whichever answer you give.