Privacy

Who we are

The controller of the personal data described here is Martin Clavell, trading as SuiteAnalytics (martinclavell.com), at [to be supplied: the postal address the operator can be reached at, which a data protection notice must publish]. Requests about your data — access, correction, erasure, a copy, or the deletion of a storefront’s audits — go to the support address in the footer of this site.

The one thing we deliberately do not store

A SuiteCommerce storefront ships its configuration to every visitor, and that configuration often contains third-party API keys. When we find a value that looks like a credential we record where it is, how long it is, which character classes it uses and its entropy — the path, the length, the shape — and we discard the value itself. You get what you need to rotate the key. We never hold a database of other people’s keys, because a database like that is a liability no amount of encryption makes acceptable.

We do not train models on your data

No model is trained or fine-tuned on anything we hold about you or your storefront. Part of a report is written by a language model, and every one of those calls is inference: we send a slice of the evidence we already collected, the slice is restricted to declared sources and checked for redaction before it leaves, and the answer comes back and is stored in your report. Calls to OpenAI are sent with retention switched off, so the provider is asked to keep nothing beyond answering. We keep the answer, the model and the cost; we do not keep the prompt, only a hash of it. The providers that receive those calls are named in the sub-processor list with what each one can see.

We also compute benchmarks, so a report can tell you where you sit against comparable storefronts. A benchmark point records a release family, a page type, a metric, a value and the month. It carries no hostname, no account and no audit id, so it cannot be traced back to the site it came from — by us or by anyone who obtained the table.

What we hold about people

Thin by construction: the account holder’s e-mail address and name, the billing contact Stripe holds, and hashed addresses in the audit log. There are no advertising cookies, no third-party analytics scripts, and no visitor identifier. A page view records the path, the referring host, a viewport bucket and the hour, against a visitor hash salted with a value that rotates daily — so two visits on two days cannot be joined, by us or by anybody who obtained the table.

What we crawl

Only what a storefront serves publicly to an anonymous visitor. Nothing behind a login is fetched, and no order, customer or account data is read — that is a scope decision, not a setting. Our crawler identifies itself on every request and says what it honours and how to turn it away.

The crawler carries no cookie jar. Every request is made as a first-time anonymous visitor, and a Set-Cookie a storefront sends back is discarded: we record the cookie’s name and its flags, never its value. So we hold no session from any storefront we have read, which is the part of this that would matter if we were ever breached.

Why we are allowed to

Account data, and audits of a domain whose owner verified it and asked for them, rest on our contract with that customer. Audits requested by an agency account, and the anonymous pre-check somebody runs from our home page, rest on a legitimate interest in auditing a publicly served commercial website — balanced by the things that make it bearable for the site being read: a crawler that names itself on every request and links to a page explaining how to refuse it, rate budgets small enough that a storefront built for shoppers does not notice, an owner opt-out that no account tier overrides, and a blocklist that refuses a hostname before a request is made. That balancing test is written down and reviewed at each security review rather than assumed.

How long we keep it

When a plan ends or a payment fails, your history is kept on the old plan's terms for 30 days before the new plan's shorter window applies, so a card that fails on a Friday does not delete a year of reports on Saturday.

Be clear about what the sweep reaches, because “we delete it after N months” would be too strong. What expires on the periods above is the raw artefacts — the captured pages, the DOM dumps, the screenshots, the evidence pack and the PDF — together with the findings, the reports, the per-page snapshots and the progress feed. What does not expire is the record that an audit ran and what it scored, the list of URLs we have seen on the domain, the catalog and category rows, and the model output stored against a report. Those persist until the organisation is deleted, because the score history and the trend line are read from them. Deleting the organisation removes all of it.

Who else touches it

The providers that process data on our behalf are listed at /subprocessors, with what each one is for and what each one can see. Enterprise and Partner accounts can sign the data processing addendum, which attaches that list as its schedule.

If you own a storefront we audited

You do not need an account with us, and you do not need to have asked for the audit. If you control the domain, you can tell us to delete what we hold about it and we will, within 30 days of confirming you control it. We will ask you to prove that the same way a customer does — an e-mail at the domain, a DNS record, or a tag in the site’s head — because otherwise the request is an instruction from a stranger to destroy somebody else’s records.

What we delete:

• Every stored audit of that hostname and everything under it — the captured pages and headers, the DOM snapshots, the screenshots, the bundle evidence, the findings, the reports and their PDFs, and the comparisons between them.
• Whatever a language model was sent about the site, as it is stored inside those reports and nowhere else.

What survives, and why each one:

• The record that the audit happened. The audit log keeps the domain, the account that requested it and when. That entry exists to protect you rather than us — it is what lets us tell you who audited your storefront — and it is kept for the period in the table above.
• Benchmark points. They carry no hostname, no account and no audit id, so there is nothing in them to identify as yours and nothing to remove. That is the same property that makes them safe to hold at all; we are not declining, we genuinely cannot find them.
• The instruction itself. If you also ask us never to fetch the domain again, we keep the hostname on a blocklist, because forgetting it is how we would crawl you again next month.

You can also stop us before there is anything to delete. Our crawler page explains how to refuse the user agent, and verifying the domain lets you switch off agency audits of it permanently, with no appeal path and no account tier that overrides it.

Deleting an account

Ask us and we delete the organisation. That removes its audits, snapshots, findings, reports, comparisons, alerts, schedules, destinations, memberships, sessions and credit ledger, and queues a purge of the stored files those rows pointed at — the raw HTML, the DOM dumps, the screenshots and the PDFs. Each purge lists its storage prefix empty before it reports itself finished, so “the files are gone” is something we check rather than something we assume.

Three things survive it, deliberately. The audit log stays with the organisation detached from it, because it is the record that an audit of somebody else’s domain happened. Payment records are held by our payment processor for the statutory period and are theirs to delete. And a person’s user row survives if they belong to another organisation — deleting one customer should not sign them out of another.

It is run by an operator rather than by a button in your settings, and it refuses while a Stripe subscription is still live — cancel first, or we would leave the processor billing a customer that no longer exists.

Your rights, and complaining about us

Where data protection law applies to you, you have the right to ask what we hold about you, to have it corrected, to have it erased, to get a copy in a portable form, to object to processing we base on a legitimate interest, and to complain to your supervisory authority. Ask at the address above; we answer within one month, and we do not charge for it. Where we must notify a personal data breach, the General Data Protection Regulation sets that at 72 hours after we become aware of it, and we will tell you directly where it is likely to be a high risk to you.