A merge can occur in the following cases:

• Automatically in real time when the visitor is authorized on the site. In this case, the guest (who was there before authorization) will be merged with the authorized visitor. The main visitor is considered to be authorized, while the guest is secondary. The history which the guest had before authorization is added to that of the authorized visitor.
• Automatically once a day (at the time of writing this article) when identifying visitors with the same email address. The main visitor is the one who was last on the site (according to the last_visited_at attribute); the older visitor is the secondary one.

Description of the merge process

1. The history of events and the visits of the secondary visitor are transferred to the main visitor, complementing their history according to the chronology (there may be some mixing of events/visits).

2. The characteristics of the secondary visitor are transferred to the main visitor, complementing them, but not replacing them:

• If the secondary field is filled in and the primary field is not filled in, the value will be transferred from the secondary to the primary.
• If the secondary field is filled in and the primary one is also filled in, the primary value will be left as it is.
• If the secondary field is not filled in and the main field is filled in, the value of the main field will be left as it is.

3. The history of conversations in the secondary visitor’s chat is transferred to the main one, complementing their conversation history in chronological order (there may be some mixing of messages).

4. The history of the secondary visitor’s interaction with widgets is transferred to the main one, complementing their history.

5. The service entity associated with orders, the opening event, and the lead of the secondary visitor is transferred to the main one.

6. The secondary visitor is removed.