Policies

Cookies and tracking

Last updated July 29, 2026

Draft for legal review — not yet in force.

Last updated 29 July 2026.

The short version

There is no advertising network in Voyade, and no third-party analytics tracker. Not Google Analytics, not anything.
Nothing we set follows you to another website. We cannot build a cross-site profile of you, and we have not built the plumbing to.
The only genuinely optional thing we would like to store is a small cookie that remembers which creator’s link brought you here, so they get paid if you book. You can say no, and everything still works.
Declining costs you nothing except some accuracy in a creator’s earnings. No cookie wall, no nag, no feature held hostage.
When you click a booking link you leave Voyade, and the partner’s site sets its own cookies under its own policy. §5 explains how those actually work, because it is the interesting part.

1. Why this page is longer than most

Affiliate attribution is the mechanism that pays for this product and pays our creators, and most companies describe it in one vague sentence. We would rather explain it, because once you understand it you can make a real decision about the one optional switch.

2. What we set, and what it is for

Strictly necessary — no consent needed, no way to turn off

These are the ones the service cannot work without. Under EU law they do not require consent, and we do not pretend to ask.

This is the complete list, by the name you would see in your browser.

Name	What it does	How long
`_voyade_session`	Rails’ own session cookie. Holds the cross-site request token that stops another site submitting a form as you, the “come back here after signing in” address, and one-off messages like “Reported — reference VOY-00000123”. Signed, `HttpOnly`, `SameSite=Lax`.	The browser session
`voyade_session`	Says which sign-in this browser belongs to. Signed and `HttpOnly`, so its contents cannot be read or forged by a script or by another site. The session it points at is what actually expires: 30 days, or 14 days without use.	The cookie is long-lived; the session behind it is not
`voyade_guests`	The tokens for trips you joined as a guest with a first name and no account, so those contributions are still yours before you sign up, and come with you when you do. Up to 20 of them. Signed, `HttpOnly`.	Until you sign up and they are adopted, or you clear it
`voyade_consent`	The answer you gave on the cookie-choices screen, so we can honour it and so we never ask you again. It holds four things: which version of the question you were asked, when you answered, whether you answered on the banner or in settings, and which optional categories you allowed. Deliberately not `HttpOnly` — see below.	12 months
Offline pack storage	Not a cookie: your cached day, your tickets and your map tiles held by the service worker so Travel mode works with no signal. Storage on your device that you asked for when you downloaded the pack.	Until the trip ends, or you clear it

SameSite=Lax rather than Strict throughout, and deliberately: an invite link arriving from WhatsApp is a cross-site navigation, and Strict would drop the guest cookie on exactly the tap the product is built around.

Why voyade_consent is readable by the page. Every other cookie we set is HttpOnly, which means a script on the page cannot see it. This one is not, and it is the only one. Our public pages are cached — the feed, every trip page, every guide are served from a cache that has no idea who is reading them, which is most of the reason they load fast on a phone. That cache cannot decide whether to show you the cookie banner, because it does not know whether you have already answered. So your own browser decides, by reading this cookie. Making it readable is what lets the banner stay away from people who have already said no. There is nothing in it about you: a version number, a date, the word “banner” or “settings”, and the word “attribution” if you said yes.

Two more exist and you will never meet them unless you work here: an administrator session, scoped to /admin, which times out after 30 minutes idle, and a short-lived cookie recording that a support session is acting as a user, which the product shows as a banner the whole time it is set. Neither is ever set on an ordinary visit.

Optional — only with your consent

Name	What it does	How long
`voyade_creator_ref`	Remembers that you arrived through a specific creator’s share link or `/@handle` page, so that if you clone their trip and book something in the next 30 days, they earn their 70% share instead of their 30% one. It holds one thing: that creator’s public handle. Signed and `HttpOnly`.	30 days

That is the entire optional list. One cookie, on our own domain, holding a public username. It is not for us — it is the difference between a creator getting paid and not.

Built, as of 29 July 2026. Nothing is written to this cookie until somebody has answered the question in §6. Not on arrival, not “while you decide”, not on the second page. If you have not answered, or you said no, or your browser sent Global Privacy Control, the creator’s link still works and their trip still clones — the booking simply earns them the Voyade-brought rate instead of the creator-brought one, which is stated in the creator terms §5.1 so that creators know it too. If you are reading this on a live site and were never asked, that is a bug we want to hear about: [email protected].

What we never set

No advertising cookies. No conversion pixels. No Meta, Google Ads, TikTok or LinkedIn tags. No third-party analytics — not Google Analytics, not anything. No fingerprinting, no session recording, no heat maps, no cross-device graph, no data brokers.

Sentry, our error monitor, runs in the browser but sets no cookies. It sends us a stack trace when something breaks, along with your IP address and browser version. It is configured to strip cookies, request bodies, query strings and authorisation headers before anything leaves your browser, and to blank the token out of any link that carries one. That is covered in the privacy policy §3.11.

To confirm before publishing. If a CDN sits in front of the public pages at launch, it will set a bot-management cookie on our own domain — typically for under an hour, holding nothing about you beyond “this request came from a browser rather than a script”. It is strictly necessary and it goes in the table above by name, once the answer is settled. Today the public pages are served without one.

3. How our own affiliate tracking works — the honest version

There are two separate things going on, and they have different privacy consequences.

The click token — no cookie, no consent

When you tap “Book →” on a booking task, we do this:

We generate a random click identifier. It means nothing on its own.
We record it on our server, against the trip and the task it came from, and against the creator whose template that trip was cloned from.
We put the identifier into the outbound link, alongside our partner code, and send you to the partner.
Days or weeks later, if you booked, the partner’s network sends us a postback: that identifier, an amount, a currency, and a status. That is how we know a commission is owed and to whom.

Note what does not happen. We do not store the click token on your device. It travels in the URL and lives in our database. Nothing is written to or read from your browser, so this is not something EU cookie law asks us to get consent for — it is a server-side record, and we keep it because we have a legitimate interest in being paid and in paying creators correctly. You can object to it: [email protected].

Note also what we send the partner: an anonymous identifier and our partner code. Not your name, not your email, not your payment details, not your trip, not who else is on it.

The 30-day attribution memory — this one needs a cookie

The click token covers the moment you book. Creator attribution is a longer story: a creator’s audience finds them on Instagram, arrives at voyade.com/@maya/azores-week, looks around, comes back three days later on the same laptop and clones the trip, and books a hotel a fortnight after that. For Maya to be paid the 70% rate, something has to remember that she brought you.

If you are signed in, that something is your account. We stamp the attribution on the trip when you clone it, server-side, and it sticks for that trip’s life. No cookie involved.

If you are not signed in, the only place to remember it is your browser. That is what the optional attribution cookie is: a creator handle and a date, on our own domain, for 30 days.

If you decline it, or you have not answered yet: we store nothing, and we read nothing. Maya’s link still opens her trip, you can still clone it, and she still earns from it — because it is still her template. What changes is the rate: the clone is stamped Voyade-brought, so she earns 30% of our commission on it rather than 70%, for the life of that trip. That is the whole consequence, it is the only consequence, and it is written into the creator terms §5.1 so creators are told the same thing you are.

Nothing else in the product changes — same feed, same trips, same suggestions, same order, same prices, nothing withheld, nothing degraded.

We are deliberately not doing the clever thing here. We could hold the attribution in your session for the length of your visit and argue that a session cookie is different. It is not different: it is still storage on your device, for a purpose the service does not need, and the law is about the purpose rather than the container. So a refusal means we remember nothing at all.

We think this is a fair thing to ask for once, clearly, and then never mention again.

4. What the partners set — and why the windows are so different

The moment you land on a partner’s site, you are their visitor. They set their own cookies, under their own privacy policy, subject to their own consent banner. We cannot set, read, or delete them, and we have no visibility into them.

Their attribution windows vary enormously, and that difference is real enough that it shapes how this product is designed:

Partner	How long their attribution lasts
Booking.com	The browser session only. If you close the tab and come back tomorrow, the link no longer counts.
Agoda	About a day
Expedia	About 7 days
Viator, Tiqets, GetYourGuide, Hostelworld	About 30 days
Travelpayouts (flights)	Varies by airline and agency
Discover Cars	365 days

We are telling you this for two reasons. First, because it is the honest answer to “what happens when I click that link”. Second, because it explains a design choice you may notice: hotel links appear at the moment you are actually ready to book, inside a claimed task, rather than scattered through the planning phase — because a Booking.com link clicked three weeks early is worth nothing to anyone.

Those windows are the partners’ terms as we understood them at the time of writing, and partners change them. Check their own pages for the current answer.

5. Sign-in, maps and embedded things

Sign in with Apple / Sign in with Google: if you use them, those companies set their own cookies during sign-in, under their policies. Use a magic link instead if you would rather they did not.
Maps: our maps use MapLibre with vector tiles we serve ourselves. There is no Google Maps embed sitting on your session.
Photography: destination images come from Unsplash and Pexels through our own servers and cache, not through their scripts. They receive a search term, never you.
Push notifications: if you allow them, your browser registers with its own push service (Apple, Google or Mozilla, depending on your browser). We store the resulting subscription; the routing is your browser vendor’s, not ours.

6. The consent flow: what we promise, and what it looks like

The rule is simple. Refusing must be exactly as easy as accepting. Everything below follows from that, and all of it is built — you can go and look.

“No thanks” and “Yes, remember it” are the same size, the same weight, the same colour, side by side, on the first screen. They are literally rendered from one list with one shared style, so they cannot drift apart into a bright yes and a grey no. “No thanks” comes first. No greyed-out decline, and no “Manage preferences” maze standing in for “no”.
One tap either way. Accepting is one tap. Refusing is one tap. Changing your mind later is one tap. Turning it back on is one tap. There is no direction in which the answer we would prefer costs you fewer taps than the one we would not.
Nothing optional is on by default. There is nothing pre-ticked, because there is nothing ticked at all — the banner is two buttons, and until you answer, the choices screen marks neither Yes nor No, because you have not chosen either. It says in words that nothing is stored, which is the true statement; painting “No” as your answer would be claiming a choice you never made. No “legitimate interest” tab quietly switched on behind a second click.
Nothing is stored before you answer. Not while you decide, not on the second page, not “for the duration of your visit”. Silence is not consent here and never becomes it.
No cookie wall. Declining never blocks the feed, a template, a guide or your own trip. There is no “accept to continue”.
No nagging. If you decline, we remember it and we do not ask again for 12 months, or until something material changes about what we would store.
No confirm-shaming. The decline button says “No thanks”. It does not say “No, I don’t want creators to get paid”.
No countdown, no urgency, no interstitial. The banner sits at the bottom of the page, over nothing you were reading, and it never covers the page.
Withdrawing is one tap, at Cookie choices — linked from the footer of every page and from Settings → Privacy — and it is exactly as prominent as the original accept was. Withdrawing also deletes the cookie, on the spot, rather than only revoking the permission.
You can start over. “Forget my answer” on the same screen erases the record and puts the question back, if you would rather decide again from scratch.

One honest note about how it appears. The banner is delivered on every page but stays hidden until your own browser has checked whether you have already answered. If you have JavaScript switched off it therefore never appears at all — and nothing optional is ever stored either, which is the safe way round. The Cookie choices page works with no JavaScript at all, and the footer link to it is on every page.

If you ever see a consent screen from us that breaks one of these, that is a bug and we would like to know: [email protected].

7. Managing it yourself

In Voyade: Cookie choices, linked from the footer of every page and from Settings → Privacy. One tap, as often as you like, in either direction, and exactly as prominent as accepting was.
In your browser: every browser lets you block or clear cookies for a site. Blocking the strictly necessary ones will sign you out and break the offline pack; everything else will keep working. Nothing we set is readable by another website.
Global Privacy Control. If your browser sends Sec-GPC: 1, we read it as a refusal of anything optional. Nothing is stored, and you are not shown the banner, because you have already answered. The Cookie choices page tells you we saw it, and still lets you say yes on purpose if you would rather — an explicit answer from you is more recent and more specific than a setting in your browser, so it wins.
Do Not Track. We deliberately do not read DNT: 1, and we would rather explain why than quietly ignore it. It is deprecated, and several browsers and privacy extensions send it by default. A header that is on by default cannot be told apart from a preference somebody actually expressed — so if we treated it as an answer, we would be hiding the question from people who never chose anything, which takes your choice away rather than protecting it. GPC is different: it exists for exactly this, and a person has to turn it on.

It costs you nothing either way. With DNT: 1 and no answer from you, we still store nothing — you simply get asked.

8. Changes

If we ever add a cookie, this page is updated first and your consent is asked again before anything new is set. Material changes get 30 days’ notice in-app.

Change log

Date What changed

2026-07-29 The consent flow described in §6 is built, and this page is rewritten against it rather than against a specification. §2: voyade_consent added to the strictly-necessary table by name, with an explanation of why it is the one cookie a script on the page can read; the “not yet true” warning on the attribution cookie replaced with what the code now does. §3: the decline case rewritten — declining now means nothing is stored at all, including in the session, and the consequence is stated as the Voyade-brought rate, matching creator terms §5.1. §6: rewritten as a description with the one-tap-either-way property, the nothing-before-an-answer rule and the no-JavaScript case stated. §7: GPC is honoured and DNT is deliberately not, with the reasoning in full. Front matter: added the one remaining gap — the consent record lives only on the user’s device, so a refusal is enforceable but a consent is not demonstrable under GDPR Art. 7(1).

2026-07-28 First draft. Not yet in force. §2 rewritten against the cookies the code actually sets, by name: two cookies removed that were described but never existed (a stored cookie choice, and locale/currency preferences — both are account settings, not cookies), the Rails session cookie and the two administrator cookies added, and the CDN row moved to a to-confirm note. §2 and §6 now state out loud that the consent flow does not exist yet and that the optional attribution cookie is currently set without asking, which this page does not permit.

Date	What changed
2026-07-29	The consent flow described in §6 is built, and this page is rewritten against it rather than against a specification. §2: `voyade_consent` added to the strictly-necessary table by name, with an explanation of why it is the one cookie a script on the page can read; the “not yet true” warning on the attribution cookie replaced with what the code now does. §3: the decline case rewritten — declining now means nothing is stored at all, including in the session, and the consequence is stated as the Voyade-brought rate, matching creator terms §5.1. §6: rewritten as a description with the one-tap-either-way property, the nothing-before-an-answer rule and the no-JavaScript case stated. §7: GPC is honoured and `DNT` is deliberately not, with the reasoning in full. Front matter: added the one remaining gap — the consent record lives only on the user’s device, so a refusal is enforceable but a consent is not demonstrable under GDPR Art. 7(1).
2026-07-28	First draft. Not yet in force. §2 rewritten against the cookies the code actually sets, by name: two cookies removed that were described but never existed (a stored cookie choice, and locale/currency preferences — both are account settings, not cookies), the Rails session cookie and the two administrator cookies added, and the CDN row moved to a to-confirm note. §2 and §6 now state out loud that the consent flow does not exist yet and that the optional attribution cookie is currently set without asking, which this page does not permit.