Shield · Cookies

Cookies

FindIP Shield stores two random IDs in the visitor's browser, both first-party and containing no personal data: a session ID and a visitor ID. The visitor ID is also kept in localStorage.

`_fip_sid`

Session

Purpose	Session continuity
Duration	30 minutes (rolling)
Value	Random opaque ID, e.g. `sess_abcd1234`
Contains	No IP, email, or personal data

`_fip_vid`

Visitor

Purpose	Repeat visitor detection
Duration	7–30 days (configurable)
Disabled in	`strict` privacy mode
Value	Random opaque ID, e.g. `vis_abcd1234`
Also stored in	`localStorage`, key `_fip_vid` (SDK 1.11.0 and later)

Other entries the SDK writes

These hold no new information about the visitor; they repeat the session ID or record that something already happened.

Where	Name	Purpose	Lifetime
Cookie	`_fip_ss`	Holds the session ID again, to mark that this session's start has been reported, so `session_start` is sent once	Same as `_fip_sid`
`sessionStorage`	`_fip_sid`, `_fip_ss`	Copies of the two cookies above, used when a cookie cannot be written	Until the tab closes
`sessionStorage`	`_fip_snap:<hash>` (SDK 1.9.0 and later)	Records that this browser already tried a form snapshot for one form version, so it does not try again. The value is `1`	Until the tab closes

When cookies are blocked

Fallback order

Session ID

1sessionStorage

2The tab's window.name (SDK 1.11.0 and later), see below.

3A link token, only when you switch on linkSession (SDK 1.11.0 and later), see below.

4In-memory session ID, for the current page only

5When nothing in the browser keeps the ID, Shield derives one for the visit from the request (IP address, browser and language, for one UTC day) and the SDK uses it. Nothing is stored in the browser for this.

Visitor ID

1localStorage (not in strict mode)

2When neither the cookie nor localStorage can be written, the SDK sends no visitor ID. Shield derives one the same way as the session ID, except in strict mode.

Sessions from such browsers are marked "Cookies blocked" in the dashboard, with what held the session together instead (for example "Cookies blocked · window name"). The session and event details show it in full under "Recognised by". The SDK continues working without cookies.

The `localStorage` copy of the visitor ID

SDK 1.11.0 and later

The visitor ID is kept in two places with the same lifetime: the _fip_vid cookie and a localStorage entry of the same name (<visitor id>.<expiry time>). On each page the SDK reads whichever still holds the ID, the cookie first, and writes both again. A visitor whose cookie was removed, or whose browser refuses the cookie, keeps the same visitor ID as long as the localStorage entry is there.

Clearing site dataRemoves both and starts a new visitor.

Strict modeNeither is written or read.

Consent withdrawnWhen a visitor who had agreed withdraws consent (FindIP.setConsent(false) after an earlier grant), the SDK deletes both and stops sending the visitor ID. Agreeing again starts a new one.

If your cookie notice lists the storage your site uses, list the _fip_vid localStorage entry next to the cookie.

Session fallbacks in detail

SDK 1.11.0 and later

The session ID in `window.name`

When the browser refuses both the cookie and sessionStorage, the SDK keeps the session ID in the tab's window.name, as _fip_sid=<site key>.<session id>.<last seen time>. It stays for the pages of one visit in that tab and ends when the tab closes.

It expires like the session cookie (sessionCookieDurationMinutes).
It names your site key, so a session written on one site is never read on another. The value is a random ID with no personal data; a page the visitor navigates to next in the same tab may be able to read it, as with any window.name.
The SDK only writes an empty window.name. If your page or the window that opened it gave the window a name, the SDK leaves it alone and falls back to the next step.
The SDK removes its value once the cookie or sessionStorage works again.

The session ID in a link token (`linkSession`, off by default)

window.name belongs to one tab, so a link opened in a new tab starts a new session, and a window that already has a name cannot be used at all. With FindIP.init({ linkSession: true }) the SDK also carries the session ID in the link itself, for visitors whose session cookie does not work:

When the visitor clicks a same-origin link, the SDK adds _fip=<session id>.<time> to that link's address. The link in your page is put back right after the click.
The page that opens continues the session and removes _fip from the address bar as soon as the SDK starts.
A token is accepted for two minutes, and only on a page reached from the same origin. A pasted, shared or bookmarked address starts no session.
Nothing is added to links on other origins, downloads, in-page jumps, or clicks your own code handled (preventDefault), such as a single-page app's router.

What to check before switching it on: your server receives the _fip parameter on that one request (caches keyed on the full URL will see it as a new address), and an analytics script that reads the address before the Shield SDK starts can record it. Load the SDK early, or exclude _fip in those tools.

Configuration & troubleshooting

FindIP.init({
  sessionCookieDurationMinutes: 30,
  visitorCookieDurationDays: 30,
});

No _fip_vid in strict modeExpected behavior, for the cookie and the localStorage entry.

sess_cl_… or vis_cl_… IDsDerived by Shield for a browser that keeps nothing.

_fip_sid missingCheck browser privacy settings — the sessionStorage fallback still works.

Cookies

_fip_sid

_fip_vid