Объединение (объединение) идентификаторов устройств, идентификаторов cook ie и идентификаторов учетных записей в единый идентификатор - PullRequest
Новая
       61

Объединение (объединение) идентификаторов устройств, идентификаторов cook ie и идентификаторов учетных записей в единый идентификатор

0 голосов
/ 21 февраля 2020

Я пытаюсь создать сегменты пользователей, сгруппированные по общим интересам, для лучшего таргетинга объявлений.

Исходные данные журнала содержат как минимум одно из следующего (может быть только одна запись, две записи или все три записи):
идентификатор устройства
идентификатор учетной записи
-cook ie идентификатор

Моя конечная цель - назначить один и только один так называемый "идентификатор профиля" каждому физический пользователь, имея в виду, что у одного и того же человека могут быть разные устройства, браузеры и учетные записи (назовите это «объединением профилей»)

Теперь я веду таблицу БД со следующей (упрощенной) схемой : 

profileID,
idType, 
idValue

и получать запросы, содержащие тройки {deviceID, accountID, cookieID} и регистрировать (если еще не зарегистрирован) соответствующий идентификатор профиля для них
Например,

  1. Допустим, таблица БД изначально пуста, и мы получили {deviceID=1, accountID=2}
    . Мы генерируем новый profileID=aaa и сохраняем в таблице две строки с этим идентификатором профиля:

    profileID=aaa, idType=deviceID, idValue=1
    profileID=aaa, idType=accountID, idValue=2

  2. Затем мы получаем новый запрос {deviceID=1, accountID=3}
    Мы проверяем БД на наличие любых из {idType=deviceID, idValue=1} и {idType=accountID, idValue=3}

    Мы видим, что {idType=deviceID, idValue=1} уже был зарегистрирован под идентификатор профиля aaa, поэтому мы вставляем новую запись {idType=accountID, idValue=3} под тем же идентификатором профиля, поэтому наша таблица теперь выглядит следующим образом:

    profileID=aaa, idType=deviceID, idValue=1
    profileID=aaa, idType=accountID, idValue=2
    profileID=aaa, idType=accountID, idValue=3

Однако у этого подхода есть один побочный эффект:

  1. Предположим, мы получаем {deviceID=1}
    , поэтому добавляется запись profileID=aaa, idType=deviceID, idValue=1 в таблицу.

  2. Затем мы получаем {accountID=2}
    , поэтому запись profileID=bbb, idType=accountID, idValue=2 добавляется в таблицу.

  3. Теперь, если мы получим {deviceID=1, accountID=2} и проверим таблицу, мы обнаружим, что два идентификатора профиля были зарегистрированы для обоих, поэтому нам нечего вставлять. Но это оставляет нам два идентификатора профиля для одного и того же физического лица.
    Один из вариантов - создать новый идентификатор профиля ccc и обновить значение поля profileID для обеих строк, но это будет слишком много времени и добавит задержка запроса API.

Отсюда возникает вопрос, каков будет лучший способ выполнения таких слияний, но в пакетном режиме (не как часть API запроса)?

...