How this site measures itself.

What we record.

When you open a page, and when you click one of the primary buttons, your browser sends a short message to our own server at esya.studio. We write it to a database we own. Each record holds the time, which page, which button if it was a button, any campaign parameters that were in the link you followed, and the marker described in the next section. Nothing else, and nothing you type.

When you send the contact form, our server records that a submission succeeded or that it failed, and if it failed, which kind of failure it was. It records nothing you wrote.

How we tell visits apart, and how we recognise a return.

The first time you arrive, your browser generates a random number for itself and keeps it. It is not derived from you, your address or your device, and it means nothing anywhere except on this site. It is sent with each of the records described above, so we can see that a set of page views belongs to one visitor, and that someone who read a page last week has come back. That is the whole purpose: knowing whether people return is the difference between counting traffic and understanding it.

The marker persists until you clear your browser storage or switch it off, so visits can be linked across days. It is first-party in the way that matters: no other website you visit ever sees it, it cannot follow you off this site, and it is not combined with anything bought from anyone else. The one copy that leaves our systems goes to the charting company named below, working under our instruction.

To switch it off, use the control at the foot of any page. One click deletes the marker, stops a new one being made on this browser, and stops the visit recording described below. We go on counting page views after that, using a fallback marker our server works out from your network address and your browser’s identifying string, for that day only. It changes every day and we do not join one day to the next with it.

If you block scripts or storage and never had the marker, the same daily fallback is what we use, and nothing here needs you to do anything.

Who else sees it.

Cloudflare runs this site. Everything you send us passes through them, including the contact form, and they hold our database and deliver our email, so they are the one company that handles all of it on our behalf. We also use their Web Analytics: a small script that reports page views, the page you arrived from, and how quickly pages loaded. It sets no cookies and stores nothing on your device; what it reports comes from the page request itself and the timing figures your browser already keeps in memory. Cloudflare say they discard the address that script arrives from at the nearest data centre rather than storing it.

PostHog is the only other company involved in the measurement. The counting records reach it as a copy sent from our server rather than from your browser, so for those it never sees your address; what it holds is the marker described above. The visit recordings are different: your browser sends them to PostHog directly, so that traffic carries your IP address to them the way any request to any website does. Both carry the same marker, so at PostHog the recordings and the counting records line up under one visitor, and because the recordings arrive from your browser, PostHog holds the marker and your address together for as long as a recording lives. Both are processed for us in the EU, in Frankfurt.

The counting copy sent to PostHog does not contain your name, your email address, or anything you type into the contact form. The recording software is configured to mask what you type before it leaves your browser. If you open a book-a-call link that already carries your name and email in the page address, a recording of that page, and any log of that address, can include them: they are in the address, not in a field you typed. Their copy is there for charting; the record itself is ours.

We record visits.

Visit recording is on by default. We record what happens in the browser window while you are on the site: where you move, what you click, what you scroll past, where you stop. Played back, it shows us where the site confuses people, which is the one thing numbers alone never tell us. Recordings from this browser are labelled with the same recognition marker described earlier, so we can find the recording that belongs to a visit we counted; the one control switches both off together.

The recording software is configured to mask everything you type before it leaves your browser. Every field on the contact form is masked at source, so a recording shows that someone typed and never what they typed. PostHog store the recordings for us in the EU; they are kept for about a month and then deleted.

To turn it off, use the control at the foot of any page. One click stops the current recording, stops this browser being recorded again, and deletes the recognition marker described earlier. If this site is open in more than one tab, the others stop too. It stores a small marker of its own so we remember your decision.

The same control turns it back on. When recording is off, the control reads “Recording is off”; using it again reloads the page, removes the marker that remembered your decision, and starts afresh, with a new recognition marker that has no link to the old one. In other open tabs, recording stays off until you reload them, but the new recognition marker applies in those tabs straight away. If you clear your browser storage instead, the setting goes with it, and recording is on again the next time you visit.

Turning it off stops future recording; it does not delete recordings already sent, which stay until they age out at about a month. If you want those removed, ask us. PostHog’s own software leaves some of its working state in your browser after you opt out; clearing your browser storage for this site removes it, and turning recording back on clears it before anything fresh is made.

Turning it off costs you nothing else: the site works exactly the same, and we do not treat a visitor who opts out any differently.

Booking a call.

The calendar on our booking pages is provided by Cal.com, and it loads as soon as you open one of those pages. There is no button to press and nothing to agree to first. Those two pages are the only place on this site where that happens: everywhere else, nothing of Cal.com’s is loaded, requested or stored, and if you never open a booking page nothing in this section applies to you.

The calendar appears inside an isolated frame belonging to Cal.com. Their software runs inside that frame under their address, not as a script under ours, so it cannot read this page or the browser storage kept for esya.studio. We exchange only the messages needed to know when the calendar is ready and how tall its frame should be.

As the calendar renders, Cal.com set three cookies of their own: __cf_bm, __Secure-next-auth.csrf-token and __Secure-next-auth.callback-url. The first helps Cal.com distinguish automated traffic from people. The other two support their authentication system: one protects authentication requests and one remembers where to return after authentication. Cal.com set them before you ask to sign in, so we do not describe either as necessary merely to display the calendar. If you choose a time and proceed to the booking form, Cal.com also set uid for the temporary slot reservation. All four belong to cal.com rather than to us, they are set on cal.com’s address and not on esya.studio, and we cannot read them. The first lasts about half an hour and the other three last for the browser session. None of them follows you to other websites. Their software also keeps three small items in your browser under its own address rather than ours: which clock format you prefer, a note of its own sign-in state, and which colour theme the calendar last used.

What you type into the calendar goes to Cal.com, because the booking is made with their service: your name, your email address, anything you write in the notes, any guests you add, and your answer to either optional qualifying question if you choose to give one: annual revenue on the engineering calendar, or how many people you need to hire on the talent calendar. Both questions are optional and a booking is confirmed whether or not you answer one. We receive the booking from Cal.com, and the meeting appears in our diary and our email.

The emails a booking sends. Two confirmations follow a booking. Cal.com send their own, as part of making the booking with their service. We send ours as well, from us through Cloudflare, to the address you booked with, so the confirmation reads like the site you booked on, with replies going to the studio inbox. There is no counting image in it, and we make no second copy of your booking details to send it. Two working records do follow from the send. One is a one-way fingerprint of the address you booked with, which stops the same address being mailed twice and is discarded after ten minutes. The other happens only if the send fails: a note of that failure against the booking reference, carrying no name and no address.

Where this one goes. We can evidence that our own measurement stays in the EU, and we say so above. We cannot make the same statement about Cal.com. Our account is on their main platform rather than a European-only one, and we have observed their software reporting its own errors to an address in the United States. So treat a booking as leaving the UK and the EU. Cal.com commit to the standard contractual clauses in the terms that bind them to us, and that is the safeguard the transfer runs under.

If you would rather not. Do not open a booking page, and nothing above happens. If you are already on one, the two links below the calendar are the ways out, and they are not the same as each other. A plain link opens the calendar on cal.com’s own site: that keeps their software off our page, but you are then on their site under their notice, so it avoids none of the cookies above. A link to our contact form reaches us without involving Cal.com at all, and that is the one to use if you would rather they were not involved. Both stay on the page for as long as you are on it, whether or not the calendar loads, and both work with scripting switched off, when the calendar does not load at all.

The contact form.

If you fill in the form, we store what you wrote so that we can reply to it, and we send it to ourselves by email. Along with the booking calendar, this is a place where you choose to give us personal information. We use it to answer you and for nothing else. If you would like it deleted, ask, and we will delete it.

The form is protected by Cloudflare Turnstile, which examines signals from your browser to judge that a submission came from a person rather than a script, and gives the submission a pass token our server checks. We never see those signals ourselves, and Turnstile does not track you across sites.

The confirmation email.

We send a confirmation email because you wrote to us. It confirms that your note reached a person, restates the two working days, says we will review and assess what you wrote then come back, and offers a book-a-call link on this site. We send it to the address you gave, from us, with replies going to the studio inbox.

We count whether that email was opened. A tiny image on our own site is what the count uses. Mail apps often fetch this automatically, so it is a count, not proof you read it. We count whether someone arrived at a booking page from a link in that email, using the campaign tags on the address.

An opaque token sits on the counting record so we can count opens per send. The mapping from that token to your introduction lives with the introduction, not as a name in the ledger. The charting copy of an open does not carry that token.

If you open a book-a-call link from that email, the page address can carry your name and email so the calendar can be filled in. A visit recording of that page, and any log of that address, can therefore include them. The counting record still does not store your name or email.

We cannot, from the ledger alone, say that this open became that booking.

Why we are allowed to do this.

The Privacy and Electronic Communications Regulations govern storing information on your device or reading information from it. Since February 2026 they permit storage for measurement without asking first, on four conditions, and here is each one against what we do. The purpose must be statistical information about how the site is used, with a view to improving it: counting visits, returns and completed forms so these pages can be made better is what the marker is stored for. The information may be shared only with those who help with that: the one company that receives a copy is named on this page and works under our instruction. You must be given clear and full information: this page is it. And you must have a simple, free way to object, which is honoured: the control at the foot of every page is that way, one click, no charge.

The visit recording stores something too, and we do not stretch that permission to cover it: the permission is for counting, and a recording of your visit is more than a count. The recordings are also labelled with the marker, as the recording section above says plainly, and that use belongs to the recording rather than to the counting permission. We run the recording on open terms instead of behind a banner: on by default, configured to mask everything you type before it leaves your browser, described in full in its own section above, and switched off with the same one click, which ends the labelling with it. The same control switches it back on, and a fresh marker is made when it does. If you think that is the wrong trade, use the control, or say so at hello@esya.studio and we will listen properly.

Here is everything this site stores in your browser, in full:

• esya:vid, the random recognition marker described above. Deleted by the control at the foot of the page.
• esya:consent:replay, set only if you turn recording off, so we remember your decision. It stays until you turn recording back on, which deletes it, or until you clear your browser storage.
• esya:contact:draft, a copy of what you have typed into the contact form, so a failed submission does not lose your message. It stays in that one browser tab and is deleted as soon as your message reaches us. It is your own words, kept for you.
• A handful of keys belonging to PostHog’s recording software. These include a record of your decision if you turn recording off, so they do not all go away when you do. They stay until you turn recording back on, which clears them before fresh ones are made, or until you clear your browser storage for this site.

None of these are cookies. We set no cookies of our own, for anything. Two other companies set cookies of theirs: Cloudflare, who run the site, may set one to tell automated traffic from people. Cal.com set three of the cookies named above when either booking page opens and loads the calendar automatically, and set uid only if you proceed to the booking form. Those are theirs rather than ours and we do not read them.

Under the UK GDPR our basis for the measurement is legitimate interests: knowing whether the pages we publish actually work. We have written that assessment down rather than asserted it, and we will summarise it for you on request. Our basis for handling a contact form submission is that you asked us to reply to it.

Cookies.

We set none of our own, for anything. The recording software is configured to keep its state in browser storage rather than in a cookie for exactly that reason. The list above is the whole of what we leave on your device instead, named key by key.

On every page except the two booking pages, that is the end of it, apart from Cloudflare, who serve the site and may set one of their own to tell automated traffic from people. It is theirs and we do not read it.

The booking pages are the exception, and only if you use them. Loading the calendar there opens Cal.com’s isolated frame and it sets three cookies of its own, named one by one in the booking section above. A fourth appears only if you proceed to the booking form. Those are the only cookies on this site besides Cloudflare’s, they appear only during those booking visits, and the contact form reaches us without them.

To clear the parts stored under esya.studio, clear site data for esya.studio in your browser, and everything in the list above goes with it. That does not reach Cal.com’s cookies, because a browser keeps each site’s storage separate and theirs are held under cal.com: to clear those, clear site data for cal.com as well. To clear only the parts we control and stop them coming back, use the control at the foot of this page: one click deletes the recognition marker and stops both it and the recording starting again on this browser, for as long as you leave it off.

The bases we rely on.

The same four things the sections above describe, in one place, because that is where a careful reader wants them.

Three of those also store something on your device, which is the separate question the Regulations in the section above govern: the marker is stored under their measurement permission, and the recording on the open terms set out there, each with the same one-click way out. The booking cookies are the third, and they rest on neither of those. __cf_bm protects Cal.com’s service and uid holds a temporary slot after you choose a time. Their two NextAuth cookies support authentication, but Cal.com set them before you request authentication and we do not claim that they are strictly necessary merely to show the calendar. None of the four is an advertising or cross-site tracking cookie, none follows you to another website, and we set none ourselves. This site does not put a consent banner in front of them: that is the current owner-approved implementation, stated here plainly rather than justified by treating every cookie as necessary. Use the contact form instead if you do not want Cal.com involved.

The honest limit of that. Cal.com set those cookies, so the exact account of what each one does is theirs to give. Ours comes from their names, their published authentication code, their behaviour and when they appear. If you think one goes beyond what the booking needs, tell us at hello@esya.studio and we will ask them and say what we are told. To avoid the question entirely, use the contact form instead of opening a booking page: it reaches us without Cal.com at all.

How long we keep it.

Who processes it, and where.

Nobody else processes it for us. There is no advertising network on this site, no marketing platform reading this page, no data bought from anyone and nothing sold to anyone.

On leaving the UK: serving a site from a global network means a page can be served, and a request handled, outside the UK and the EU. Where Cloudflare, Microsoft, PostHog or Cal.com handle personal data outside the UK, the transfer runs under the UK Addendum to the EU standard contractual clauses, or under a UK adequacy decision where one covers the destination; all four build those safeguards into the data-processing terms that bind them to us. The measurement copy and the recordings go only to PostHog in the EU, a transfer the UK covers with its adequacy regulations for the EEA. A booking is the one thing on this site we cannot make that statement about, and the booking section above says so plainly rather than leaving it to be inferred from this paragraph.

What you can ask for.

You can ask what we hold about you and get a copy of it, ask us to correct it or delete it, and ask us to stop using it while a dispute about it is worked out. Where you gave it to us yourself and it sits in a structured record, the contact form being the practical case, you can ask for it in a machine-readable copy to take elsewhere. Write to hello@esya.studio and a person will answer.

You can object at any time, and the control at the foot of any page takes effect immediately. It ends the recognition and the recording on that browser: the marker is deleted and no new one is made while your decision stands. The decision is yours to reverse from the same control, and if you do, a fresh marker is made, with no link to the old one. Counting itself does not stop, as the section near the top of this page explains: after an objection this site still counts a page view the way a turnstile counts a person, under a fallback that changes daily and joins nothing together. If you write to the address above instead, we will walk you through the same control and delete any records you can point us to.

If you are not happy with an answer, you can complain to the Information Commissioner’s Office.

How we can actually find your records. Measurement records carry the recognition marker and nothing else about you. We keep no stored link between a marker and a name, and we do not build one, so an email address does not find measurement records. A marker you send us locates records: it is in your browser’s storage for this site under esya:vid. It does not by itself prove the records are yours, because a marker proves possession of a browser rather than identity. If you send us a marker and ask us to delete the records under it, we delete them without further proof, because an unverified deletion can only cost the person asking. If you ask to see them, we will agree a confirmation step with you before showing anything, and we will say what we are asking for and why.

One thing to know before you use the footer control: it deletes the marker from your browser, and records made while it existed keep it, so once it is gone we can no longer pick those records out for you. If you want them deleted, send us the marker first, or ask before you switch off. The recording software’s own storage can keep a copy of the old identity until you clear site data or turn recording back on; if you find it there, the deletion route above still works. Records made while recording stays off carry only the daily fallback, which we do not join across days and make no attempt to trace back to anyone. If you turn recording back on, records from then on carry the fresh marker, and nothing joins it to the old one. Contact form submissions are different: those we can always find, because they carry your name and your email address. So are bookings, for the same reason, and deleting one means deleting it at Cal.com as well as at our end.

Who we are.

The controller for everything on this page is the company below. Write to the address in it and a person answers, which on a company this size means the person who built the thing you are asking about.

We are registered with the Information Commissioner’s Office, the UK regulator for this. If you are not satisfied with how we answer you, you can complain to them.

This notice was last changed on 17 August 2026.