Приоритеты клиентов при объединении и затирании email/телефона/id при противоречиях
  • 09 Feb 2022
  • 3 минуты
  • Темная тема
    Светлая тема
  • формат pdf

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

  • Темная тема
    Светлая тема
  • формат pdf

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

  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 до объединения

Сегментации клиента1 Дата попадания Сегментации клиента2 Дата попадания
Подписан на рассылки 02.2019 Подписан на рассылки 01.2021
Покупает хлеб 01.2020 Покупает хлеб 03.2020
Уровень лояльности1 01.2021 Уровень лояльности2 08.2020
Не открывает письма 02.2021

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

Сегментации клиента Дата попадания
Подписан на рассылки 01.2021
Покупает хлеб 03.2020
Уровень лояльности1 01.2021
Не открывает письма 02.2021

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