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

Грубо можно разделить на два больших куска:
1. Больше зарабатывать: маркетинг и продажи хотят делать релевантные предложения, поддержка и колцентры хотят быстрее и качественнее обслуживать клиентов. Для этого нужен максимально полный профиль клиента
2. Меньше терять: всякие мошенники, чёрносписочники — идентифицировать и получать более полный профиль которых очень хочется рискам, скорингам, коллекторам и прочим.

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

ты вот шутишь, а они ещё как могут

Ну, есть ощущение, что это "искать где светло".
В маркетинге и продажах основные проблемы не в отсутствии данных, а в отсутствии мозгов, а это данными не лечится.
Ну и бороться с рисками пользователя банку не интересно (собственно потому и не борются)
Для скоринга по кредитам подобные данные еще могли бы быть интересны, но их, насколько я знаю, все равно не используют.

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

"Маркетинг и продажи" не очень совместим с понятием "релевантные предложения" ))) Я бы не стал верить добрым звонкам с предложением кредита или нового тарифного плана. Думаю, таких людей большинство. Нет, ну есть люди, которые готовы взять кредит, но я бы деньги в долг таким бы не давал и наоборот. По поводу мошенничества. Вроде бы индивидуалов уже не осталось. Остап Бендер сегодняшнего дня - это много чаще не человек, а крупная организация... Впрочем,  их всё равно особо не ловят

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

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

Это не золотая запись уже. Не в терминал golden source. И вообще ML даже близко к таким вещам нельзя допускать. Поиск дубликатов для сравнения оператором - пожалуйста. Но с обязательным механизмом давания оператору по голове за нажимание «выделить всё» и «объединить» без раздумий.

ML хорошо применять для объединения, разделения и инвалидками данных в маркетинге на data provider’ах. Там, где прибыль есть, но нет юридических последствий ошибки.  Но это не golden source / golden record, которую можно пропагировать во все системы

какие все? для apple вполне себе золотая, для google тоже. Все де зависит от окружения и целей. Да, для резидент не резидент так себе запись, и то пока дата сеты не полные. Так купи у гугла, и вполне, не на всех есть дата сет, но на кого есть, уже считай золотой ключ.

«Все» в смысле системы учета заказчиков/клиентов. Не потенциальных, а реальных.

можно попробовать дополнить данные о клиенте в CRM системе тем, что мы найдём в других источниках, но нельзя просто так на основе решения ML взять две записи в CRM и объединить с объединением данных, ФИО, email'ов и прочее. Всё равно будет "главная" база данных с клиентами и дополнительная внешняя база с ML-улучшенными и ML-очищенными и ML-дедублицированными данными.

Только никакой ml нафиг тут не нужен. Потому что или у тебя есть железобетонно однозначная привязка к клиенту его очередного тайного личного емейла, либо ненулевой шанс отправить не тому человеку данные клиента, а должен быть нулевой.

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

Я к чему, собирайте дата сеты, и настраивайте алгоритмы, все будет работать.

покажите, пожалуйста, пример того, где ML использовался для дедупликации бизнес-данных пользователей без вмешательства оператора? (не того, что используется в маркетинге, а того, что используется для логина на сайт, оплаты подписки, оформления пособий, выдачи больничных и пр.)

к использованию в маркетинге никаких претензий (кроме названия — это неправильно называть golden record)

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

Если вы задаете вопрос  игры резидент не резидент, там смотрите как Китай решает.

Вообще тут все просто, объект и предмет идентификации должны быть одним целым. И да тут чутка ml тоже нужно. НО другого, а вот поведение объекта идентификации и матчинг его  с "серыми" объектами - ml отлично себя раскрывает. Да и дальнейший матчинг "вторичных аватаров", на набранном сете почти гарантирован. Да даже пользователю не нужно давать доступы при матчинге, пусть просто алгоритмы отрабатывают его как один мастер аватар, а видимость множества независимых аватаров сохраните. А то что делается в мелких конторах, ну даже 2000-3000 юзеров дешевле свести ручками, порционно "отрубая" доступы, по обратной связи.

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