Cookie categories and the approval gate

The four categories

Every cookie in UserGuard belongs to one of four categories, or to none:

• necessary — the site does not work without it.
• functional — remembers a choice the visitor made.
• analytics — measures how the site is used.
• marketing — supports advertising and cross-site tracking.

"Or to none" is the important part. A cookie discovered by a scan starts unclassified unless the known list recognizes it. Unclassified is not a fifth category. It is the absence of one, and UserGuard treats it that way.

Why unclassified blocks publishing

An unclassified cookie cannot be approved. This is deliberate. Approving a cookie means confirming its categorization, and an unclassified cookie has no categorization to confirm. There is nothing for a reviewer to agree with, so the approve control stays off until someone assigns a category.

Unclassified cookies do not slip into a published policy quietly, and they do not vanish quietly either. The cookie policy warns when unapproved cookies are excluded. A gap in your review shows up as a visible warning, not a silent omission.

Where a categorization came from

Every categorization carries its provenance, shown on the cookie's row. There are three sources:

• Known list — the cookie matched UserGuard's list of recognized cookies and was categorized automatically.
• AI draft — the category was suggested by AI, shown with a confidence percentage.
• Human — a person set or changed it.

Provenance exists so you know how much scrutiny a row deserves before you approve it. A known-list match is a lookup. An AI draft is a suggestion, and its confidence percentage tells you how firm a suggestion. A low-confidence draft is a request for your attention, not an answer.

The approval gate

Nothing reaches a published cookie policy or Do Not Sell notice until a person approves it. That is the whole rule. Scans discover, the known list and AI propose, but publishing waits for you.

You approve from the review bar: one cookie at a time, or everything that already has a category in a single action. The bulk action cannot pull unclassified cookies through. They are not approvable, so they stay behind the gate until you categorize them.

Editing a category clears its approval

Change a cookie's category by hand and two things happen. The provenance becomes human. Any existing approval is cleared.

The second part surprises people, so here is the reasoning. An approval is not a property of the cookie. It is a statement about a specific categorization: this cookie, in this category, confirmed by a person. Once the category changes, that statement no longer describes anything. Keeping the approval would mean publishing a categorization nobody has actually reviewed. So the approval cannot survive the change, and the edited row goes back through the gate.

Provider, purpose, and retention

Each cookie also carries three text fields: provider, purpose, and retention. They are printed verbatim in the cookie policy. The text in the row is the text visitors read. Edit them in the row's Details panel.

Purposes can arrive as AI drafts, marked with a draft badge. Editing an AI-drafted purpose removes the badge: the words become yours, and UserGuard stops presenting them as machine output. This mirrors how category provenance works: once you have touched something, it is attributed to you.

Because these fields publish verbatim, review them the way you would review the policy itself. If a purpose is vague or a retention period is wrong in the row, it will be vague or wrong on your site.