<\/p>\n<\/p>\n
В системах сквозной аналитики ключевую роль играет правильная модель атрибуции. Без нее данные невозможно интерпретировать, и их ценность для бизнеса невелика. При этом важно понимать, что любая модель напрямую зависит от качества данных.<\/p>\n
Частая проблема с сырыми данными в том, что информация об одном клиенте дублируется или, напротив, противоречит друг другу в разных источниках.<\/p>\n
Кроме того, что предобработка данных — база для аналитика, без правильного объединения персональных данных в принципе сложно отследить клиентский путь. Значит, нужно настраивать процессы объединения неоднородных персональных данных.<\/p>\n
Сегодня в любом клиентском бизнесе воронки регистрации устроены таким образом, что клиенты попадают в базу множеством способов — часто через маркетинговые каналы, которых всегда много (рассылки, реклама, соцсети). В каждом таком канале может быть ссылка на форму подписки, регистрацию на платформе или чат, и один клиент часто проходит все эти этапы. Сразу же образуется путаница в идентификации, которая сильно влияет на качество данных и результаты аналитики, если ее не лечить.<\/p>\n
Мы столкнулись с этой проблемой, работая с одним из наших клиентов, и решили ее, создав сквозной идентификатор. Это уникальный номер, который присваивается реальному клиенту и дублируется во все источники, где есть данные об этом клиенте, тем самым избавляя от путаницы.<\/p>\n
Мы разрабатывали кастомную систему сквозной аналитики для эдтех-стартапа Refocus. Данные каждого студента в системы Refocus попадали из нескольких источников и были записаны несколько раз — как минимум при регистрации на курс, при первом входе на образовательную платформу и при входе в чат сопровождения.<\/p>\n
В нашем случае мэтчинг был важнее всего по трем источникам из тринадцати:<\/p>\n
Остальные источники, с которыми мы работали, либо не содержали данных студентов (например, цифры эффективности работы sales-менеджеров были завязаны на данных сотрудников и трекались через другие системы), либо дублировали информацию из указанных трех.<\/p>\n
В Discord и Thinkific данные попадали напрямую, от студентов при регистрации в системах, а затем подтягивались в amoCRM. Основные причины несовпадения клиентских данных как у Refocus, так и в похожих случаях — человеческий фактор (опечатки), наличие у людей более чем одного телефона или адреса почты и ограничения самих платформ, с которых приходят данные: разный заданный формат полей и их количество.<\/p>\n
Часть этих факторов может решаться корректировкой самой клиентской воронки. Правда, не все платформы позволяют одинаково настроить вводные поля, а просьбы вводить данные в конкретном формате не всегда работают и не страхуют от ошибок. Плюс, задача аналитиков — получить чистые данные в любом случае.<\/p>\n
Данные в Refocus мы подгружали в хранилище в BigQuery напрямую из интересующих нас источников (рекламных кабинетов, LMS и т. д.), используя Python. В дальнейшем на этих данных строились дашборды в Tableau.<\/p>\n
Обнаружить проблему несложно — при создании хранилища и дальнейшей выгрузке данных из него мы в любом случае чистим датасет от дубликатов и несовпадений.<\/p>\n
Поля, в которых возникали ошибки и для которых нам важен был мэтчинг, чтобы правильно отследить клиентский путь:<\/p>\n
Поначалу, пока количество студентов Refocus было относительно небольшим, достаточно было скриптов, которые объединяли данные по одному из этих полей. В полученных таблицах в Tableau проводился поиск строк с пустым значением в соответствующем поле — и вот видно всех студентов, чьи данные не сошлись.<\/p>\n
Количество таких строк было в пределах пары десятков, и трекать и объединять их было несложно вручную. Это делалось прямо в первоисточниках сотрудниками Refocus, которые могли поправить опечатки и ошибки у себя в системах. После этого наш код выгрузки в хранилище перезапускался и тянул уже чистые данные. Если после этого что-то не сходилось, то наши аналитики правили информацию на уровне базы данных.<\/p>\n
Но при росте компании в какой-то момент число студентов, потерянных при мэтчинге, могло достигать сотни за месяц. Пока ошибка обнаружится, данные поправят в источниках, а мы перезапустим код выгрузки, могло пройти несколько часов — а это критичный интервал. Да и перезапускать выгрузку каждый день ради нескольких несовпадений — неэффективно. Стало понятно, что масштаб проблемы требует более точного и универсального решения.<\/p>\n
Вообще, в такой ситуации возможны несколько вариантов. Можно бесконечно править скрипты мэтчинга, учитывая новые и новые случаи и создавая костыли. А можно, например, настроить алерты в оркестраторе процессов (в нашем случае — Airflow), которые позволят моментально узнавать о появившемся несовпадении и объединять “потерянные” клиентские сущности по паре за раз. Но это все еще неполная автоматизация, и она только ускоряет, а не упрощает процесс.<\/p>\n
Руководствуясь соображениями эффективности, мы предложили ввести сквозной идентификатор — одно значение ID, присваиваемое одному клиенту после автоматической интеграции его данных из разных источников.<\/p>\n
Чтобы понять масштаб проблемы, мы начали с того, что создали таблицы несовпадающих персональных данных. Для этого мы использовали скрипты на Python. Эти скрипты объединяли данные из разных источников и создавали из них большую сводную таблицу. Для того, чтобы свести данные о студенте в одну сущность, использовался мэтчинг по адресу электронной почты. Мы попробовали мэтчить по имени, фамилии, телефону (который сначала надо было привести к одному формату!) и почте, и именно последний вариант показал самую высокую точность. Возможно, дело в том, что из всех данных почта имеет самый однородный формат, поэтому остается учитывать только опечатки.<\/p>\n
Например, нам нужно было мэтчить данные для создания дашборда по возвратам, о которых информация объединялась как раз из наших трех основных источников. В ранней версии скрипта данные отбирались таким образом:<\/p>\n
WITH snapshot_ AS (\r\n SELECT DISTINCT s.*,\r\n IFNULL(ae.name, ap.name) as contact_name,\r\n ap.phone, ae.email,\r\n split(replace(trim(lower(ae.email)),' ',''),'@')[OFFSET(0)] as email_first_part,\r\n ai.thinkific_id, ai.intercom_id, ac.student_id\r\n FROM (\r\n SELECT *,\r\n ROW_NUMBER() OVER(PARTITION BY lead_id ORDER BY updated_at DESC) as num_,\r\n FROM `Differture.amocrm_leads_snapshot`\r\n ) s\r\n LEFT JOIN (\r\n SELECT DISTINCT lead_id, contact_id, name, email,\r\n ROW_NUMBER() OVER(PARTITION BY lead_id ORDER BY contact_id) as num1_\r\n FROM `Differture.amo_emails`\r\n ) ae using(lead_id)\r\n LEFT JOIN (\r\n SELECT DISTINCT lead_id, contact_id, name, phone,\r\n ROW_NUMBER() OVER(PARTITION BY lead_id ORDER BY contact_id) as num2_\r\n FROM `Differture.amo_phones`\r\n ) ap using(lead_id)\r\n LEFT JOIN `Differture.amo_contact_thinkific_intercom_match` ai using(lead_id)\r\n LEFT JOIN `Differture.AmoContacts` ac on cast(ae.contact_id as string)=ac.amo_id\r\n WHERE (num_=1 or num_ is null) and (num1_=1 or num1_ is null) and (num2_=1 or num2_ is null)\r\n and s.pipeline_id in (4920421,5245535) and s.status_id=142 and lower(s.lead_name) not like '%test%'\r\n )<\/code><\/pre>Как можно заметить, идея сквозного идентификатора здесь уже присутствует — фигурирует student_id<\/tt>. На самом деле, в этой версии скрипта это графа из AmoContacts — таблицы, в которой хранятся только данные из amoCRM. Никаких джойнов по student_id<\/tt> пока не происходит. А происходят по email_first_part<\/tt>, адресу почты до символа @:<\/p>\nselect distinct * from th_amo_ds_rf\r\n left join calendly ce using(email_first_part)\r\n left join typeform_live tfl on email_first_part=tf_email_first_part\r\n left join typeform tf using(email_first_part)\r\n left join csat using(email_first_part)<\/code><\/pre>Первым шагом по практическому введению идентификатора была таблица students_main_info<\/b>, созданная в BigQuery in-house специалистом Refocus. К сожалению, у нас нет доступа к коду, который использовался для присвоения идентификатора. Зато мы можем показать вид этой таблицы:<\/p>\n\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/--2021-03-26--11.14.34.png\")
\n<\/div>\n",
"date_published": "2021-03-30T13:51:48+03:00",
"date_modified": "2021-03-26T15:11:01+03:00",
"image": "http:\/\/test.leftjoin.ru\/pictures\/--2021-03-26--11.14.34.png",
"_date_published_rfc2822": "Tue, 30 Mar 2021 13:51:48 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "105",
"_e2_data": {
"is_favourite": false,
"links_required": [
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css"
],
"og_images": [
"http:\/\/test.leftjoin.ru\/pictures\/--2021-03-26--11.14.34.png"
]
}
},
{
"id": "101",
"url": "http:\/\/test.leftjoin.ru\/all\/coinkeeper-data-bot\/",
"title": "Бот для преобразования данных из Coinkeeper",
"content_html": "![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/@2x-copy.png.jpg\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/1-27.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/2-26.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/3-22.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/4-13.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/5-14.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/6-14.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/7-8.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/8-9.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/9-8.png\")
\n<\/div>\n",
"date_published": "2021-03-09T17:28:36+03:00",
"date_modified": "2021-03-09T17:13:54+03:00",
"image": "http:\/\/test.leftjoin.ru\/pictures\/0@2x.jpeg",
"_date_published_rfc2822": "Tue, 09 Mar 2021 17:28:36 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "101",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"http:\/\/test.leftjoin.ru\/pictures\/0@2x.jpeg",
"http:\/\/test.leftjoin.ru\/pictures\/@2x.png-1.jpg",
"http:\/\/test.leftjoin.ru\/pictures\/@2x-copy.png.jpg",
"http:\/\/test.leftjoin.ru\/pictures\/1-27.png",
"http:\/\/test.leftjoin.ru\/pictures\/2-26.png",
"http:\/\/test.leftjoin.ru\/pictures\/3-22.png",
"http:\/\/test.leftjoin.ru\/pictures\/4-13.png",
"http:\/\/test.leftjoin.ru\/pictures\/5-14.png",
"http:\/\/test.leftjoin.ru\/pictures\/6-14.png",
"http:\/\/test.leftjoin.ru\/pictures\/7-8.png",
"http:\/\/test.leftjoin.ru\/pictures\/8-9.png",
"http:\/\/test.leftjoin.ru\/pictures\/9-8.png"
]
}
},
{
"id": "100",
"url": "http:\/\/test.leftjoin.ru\/all\/borderline-text-analysis\/",
"title": "Python и тексты нового альбома Земфиры: анализируем суть песен",
"content_html": "![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/Zemfira_borderline-2.jpg\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/1-26.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/2@2x-2.png.jpg\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/3-21.png\")
\n<\/div>\n