Privacy

We measure how people use the public site, keep the minimum needed to deliver and operate an API key, and keep product-update consent separate from key delivery.

The website

quantdata.uk is a static site. It runs exactly one third-party script: Google Analytics 4 (measurement ID G-X7WQPJZ9DW), which tells us how many people visit, which pages they read, and roughly where in the world they are. That is used to decide what to write next. There is no advertising pixel, no session or screen recording, no A/B testing tool, no heatmapping, and no chat widget.

Analytics sets two first-party cookies in your browser, _ga and _ga_X7WQPJZ9DW, which hold a randomly generated ID so a second page view is not counted as a second person. They expire after two years. Google receives your IP address in order to derive an approximate country and city; for Google Analytics 4 it discards the address rather than storing it, and we never see it. We do not send Google your email address, your API key, or anything you have typed. When the free-key form on the homepage succeeds, a single event records that a key was sent — the event carries no email address and no typed text, only the fact that the form completed.

You can refuse it. Blocking googletagmanager.com in your browser or an extension stops the script loading and costs you nothing on this site — every page works identically without it. Google also publishes an opt-out browser add-on. Nothing here is behind a consent wall, and there is no cookie banner: if you would rather not be counted, block it and the rest of the site behaves exactly the same.

Apart from that script, pages load only from quantdata.uk itself: no external fonts, no other CDN scripts, no embedded widgets. Our host records ordinary web-server request logs (IP address, requested path, timestamp) for reliability and abuse protection, as any web server does. We do not use those logs to build any profile of you.

If you request a free API key

The free-key form and POST /v1/access/free-key ask for an email address. An account, password and card are not required. We normalise the address, create or retrieve one qd_ key for it, and send the raw key only to that inbox. The raw key is never returned in the API response or placed in a URL.

One path works differently, and you should know which. An AI assistant connected over our MCP server can request a key for you with the quantdata_request_free_api_key tool. Because an assistant cannot read your inbox, that tool returns the key to the assistant as well as emailing a copy to the address given. Two consequences. The key is visible to whoever operates that assistant session, so treat it as a shared credential; it expires after 30 days and covers only the free daily allowance. And if someone enters your address without asking you, you still get the email — it says an assistant requested the key and how to have it disabled. That path never returns a key that already belonged to the address, so no existing free or paid key can be handed to someone else, and it never records marketing consent, because a third party entering your address is not you agreeing to anything.

We store the email address, the key and its access status, when it was created, the request source label, and usage needed to enforce the shared 10-successful-call allowance per UTC day across all four endpoints. AgentMail processes the address and message content to deliver the key and necessary service email.

Product updates are a separate, optional choice. The marketing_opt_in field and the matching form control default to false. If you actively opt in, we first record the request as pending, with its time and the consent wording version. The recipient must reply SUBSCRIBE to the key-delivery email before it becomes active; until that reply, we send no marketing updates. This prevents someone else from subscribing an address they do not control. If you do not opt in, we still send the key-delivery email and necessary messages about the key; those service messages do not add you to marketing. You can withdraw product-update consent at any time by replying or emailing quantdata@quantdata.uk, without losing API access.

If you subscribe to the daily research notes

The sign-up form on this site posts your email address and your language choice (English or Chinese) to a small service Quant Data runs on Google Cloud in Hong Kong (quantdata-newsletter, Cloud Run, region asia-east2). Submitting the form puts the address on the list at once; there is no separate confirmation step. The first email is a welcome note carrying the unsubscribe link, so an address someone else entered by mistake can be removed with one click. Submitting an address that is already on the list does not create a second record: it updates the language choice and, at most once every five minutes, resends the welcome note.

We store, in Google Cloud Firestore in that same region: the normalised address, the language, the status, the time of each step, a label for which page the form was on, and a random token used only in the unsubscribe link. Records created before 6 September 2026, when the list used a confirmation step, also carry the token from that confirmation link; it does nothing further. The record's identifier is a hash of the address, not the address itself. Unsubscribing deletes the record; we keep no suppression list and no copy of the address.

To limit abuse, each sign-up attempt increments a counter keyed by a salted hash of the requesting IP address and the UTC date. The salt lives in the same database, not in configuration; the IP address itself is not stored. AgentMail delivers the welcome email and the notes, and processes the address for that purpose. The notes themselves are the same text as the public pages under /notes and contain no tracking pixels or per-recipient links other than the unsubscribe link.

If you subscribe to the paid API

Checkout happens on Stripe's own pages, not here. Your card number, your billing address and the tax ID you can optionally add to an invoice are entered there and stay in Stripe's records under its privacy policy. Card details never reach us. There is no payment form anywhere on this site, so there is nothing here that could see them.

What we store afterwards is small and fixed. Per subscriber: the Stripe customer ID, the Stripe subscription ID, the billing email address Stripe collected, and the API key those belong to, alongside that key's own status, expiry date and fair-use cap. That is enough to tell whether a key is currently paid for and where to write if something breaks. If the checkout email matches a free key, that same key is upgraded in place. Your billing address and any tax ID stay in Stripe's records, not ours.

Stripe is the payment processor and handles that data as its own controller. Cancelling is done in Stripe's customer portal; we find out because the subscription state changes, not because you tell us.

If you email us

We hold your email address and what you wrote so we can answer you and sort out anything to do with your key. Writing to support does not subscribe you to product updates.

Email addresses are never sold or rented. They are shared only with processors needed to provide the service, such as AgentMail for email delivery and Stripe when you choose to subscribe.

Ask us to delete your email and correspondence and we will, and confirm it. If you have an active subscription, that means cancelling it first, because the billing email is how a key is identified.

If you use the API

Each request writes one usage row: which key was used, which endpoint, which symbol, and when. That is what metering, fair-use enforcement and debugging need, and it is all we keep. We do not log request bodies for market-data calls; those calls are GET requests.

Those rows are tied to a key, and a free or paid key is tied to its email address. So yes, we can in principle see which symbols a given key looked up. We do not sell or share that usage, and it is used only to operate, protect and debug the service. Usage rows are kept while the key is active and for a short period afterwards for reconciliation, then deleted.

If you use the anonymous first look

A caller with no key can receive 1 successful first-look response per source per UTC day. That allowance has to be counted against where the request came from. We do not store your IP address in the allowance table. It is hashed with a secret salt when the request arrives, and only that hash is written — a value we cannot turn back into an address. The row holds the hash, the UTC date and a call count.

Those counters are deleted after 7 days. An anonymous call also writes the same usage row a keyed call does — endpoint, symbol, timestamp — with the hash standing in for the key. There is no email and no account anywhere in that path, and the hash is not linked to anything else we hold. Our host separately keeps ordinary web-server request logs, as described above.

One case stores even less. When a request arrives from a recognised AI-platform fetcher — the servers ChatGPT, Claude or Perplexity use when a user asks them to read a URL, recognised by the User-Agent header those platforms document for user-triggered fetching, or by ChatGPT's signed-agent request header — the allowance is counted against a single shared daily pool for that platform (100 successful calls per UTC day per platform). The counter row for that pool holds the platform's name, the UTC date and a call count: no address, and no hash of one. A pooled call still writes the same usage row an anonymous call does — endpoint, symbol, timestamp — with the platform's name in place of the hash, and the pool's counter rows are deleted on the same 7-day schedule as the anonymous counters.

The free parts need nothing

The static Max Pain and GEX pages, and every other page on this site, work with no key, no account, no email and no login. These pages are the permanently free part. If you never request a free key, subscribe or write to us, the only identifying material available to us is the analytics and ordinary hosting data described above; the anonymous API allowance stores only its salted source hash.

Your rights, and how to use them

You can ask what we hold about you, ask for it to be corrected, ask for it to be deleted, or ask for a copy. Email quantdata@quantdata.uk. It is one person reading a small mailbox, so the answer is usually quick and always from a human.

Last updated 6 September 2026. Material changes will be noted here with a new date.