The visitor token

Every visitor gets a token on their first pageview: an anonymous ID with an ar_ prefix. It's the thread that connects everything a person does before you know who they are — the ad click on Tuesday, the pricing page on Thursday, the signup a week later. When your identify call fires, the whole thread attaches to that email at once.

How it behaves

• It lasts. The token lives for a year and is re-stamped on every visit, so an active visitor never expires.
• It spans your subdomains. One token covers yourdomain.com and everything under it — see Domains & subdomains.
• It's stored redundantly. The token is kept in both a cookie and localStorage; either one alone is enough to recover it. You can see it yourself in devtools under the name ar_token. If a browser wipes both, a returning visitor can often still be re-linked server-side.
• It rotates on reset. Calling window.ar('reset') mints a fresh token for shared-browser setups.

Reading it: getToken

const token = window.ar.getToken();  // "ar_..."

Use this when you want to stamp the visitor's identity into your own systems — for example, storing it with a lead in your CRM, or passing it as ar_token to the conversions API so a server-side conversion links straight back to the on-site visitor even when no email is available.

One rule: getToken is a direct method and only exists after the pixel has loaded. Unlike identify, it can't be queued — a queued call has nowhere to return the value. If you call it on page load, check it exists first:

if (typeof window.ar?.getToken === 'function') {
  const token = window.ar.getToken();
}

Most customers never touch getToken. Email identity plus the built-in integrations cover the normal paths; this is the escape hatch for wiring up systems we don't integrate with yet.