Как избежать ошибок в хранении персональных данных

Слишком много систем для хранения персональных данных, нет «единой версии правды»

Частая картина: клиентские данные хранятся в самых разных системах. Например, в B2C и B2B CRM. Но такие приложения не предназначены для хранения большого объема клиентских данных и имеют ограниченную функциональность для работы с ними. В итоге бизнес не понимает, сколько у него в реальности клиентов, и не видит полный продуктовый профиль каждого из них. 

Для работы с большим объемом клиентских данных лучше всего подходят системы класса CDI (Customer Data Integration, или клиентский MDM). Такая система выявляет дублирующиеся записи по сложным алгоритмам: правил слияния дубликатов может быть больше сотни. CDI улучшает качество данных, приводит в порядок адреса, формирует эталонную запись клиента. По сути, она выступает той самой «единой версией правды» в отношении клиентских данных, к которой обращаются за информацией все другие системы. Они, кстати, тоже в выигрыше: увеличивается их производительность, так как не нужно проводить нетипичную для них обработку данных.

После внедрения CDI один из банков разделил клиентскую базу на клиентов и лидов (проспектов — тех, кто оставил заявку, но договор в итоге не подписал). После этого вся база уменьшилась на 60%. Казалось бы, что в этом хорошего? На самом же деле банк узнал реальное количество клиентов и очистил базу от мусорных данных и неверифицированных данных из заявок. Теперь отдел маркетинга сможет точнее оценивать конверсию и видеть, какая заявка в итоге стала клиентом, а какая нет. 

Появляются многочисленные копии данных

Хранение данных клиентов в CDI позволяет развести по разным системам персональную информацию и транзакции. По этой причине, кстати, службы информационной безопасности все чаще выступают за появление в корпоративной архитектуре именно CDI, так как становится понятно, где именно лежат данные и как их защищать от атак и утечек. 

И еще один аспект. Когда мы говорим о том, что клиентские данные хранятся в разных системах, речь идет в том числе и о тестовых контурах. В крупных компаниях могут быть десятки копий клиентских данных, которые используются для тестирования высоконагруженных систем или для моделей машинного обучения. Доступ к тестам, как правило, имеют еще и подрядчики, и это серьезно повышает риск утечек. 

Плохое качество клиентских данных

Плохое качество клиентских данных — это тот самый мусор, неактуальные сведения, нестандартизированные адреса и номера телефонов, клиентские записи-дубли. 

Если в данных нет порядка, операторы тратят время и звонят по неактуальным номерам или беспокоят клиента, действие договора с которым уже закончилось. Иногда и вовсе случаются казусы — например, СМС приходит в то время, когда у клиента во Владивостоке ночь, то есть компания не учитывает его актуальный часовой пояс. Или еще хуже: в почтовой рассылке человека называют другим именем или обращаются к нему «Дорогой Светлана!». Интернет уже даже полон мемов — вот, например, один из самых знаменитых: 

А вот другая история. Как-то при работе с оператором связи CDI буквально за пять минут нашел больше 2000 договоров, оформленных на одного клиента. А с точки зрения учетной системы это были 2000 абонентов. На практике это означает, что за действиями человека могут стоять мошеннические схемы (например, продажа сим-карт у метро без документов), и рано или поздно регулятор может обратить на это внимание. С другой стороны, если таких клиентов много, явно нарушается сегментация. Когда человек регулярно пользуется услугами оператора для своего бизнеса, ему можно предложить другие продукты или тарифы. 

Еще один пример плохого качества данных — это звонок из банка, когда вам предлагают кредитную карту на 50 тысяч рублей, совершенно игнорируя тот факт, что у вас уже есть кредитная карта на 500 тысяч. Это вызывает раздражение клиента («Вы что, не видите, что у меня уже есть!») и означает, что банк попусту тратит маркетинговый бюджет. Знаю случаи, когда банк отказывает людям, например, в получении кредита не потому, что они по скорингу не проходят, а потому, что клиентские данные плохого качества. Например, клиент пришел с новым телефоном, а этот номер пять лет назад принадлежал человеку с плохой кредитной историей. Банк не может провести идентификацию и либо отказывает человеку, либо заставляет его прийти в офис. И то и другое не лучшим образом сказывается на отношениях человека с финансовой организацией.

Слишком много данных, в том числе исторических 

Долгое время бизнес стремился агрегировать всю доступную информацию о клиентах. Нередко эти данные вовсе не требовались для оказания услуг — кому из нас не приходилось заполнять анкеты на получение карт лояльности с многочисленными полями? Сейчас этот тренд постепенно угасает. Но многие компании успели накопить столько данных, что теперь им нужно разобраться, какие из них ценные, а какие — чемодан без ручки. Например, в профиле клиента есть 10 телефонов, и перед компанией встает вопрос: а по какому номеру с ним в итоге контактировать? Тут, кстати, тоже выручит клиентский MDM, так как скоринговая модель, заложенная в нем, позволяет с большой долей вероятности выявить актуальный контакт.

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

Под историческими я понимаю персональные данные тех людей, которые не пользуются услугами компании на протяжении последних 9–10 лет. Почему их хранение рискованно? Если произойдет утечка, никто не будет разбираться, актуальные это данные или нет. Компания получит репутационный ущерб. Использовать эти данные для машинного обучения тоже нецелесообразно, так как за последние годы потребительское поведение и стиль жизни многих людей изменились. Наконец, сроки согласий на обработку таких персональных данных могут быть истекшими. В случае проверки Роскомнадзора это обернется штрафом. 

Хранение исторических данных приводит и к более медленной обработке задач, и к переполнению хранилищ, и к путанице в процессах. Знаю банк, который исторически рос путем поглощения более мелких финансовых организаций. У каждой из них были свои клиентские базы. После того как данные были объединены в одном приложении, в контуре организации все равно остались системы-источники. Постепенно они отмирали, переставали функционировать, но данные из них, часто устаревшие, продолжали жить. Банку пришлось проделать большую работу, чтобы избавиться от этого наследия.

Нет управления согласиями

Пока я вижу лишь единичные примеры, когда компаниям удалось выстроить полноценный Consent Management. Дело в том, что согласия на обработку персональных данных и рекламные коммуникации собирают все компании, но далеко не каждая может обеспечить трассирование полученных «галочек» (согласен или не согласен) в IT-системы. В результате при выгрузке данных — например, для маркетинговой кампании — желание клиента получать или не получать рекламную информацию не учитывается вовсе либо учитывается не в полной мере. За это можно получить штрафы от регуляторов — как от Роскомнадзора, так и от Федеральной антимонопольной службы. 

Но дело не только в штрафах. Как говорилось в известной рекламе, лояльность клиента бесценна. Рынок банков и телеком-операторов давно поделен, поэтому фокус переключается на удержание клиента и работу с его лояльностью. И к согласиям стоит относиться не как регуляторной нагрузке, а как к инструменту заботы о клиенте. Кстати, пару лет назад я сам поменял оператора сотовой связи только из-за того, что он не справился с отключением назойливой рекламы своих услуг. 

Между тем именно Consent Management позволяет перейти от общего отзыва согласия на обработку персональных данных и рекламу к гранулярному, когда в информационной системе зафиксировано, дал клиент согласие на звонок, СМС или письма. Именно такой сценарий реализовала одна из страховых компаний. Управление согласиями позволяет ей на лету формировать так называемое бизнес-согласие как сумму всех входящих в него атомарных согласий и отзывов. Так маркетинг нивелирует риск штрафов и выстраивает продвижение с учетом пожеланий клиентов. 

Рекомендации

• Собирайте только те клиентские данные, которые действительно нужны бизнесу или требуются для регуляторной отчетности. Максимально упрощайте формы на сайте и не добавляйте в них большое количество обязательных полей. Если человек не желает делиться своими данными, он оставит «мусор» — например, 111111 вместо индекса. Позже эти данные вы не сможете никак использовать, но их хранение будет съедать бюджет. 
• Установите для сотрудников четкие правила работы с персональными данными. Например, у нас в компании не разрешается пересылать такие данные по почте или выкладывать в облако. Нельзя хранить их на собственной машине, оставлять ее незалоченной и давать свой пароль даже коллегам. Также мы рекомендуем никому не рассказывать о том, куда и к каким данным есть доступ. Коллеги в курсе, что для работы нельзя пользоваться открытыми Wi-Fi-сетями и бесплатными VPN.
• Управляйте персональными данными с помощью систем, которые разработаны специально для этого. CDI стандартизирует данные, дедублицирует клиентские записи по сложным правилам, формирует эталонные карточки с данными клиентов и затем распространяет эти данные в другие системы. CDI-система может быть встроена в любую архитектуру. При внедрении создается модель данных, которая отвечает бизнес-процессам в организации. 
• Используйте логирование доступа к персональным данным клиентов. CDI-системы тоже имеют такую опцию. Это позволит вовремя отследить аномалии и снизить риски по «сливу» данных. Например, логирование позволяет проследить, что кто-то из сотрудников открывает слишком большое количество клиентских карточек. 
• Обеспечьте маскирование персональных данных. За последний год интерес к маскированию существенно вырос. Причина — частые утечки. Маскирование данных необходимо, например, для их безопасной передачи в тестовый контур или для обучения ML-моделей. Чтобы тестирование было корректным, адреса должны сохранять привязку к региону, а номера телефонов — код мобильного оператора. Такой подход называют «умным маскированием». Имена и фамилии можно маскировать с учетом пола и популярности ФИО, а также с сохранением существующих родственных связей. 
• Не забывайте про деперсонализацию данных. Я уже упоминал об исторических данных — их следует своевременно удалять. В случаях, когда истек срок согласия на обработку персональных данных, данные можно хешировать без возможности восстановления, но зато с сохранением связей с договорами и идентификаторами исходных систем. Это позволит продолжить анализировать данные, но исключит риск утечек.