Совместные программы лояльности крупных компаний — это настоящее и будущее маркетинга. Но чтобы запустить интересную и релевантную интеграцию, которая зайдет общей аудитории и принесет деньги обеим компаниям, нужно для начала найти эту самую общую аудиторию. Эту задачу и решает мэтчинг данных.
Задача непростая, ведь российские законы запрещают раскрывать персональные данные третьим лицам. А для некоторых компаний обогащение данных осложнено дополнительными ограничениями. Но выход есть.
Platforma и HFLabs впервые протестировали процесс безопасного мэтчинга данных между двумя компаниями. Рассказываем, как это было и что получилось в итоге.
Мэтчинг данных: простыми словами
Мэтчинг — это процесс сопоставления данных. Для человеческого мозга это обычная и привычная задача. Сравнить две фотографии и понять, что на них изображен один и тот же человек — дело пары секунд.
В бизнесе же процесс сопоставления и сравнения данных — задача куда более сложная.
Чтобы было понятнее, давайте поясним на примере гипотетической компании, в которой есть несколько направлений: банк, онлайн-магазин, доставка еды и каршеринг.
Все направления ведут клиентов независимо. То есть, чтобы воспользоваться каршерингом, человеку нужно создать отдельный аккаунт — банковский ID не подойдет. В результате получается, что у одного клиента будет четыре записи в разных базах одной компании.
Чтобы работать с клиентами более рационально, руководство компании решает свести базы в одну. Главная задача: чтобы система распознала все эти четыре записи как одного человека.
Это сложно уже в пределах одной компании. Ведь мэтчинг — это не просто сведение баз и удаление дублированных записей. Здесь есть куча нюансов, которые влияют на результат.
В разных аккаунтах клиент может указать разные номера телефонов или email-ы. Или контакты могут иметь одинаковую суть, но отличаться способом записи. К примеру, адреса vasiliy@ya.ru и vasiliy@yandex.kz — это одна и та же почта, хоть похожесть строк и невысока. То же с номерами телефонов: одна база данных может предполагать хранение телефона с кодом страны +7 999, а другая без него — 999. Эти телефоны не совпадут друг с другом при сравнении в лоб.
При этом возможна и обратная ситуация: в реальном мире номер телефона иногда переходит от одного владельца к другому. Вы могли встретиться с такой ситуацией во время переводов денег через СБП: в одном банке отображается одно ФИО, а в другом – другое. Поэтому считать телефон уникальным идентификатором человека не стоит.
Человеческий фактор также вносит большую погрешность в процесс. Один оператор может записать только имя клиента, а второй добавит еще и отчество. И все, в системе появилось два разных клиента. Об обычных описках даже не вспоминаем — они случаются часто и тоже усложняют процесс мэтчинга.
Но самое сложное начинается, когда мэтчинг данных нужно провести двум разным компаниям. К примеру, чтобы запустить рекламную компанию или программу лояльности для общих клиентов, проанализировать профиль покупателя или его историю. Ведь в силу вступает закон «О защите персональных данных», который прямо запрещает передавать третьим лицам информацию об именах, номерах телефонов, адресах, email-ах — то есть, любые клиентские базы.
Организовать это как открытую экосистему нельзя. Но компании Platforma и HFLabs нашли способ, как эффективно провести сопоставление баз данных, не нарушая законодательство.
Опыт мэтчинга от Platforma и HFLabs
Прямой обмен данными невозможен, но 152-ФЗ позволяет использовать анонимизированные данные для статистических и аналитических задач. Поэтому специалисты Platforma и HFLabs разработали процесс мэтчинга на основе двухэтапного хеширования с использованием сессионного «секрета», доступного только владельцам данных.
Клиентские данные преобразовываются в синтетические идентификаторы — UUID, которые уже не являются персональными данными и состоят из случайного набора букв и цифр фиксированной длины. Хешированные данные передаются в федеративный хаб, где и проводится сравнение хешей и поиск пересечений.
Здесь можно провести аналогию с алгоритмами совместных конфиденциальных вычислений, где модели аналитики строятся на зашифрованных «секретах», а не на реальных данных. И только после сравнения весов двух моделей можно получить истинную.
Для сопоставления баз данных эксперты Platforma и HFLabs создали особую архитектуру.
Каждый участник прогоняет уже синонимированные БД через CDI с модулем хеширования. Затем они попадают в федеративный хаб, в котором и ведется сравнение данных. При их совпадении система дает знать о пересечении клиентов.
Получается следующая схема:
В результате после сравнения хешей каждый из участников получает идентификаторы собственных клиентов, которые есть у прочих партнеров, не раскрывая собственную клиентскую базу.
Главная проблема метода и ее решение
Процесс мэтчинга с помощью хеширования может показаться довольно простым, но на деле есть целый ряд сложностей.
Сравнить и найти одинаковые строки несложно. Допустим, в обеих базах есть «Наталия Кузнецова». Мы поймем, что это один и тот же человек, т.к. ФИО совпадает. Если в хабе данные хешированы одинаковым способом, то и хеши этих ФИО будут идентичны, а значит и по ним мы сможем определить совпадение записей.
Здесь мы привели упрощенный пример. Для построения сильной связи нужно использовать как минимум три критерия: ФИО + дата рождения + адрес регистрации или номер паспорта.
Одного ФИО для идентификации человека в масштабах России недостаточно. Полные тезки находятся у людей с не самыми распространенными ФИО, и даже дата рождения не всегда позволяет выправить ситуацию — многие знакомы с ошибками приставов, из-за которых на человека вешают долги его тезки с аналогичной ДР из другого региона и вынуждают разбираться с этим прямо в аэропорту. Это пример того, как идентифицировать людей ни в коем случае нельзя.
Вернемся к упрощенной схеме и рассмотрим ситуацию, когда в одной базе клиент записан как «Наталья Кузнецова», а во второй как «Наталия Кузнецова». Формально строки разные, совпадения нет.
Определять схожесть оригинальных данных несложно — есть масса алгоритмов, позволяющих определить похожесть строк: это и n-граммы, и расстояние Левенштейна, и сходство Джаро-Винклера. Хотя и тут есть сложности – похожесть между Сашей и Александром по мнению этих алгоритмов будет низкой, а вот Миша и Маша будут очень похожи.
У строк «Наталья Кузнецова» и «Наталия Кузнецова» разница только в одной букве — 16 из 17 знаков совпадают (пробел тоже считаем). То есть, строки идентичны на 94% и с высокой вероятностью они ссылаются на одного и того же человека. Такой способ проверки хорошо подходит и для обработки данных, в которых есть случайные описки. Чем больше данных, тем сильнее упрощается идентификация.
С хешированными данными иначе. Разница в одну букву исходника делает хеши от слов «Наталья» и «Наталия» абсолютно разными. Их сравнение ничего не даст. Можете проверить сами:
sha512 от «Наталья»
a771625ed02ba6a1ba14d100e7de9af21cac5008930184ccc73f4ed68c3f2a6fb8286ed7ce31a46fd75e00846c346ccf5cd0afe4874af3c080fcc2b75a422aeb
sha512 от «Наталия»
5b997c9e30041489ad1a5b0f65996b40a53c15b864ea920e4fe14b17fee19e5cc4a00f93eb601e2b30f59ff6ab20551b4d21cfb4962c85105b5eac5dc7e46e53
Чтобы избежать подобных ситуаций, специалисты разработали систему синонимов.
Для одной строки мы генерируем ряд связанных значений. К примеру, «Наталья», «Наталия», «Наташа». То же и с другими блоками: номера телефонов с кодом страны и без, электронные почты @yandex.ru и @ya.ru. Везде, где есть несколько равнозначных вариантов. Платформа по другую сторону делает то же самое.
Под каждый синоним формируется отдельный хеш, а уже в контуре платформы мы попарно сравниваем полученные хеши. Алгоритмы формирования синонимов по обе стороны одинаковые, поэтому перекрестное сравнение их хешей позволяет почти со стопроцентной точностью утверждать, что «Наталья Кузнецова» и «Наталия Кузнецова» в двух базах — это один человек.
Наиболее сложное и длительное в этом процессе — создать ряд синонимов для записей в базах, которые учитывают все возможные варианты их записи. Иногда это занимает месяцы реального времени и работу целого отдела специалистов. Сам алгоритм нормализации ФИО и исправления в нем опечаток мы оставляем за рамками этой статьи.
Кластеризация для скорости мэтчинга
В небольших базах данных можно сравнивать все позиции со всеми. Квадратичная сложность алгоритма даже при 10 000 позиций не критична — 100 млн операций сравнения строк мощный компьютер проведет за минуту.
А вот обработка базы в 20 млн записей в таком случае будет долгой — придется выполнить почти 200 трлн сравнений. Считаем это число, используя формулу для определения количества ребер полного графа: n(n-1)/2.
Такая операция может занять месяцы реального времени. И это еще не самая большая база, с которой приходится работать — есть российские компании, которые оперируют клиентскими базами, содержащими почти все население страны. А с алгоритмом синонимов она вырастет еще в несколько раз.
Тратить месяцы на одну обработку БД — не вариант. Поэтому для больших баз запускается двухфазный процесс работы с данными.
Первая фаза – кластеризация. Все данные разделяются на множество небольших групп по одному или нескольким общим признакам. Они могут быть любыми: серия паспорта, первая буква фамилии, дата рождения. И только на следующей фазе хеши в этих группах сравниваются между собой.
Давайте посчитаем эффективность такого способа на примере базы в 20 млн записей. Алгоритм сравнения всех со всеми обладает квадратичной сложностью — придется выполнить 200 трлн операций сравнения.
Теперь разделим всю базу на группы по серии паспорта. Предположим, что у нас получилось 2000 групп по 10 000 записей в каждой. Алгоритм сравнивает только записи в одной группе. Из каждой мы получаем 50 млн операций, а со всей базы целиком выходит 100 млрд. Это в 2000 раз быстрее, чем в полном графе.
Даже если запустить целый ряд анализов кластеров, созданных по разным атрибутам, это все равно будет на несколько порядков быстрее, чем обработка БД целиком — всего 10-20 минут.
Результатом такой сверки становится таблица, в которой хранится соответствие идентификаторов записей различных партнеров. Та самая база общих клиентов, для поиска которой и запускался процесс. И именно от этой таблицы строится вся экосистема совместных данных двух компаний, которую можно использовать для точечной коммуникации с клиентами. На ее основе аналитики могут разрабатывать совместные маркетинговые предложения общим клиентам, строить более точные модели прогнозирования потребностей покупателей или улучшения конверсии.
В итоге процесс безопасного мэтчинга данных дает только плюсы для всех участников. Отсутствует даже минимальный риск раскрытия персональных данных клиентов. Аналитики работают только с информацией, которая совпадает в обеих базах. Это дает массу возможностей для сотрудничества между компаниями и более качественной аналитике аудиторий, но при этом сразу закрывает вопрос с передачей персональных данных и возможными утечками.
А для потребителей мэтчинг данных означает, что компании смогут предлагать им совместные продукты и программы лояльности, лучше анализировать покупательский опыт и разрабатывать персонализированные предложения.
И чем больше компаний в перспективе будет участвовать в общей системе, тем сильнее будет позитивное влияние на отдельного покупателя и рынок в целом.
