Cookies and ad pixels on a hotel website: what the KVKK guide asks

A cookie is a small file a website stores in the visitor's browser; an ad pixel is a tiny image or script that reports the visit to an advertising platform. Türkiye's data protection authority says any cookie that is not strictly necessary needs explicit consent before it is placed, unless another processing condition in Law No. 6698 applies. That rule reaches every part of a hotel website cookie policy, from the banner to the booking engine.

The booking page loads, and between the hero photo and the rate calendar several scripts start at once: an analytics tag, a retargeting pixel from an ad account nobody remembers opening, a chat widget, the booking engine's own session cookie. Ask three people in the hotel who put them there and you get three different answers. After reading this you will be able to sort which of those tags need consent, what your banner must actually offer, and how to build the one document that makes the rest possible: a complete inventory of every tag on the site.

What is the difference between a cookie and an ad pixel?#

A cookie is a small text file a site asks the browser to keep and send back on later requests, so the site recognises the same browser across pages and visits. An ad pixel is a tiny image or a short script on the page that reports the visit to an advertising platform, which can match it to an ad account or an audience.

The two overlap in practice. Many pixels set their own cookies, so a single entry in the page can be both a cookie and a pixel at once. This is why a hotel website cookie policy cannot stop at the list of cookies: the scripts that carry them matter too.

The reference document is the Personal Data Protection Authority's Guide on Cookie Practices (opens in a new tab) (Çerez Uygulamaları Hakkında Rehber, KVKK Publications No. 69, updated July 2025). It is a set of practical recommendations for any data controller that runs a website, which includes every hotel with a booking page.

The guide's scope is narrower than the problem. It covers only cookies used to process personal data, and it states plainly that it gives no guidance on similar technologies such as pixels, user fingerprinting, local storage or beacons. The gap is not permission: a pixel that processes personal data still needs a lawful condition under Law No. 6698. The guide simply does not tell you which one. So the guide is the checklist for the cookie layer, and the hotel's own inventory has to cover everything else on the page.

Both mechanisms identify a browser rather than a named person, and that thread is personal data. The browser is the thread that ties a visit, a retargeting audience and a later booking together.

Which cookies need explicit consent under the KVKK guide?#

Only two kinds escape explicit consent: cookies used solely to carry out communication over an electronic communications network, and cookies strictly necessary for an information society service the visitor has explicitly requested. Anything that meets neither needs explicit consent, unless another processing condition in Articles 5 and 6 of Law No. 6698 applies.

The guide names the cookies it treats as not needing explicit consent: user-input, authentication, user-centric security, multimedia-player session, load-balancing, interface customisation, social plug-in content sharing, consent management and website security cookies. First-party analytics cookies sit in a different group, legitimate interest: they also fall outside explicit consent, but only on conditions, namely anonymous statistics, no cross-site tracking, IP masking recommended, a reasonable lifetime, and no transfer to third parties. For cookies processed under legitimate interest, you do not need explicit consent, but you must give visitors a clear way to object to this processing.

Two of these carry a caveat. Authentication cookies count as session cookies, but persistent cookies that keep a user logged in between browser sessions fall outside the strictly-necessary ground; the guide suggests a "remember me" box instead. Social plug-in content-sharing cookies qualify only for visitors already logged into that social network; for non-members and logged-out users, the guide recommends obtaining consent.

Social plug-in tracking cookies and online behavioural advertising cookies need explicit consent. The guide lists advertising purposes explicitly: frequency capping, financial logging, ad affiliation, click-fraud detection, research and market analysis, product development and debugging. If a tag on your site serves any of those, it belongs in the consent layer.

The guide is guidance, not statute. The duty comes from Law No. 6698, so confirm how it applies to your own site with a lawyer before you rewrite anything. For the wider consent and notice duties beyond the website layer, see KVKK for hotels: notices, consent, staff access and retention.

What makes a cookie banner's choices real?#

A banner works when every choice it offers is specific, informed, freely given, made by an active affirmative act before any cookie is placed, and as easy to withdraw as to give. Anything less is a record of a click, not consent.

Consent must be specific. It has to state the cookie's purpose, its duration and whether it is first-party or third-party. One "accept all" button covering a dozen different purposes does not meet that test. Entering the site is not consent, and neither is a pre-ticked box; the act must come before the cookie is placed.

The guide gives a good-practice example: a panel on entry with accept, reject and preferences buttons of equal colour, size and font, and cookies that need consent switched off by default. Consent for advertising cookies cannot be bundled into terms of use or a privacy notice, and it cannot be made a precondition of using the site. The guide notes that a cookie wall may make consent invalid.

Withdrawal must be easy, for example through an icon or a small band that stays reachable after the first visit. Keep a record of what each visitor chose, when, and which version of the banner they saw. That record is what lets you show the choice was specific and informed if anyone asks later.

How do you inventory every tag on the hotel website?#

List every script and cookie on the site, with its supplier, purpose, lifetime and the person who can remove it. You cannot obtain specific consent for tags you cannot name, so the inventory comes before the banner, not after it.

Tags arrive from many directions: the site build, the advertising agency, the booking engine embedded in the page, chat and review widgets, map embeds, a tag container that loads other scripts, and accounts opened by staff who have since left. Nobody plans this sprawl; it accumulates one campaign at a time.

Find them by opening the live site in a browser and using the developer tools, the panel that lists what the page has stored. Repeat the check on the booking path and the confirmation page, not only the home page, because the booking engine sets its own tags inside its own frames. Ask every supplier in writing for the cookies and similar technologies their product sets, with purpose and lifetime, and put that list into the contract rather than an email thread. Where third-party cookies are placed, both the hotel and the third party must inform visitors and obtain consent, so a supplier's silence is not a defence.

Record per tag: name, supplier, purpose, first or third party, lifetime, consent category, which account owns it and who holds the password to remove it. Re-run the inventory when the site is rebuilt, when a campaign ends, and once a year. Most drift comes from a campaign that was never switched off. If you are commissioning a new site, bake this into the supplier contract from the start, as covered in commissioning a hotel website and the hotel website checklist.

What must the cookie notice say, and how is it different from consent?#

The notice explains, the consent authorises. The notice tells the visitor who controls the data, what is collected, why, for how long, whether it reaches third parties and which condition under Law No. 6698 is relied on; consent is the separate act that allows anything beyond the strictly necessary.

For cookies specifically, the notice has to carry purpose, duration and first or third party for each category, plus how a visitor withdraws a choice already made. A notice that lists categories but never names the supplier leaves the visitor unable to understand who receives the data. The booking engine is a supplier in its own right and may set session and analytics cookies inside the booking path; those belong in the same inventory and the same notice as the marketing tags.

Marketing messages are a separate duty. If cookie data feeds an email or message campaign, the rules on electronic commercial messages apply on top of the cookie rules; see marketing messages to hotel guests. Keep the notice and the banner in step: a banner offering three categories while the notice describes seven is a sign that one of them was never updated.

For the notice itself, the section-by-section template in hotel privacy notice under KVKK is the companion piece to this article.

What happens to ads and retargeting when a visitor refuses consent?#

The advertising cookies do not run, so no retargeting audience can be built from that visitor. A banner that records a refusal and still fires the pixel is a false choice, and it undermines the consent of everyone who accepted.

Test the refusal path yourself: refuse everything, then check whether the advertising tags still load on the next page. It is a failure worth testing for on every hotel site. Without consent there are no online behavioural advertising cookies, which removes frequency capping, ad affiliation and audience building for that visitor.

What remains is legitimate: contextual advertising placed by page content, first-party anonymous statistics inside the guide's conditions, search, and the hotel's own booking content. Withdrawal has to travel: when a visitor withdraws, the tag should stop on the next page load, and any audience segment built from that browser should be updated or removed.

If a pixel has been running without a valid basis, stop it first, write down what ran and for how long, and take advice before deciding what else to do. Confirm dates, penalties and your own situation with a lawyer or your data protection adviser. The guide sets out recommendations; it is not a penalty schedule.

What to do next#

Build the tag inventory this week, before touching the banner: one list of every cookie and pixel, its supplier, purpose, lifetime and the person who can switch it off. Then rewrite the banner so refusal is real, align the notice with it, and take the whole set to your lawyer. The guide recommends and the law obliges, and only your adviser can tell you where your own site stands.