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 deleted before transmission.
• Session context: viewport and document dimensions, device type, user agent string, page URL (path only; query strings stripped except UTM campaign tags, length-capped), and referrer hostname only.
• A session identifier: a random UUID generated in the browser for that visit.

What the snippet never collects

• Form field values (masked twice before anything ships: deleted from the HTML copy, and painted over with an opaque box in screenshot pixels)
• Keystrokes
• Camera, microphone, video, images of the visitor, gaze, facial, or biometric data (no such code exists in the shipped bundle; no browser permissions are requested)
• 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. We flag known cases (chat widgets especially) during onboarding.

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. One honest 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 deleted, or, if no visit happens within 7 days, deleted 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-visit or cross-site identification of any kind in the system.

IP addresses

The visitor's IP address reaches Cortality 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 for geolocation or identification. It appears only in standard infrastructure request logs kept on a 30-day fixed retention for operational debugging.

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. Where a client has opted out of aggregate or model use in writing, that client's data is used solely for service delivery.

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 ingested, stored, and processed in AWS us-east-1 (USA). Masked page-render images are additionally processed by the AI analysis subprocessors listed below, one of which uses a Singapore-region endpoint. Clients who need processing restricted to specific providers or regions can request it (see Subprocessors). For engagements targeting EU visitors, we do not route data through the Singapore endpoint by default: visual analysis is restricted to providers for which appropriate cross-border transfer safeguards are documented in that engagement's GDPR paperwork, or the client's chosen provider, before any 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) is intended to minimize personal-data processing by architecture rather than by policy alone. Formal GDPR documentation is provided when an engagement targets EU visitors. 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 (AWS ECS Fargate behind an HTTPS application load balancer). Ingestion is fully separated from the client dashboard and from processing workloads.
• Raw session data lands in a private, encrypted S3 bucket; processing runs in isolated Lambda functions inside a VPC; analytics are stored in RDS PostgreSQL reachable only over private VPC 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: S3 and RDS encrypted with AWS KMS keys.

Access control

• AWS access via SSO with scoped IAM roles; least-privilege task roles per service, so each service can reach only the specific buckets, queues, and secrets it needs.
• Client dashboard logins are per-client access codes scoped to that client's site(s) only; passwords are stored as bcrypt hashes.
• Per-site submission keys are stored in AWS Secrets Manager and are rotatable at any time.

Data ingestion integrity

• Every submission is HMAC-SHA256 signed and verified server-side (timing-safe comparison) before acceptance; the service fails closed if signing keys are unavailable.
• Per-site rate limiting bounds abuse from copied publishable keys.

Monitoring, audit, and tenant isolation

• CloudTrail audit logging is enabled on the AWS account; structured service logs are kept in CloudWatch on a 30-day retention with no analytics-linked storage of IPs.
• 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.

Clients are notified before any addition to this list.

Deletion on request

Any client may request complete deletion of their collected data at any time. Deletion covers raw bundles, processed analytics, and stored assets across all storage systems. Cortality confirms completion in writing within 30 days of the request; automated database backups containing the deleted data age out on their 7-day cycle within that window. Client dashboard logins and configuration are deleted on request as well, or retained if the client prefers to keep the account.

End-of-engagement default

For pilot engagements that do not continue, the client may choose deletion (as above) or retention for a possible future engagement. Absent instruction, data follows the standard schedule.

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 audit logs (CloudTrail) 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. We check the common cases with you at onboarding; tell us if you add widgets later.

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 check for the common cases during onboarding, 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 our capabilities ever expand (for example, any future camera-based features), affected clients get written notice and must opt in before anything changes on their sites.
• Subprocessor control. Our visual-analysis subprocessors include Alibaba Cloud (a China-headquartered company; Singapore-region endpoint; masked page pixels only, as detailed in Subprocessors). Clients who cannot route data through specific vendors can restrict processing to a single named provider before any of their data is processed. Say so at onboarding and we configure it from day one.
• Deletion with written confirmation within 30 days, covering every storage system.

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: colton@cortality.com. Reports of vulnerabilities or data concerns are answered same-day by the founding team.

Deletion or data requests: email from your registered client address; we confirm completion in writing.