Skip to main content
Identification means linking a visitor browsing your website to a specific contact ID in Engage. Until that happens, their activity is stored against their browser instead. Once a visitor is identified, all their activity from that browser — including the activity recorded before they were identified — is connected to their contact record in Engage.
Because anonymous activity is connected retroactively, never restrict cart() or productview() calls to logged-in or identified visitors. Send events for everyone.

​
How a visitor gets identified

The tracking script identifies a visitor in three ways:
  1. They click a link in an Engage email. The link carries a vtid query parameter, which the script reads from the URL.
  2. Your site identifies them and calls setContactId(), for example on login, registration, newsletter signup, completed purchase, or soft identification.
  3. A _vaI cookie already exists from a previous visit.
The identification then applies to all subsequent events from that browser, until the cookie expires or changes (such as when a different person logs into the same browser).

See how soft identification works

​
The order of events

  1. The visitor gives consent for cookies. No cookies are created before this.
  2. Activity in that browser is recorded anonymously against the client ID in the _va cookie.
  3. The visitor is identified, and their contact ID is stored in the _vaI cookie.
  4. Engage connects the earlier anonymous activity to that contact.

​
The cookies

Both cookies are first-party.
_vaI is _va followed by an uppercase letter I (I as in Ingemar), not a lowercase L.
In Safari, any cookie created with JavaScript lives for a maximum of 7 days, regardless of the expiry date set. See server-side cookies for the workaround.

​
About the vtid parameter

vtid holds the contact ID in an encoded form, which Engage decodes internally. An Engage user cannot retrieve the contact ID or identify the contact from the vtid value alone. When you send events, the contactId field accepts either the full contact ID guid or the encoded value from vtid.

​
Using setContactId()

Call setContactId() with the visitor’s contactId at the moment your site identifies them:
When using soft identification on a site running the tracking script, take the contactId from the decrypted eClub query parameter. setContactId() does not generate a request to the Collect endpoint.
Never call setContactId() with zero, an empty string, null, undefined or any other invalid value.
A visitor may already be identified without being logged in. For instance, if they arrived from an email link. Calling setContactId() with an invalid value clears that existing identification.
Voyado recommends also including contactId explicitly in every cart() and productview() event for identified visitors.

​
Server-side cookies

Apple’s Intelligent Tracking Prevention (ITP) caps client-side cookies and LocalStorage in Safari at 7 days. Since _vaI is created by the script, an identified visitor who doesn’t return within 7 days loses their identification. The cap does not apply to cookies created server-side. Script version 0.1.7 and later can therefore read a server-created cookie named _vaI_server and use it to recreate _vaI. Identified visitors then stay identified when they return, even after months away.

​
How to implement it

Server-side, check whether the incoming request contains a _vaI cookie. If it does, copy its value into a new _vaI_server cookie with a one-year expiry and add it to the response.
An example in C#
Server-side cookie

Server-side cookie

​
When _vaI is recreated

The script recreates the _vaI cookie in any of these cases, checked in this order:
  1. Your site calls setContactId(), or includes contactId in an event.
  2. The URL contains a vtid parameter.
  3. LocalStorage contains a vtid key.
  4. A _vaI_server cookie exists.

Troubleshoot identification problems