Skip to content

Projects and keys

A project holds one site's data. Keys are how code reaches it, and each key does exactly one kind of thing.

3 min read Updated Suggest an edit

Create a project

Open the workspace's Projects and choose New project. A project is one site or one product: it carries its own keys, tracking rules, goals, alerts, boards and share links, and its data never mixes with another project's.

Give it a name and an IANA time zone — the zone every report and every whole-day range is read in. A project with no zone set reports in UTC. Both can be changed later on the project's Settings page.

Key types

Keys live on the project's Keys page.

Scope What it can do Safe in page source Use it for
Send events Write events to this project. Yes The browser tracker, mobile apps, servers sending events.
Read stats Query this project's numbers. No Reports, spreadsheets, your own back office.
Manage project Change this project through the API, limited to the abilities you tick. No Automation that creates goals, keys or share links.

Scopes never overlap. A sending key cannot read and a reading key cannot write. If one leaks, the damage is bounded by the one thing it was allowed to do.

The install key is the sending key the tracker uses. It is the one key DataVisitors can show you again: its secret is sealed so an administrator can re-open the install tag. Every other key is shown once.

Create a key

  1. Open Project → Keys and choose Create key.
  2. Pick the scope and name the key after where it will live — Website, iOS app, Finance report. For a managing key, tick the abilities it needs and no more.
  3. Optionally give it an expiry in days.
  4. Copy it now. The row afterwards stores only the key's first 12 characters and a hash of the rest — enough to name it in a list, never enough to use it.

The list shows each key's scope, its opening characters and when it was last used, and marks a key that has gone unused for 30 days.

Narrow what a key may do

Beyond its scope, a key carries rules:

  • Allowed origins — the browser origins a sending key accepts requests from. See Allowed origins.
  • Allowed IP ranges — the addresses a key may be used from, for a key that lives on servers you control.

A request that breaks a rule is refused with 403 and never reaches storage. Rule changes take effect everywhere immediately: the service is told to drop its cached copy of the key in the same transaction that saves them.

Rotate or revoke

Rotate mints a new secret for the same key and keeps its policy — origins, IP ranges, abilities, expiry — then shows the new secret once. The old secret stops working at that moment, so deploy the new one first.

Revoke is immediate: the key is evicted from every running process, and anything still using it receives 401 on its next request. It cannot be restored. Create the replacement, deploy it, then revoke.

A key of another project, an unknown id and an already-revoked key all answer the same way — 404. Nothing about a key you may not see is distinguishable from a key that does not exist.