Privacy

The product is in beta. This policy describes how the software is built and how we operate. It has not been reviewed by a lawyer. Before you put this on a production site with real users, read it against your own obligations rather than treating it as cover.

We collect very little. Requesting a page produces a server log entry containing the request path, timestamp and general technical metadata, which is ordinary web server behaviour and is retained briefly for security and debugging.

If you sign up for the beta, the form collects your name, your email address, optionally your website, and whatever you tell us you are trying to work out. That goes to two places: Splitforms, who deliver the submission to us, and our own database, so we can set up your account when the time comes. Splitforms is on the sub-processor list below.

We use it to contact you about the beta and nothing else. We do not sell it, we do not add you to an unrelated marketing list, and there is no newsletter to end up on by accident. Email privacy@paidamplification.com and we will delete it.

Here you are the data controller and we are the processor. Your visitors are your visitors. We hold their data on your instruction, and we do not decide what it gets used for.

The script is built to collect the minimum that makes a funnel work. The design rule is default deny: nothing is captured unless it has been explicitly allowed.

These are properties of the code rather than promises about our conduct, which makes them checkable. The tracker is a single file you can read.

Query parameters are an allowlist, never a denylist. A parameter we have not explicitly permitted is dropped before the event leaves the browser. This matters because authentication tokens in URLs are the leak that happens in practice.

The URL fragment is dropped unconditionally. Everything after the hash is discarded without inspection.

Raw IP addresses are never stored. An IP is used transiently to derive an anonymous identifier and a coarse region, then discarded. It is not written to a row, a log, or the archive.

Form field values are never captured. Form analytics records which field a visitor stopped at and how long they spent. It does not record what they typed.

Everything the script does collect is scrubbed a second time server-side, because a browser-side check is a defence rather than a proof.

We do not pool your visitors into cross-customer benchmarks. This is worth stating plainly because it is a feature we would like to sell and a decision that cannot be reversed once customers rely on it.

To be honest about the status: our intended contractual position is processor-only, which forecloses benchmarking permanently. That commitment will be in the data processing agreement before the product is generally available. Until that document exists and is signed, treat this paragraph as a statement of intent rather than a contract.

The sub-processor list is published and kept current. It names every third party that touches data on our behalf, what it receives, and where it processes.

Hosting and database regions are still listed as deployment-dependent, because the production infrastructure is not finalised. That gap is stated on the page rather than papered over.

Some analytics vendors market themselves as cookieless and therefore exempt from consent requirements. We are not going to tell you that. The European Data Protection Board's guidance from October 2024 attaches consent obligations to storing or accessing information on a device by a range of means, not only to cookies.

Whether you need consent depends on your jurisdiction, your configuration and your own legal basis. That is your assessment to make, and any vendor making it for you in a marketing page is overreaching.

If you are a visitor to a site running our script, we are the processor and the site owner is your first point of contact. We will support them in responding to you.

For customer-initiated deletion, the archive is addressable per event, so deletion means deletion in the archive as well as the live store. A deletion that leaves the data in a backup is not a deletion.

When this changes materially, the date at the top changes and we will say what changed rather than quietly replacing the text. That is the same commitment we make about product status on the about page.