Skip to content
Black BoxPersonalization

Collect

Cookies and storage

Every cookie, localStorage key, and sessionStorage key on this origin, with the owner, the purpose, the lifetime, and whether the identifier belongs to this site or to Google.

Reset my data

Reading this browser…

What this site can clear

  • Cookies written on this host. That includes bbp.visitor, the Auth.js session, and the Google Analytics cookies gtag writes here (_ga, _ga_*, _gid, _gat). A cookie only disappears when the name, path, and domain match, so the page expires each readable name on /, on each folder of the current path, on this host, and on the parent domain.
  • HttpOnly cookies are invisible to page script. The server route expires every name on the request, plus the names this site sets, with Max-Age=0. The same response sends Clear-Site-Data: "cookies", "storage".
  • localStorage, sessionStorage, IndexedDB, and Cache Storage for this origin. This site does not open an IndexedDB database. The reset still deletes one if the browser has one.
  • The signed-in session, by expiring the session cookie. The account itself stays.
  • Collection rows for this anonymous id that have no account id yet: collect_event and visitor_profile. Consent keys are removed, so the banner asks again.

What stays

  • Cookies on other domains. A third-party cookie set on google.com is not in this response, and this page cannot expire it.
  • Hits already accepted by Google Analytics. Deleting _ga here drops the browser’s client id. The next hit is a new user. The old hits remain in the property.
  • Rows already attached to an account, contact messages, and white-paper leads. The account page deletes the stored profile and events for the signed-in person.
  • Browser history. That list belongs to the browser.

How GA4 deletion and retention work

In GA4 Admin, Data retention is 2 months or 14 months for event data. When that window ends, Google drops the event-level and user-level data, including the client id, from the property. An admin can also file a data deletion request for a client id or user id. This site does not call that API, and the reset event does not include the client id. reset_my_data is pushed before the clear, with the surface name only, and only while measurement consent is on.

Why analysts care

Each reset mints a new client id and a new anonymous id. User counts rise, and the path from the first campaign to later visits breaks, because the join key is gone. Safari’s Intelligent Tracking Prevention caps cookies written with document.cookie at seven days. gtag writes _ga that way, so the client id can expire on its own and the next visit is a new user. A stretch without interaction can clear script storage the same way. The browser does it without a button.

Identity stitching

  1. Before sign-in, a consented beacon is stored with collect_event.visitor_key set to the bbp.visitor cookie. collect_event.user_id is null.
  2. site.visitor.v1 is a separate localStorage record for visit counts. Rules read that record. They do not read the cookie.
  3. On sign-in, claimVisitor sets user_id to the Auth.js user.id on rows that already have this visitor key and no account. It does not take rows that already belong to someone else. The email is not copied onto the event.
  4. Later beacons store both ids. Google’s _ga cookie is not joined to the account.

This request: Checking the cookie names…

What this browser is holding

The table lists names. Values are not printed. HttpOnly names come from the request the browser already sent to /api/cookie-inventory. A cookie written on this host by gtag.js is still stored as a first-party cookie; the party column names the organization that owns the identifier.

Reading this browser…

Recommended next

Why these picks

Reading path transitions…