Skip to main content
Website visitor identification starts with a small script installed on your site. Without it, Swan has no visits to identify and this trigger never fires.

​
Installing the script

You’ll find your organization’s tracking script and its setup status on your Website Visitor trigger: open Triggers, go to that trigger’s Configuration, then the Script tab (if you don’t have one yet, create it at agent.getswan.com/triggers/new?type=NEW_WEBSITE_VISITOR). Add it to your site the way you’d add any tracking snippet — directly in your site’s HTML, through Google Tag Manager, or through your site builder’s custom-code/embed option (most no-code platforms support this). The script is tied to your organization, not to a specific page, so one install covers your whole site. If you already run a visitor identification pixel, remove it first. Swan’s script includes RB2B’s pixel, and RB2B only supports one instance per page — with both installed, whichever loads first wins and the other silently stops reporting, with no error to tell you which. See replacing a visitor identification tool.

​
Domain allowlist

The script only reports visits from domains you’ve explicitly allowed. Add every domain and subdomain you want tracked, under Allowed Domains on the same Script tab — a script installed on a domain that isn’t on the allowlist won’t report any sessions. If you change your primary domain, re-add it to the allowlist; the previous one isn’t automatically replaced.

​
What you can configure

These live on the trigger’s Configuration → Settings tab:
  • Excluded paths — specific paths on your site (for example, an internal admin area or your careers page) that should never generate a tracked session.
  • Allowed country codes — restrict tracking to visitors from specific countries. Leave this empty to track visitors from anywhere.
  • Minimum session time — a visit has to last at least this many seconds before Swan will attempt to identify it, which helps filter out bounces and bots. There’s no minimum enforced by default.
  • Identification mode — choose whether Swan tries to identify every visitor, including anonymous company-level matches from their IP address, or restricts identification to visits it can already tie to a known contact.
  • CRM exclude lists — companies belonging to lists you choose (for example, existing customers or a do-not-contact list) are filtered out before they can qualify a visit for your trigger.
  • Daily identification limit — a cap on how many visits get identified per day, defaulting to 1,000. Your plan may impose a lower effective cap than the one you set here — whichever is lower wins.

​
Sending a custom visitor ID

If your site already knows who the visitor is — they’re logged into your product, or arrived from a link carrying your CRM ID — you can pass that identifier to Swan alongside the visit. The install snippet Swan gives you already includes a commented-out swan.eId line for exactly this: uncomment it and set your identifier before the script loads. With that line filled in, the full snippet looks like this:
Use a stable, non-sensitive opaque identifier — a user ID from your product, a CRM record ID, whatever lets you tie the visit back to your own systems — never an email, phone number, name, or other sensitive value. Swan accepts any non-empty string or number and truncates values longer than 500 characters. It stores the value on the visitor session as the External Visitor ID, and it’s included in the visit details your agent sees when the trigger fires, so workflows can reference it (and it appears in the visitor’s previous-visits history on later sessions). The value is only accepted from domains on your allowlist, and Swan redacts it from its own internal logs.

​
Verifying the install

Ask Swan, from Chat or any conversation, to check whether the script is live on your site — it can check your registered domain directly rather than you needing to inspect page source yourself. If the script is installed but no visitor data is showing up, the most common causes are a missing domain on the allowlist, a country filter that excludes your test traffic, or a minimum session time your test visit didn’t reach.

​
Common questions

Do I need to reinstall the script after an update? No — the script updates itself; there’s no version to track or reinstall. Can I run Swan’s script alongside my existing RB2B snippet? No — the two conflict and only one will report, silently. Remove the standalone snippet before installing Swan’s; see replacing a visitor identification tool. Can I exclude specific IP addresses, like internal office traffic? Not directly. Use path exclusion for internal-only pages, or a CRM exclude list if your internal team’s company domain would otherwise be identified as a visit. Does installing the script require cookie consent? Session tracking involves collecting IP address and browsing behavior; whether that requires cookie consent under your applicable privacy law depends on your setup and jurisdiction — check with your legal team. What happens to visits from a domain I haven’t added to the allowlist? They’re dropped — Swan never creates a session for them. Can I lower the daily identification limit to control cost? Yes — set a lower daily limit than the default 1,000 if you want to cap how many visitor identifications (and their associated credit cost) happen per day.