SendOps already knows what happens to your **email** — opens, clicks, bounces — and, through [Activities](/audience/activities), what happens inside your **product**. Website Identity adds the third place a customer shows up: your **website**. When a person you have already identified comes back to your marketing site, your docs or your pricing page, SendOps records a `site_visit` activity on their timeline, and a [Drip Workflow](/workflows/triggers) can enter on it.

The classic use is "welcome back": a customer who has gone quiet lands on your site again, and a workflow sends them something relevant. Another is "looked at pricing twice, has not bought" — a `site_pricing_viewed` event you record yourself, with a follow-up a day later.


  Website Identity is being enabled workspace by workspace. If you do not see **Website** under Workspace yet, it has not reached yours. The identify step below can be wired ahead of time and is the recommended order anyway.


## How it works

Three pieces, in the order you must set them up:

1. **Your backend identifies the customer.** At login and signup, your server asks SendOps for the contact's **visitor id** — a random, opaque value that belongs to that contact and nobody else.
2. **Your backend sets it as a cookie.** The id goes into a first-party cookie called `so_vid` on your registrable domain, so every site you run under that domain can see it.
3. **The snippet reports visits.** A 2 KB script, `sendops.js`, installed directly or through Google Tag Manager, reads the cookie and sends one `site_visit` per browser session. It can also send custom `site_*` events you choose.

SendOps matches the id to the contact and records the activity. From then on it is ordinary workflow and segment material.

The order matters because the snippet is **read-only**. It never creates an identifier of its own: if there is no cookie, it does nothing at all. Install it before identify is wired and the health card will simply show that nothing has arrived.

## What it deliberately does not do

Most website trackers assign every visitor an anonymous id and try to join it to a person later. Website Identity does the opposite, and the difference is the whole design:

- **No anonymous tracking.** A visitor who has never logged into your product is invisible to SendOps. The snippet sends nothing and stores nothing for them.
- **No fingerprinting, no cross-site graph.** The id is minted by SendOps, random, and derived from nothing about the person. It says "this is contact X" and nothing else.
- **Unknown ids are dropped at the edge.** A cookie carrying an id SendOps does not recognise — one you revoked, one someone guessed, one belonging to a contact you have since archived — is discarded with no record and no log line.
- **The snippet never writes a cookie.** Your server sets it, over HTTP. That is not just tidiness: Safari caps a cookie written by JavaScript at seven days, and a script-set id would quietly expire on every Safari user a week after they logged in. An HTTP cookie from your own domain keeps its full 400-day lifetime.

Whether setting the cookie needs consent under your policy is your call. The snippet has a consent mode for when it does — see [Installing the snippet](/website/installing-the-snippet#consent).

## What you see in SendOps

- **Workspace → Website** holds your site key, a three-step install guide with your key filled in, and a [beacon health card](/website/troubleshooting-beacons) that shows what arrived over the last seven days.
- A contact's detail page shows a **Website** badge once they have a visitor id, with when it was issued and a masked copy of the id.
- `site_visit` and your `site_*` events appear on the contact's activity timeline with the source **site**, and in every place activities are usable: `enter on activity.site_visit` in a workflow, `exists(activity.site_visit within 7d)` in a segment.
- Issuing a visitor id also records one `site_identified` activity, so a workflow can greet somebody the moment they are identified, before any visit arrives.

## Who can set it up

The **Website** page is available to the Owner and Org Admin roles. Other roles do not see it. The identify call is made with an API key that has the `api.contacts.manage` scope — see [API Keys](/api-integrations/api-keys) — and the site key itself is publishable: it sits in your page source, identifies your workspace to the beacon, and can do nothing else.

## What's next?

- [Installing the snippet](/website/installing-the-snippet) — the site key, the cookie rules that catch everyone out, script tag or Tag Manager, consent and custom events.
- [Troubleshooting beacons](/website/troubleshooting-beacons) — reading the health card, and the four silent misconfigurations.
- [Triggers & enrollment](/workflows/triggers) — building the workflow that acts on a visit.
- The developer guide at [developers.sendops.dev](https://developers.sendops.dev/api-reference/website-identity) for the API detail and full cookie contract.