Skip to main content

Managing Sites

Each WordPress site you monitor is represented as a Site in the Platform. You can manage multiple sites from one dashboard account.

Adding a Site​

  1. Open the organization the site belongs to — the menu on the left lists yours — and press Add site on its Sites page
  2. Enter the site Name (display label) and Domain (e.g. mystore.com)
  3. Follow the wizard: it asks how the site is built and shows the install step for exactly that

The Platform generates a unique API key for this site immediately.

Switching sites. Press the site's name at the top of the menu, or ⌘K (Ctrl+K on Windows and Linux) anywhere in the dashboard. Either opens the organization's Sites page with the search ready: each site is a card with whether it is still collecting, last week's visits, open issues, outages and revenue — the ones needing attention first — and Table shows the same sites as rows. Typing searches every site in every organization you belong to; ↓ moves into the cards, Enter opens one on the same page you were on (Issues stays Issues), and Esc takes you back. Another organization is one click away in the menu under its name.

An organization's Sites page is its home: every site in it with whether it is still collecting, last week's visits, open issues, incidents and revenue, the ones needing attention first. Every site page names its organization above the title; pressing the name opens it.

Site Settings​

Navigate to Sites → [Site] → Settings. The page has seven tabs, named for the question each answers. Every group on a tab keeps its row to one sentence and links here — to the section below that explains the reasoning behind it.

Installation​

Connection shows how this site reaches the platform — the API key for the WordPress plugin and the server SDK, the script snippet for every other platform — and can check the live page for the tag. It is the first tab because it is the one you need before any data exists.

Additional origins lists other hosts the tracking script may run on: a checkout, a staging copy or a mirror on a different domain. The site's own domain and its www. form are always accepted; requests from any host not listed are refused, and the panel names the last one it refused.

caution

Rotating the API key invalidates the previous one immediately. Paste the new key into StorePilot → Settings on your WordPress site, or into your server SDK's configuration, or the site collects nothing.

Site​

The site's name, domain, how it is connected (observed from the first request, not chosen) and when it was created.

Environment name is the word this site's error reports are filed under on the Issues page, where it is a filter. A WordPress install states its own environment and that wins; this field answers for a site running only the script tag.

Notifications​

Every place a message can go is on this tab.

Destinations​

Where alerts go is a list of destinations you add. Each one is one place — an inbox, a Slack channel, a Telegram chat or a webhook — with a name you choose and the events it receives. A destination gets exactly the events it is subscribed to, nothing more; there is no hidden "send everything" default.

FieldWhat it does
NameHow the destination is listed, e.g. Team Slack — critical errors
ChannelEmail, Slack, Telegram or Webhook. The form shows only the fields of the channel chosen
EventsErrors (with the lowest severity to hear about), error spikes, leads, abandoned checkouts, paid orders, chats, uptime, revenue silence. Events this install cannot produce are not offered
SendingOff keeps the destination and stops sending to it

Credentials — Slack and webhook URLs, Telegram tokens, signing secrets — are stored encrypted and never shown again; leave the field as it is to keep the saved value. A webhook destination also has a signing secret, a payload version (1 or 2) and how much of each row to send. Test sends one real message through the saved destination, and Copy puts it on your other sites. See Notifications for every channel and event.

Abandoned checkout alerts​

When a shopper fills in the checkout and does not pay, we tell you. Two settings decide when, and whether it is worth telling you at all. Shown only on installs that report carts (the WordPress plugin).

Wait before alerting (minutes) — 0 sends immediately. A checkout lead is captured the moment the first field is filled, minutes before the payment goes through, so a short wait stops you calling somebody who is still paying. If they buy in the meantime you get the order instead. Alerts go out on a five-minute sweep, so this is a floor rather than an exact time.

Minimum cart value — 0 alerts on every abandoned checkout. It is in your shop's own currency and compared with the basket as it stands when the alert is due, so a basket that grows past it while you wait still reaches you. Setting a floor adds up to five minutes of delay even with a 0-minute wait, because the basket has to be re-read to be compared. See Notifications → Abandoned checkout alerts.

AI​

The site's AI digest, and the organization's morning letter assembled from every site's digest.

AI digest​

A morning brief about the site, mailed to the comma-separated recipients only when the nightly pass wrote something new. Empty switches it off. The written brief needs the AI writer to be switched on for the service; while it is off, the recipients get the day's figures alone, once a morning.

Language of the brief is separate from the dashboard's own language on purpose: a digest is read in a mailbox, often by somebody who never opens the dashboard, and a shop with a Ukrainian owner and an English-speaking developer has one of each. See AI summaries.

Organization morning letter​

One letter about every shop in this site's organization, to one address, sent only while the AI writer is switched on for the service. It belongs to the organization, not to the site, so it reads the same on every one of its sites and only an owner or an admin who sees all of them can change it. See Teams.

Monitoring​

Everything that answers is anything wrong with this site right now.

Uptime monitors​

What we probe from outside, every five minutes. A shop with a storefront and an API has two targets; each keeps its own history and alerts by name. A web page is probed with HEAD and a bot wall counts as up — a WAF answering is your site answering. An API endpoint is probed with GET, needs a 2xx, and a 403 counts as down. Expected status makes one exact status the whole rule, for an endpoint that legitimately answers 401 or 404. An API endpoint can also check what it answers: Response must contain some text, or up to 10 JSON fields (dotted paths such as status) that must each equal a value, all of them at once — so a health endpoint answering 200 with "status": "degraded" counts as down. Switching a monitor off keeps it and its history without probing. See Uptime.

Bot protection​

Our probes come from a datacentre address, which bot protection challenges by design, so without help a live shop can read as down and the installation check cannot see your page.

Bot-protection bypass key is optional. When set, every check we make on this site — uptime and the installation check alike — carries the header X-StorePilot-Bypass with this value, and you allow it through in your WAF. In Cloudflare that is a Custom Rule matching (http.request.headers["x-storepilot-bypass"][0] eq "your value") with the action Skip.

Use a long random value: it is a credential, stored encrypted and never shown back, and it is sent only to this site's own domain — never to a host it redirects to.

A Skip rule does not cover Cloudflare's Under Attack Mode, which is a Security Level rather than a WAF component. While it is on, allow our prober's address directly (IP Access Rules → Allow) or add a Configuration Rule setting Security Level to Essentially Off for the header above. Until one of those is in place the site reads Can't verify rather than a guess: a challenge is served by Cloudflare's edge without touching your server, so it proves nothing either way. More in Uptime → Sites behind bot protection.

Error spike alerts​

Spike detection compares each hour's errors with the trailing 24-hour average, every ten minutes, and alerts through your channels at most once an hour. Threshold multiplier is how many times the average the hour must reach — a site averaging 2 errors an hour at ×5 alerts at 10 — and never under 5 errors either way. See Spike detection.

Shop clock​

Timezone is your shop's own timezone as an IANA name, such as America/Los_Angeles. Alerts are timed and stamped in it. Leave it empty and we use whatever your shop reports about itself; typing a zone overrides that, and clearing the box hands the answer back to the shop.

Alert after this many hours with visitors and no orders tells you when a shop that normally sells has gone quiet. 0 switches the rule off. The default of 24 hours was measured: at 12 it fired about once a week on a shop selling around the clock, which is ordinary quiet rather than news.

Minimum visitors in that time — three visitors and no sale is not news. This protects a small shop; on a busy one it changes nothing. See Notifications → Events.

Integrations​

Services the platform calls with the shop's own key.

Chat provider​

Your shop's chat lives with your chat provider. Connect Brevo Conversations and every conversation appears in StorePilot beside the lead it belongs to; nothing is ever sent back. The webhook URL is shown once and is the credential — rotate it if it leaks. Setup steps are in Brevo Conversations.

Privacy​

Settings → Privacy is the authoritative copy of these switches. The WordPress plugin no longer carries its own privacy tab: it used to, and a setting stored there could override the dashboard, so a shop that switched recording off in the plugin could not switch it back on from here. Every change takes effect within about a minute, on every install method.

The tab has five groups of switches, and each one links to its section below. A sixth group, Find a person, is not a switch: it answers a shopper's access or erasure request by their email or phone — see Find a person.

SettingGroupWhat it does
Stop collectingCollectionStops everything this site sends: page views, errors, recordings, leads and orders. Nothing already collected is deleted
Require consentCollectionNothing is collected from the visitor's browser until their consent is signalled. Orders your shop's server reports still arrive
Session recordingSession replayMaster switch for replay on this site. Off means the recorder is never even downloaded
Record canvasSession replayInclude canvas content in replays. Off by default
Record consoleSession replayInclude browser console output in replays. Off by default
Report console.errorErrors and dataFile what your scripts pass to console.error() as an error. Off by default
Excluded URLsExclusionsOne pattern per line. Matching pages are skipped
Exclusion modeExclusionsWhether an excluded URL skips session replay only, or everything
Lead retentionRetentionDays to keep leads for this site, if you want them kept for less time than the platform default

Collection​

Stop collecting is the switch for the moment you need collection to end now — a legal request, a load test, a flood of traffic you would rather not pay for. It is not the same as removing the plugin or rotating the key: nothing about your install changes, so turning it back on resumes collection within a minute and needs no re-configuration.

What it does not do is delete anything. Your dashboards, exports and retention windows are exactly as they were, and the platform records when the switch was pressed, so a screen that looks empty afterwards says so in those words rather than sending you to check a working plugin. Visitors' browsers stop sending within a minute of the change; a page that was already cached may try for a few minutes longer, and the platform refuses those quietly.

Require consent is the setting that turns StorePilot into an opt-in tool. With it on, nothing is stored on the visitor's device and nothing is sent until your consent banner calls window.StorePilot_grantConsent(). Nothing is buffered meanwhile: a visitor who never accepts is never recorded, rather than recorded and held back. A visitor who has not agreed produces no pageview, no error, no recording and no lead — and this is enforced on the server, not only in the browser, so a form your site forwards from PHP is covered too. What it does not hold back is an order: the WordPress plugin reports each WooCommerce order from your server — number, status, amounts, line items, payment method and billing email — whatever the visitor answered, because it is your record of a sale rather than tracking of the visit. A browser still running an older cached script is treated as not having consented, so its data is dropped rather than stored.

Global Privacy Control is always honoured, on every site, and is not a setting. A browser sending Sec-GPC: 1 is treated as having opted out, whatever else is configured — under the CPRA that signal is a binding opt-out, not a preference.

Do Not Track is not a signal here. DNT: 1 does not suppress collection. The specification was discontinued in 2019, no privacy law names it, and in practice it was switched on in browsers whose owners did not know — while Global Privacy Control, which is recognised in law, stays unconditional. Dropping the advisory signal is what lets the binding one stop being argued with.

Session replay​

Session recording is on by default. It captures mouse movement, clicks, scrolling and page changes so a visit can be replayed. Inputs are masked; passwords, payment and hidden fields are never recorded. Turning it off stops recording this site entirely — errors, page views, leads and heatmaps keep working.

Record canvas adds canvas content as up to 2 image frames per second, only while a canvas is being redrawn; pages without a canvas cost nothing. A canvas is pixels, and no masking rule can reach into pixels, so a signature pad or a product personaliser records exactly as drawn. Turn it on only if you need it, and disclose it in your own privacy notice.

Record console adds the browser console to replays. Console lines can carry anything your scripts log — API responses, cart contents, tokens — and there is no element to mask, so the same caution applies.

These three appear only on installs that can record, i.e. those with a browser.

Errors and data​

Report console.error files what your scripts pass to console.error() as an error, with a stack trace. It is separate from Record console: this one writes into Issues under the type console, catching failures a script caught itself and never let reach the browser as a crash — a payment library reporting a bad key, for example. The arguments are whatever the script chose to log, including third-party scripts you do not control. Repeats are collapsed and rate-limited in the browser.

IP addresses are always truncated before they are stored — the last octet of an IPv4 address, the last 80 bits of an IPv6 one. Country is resolved before truncation, so your geography breakdown is unaffected. There is no setting to store full addresses.

Exclusions​

Excluded URLs takes one path pattern per line. * matches within a path segment and ** across segments; only the path is matched, so query strings are ignored. Exclusion mode decides what an excluded page skips: session replay only is the usual choice — you keep a checkout's traffic numbers without filming it — or everything.

Retention​

Lead retention empty means the default: 365 days from November 3, 2026 (until then, empty keeps leads until you set a number). The same window covers chat transcripts and the customer's email address on an order — the order itself, with its amounts and dates, is kept. Set a number, shorter or longer, if your own retention policy requires one; it replaces the default for all three. GDPR storage limitation is the shop's obligation, and this is where you meet it.

Everything else is on the platform's own schedule: page views 90 days, session recordings 14 days, errors 180 days, visitor records 400 days, aggregated statistics 2 years.

See GDPR and the Privacy Policy for what is retained and for how long.

Find a person​

A shopper who writes to you asking what you hold about them — or asking you to delete it — knows their email address and their phone number, not which browser they used. Find a person takes either or both and looks across this site:

  • leads with that email or phone — including a checkout filled in with JavaScript off, a Blocks checkout, a lead sent by the Node SDK, or one from another device;
  • orders placed with that email, and every order those leads produced;
  • chats your chat provider sent with that email;
  • survey answers in which they typed that email or phone;
  • and every visitor (browser) those rows name, with its recordings, page views, clicks and the rest of its history.

The address is matched ignoring case and surrounding spaces. A phone number is matched by its digits, exactly — +380 (67) 123-45-67 and 380671234567 are the same number, but a number stored without its country code is not matched by one typed with it, so if nothing turns up, try the other form. Find shows only how many of each it found, never the rows.

Then:

  • Export data downloads one JSON file with everything found — the same file the visitor page's export produces, with every browser folded in. Available to members and above.
  • Erase deletes the leads, chats and survey answers, and erases every visitor listed exactly as the visitor page's erase does. Orders are not deleted: they stay in your revenue with their amount, status and dates, and the email is removed — your books are yours, the address is theirs. Erasing is permanent and needs an admin or the owner. Each erase is written to your organization's audit log with the counts, never the address.

Viewers do not see this group.

Internal traffic​

Settings → Internal traffic lists your own team: email addresses, email domains and office IP ranges, plus a link that excludes the browser it is opened in. It used to be a group on the Privacy tab; it has its own because it decides whose numbers you are reading, not what is collected about your visitors. Excluding a page is still on Privacy, under Exclusions.

It is how a shop says this is us. Anyone it names is not a customer, and the two halves of that are treated differently on purpose:

  • Visits are not collected at all. A request from a listed office range, from a WordPress user who can manage the shop's orders, or from a browser that opened the Exclude this browser link on the settings page writes no pageview, no session, no recording and no unit of your plan's quota. A link ending in sp_internal=0 switches that browser back on.
  • Orders and checkouts are kept, and marked. A test order is money that moved through your shop, so deleting it would change your own history. It stays in the database and simply drops out of revenue, conversion, average order value and the three lists — each of which prints how many rows it withheld, with one press to show them.

Email addresses and domains (without the @ — useful for an agency that works on the shop) are matched when an order or a checkout is written, which is the only moment anyone's address is known. Addresses already stored can be re-marked by support with orders:mark-internal.

Exports​

Scheduled exports are a standing order: the platform generates CSV files on a schedule and mails the recipients a link. The files come from the same exporter the API serves for each list, without the raw form fields column — a scheduled file is opened by whoever reads a mailbox. Generated files are kept for 7 days and then removed: each is a copy of personal data, and copies are not kept longer than they are useful. See Scheduled exports.

Recording storage​

There is nothing to configure. Session replay data is stored by the platform, not on your own server and not in a bucket you provide — earlier versions did it the other way round, and the per-site S3 settings that went with that are gone.

Deleting a Site​

  1. Go to Sites → [Site] → Settings
  2. Scroll to the bottom
  3. Click Delete Site
danger

Deleting a site permanently removes all errors, recordings, leads, pageviews, and visitor data associated with it. This cannot be undone.