Audience & Identity
Who Rover recognizes, how personally it may speak, and what it remembers between conversations.
Rover works without knowing anyone; visitors are anonymous by default. Pass signed-in identity so Rover can keep accounts separate and Rover Analytics can group outcomes by account. If you also pass a preferred name, plan, or goals as bounded visitor context, Rover can use those details in the experience.
These controls live in the Workspace under Audience. The sign-in card's header carries a live readout — how many visitors Rover currently recognizes, whether sign-ins are flowing, or that none have arrived yet.
The sign-in call
One call, wherever your app learns who signed in. The Audience view has a picker for your sign-in setup — Firebase Auth, Clerk, Auth0, Supabase, Amazon Cognito, Auth.js, OpenID Connect, or something else — and adjusts the snippet to match. The generic form:
// Wherever your app learns who signed in:
window.rover?.identify({ userId: user.id, email: user.email });
// On sign-out:
window.rover?.update({ visitor: null });
window.rover?.resetIdentity();The sign-out pair matters. resetIdentity() detaches the identity and rotates Rover's anonymous continuity, so on a shared machine the next account never inherits the previous conversation.
You can also pass small, non-sensitive facts your page already knows — a preferred name, a plan, a goal. Rover treats them as background, never instructions; keep anything secret out.
window.rover?.update({
visitor: {
name: user.preferredName,
context: {
profile: { role: user.role, company: user.companyName },
account: { plan: user.plan },
intent: { goals: [user.primaryGoal] },
},
},
});Already running Segment, PostHog, Amplitude, or Google Analytics? Set identityProvider in your boot call to a built-in adapter — rover.identityAdapters.segment(), .posthog(), .amplitude(), or .ga() — and Rover reads who's signed in from the tool that already knows. firstAvailable(...) chains several and takes the first answer; any function that returns the signed-in visitor works as a custom adapter.
Verified account context
For teams that want Rover to fetch verified account details from their own server — most sites never need this. Your server mints a short-lived token and your page hands it to Rover; Rover exchanges it once, server to server, at the lookup address you set. Raw customer details never enter prompts or links.
- Signed — Rover signs every request, so your server can verify who's calling before it answers.
- Bounded — the context you return is grouped (profile, account, intent, success, support, activity, facts) and capped at 2,048 bytes. Return only the documented shape — never secrets or payment details.
- On your clock — pick how long Rover waits (150 ms to 1.5 seconds, 650 ms recommended) and how long an answer is reused (15 seconds to 15 minutes, 2 minutes recommended). Past the wait, Rover moves on without the context. The lookup address must start with
https://.
Test it before trusting it: paste a disposable test token from your server into Try the connection and press Test it. The result reports the connection time and a redacted preview of what came back, and the last test stays on record with its timestamp. See the endpoint contract shows the exact request Rover sends and the response shape it expects.
What Rover remembers
Memory is off until you turn it on — by default, every visit starts fresh. Turned on, Rover carries a little recent history into new conversations: up to 12 short excerpts of what a visitor asked, each capped at 160 characters, with at most 3 appearing as background in any conversation. What Rover answered or did is never carried in.
| Setting | Choices | Default |
|---|---|---|
| Who can be remembered | Signed-in accounts only, or signed-in accounts and this device | Accounts and this device |
| Recent requests Rover sees | 1, 2, or 3 | 3 |
| How far back | 7, 30, or 90 days | 30 days |
| Keep conversation history | 30 days, 90 days, a year, or until someone deletes it | 90 days |
| Consent category | Functional, or behind the analytics consent | Functional |
Pick Functional when memory is part of how your site works; pick the analytics option to hold memory behind the visitor's analytics consent. A separate setting decides whether Rover uses a known name — once, naturally near the beginning, or never.
Administration
At the bottom of Audience, Visitor and memory administration shows the totals — recognized visitors out of all visitors, how many memory records exist — and lists the most recently recognized visitors.
- Export memory runs in the background and reports progress in records; when it finishes, Download export hands you the file.
- Clear site memory asks you to confirm, then new conversations start with a clean slate immediately while old records are deleted in the background.
- If either job stops partway, the panel says so and offers a safe retry.
The same panel holds Account-wide rtrvr context — a preferred name, locale, and preferences shared by Retriever surfaces across your whole account. It is labeled that way because it isn't site configuration: clearing it leaves your Rover site setup unchanged.
Privacy
- Ids are masked in Rover Analytics — user and account ids are hashed before analytics sees them, so reports group by account without carrying raw identifiers.
- An email recognizes the account — a display name only ever comes from a name you pass — and it never enters what the model reads.
- Rover never guesses a name from an email.
- Anonymous continuity comes from a first-party, site-scoped secret — never from IP address, browser details, or fingerprinting — and it never stands in for a sign-in: verified account context always takes a token your server minted.