How AI cookie categorisation works, and where a person still decides

All posts

AI cookie categorisation suggests a consent category for each cookie a site scan finds but cannot match to a known vendor. The model reads very little: the cookie's name, the site's domain and any vendor name the scan attached. It picks necessary, functional, analytics, ads, personalisation or unknown. In Velo, a person accepts or changes each suggestion before it counts.

What does the model actually read?

Less than most people expect. In Velo, a scan loads your pages, records every cookie it sees and checks each name against a dictionary of known vendor signatures first. A cookie like _ga matches Google Analytics there, and no model is involved. Only the cookies the dictionary cannot place go to the AI step.

For each of those, the model gets three things: the cookie name, your site's domain, and any vendor name the signature check attached to it, which for an unmatched cookie is usually none. It never receives the cookie's value, anything about the visitor who carried it, how long the cookie lasts, or which script set it. It must answer with one of six categories and, where it can tell, a vendor name. An answer outside those six is thrown away rather than stored, and a cookie the model cannot place should come back as unknown.

Other tools take other routes. Some also read public cookie databases or classifications pooled from other customers, and some attach a confidence rating and can publish the confident answers without a review. Whatever the inputs, the output is the same kind of thing: a suggestion about purpose, made without watching what the cookie does on your site.

Which cookies can AI not categorise correctly?

Any cookie whose purpose is not written in its name. From the name alone, a model cannot know:

• What a generic first party cookie does. session, token, uid or pref set by your own code could be a login, a basket, an experiment bucket or a tracking ID. Only whoever wrote that code knows.
• What a renamed cookie used to be. Some tags let a site change their cookie names; Google's tag, for instance, accepts a cookie prefix. A server side setup can also store its own identifier under any name you choose. Once renamed, the cookie loses the pattern that would have matched it.
• Which features you switched on. The same vendor cookie can serve measurement on one site and advertising audiences on another, depending on what is enabled in the vendor's account.
• When the cookie appears. Whether a cookie was set before the visitor made a choice is a fact about your page, not about the name. The scan measures that; the model never sees it.

That is why unknown is a good answer, not a failure. A cookie left unknown stays on the review list. A confident wrong category drops off it.

What should a person check before accepting a suggestion?

Start with the suggestions the AI made and the cookies still marked unknown. Known vendor matches need less time, though they deserve a glance if you use that vendor in an unusual way. Then work through each one.

1. Find out what sets the cookie

   Open the page in a private window, find the cookie in the browser's storage panel and look at the request that set it. The domain and the script tell you more than the name does.

2. Read the vendor's own cookie list

   Many vendors publish what each of their cookies is for. If the suggestion and the vendor's description disagree, go with the vendor.

3. Ask the developer about first party names

   For cookies your own code sets, one question settles most cases: what breaks for the visitor if this cookie is missing? If nothing they asked for breaks, it is not necessary.

4. Keep necessary for what the site cannot work without

   The consent exemption in Article 5(3) of the ePrivacy Directive covers storage that is strictly necessary for a service the visitor asked for. The ICO's guidance on storage and access technologies shows how narrowly regulators read that. When in doubt, choose the stricter category.

5. Match the category to the banner group

   A category only helps if the script that sets the cookie waits for the matching group in your banner. If the two disagree, fix the tag setup rather than the label. What a wrong consent category does to GA4 and Google Ads covers what each mismatch costs.

Scan again after any change, and read the findings a second time.

What changes once you accept a category?

In Velo, the accepted category becomes the cookie's category in your scan reports, including earlier ones, which are shown again with today's decisions. The findings are worked out from it. An unknown cookie is listed for review. A cookie outside necessary that was already present before any choice is flagged. A cookie whose group is switched off in your banner but still turns up is flagged too.

Later scans do not ask about an accepted cookie again. If you change the suggestion as you accept it, the record shows it as your own decision rather than the AI's, so you can always tell which categories a person chose.

Accepting a category does not switch a tag on or off by itself. Which groups your banner offers, and which scripts wait for consent, are set in the banner and in your tag setup. The category tells you whether those settings match what the site really does, which is the point of checking whether a tag sets cookies before consent.

How Velo handles it

AI cookie categorisation is new in Velo. It runs on the cookies a scan cannot match to a known vendor, labels each suggestion as coming from the AI, and applies nothing until someone with edit rights accepts it. If the AI step is unavailable, or the account's monthly allowance of AI suggestions is used up, the scan still completes and those cookies wait as unknown. The rest of the workspace is on the product page, and you can run a first check of your own site from the scan page.