In order to connect events with visitors, the visitors must be identified by eSales. This can occurs on two levels, by device and by actual visitors. All visitors can experience device-based personalisation through an assigned randomized customer key.
To enable cross device personalisation and personalised recommendations off-site, such as with Email Recommendations, an identifier tied to the visitor is required. This is normally only applicable for signed in visitors and requires a secret visitor identifier.
Selecting visitor identifier¶
The identifier must uniquely identify the visitor, but must not be an externally known customer property such as a user name, email address, or social security number as that is a personal data breach liability and against the EU General Data Protection Regulation.
The identifier must however be possible to obtain given a visitor, regardless of device and site, where personalisation is to have any effect. For example, to enable personalised email recommendations, it must be possible to access the identifier within the email service provider.
A retailer will typically have their own internal identifier systems for visitors, such as using identification tables or secret hashing of visitor data, to enable personalisation. This type of internal identification will likely only be able to provide personalisation for members or signed in visitors to a retailer's site.
Identical customer keys
For any external use, such as Email recommendations, the same identifier used on the site must be supplied. This means that the
customerKey argument provided to Email recommendations must match the
customerKey that is set when a visitor signs in to a retailer's site.
Web Component integration¶
When a visitor signs in, set the selected retailer visitor identifier as the
customerKeyon the eSales session object:
esales.session.customerKey = 'secret-retailer-visitor-identifier';
When a visitor signs out, call the reset method on the eSales session object:
Web API Integration¶
When using the Web API both device based and visitor based personalisation must be integrated.
- When an unknown visitor triggers a request, assign the visitor a random customer key and set the assigned customer key to the request.
- Use UUID v4 as initial randomized customer keys
- Persist the randomized customer key for the visitor, for example in a cookie or local storage.
- When a visitor with an already assigned customer key triggers a new request, set the assigned customer key on the request.
- When a visitor signs in to the site or is otherwise identified, replace the previously assigned customer key with a secret visitor identifier to be used in future requests.
- When a visitor signs out, reset the session:
- Signal closing of the current session through an end notification with the secret visitor identifier as the customer key in the notification.
- Randomize a new customer key and replace the previously assigned secret visitor identifier.
For client side integrations, the API library,
esales-lifestyle-api, offers support for working with session keys and customer keys.
If more than one customer key is provided for a session, eSales will automatically link them together. An example of this is when a session is started with a visitor that is not signed in to the site at first. The visitor still triggers events in the session. While the session is still active, the visitor signs in to the site thus creating an new or activating a pre-existing customer key.