Skip to main content

Cookie Policy

Last updated: August 13, 2026

This Cookie Policy explains how StorePilot uses cookies and similar tracking technologies, the distinction between the Platform dashboard and the WordPress Plugin, and what obligations arise for website owners ("Clients") using the Plugin.


1. What Are Cookies?

Cookies are small text files stored in your browser to enable functionality such as staying logged in, remembering preferences, or tracking usage patterns. Similar technologies include localStorage, sessionStorage, and browser fingerprinting.


2. Storage on the StorePilot Dashboard

The Platform dashboard (at dashboard.store-pilot.net) sets no cookies at all. Authentication tokens are held in localStorage:

KeyStoragePurposeDuration
access_tokenlocalStorageKeeps you logged in15 minutes
refresh_tokenlocalStorageSilent renewal without re-entering credentials7 days

These are strictly necessary for the Platform to function and do not require consent under the ePrivacy Directive.

No third-party analytics, advertising, or social media cookies are used on the Platform dashboard.


3. Storage Used on Client Websites

StorePilot's collectors — whether delivered by the WordPress Plugin or by the script tag — set one first-party cookie and several browser-storage keys.

KeyStoragePurposeDuration
sp_vidFirst-party cookieIdentifies the browser. SameSite=Lax, Secure on HTTPS, not HttpOnly (it is written by script)2 years, rolling — renewed on each visit
wpelVisitorIdlocalStorageThe same identifier, duplicatedPersistent
storepilotRecordingSessionIdlocalStorageGroups events within one visit, across the browser's tabsReplaced after 30 minutes without activity, on sign-out, or after an order (see below)
storepilotRecordingSessionActivitylocalStorageInactivity clock for the visit, shared by its tabsSame as the visit
storepilotSessionRotateHandledlocalStorageA timestamp: the site asked for a new visit to begin (on sign-out, or after an order) and this browser has already done it, so one signal starts one visit. Holds no information about the visitorReplaced by the next such signal
storepilotEnrSentlocalStorageThe visit for which the browser and referrer details have already been reported, so they are sent once per visit rather than once per tabSame as the visit
storepilotRecordingTabsessionStorageNames this tab's own footage stream inside the visit. A random label and nothing elsePer tab
storepilotTabLease_<id>localStorageMarks that a tab holding that stream label is open, so a duplicated tab takes a label of its own (the prefix is storepilotTabLease). Removed when the tab closesWhile the tab is open
storepilotRecordingSessionSequencesessionStorageSegment counter for this tab's stream of the session replayPer tab
storepilotPvId, storepilotPvEntry, storepilotPvAccum, storepilotPvSentsessionStoragePageview bookkeeping — how long the page has been on screen, and what has already been reported (the prefix is storepilotPv)Per visit
storepilotMuted_<endpoint>sessionStorageA timestamp: the collector was rate-limited and is staying quiet until then. Holds no information about the visitor (the prefix is storepilotMuted)Per visit
storepilotCount_<name>sessionStorageA count of reports already sent during the visit, so a page repeating a fault stops repeating it. A number and nothing else (the prefix is storepilotCount)Per visit
storepilotSurveyDone_<id>localStorage"Don't ask again" — set when a survey is answered (the prefix is storepilotSurveyDone; one key per survey)Persistent
storepilotSurveyDismissed_<id>localStorageWhen a survey was closed without answering, so it stays quiet for a day before asking again (the prefix is storepilotSurveyDismissed; one key per survey)Persistent
storepilotInternallocalStorageSet when somebody opens the site with the shop's own "exclude me" link (?sp_internal=1), so their own visits are not collected at all. Holds the value 1 and nothing about the visitor; ?sp_internal=0 removes itPersistent, until removed

The identifier is stored twice on purpose: cookies and script storage are cleared by different user actions and capped by different browser policies, so whichever survives re-seeds the other. It identifies a browser, not a person — a private window is legitimately a new visitor.

A visit ends after 30 minutes of inactivity, not when a tab closes — a visit belongs to the browser, so opening a second tab continues the same visit rather than starting a new one. It also ends after a completed WooCommerce order and on logout.

WordPress additionally sets one short-lived server-side cookie, storepilot_session_rotate (HttpOnly, SameSite=Strict, 5 minutes), after a logout or a completed order, to tell the collector to start a new visit. It is not set when consent is required and has not been given.

:::note Why one key still reads wpel wpelVisitorId keeps a name the other keys have dropped. Sites upgrading from the older WP Error Logger plugin may run both collectors during the changeover, and the visitor identifier is the one value both must agree on — renaming it would split a single browser into two visitors and make the two sets of measurements impossible to reconcile. It is written once and never re-minted, so there is no question of which copy wins. :::

This depends on applicable law:

  • GDPR / ePrivacy Directive (EU): localStorage used for analytics or behavioral tracking (session recordings, pageview analytics) typically requires prior informed consent. Error tracking for purely technical/security purposes may fall under "strictly necessary" depending on the scope.
  • CCPA (California, USA): Does not require opt-in consent but requires disclosure in the Privacy Policy and support for opt-out of "sale" of personal information.
  • UK PECR: Similar to EU ePrivacy Directive.

Client Obligation: If session recording or pageview analytics is enabled, you must obtain visitor consent via a cookie/tracking consent banner before the Plugin initializes. You are solely responsible for this — the Platform does not manage consent on your behalf.

US session-replay litigation note: several US states have all-party-consent wiretap statutes (California Penal Code §§631–632, Florida's Security of Communications Act, Pennsylvania's WESCA) under which session-recording tools have drawn class actions against the websites that ran them. That risk attaches to you as the website operator, and the practical defence is the same posture the GDPR bullet above requires: disclose session recording in your privacy notice, and consider switching on the consent gate below for US traffic too. StorePilot's own position — your data is never used for our purposes, sold, or shared — is the vendor-side half of that defence, but the disclosure on your site is yours to make.


4. Third-Party Services Triggered by the Plugin

Depending on Client configuration, the Plugin sends data to:

ServiceTriggered ByData Sent
StorePilot Platform API (api.store-pilot.net)All featuresErrors, recordings, pageviews, leads, clicks
The Client's own chat widget (Brevo Conversations), only where the Client embedded itChat identity — so a transcript can be matched to the visitSTOREPILOT_VISITOR (the browser identifier) and STOREPILOT_SESSION (the visit), handed to the widget inside the visitor's browser, only where tracking is allowed

Session recordings are stored by the Platform. Earlier versions of the Plugin stored them on the Client's own server or S3 bucket and sent us only a URL; recordings made before that change may still live on the Client's own storage.

No advertising networks, social media pixels, or retargeting platforms are embedded by the Plugin.


To comply with GDPR/ePrivacy requirements, you should integrate the Plugin's initialization with your cookie consent solution.

Step 1 — switch the gate on. In your StorePilot dashboard: Settings → Privacy → Require consent before tracking. This takes effect on every visitor within about a minute. (Plugin versions before 1.10.2 also carried this switch in the site's own admin; it is gone since — the dashboard is the only copy.)

If your consent plugin supports the WP Consent API, Step 2 is already done. Since Plugin 1.11.0 StorePilot registers itself with that standard, which Complianz, CookieYes and others implement: StorePilot then appears in your banner's cookie declaration by itself, and the collector reads the visitor's decision from it — granting, refusing, and changing later. Nothing has to be wired by hand.

The category is statistics, not statistics-anonymous: StorePilot stores a visitor identifier that persists across visits, which is exactly what the anonymous category excludes.

Two rules apply to that signal, both deliberate:

  • A refusal there stops collection, even if the switch in Step 1 is off and even if window.StorePilot_grantConsent() was called. A visitor's answer to your banner outranks a page script asserting consent on their behalf.
  • Global Privacy Control still outranks the banner. A shop's consent tool cannot consent over a binding browser-level opt-out — see below.

A consent plugin that does not implement the WP Consent API is not integrated automatically. Use Step 2 below; nothing about that path has changed.

Step 2 — tell StorePilot when consent is granted, from your consent tool's "accept analytics" callback:

// Any one of these. Use the first if your banner runs before the StorePilot tag.
window.StorePilot_CONSENT = true;
window.StorePilot_grantConsent();
window.dispatchEvent(new CustomEvent('storepilot:consent'));

To withdraw consent later — for example if the visitor changes their choice:

window.StorePilot_withdrawConsent();

Withdrawal stops collection and deletes the visitor's identifiers from the browser.

Nothing is collected and nothing is buffered. No cookie is written, no browser storage is touched, no request is sent. A visitor who never accepts is never recorded — as opposed to being recorded and held back pending a decision.

Data sent by a browser still running a script cached from before you switched the gate on is discarded by the Platform, because such a script cannot assert that consent was given.

Global Privacy Control

StorePilot honours navigator.globalPrivacyControl (and the Sec-GPC: 1 request header) unconditionally, on every site, whether or not the consent gate above is switched on. There is no setting to disable this.

Do Not Track is not honoured. navigator.doNotTrack and the DNT: 1 header are ignored. The W3C discontinued work on that specification in 2019, no privacy law names it, and browsers that still offer the switch describe it as advisory — Chrome's own settings screen says sites use their discretion when responding to it. If you want visitors asked before anything is collected, use the consent gate above, which is a decision your site makes and communicates rather than a header set on a visitor's behalf.

Excluding specific pages

Settings → Privacy → Excluded URLs takes a list of path patterns (/checkout/*, /my-account/**). By default those pages are excluded from session replay only, so you keep their traffic figures without filming them; the same screen can widen that to all collection.


6. How to Opt Out

For visitors of Client websites:
Contact the website owner. As the Data Controller, the website owner is responsible for honoring opt-out and erasure requests. They can use the Platform's right-to-erasure endpoint to delete your data.

For Clients (dashboard users):
The dashboard uses only strictly necessary authentication cookies. These cannot be disabled without breaking login functionality. You may delete your account to remove all associated data.


7. Changes to This Policy

We will post changes on this page and update the date at the top. For material changes — a new storage key, a longer duration, a new category of data — we will notify registered account holders by email, the same standard the Privacy Policy and the Terms of Service already apply to theirs.


8. Contact

Questions about cookies: contact@store-pilot.net