We never receive a user identifier
Shadow asks your analytics two reporting questions — what your event names are, and how many distinct users did each thing per day. Your analytics does the counting and sends back a list of numbers. That is the whole surface, and the rest of this page is the detail behind it.
What Shadow does
Two reporting endpoints, and nothing else
/api/2/events/list returns your event names. /api/2/events/segmentation returns daily counts of distinct users per event. Amplitude does the counting. Those are the only two calls a forecast needs, and you can verify that from your own API logs.
Names before numbers
The step where we work out what to forecast reads event and property NAMES only — no counts, no values, nobody's behaviour. So the entire mapping conversation happens before any measurement of your users has been requested, and you approve the pair before it is.
Only ever reads, though the key could do more
Nothing is written back to your project. No events, no cohorts, no properties. No emails, billing, webhooks or outbound user communication. No autonomous decisions. Amplitude has no read-only key, so this is a property of what Shadow calls rather than of the credential you issue — see below, because you should not take that on trust.
Your key, for one session
On the self-serve flow the key is used for those requests and not written anywhere — no database row, no session, no log line containing it. Close the tab and nothing of yours remains. On a pilot we hold it per tenant in that tenant's own environment, so it rotates and revokes one customer at a time.
No model sees your numbers
A language model is given event NAMES to suggest what is worth forecasting. The counts never go near one. Every figure on screen is arithmetic — the forecast, the range, the probability, the accuracy score. Switch the suggestion step off and the product still works.
What Shadow does not do
We never call the export endpoint
/api/2/export returns raw NDJSON: every event, every user id, every property. An earlier version of Shadow used it. Nothing does now.
We do not receive a user identifier
Not hashed, not pseudonymised, not held briefly. The aggregate endpoints return lists of daily numbers, so there is no row about a person for us to hold, lose, or be asked about.
We do not need an SDK or a code change
Nothing is installed in your product. No tag, no script, no library, no deploy.
We do not run inside your infrastructure
Worth saying plainly because an earlier version of this page claimed otherwise. Shadow calls Amplitude's API from our side. The reason that is acceptable is the line above: there is nothing user-level in the response.
“Can that key do more than you say?”
Yes, and we would rather you heard it here. Amplitude does not offer a read-only key. A project key and secret can read, write or modify depending on which endpoint you point them at — the restriction is per endpoint, not per credential. The same pair would open the raw export endpoint, and some write endpoints too.
So the guarantee is in our code, not in the credential, and anyone telling you otherwise about an Amplitude key is wrong. What makes ours checkable rather than a promise: we call exactly two endpoints, both named above, and every call we make appears in your own Amplitude API logs. Compare them against that list whenever you like.
If you need it enforced rather than verified, there is one architecture that does: a warehouse connection with a database role granted SELECT on two aggregate views and nothing else. Then the permission is the boundary and our code cannot exceed it even by mistake. It is on the roadmap and it is not built — and this is the strongest reason to build it.
What we store, and for how long
| Thing | Self-serve | Pilot |
|---|---|---|
| Your API keys | Not stored at all | Per-tenant environment, revocable by you |
| Event and property names | Not stored | In a reviewed config, in version control |
| Daily counts and rates | In the page, gone when you close it | Retained, so forecasts can be scored |
| Forecasts we made | Not stored | Written once on the day made, never edited |
| Anything user-level | Never received | Never received |
What we have not got yet
Shadow is pre-launch and this page would be worth less if it pretended otherwise. If your vendor process requires any of the following, we are not ready for you yet and it is better to know now.
- · No SOC 2 or ISO 27001.
- · No third-party penetration test.
- · No DPA template. We will sign yours.
- · No single sign-on, and no per-person audit trail on internal access.
- · One source supported, Amplitude. Mixpanel and warehouse connections are on the roadmap.
- · No way to enforce read-only at the credential, because Amplitude does not offer one. A warehouse role scoped to two views would fix that and is not built.
What we would argue is that the surface you are reviewing is two reporting calls with no user-level data in the response, verifiable against your own API logs, and a key you can revoke in one click — which is a smaller thing to approve than most vendors ask of you.