Privacy Policy

1. Who we are and how to reach us

Controller: SITE QWALITY INC., a company incorporated in Delaware, United States. A Delaware corporation.

Registered postal address:

SITE QWALITY INC.
254 Chapman Rd Ste 208 # 10720
Newark, Delaware 19702
United States

Privacy and data-rights contact: privacy@siteqwality.com. This mailbox exists, it is monitored, and it is the intake point for every request described in this notice. You can also write to the postal address above.

Security contact: security@siteqwality.com. Support: support@siteqwality.com.

Data protection contact: Shawn Allen, Chief Executive Officer, ceo@siteqwality.com, is the named person accountable for data protection at Site Qwality. He is not a Data Protection Officer and we do not describe him as one. We have not appointed a statutory Data Protection Officer, and having assessed Article 37 we do not consider one to be required. We publish an accountable name anyway, because “no DPO is required” is not the same as “nobody is accountable”. For rights requests use privacy@siteqwality.com, which is monitored; the address above is for escalation.

Representative in the EU and the UK: we have not appointed a representative in the European Union under Article 27 GDPR, and we have not appointed a representative in the United Kingdom. We do not intend to appoint either. Send anything you would send to a representative to privacy@siteqwality.com, or to the postal address above. It reaches us directly and we answer it ourselves.

2. Two different roles, and why it matters to you

Site Qwality handles personal data in two distinct capacities, and your rights work differently in each.

As a controller, we decide why and how data is processed. This covers: the people who hold accounts with us, billing contacts, people who contact us, visitors to our marketing websites, domain registrant details returned by WHOIS lookups when a customer monitors a domain, and our own staff records.

As a processor, we process data on a customer’s documented instructions and the customer is the controller. This covers everything our SDK and our ingest endpoints collect on behalf of a customer: real user monitoring, session replay, logs, metrics, traces, monitoring check results, and the notification destinations a customer configures. Our Data Processing Addendum governs that processing.

If you are an end user of a website that has installed Site Qwality, we are a processor for your data. Send your request to the operator of that website. If you send it to us, we will pass it to them where it is lawful to do so, and we will tell you that we have done so.

3. What we collect, where it comes from, and why

We do not ask for and do not want special categories of data as defined in Article 9 GDPR. The Services are not designed to hold them.

4. Session replay: what it actually records

Session replay is off until a customer creates a session filter for an application with replay capture enabled. That filter is the only thing that starts a recording, and deleting or disabling it stops new recordings. When a recording is running it captures the rendered page as the end user sees it, and we want to be exact about the defaults rather than reassuring.

• Page text is not masked by default. Whatever text is rendered on the page is recorded, including text behind a login. The customer can turn text masking on per application.
• Input masking is a per-application setting, and until a recent fix it was stored switched off on every application at the moment it was created, whether created in the dashboard or through the API. It stayed off unless someone opened the application’s privacy settings and turned it on. We have not altered the stored settings of existing applications, so any application you have not explicitly changed is still recording form input values unmasked. Check the setting on every application you operate.
• Card numbers are not capturable where the payment field is a cross-origin element from a payment provider, because the recorder cannot see inside another origin’s frame. That is true of our own checkout.
• Element-level control uses three rrweb CSS classes, and they do three different things. Add them to the element’s class attribute, for example <div class="rr-mask">. They are class names, not HTML attributes: <div rr-mask> has no effect. Whether a class covers nested elements differs per class, so the three are described separately rather than together.
  • rr-mask replaces the text inside the element, and inside everything nested within it, with asterisks. It cascades to descendants. It masks text only: it does not mask input values, and it does not mask attributes such as placeholder, alt, title or aria-label, which are recorded as written.
  • rr-block stops the element being recorded at all. The recording keeps a blank placeholder of the same size and does not descend into it, so everything nested inside is covered too.
  • rr-ignore stops input events being recorded on the element that carries the class. It does not cascade. The class is read from the element that received the event and nothing walks up the tree, so <div class="rr-ignore"><input name="ssn"></div> gives that input no protection at all. The class has to be on the <input> itself. Even placed correctly it suppresses only later typing: a value already present in the field when the recording starts is still captured in the initial snapshot unless input masking is on.
• Input masking covers a fixed list of input types and nothing else. When it is on, the value is replaced with one asterisk per character before it leaves the browser, for these input types and no others: color, date, datetime-local, email, month, number, password, range, search, tel, text, time, url and week, plus <textarea> and <select>. Three things it does not cover: an <input type="hidden">, or any other type outside that list, keeps its value; a radio button or checkbox has its value string recorded unmasked alongside its checked state; and no element attribute is ever masked. When input masking is off, type="password" is the only type masked.
• rr-unmask, data-sq-mask and data-sq-unmask do not exist. Older material of ours described element-level opt-in through those names. The recorder we run has never supported any of them, and applying them changes nothing.

5. Our legal bases

Where we rely on legitimate interests you can object at any time. See section 9.

6. Cookies, tags and tracking on our websites

Our marketing websites can load four third-party tags: Google Analytics 4, Google Ads conversion tracking, Microsoft Clarity session recording and an affiliate attribution script. We also set four first-party cookies of our own. The Cookie Policy names every one of them, along with every browser-storage key we set. It does not name the cookies those third parties set once loaded, because we cannot read those from our own source, and it says so rather than guessing.

In the European Economic Area, the United Kingdom and Gibraltar those four tags are behind a consent gate. The decision is taken on our server before the page is assembled, so for a visitor who has not agreed, the tags are not in the page at all rather than being loaded and then suppressed. The banner offers accept, reject and a per-category choice across three categories: analytics, advertising, and session recording. A Cookie preferences control at the bottom of every page reopens the choice, and withdrawing consent is as easy as giving it. Your choice is stored for 180 days, and if we change the categories or the vendors behind them we ask again rather than relying on a choice you made about something else.

Outside those countries the banner is not shown and the four tags load as they did before. A recorded refusal is honoured everywhere; an absence of one, outside the gated region, is not treated as a refusal. We would rather state that limit than describe the gate as though it were global.

The record of your consent exists only in your own browser. These are static sites with no database, so there is no server-side consent log. That is a real limitation on our ability to demonstrate a given person’s consent after the fact, and we are not going to imply we hold a ledger we do not have.

We honour Do Not Track and Global Privacy Control on our marketing websites. A DNT: 1 or Sec-GPC: 1 request header, or the equivalent browser property, is treated as a refusal in every region, and we do not show a banner on top of it. We do not act on either signal in our dashboard or in our SDK. Nothing at app.siteqwality.com, and nothing in the SDK a customer installs on their own website, reads navigator.doNotTrack, Sec-GPC or navigator.globalPrivacyControl. The two halves are different and we state both.

We do not sell personal data for money. Our marketing sites do load Google Ads conversion tags, and under some United States state privacy laws that counts as sharing personal information for cross-context behavioural advertising. We would rather describe it than claim an exemption.

7. How long we keep it

Retention differs sharply by category, and several stores have no automatic deletion in place today. Publishing a tidy single number would be untrue. The Data Retention page lists, for every category, either the window our systems actually enforce or a plain statement that no automatic deletion is in place yet.

Two rules apply to the windows your plan sets. A retention window runs from the moment a record is written, not from the end of a billing period. And changing your plan never shortens data that is already stored: a plan change applies forwards only, by design. Whether a window can also be lowered by a setting, rather than by a plan, is answered on the Data Retention page category by category, because the answer is not the same for every category.

8. Who we share it with

We use third-party providers to run the Services. The Subprocessors page is the authoritative, dated list. It separates providers engaged for every customer, integrations a customer switches on themselves, and vendors that only touch our website and corporate operations.

We also disclose personal data where we are legally required to, and to professional advisers where necessary. If we are ever party to a merger or acquisition, personal data would be one of the assets transferred, and we would update this notice before that took effect.

9. International transfers

Site Qwality is a United States company. All of our own infrastructure is in the United States, in the AWS us-east-1 region: the transactional database, the analytics store, all object storage, all serverless compute and the execution of every monitoring check. There is no European Union or United Kingdom data-residency option. If we bring another region into service we will update this notice before we do.

That sentence is scoped to our own infrastructure on purpose, because “United States only” without a qualifier would overstate it in two ways. First, our content delivery network terminates connections at edge locations that include Europe; the paragraph below says what that means. Second, some of the providers we depend on operate global networks or process outside the United States, The Subprocessors page states each provider’s location. Read that page alongside this section.

Where personal data protected by the GDPR or the UK GDPR reaches us, Standard Contractual Clauses (and the UK Addendum where required) are available through our Data Processing Addendum and on request. We do not claim certification under the EU-US Data Privacy Framework.

Our content delivery network. We operate six content delivery distributions and all six use a price class that includes European edge locations, so a request from Europe is terminated in Europe rather than in the United States. Two of the six serve public files only: the monitoring script and status-page branding images. Two serve status pages, one of ours and one on a customer’s own domain. Two front our internal staff portal, one for the interface and one that proxies staff requests to our API, which carry customer account data. None of the six has access logging enabled, so we keep no record at the edge of who requested what. Cached copies of the content itself are held at those edge locations, including in Europe, for the lifetime of the cache.

10. Your rights

If the GDPR or the UK GDPR applies to you, you have the rights below. We answer within one month of receiving your request. Where we have reasonable doubts about who you are we may ask for information to confirm it, and where we do, that month runs from the point we receive it. We will tell you if we need to extend by up to two further months, and why.

There is no fee. If a request is manifestly unfounded or excessive, in particular because it repeats one we have already answered, we may charge a reasonable fee reflecting the cost of answering it or decline to act, and we will explain which and why.

Send any request to privacy@siteqwality.com. Please do not use the contact form on our website for a rights request: that form is operated by a third party.

We want to be honest about how these are fulfilled today. None of them is a self-service button in the product. Each is a manual operation carried out by our staff, and the sections below say where that has practical consequences for you.

• Access (Article 15). Ask us and we will assemble a copy of the personal data we hold about you. There is no automated subject-access export in the product; we compile it by hand across our databases, object storage and our providers.
• Rectification (Article 16). An account administrator can correct a user’s name in the dashboard. An email address cannot currently be changed, by you, by an administrator or by us: the only route is to remove the user and re-invite them at the correct address, which leaves the old address reserved. If that is a problem for you, contact us and we will handle it manually.
• Erasure (Article 17). You can ask us to delete your data. Closing an account today marks the account deleted and ends access to it; it does not by itself erase every stored copy. If you want data erased rather than retained, ask us explicitly at privacy@siteqwality.com and we will carry out the deletion and confirm what was deleted and when. There is no self-service account-deletion control in the dashboard. Two limits apply. Automated database backups are retained for 7 days, so erased data can persist in a backup for up to 7 days after we delete it from live systems; we do not restore a backup in order to re-apply an erasure. And we keep billing, invoice and tax records for the period the law requires.
• Restriction (Article 18). We have no automated way to mark data as restricted while a dispute is resolved. Contact us and we will handle it manually.
• Portability (Article 20). The product exports three things to CSV today: HTTP check results (up to 50,000 rows), the monitor uptime summary, and telemetry logs (up to 10,000 rows). Nothing else is covered by a self-service export. For any other category, ask us and we will produce it.
• Objection (Article 21). You can object to processing we base on legitimate interests. You can object to direct marketing at any time and we will stop. If you are an end user of a customer’s site, our SDK has no end-user opt-out surface today; your objection has to go to the operator of that site, who controls whether the SDK runs at all.
• Withdrawing consent (Article 7(3)). Where we rely on consent you can withdraw it at any time. Withdrawal does not affect processing that already happened.
• Automated decision-making (Article 22). We do not carry out profiling or automated decision-making that produces legal or similarly significant effects.

If you are in California or another United States state with a comparable law, the same intake address applies and we do not discriminate against you for exercising a right.

11. Complaining to a supervisory authority

You have the right under Article 77 GDPR to lodge a complaint with a supervisory authority, in particular in the country where you live, where you work, or where you believe an infringement occurred. In the EEA, the European Data Protection Board publishes the list of national authorities. In the United Kingdom, the authority is the Information Commissioner’s Office.

You do not need to contact us first. We would like the chance to fix it, but that is your choice.

12. Children

The Services are a business product and are not directed to children under 16. We do not knowingly collect personal data from anyone under 16. We have chosen 16 rather than a lower figure because the age at which a child can consent for themselves under Article 8 of the GDPR is set by each member state and ranges from 13 to 16, so 16 is the only single number that is correct everywhere we operate.

We do not operate an age gate: there is no age check anywhere in the signup flow, and we are telling you that instead of implying one exists. If you believe a child has given us personal data, contact privacy@siteqwality.com and we will delete it.

13. Email we send you

There are two kinds, and they behave differently on purpose.

Alerts and service email. Monitor up and down notices, expiry warnings, quota notices, invitations, welcome and support mail. These carry no unsubscribe header. They exist because you or an account administrator configured them, and an alert you cannot receive is worse than no alert. The way to stop them is to remove or change the destination in the dashboard, or to close the account.

Lifecycle and marketing email. A small number of messages sent to accounts that have gone quiet carry a List-Unsubscribe header addressed to a monitored mailbox. Reply to it, or write to support@siteqwality.com, and we will stop. An earlier version of this notice promised to remove you from all correspondence on request. That was never accurate for contractual alerts and it has been removed.

For commercial email we identify ourselves accurately and do not use misleading subject lines, and we act on opt-out requests promptly.

14. How we protect it

The measures below are in place today. This list is deliberately exhaustive: where a measure is not listed here, do not assume it is in place.

• Every connection between you and the Services is encrypted. All eight of our public API domains enforce a minimum of TLS 1.2, and our websites redirect HTTP to HTTPS.
• Object storage is encrypted at rest with AES-256 using provider-managed keys, and every bucket has public access blocked on all four settings. The analytics data volume that holds telemetry, real user monitoring and replay data is encrypted. Our message queues are encrypted at rest.
• Passwords are hashed with Argon2 and never stored in plain text. Primary authentication is delegated to a specialist identity provider that holds the credential.
• Multi-factor authentication is available to customers, using time-based codes or passkeys, and it is mandatory for Site Qwality staff. The staff organization in our identity provider requires a second factor on every staff sign-in. That requirement is a policy held in the identity provider rather than a setting in our own code, so it is enforced at sign-in and you will not find it in our repositories.
• API keys are stored only as a one-way SHA-256 digest. We keep the first eight and last four characters so you can recognise a key in a list. The secret itself is never written down anywhere we can read it.
• Role-based access control, enforced from the session token rather than from a local database column.
• Mutating authenticated requests are recorded to a customer-readable audit log with actor, action, method, path, result, request IP address and user agent, including requests that were identified and then denied. The write is best-effort by design so that a logging failure can never fail your request, which means a database outage can leave a gap in the log. Two endpoints that use a mutating method only to carry a read query are exempt.
• Every Site Qwality staff administrative request is written to a separate staff audit log, including a recorded reason whenever a staff member acts inside a customer account.
• Card data never reaches our systems. It is entered into a payment element served by our payment processor on its own origin.
• Bot mitigation on the signup endpoint, and request-rate throttling on eight of our nine API gateway stages. The ninth is an abandoned test gateway that serves no part of the Services and holds no data; it has no throttle and it should be deleted.
• Queries against our transactional database use bind parameters rather than assembled SQL, with no string-concatenated SQL anywhere on that path, and every data-plane read is scoped to an account identifier as a typed value before it reaches storage.
• Deletion protection on the production database, with automated backups retained for 7 days.

We hold no security certification of our own. We have no SOC 2 report, no ISO 27001 certificate and no published penetration test. Where SOC 2 or ISO 27001 is mentioned anywhere in relation to our infrastructure, that is the certification of our infrastructure provider, not ours.

15. Personal data breaches

If a personal data breach affects data we process on a customer’s behalf, we notify that customer without undue delay and in any event within 72 hours of becoming aware of it, as set out in our Data Processing Addendum. Where we are the controller, we notify the competent supervisory authority under Article 33 and, where the breach is likely to result in a high risk to you, we notify you directly under Article 34.

An earlier version of this notice said 7 business days. That conflicted with our own contractual commitment. The commitment is 72 hours.

16. Changes to this notice

We date this notice at the top of the page. When we change it we update that date. For a change that materially affects how we handle your data, we will say so on this page rather than changing it silently.

17. Questions

Write to privacy@siteqwality.com. Please do not use the contact form on our website for anything involving your personal data: it is operated by a third party, and once you load it, it runs in a frame from that vendor rather than on our page. Section 3 describes it.