Skip to main content

GDPR Compliance

Last updated: September 5, 2026

This page explains how StorePilot supports GDPR compliance for website owners (Clients) who use the Platform to collect data from EU-based visitors.

Role Definitions​

RolePartyExplanation
Data ControllerYou (the Client / website owner)You determine the purpose and means of collecting visitor data
Data ProcessorStorePilot PlatformWe process visitor data strictly on your behalf and according to your instructions
Data SubjectsYour website visitorsEU individuals whose data is collected via the Plugin

By accepting our Terms of Service, you also accept our Data Processing Agreement (DPA), which governs our role as your Data Processor under GDPR Article 28.

Lawful Basis for Processing​

As Data Controller, you must establish and document a lawful basis for each type of data your Plugin configuration collects:

FeatureSuggested Legal BasisNotes
JavaScript / PHP error trackingLegitimate Interests (Art. 6(1)(f))Can be framed as security/stability interest; document your LIA
Pageview analyticsLegitimate Interests or ConsentDepends on whether data is linked to an identifiable individual
Session recordingsConsent (Art. 6(1)(a))Required — recordings are behavioral profiling data
Lead / checkout dataContract Performance (Art. 6(1)(b))Data entered by the user during a checkout process
WP User ID linkingLegitimate Interests or ConsentLinking anonymous visitor to a known user requires justification

For session recordings, prior, freely given, informed, specific, and unambiguous consent is required before the Plugin may activate recordings for that visitor.

Data Subject Rights — How to Fulfill Them​

GDPR grants eight rights to data subjects. Here is how StorePilot helps you comply:

Right to Access (Art. 15) ✅​

You can view all data linked to a visitor in Dashboard → Visitors → [Visitor Profile], and download the whole of it as one file with the "Export data" button beside the erasure one:

GET /api/v1/sites/{siteId}/visitors/{visitorId}/export.json
Authorization: Bearer <jwt>

The file contains:

  • The visitor record — geolocation (country), device, browser, language, time zone, first and last seen
  • All pageviews
  • All leads / checkout data
  • Session recording metadata, including which pages were filmed and when
  • Clicks, rage clicks, dead clicks and scroll depth
  • Survey answers: what they were asked and what they answered, scores and free text alike
  • Consent decisions: what was decided, by which signal, and when
  • The faults that visitor encountered

Two limits are stated inside the file rather than left for you to discover:

  • Recording footage is described, not embedded. The segments are compressed binary blobs; the export names them and their timings, and the replay itself stays in the dashboard.
  • Error entries are reduced to the fault. A stored error is an aggregate over everyone who hit it, so handing the whole record to one visitor would answer their request with other people's data. What is theirs — that they hit it, what it was, when — is included.

Where the same person used more than one browser and was logged in on both, the linked records are listed rather than merged. A visitor identifier identifies a browser; treating two of them as one person is an inference, and an inference does not belong inside a legal answer. Export each one and hand over both.

Right to Erasure (Art. 17) ✅​

Use the "Erase visitor data" button in the Data requests panel at the bottom of a visitor profile, or call the API:

DELETE /api/v1/sites/{siteId}/visitors/{visitorId}/data
Authorization: Bearer <jwt>

This performs:

  • Permanent deletion of all pageviews, recordings, leads
  • Permanent deletion of chat transcripts and their messages — found by the visitor identifier AND by the email addresses their leads carry, so one whose lead was already erased still goes with them
  • Permanent deletion of survey responses and their answers, whether linked by visitor or only by session
  • Anonymisation of linked error records. The error itself is kept — it is an aggregate over everyone who hit that fault, so deleting it would erase other people's data to satisfy one request — but every trace of the individual goes: visitorId, sessionId, wpUserId and ipAddress are cleared, and the stored diagnostic context is stripped of identity fields and captured request/response data
  • Deletion of the per-session error links, which carry the browser-minted session id
  • Deletion of any heatmap background image rendered from that visitor's recordings
  • Permanent deletion of the visitor record itself

One category is out of our reach: footage recorded before the Platform owned recording storage lives on your own server (wp-content/uploads/wpel-recordings/) or your own S3 bucket. Erasure here removes the rows that point at it; deleting those files is your task, and an Article 17 answer for such a visitor is complete only once you have.

Right to Rectification (Art. 16)​

Lead / checkout data can be edited from Dashboard → Leads → [Lead Detail]. You can update personal fields where a user has requested correction.

Right to Restriction (Art. 18)​

If a visitor requests restriction of processing, you can:

  1. Immediately delete their data using the erasure endpoint above
  2. Or disable recordings for your site in Dashboard → Settings → Recordings

Right to Data Portability (Art. 20) ✅​

The access export above is the portability export: one JSON document, machine-readable, containing everything held about that person. There is no separate endpoint, because Article 15 and Article 20 are the same set of rows asked for by two different articles.

For your own data as a StorePilot customer — your account, your organizations, your sites and their configuration, your invoices and your audit trail — use:

GET /auth/me/export.json
Authorization: Bearer <jwt>

Site API keys, public keys and integration credentials are deliberately not in that file. Configured settings appear with their value replaced by <redacted>, so the export tells you which integrations exist without becoming one of them. Errors, leads and recordings are exported per site as CSV from their own pages, which streams and reports truncation.

Right to Object (Art. 21)​

If relying on Legitimate Interests as legal basis, you must honor objections. The fastest way to comply is to erase the visitor's data (see Right to Erasure above).

Data Minimization Recommendations​

To minimize GDPR risk, consider the following settings:

  1. Disable session recordings unless specifically needed — they collect the most personal data.

  2. IP addresses are anonymised automatically — stored as 203.0.113.0 instead of 203.0.113.42 (and a /48 prefix for IPv6), always, with no setting to store full addresses. The country breakdown is unaffected: the full address is used for the lookup and then discarded.

  3. Understand how long a recording runs — there is no maximum-duration setting. A visit ends after 30 minutes of inactivity, after a completed WooCommerce order, or after a long session is rotated at its segment cap (roughly 25 minutes of continuous activity); each of those starts a new recording.

  4. Do not record checkout pages with payment fields — all input is masked, but as an extra precaution add /checkout/* under Dashboard → Settings → Privacy → Excluded URLs. By default that excludes those pages from session replay only, so you keep their traffic figures; the same screen can widen it to all collection.

  5. Require consent — Dashboard → Settings → Privacy → Require consent before tracking. Nothing is written to the visitor's device and nothing is sent until your consent banner signals acceptance, and nothing is buffered meanwhile. See the Cookie Policy for the two lines of JavaScript this needs.

  6. Global Privacy Control is honoured unconditionally on every site, with no setting to disable it. Nothing is required of you for this. Do Not Track is not honoured — its specification was discontinued in 2019 and no law names it; use the consent gate if you want visitors asked first.

  7. Switch console capture off — it already is, by default. If you turn it on, whatever your own scripts log into the browser console becomes part of the recording, and no masking rule can reach it.

Where Your Data Is Processed​

The Platform runs on servers located in the European Union. Visitor data collected by the Plugin or the loader script is transmitted to, and stored in, the EU. It is not replicated to any other region.

That has two consequences worth stating plainly:

  • If you are an EU business, no Chapter V transfer takes place for the processing we carry out. There is no third country involved, so no Standard Contractual Clauses and no transfer impact assessment are required for it.
  • If you are outside the EU — a US shop, for example — sending your visitors' data to the EU is not restricted by GDPR (which governs data leaving the EEA, not data entering it) and is not restricted by the CCPA either. If some of your visitors are in the EU, the GDPR applies to your collection of their data wherever your business sits, and the fact that we process it inside the EU removes one obligation rather than adding one.

The current sub-processor list, with each one's role and location, is available on request under the DPA §4. We will tell you before adding one.

The Data Processing Agreement covering this processing is at DPA and is incorporated into the Terms of Service.

Data Processing Agreement (DPA)​

By accepting our Terms of Service, you agree to the DPA which covers:

  • Subject matter, duration, and nature of processing
  • Categories of personal data processed
  • Categories of data subjects
  • Our obligations as Data Processor (Article 28(3) requirements):
    • Process data only on your documented instructions
    • Ensure confidentiality
    • Implement appropriate technical and organizational security measures
    • Assist with data subject rights requests
    • Delete or return all data after service termination
    • Make available all information necessary to demonstrate compliance
    • Notify you within 72 hours of becoming aware of a data breach

For a signed PDF copy of the DPA for your records, contact: contact@store-pilot.net

Security Measures (Article 32)​

We implement the following technical and organizational measures:

MeasureImplementation
Data in transitTLS 1.2+ for all API endpoints
AuthenticationJWT with 15-min expiry + bcrypt (rounds: 12) + refresh token rotation
Database accessIn production, MariaDB is reachable only from the application container — only the reverse proxy publishes ports. (The development compose file deliberately publishes the database and Redis for local tooling; it is not the production configuration.)
Storage at restRecording files and heatmap images are stored on the Platform's own server, outside the web root, readable only through the authenticated API. Notification and integration secrets are encrypted with AES-256-GCM.
Access controlAPI keys per site; JWT guards on all dashboard endpoints
LoggingStructured logging with sensitive headers redacted
Key rotationAPI keys can be rotated from the dashboard at any time
Token revocationRefresh tokens are immediately revoked on logout and on rotation

Breach Notification​

In the event of a data breach affecting personal data, we will notify affected Clients within 72 hours of becoming aware, as required by GDPR Article 33. Notification will include:

  • Nature of the breach
  • Categories and approximate number of data subjects affected
  • Likely consequences of the breach
  • Measures taken or proposed to address the breach

Contact for GDPR Inquiries​

Privacy / Legal contact: contact@store-pilot.net

We have not designated a formal Data Protection Officer under Article 37 — at the current scale none is required — and we will appoint and announce one before the scale of processing makes it so.