Website Cookie Consent: Inventory, Records, and Acceptance

Learn how to build a cookie inventory, classify cookies as necessary or optional, and record consent events with audit trails for your website.

What Constitutes a Cookie Inventory and Why It Matters for Consent

A cookie inventory is a complete, up-to-date list of every cookie your website sets or reads. It records the cookie name, domain, purpose, duration, and whether it is necessary or optional.

This inventory is the foundation of your consent management because it tells you what you need to ask permission for.

Without an accurate inventory, you cannot present a valid consent banner. If you miss a tracking cookie, you may collect data without consent. If you list cookies that no longer exist, you confuse users and risk non-compliance.

The inventory also helps you respond to user requests about their data.

For consent to be meaningful, users must know exactly what they are agreeing to. A cookie inventory provides that transparency. It also supports your privacy policy, which should reference the inventory so users can review details before deciding.

Step-by-Step: How to Build a Cookie Inventory from Your Website

Start by opening your website in a browser’s developer tools. Go to the Application or Storage tab and look at Cookies. You will see cookies set by your domain and third-party domains.

Record each cookie’s name, domain, path, expiration, and whether it is HTTP-only or Secure.

Next, scan your website’s source code for scripts that set cookies. Look for tags from analytics, advertising, or personalization platforms. Each tag may set multiple cookies.

Use a browser extension or a dedicated scanning service to automate discovery, but verify results manually because automated tools can miss cookies set after user interaction.

Also check cookies set by embedded content such as videos, maps, or social feeds. These third-party services often set their own cookies. You need to include them in your inventory because they may require consent.

After listing all cookies, test your site in a private browsing session. Accept all cookies and note which appear. Then clear cookies, reject all, and see which remain. This reveals which cookies are strictly necessary for basic functionality.

Document your findings in a spreadsheet or a consent management platform. Include the cookie name, provider, purpose, duration, and category. Update this inventory regularly because scripts and services change over time.

Separating Necessary and Optional Cookies: A Decision Framework

Classify each cookie as either strictly necessary or optional. Strictly necessary cookies are essential for the website to function, such as session cookies that keep you logged in or security cookies that protect against fraud.

These do not require consent under most regulations.

Optional cookies include analytics, advertising, and personalization cookies. They are not essential for the site to work but enhance user experience or help you understand behavior. These require consent before they are set.

Use a simple decision framework: if the cookie is required for the core service the user requested, it is necessary. If it is used for purposes like tracking, profiling, or cross-site advertising, it is optional. When in doubt, treat it as optional to be safe.

For example, a cookie that remembers a user’s shopping cart is necessary. A cookie that tracks which pages a user visits to show targeted ads is optional. A cookie that measures site performance for analytics is optional, even if it does not identify the user.

Document your reasoning for each classification. This helps when regulators or users ask why a cookie is necessary. It also ensures consistency across your team.

Recording Consent: Triggers, Withdrawal, and Audit Trails

Consent must be recorded when a user makes a choice. This happens when they click "Accept," "Reject," or customize their preferences.

Each action should trigger a log entry that captures the user’s choice, the date and time, the consent version, and an identifier for the user or their browser.

Store this information in a secure log that cannot be altered. This audit trail proves that you obtained consent and shows what the user agreed to. It also helps you honor withdrawal requests.

When a user withdraws consent, you must stop setting optional cookies and delete any that were previously set. Record the withdrawal event with the same detail as the initial consent. This ensures you have a complete history of the user’s preferences.

Your consent management platform should generate a unique ID for each consent event. This ID links the user’s choice to the specific cookie inventory version they saw. If you update your cookie inventory, users must be asked again for consent.

For audit purposes, keep records of consent for as long as required by applicable law. Regularly review your logs to ensure they are complete and accurate. This practice helps you respond to user requests and regulatory inquiries.

Remember that consent is not a one-time event. Users may change their minds, and you must respect that. Your system should allow users to update their preferences at any time, and each change should be logged.

By maintaining a clear audit trail, you demonstrate accountability and build trust with your users. This is a key part of Website Cookie Consent: Inventory, Records, and Acceptance.

Handling Regional Variables: GDPR, CCPA, and Beyond

Consent requirements vary by region, and your implementation must adapt. The GDPR, applicable in the European Economic Area, generally requires opt-in consent before setting non-essential cookies.

In contrast, the CCPA, which applies to California residents, provides an opt-out right for the sale or sharing of personal information. Other regions, such as Brazil with the LGPD or South Africa with POPIA, have their own rules.

You need a mechanism to detect the user’s location and apply the correct consent logic.

Geo-detection can be done through IP address lookup or browser language settings, though IP is more reliable. Once you know the region, you can present the appropriate consent banner.

For GDPR, you might show a banner that requires an affirmative action, like clicking "Accept" or "Reject," before non-essential cookies load. For CCPA, you might show a "Do Not Sell or Share My Personal Information" link that allows users to opt out.

Your consent management platform (CMP) should support multiple configurations and switch based on the detected region.

A common approach is to use a CMP that integrates with your tag manager. The CMP stores the user’s choice and exposes a consent state that your tags can check.

For example, a user in Germany might see a banner with granular toggles for different cookie categories, while a user in California sees a simple opt-out link.

The underlying logic must ensure that no non-essential cookie is set until the appropriate consent is given.

Tag Manager Behavior: Controlling Script Loading Based on Consent

A tag manager like Google Tag Manager (GTM) gives you a central place to control when scripts fire. The key is to configure tags to wait for consent before loading. GTM offers built-in consent settings that integrate with a CMP.

You can set each tag to require consent for a specific category, such as "analytics_storage" or "ad_storage." When a user consents, the CMP updates the consent state, and GTM automatically fires the tags that match the granted categories.

For tags that are not natively consent-aware, you can use triggers and custom JavaScript. For example, you might create a custom HTML tag that checks a global variable set by your CMP before injecting a script.

Alternatively, you can use GTM’s consent mode to delay tags until consent is given. The exact implementation depends on your CMP and tag manager, but the principle is the same: no non-essential script should load without the user’s explicit acceptance.

A practical approach is to use GTM’s built-in consent overview to see which tags are blocked and which have fired. You can also create a custom trigger that fires only when a consent signal is present.

For instance, you might have a tag for a marketing pixel that should only fire after the user clicks "Accept" on the banner. You would set the tag’s consent setting to require "ad_storage" and then test to ensure it does not fire before consent.

Worked Example: Consent Flow for a Marketing Analytics Cookie

Let’s walk through a concrete scenario. Suppose you have a marketing analytics cookie, _mkt, that tracks user behavior for campaign optimization. This cookie is non-essential and requires consent. Your inventory lists it under the "Marketing" category.

You use a CMP that integrates with GTM.

1. User lands on your site. The CMP detects the user’s region (e.g., EU) and displays a consent banner with options to accept or reject marketing cookies.
2. User clicks "Accept." The CMP records this choice and updates the consent state in a JavaScript variable, e.g., dataLayer.push({‘event’: ‘consent_granted’, ‘consent’: {‘marketing’: true}}).
3. GTM listens for the consent event. Your marketing tag has a trigger that fires on the consent_granted event when marketing is true. The tag then loads the script that sets _mkt.
4. The cookie is set. The script runs and creates the _mkt cookie in the user’s browser.
5. A record is created. Your CMP logs the consent event, including the timestamp, the user’s choice, and the region. This record is stored for compliance purposes.

If the user clicks "Reject," the CMP updates the consent state to marketing: false, and the tag does not fire. The _mkt cookie is never set. This flow ensures that the cookie is only loaded after acceptance, and you have a record of that acceptance.

Validation and Failure Handling: Testing Your Consent Implementation

After implementing your consent flow, you must verify that cookies are loaded only after consent and that the system handles withdrawals correctly. Start by testing in a private or incognito browser window to ensure no cached consent state interferes.

Use your browser’s developer tools to inspect cookies before and after interacting with the banner.

Test scenarios:
– No interaction: Load the page and do not click anything. Check that no non-essential cookies are set. Only strictly necessary cookies should appear. – Accept all: Click "Accept" and verify that all non-essential cookies are set.

– Reject all: Click "Reject" and verify that no non-essential cookies are set. – Withdraw consent: After accepting, go back to the banner and revoke consent. Check that the non-essential cookies are deleted or that no new ones are set.

You can also use GTM’s preview mode to see which tags fire and when. If a tag fires before consent, you have a configuration error. Check that the tag’s consent settings are correct and that the trigger is properly tied to the consent event.

If a user withdraws consent, your CMP should update the consent state and you should delete any cookies that were set based on that consent. This may require additional JavaScript to remove cookies.

For example, you might have a function that deletes _mkt when consent is revoked. Test this by accepting, then withdrawing, and confirming the cookie is gone.

Common failures include tags firing on page load regardless of consent, or consent state not being updated correctly. To troubleshoot, check your CMP’s documentation and ensure that the integration with your tag manager is correct.

Also, verify that your cookie inventory is accurate; if you miss a script that sets a cookie, it will load without consent.

Remember that consent management is an ongoing process. Regularly audit your site for new scripts and update your inventory and consent settings accordingly. This ensures that your records remain accurate and that you continue to honor user choices.

Next step

Need help implementing a compliant cookie consent system? Contact SHMLANG for expert guidance on website development and consent management.