Cookie Policy and Consent Management (Consent Mode)

In Brief

A cookie policy and consent management setup is what makes a site obtain permission before writing data to a visitor's browser or using that data for measurement or marketing, record that permission, and switch tags on and off according to it. Two separate jobs get confused here: one is the legal side — explaining in plain terms what you collect and obtaining consent; the other is the technical side — passing the consent you did or did not receive to advertising and analytics tools as a machine-readable signal. Consent Mode is the name of the second job, and it does not replace the first. As of 2026 the question is not "should we put up a consent banner" but "are we carrying the permission given and withheld into our measurement stack as the right signal".

Tuesday morning, 10.40. A cosmetics store's marketing team has two screens open side by side and the numbers do not agree. The ad platform shows 1,240 conversions for last month; the analytics tool shows 690 for the same period. The real order count in the order management screen is 1,310. For three weeks the team has been managing budget against the analytics figure, and has cut its best-performing campaign twice.

The cause was not an advertising error. A consent banner had been added to the site six months earlier; when "Reject" was clicked, the banner silenced every measurement tag completely and sent no signal at all. A significant share of visitors were rejecting, and orders from those visits appeared in no report. The ad platform partially compensated through its own modelling; the analytics tool did not compensate at all. The gap was not a measurement bug but a consent architecture bug: nobody had drawn the distinction between "send nothing" and "send an identity-free signal" when consent is absent.

1. What Is a Cookie and What Types Exist?

A cookie is a small text record a site stores in a visitor's browser, and the issue is never the record itself but the purpose it serves. Consent rules are built around purpose, not around technical structure, which is why classifying correctly is the first step of compliance.

Classification by purpose

Four groups are enough in practice, and your banner's categories should not exceed these four.

• Strictly necessary cookies: records required for the site to function that cannot be turned off — session ID, cart contents, security verification, language choice. Prior consent is not expected for these, but they still belong in the cookie policy.
• Functional cookies: records that improve the experience without being required — live chat tools, recently viewed products, video player preferences.
• Analytics cookies: records that measure visitor behaviour — session counts, page flow, conversion funnels. They are not needed for the site to work.
• Marketing cookies: records used for ad targeting, remarketing and ad measurement. These sit at the centre of the consent debate.

First-party versus third-party

A first-party cookie is written by your own domain, a third-party cookie by another. Browsers have been restricting third-party cookies for years, which is why many measurement tools moved to first-party records and server-side communication. But being technically first-party does not mean consent is unnecessary: a marketing record written on your own domain still carries a marketing purpose and falls under the same rule. Classify by asking "what is it used for", not "who writes it".

Storage methods that are not cookies

This is the most frequently skipped point in consent management: localStorage, sessionStorage, IndexedDB and pixel-based tracking are technically not cookies but serve the same purpose. A banner that only blocks document.cookie writes does not mean the site has actually gone quiet. Run the audit in the browser's developer tools storage tab after clicking "Reject"; every record that remains deserves an explanation.

Category	Typical example	Prior consent	Typical lifetime	Effect when disabled
Strictly necessary	Session, cart, security	Not required	Session - 1 year	Site does not work
Functional	Live chat, recently viewed	Required	1 month - 1 year	Experience degrades
Analytics	Session and funnel measurement	Required	1 day - 2 years	Reports lose coverage
Marketing	Remarketing, conversion	Required	1 - 24 months	Targeting and measurement narrow

2. Cookie Consent in Turkey: Which Framework Applies?

In Turkey the basis for cookie consent is personal data protection legislation, and in practice it produces two separate obligations: disclosure and explicit consent. What follows describes the mechanism; which cookie on your site rests on which legal basis is a separate assessment, and you should confirm the current state of your obligations with your own legal adviser.

Disclosure and consent are not the same thing

Disclosure means explaining what you collect, for what purpose, for how long and with whom you share it; consent is the visitor knowingly and freely agreeing to that. Having shown someone a text does not mean you obtained consent. The practical rule: disclosure is always required, consent is required for non-essential cookies. The short text on your banner summarises the disclosure; the detailed cookie policy page carries the whole of it.

What a cookie policy page is expected to contain

• Cookie inventory: name, category, purpose, retention period and third-party provider where applicable — as a table, not in general phrases.
• Purpose description: what each category concretely does; "to improve your experience" is not on its own an adequate statement of purpose.
• Transfer abroad: most advertising and analytics tools move data to servers outside the country, and stating this plainly is expected.
• How to withdraw consent: a permanent link or button where the visitor can change their decision. This is the item most often forgotten in practice.
• Last updated date: when the policy was last reviewed.

Storing the consent record

To be able to claim you obtained consent, you have to keep the record of it. The minimum to store: the date and time consent was given, which categories were approved, the version of the text shown, and how consent was collected. The version matters: when you change the policy, it is the only way to show that consent given to an older version does not cover new purposes. Electronic message permissions are a separate world from cookies and run through İYS; combining the two in a single checkbox is a common but ill-advised shortcut. We covered the personal data side as a whole in the KVKK compliance checklist.

3. How Should a Consent Banner Be Designed?

A valid consent banner is one that makes rejecting as easy as accepting and pre-ticks no category. Design here is not an aesthetic preference but part of compliance, because whether consent counts as "freely given" depends on how the banner is built.

Components of a valid banner

• Buttons of equal weight: "Accept all" and "Reject all" on the same screen with the same visual weight. Burying the reject option on a second screen is the most common banner mistake.
• Boxes that start unticked: every category other than strictly necessary begins unchecked. A pre-ticked box does not count as consent.
• Category-level choice: a visitor should be able to say yes to analytics and no to marketing.
• Understandable copy: two or three sentences without drowning in legal language; a link to the policy for detail.
• Permanent access: a fixed link — usually in the footer — that reopens the settings after a decision has been made.
• Blocking order: the relevant tags must not run before the decision. If tags fire first and the banner appears afterwards, the banner is decorative.

Dark patterns to avoid

Greying out the reject button while colouring the accept button, showing rejectors an extra confirmation screen, adding loaded warnings such as "the site may not work properly if you decline", and making the banner impossible to dismiss — all of these make the validity of the consent arguable. They also wear the visitor down: someone forced to decide twice usually leaves the site rather than accepting.

Effect on conversion, and the balance

A consent banner occupies part of the first screen, and on mobile it damages sales directly if it sits over the product image. Strike the balance with three decisions: show the banner immediately after load but position it so it does not cover the product image; shorten the copy; make the decision possible in one click. It also matters that the banner causes no layout shift, because that degrades a speed metric directly — we detailed the effect of first-screen behaviour on sales in our article on conversion rate.

Design decision	Compliant approach	Risky approach	Likely effect
Button hierarchy	Accept and Reject equal	Reject hidden or faded	Validity of consent arguable
Default state	All boxes unticked	Pre-ticked boxes	Does not count as consent
Tag order	Fire after the decision	Fire on page load	Processing without permission
Withdrawal	Permanent footer link	First visit only	Obligation left incomplete
Scope	Cookies + localStorage + pixels	Cookies only	Gap remains under audit

4. What Is Consent Mode and How Does It Work?

Consent Mode is a signal layer that communicates the visitor's consent decision to Google tags through standard parameters and makes those tags behave according to it. Instead of removing the tag entirely, it tells the tag to run without cookies and without identifiers when consent is absent, so that consent is respected and measurement does not go completely blind.

Signal parameters

There are seven parameters in practice, but four are critical in e-commerce.

• ad_storage: whether writing cookies for advertising purposes is permitted.
• analytics_storage: whether writing cookies for analytics purposes is permitted.
• ad_user_data: whether user data may be shared for advertising purposes.
• ad_personalization: whether data may be used for personalised advertising and remarketing.
• functionality_storage, personalization_storage, security_storage: the remaining three parameters, covering functionality, preference and security records.

The two latter advertising parameters — ad_user_data and ad_personalization — became mandatory with the current version. An older setup sending only ad_storage and analytics_storage produces an incomplete-setup warning in the ad platform and can stop remarketing lists from being fed. If your implementation dates from before 2023, this is the first thing to check.

Default state and update

The mechanism has two steps. As the page loads, a default state is declared: every parameter requiring consent starts as "denied". Once the visitor decides, an update is sent and the approved parameters become "granted". The critical point is the order: the default declaration must run before every measurement tag on the page. If the order is reversed, data leaves without permission in the first few hundred milliseconds, and this is the most frequently seen flaw in these setups.

Basic mode and advanced mode

There are two implementation styles, and the difference between them determines how much measurement you lose.

• Basic mode: the tag does not load at all until consent is given. This is the most conservative approach; no signal arrives from visitors who decline, and no data accumulates for conversion modelling.
• Advanced mode: the tag loads but, in the absence of consent, sends a cookieless, identity-free and aggregated signal. The ad platform can produce modelled conversions from those signals.

It is reasonable to question advanced mode because it looks like "collecting data without consent"; the distinction is that the signal sent carries no identifier and cannot be tied to a person. Which mode fits your data processing inventory is a legal decision, not a technical preference — settle that with your organisation's adviser.

What does modelled conversion mean?

Modelled conversion: estimating conversions from visitors who declined by looking at the behavioural pattern of visitors who consented. These figures are a statistical estimate, not a real measurement; they can be used to compare campaigns but not as an accounting record. This is usually the answer to why the conversion count in the ad panel does not match the number in the order management screen. Keeping those two numbers apart in campaign evaluation is the basis of reporting discipline on a site that has consent management in place.

Parameter	What it controls	Recommended default	Behaviour when denied
ad_storage	Advertising cookies	denied	No cookie written, identity-free signal
analytics_storage	Analytics cookies	denied	No session ID, aggregated measurement
ad_user_data	Data sharing for advertising	denied	User data is not transmitted
ad_personalization	Personalised advertising	denied	Not added to remarketing lists
security_storage	Security and fraud prevention	granted	Usually treated as necessary

5. Technical Setup: Tag Manager and Server Side

The technical core of consent management is binding every measurement tag to its own consent category and letting no tag fire before the decision. Building this through a tag manager rather than hand-writing it into individual tags gives you a structure that is both auditable and reversible.

Binding tags to categories

Produce an inventory of every tag on the site and assign each one a single category. The typical mapping: analytics measurement to analytics_storage, advertising pixels and conversion tags to ad_storage and ad_user_data, remarketing tags to ad_personalization, live chat and recommendation tools to the functional category. If a tag cannot be assigned a category, why it is on the site at all is a separate question — the answer is usually "nobody remembered to remove it", and removing it helps both compliance and speed.

Server-side tagging

Server-side tagging: sending measurement data not straight from the browser to the ad platform but first to a server under your control, and forwarding it from there. The benefit is that you decide which field reaches whose server, you are less affected by browser restrictions, and you reduce third-party script weight on the page. It does not remove the consent obligation: sending data from your own server does not mean consent is unnecessary. A server-side setup requires carrying the consent signal to the server too; otherwise the banner works on the front end while data keeps flowing in the background. We gathered the infrastructure side of such flows on the integration options page.

Platforms other than Google

Consent Mode is a Google standard; tags from Meta, TikTok and other platforms do not listen to these parameters on their own. There are two routes for them: fire the tag conditionally through a trigger bound to a consent category, or populate the platform's own consent-aware field (for example Meta's limited data use flag). Installing a single consent management tool and assuming "everything is handled" is where audits most often find a gap. For teams splitting budget across two platforms this double setup is mandatory; a consent signal that works on one platform means nothing on the other.

Verifying the setup

Verification has three steps and should be repeated after every release. First: open the site in a private window and, before making any decision, watch the network tab in developer tools — if a measurement request goes out, the order is wrong. Second: click "Reject all" and check the storage tab; nothing beyond strictly necessary records should remain. Third: click "Accept" and repeat the same checks, confirming the expected tags really do fire. These three checks take ten minutes and catch most implementation errors.

6. Managing the Measurement Loss

When consent management goes live the numbers in your reports drop, and that is not a malfunction; the real work is building a measurement discipline that lets you decide correctly with the data that remains. Treating the drop as a bug and weakening the banner to fix it increases compliance risk and does not fix the data.

Measuring the consent rate

You cannot manage what you do not measure, so the first report to build is the consent rate. Record the consent decision itself as an event, by category: accepted, partially accepted, rejected, and left without deciding. Those four numbers both explain the shortfall in your reports and let you measure the effect of changes to the banner copy. The record itself can be kept aggregated, without being tied to a person.

Moving toward first-party data

As consent-dependent measurement narrows, the data you own becomes more valuable. Three sources remain in practice and all three are yours: order records, the email list and member accounts. Judging channel performance against real revenue in the order record rather than only the ad panel is the method least affected by consent loss. We described how to read the gap between analytics figures and the order record regularly in our article on analysing analytics data.

Keeping comparisons inside one period

The day you launch the consent banner, all your historical comparisons break. Write that date into the change log and compare the post-launch period only against itself. Comparing the launch month with the same month a year earlier and concluding "traffic fell" is the trap teams fall into most often: what fell is not the traffic, it is the measured traffic.

Building Consent Management in Thirty Days

Thirty days is enough to produce the inventory, build the banner correctly, wire up the signal and re-interpret the measurement. The order matters: a banner built without an inventory is a banner that does not know what it is blocking.

Days 1-7: inventory and diagnosis

Open the site in a private window and, without making any decision, list every cookie written, every localStorage record and every outgoing network request. Fill three columns for each line: who writes it, for what purpose, which category it falls into. In the same week, compare your existing cookie policy text against that list; usually three to five items turn up that are on the list but not in the text. Nothing is changed this week.

Days 8-14: banner and policy text

Build the banner with equal-weight buttons, unticked defaults and category-level choice. Produce the cookie policy page from the inventory — put the real list into a table instead of copying a generic template. Add a permanent "Cookie settings" link to the footer. Decide this week where the consent record will be stored and with which fields.

Days 15-21: signal and tag binding

Place the default consent state so that it runs before every measurement tag, make sure all four parameters are sent, and bind each tag to its own category. Move non-Google platform tags onto conditional triggers. Close the week with the three-step verification and save the results as screenshots; that record will serve you in later audits.

Days 22-30: measurement and continuity

Build the consent rate report, write the launch date into the change log, and rework campaign evaluation so that it runs off the order record. Leave a quarterly review reminder: when a new tool is added the inventory has to be updated, and that does not happen by itself. Tie the cookie policy's last-updated date to the same reminder; when the inventory changes, the policy has to change with it.

Here is the job for tomorrow morning: open the site in a private window and, without touching the consent banner, look at the storage and network tabs in developer tools. Every cookie written and every measurement request sent before a decision was made is proof that your banner is currently decorative; pulling that list takes half an hour and tells you on its own where consent management should start. On an e-commerce platform where the banner, policy page and tag management come together at template level, most of this list is already in place.

Frequently Asked Questions

Is obtaining cookie consent mandatory?

Prior consent is expected for cookies that are not required for the site to function; records such as session and cart are not subject to prior consent but still need to be explained in the cookie policy. Which record on your site falls into which group depends on your data processing inventory, and it is right to settle that distinction with your legal adviser.

Once Consent Mode is installed, do I still need a consent banner?

Yes — the two do not replace one another. Consent Mode does not collect consent, it only reports collected consent to the tags. What collects and records consent is the banner and the consent management tool behind it; Consent Mode is the layer that makes that decision machine-readable.

How much will my analytics data drop after adding a banner?

The size of the drop depends on your consent rate, your audience and the design of the banner, so quoting a fixed percentage would be wrong. The right approach is to mark the launch date, measure the consent rate by category, and make subsequent comparisons only against periods after that date. What falls is not real traffic but measurable traffic.

Is collecting nothing at all from rejectors safer?

It is the most conservative route for compliance, and basic mode does exactly that. The cost is that those visits stay completely invisible in measurement and no signal accumulates for conversion modelling. Advanced mode partially closes that gap with identity-free aggregated signals; which one suits you is a legal decision rather than a technical one.

Can I copy a cookie policy text from another site?

A copied text does not describe your actual cookie inventory, and that is the first thing noticed in an audit. The policy must be produced from the list of records genuinely written on your site. Working from an example for structure is possible, but the inventory table has to be filled with your own site's real data.

I use localStorage, not cookies — is consent required?

If the purpose is the same, the treatment is the same: localStorage, sessionStorage, IndexedDB and pixel-based tracking fall within scope when they serve a marketing or analytics purpose. "It is technically not a cookie" is no defence in a purpose-based assessment. Run your audit against all storage and network traffic, not against a cookie list.

What should happen if a visitor withdraws consent?

Withdrawing must be at least as easy as giving: a permanent footer link should reopen the settings, the new decision should be recorded, the relevant cookies deleted, and the tags silenced from that session onward. Showing the change only on the front end without updating the record is the most common omission.

Does a consent banner hurt SEO?

It does indirect harm when it is built as a layer that covers the content and when it causes layout shift, because that degrades page experience metrics. For a banner that hides no content, has fixed dimensions and loads fast, no such problem is expected. Test the banner design as part of your page speed checks.

Is İYS permission the same as cookie consent?

No. Cookie consent concerns data processing in the browser; İYS permission is for sending commercial electronic messages and runs through a separate system. Combining the two in one checkbox makes the validity of both arguable. Collect them separately in forms, each with its own text.

How often should I review consent management?

Review the inventory quarterly, and additionally whenever a new tool, theme update or integration is added. In practice the most common leak comes from a new pixel the marketing team added without telling anyone about the consent inventory; so build the question "which category is it" into your process for adding any new tool.