This policy covers Version Compare, including email sign-in and customer-site browser integrations. The customer-side aggregate proxy and server/CDN adapters remain planned features, not available privacy protections.
For browser storage, read the Version Compare cookie policy. This notice is hosted on the corporate website, which has its own DoNoHarm privacy policy.
Version Compare is operated by DoNoHarm GmbH, Singerstr. 33 c/o Felix Bauer, 10243 Berlin, Germany. DoNoHarm GmbH is the controller for our account service and our own website analytics. Our company details are in the imprint. For privacy questions, contact webmaster@donoharm.world.
When a customer uses Version Compare on their website, that website operator decides which content to test and which goals to measure. Their privacy notice and browser-storage choices also apply. Contact that operator about experiments on their site.
Requests to our website and hosted experiment endpoints disclose connection information to our infrastructure, including your IP address, the requested URL, the time of the request, and HTTP headers such as the browser's user-agent. A referrer may also be sent, depending on the browser and website settings. This applies even when an experiment event contains no name or email address.
Version Compare's public marketing and documentation pages use Ackee, hosted by DoNoHarm at ackee.donoharm.world, to measure visits. We do not load this analytics tracker on Version Compare's sign-in, authentication, account administration, or backoffice pages. Marketing analytics are separate from the experiment measurements collected for customer sites.
We disable Ackee's optional detailed mode. The tracker sends the page URL and available referrer and measures visits and visit duration, without the optional device, screen, or language details. We do not add email addresses, account identifiers, or customer experiment records to these analytics events. Page URLs can include query strings or fragments, so avoid putting personal or confidential information in marketing links.
Ackee measures page visits and visit duration without setting visitor-measurement cookies. Its documentation explains that the server derives a daily identifier from the IP address, user-agent, and tracked domain, using a salt that changes daily. Cookie-free does not mean that no connection information is processed or that every measurement is necessarily anonymous. See Ackee's data-processing documentation.
The email-sign-in beta stores your email address, account membership, verification status, and creation time. If another member invites you, we store your address and the pending invitation. An invitation is not membership until you accept it and confirm control of the email address. All verified members of an account have equal access to its sites, settings, experiments, and member management.
We store hashes of sign-in and session tokens, their expiry times, and request counters used to limit sign-in emails. Sign-in and invitation links are single-use and expire after 15 minutes. Account sessions expire after 30 days at the latest. The vc_session account cookie lasts for the browser session by default, or up to 30 days if you select “Keep me signed in” when confirming the email link. Signing out clears the cookie and revokes that session. Browsers may restore session cookies when reopening a previous session.
We use Postmark to deliver sign-in and invitation emails. Postmark receives the recipient and sender email addresses, subject, and message content, including the sign-in or invitation link. Our messages request that email-open and link-click tracking be disabled. Postmark documents US hosting and its own message retention practices in its data-protection information. A link expiring does not delete the email from Postmark or your inbox.
There is currently no billing in the beta. We do not collect payment details or send them to a payment processor for this service.
We store the sites you register, their titles and allowed origins, experiment and alternative identifiers and titles, associated page URLs, goal settings, and a hash of each site's integration key. These records let us provide account administration, experiment configuration, and results.
The browser runtime sends the page's origin and path, experiment and alternative identifiers, exposure references, and any reported goal interaction. Query strings and fragments are excluded from these page-address fields. Assignments use server-issued exposure identifiers, not a general-purpose visitor identifier or fingerprinting. We store assignment and origin information to recognise valid references; the assignment window is 30 minutes.
Direct browser reporting records an exposure identifier, the site, experiment, and alternative shown, the time recorded, and a success time if a goal is reported. We also store exposure and success totals. Exposure identifiers link a reported success to an earlier exposure and help avoid counting it twice. These are individual event records, not aggregate-only collection.
A customer can explicitly mark links between approved connected origins for attribution handoff. The hosted service then issues a single-use token valid for 120 seconds, bound to the destination origin and page path. We store its hash, destination, associated exposure references, and expiry. It can transfer up to 32 already observed, unexpired assignments. This links those experiment measurements across the configured sites; it does not make them anonymous.
The hosted service also accepts aggregate count batches and stores their batch identifiers, payload hashes, and receipt times to avoid counting retries twice. The existence of this endpoint does not mean that a browser integration stops contacting our servers.
When previews are generated, we fetch public HTML and supporting resources in a fresh, cookie-free browser context with page JavaScript disabled. The capture does not use visitor credentials or a visitor's browser session. Resource requests pass through our public-network address checks.
We capture images clipped to the marked experiment alternatives and store the latest previews and related metadata in the hosted service's database for the account interface. Descriptive titles come from public page text; no external AI service is used for this processing.
A screenshot can contain personal information visible in the captured area. Do not put secrets, credentials, or private visitor information in content submitted for previews. These previews are separate from exposure and success records, and aggregate results do not make their associated images anonymous.
If you contact us, we receive your email address and the information you include in your message. Configured support operators can view account details and open access to an account for up to 15 minutes, including making changes. We record the operator's email address, the account, and the access start, expiry, and any explicit stop time. This is an access-period record, not a record of every action taken during support.
The proposed proxy runs on the customer's infrastructure. Its intended design keeps browser assignment and attribution on the customer's side and sends grouped experiment counts to Version Compare, rather than forwarding individual visitor events. That reporting path is intended to exclude visitor identifiers, IP addresses, user-agents, referrers, full visit URLs, cookies, and form values. It is not the current direct hosted-browser path and is not yet an available privacy guarantee.
Grouped counts are not automatically anonymous, especially for small groups. The release conditions and storage rules still need to be established before this feature is offered. Customer servers and first-party browser storage still process visitor information; a proxy is not a blanket exemption from consent or privacy duties.
The current service has no automatic retention limit for experiment exposure records, aggregate batch identities, or support-access history. The 15-minute link, 30-day session, 30-minute assignment, and 120-second handoff limits govern access or attribution; they are not deletion deadlines for account information, experiment results, previews, support history, or infrastructure records.
To request access to, correction of, or deletion of your account information, write to webmaster@donoharm.world. There is no self-service account-deletion control in the current beta. For product support, you can also contact support@donoharm.world.