Cookie categories and the approval gate

How the four categories, provenance, and human approval decide what reaches your published cookie policy, and why editing a category by hand clears its approval.

What are the four categories?

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

  • necessary: the site doesn't work without it.
  • functional: remembers a choice the visitor made.
  • analytics: measures how the site is used.
  • marketing: supports advertising and cross-site tracking.

A cookie discovered by a scan starts unclassified unless the known list recognizes it. Unclassified means the cookie has no category at all, so UserGuard doesn't treat it as a fifth one.

Why does an unclassified cookie block publishing?

Because an unclassified cookie can't be approved. Approving a cookie means confirming its categorization, and an unclassified cookie doesn't have one to confirm. A reviewer has nothing to agree with, so the approve control stays off until someone assigns a category.

Unclassified cookies can't slip into a published policy unnoticed, and they can't disappear from it unnoticed either. The cookie policy warns when unapproved cookies are excluded, and that warning makes any gap in your review visible.

Where a categorization came from

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

  • Known list means the cookie matched UserGuard's list of recognized cookies and was categorized automatically. The row shows no extra label.
  • AI draft means the category was suggested by AI. Until it's approved, the row says Suggested by AI, and its tooltip shows the confidence percentage.
  • Human means a person set or changed it. The row shows no extra label.

Provenance tells you 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 that suggestion is. Treat a low-confidence draft as a request for your attention, and don't take it as the answer.

The approval gate

Nothing reaches a published cookie policy or Do Not Sell notice until a person approves it. Scans find the cookies, and the known list and AI propose categories, but publishing waits for you.

You approve from the review bar, either one cookie at a time or everything that already has a category in a single action. The bulk action can't pull unclassified cookies through. They can't be approved, so they stay behind the gate until you categorize them.

Editing a category clears its approval

When you change a cookie's category by hand, two things happen. The provenance becomes human, and any existing approval is cleared.

The second part surprises people. An approval applies to a specific categorization: this cookie, in this category, confirmed by a person. Once the category changes, that confirmation no longer describes anything, and keeping it would mean publishing a categorization nobody has reviewed. So the approval is cleared, and the edited row goes back through the gate.

Provider, purpose, and retention

Each cookie also has three text fields: provider, purpose, and retention. They're printed verbatim in the cookie policy, which means the text in the row is the text visitors read. You edit them in the row's Details panel.

Purposes can arrive as AI drafts, marked with a note. When you edit an AI-drafted purpose, the note goes away, the words become yours, and UserGuard stops presenting them as machine output. Category provenance works the same way. Once you've changed something, it's 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.