- Treat cookie names, storage keys and network destinations as different evidence types.
- Capture enough context to make an inventory reviewable.
- Avoid collecting values or request payloads when a technical inventory does not need them.
Choose the inventory boundary
Identify the pages and flows you are authorized to review. A public homepage, an account area and a checkout can have different dependencies. State whether the inventory covers a single page or a broader workflow, and record which parts remain untested.
Start with a narrow, repeatable scope. A clear inventory of one important flow is more useful than a broad spreadsheet whose collection conditions nobody can explain.
Record names and context, not sensitive values
For each observation, record the cookie name or storage key, observed domain when applicable, scenario and run time. An internal owner and review status are useful fields for follow-up. The downloadable CSV illustrates this structure with fictional observations.
Cookie values can contain identifiers or session material. They are not required for a names-and-domains inventory. Likewise, avoid copying complete request URLs with query parameters, form contents or request bodies into a general review spreadsheet.
Do not confuse cookies with requests
A cookie is browser state associated with a domain and other attributes. A request is a network event. A browser can contact an external destination without creating a cookie, and a cookie can remain from a prior visit if you reused a profile.
Storage keys are another evidence type. Local storage and session storage are not cookies, so label them accordingly. A field named observation_type avoids hiding these differences in a single undifferentiated list.
| Type | Example | What it establishes |
|---|---|---|
| Cookie name | session_example | A named cookie was observed |
| Storage key | display_preference | A named browser-storage key was observed |
| External host | media.example | The browser contacted a destination |
Classify only what you can justify
A familiar-looking cookie name does not establish its purpose. Ask the team that installed the component, review its configuration and record the basis for classification. Keep an unknown status where the purpose has not been established.
Distinguish an observed hostname from a confirmed service identity. Shared infrastructure, custom domains and first-party proxies can complicate that mapping. Preserve the original technical observation so another reviewer can follow your reasoning.
Maintain the inventory after releases
Repeat the same review after changes to analytics, support tools, embedded content or the consent interface. Compare observations under similar conditions and assign new entries to a responsible reviewer.
A missing entry in a later run is not automatic proof that a component was removed. The trigger may not have fired, the observation window may differ, or the run may have failed. Keep coverage notes alongside the comparison.
Use the template responsibly
The CSV contains invented cookie, storage and hostname entries under reserved example domains. Replace them with observations from your authorized test. The file is a documentation template, not evidence about a real site.
TruCookie’s described workflow records names rather than values. Public scanning is not enabled in this release, so you can use the guide and template independently while evaluating the product.