---
title: "Follow a visitor across workspaces | Busymate AI"
description: "Platform operators: open one visitor's route across every workspace as stops, read each stop's honest identity state, and erase the visitor everywhere on request."
last_updated: "2026-09-15T11:36:58+03:00"
---
# Follow a visitor across workspaces | Busymate AI

Source: https://busymate.ai/hi/docs/guides/visitor-journey
Last modified: 2026-09-15T11:36:58+03:00
A platform operator can follow one visitor across every workspace they reached on Busymate AI — as a route with stops: where they arrived first, where they came back, whether they ever signed in there, and how much they talked. It is for the platform team only; a workspace operator sees a visitor's history inside their own workspace and nothing beyond it.

## Two visitor ids, two scopes

- **Workspace visitor id (`dv1_…`)** — derived per workspace from one first-party browser token. It groups a returning browser's sessions inside ONE workspace and powers the Inbox's "Returning visitor" badge and "This visitor" filter. Two workspaces never share it.
- **Platform visitor id (`pv1_…`)** — derived from the same token under a platform-only secret, with no workspace in the derivation, so the same browser gets the same id everywhere. It exists only in the platform's own graph and is readable only by platform operators.

No canvas or device fingerprinting is involved: the only signal is the opaque token the widget keeps in the browser.

## 1. Open a journey

- **From the Inbox** — on a returning visitor's conversation, the contact panel's badge offers **Cross-tenant journey →** to platform staff. It looks the workspace visitor id up in the platform graph and opens the route.
- **From Console → Platform → Visitors** — paste a `pv1_…` or `dv1_…` id into the search field, or pick a row of the recent-touchpoints feed.
- **From your AI tools (MCP)** — `get_visitor_journey` with `pv1_id`, or `list_visitor_touchpoints` with `dv1_visitor_id` for the reverse lookup.

## 2. Read the route

Each stop is one workspace, in order of first visit, and shows:

| On the stop | Meaning |
|---|---|
| The workspace's mark | Its real icon, or a monogram when none is published |
| First seen → last seen | The hop's arrival and most recent launch |
| Sessions · conversations | Counted at read time from that workspace's own tables — the graph stores no conversation data |
| `returned ×N` | The visitor came back to this workspace N times |
| Identity | One of four honest states, below |

Identity per stop is never merged across workspaces:

- **Linked to an account** — the workspace's own resolution is unambiguous; the subject is shown.
- **Anonymous** — recognised by the browser id only; never signed in there.
- **Seen with multiple accounts** — that browser was used with more than one account in this workspace. No subject is claimed; the count of accounts is shown instead.
- **No visitor id recorded** — the hop predates durable visitor ids.

Tap a stop for its touchpoint detail: entry page, referrer, sessions, conversations, the workspace visitor id, and a link to the workspace's Tenant 360 page.

## 3. Retention

The platform graph keeps a touchpoint for a fixed window after the visitor was last seen there (the window is printed on the journey, e.g. "90 days") and prunes it on its own schedule, independent of any workspace's settings. A visitor with no stops left is dropped from the graph.

## 4. Erase a visitor (GDPR)

**Purge this visitor everywhere** deletes the platform record — the id and every hop — after you confirm the exact call. Workspace-owned data (sessions, conversations, the workspace's own visitor grouping) is not touched; redact those in the workspace. The erasure is written to the platform audit log as a digest of the id, never the id itself. Redacting a contact inside a workspace also purges that person's platform record.

From your AI tools: `purge_platform_visitor_identity` with `pv1_id` and `confirm: true`.

## Who can see what

| Reader | Sees |
|---|---|
| Workspace operator | That workspace's visitor history only (Inbox badge, filter, previous conversations) |
| Platform operator | The cross-workspace route, the touchpoint feed, the purge |

Every layer enforces the same rule: the platform tables have no workspace-scoped read policy, the functions re-check the operator role on every call, the MCP tools serve only platform operators, and the Console section exists only in the platform navigation. None of the calls accept a workspace parameter.

## Reference

- Console: `/console/platform/visitors?pv1=<id>` · `?dv1=<workspace visitor id>` · `&stop=<workspace id>`
- MCP: `get_visitor_journey` · `list_visitor_touchpoints` · `purge_platform_visitor_identity`
- Related: [Recognize signed-in customers](https://busymate.ai/hi/docs/guides/identified-visitors)