message.comDevelopers
Developers/Concepts/Visitor vs contact vs user

Visitor vs contact vs user

Three overlapping words for "the person on the other side of the chat". They are not interchangeable. This page defines each, explains the identity model message.com uses, and shows how a single human moves between the three states.

Visitor

A visitor is anyone who has loaded the widget script on a site. The widget assigns a long-lived browser cookie the first time it boots. From that moment on, every page view, conversation, and event is attributed to the same visitor record, even if the person never types their name.

Anonymous visitors are still useful. You can see what page they landed on, how long they have been browsing, and which campaign brought them in. They can start a chat without filling in any form. message.com's Visitors API returns one row per visitor regardless of whether they are identified.

Contact

A contact is a visitor that has provided some identifying information: an email address, a phone number, or a name typed into a pre-chat form. The cookie is still in play, so the visitor and contact are the same record. Adding a contact field promotes the visitor into a contact in the dashboard, but it is the same row in the database.

Contacts are the unit you market to and report on. CSAT survey delivery, transactional email, follow-ups, and cross-channel deduplication all key off the contact email. See canned response for one-tap reply patterns aimed at contacts.

User

A user is a contact that has authenticated. Either they logged into your product and you called Message.identify from the browser, or they replied from an email address you already had on file, or you synced them in from your CRM with a known external ID.

Users get the strongest cross-channel stitching because you have a stable identifier from your side. A logged-in user who switches devices still resolves to the same record because the external ID is the join key.

The identify call

Promoting a visitor to a user happens client-side with one call. The full reference lives at identifying visitors:

Message.identify({
  email: "[email protected]",
  userId: "crm-4567",
  userHash: "<HMAC-SHA256 server-side>"
})

The optional userHash prevents one logged-in customer from impersonating another by guessing email addresses. Compute the HMAC server-side using your workspace signing secret.

Why three words instead of one

Different tools picked different terms. Intercom uses "users" and "leads". Zendesk uses "end users". Drift uses "contacts". None of these distinguish anonymous browsing from authenticated identity, which is the difference that actually matters for routing, AI context, and security.

message.com keeps all three states on one record. The vocabulary helps you reason about which fields are trustworthy. Anonymous data is hint-quality. Contact data is self-asserted. User data is verified by your auth system.