Security

This page describes CleanClicks’s security design principles and operational practices as of the date above. CleanClicks may update this page as the product evolves; material changes will be reflected in the date above and prior versions are available on request.

CleanClicks runs on serverless edge infrastructure with a deliberately small data footprint. Every claim on this page is something the platform actually does today, verifiable in the running code. We don’t sell your visitors’ data, we don’t store what we don’t need, and our infrastructure is designed without persistent server access points.

1. Infrastructure

Traditional tracking platforms run on servers that have to be trusted, patched, and monitored for unauthorized access. CleanClicks runs on Cloudflare’s serverless edge: no origin servers we operate, no virtual machines, no containers, and no shell access we provision for anyone. The compute layer is the code itself, executed in isolated, ephemeral runtimes that spin up per-request and retain no state between invocations.

Serverless edge compute. Our code runs in a serverless, per-request execution model with no filesystem, no shell, and no persistent memory across invocations. The traditional “server got popped” failure mode is not part of our threat model because we do not operate persistent servers.

Global edge distribution. Processing happens at the Cloudflare edge location nearest your visitor, across a globally distributed edge network. Conversion data does not traverse extra hops or concentrate in a single region.

First-party context, your domain. The tracking script loads from a subdomain of your domain over HTTPS (for example, cleanclicks.yoursite.com). No third-party domains in the page, no cross-origin requests, no Content Security Policy conflicts to negotiate.

Inherited infrastructure certifications. Cloudflare, our underlying infrastructure provider, maintains SOC 2 Type II, ISO 27001, and PCI DSS Level 1 certifications. Their attestations cover the compute, storage, and network layers our platform runs on.

2. Data Handling

Most data-breach impact scales with what the breached system was storing. CleanClicks takes the opposite approach: hash personal identifiers at the earliest point, write only what conversion attribution needs, and set automatic expiration on everything that is not long-lived configuration.

Email addresses hashed at ingress. For browser-side tracking, our script (cc.js) SHA-256 hashes emails in the visitor’s browser before any data leaves the device. For server-to-server integrations (webhooks, the inbound API), raw email is hashed at the edge before persistence. Only the hash is stored. Only the hash is sent to ad platforms.

IP addresses are edge-only, short-lived, and redactable. Visitor IP is processed at the edge for geographic classification, bot filtering, and conversion attribution. It is written to short-lived storage (90-day retention on conversion records and traffic analytics) and never retained beyond that. When a visitor opts out, their IP is never sent to any advertising platform.

Mandatory expiration on visitor data. Conversion records, session fingerprints, dedup keys, and audit entries all carry storage-enforced expiration: 30 minutes for session continuity fingerprints, 24 hours for dedup, 90 days for conversion records and failed-event replay logs, and 180 days for audit entries. There is no “forgot to purge” scenario because the storage layer enforces it.

First-party cookies only. Cookies set by CleanClicks are host-only and scoped to your subdomain (no Domain attribute, no cross-site reach). No third-party cookie matching, no cross-domain tracking, no data-broker integrations. Your visitors cannot be followed from your site to anyone else’s through CleanClicks.

No raw email or IP in long-term storage. Customer configuration (allowlists, OAuth credentials, integration keys) persists for the life of your account. Visitor-event data is short-lived: conversion records and click-ID mappings expire within 90 days and audit entries within 180 days. First-party cookies on the visitor’s device (the visitor ID and opt-out preference) last up to 1 year.

3. Encryption

In transit. TLS 1.2 or higher, enforced by Cloudflare on every request. The tracking script loads over HTTPS from your subdomain; server-to-server dispatch to ad platforms uses authenticated HTTPS connections.

At rest. All stored data — conversion records, audit logs, session fingerprints, and customer configuration — is encrypted at rest by Cloudflare’s storage layer. The storage-layer encryption keys are managed by Cloudflare and are not accessible to CleanClicks application code. Stored OAuth refresh tokens receive an additional application-layer encryption using AES-256 with per-account keys, isolated from application code and rotated under a documented procedure.

At the application layer. Email addresses are SHA-256 hashed before storage. Inbound API keys are validated using constant-time comparison, mitigating timing-based side-channel attacks.

4. Privacy Signals

CleanClicks reads the privacy signals your visitor has already broadcast — Global Privacy Control and CleanClicks opt-out cookies — and applies the right platform-specific flags before any data is dispatched. You do not have to wire this up per ad platform; it is the default behavior.

Global Privacy Control (GPC). When a visitor’s browser sends the GPC signal, the tracking script recognizes it and applies opt-out treatment automatically. No customer code or configuration required.

CCPA and CPRA. California residents can exercise their rights through our CCPA Notice. When a visitor opts out (GPC or CCPA cookie), CleanClicks withholds their conversions from advertising platforms entirely — Meta, TikTok, LinkedIn, and Microsoft receive nothing — and sends Google Ads only privacy-preserving, identifier-free signals with advertising click identifiers removed.

Consent-based dispatch. For visitors who have not opted out, conversions dispatch with Google Consent Mode v2 signals applied. When a visitor opts out, CleanClicks does not send their conversions to advertising platforms at all: Meta, TikTok, LinkedIn, and Microsoft receive nothing, and Google Ads receives only privacy-preserving signals with click identifiers removed.

US opt-out-by-default (where enabled). US state privacy law uses an opt-out model: a visitor is treated as opted in until they opt out. On client sites that turn on our optional us-optout setting, CleanClicks treats US visitors as opted in to first-party analytics until they use Global Privacy Control or a recorded opt-out. A third-party cookie banner’s “reject,” on its own, is not treated as an opt-out of the first-party analytics lane. This setting is US-only, applies to first-party analytics only (it never changes how conversions are sent to advertising platforms), never overrides GPC or a recorded opt-out, and never fabricates a consent signal — it only removes a denied or unset analytics-consent flag so the measurement is processed as signal-absent.

Data minimization, by architecture. Data minimization is not a policy we promise — it is a property of how the system is built. Hashed identifiers, short TTLs, edge-only IP handling, first-party-cookie-only scope: each is a constraint baked into the pipeline, not a behavior we have to remember to apply.

5. Bot Protection

Non-human traffic is filtered out before it touches your conversion data or reaches any ad platform. The filtering is not a separate product or an after-the-fact cleanup pass — it runs natively at every layer of the pipeline.

Edge-level bot scoring. Edge-level bot scoring intercepts known bot networks before they reach our application layer. Edge-blocked traffic is counted in our internal Bots Stopped reporting alongside our own filtering.

Worker: structural and named-bot filtering. Every conversion request is checked against a maintained list of named bot user-agents plus structural filters. Google’s verification bots are whitelisted so your ads are not disapproved for being unreachable.

Application: customer-configured rules. You can layer your own filters on top: geographic allowlists or blocklists, IP range filtering, and custom user-agent pattern matching. Useful for sites that only sell in specific markets or have unusual bot exposure.

Default-on, not opt-in. The named-bot filter and structural filters run on every conversion request, on every plan, with no toggle. The only filters that are opt-in are the customer-configured ones, because those depend on your business geography.

6. Monitoring

If something breaks in conversion delivery, our monitoring stack is designed to surface the issue to us as quickly as possible. Two independent monitoring systems run continuously against the production pipeline.

Daily classifier health check. Every active customer domain is checked once daily across data completeness and vendor API health. Red conditions raise an alert to our internal tracking system; results are also surfaced in your CleanClicks dashboard.

Synthetic conversion probe. Every 15 minutes, a synthetic conversion is fired against the production pipeline. The probe verifies that the request reaches the edge, persists to storage, and dispatches to a real ad-platform API. If any step fails, we are paged.

Audit trail with replay. Failed vendor dispatches are stored separately for 90 days so they can be replayed once the underlying issue (an expired token, a rate-limit window, a transient platform outage) is resolved. Failed dispatches that the pipeline observes are surfaced via the audit trail and the replay system.

7. Incident Notification

In the event of a security incident affecting data CleanClicks processes on a Customer’s behalf, CleanClicks will notify the affected Customer in accordance with the terms of the Data Processing Addendum and applicable law. In the event of a security incident affecting personal information for which CleanClicks is itself the controller (for example, marketing-site data submitted through cleanclicks.ai forms), CleanClicks will notify affected individuals and applicable regulators in accordance with the breach-notification statutes of all applicable jurisdictions. CleanClicks does not commit on this page to a specific notification timeline; the controlling timelines are those set by applicable law and the Data Processing Addendum.

8. Customer Isolation

Customer data isolation is not a query filter we hope we remembered to add. Every piece of stored data is keyed by your tracking subdomain at the storage layer, so cross-customer data access would require both a key-construction bug and the bug surviving the test suite that exercises the storage interface.

Domain-scoped storage keys. Every customer’s configuration, conversion records, audit log entries, and OAuth credentials are stored under a key prefixed with the customer’s tracking subdomain. There is no shared database table where customers commingle.

Constant-time API key validation. Inbound integration keys are validated with constant-time comparison (SHA-256 digest both sides, then byte-equal compare), mitigating timing-based side-channel attacks against the key-validation path.

Admin access gated by SSO. Internal admin routes (used by CleanClicks operations to provision customers and investigate issues) are protected by SSO. There is no admin UI exposed to the public internet. General support staff have no access to raw customer conversion data; administrative access for system maintenance and incident response is limited to the operator (CJF & Associates LLC d/b/a ClickPath Consultants) acting in their administrative capacity, gated by SSO.

9. What We Do Not Do

Some of the safety here comes from things we never built. The points below are as load-bearing as anything above.

No Google Tag Manager delivery. CleanClicks’s tracking script is never delivered through GTM. GTM is itself blocked by every major ad blocker, so loading our script through it would defeat the first-party advantage. Direct script tag install only.

No third-party cookie syncing. CleanClicks does not participate in third-party cookie syncing or identity-matching marketplaces. The platform does not have a relationship with data brokers and does not enrich your conversion data with externally-sourced identifiers.

No cross-customer data access. No shared database table joins customer data. No support agent has a panel that lists every customer’s conversions. No internal job aggregates conversion data across customers for any purpose.

No raw PII in long-term storage. Raw email is never written to durable storage. Raw IP is written only to short-lived (≤90-day) edge storage for attribution and bot-filtering, and is never sent to advertising platforms when a visitor opts out.

10. For Your Security Review

Where is data stored geographically? Conversion records and configuration are stored in Cloudflare’s globally distributed edge storage (Workers KV). Read and write requests are served from the data center nearest the visitor or operator. Cloudflare’s storage replicates across multiple regions for durability.

What certifications does CleanClicks carry? CleanClicks the application does not carry independent compliance certifications today. Cloudflare, the infrastructure provider that runs the compute, storage, and network layers, maintains SOC 2 Type II, ISO 27001, and PCI DSS Level 1. Our security model relies on (a) Cloudflare’s attested infrastructure controls, (b) a deliberately minimal data footprint, and (c) per-customer storage-key isolation. If you require security documentation for a vendor review (for example, a completed CAIQ, a SIG Lite, or a custom security questionnaire response), please reach out via the contact form on this site and we will provide what we have available.

How are visitor identifiers handled? The cc.js tracking script hashes email addresses using SHA-256 in the visitor’s browser before the data leaves the device. For server-to-server integrations (e-commerce webhooks, the inbound API), the platform accepts raw email at the edge and hashes it before persisting to storage. Only the hash is stored, and only the hash is sent to ad platforms.

How are IP addresses handled? Visitor IP is read from the request at the edge for three purposes: geographic classification, bot filtering, and conversion attribution. It is written to short-lived storage (90-day retention) and never persisted longer. When a visitor opts out, their IP is never sent to any advertising platform.

How is customer access controlled? Customer data is isolated by domain at the storage layer — every key includes the customer’s tracking subdomain as a prefix. Inbound integration keys are validated using constant-time comparison. Internal admin operations are protected by SSO. There is no admin UI exposed to the public internet. General support staff have no access to raw customer conversion data; administrative access for system maintenance and incident response is limited to the operator (CJF & Associates LLC d/b/a ClickPath Consultants) acting in their administrative capacity, gated by SSO.

How is the platform tested? Application code is reviewed before every deploy. The platform has a substantial automated test suite (480+ tests across the conversion-tracking Worker alone) covering data sanitization, vendor dispatch, bot filtering, and webhook signature verification. Two production monitoring systems run continuously: a daily classifier health check across all customer domains and a 15-minute synthetic conversion probe end-to-end.

What about responsible disclosure? If you find a security issue we should know about, please report it through the contact form on this site. CleanClicks commits to (a) acknowledging your report promptly, (b) providing a substantive response without unreasonable delay, (c) not pursuing legal action against good-faith security researchers who follow this coordinated disclosure path and who do not access, modify, or destroy data beyond what is necessary to demonstrate the issue, and (d) crediting the discovering researcher in any post-fix advisory if the researcher consents to attribution. We do not currently operate a paid bug bounty program, but we welcome and value good-faith disclosures.

Has CleanClicks undergone a third-party penetration test? CleanClicks has not commissioned a formal third-party penetration test as of the date above. The security model relies on (a) Cloudflare’s attested infrastructure controls, (b) the deliberately minimal data footprint described above, (c) the per-customer storage-key isolation described above, and (d) the automated test suite covering data sanitization, vendor dispatch, bot filtering, and webhook signature verification. A third-party penetration test is on the security maturity roadmap; a published timeline will appear here once the engagement is scheduled.

11. Sub-Processors

The following providers process personal information on CleanClicks’s behalf:

• Cloudflare, Inc. — Compute, storage, edge network, bot protection, and SSO gateway. SOC 2 Type II, ISO 27001, PCI DSS Level 1.
• Stripe, Inc. — Payment processing for cleanclicks.ai subscription billing. SOC 2 Type II, PCI DSS Level 1.
• HubSpot, Inc. — Customer relationship management for marketing-site leads. SOC 2 Type II.
• Encharge — Marketing automation for cleanclicks.ai leads.
• Resend — Transactional email delivery for magic links, billing notices, and system alerts. SOC 2 Type II.
• Google LLC — Google Analytics 4 processing for the per-customer analytics property. Depending on the option you choose during onboarding, that property lives in your own Google Analytics account (created there with your explicit approval, or an existing property you select), or is a CleanClicks-provisioned proxied property on legacy configurations. Governed by Google’s Analytics and Ads data-processing terms.

A current list is also available on request and is referenced in the Data Processing Addendum.

12. Contact

We are happy to walk your security team through the architecture, provide additional documentation, or answer specific compliance questions. Use the contact form on this site and we will route the request to someone who can answer it.

This page is provided for informational purposes and describes design principles and architectural choices, not contractual commitments. The contractual terms governing the use of CleanClicks’s services are set forth in the Master Services Agreement, the Data Processing Addendum, and the Privacy Policy. To the extent any statement on this page conflicts with those documents, the contractual documents control.