Skip to content

Product

Cookie Inventory: what to verify before client handoff

Before handoff, verify that the Cookie signals inventory matches what the public site actually sets and loads—then keep Consent controls and privacy links in the same conversation.

· by Maya Okonkwo

Cookie Inventory: what to verify before client handoff

Handoff calls go sideways when the client opens DevTools and sees third-party cookies you never mentioned. A polished homepage screenshot does not inventory Set-Cookie headers, document.cookie writes, or pixels that only fire after scroll. The public surface still tells that story whether your deck does or not.

SlaySlop names this check Cookie signals in the catalog. The glossary line is blunt: it "Inventories public cookie and tracking signals observed by the scan." Before you send portal access, that inventory is the Legal row I refuse to hand-wave.

Outcome you want at handoff

On the launch URLs you claim are done, you can name the first-party and third-party cookie and tracking signals a visitor actually picks up in a normal browse. You can point at evidence, not vibes. If marketing tags are intentional, they show up in the inventory on purpose. If something unexpected shows up, you own the ticket before the client finds it live.

This is exposure language, not theater. What an outsider sees on the public surface includes cookies and trackers the scan can observe. Pretending the banner alone covered that is how agencies get surprised on week two.

Primary marketing URLs and any page that loads tags come first. Deep archive pages come later. If checkout-adjacent routes are in scope for the SOW, they are not optional for the inventory pass.

Boundaries to state on the call

Say the quiet parts out loud. SlaySlop is a free read-only scan of a public URL you have permission to assess. It does not edit the site. It is not a pentest. It is not a DPIA. A clean Cookie signals result is not legal advice and not proof every regional regime is satisfied.

Keep sibling checks in the same breath so one green row does not swallow the Legal story:

  • Consent controls: reviews visible signals related to analytics and cookie consent
  • Privacy policy: checks whether a public privacy policy can be found and reached
  • Terms page: checks whether public terms are discoverable

Those definitions come from SlaySlop's checks catalog and glossary. Quote them if someone asks what was measured. The Acceptable Use Policy is equally plain: only scan sites you own or are explicitly authorized to assess.

Happy path checklist before you send the portal

Work production hosts, not a staging build with half the tags disabled.

Loading diagram.

bash
# Permissioned spot-check: document headers only (not the full inventory)
curl -sI -L "https://www.example.com/" | awk 'BEGIN{IGNORECASE=1} /^HTTP|^set-cookie:|^content-type:/{print}'

Then, in a real browser with a fresh profile:

  1. Load / and one tagged landing or pricing page.
  2. Open Application → Cookies and the Network filter for known analytics hosts.
  3. Accept or reject consent the way a first-time visitor would, and note what changes.
  4. Compare that list to the Cookie signals findings in the SlaySlop report for the same routes.
  5. Confirm privacy and cookie policy URLs still resolve before you promise them on the call.

SlaySlop crawls the public site in a real browser, ranks verified findings by impact, and attaches evidence to the page where the signal was observed. Put those URLs in the handoff notes. "Cookies looked fine" is not a note. "Cookie signals: expected first-party session on /; unexpected doubleclick pair on /pricing — ticket SS-184" is a note.

Pitfalls that embarrass you on the call

Already-accepted sessions hide half the story. Your laptop from last week's QA still holds consent state; the client's fresh laptop does not. Demo accounts that clicked Accept on Tuesday will not show the first-layer inventory the privacy person cares about.

Tag managers that fire only after interaction also fool a one-second glance. Scroll, click the hero CTA, open the chat widget, then re-check cookies. Cookie signals inventories what the scan observed across the crawl—not what your memory of staging looked like.

Do not collapse inventory into consent. A banner can be visible while the inventory still shows trackers you never disclosed. Opposite failure: inventory looks quiet while Consent controls flags missing visible cues. Different checks. Different fixes.

Another classic: production GTM container published with a vendor the SOW never named. Your internal QA used a trimmed container. The public launch host did not.

What to put in the portal notes

Route, observed cookie or tracker family, whether it is expected, owner (marketing / eng / CMP), and the follow-up scan date. If the inventory and the public cookie policy disagree, say so before the client does. Link the Cookie signals glossary entry if they want the product definition in writing: Cookie signals. Soft next step: keep scanning the live host so a new pixel does not land silently after launch week.