What actually sits on your device

Local storage versus a cookie

A cookie rides along with every request your browser makes to a site, sent back and forth automatically. Local storage sits still: the browser keeps it, but nothing is transmitted unless a script on that page deliberately reads it and does something with it. Functionally close enough that both get covered on one page, since what matters to you is what is stored, not the specific shelf it sits on.

Both keys are set by this site and nothing else. The wtdim prefix on each is left over from the shared codebase this site was built on top of rather than anything chosen for this domain, and it changes nothing practical: storage is locked to the site that wrote it, so no other address can read either value regardless of what it happens to be named.

What happens, start to finish, before you touch the banner

Nothing measurement-related exists on the page at load time. No script tag pointed at Google is present, and no request toward Google has been made. With no stored answer yet, the banner appears, and Decline sits next to Accept at identical size and weight, with neither highlighted as the assumed choice and no way to close the banner into a default yes.

Pick Decline, and denied is written straight away; the banner closes and stays closed. Ignore it completely, and functionally nothing changes this visit, except your answer is not remembered, so the banner is back the next time you arrive. Pick Accept, and four things happen in this exact sequence: advertising storage, advertising personalisation and advertising user data are all told to stay denied, analytics storage alone flips to granted, and only then does the page reach for Google's script, set to truncate your IP address before anything is logged. Advertising permissions are never switched on through any of these paths.

There is a second layer worth spelling out, because most sites running this kind of banner do not need to: right now, no analytics account is actually connected to this domain, so an accept records your choice and stops there, no script fetched, nothing sent anywhere. Once an account is wired up, whichever answer you gave last, granted or denied, takes effect from your next page load without the banner asking again.

What would get set once an account exists

Only Google Analytics, nothing wider. These are the two cookies it would place:

The exception the banner does not cover

Every option inside a booking panel shows the partner's own product photo, and that image is fetched from the partner's own server rather than stored on ours. Today, all 41 of them, one for each bookable Tiqets option currently on the site, come from a single address: aws-tiqets-cdn.imgix.net. Klook and KKday's current listings have no photo of their own attached, and there is no live WeGoTrip product on this site yet, which is the entire reason none of those three hosts sees a request today. Add a photo to any of their products later and the same thing would happen from their own server instead.

These images are set to load lazily, meaning the request fires the instant the panel scrolls into your view rather than when you click anything, and it fires whether you accepted, declined or ignored the banner entirely. That is a plain image request, and a plain image request hands the receiving server your IP address, your browser's identifying string, and the page you were reading, and its response is free to set a cookie of its own back on its own domain. None of it comes back to us. Calling this a site where "nothing loads before you click" would simply be false, so this page does not say it.

These are not copied onto our own server because they are not ours to copy: they belong to whichever partner's product they illustrate, licensed for exactly this kind of use and nothing broader. A content blocker or images disabled stops the requests outright, and every booking link keeps working regardless.

What happens once you actually click through

A tracked link routes first through Travelpayouts, which logs the click and passes you straight on to whichever of Tiqets, Klook, KKday or WeGoTrip the link pointed at. From there, anything placed on your device to attribute a later booking is placed by that company, on their own domain, under their own rules, once you have already arrived. This site writes nothing to your device at that point or beforehand, aside from the product photo covered above. More on the arrangement itself on the affiliate disclosure.

Reversing a decision

• Every footer carries a Cookie settings link that brings the banner back regardless of your earlier answer. A new decline takes effect instantly, reaching a running tag immediately rather than waiting for a page refresh.
• What it cannot touch is a Google cookie already set during a previous visit where you had accepted; that lives under Google's own domain, and only your browser's own controls remove it. Worth saying plainly rather than implying a reach this page does not have.
• Clearing your browser's stored data wipes both keys at once, taking your starred beaches down with the banner reset.
• Browsers that block local storage outright, private windows especially, mean nothing gets remembered and the banner shows up every time, but measurement also never loads. That failure mode leans in your favour.
• Declining changes nothing you can read on the site. No page is thinner for it, and you will not be asked a second time in the same visit.

Everything this site does not do

Fonts ship from this domain's own server rather than a third-party font service, so opening a page here exposes you to our host and nobody else on that front. There is no ad network anywhere, no embedded video player, no share buttons, no comments section, no chat widget. Set against all of that, the partner photographs are the one deliberate exception, images tied to something you can actually book rather than anything built to watch you.

Anything else

Ask at admin@whattodoinmalta.com, or read the broader privacy policy for the fuller picture.