Sub-processors

Hosting, edge compute, DNS, analytics storage, and security services.

Visitor events, account configuration, and operational logs. Cloudflare operates the edge that every ClickStream request terminates on: the visitor’s browser connects to it to download the SDK and to send each event, so it receives the visitor’s IP address, user agent and request headers on every one of those requests.

Managed PostgreSQL hosting for ClickStream’s databases.

Account configuration and the visitor, identity and event records the platform stores, in the same form. Only ClickStream’s servers connect to it, through Cloudflare Hyperdrive; visitors’ browsers never do.

Billing, subscriptions, invoices, and payment processing.

Account and billing details. Stripe does not receive ClickStream event data.

ClickStream’s own sales and account management for ClickStream customers.

ClickStream customer account details: the account holder’s name, login email, and phone number and company name when provided, signup date and email verification state, package, billing and subscription status, whether the account is a lead or a paying, complimentary or former customer, Stripe invoice, payment and refund history, and the names and addresses of the properties the account tracks. HubSpot does not receive ClickStream event data or any tracked visitor’s data.

Delivery of the emails ClickStream sends: account verification, password resets, invitations, notifications to account holders, and ClickStream’s own operator alerts.

The names and email addresses of ClickStream account holders, the email addresses of people they invite to a property, and the full content of each email ClickStream sends: verification and password-reset links, invitations naming the inviter and the shared properties, notifications from automations an account holder sets up, and notices about data subject requests for their properties, which never identify the data subject. Resend also carries ClickStream’s internal operator alerts, which contain operational details such as property ids and tracking hostnames, and ClickStream’s internal new-account notifications, which contain the new account holder’s name and email address, and their phone number and company name when provided. Resend does not receive ClickStream event data or any tracked visitor’s data.

Integration platform for the third-party tools a customer connects to ClickStream, such as its CRM. Planned: not yet in use.

Once in use: the access credentials a customer grants for the tools it connects, and the records the customer chooses to send to those tools.

Demand-side platform for the advertising audiences a customer chooses to activate. Planned: not yet in use.

Once in use: the audience segments a customer chooses to activate for advertising, sent as hashed identifiers such as hashed email addresses, and the campaign settings that go with them.

Optional person-profile enrichment when a site owner enables enrichment.

Two separate transfers, and the one in the browser is the larger. FROM CLICKSTREAM’S SERVERS: a hashed email identifier (MD5) and a ClickStream visitor match key. IN THE VISITOR’S BROWSER: ClickStream loads this vendor’s own script directly into the page, so the visitor’s browser connects to the vendor’s hosts itself and discloses the visitor’s IP address on the script request and on every request the script then makes; those requests carry at least the page’s origin in their Referer header. Once running, the script has whatever access to the page any script loaded by that page has — the full page URL and referrer, the page’s content, browser and device properties, and cookies it sets and reads, including cookies written into your own site’s cookie store. ClickStream additionally exposes the ClickStream visitor id to it as window.customUserId, and the script loads the LiveIntent dependency listed below. What it receives in the browser is therefore bounded by what runs in the page, not by what ClickStream sends. All of this applies only to sites with optional enrichment enabled and the required consent posture; disabling enrichment stops both legs. A hashed email address is personal data and is not made anonymous by hashing.

Browser-side identity resolution supporting optional enrichment. Runs only on sites where enrichment is enabled and the required consent is present.

A SECOND SCRIPT EXECUTING IN THE PAGE, not a beacon. The enrichment vendor’s script loads this vendor’s own script into the same page (currently d-code.liadm.com), and it may open identity-sync IFRAMES to these hosts — which is why the CSP guidance for optional enrichment includes frame-src and child-src for them and not only script-src. The visitor’s browser therefore connects to these hosts itself and discloses the visitor’s IP address on the script request, on every request the script then makes, and on every frame it opens; those requests carry at least the page’s origin in their Referer header. Once running, the script has whatever access to the page any script loaded by that page has — the full page URL and referrer, the page’s content, browser and device properties, and cookies it sets and reads. What it receives in the browser is therefore bounded by what runs in the page, not by what ClickStream sends: ClickStream transmits nothing to this recipient from its own servers. LiveIntent resolves the visitor against its own identity graph keyed on the IP address, deriving the hashed email used as the enrichment match key. Disabling optional enrichment stops this processing entirely.