Есть один веб-сайт на обслуживании, где есть много разных каналов трафика, много регистраций пользователей, причем они и те же пользователи могут использовать:

1) разные ip
2) разные браузеры => разные куки, серверные сессии
3) разные устройства (комп на работе, комп дома, ноутбук жены, смартфон ...) => разные куки, серверные сессии, разные ip
4) разные аккаунты => разные userId для залогинившихся

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




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

Метод сопоставления прост: например, если есть часть действий с ip 123.123.123.123 и есть часть действий с ip 125.125.125.125, но у всех этих действий стоит userId = 4590, потому что во всех этих случаях посетитель работал под одним и тем же аккаунтом, то мы можем сделать вывод, что это один и тот же faceId

Если например есть часть действий без userId, а часть с userId и у всех этих записей один и тот же cookieId, значит мы можем сделать вывод, что первая часть действий без userId и эта часть с userId являются одним и тем же faceId

и т.д.

Но с ip есть и "подлянки"...:

С одного ip могут быть реально разные люди (разные faceId).

А если включить паранойю, то на одном и том же браузере с одним и тем же cookieId, serverSessionId могут быть два и более разных пользователя, но у них явно будут разные userId, но до того как они не залогинились отследить это будет невозможно, разве что по факту логаута... actTag = user.logout.4510 Но это уже реально паранойный вариант...))

Чего прошу:
посоветуйте в какой последовательности проводить нормализацию вывода faceId
и в какой момент и на основании чего генерить faceId???

Последовательность появления номеров всегда такая:
1. ip
2. serverSessId
3. cookieId
4. userId - до этого может и не дойти вообще, если юзер не логинился

при этом и "сила" кусочка в убывающем порядке: userId самый сильный, cookieId послабее, серверные сессии вообще могут перезапускаться при каждом новом входе в браузер, ну а ip может быть вообще динамическим, в том же кафе или ином публичном вайфае или просто мобильный интернет...

у меня реально что-то мозг ТУПИТ в какой последовательности проводить нормализацию.... ((((

javajdbcLumix,

я бы делал по порядку убывания силы связки.

1. все у кого есть явный юзер_ИД присвоить его в ФейсИД
2. затем все остальные --- взять cookieId и искать
совпадения с записями которые зафиксировны в пункте 1.
если есть совпадение -- позаимствовать оттуда ЮЗЕРИД и ФЕЙСИД
3. затем все остальные -- подускивать совпадения по actServSessId
4. потом по ИП.
5. оставшиеся -- ну просвоить юзерИД равно ФаисИД равно -1
6. выпить пива.

Спасибо за вариант решения! Завтра протестируем и отпишусь чёкаво.. насчет п.6 это не к нам))))) трезвенники, корпоративный абонемент в элитный фитнесс и т.п.)))

короче, все отлично получилось. спасибо за порядок нормализации!!