Privacy Policy

Last updated: September 13, 2026

This Privacy Policy describes how ABTestly ("ABTestly", "we", "us", or "our") collects, uses, stores, and shares personal information when you use our website at abtestly.com, our dashboard, our API, our browser extension, and our snippet that runs on customer websites (collectively, the "Service").

We take your privacy seriously. This policy explains what we do with your data and your rights regarding that data. If you have questions, contact us at privacy@abtestly.com.

1. Who we are

ABTestly is operated as an independent software service. We are the data controller for personal data collected about you when you sign up for our Service.

When our customers use ABTestly to run experiments on their own websites, they act as the data controller for their end-users' data. ABTestly acts as a data processor in that relationship. See Section 9 for more details.

Contact:

• Email: privacy@abtestly.com
• Address: Available on request from the above email.

EU/UK Representative under Article 27 GDPR:

We have not yet appointed a representative in the European Union or the United Kingdom. Until we do, customers and users located there can contact us directly at privacy@abtestly.com, and we will publish the representative's details here once one is appointed.

2. Information we collect

2.1 Information you provide to us

When you sign up and use ABTestly, we collect:

• Account information: your first name and your email address, collected through our authentication provider Clerk. We hold no last name, and there is no column for one. Your password and your sign in sessions stay with Clerk: we check the token Clerk issues on each request and store nothing out of it.
• Organization information: the name of your organization, your role, and the team members you add.
• People you invite: the email address of everyone you invite into your workspace. We store it when the invitation is created, whether or not it is ever accepted. That is personal data about another person, held because you asked us to invite them.
• Payment information: billing name, address, and payment method details. Payment information is collected and processed by our payment provider Paddle. We do not store full credit card numbers on our servers.
• Connected Google Analytics accounts: if you connect GA4 to one of your sites, we store the email address of the Google account you authorized with, and a refresh token for that account, one pair per site. The refresh token is encrypted with AES-GCM 256 before it is written.
• Communications: any information you provide when contacting our support team.
• Experiment configuration: the names, targeting rules, variant code, and other configurations you create within the Service.

2.2 Information we collect automatically

When you use our dashboard or API, we collect:

• A record of every change you make: each action that changes something is written to an activity log, with the account that took it and a timestamp. Creating and editing experiments, publishing, editing goals and audiences, inviting people, changing roles and site permissions, and the billing events we receive are all recorded this way. Section 7 states how long each kind is kept.
• One last active timestamp per workspace: overwritten whenever a member makes a request, so that we can tell a live workspace from an abandoned one. It is one value, not a history.
• Permission checks that disagreed: where our per site permission check reaches a different answer from the older role check, we record that single mismatch, with the account, the route, and both answers, so that we can correct it.
• Error data: where error reporting is configured for a surface, an error sends the message, the stack trace, the route, and the release to Sentry, identifying you by the user id our authentication provider gave you rather than by your email address. On the dashboard it also sends a replay of that browser session up to the point of the error, with every piece of text masked and all images, video and canvas content blocked, and it sends performance timing for one page load in a hundred. A surface whose reporting key is not configured sends nothing at all.
• Your IP address, for the chat widget only: the chat widget runs on the dashboard as well as on our public websites. If you send a message through it, your IP address is stored in plain text for one hour so that we can limit abuse of the widget, and it then expires.
• Cookies and similar technologies: see our Cookie Policy section below.

The dashboard loads no product analytics. There is no Google Analytics on it and no third party product analytics tool of any kind, so we do not measure which pages you open or which features you use, apart from the five account moments described below, and no dashboard page view is recorded as usage data anywhere. We do not collect your browser, your operating system, your screen size, or your language preference. Apart from the chat widget above, neither the dashboard nor the API records your IP address or any location derived from it: the rate limits that protect the API are counted against your account, not against your address. The one case in which a dashboard session is captured at all is the error replay described above, and that happens only on an error and only where error reporting is configured.

We record five moments in the life of every workspace created from September 13, 2026: when it is created, when it starts a trial, when our snippet is first detected on one of its sites, when its first experiment starts, and its first payment. They are stored with the workspace, like the rest of your account information, and are only shared as the next paragraph describes.

If analytics cookies are accepted in your browser when you create a workspace, or within its first day, our servers also send those five moments to Google Analytics. With the signup we send which kind of sign in your account uses, when we know it (email, or a provider such as Google); with the trial, the plan and billing period; and with the payment, the amount before tax, the tax, the currency, Paddle's transaction reference and, for each item bought, its product name, Paddle price reference, quantity, unit price and any discount. Each is sent with the Google Analytics visitor identifier your browser already holds from abtestly.com and, when the moment happens during your visit, its session identifier. Whether each may be used for advertising follows the marketing category in our cookie banner, read at the moment we send it: granting that category marks the moment as available for advertising, and anything else marks it as not for advertising, including no answer at all and a grant that has since run out. None of them is ever sent with your name, your email address, your site's address or anything from inside your experiments. We read those identifiers only for the person who created the workspace, only in its first day, and only while analytics cookies are accepted. If you withdraw analytics consent in our cookie banner, the banner sends the value of your _ga cookie to our servers, only so we can delete the matching identifiers, and then removes the Google Analytics cookies; we send nothing more, unless you grant analytics again within that first day. If you withdraw in another browser, we delete them the next time you open the dashboard there. We also delete them when that consent reaches the end of its 180 days. Moments already sent stay in Google Analytics under Google's retention rules for our property.

2.3 Information collected by our snippet on customer websites

When our customers install the ABTestly snippet on their websites, the snippet collects the following information about their end-users:

• Visitor identifier: a UUIDv7 generated in the end-user's browser and stored both in localStorage and in a cookie. The cookie is set on the registrable domain, so one identifier follows the visitor across every subdomain of that site. A UUIDv7 is not wholly random: 48 of its 128 bits are the millisecond at which it was created, so the identifier itself records when that browser was first seen. It keeps variant assignment consistent. It is also what counts monthly tracked users for billing, as described in section 3, what separates a new visitor from a returning one, and what heatmap records are grouped by. In experiment results and in the raw event archive it is stored as a salted hash. In heatmap storage it is stored as the identifier itself.
• Experiment exposure data: which experiments the end-user was exposed to and which variants they saw.
• Page address, in reduced form: the exposure and goal beacon carries no page address at all. Where an address is needed, it is reduced in the browser first. An error report carries the origin and the path, with the query string and the fragment removed before sending. Speed measurements carry a page family token chosen from a fixed list rather than an address. Heatmaps carry a path level page key, plus only those query parameters the customer has nominated.
• Referring channel, not the referrer: the referring URL is never sent. The snippet reduces it in the browser to one of four values, campaign, search, referral, or direct, and sends that value.
• Device class, browser, and operating system: derived at our edge from the request's user agent header and stored as those three values. The snippet does not send the user agent, and we store no user agent string. A mobile or desktop class is derived the same way. Screen and viewport dimensions are not collected.
• Location: what we store with experiment results is the country. Targeting rules can also use region and city, so the snippet asks our edge for country, region, and city, and keeps region and city in the visitor's own sessionStorage for 6 hours.
• IP address, read and not stored: the visitor's IP address is read at our edge so that any addresses the customer has blocked can be filtered out. It is not written to any store. Where a visitor is blocked, the only thing recorded is which rule blocked them.
• Language: read in the browser where a targeting rule needs it, and not transmitted.
• Interaction data, where the customer has turned heatmaps on: clicks and where they landed, clicks that hit nothing, episodes of repeated frustrated clicking, how many milliseconds each element was visible, how far down the page the visitor scrolled, the CSS selector of the element involved, and a short text string taken from that element so it can be recognized again.
• Form friction, where heatmaps are on: for each field, its type, which form on the page it belongs to, how long it was focused and how many times, whether the browser reported it invalid when focus left it, and whether it was reached, focused, and submitted. What was typed into it is not read.
• Page performance: Core Web Vitals and related timings for the page, and telemetry about how our own snippet was delivered, including the connection type the browser reports.
• Revenue, where a revenue goal is configured: the order value, the currency, the customer's own order identifier, and whether that order was later refunded, together with the refund identifier.
• A bot likelihood score for the request, from Cloudflare's bot management, so that automated traffic can be told apart from human traffic in results.
• Errors thrown by variant code: where a customer's variation code throws, the exception message and the stack trace, with values scrubbed out in the browser before they are sent.
• Cookies and localStorage entries: set by the snippet. Section 10 lists every one of them by name.

We do not attach a name or an email address to the visitor identifier. Whether it can be connected to a person is not entirely in our hands: where a revenue goal is in use, the customer's own order identifier is stored beside the identifier, and the customer can resolve that order to a named person in their own records.

During ordinary visitor traffic, the snippet does NOT collect:

• The contents of form fields. The snippet reads a field's tag, its type, whether it is editable, and whether the browser considers it valid. It does not read what was typed into it.
• Mouse movement or keystrokes. The snippet binds no mousemove listener, no pointermove listener, and no keyboard listener.
• A recording of the end-user's session. Nothing records the sequence of what a visitor did to a page.
• The end-user's name or email address as a field of its own. Nothing the snippet sends has anywhere to put either. The paragraph below explains where identifying text can nonetheless reach us.

Page snapshots, where the customer has turned heatmaps on. A heatmap has to be drawn over a picture of the page, so a picture of the page is what we take. Where heatmaps are on for a site and a live experiment is running on the page, the snippet serializes the rendered document on the initial page view and sends it to us, with the stylesheets inlined so that the page can be drawn again later. Every visitor who loads such a page contributes one: there is no threshold to cross and no portion of traffic that is left out. What is masked as the copy is made: the value of every input is replaced with asterisks, and the default masking tier, which is what a site gets unless it asks for the other one, also replaces numbers, email addresses, and postcodes wherever they appear in the page's text. What the default does not mask is everything else on screen. Ordinary text survives as written, and the clearest case is the one our own code calls out: a page that greets a visitor by their first name carries that first name into the snapshot. A page that displays health, financial, or other sensitive details will carry those too, unless the customer masks them. This is not a session recording. There is no stream of changes, no cursor track, and nothing to play back: it is one copy of the document as it stood at that moment, and what the visitor did to the page afterwards is not recorded. A customer who needs more masked has three ways to get it: a strict tier, switched on per site, which replaces every character of text; and two classes, abtestly-block and abtestly-mask, which they can put on any element to leave it out of the copy altogether or to redact its text. Each contributed copy reaches us. The snapshot a heatmap is finally drawn over is built from what five separate contributions agreed on, so text that was on one visitor's page and not on the others' does not survive into it. Whether to turn heatmaps on, and on which pages, is the customer's decision rather than ours, and section 9 explains why that judgment sits with them.

Our customers can also run a Signals audit capture on one of their own pages, by loading that page with a single-use capture link. That capture is started by the customer, not by a visitor. On that one page load, the snippet reads a structural description of the page, of the same kinds listed in section 2.5, together with a truncated sample of its visible text, and sends it to the customer's own ABTestly account. It takes no screenshot on this path. Because that sample is taken from the page as rendered, it can include whatever text is on screen at that moment, so we ask customers to run captures on public or test pages wherever possible. See section 2.5 for the equivalent capture performed by our browser extension, which does include screenshots.

Our customers are responsible for obtaining appropriate consent from their end-users before deploying the snippet, in accordance with applicable laws including GDPR, UK GDPR, ePrivacy Directive, CCPA, and similar regulations.

2.4 Live chat

If you open the chat widget and send a message, we receive your message, the page you are on, your referring page, and a coarse country level location derived from your connection. These details are relayed to our support inbox over Telegram so we can reply. If you choose to leave your email address, we store it so we can follow up, and it is relayed to Telegram with the rest of the conversation. Your IP address is stored in plain text for one hour so that we can limit abuse of the widget, and it then expires. Chat conversations are retained for about thirty five days in our own systems and are then deleted automatically. The copy that sits in Telegram is a separate matter, and we will not overstate it: we do not delete it, nothing in our code asks Telegram to delete it, and so your messages and any files you attach remain in that Telegram account indefinitely. Section 5.1 lists Telegram as a sub-processor and states exactly what reaches it. Your chat session is kept in four cookies shared across our abtestly.com sites, named in section 10, so a conversation you start on one site continues on another. If you are signed in to the app while chatting, we also include your name and your account email so we know who we are speaking with. We do not use the chat to build advertising profiles.

2.5 Information collected by the ABTestly browser extension

The ABTestly browser extension is a separate product surface from the snippet described in section 2.3. It is installed by a signed-in ABTestly user in their own browser, and its only function is to capture a page so that a Signals audit can be generated for it. It is not installed on, or delivered to, our customers' end-users.

A capture happens only when the user starts one, from the extension's side panel, on a page they have selected. The extension does not capture pages in the background, and it does not monitor browsing.

When a user starts a capture, the extension collects, from that page only:

• Screenshots: three images at two viewport sizes. One is a full page capture at a desktop viewport. One is a full page capture at a mobile viewport of 390 by 844 CSS pixels, at a device pixel ratio of 2. The third covers only what fits in that mobile viewport, taken under an emulated slow connection. The two full page images are clipped at 8000 CSS pixels of height, so a very long page is not captured in full. Where the full page path fails, the extension falls back to a single image of the visible viewport.
• Page structure: a classification of what kind of page it is, counts of the heading levels it uses, and counts and flags describing its form fields, such as how many fields there are and whether any of them is required. Field labels and field values are not collected. The extension does not send the page's markup.
• Samples of the page's visible text: up to 500 characters of the hero copy, up to 400 characters of the footer copy, up to 8 value propositions of between 10 and 200 characters each, and up to 12 navigation labels of under 40 characters each. The page title and the meta description are collected as they stand.
• What the page is built with: the ecommerce platform, the JavaScript framework and whether it hydrates, the checkout providers, the review widget vendor, any competing experimentation or A/B testing tool, how many scripts the page loads, whether it is served over HTTPS, and any bot wall or web application firewall in front of it.
• Visible trust and media signals: the number of trust badges, the number of reviews shown, the star rating shown, the number of images, and how many of those images carry alternative text.
• Page address: the full URL of the page being captured, including its path and its query string.
• What you type into the side panel: the problem you already know about, your niche, your average order value and its currency, your monthly sessions, and your primary goal.

A capture can cover more than one page. A funnel walk records an ordered sequence of up to 8 pages in a single run, so that an audit can look at a path rather than at one page. Each step is started by the user, on the page they are on at the time.

Taking the mobile images needs Chrome's DevTools protocol, which the extension attaches to the tab. Chrome tells you when that happens, with a banner saying that something started debugging the browser; that banner is this capture, and it goes when the capture finishes. While attached, the extension reloads the page up to three times, once with the browser cache bypassed, under an iPhone user agent and an emulated slow connection, so that it can see what a phone on a poor connection would see. On a page behind a login, those reloads send that page's requests again as you. If a page does something when it loads, loading it three more times does that again.

This capture is sent to the signed-in user's own ABTestly account and is used to produce their audit. Deleting an audit run from the dashboard deletes its screenshots from our object storage and the run record with them. Nothing expires a capture on a timer, so a run you keep is kept. We have not built a self serve way to delete everything held for an account, so a request of that kind is actioned by hand, as described in sections 7 and 8.

Because a screenshot records the page as it appears at that moment, a capture can contain any information rendered on screen, including data shown behind a login. We ask users to capture public or test pages wherever possible, and we do not use captures for any purpose other than producing that user's audit.

Outside of a capture the extension reads only the hostname of pages you visit, and only in order to answer one question: whether that hostname belongs to a site registered in your own ABTestly account. If it does, the extension shows a small button that opens the side panel. If it does not, the extension displays nothing and reads nothing further from the page. Hostnames checked in this way are not stored or transmitted as browsing history.

What the extension asks Chrome for is wider than the use it makes of it, and we would rather say so than leave you to read it off the install prompt. It declares access to every http and https address, a content script that runs on all sites, and permission to read cookies, to see your tabs, and to attach the debugger. Chrome grants that access by address pattern rather than page by page, and a capture has to be startable on whichever page you choose, which is why the patterns are that wide. What the code does with it is the three things described here: the hostname check above, the capture you start yourself, and the cookie read below.

The extension also stores your ABTestly sign-in session locally, and reads the cookie set by our own application at app.abtestly.com so that a user already signed in there is not asked to sign in twice. It does not read cookies belonging to any other website.

The extension does NOT collect your browsing history, your keystrokes, your mouse movements, or the content of pages you have not chosen to capture. It does not sell any data, and it does not transfer data to third parties for advertising or for assessing creditworthiness.

3. How we use information

We use the information we collect for the following purposes:

• Provide the Service: create and maintain your account, process your experiments, deliver variant code to end-users, count monthly tracked users for billing.
• Process payments: charge you for paid plans, send receipts, manage subscriptions.
• Communicate with you: send service updates, security alerts, billing notices, and respond to support requests.
• Send marketing communications: with your consent, send product updates, tips, and promotional content. You can opt out at any time.
• Improve the Service: analyze usage patterns to fix bugs, optimize performance, and develop new features.
• Prevent fraud and abuse: detect and prevent unauthorized access, account takeovers, and policy violations.
• Comply with legal obligations: respond to lawful requests from authorities, enforce our Terms of Service, and protect our rights.

4. Legal bases for processing (GDPR)

If you are located in the European Union, the United Kingdom, or other regions with similar laws, we rely on the following legal bases:

• Contract: to provide the Service you've subscribed to.
• Legitimate interests: to improve the Service, prevent fraud, and communicate with you about your account.
• Consent: for marketing communications and non-essential cookies. You can withdraw consent at any time.
• Legal obligation: to comply with applicable laws and respond to lawful requests.

5. How we share information

We do not sell your personal information. We share information only as described below:

5.1 Service providers (sub-processors)

We use the following third-party services to operate ABTestly. Each has its own privacy policy and data handling practices:

• Cloudflare (USA): edge compute, database hosting, content delivery, DNS, security. Privacy policy
• Clerk (USA): authentication and user management. Privacy policy
• Anthropic (USA): AI analysis for Signals, our optional CRO audit add on. Only if you run a Signals scan. A scan sends the page content and screenshots it captured, your connected GA4 figures, any brand context you supplied, aggregated heatmap and behaviour evidence drawn from your own site's visitors, field performance data for the page from Google's Chrome UX Report, and your earlier experiments together with whatever you recorded as learning from them. We use the commercial API, whose terms do not use your data to train models. Privacy policy
• jsDelivr (EU/global): open source code delivery. Only if one of your experiments uses the Carousel or Lightbox library, in which case the visitor's browser fetches that file from jsDelivr and it receives the visitor's IP address and browser details, as any file host does. The files are public open source packages pinned to a fixed version and checked against a hash. Privacy policy
• Paddle (UK/USA): payment processing and merchant of record. Privacy policy
• Resend (USA): transactional and marketing email delivery. Privacy policy
• Sentry (USA): error tracking and performance monitoring. Where it is configured for the dashboard, an error also sends a replay of that browser session with every piece of text masked and all media blocked, as described in section 2.2. You are identified to Sentry by the user id our authentication provider gave you, not by your email address. Privacy policy
• Telegram (British Virgin Islands and Dubai, per their own privacy policy): delivery of live chat messages to our support inbox. Only if you use the chat widget. What reaches Telegram: a conversation thread named with the path of the page you opened the chat on and your country; that page's address and your referring page; every message you send, up to 2000 characters each; your email address if you give one; your name and account email if you are signed in to the dashboard while chatting; and any file you attach, up to 10 MB, which may be an image, a PDF, an Office document, or a zip. We do not delete the copy Telegram holds, as section 2.4 states. Privacy policy
• Google (USA). Google Analytics 4 for aggregate traffic and usage measurement on our marketing website and the documentation site, and Google Ads for measuring which advertisements bring people to us. On our marketing website both run through a single Google tag. That tag loads on every page, before you answer the cookie banner, but it starts in a state in which it is allowed to store nothing: no cookie is set, and no identifier is read or written, until you grant a category. While you have granted nothing it sends Google an anonymous record of the page view with no identifier attached, which is what lets Google estimate the visits and sign ups it is not permitted to observe. Granting the analytics category lets it set the Google Analytics cookies. Granting the marketing category lets it set the advertising cookie and measure advertising. Either can be withdrawn at any time from the banner, and the tag stops storing again. Google also receives requests from our own servers in four other cases. When you connect a GA4 property, we exchange an authorization code and refresh tokens with Google and read the email address of the Google account you authorized, or, where you connect with a service account, exchange that account's credentials for an access token. When a connected site pulls its figures, we call Google's Analytics Admin and Analytics Data APIs for your property. And where a Signals audit looks up field performance, the address or the origin of the page being audited is sent to Google's Chrome UX Report API. And for workspaces whose creator accepted analytics cookies in the workspace's first day, we send the five account moments described in section 2.2. Privacy policy

We may add or change sub-processors over time. Material changes to our sub-processor list will be reflected in updates to this policy.

5.2 Legal requests

We may disclose information if required by law, regulation, or valid legal process, including responding to subpoenas, court orders, or government requests. We will notify affected users where legally permitted.

5.3 Business transfers

If ABTestly is involved in a merger, acquisition, financing, or sale of assets, your information may be transferred as part of that transaction. We will notify you of any change in ownership.

5.4 Aggregated or de-identified data

We may share aggregated or de-identified data that cannot reasonably be used to identify you for any purpose.

6. International data transfers

Our service providers operate in various countries including the United States, the United Kingdom, and the European Union. One of them sits outside all three: Telegram, which carries live chat messages to our support inbox, names in its own privacy policy a parent company in the British Virgin Islands and a group company in Dubai. By using our Service, your information may be transferred to, stored, and processed in countries outside of your country of residence, including countries that may have different data protection standards than your country.

For transfers from the EU/UK to countries that have not received an adequacy decision, we rely on Standard Contractual Clauses approved by the European Commission or equivalent safeguards. That includes the relay of live chat messages over Telegram. If you would rather not have a message transferred on that basis, email us at privacy@abtestly.com instead of using the chat widget.

7. Data retention

We retain personal information for as long as necessary to provide the Service and comply with legal obligations:

• Account information: retained for as long as your workspace exists. We do not delete it automatically, including when your subscription ends or when your sign in account is removed at our authentication provider. To have it deleted, email [email protected] and we will action the request within 30 days, except where we are required by law to keep records for longer. Actioning it removes the workspace and everything under it: your sites, your experiments and their results, the end-user exposure records described above, the raw event archive, your uploaded assets, your published configuration, and your team activity log. Your sign in details are removed too, unless you are also a member of another workspace. We keep a record of the request itself: the workspace name, who asked, any reason given, the dates, and, once a deletion completes, the number of members removed but not who they were. That record is kept for 24 months after the request completes or is cancelled, then purged nightly. Billing event records are kept, as described below.
• Account moments and the Google Analytics identifiers: the five account moments described in section 2.2 are kept for as long as your workspace exists. The identifiers are kept until you withdraw analytics consent, until that consent reaches the end of its 180 days, or until the workspace is deleted, whichever comes first. Moments already sent stay in Google Analytics under Google's retention rules for our property.
• Experiment data and variants: retained for as long as your workspace exists. Nothing expires them on a timer. You can permanently delete an archived experiment, or an entire site and everything under it, from the dashboard at any time. Anything beyond that, including removing the whole workspace, is actioned manually on request.
• Signals audit captures: the screenshots and page data a Signals audit run captured, described in section 2.5. Deleting the audit run from the dashboard deletes its screenshots from our object storage and the run record with them. Nothing expires them on a timer, so a run you keep is kept for as long as your workspace exists.
• End-user exposure records (the experiment ledger): the per-visitor records your experiment results are computed from, holding the visitor identifier described in section 2.3 together with coarse cohort categories: device type, country, browser, operating system, referring host, and campaign. The ledger stores no IP address, no page URL, and no raw user agent string. Retained for the life of the experiment, so that results stay accurate for as long as the experiment can be read. Nothing removes them on a schedule. They are deleted when you reset the experiment's data, when you delete the experiment, when the site is deleted, and otherwise on request.
• Raw end-user event archive: the compressed archive of individual exposure and goal events, carrying the same fields as the ledger above but one record per event rather than one per visitor. Retained for 24 months, then purged nightly. It is what raw event export, compliance audits, and rebuilding the ledger read from. Deleted when the site is deleted, and otherwise on request.
• Team activity logs, workspace changes: records of changes members make to experiments and configuration (creating and editing experiments, publishing changes, editing goals and audiences) are retained for 6 months, then purged nightly. These entries contain the member's name and email address; they do not contain visitor personal data.
• Team activity logs, access and billing: records of who holds access and what changed it (invitations, role changes, permission changes, site access granted and revoked) and records of billing events are retained for the life of your workspace, so that access and billing history stays available for security review and account enquiries. They are deleted only if the workspace itself is deleted, which we action manually on request. These entries contain the member's name and email address; they do not contain visitor personal data.
• Payment records: your subscription state and a log of the billing events we receive from Paddle are retained indefinitely so that we can meet tax and accounting obligations. Nothing deletes them on a timer, and the billing event log is kept even if the workspace it relates to is removed. Invoices and payment method details are held by Paddle, our payment provider and merchant of record, under their own retention policy.
• Support communications: chat conversations are retained for about thirty five days in our systems and then deleted automatically, as described in section 2.4. Email you send to our support address is retained in our email provider so that we can handle follow ups and disputes; we do not store it in the product.

8. Your rights

Depending on where you live, you may have the following rights regarding your personal information:

• Access: request a copy of the personal information we hold about you.
• Correction: request that we correct inaccurate or incomplete information. One correction we should flag: your organization's name is set once, when the workspace is created, and the product has no way to rename it, so ask us and we will change it for you.
• Deletion: request that we delete your personal information, subject to legal retention requirements.
• Portability: you can export your experiment results and the raw event data behind them from the dashboard at any time, in a structured, machine-readable format. Be clear about what that export is: it is your end-users' event data, keyed by the anonymous visitor identifier described in section 2.3, not the personal data we hold about you. For a copy of your own personal data, email us and we will assemble it.
• Restriction: request that we restrict processing of your data in certain circumstances.
• Objection: object to processing based on legitimate interests or for direct marketing. Marketing email is the one you can stop without us: every marketing email we send carries a one click unsubscribe, the link in it needs no sign in, and our email provider honours the unsubscribe header as well as the link.
• Withdraw consent: where processing is based on consent, you can withdraw it at any time. On abtestly.com, the Cookie settings link in the footer of every page reopens the cookie banner, so you can grant or withdraw a category whenever you like.
• Complaint: file a complaint with your local data protection authority.

Access, correction, deletion, restriction, and objection other than to marketing email are handled by hand, by a person reading your email. There is no self serve button for them in the product, and we would rather tell you that than imply one exists.

For users in California (CCPA/CPRA), you have additional rights to know what categories of personal information we collect, the sources, the business purposes, and the categories of third parties with whom we share information. We do not sell personal information. Section 11 states how we respond to browser privacy signals, including Global Privacy Control.

To exercise any of these rights, email privacy@abtestly.com. We will respond within 30 days (or sooner if required by applicable law).

9. Customers as data controllers

When our customers install the ABTestly snippet on their websites, they determine what experiments to run, what data to collect about their end-users, and how to comply with applicable laws. In this relationship:

• The customer is the data controller for their end-users' personal data.
• ABTestly is the data processor, acting on the customer's instructions.
• The customer is responsible for obtaining appropriate consent and providing required notices to their end-users.
• ABTestly will sign a Data Processing Agreement (DPA) with customers on request.

If you are an end-user of a customer's website and have questions about how your data is being used, please contact the website owner directly. ABTestly cannot identify or contact you on the customer's behalf.

10. Cookies and tracking technologies

We use cookies and similar technologies for the following purposes:

• Essential cookies: required for authentication and security. Cannot be disabled.
• Functional cookies: remember your preferences and settings.
• Analytics cookies: help us understand how the Service is used. Our marketing website uses Google Analytics 4, which sets _ga and _ga_* cookies with whatever lifetime Google's own library chooses; we do not configure them. The same website also runs our own ABTestly snippet, which sets the __abtestly_ entries listed below. The snippet does not load at all until you grant the analytics category. The Google tag does load before you answer the banner, but it sets no cookie until you grant one: _ga and _ga_* appear only once you grant analytics. You can withdraw that at any time from the cookie banner. The dashboard never sets these cookies. Apart from the cookie banner described next, it reads _ga and _ga_* only in the first day after you create a workspace, and only if you have granted the analytics category. When analytics is not granted, our cookie banner, on the dashboard and on abtestly.com, reads _ga only to send its value to our servers so we can delete the matching identifiers, and then removes _ga and _ga_* from your browser.
• Advertising cookies: used to measure which advertisements bring people to our marketing website. The same Google tag sets _gcl_au for this, and, where you arrived from a Google advertisement, _gcl_aw, which holds that advertisement's click identifier. Both are set only once you grant the marketing category in our cookie banner. Granting that category also lets Google use your visit for advertising personalisation. Until you grant it, nothing is set and nothing is personalised, and withdrawing it stops both again. The dashboard never sets this cookie.

What follows is the full list, grouped by where the entries live. Everything in it is held in the browser's localStorage unless the entry says otherwise, so a reader looking for one of these in their own browser should check localStorage first, then cookies, then sessionStorage.

Set by our snippet, on customer websites and on abtestly.com alike:

• __abtestly_uid: the visitor identifier described in section 2.3. Held twice: as a cookie that lasts 2 years, and in localStorage, where nothing expires it.
• __abtestly_v_ followed by an experiment id: which variant this browser was assigned in that experiment. 30 days.
• __abtestly_seen_v: the version of the site's experiment configuration this browser last saw.
• __abtestly_first_seen: when this browser was first seen, which is what tells a new visitor from a returning one.
• __abtestly_ledger: this browser's own behaviour on the site, so that targeting rules can use it. How many visits it has made, when the previous one was, how many pages it has viewed, which goals it has completed, and a session id that restarts after 30 minutes without activity.
• __abtestly_session_exp: which exposures have already been recorded in this session, so that one is not counted twice.
• __abtestly_goal_delivery: goal events queued or in flight, so that one is not lost or sent twice.
• __abtestly_rr_ followed by an experiment id: marks this browser as a returning visitor in a split URL experiment. 30 days.
• __abtestly_rrs: a log, for this session, of redirects that were suppressed.
• __abtestly_geo_v2: sessionStorage. The country, region, and city described in section 2.3, held for 6 hours.
• __abtestly_optout: a cookie, 2 years. It records that this browser has opted out. Read the warning below before you clear it.
• __abtestly_probe: a cookie, written and immediately expired, to work out which domain a cookie can be set on. It does not persist.
• __abtestly_preview, __abtestly_preview_pos, and __abtestly_preview_banner: sessionStorage. These belong to the preview and QA tools, so they appear for a customer's own staff rather than for their visitors.

Set by abtestly.com itself:

• __cookie_consent_v1: a cookie on .abtestly.com, 180 days. It is the record of the choice you made in our cookie banner. It is set across the whole domain on purpose, so that one choice is shared across our abtestly.com sites.
• abtestly-theme: whether you chose the light or the dark theme.
• abtestly_chat_cid, abtestly_chat_active, abtestly_chat_muted, and abtestly_chat_idsent: cookies on .abtestly.com, 1 year. Your chat conversation id, whether the widget is open, whether you muted it, and whether your email address has already been sent. These are the four cookies section 2.4 refers to. Where the widget runs somewhere other than an abtestly.com host, the same four are kept in localStorage instead.

Set by the dashboard at app.abtestly.com, for signed in users:

• abtestly-theme and abtestly-editor-settings: your theme choice and your code editor preferences.
• abtestly-me-warm-v1: followed by your user id. A cached copy of your workspace membership and permissions, so that the app can draw itself before it has asked us again.
• abtestly:draft: followed by a version, a site id, an experiment id, and a variant key. One entry per variant you have open, holding variant code you have not saved yet, so that closing the tab does not lose your work.
• ab_rail_collapsed, ab_issues_minimized_ followed by an experiment id, and abtestly:snapshot-open: which panels you left collapsed or open.
• ab_ext_banner_dismissed and __abtestly_chunk_reload_at: sessionStorage. That you dismissed the browser extension banner, and when the app last reloaded itself to recover a failed script load.
• Clerk, our authentication provider, also sets its own session cookie. It is written by Clerk's code rather than by ours, and it is what keeps you signed in.

We run ABTestly on this website too, to test our own pages. When you grant the analytics category on abtestly.com, the snippet sets the same entries in your browser, for the same purposes and for the same durations shown above. Until you grant it, the snippet is not loaded and none of its entries are set.

Where the site has turned on the Global Privacy Control setting described in section 11 and the visitor's browser sends that signal, none of these entries is written at all.

End-users can delete these entries by clearing their browser's cookies and localStorage. One warning before you do. If you have opted out of ABTestly on a site, your opt out is itself one of the entries above: the __abtestly_optout cookie. Clearing your cookies takes the opt out with everything else, and the next page you load will treat you as a visitor who never opted out. If the opt out is the thing you want to keep, delete the other entries individually and leave that one alone, or opt out again afterwards.

Customers using ABTestly should disclose these entries in their own privacy policies.

11. Browser privacy signals

Some browsers can send a privacy signal on behalf of the person using them. This section states how ABTestly responds to the two that exist today, both on our own website and in the snippet our customers run on theirs.

11.1 Do Not Track

Our snippet can act on Do Not Track, and does not unless a site asks it to. Like the signal below, it is chosen for each site by that site's own administrators, on the Consent tab in site settings, and it is off for every site until one of them turns it on. Where it is on, a pageview whose browser sends the signal is left alone: nobody is put in a variation, no cookie is set, and no event is recorded.

Expect that to change very little. The standards work behind Do Not Track closed in January 2019 for want of adoption, no law asks a site to act on what it produced, and browsers have withdrawn the control that sets it, Safari some years ago and Firefox in version 135. A browser that sends nothing has asked for nothing, so on most traffic this setting will do exactly nothing. We read the signal for the sites that would rather honour every request a browser still makes, however few now make it.

The choices that work on abtestly.com itself are the cookie banner described in section 10, which you can reopen at any time to grant or withdraw a category, and the rights described in section 8.

11.2 Global Privacy Control

ABTestly acts on Global Privacy Control. It is a browser privacy signal that several privacy laws recognize, sent by a browser to ask that a person's personal information not be sold or shared. Section 5 states separately that we do not sell personal information.

Acting on it is a setting on each site rather than one switch for everyone, and it is that site's own administrators who control it, on the Consent tab in site settings. New sites have it on. Sites that already existed when we added the setting stay off until an administrator turns it on.

Where the setting is on and a visitor's browser sends the signal, our snippet stops for that page view. Nobody is put in a variant, no variation is applied, no cookie or localStorage entry listed in section 10 is written, no exposure or goal event is sent to us, nothing is pushed to the site's data layer, and no heatmap is captured. No record of that page view reaches the experiment results.

We act on the signal only when a browser sends it. ABTestly does not work out whether a visitor wants to be measured, and nothing in the snippet infers that. Browsers differ in whether they send the signal at all, and in several it stays off until the person using them turns it on, so a page view that arrives without one carries no request either way.

The signal identifies a browser, not a person. What is suppressed is the browser that sent it. The same person in another browser, on another device, or in a private window arrives as a separate visitor. Carrying one request across everything one person uses would take the site operator's own identity system, which our snippet neither holds nor builds.

Whether to turn the setting on is the site operator's decision. We describe here what the setting does. We do not advise our customers on which laws apply to their websites, and section 9 explains why that judgment sits with them as the data controller.

We run ABTestly on abtestly.com through the same snippet and the same site setting, so this section describes our own website as well as our customers'. Section 10 covers what our cookie banner decides here.

12. Security

We implement reasonable technical and organizational measures to protect your information, including:

• TLS encryption for data in transit
• Encryption at rest for stored data via our service providers. The one encryption we apply ourselves rather than inherit is on the Google refresh token described in section 2.1, which is encrypted with AES-GCM 256 before it is written
• Access control enforced in our application code. Every request is resolved into an organization, a resource, a role, and a publishing capability, and every request that changes something is checked against that role and against the caller's per site permissions before it runs. Our database has no access rules of its own, so this check is the control, and it is switched on in production
• Secrets management via secure environment variables
• A log of changes. Every action that modifies your workspace is recorded, including every change to who has access, as sections 2.2 and 7 describe

Two things we should be straight about rather than leave you to assume. That change log is not an access log: we record what was changed and by whom, and we do not log sign ins, sessions, or reads, so it cannot tell you who looked at something. And we update dependencies and apply security patches as a matter of practice, not through an automated update or vulnerability scanning service, so treat it as a practice rather than a control you can verify from outside.

No security measure is perfect. If we become aware of a data breach affecting your personal information, we will notify you and applicable regulators as required by law.

13. Children's privacy

ABTestly is not intended for use by individuals under the age of 16. We do not knowingly collect personal information from children under 16. If you believe we have collected information from a child under 16, contact us at privacy@abtestly.com and we will delete it promptly.

14. Changes to this policy

We may update this Privacy Policy from time to time. Material changes will be communicated via email or a prominent notice on our website at least 30 days before they take effect. The "Last updated" date at the top of this policy reflects the most recent revision.

15. Contact us

For questions, concerns, or requests regarding this Privacy Policy or your personal information:

• Email: privacy@abtestly.com
• Legal notices: legal@abtestly.com
• Mailing address: available on request from the above email addresses.

For complaints in the EU, you may contact your local Data Protection Authority. For the UK, the Information Commissioner's Office (ico.org.uk).