Why Cookie Categories Matter
Under GDPR and PECR, not all cookies are treated equally. Some cookies are essential for your website to function and can be set without consent. Others require explicit, informed user agreement before they can be placed.
Correctly categorizing your cookies is not just a legal requirement — it directly affects your consent banner design, your cookie policy, and your exposure to regulatory fines. Miscategorizing a marketing cookie as 'necessary' is one of the most common (and most fined) GDPR violations.
Necessary / Strictly Essential Cookies
Strictly necessary cookies are those that are absolutely essential for the website to function. They cannot be switched off in your consent banner because without them, basic functionality (logins, shopping carts, security) would break.
Examples:
- Session cookies: Keep users logged in as they navigate between pages
- Shopping cart cookies: Remember items added to cart
- CSRF tokens: Protect against cross-site request forgery attacks
- Load balancer cookies: Route requests to the correct server
- Cookie consent preferences: Remember the user's own consent choice (meta!)
The test: If removing this cookie would make part of the site stop working for the user, it is likely strictly necessary.
| Cookie Name | Vendor | Purpose | Retention |
|---|---|---|---|
| PHPSESSID / JSESSIONID | Your website | Maintains user session state across page requests | Session |
| XSRF-TOKEN / _csrf | Your website | Prevents cross-site request forgery (CSRF) attacks | Session |
| cookiebeam_consent | CookieBeam | Stores the user's cookie consent preferences | 12 months |
| stripe_sid | Stripe | Required for payment processing fraud prevention | 30 minutes |
Analytics / Performance Cookies
Analytics cookies collect information about how visitors use a website — which pages they visit, how long they stay, where they came from. This data is used to improve the website's performance and content.
Despite the name, analytics cookies are not strictly necessary under GDPR, because the website functions perfectly without them. They require explicit opt-in consent from EU users.
Examples:
- _ga, _ga_XXXXXX: Google Analytics 4 — user and session tracking
- _hjSession: Hotjar — session recording and heatmaps
- clarity_s: Microsoft Clarity — user session recording
- _clck, _clsk: Microsoft Clarity click and session IDs
| Cookie Name | Vendor | Purpose | Retention |
|---|---|---|---|
| _ga | Google Analytics 4 | Distinguishes unique users by assigning a randomly generated number as a client identifier | 2 years |
| _ga_XXXXXX | Google Analytics 4 | Stores and counts page views for the specific GA4 property | 2 years |
| _hjSession_XXXXXX | Hotjar | Holds current session data. Ensures subsequent requests within the session window are attributed to the same session. | 30 minutes |
| clarity-s | Microsoft Clarity | Sets a unique ID for the session. Allows the website to obtain data on visitor behaviour for statistical purposes. | 1 day |
| _clck | Microsoft Clarity | Persists the Clarity User ID and preferences unique to that site | 1 year |
Marketing / Advertising Cookies
Marketing cookies track users across websites to build a profile of their interests and serve them relevant advertising. These are the most privacy-invasive cookies and are subject to the strictest rules under GDPR.
Examples:
- _fbp, _fbc: Meta/Facebook Pixel — tracks conversions and builds remarketing audiences
- _gcl_au, _gcl_aw: Google Ads conversion tracking and remarketing
- IDE, DSID: Google DoubleClick Display advertising targeting
- muc_ads: Twitter/X advertising tracking
- li_fat_id: LinkedIn Insight Tag — LinkedIn ad attribution
These cookies typically involve sharing user data with third-party advertising networks, making them among the most heavily scrutinised under GDPR's data minimisation and purpose limitation principles.
| Cookie Name | Vendor | Purpose | Retention |
|---|---|---|---|
| _fbp | Meta (Facebook) | Used by Facebook to deliver a series of advertisement products such as real-time bidding from third-party advertisers | 90 days |
| _fbc | Meta (Facebook) | Stores the Facebook click ID used to attribute conversions to specific Facebook ad clicks | 90 days |
| _gcl_au | Google Ads | Used by Google AdSense for experimenting with advertisement efficiency across websites | 90 days |
| IDE | Google DoubleClick | Used by Google DoubleClick to register and report the user's actions after viewing or clicking one of the advertiser's ads | 13 months |
| li_fat_id | Member indirect identifier for Members for conversion tracking, retargeting, and analytics | 30 days |
Preference / Functional Cookies
Preference cookies (also called functional cookies) enable a website to remember information that changes the way the site behaves or looks — such as the user's preferred language, region, or display settings.
Whether these require consent is nuanced. If the preference directly serves the user (e.g. language setting they chose) with no third-party data sharing, some regulators consider them closer to necessary. However, best practice and most CMPs include them as an opt-in category.
Examples:
- Language and locale preference cookies
- Theme (dark mode/light mode) preference storage
- Saved search filters or display settings
- Region and currency preferences on e-commerce sites
Common Miscategorization Mistakes
- Google Analytics as 'necessary': GA is analytics, not necessary. Many companies got fined for this categorization.
- Facebook Pixel as 'analytics': It is a marketing/advertising tool. Categorizing it as analytics understates its invasiveness and misleads users.
- Consent cookie itself: The cookie that stores the user's consent choice (e.g.
cookiebeam_consent) is itself necessary — without it, you'd ask for consent on every page view.
Audit Your Cookies with CookieBeam
CookieBeam includes a cookie scanner that automatically detects all cookies set by your website and suggests categorizations. Run a scan from the dashboard to generate a compliant cookie policy and ensure no cookies are miscategorized or undisclosed.
Preference / Functional Cookies: The Often-Forgotten Category
Preference cookies — sometimes called functional cookies — are one of the most misunderstood cookie categories. Unlike strictly necessary cookies, they are not required for the site to function at a basic level. Instead, they remember choices you have made to personalise your experience: your preferred language, your chosen display currency, your colour scheme or dark mode preference, and similar settings.
Under the GDPR and ePrivacy Directive, preference cookies that go beyond what is strictly necessary to provide the service require prior, freely-given consent. Many website owners incorrectly classify preference cookies as necessary because they relate to site functionality. The key legal test is: could the website still be delivered without this cookie? If the answer is yes, consent is required.
CookieBeam automatically places preference cookies in the Functional consent category, meaning they are blocked until the user explicitly enables that category in your banner. This keeps you compliant with GDPR Article 6 and the ePrivacy Directive without any manual configuration.
| Cookie Name | Vendor | Purpose | Retention |
|---|---|---|---|
| locale | Stores the user's preferred language or locale (e.g. en-GB, de-DE) so the site renders in the correct language on return visits. | - | |
| currency | Remembers the user's preferred display currency (e.g. EUR, GBP, USD) in e-commerce stores. | - | |
| theme | Saves the user's light/dark mode preference so it persists across sessions without requiring a login. | - | |
| tz | Stores the user's detected or chosen timezone to display dates and times correctly. | - | |
| Intercom.io-user | Identifies returning users in the Intercom live chat widget and loads conversation history. | - | |
| CookieLawInfoConsent | Stores the consent record (CookieBeam uses its own consent token instead). If present, this is a consent-management cookie, classifiable as strictly necessary. | - |
Cookie Attributes Explained: HttpOnly, Secure, and SameSite
Every cookie that your server sets carries a set of optional attributes that control its security and accessibility. Understanding these attributes is essential for developers building GDPR-compliant websites, because insecure cookie configurations can expose user data and undermine the privacy guarantees you are making to your users.
When you conduct a cookie audit with CookieBeam's built-in scanner, these attributes are checked automatically and flagged where they represent a potential security or compliance risk.
| Attribute | What It Does | Security / Privacy Impact | Recommended Value |
|---|---|---|---|
| HttpOnly | Prevents JavaScript (document.cookie) from reading the cookie value. | Protects session tokens from Cross-Site Scripting (XSS) attacks. If a malicious script runs on your page, it cannot steal an HttpOnly cookie. | Set on all session and authentication cookies. |
| Secure | Instructs the browser to only transmit the cookie over HTTPS connections. | Prevents cookie interception via man-in-the-middle attacks on unencrypted HTTP connections. Required for any cookie containing sensitive data. | Always set on production cookies when the site runs on HTTPS. |
| SameSite=Strict | Cookie is only sent on requests originating from the same site — never on cross-site requests. | Strongest CSRF protection. May break OAuth/OpenID flows where a redirect from a third-party returns to your site. | Use for sensitive authenticated-only cookies where cross-site access is not needed. |
| SameSite=Lax | Cookie is sent on same-site requests and on top-level navigations from external sites (e.g. clicking a link). | Good balance of security and usability. Prevents most CSRF vectors while allowing normal browsing. | The recommended default for most cookies in modern browsers. |
| SameSite=None | Cookie is sent on all requests, including cross-origin requests from iframes and third-party embeds. | Required for third-party cookies (e.g. ad pixels, embedded widgets). Must be combined with Secure or browsers will reject it. | Use only when cross-site access is genuinely required, and always pair with Secure. |
| Expires / Max-Age | Controls how long the cookie persists. Without this, the cookie is a session cookie and deleted when the browser closes. | Long retention periods for tracking or analytics cookies can violate GDPR data minimisation principles. Supervisory authorities recommend retention periods proportionate to the purpose. | Set the shortest period that fulfils the legitimate purpose. Document the reason in your cookie policy. |
How to Audit Your Website's Cookies
A cookie audit is the process of discovering, categorising, and documenting every cookie your website sets. GDPR and the ePrivacy Directive require that you disclose all cookies used on your site in your cookie policy and obtain prior consent for non-essential cookies. An outdated or incomplete audit is one of the most common compliance failures identified by data protection authorities.
CookieBeam's automated cookie scanner performs this audit continuously — detecting new cookies as your site changes — but it is also valuable to know how to do a manual audit using browser developer tools.
Cookie Audit: Step-by-Step
Open your browser's Developer Tools
In Google Chrome or Microsoft Edge, press F12 or right-click anywhere on the page and select Inspect. Navigate to the Application tab (Chrome) or Storage tab (Firefox). Under the Cookies section in the left sidebar, you will see all cookies currently set for the domain you are viewing.
Visit every key page of your website
Different pages may trigger different cookies. Visit your homepage, a blog post, a product page, the checkout, and any page with a third-party embed (chat widget, video player, social share buttons). Note any new cookies that appear after navigating to each page.
Record all cookies in a spreadsheet
For each cookie, record: Name, Domain (first-party or third-party), Path, Expiry, HttpOnly, Secure, SameSite, and the Purpose. This spreadsheet becomes the source of truth for your cookie policy and your CookieBeam configuration.
Categorise each cookie
Assign each cookie to one of the four standard categories: Strictly Necessary, Functional/Preference, Analytics/Performance, or Marketing/Advertising. If you are unsure, use CookieBeam's cookie database — it recognises over 10,000 known cookies from 2,000+ vendors and categorises them automatically.
Update your cookie policy and CookieBeam configuration
Add any newly discovered cookies to your CookieBeam dashboard under the appropriate consent category. CookieBeam will auto-update your hosted cookie policy page to reflect the changes. For cookies that cannot be justified, consider removing the service that sets them — fewer cookies means a simpler consent UX and lower compliance risk.
Schedule quarterly re-audits
Cookie inventories change whenever you install a new plugin, update a theme, or change your analytics stack. CookieBeam's continuous scanner alerts you by email when a new unknown cookie is detected on your site so you can act immediately rather than discovering the gap during a regulator inspection.
Writing Your Cookie Policy: What to Include
A cookie policy is a legally required document — distinct from your privacy policy — that explains to your users exactly which cookies you use, what they do, how long they last, and what rights users have over them. Supervisory authorities under the GDPR and national ePrivacy laws regularly review cookie policies during investigations, so accuracy and completeness matter.
What Your Cookie Policy Must Cover
At minimum, a GDPR-compliant cookie policy should include:
- A plain-language explanation of what cookies are and how they work.
- A categorised list of every cookie used on your site — name, provider, purpose, and retention period. CookieBeam auto-generates and keeps this list current.
- The legal basis for each cookie category (e.g. consent for marketing cookies; legitimate interest or contract for strictly necessary cookies).
- How users can withdraw consent — your CookieBeam banner provides a 'Manage Preferences' link that should be referenced here.
- Third-party cookies — identify each third-party vendor, link to their own privacy/cookie policies, and explain that you have no control over what they may change in the future.
- How to opt out via browser settings — describe how to delete or block cookies in Chrome, Firefox, Safari, and Edge.
- Date of last update — keep this current whenever your cookie list changes.
Formatting Tips for Usability and SEO
Structure your cookie policy with clear headings (H2/H3) so it is scannable. Regulators look favourably on policies written in plain language at a reading age accessible to a general audience. Avoid legalese wherever possible. CookieBeam's auto-generated cookie tables are formatted in a way that is both human-readable and crawlable by search engines, helping your policy page rank for informational queries.
Link your cookie policy prominently from your site footer, your privacy policy, and your CookieBeam consent banner. The more visible and accessible the policy, the stronger your compliance posture.
| Cookie Category | Recommended Max Retention | Regulatory Guidance | CookieBeam Default |
|---|---|---|---|
| Strictly Necessary | Session (browser close) to 1 year | No formal cap — but retention must be proportionate to the technical purpose. Session cookies preferred. | Not blocked (no consent required) |
| Functional / Preference | Up to 1 year | ICO and CNIL guidance recommends aligning expiry with the user's reasonable expectation of the preference persisting. | Blocked until consent granted |
| Analytics / Performance | Up to 13 months (GA4 default) | CNIL has explicitly approved 13 months for analytics cookies. Some DPAs prefer 6 months. Clearly document and justify in policy. | Blocked until consent granted |
| Marketing / Advertising | Up to 13 months (industry norm: 30–90 days) | No formal EU maximum, but data minimisation under GDPR Article 5(1)(e) requires justification for longer periods. IAB TCF recommends 13 months. | Blocked until consent granted |
Frequently Asked Questions About Cookie Types
Do session cookies require consent under GDPR?
Not necessarily. If a session cookie is strictly necessary for the website to function — for example, to maintain a shopping cart or authenticate a logged-in user — it does not require consent under the ePrivacy Directive's Article 5(3) exemption. However, if a session cookie serves analytics or tracking purposes, consent is still required even though it expires when the browser closes. The key is the purpose of the cookie, not its lifespan.
Can I use Google Analytics without cookies?
Yes, partially. Google Analytics 4 introduced a cookieless measurement option that uses modelled data rather than persistent client-side cookies. You can also configure CookieBeam to only load GA4 after analytics consent is granted. In Advanced Consent Mode, GA4 sends anonymised, cookieless 'pings' even before consent, which Google uses to model conversions — reducing the data loss from non-consenting users without storing cookies on their device.
What is the difference between a first-party and a third-party cookie?
A first-party cookie is set by the website the user is currently visiting (your domain). A third-party cookie is set by a different domain — typically an ad network, analytics platform, or embedded widget. Third-party cookies are under heavy regulatory and browser-level pressure: Safari and Firefox already block them by default, and Google Chrome has been phasing out support. First-party cookies set by your own server remain fully functional in all browsers.
Are 'tracking pixels' the same as cookies?
No, but they work alongside them. A tracking pixel (also called a web beacon) is a tiny 1×1 transparent image embedded in a page or email. When the browser loads it, the pixel's server logs the request — recording your IP address, browser type, and timestamp. Pixels often work in conjunction with cookies: the pixel request carries a cookie ID that allows the ad network to match the visit to a user profile. Both pixels and cookies require consent when used for tracking or marketing purposes.
Do I need to list cookies set by third-party scripts I did not write?
Yes. Under GDPR, you are responsible for all processing that occurs on your website, including via third-party scripts you embed. If a chat widget, video player, or ad network sets cookies when a user visits your site, those cookies must be disclosed in your cookie policy and covered by your consent mechanism. CookieBeam's scanner detects these third-party cookies and adds them to your policy automatically.
What happens if I have cookies in my policy that are no longer used?
Having 'ghost' cookies — entries in your policy for technologies you no longer use — is not a direct GDPR violation, but it can undermine trust and create problems if a user exercises their rights based on incorrect information. Regulators may also view an outdated policy as evidence of sloppy compliance practices. Use CookieBeam's continuous scanning to keep your cookie inventory accurate and remove stale entries when you discontinue a service.
Preference / Functional Cookies: The Often-Forgotten Category
Preference cookies — sometimes called functional cookies — are one of the most misunderstood cookie categories. Unlike strictly necessary cookies, they are not required for the site to function at a basic level. Instead, they remember choices you have made to personalise your experience: your preferred language, your chosen display currency, your colour scheme or dark mode preference, and similar settings.
Under the GDPR and ePrivacy Directive, preference cookies that go beyond what is strictly necessary to provide the service require prior, freely-given consent. Many website owners incorrectly classify preference cookies as necessary because they relate to site functionality. The key legal test is: could the website still be delivered without this cookie? If the answer is yes, consent is required.
CookieBeam automatically places preference cookies in the Functional consent category, meaning they are blocked until the user explicitly enables that category in your banner. This keeps you compliant with GDPR Article 6 and the ePrivacy Directive without any manual configuration.
| Cookie Name | Vendor | Purpose | Retention |
|---|---|---|---|
| locale | Stores the user's preferred language or locale (e.g. en-GB, de-DE) so the site renders in the correct language on return visits. | - | |
| currency | Remembers the user's preferred display currency (e.g. EUR, GBP, USD) in e-commerce stores. | - | |
| theme | Saves the user's light/dark mode preference so it persists across sessions without requiring a login. | - | |
| tz | Stores the user's detected or chosen timezone to display dates and times correctly. | - | |
| Intercom.io-user | Identifies returning users in the Intercom live chat widget and loads conversation history. | - | |
| CookieLawInfoConsent | Stores the consent record (CookieBeam uses its own consent token instead). If present, this is a consent-management cookie, classifiable as strictly necessary. | - |
Cookie Attributes Explained: HttpOnly, Secure, and SameSite
Every cookie that your server sets carries a set of optional attributes that control its security and accessibility. Understanding these attributes is essential for developers building GDPR-compliant websites, because insecure cookie configurations can expose user data and undermine the privacy guarantees you are making to your users.
When you conduct a cookie audit with CookieBeam's built-in scanner, these attributes are checked automatically and flagged where they represent a potential security or compliance risk.
| Attribute | What It Does | Security / Privacy Impact | Recommended Value |
|---|---|---|---|
| HttpOnly | Prevents JavaScript (document.cookie) from reading the cookie value. | Protects session tokens from Cross-Site Scripting (XSS) attacks. If a malicious script runs on your page, it cannot steal an HttpOnly cookie. | Set on all session and authentication cookies. |
| Secure | Instructs the browser to only transmit the cookie over HTTPS connections. | Prevents cookie interception via man-in-the-middle attacks on unencrypted HTTP connections. Required for any cookie containing sensitive data. | Always set on production cookies when the site runs on HTTPS. |
| SameSite=Strict | Cookie is only sent on requests originating from the same site — never on cross-site requests. | Strongest CSRF protection. May break OAuth/OpenID flows where a redirect from a third-party returns to your site. | Use for sensitive authenticated-only cookies where cross-site access is not needed. |
| SameSite=Lax | Cookie is sent on same-site requests and on top-level navigations from external sites (e.g. clicking a link). | Good balance of security and usability. Prevents most CSRF vectors while allowing normal browsing. | The recommended default for most cookies in modern browsers. |
| SameSite=None | Cookie is sent on all requests, including cross-origin requests from iframes and third-party embeds. | Required for third-party cookies (e.g. ad pixels, embedded widgets). Must be combined with Secure or browsers will reject it. | Use only when cross-site access is genuinely required, and always pair with Secure. |
| Expires / Max-Age | Controls how long the cookie persists. Without this, the cookie is a session cookie and deleted when the browser closes. | Long retention periods for tracking or analytics cookies can violate GDPR data minimisation principles. Supervisory authorities recommend retention periods proportionate to the purpose. | Set the shortest period that fulfils the legitimate purpose. Document the reason in your cookie policy. |
How to Audit Your Website's Cookies
A cookie audit is the process of discovering, categorising, and documenting every cookie your website sets. GDPR and the ePrivacy Directive require that you disclose all cookies used on your site in your cookie policy and obtain prior consent for non-essential cookies. An outdated or incomplete audit is one of the most common compliance failures identified by data protection authorities.
CookieBeam's automated cookie scanner performs this audit continuously — detecting new cookies as your site changes — but it is also valuable to know how to do a manual audit using browser developer tools.
Cookie Audit: Step-by-Step
Open your browser's Developer Tools
In Google Chrome or Microsoft Edge, press F12 or right-click anywhere on the page and select Inspect. Navigate to the Application tab (Chrome) or Storage tab (Firefox). Under the Cookies section in the left sidebar, you will see all cookies currently set for the domain you are viewing.
Visit every key page of your website
Different pages may trigger different cookies. Visit your homepage, a blog post, a product page, the checkout, and any page with a third-party embed (chat widget, video player, social share buttons). Note any new cookies that appear after navigating to each page.
Record all cookies in a spreadsheet
For each cookie, record: Name, Domain (first-party or third-party), Path, Expiry, HttpOnly, Secure, SameSite, and the Purpose. This spreadsheet becomes the source of truth for your cookie policy and your CookieBeam configuration.
Categorise each cookie
Assign each cookie to one of the four standard categories: Strictly Necessary, Functional/Preference, Analytics/Performance, or Marketing/Advertising. If you are unsure, use CookieBeam's cookie database — it recognises over 10,000 known cookies from 2,000+ vendors and categorises them automatically.
Update your cookie policy and CookieBeam configuration
Add any newly discovered cookies to your CookieBeam dashboard under the appropriate consent category. CookieBeam will auto-update your hosted cookie policy page to reflect the changes. For cookies that cannot be justified, consider removing the service that sets them — fewer cookies means a simpler consent UX and lower compliance risk.
Schedule quarterly re-audits
Cookie inventories change whenever you install a new plugin, update a theme, or change your analytics stack. CookieBeam's continuous scanner alerts you by email when a new unknown cookie is detected on your site so you can act immediately rather than discovering the gap during a regulator inspection.
Writing Your Cookie Policy: What to Include
A cookie policy is a legally required document — distinct from your privacy policy — that explains to your users exactly which cookies you use, what they do, how long they last, and what rights users have over them. Supervisory authorities under the GDPR and national ePrivacy laws regularly review cookie policies during investigations, so accuracy and completeness matter.
What Your Cookie Policy Must Cover
At minimum, a GDPR-compliant cookie policy should include:
- A plain-language explanation of what cookies are and how they work.
- A categorised list of every cookie used on your site — name, provider, purpose, and retention period. CookieBeam auto-generates and keeps this list current.
- The legal basis for each cookie category (e.g. consent for marketing cookies; legitimate interest or contract for strictly necessary cookies).
- How users can withdraw consent — your CookieBeam banner provides a 'Manage Preferences' link that should be referenced here.
- Third-party cookies — identify each third-party vendor, link to their own privacy/cookie policies, and explain that you have no control over what they may change in the future.
- How to opt out via browser settings — describe how to delete or block cookies in Chrome, Firefox, Safari, and Edge.
- Date of last update — keep this current whenever your cookie list changes.
Formatting Tips for Usability and SEO
Structure your cookie policy with clear headings (H2/H3) so it is scannable. Regulators look favourably on policies written in plain language at a reading age accessible to a general audience. Avoid legalese wherever possible. CookieBeam's auto-generated cookie tables are formatted in a way that is both human-readable and crawlable by search engines, helping your policy page rank for informational queries.
Link your cookie policy prominently from your site footer, your privacy policy, and your CookieBeam consent banner. The more visible and accessible the policy, the stronger your compliance posture.
| Cookie Category | Recommended Max Retention | Regulatory Guidance | CookieBeam Default |
|---|---|---|---|
| Strictly Necessary | Session (browser close) to 1 year | No formal cap — but retention must be proportionate to the technical purpose. Session cookies preferred. | Not blocked (no consent required) |
| Functional / Preference | Up to 1 year | ICO and CNIL guidance recommends aligning expiry with the user's reasonable expectation of the preference persisting. | Blocked until consent granted |
| Analytics / Performance | Up to 13 months (GA4 default) | CNIL has explicitly approved 13 months for analytics cookies. Some DPAs prefer 6 months. Clearly document and justify in policy. | Blocked until consent granted |
| Marketing / Advertising | Up to 13 months (industry norm: 30–90 days) | No formal EU maximum, but data minimisation under GDPR Article 5(1)(e) requires justification for longer periods. IAB TCF recommends 13 months. | Blocked until consent granted |
Frequently Asked Questions About Cookie Types
Do session cookies require consent under GDPR?
Not necessarily. If a session cookie is strictly necessary for the website to function — for example, to maintain a shopping cart or authenticate a logged-in user — it does not require consent under the ePrivacy Directive's Article 5(3) exemption. However, if a session cookie serves analytics or tracking purposes, consent is still required even though it expires when the browser closes. The key is the purpose of the cookie, not its lifespan.
Can I use Google Analytics without cookies?
Yes, partially. Google Analytics 4 introduced a cookieless measurement option that uses modelled data rather than persistent client-side cookies. You can also configure CookieBeam to only load GA4 after analytics consent is granted. In Advanced Consent Mode, GA4 sends anonymised, cookieless 'pings' even before consent, which Google uses to model conversions — reducing the data loss from non-consenting users without storing cookies on their device.
What is the difference between a first-party and a third-party cookie?
A first-party cookie is set by the website the user is currently visiting (your domain). A third-party cookie is set by a different domain — typically an ad network, analytics platform, or embedded widget. Third-party cookies are under heavy regulatory and browser-level pressure: Safari and Firefox already block them by default, and Google Chrome has been phasing out support. First-party cookies set by your own server remain fully functional in all browsers.
Are 'tracking pixels' the same as cookies?
No, but they work alongside them. A tracking pixel (also called a web beacon) is a tiny 1×1 transparent image embedded in a page or email. When the browser loads it, the pixel's server logs the request — recording your IP address, browser type, and timestamp. Pixels often work in conjunction with cookies: the pixel request carries a cookie ID that allows the ad network to match the visit to a user profile. Both pixels and cookies require consent when used for tracking or marketing purposes.
Do I need to list cookies set by third-party scripts I did not write?
Yes. Under GDPR, you are responsible for all processing that occurs on your website, including via third-party scripts you embed. If a chat widget, video player, or ad network sets cookies when a user visits your site, those cookies must be disclosed in your cookie policy and covered by your consent mechanism. CookieBeam's scanner detects these third-party cookies and adds them to your policy automatically.
What happens if I have cookies in my policy that are no longer used?
Having 'ghost' cookies — entries in your policy for technologies you no longer use — is not a direct GDPR violation, but it can undermine trust and create problems if a user exercises their rights based on incorrect information. Regulators may also view an outdated policy as evidence of sloppy compliance practices. Use CookieBeam's continuous scanning to keep your cookie inventory accurate and remove stale entries when you discontinue a service.