#кейсы #ML
обещанный кейс про «не пущать»
Скорее рано чем поздно перед DS встает задача матчинга персон между источниками — например, в одной табличке указано ФИО + дата рождения + электронная почта + место рождения, в другой — мобильный телефон, имя и фамилия.
Состав полей может быть разный, но суть вы уловили — нет единого ID и надо бы его создать.
Такая задача — иметь сквозной ID клиента и связать его со внутренними ID разных бизнес-систем компании, называется MDM Master Data Management (а в банкетной рекламе DMP — data management platform).
Конечно же, такая информация — это персональные данные, они особо бдительно охраняются, поэтому на рынке есть специальные компании, которые занимаются такими задачами.
Но хороший Data Scientists это Data Investigator и Explorator, поэтому интереснее сделать самому и как можно точнее.
И вот в одной компании про это прознали кибербезопасники и строго запретили DSам самим матчить — но тк задача никуда не делась, решили сделать сами, чтобы по всем правилам, пром процессом и тд, и вот что из этого вышло.
Подход 1
Возьмем хэш от всех полей с одинаковым смыслом и будем маячить таблички по таким хэшам.
Догадались что произошло?
90% хэшей оказались нуллами (пусто) — поскольку строки, по которым шло хэширование, содержали хотя бы одно пустое поле. Толку от такого "матчинга", понятное дело, немного
После такого шикарного выступления бывшие сотрудники всевозможных органов не сдались, а решили перейти к плану Б
итак, Подход 2
После тотального провала в первом подходе экс заплечных дел мастера решили найти "самые главные поля" и пояснить матчить по ФИО + дате рождения.
Выяснилось что только в Москве несколько тысяч полных тезок по ФИО + ДР
Эволюционно гении пришли к Подходу 3: давайте матчить по ДУЛ (документу, удостоверяющему личность) + ФИО + ДР, ну чтоб уже наверняка
И вот что из этого вышло
PS
Потом я не раз видел как из аналитических песочниц пытались убрать любые перс данные и вспомогательные ID, оставив только единственно правильный. Заканчивался этот идиотизм как правило когда по заданию биг боссов срочно нужно было добавить в процесс какую-н выгрузку из внешней системы / полученную с рынка -- и естественно, внешний мир про прекрасный внутренний ID ничего не знал что, очевидно, делало невозможным любой матчинг -- то есть добытые извне данные никак не добавить к внутренним. Осознанием руководством такого тривиального факта приводило к развивающей обратной связи адептам "не пущать" на радость и благость, как говорит один мой товарищ, не дающий писать мне совсем дичь )
Мораль проста: не мешайте DSам делать свою работу, авось без премии не останетесь😄
обещанный кейс про «не пущать»
Беда, коль пироги начнет печи сапожник, А сапоги тачать пирожник, И дело не пойдет на лад
Скорее рано чем поздно перед DS встает задача матчинга персон между источниками — например, в одной табличке указано ФИО + дата рождения + электронная почта + место рождения, в другой — мобильный телефон, имя и фамилия.
Состав полей может быть разный, но суть вы уловили — нет единого ID и надо бы его создать.
Такая задача — иметь сквозной ID клиента и связать его со внутренними ID разных бизнес-систем компании, называется MDM Master Data Management (а в банкетной рекламе DMP — data management platform).
Конечно же, такая информация — это персональные данные, они особо бдительно охраняются, поэтому на рынке есть специальные компании, которые занимаются такими задачами.
Но хороший Data Scientists это Data Investigator и Explorator, поэтому интереснее сделать самому и как можно точнее.
И вот в одной компании про это прознали кибербезопасники и строго запретили DSам самим матчить — но тк задача никуда не делась, решили сделать сами, чтобы по всем правилам, пром процессом и тд, и вот что из этого вышло.
Подход 1
Возьмем хэш от всех полей с одинаковым смыслом и будем маячить таблички по таким хэшам.
Догадались что произошло?
90% хэшей оказались нуллами (пусто) — поскольку строки, по которым шло хэширование, содержали хотя бы одно пустое поле. Толку от такого "матчинга", понятное дело, немного
После такого шикарного выступления бывшие сотрудники всевозможных органов не сдались, а решили перейти к плану Б
итак, Подход 2
После тотального провала в первом подходе экс заплечных дел мастера решили найти "самые главные поля" и пояснить матчить по ФИО + дате рождения.
Выяснилось что только в Москве несколько тысяч полных тезок по ФИО + ДР
Эволюционно гении пришли к Подходу 3: давайте матчить по ДУЛ (документу, удостоверяющему личность) + ФИО + ДР, ну чтоб уже наверняка
И вот что из этого вышло
PS
Потом я не раз видел как из аналитических песочниц пытались убрать любые перс данные и вспомогательные ID, оставив только единственно правильный. Заканчивался этот идиотизм как правило когда по заданию биг боссов срочно нужно было добавить в процесс какую-н выгрузку из внешней системы / полученную с рынка -- и естественно, внешний мир про прекрасный внутренний ID ничего не знал что, очевидно, делало невозможным любой матчинг -- то есть добытые извне данные никак не добавить к внутренним. Осознанием руководством такого тривиального факта приводило к развивающей обратной связи адептам "не пущать" на радость и благость, как говорит один мой товарищ, не дающий писать мне совсем дичь )
Мораль проста: не мешайте DSам делать свою работу, авось без премии не останетесь😄