Приоритеты клиентов при объединении и затирании email/телефона/id при противоречиях

Критерии выбора приоритетного клиента работают в двух случаях.

1. Когда не можем объединить клиентов из-за противоречий в email, телефоне или идентификаторе (включен запрет на объединение клиентов с разными уникальными ID).
2. Когда можем объединить клиентов. Например, совпадает email. Но нужно выбрать от кого из клиентов взять информацию о личных данных и дополнительных полях.

Приоритеты

1. Есть доступ к аккаунту по этому контакту
2. Этот контакт подтвержден
3. Есть доступ к аккаунту по любому контакту или дисконтной карте (если на проекте включена функция доступа по карте)
4. Наличие заказов, промо-кодов, баллов
5. Есть любые подтвержденные контакты
6. Аккаунт с последним по дате личным действием и/или регистрацией

Критерии расположены в порядке уменьшения значимости. Если по одному из критериев у клиентов паритет, то они сравниваются по следующим критериям.

Примеры, не можем объединить и нужно выбрать у кого забрать контакт.

Пример 1. Приоритет контакта с доступом к аккаунту.

В базе проекта есть Клиент1 с телефоном дающим доступ к аккаунту и email.

В импорте новых клиентов приходит информация о Клиенте2. У него такой же телефон, но другой email-адрес. Из-за противоречий в email объединение невозможно. Нужно выбрать кому оставит телефон. Так как у Клиента1 телефон дает доступ к аккаунту, то он более приоритетный.

В итоге телефон останется у Клиента1. У Клиента2 он будет удален.

Пример 2. Нельзя выбрать на основе наличия заказов. Решаем на основе даты последнего личного действия.

Нужно выбрать кому из клиентов оставить номер телефона, т.к. email-адреса отличаются.

Контакты без доступа к аккаунту, подтверждение не требуется. Дисконтных карт нет.

В этом случае самым важным будет наличие заказа. Но заказы есть у обоих клиентов. Смотрим следующий критерий: дата последнего личного действия. Это может быть переход на сайт, открытие письма, оформление заказа.

Номер телефона останется у того клиента, кто совершил последнее по дате личное действие (в данном случае оформил заказ).

Пример 3 . Цепочка. Приоритет по наличию заказа и подтвержденному контакту .
В настройках точки интеграции включено подтверждение контактов.

Клиент1 зарегистрировался на сайте. Указал телефон1 и email1 и не подтверждал их. Далее смотрел товары на сайте, оформил заказ. В итоге у него есть личные действия и заказ.

Клиент2 зарегистрировался с телефоном2 и email1.

Email-адреса должны быть уникальны. Нужно принять решение кому из клиентов оставить email1. Клиент1 более приоритетный, т.к. он оформил заказ.

Email-адрес остается у Клиента1, а у Клиента2 затирается.

Так как в настройках включено подтверждение контактов, то у Клиента1 остается возможность подтвердить email-адрес. В итоге у Клиента2 удален основной email-адрес, но есть email ожидающий подтверждения.

Клиент2 открывает письмо отправленное для подтверждения email и переходит по ссылке “Подтвердить адрес”.

После этого email1 у Клиента2 переходит из статуса “ожидает подтверждение” в статус “Подтвержден” и становится основным контактом.

Снова складывается ситуация, когда один и тот же email-адрес принадлежат двум клиентам. Нужно выбрать у кого из них оставить email1.

Ситуация изменилась. У Клиента1 email по прежнему ожидает подтверждения и есть заказ. У Клиента2 email1 подтвержден и мы уверены, что это его адрес.

Принято решение оставить email у Клиента2, т.к. у подтвержденного контакта более высокий приоритет. У Клиента1 email-адрес удаляется.

При этом Клиент1 сохраняет возможность подтвердить свой email. Например, запросив повторную отправку письма с подтверждением. Если он подтвердит тот же адрес, то Клиент1 и Клиент2 объединятся.

Подсказка. Если важно передавать информацию о таких объединениях во внешнюю систему, то можно использовать v3-операцию с шагом “Выгрузить объединения клиентов”.

Приоритеты при выборе сегментации после объединенияПриоритеты при выборе сегментации после объединения

При объединении мы берем историю изменения сегментаций у одного из клиентов.

1. Для каждой сегментации смотрим на даты попадания в сегмент
2. Оставляем ту у которой было последнее обновление
3. Если в рамках сегментации есть противоречия в сегментах, то оставляем сегмент у которого было последнее обновление

Пример

История сегментаций Клиента1 и Клиента2 до объединения

После объединения получим клиента с такой историей сегментаций:

*если в рамках сегментации не можем определить сегмент по дате, то смотрим на более поздний id сегмента