What we collect, how we protect it, and what we will never do with it.

Applies to the Cortality website snippet (c.js) installed on client marketing sites.

What the snippet collects

• Behavioral events: mouse movement, scrolls, clicks, and touch events with page coordinates and timestamps. No keystrokes, ever.
• Viewport screenshots: periodic images of the page as the visitor's browser rendered it (the client's own published text, images, and layout). Capped per session.
• Sanitized page structure: a copy of the page's HTML and its changes during the visit, with all form input values removed before transmission.
• Session context: viewport and document dimensions, device type, user agent string, page URL path and UTM campaign tags (length-capped), and referrer hostname only. On Shopify stores, the checkout pixel sends the full page address, including query strings and on-site search terms. Addresses of links to other sites keep their query strings.
• Approximate location: country, state or region, and city, derived on our servers from the connection (not collected by the snippet, and not from the browser's location feature). Country only for EU, EEA, UK, and Swiss visitors. See IP addresses and approximate location below.
• A session identifier: a random UUID generated in the browser for that visit.
• An optional visitor ID: off by default. Sites that turn on purchase attribution get a random ID stored in the visitor's browser local storage, which links that site's own visits. It is never derived from the person.

What the snippet never collects

• Form field values (masked twice before anything ships: removed from the HTML copy, and painted over with an opaque box in screenshot pixels)
• Keystrokes
• Camera, microphone, video, or images of the visitor, from the standard tag (it requests no browser permissions). Gaze measurement is a separate module that loads only on sites that opt in, and only after the visitor grants camera access. Raw camera frames never leave the visitor's browser; only derived gaze points are sent.
• Cookies (none are set) or advertising identifiers
• Anything from pages where the snippet is not installed or not enabled

What masking does and does not cover

Masking covers form input values, everywhere, automatically. Text or images that a page renders outside form fields, for example a live-chat widget's transcript, a personalization banner, or account-status text, are part of the page content and are not automatically masked. Clients whose marketing pages render any visitor-entered or personalized content must exclude those elements with data-cortality-ignore (see the exclusion documentation) or keep the snippet off those pages.

Identity model

Each visit generates a random session ID that exists only in that visitor's browser and our records of that single visit. It is never reused across visits, never linked to a person, and never combined with other data to recognize a returning visitor. The exception is the optional visitor ID. It is off by default. When a site turns it on, a random ID in browser local storage links that site's own visits so purchases can be attributed. It is never linked to a name or contact details, and it is not shared across sites. One more nuance: if a session's data fails to send (a crash, a killed tab, a lost connection), the visit's buffered events, including its session ID, are held in the browser's local storage as crash protection for at most 7 days: sent on the visitor's next page load and then cleared, or, if no visit happens within 7 days, cleared without ever being sent. That recovery mechanism preserves a single visit's own data; it is not used to track, link, or identify anyone across visits.

Fingerprinting

The session context fields above (device type, viewport size, user agent) are standard technical context, stored per-session. Cortality does not combine them, or anything else, to build a device fingerprint, re-identify a returning visitor, or track anyone across sites. There is no cross-site identification. Visits are linked only through the optional visitor ID above, and only on sites that turn it on.

IP addresses and approximate location

The visitor's IP address reaches Cortality's delivery network (Amazon CloudFront) and servers as part of ordinary HTTPS delivery. It is not stored in the analytics dataset, is never attached to a session record, and is not used to identify anyone. IP addresses are removed before logs are written.

As a request arrives, the delivery network looks up the approximate location of that address, and a session record keeps only the result: country, state or region, and city. The address itself is then discarded as described above. Alongside a known city we keep that city's approximate map position, rounded to about 11 km (0.1°), so traffic can be shown on a map. We do not keep postal codes, street-level positions, or anything finer than a city. For visitors in the EU, EEA, United Kingdom, and Switzerland, only the country is kept. Location is an estimate (mobile connections often resolve to a carrier's hub city) and is used to show clients where their traffic comes from, never to identify or re-identify a visitor. Any client can have location turned off entirely for their site on request.

UTM parameters

The snippet retains UTM campaign tags from the page URL (source, medium, campaign; length-capped). These values are set by whoever built the marketing link. Clients are responsible for not embedding personal identifiers (emails, user IDs) in UTM parameters on links pointing at instrumented pages; if your email or affiliate tooling does this, tell us and we will drop UTM collection for your site.

Use of collected data

Client site data is used to deliver the analytics service to that client. It is never sold, never used for advertising, never used to build cross-site visitor profiles, never combined with identifiable data from other sources, and never shared with third parties except the processing subprocessors listed below. Anonymous, aggregate statistics derived from client data may be used to build benchmarks and improve our models; aggregate data never identifies a client, a site or a visitor. Any client can opt out in writing, and from then on that client's data is used solely to serve that client.

Scoping controls available to every client

• Route allowlist: on single-page applications, the snippet can be restricted to an explicit list of public marketing routes, matched by URL path. Landing outside the list means no collection at all; navigating from a listed route into an unlisted one sends the marketing page's data and then permanently stops all collection for that browser tab. See the route allowlist documentation, including its limits.
• Element exclusion: any page element marked data-cortality-ignore is excluded from observation.
• Programmatic stop: Cortality.disable() immediately and permanently stops collection for the tab, callable from a client's own consent or authentication logic.

Where data is processed

Session data is stored and processed in AWS us-east-1 (USA). On its way there, each upload is received over HTTPS by the nearest Amazon CloudFront edge location, which can be outside the USA, and is forwarded immediately without being stored at the edge. Masked page-render images are additionally processed by the AI model providers listed below, through US-region endpoints, except the alternate Google provider (global endpoint), which is used only when selected. A text model also reads the page's own text and aggregate counts to write findings (see Subprocessors). Clients who need processing restricted to a specific provider can request it (see Subprocessors). Any client can restrict visual analysis to a single named provider before processing begins.

GDPR / CCPA position

Cortality does not sell or share personal information as defined by the CCPA/CPRA. The snippet's design (no form values, no cookies, and no identifiers persisted beyond the 7-day crash-recovery window described in Identity model, unless a site turns on the optional visitor ID) is intended to minimize personal-data processing by architecture rather than by policy alone. Our DPA, including the Standard Contractual Clauses, is published and applies automatically. This describes our practices; it is not a compliance certification, and clients remain responsible for their own obligations (see Client obligations).

Architecture

• The client snippet ships data over TLS to a dedicated ingest service that is isolated from the client dashboard and from processing workloads.
• Raw session data lands in private, encrypted object storage; processing runs in isolated, network-restricted compute; analytics are stored in a managed database reachable only over private networking, with no public database endpoint.
• The client dashboard is a separate service with its own authentication; every API request re-validates the login against the database, so revocation is immediate.

Encryption

• In transit: TLS on every hop (snippet to ingest, CDN delivery, dashboard).
• At rest: all storage and databases encrypted with managed keys.

Access control

• Infrastructure access via SSO with scoped roles; least-privilege service roles, so each service can reach only the specific resources it needs.
• Client dashboard logins use email sign-in, scoped to that client's site(s) only; passwords are stored only as salted, one-way hashes.
• Per-site submission keys are held in a managed secrets store and are rotatable at any time.

Data ingestion integrity

• Every submission is signed and verified server-side before acceptance; the service fails closed if keys are unavailable.
• Site keys are submission-only credentials: they can add data to that site and cannot read anything. Per-site rate limiting and instant rotation bound abuse of a copied key.

Monitoring, audit, and tenant isolation

• Account-level audit logging (AWS CloudTrail) is enabled.
• IP addresses are removed before logs are written. Structured service logs are kept for 30 days.
• Every data record is keyed by site. Dashboard and API queries are scoped server-side to the authenticated client's sites, and asset access is validated against site-prefixed storage paths, so one client can never read another's data.

Any new subprocessor is posted to the change log below at least 30 days before it receives client data. Our DPA treats that posting as notice.

Change log

• Oct 7, 2026: list published with every provider named (AWS, Resend, Alibaba Cloud, xAI, Anthropic, Google). No new provider added.

By default, Cortality keeps the data it collects, including after a client leaves. If you instruct deletion in writing, or the law requires it, we delete or irreversibly anonymize your data within 30 days, as section 8 of our DPA describes.

Pages you paste into cortality.com/leak

When you paste a page into the /leak quiz, our servers load that public page, capture it screen by screen at desktop and phone widths, and run our own attention model on the screenshots inside our AWS account; no third party receives the page. We keep the screenshots so your result link keeps working. Your answers are stored without your IP address. We only email you if you give us an address. Questions about what you entered: email colton@cortality.com.

When a client leaves

Removing the tag stops all new collection. Data already collected is kept, encrypted at rest, scoped to that client's site, and visible only to that client's account. It is never sold or shared. Dashboard access can be closed on request. If you instruct deletion in writing, or the law requires it, we delete or irreversibly anonymize your data within 30 days (DPA section 8).

Response process

• Contain: revoke affected credentials (per-site submission keys and dashboard logins are individually rotatable and revocable with immediate effect), isolate affected services.
• Assess: determine scope from account audit logs and service logs; identify which clients and data classes are affected.
• Notify: affected clients within 72 hours of awareness, with follow-ups as facts develop; regulators where legally required.
• Remediate and review: fix root cause, document the incident, and update this process with lessons learned.

Relevant design mitigations

The snippet architecture limits blast radius by design: no visitor identities are collected, so the most sensitive data class held is the client's own published page content and anonymous interaction coordinates. Client-side keys are submission-only and cannot read data. Database access requires private VPC networking.

A starting point for your policy

Not legal advice, and your counsel should adapt it to your site, but most clients want something to hand them, so here is draft language:

"We use Cortality, a website analytics service, to understand how visitors interact with our marketing pages. It records interactions such as mouse movement, scrolling, and clicks, together with images of the page as displayed. It does not collect the values you type into form fields, does not use cookies, and does not combine data to build a profile that identifies you individually or tracks you across visits. Details of its data handling are at cortality.com/trust."

Before publishing that language: confirm any content on your pages that renders visitor-entered text outside form fields (a live chat widget above all) is excluded with data-cortality-ignore, or the "does not collect" sentence will not be accurate for your site. If you turn on the optional visitor ID, drop "or tracks you across visits" and say instead that a random ID stored in the browser links visits to your site.

You are also responsible for: not installing the snippet on pages that render regulated personal information (see Regulated industries), applying the exclusions described above as your pages change, and keeping personal identifiers out of UTM parameters. We provide the controls, but the pages are yours, and you know them better than we do.

Several controls exist specifically for clients whose products serve patients, clinical programs, or financial customers:

• Marketing-only scope via route allowlist. Collection is restricted to an explicit list of public marketing routes, matched by URL path, and fail-closed: unlisted routes are excluded by default, and collection permanently stops the moment a visitor navigates into one. Know its limit: the allowlist matches paths, not authentication state. If a listed marketing route ever renders personalized or logged-in content without a path change, that content is in scope unless you exclude it with data-cortality-ignore or call Cortality.disable() on login.
• Written scope commitments. We commit in writing that the snippet's capture scope will not change without the client's prior approval. If the snippet's capture scope ever expands in any way, affected clients get written notice and must opt in before anything changes on their sites.
• Subprocessor control. Our visual-analysis subprocessors are disclosed in Subprocessors (each provider is named there, with its endpoint region). Clients who cannot route data through specific vendors can restrict processing to a single named provider before any of their data is processed. Tell us before you install and we configure it from day one.
• Scoped, encrypted retention. Data stays encrypted and scoped to your sites. Retention terms are set in your DPA.

We would rather tell you plainly what exists than link a boilerplate policy that does not describe our system. If your procurement process needs a document we have not listed, ask; if it is something we should have, we will build it with counsel rather than improvise it.

Security and privacy contact: team@cortality.com. Reports of vulnerabilities or data concerns are answered same-day by the founding team.

Data and legal requests: team@cortality.com, from your registered client address where you have one.