Я не очень симпатизирую людям, которые размахивают bullshit-терминами на конференциях, однако до сих пор не сделали банальные миграции БД и деплойку в своём продукте. Поэтому, услышав громкие заявления о новом сервисе Битрикса, мне стало за державу обидно захотелось рассказать о том, как такие вещи устроены изнутри.
Сей пост для тех, кто уже владеет сеткой коммерческих сайтов и хочет трекать деятельность посетителей кросс-доменно (т.е. идентифицировать поведенческие факторы по всей сети), однако по счастливой случайности ещё не стал очередным адептом Битрикса.
Технологическая суть
Кратко говоря, технологическая суть укладывается в 5 простых шагов:
1. Трекаем события в пользовательском пространстве (на сайтах).
2. Собираем данные в общую кучу, объединяя данные со всех источников.
3. Перекладываем кучу в стройную систему хранения, по которой можно делать а-ля-SQL-выборки.
4. Анализируем, собираем статистику, проводим коллаборативную фильтрацию.
5. Выдаём посчитанные данные про пользователя обратно на сайты.
С чего начать кросс-доменный трекинг пользователей
Как вы понимаете, скорее мир перевернётся, чем я предложу использовать проприетарный софт. Поэтому идём вот сюда SnowPlow и читаем ридми.
Документация по SnowPlow довольно качественная, но пока можно не пытаться осилить её всю целиком. В первую очередь нам нужно взять код счётчика и разместить ответную часть где-то на наших серверах.
В реальном продакшене SnowPlow предлагает использовать Amazon как CDN для иконки счётчика и кластер для логирования запросов (между прочим, они официальные партнёры Амазона). Нам для тестирования изначально подойдёт простейший VDS, куда можно положить php-скрипт и посмотреть его принцип действия. Я выложил на github простой пример.
Javascript-трекер SnowPlow основан на известном Piwik и поставляется под той же лицензией. На каждое событие он порождает HTTP-запрос к иконке счётчика, перечисляя в GET-параметрах данные о событии и о пользователе. Из коробки доступны события типа page view, page ping, link click, social actions (лайки, ретвиты), а так же произвольные события типа “категория-действие-параметры” и отправка произвольного JSON.
Отвечающая сторона (серверный скрипт) владеет кукой, на основе которой пользователь идентифицируется кросс-доменно, и добавляет её значение ко всем логируемым запросам. Для этого в скрипте на серверной стороне определяется политика P3P “NOI DSP COR NID PSA OUR IND COM NAV STA”. Содержимое политики я скопировал из документации, – пожалуйста, не спрашивайте меня, что означают все эти буквы.
Логи
В результате мы имеем логи запросов, в которых каждая строка означает одно событие. При этом, благодаря данным из кук, мы можем идентифицировать действия пользователя в рамках одного сайта, в рамках всей сети, действия пользователей над одним объектом, над группой объектов на разных сайтах и т.д.
Сами логи для анализа малопригодны. Их следует трансформировать в SQL-подобное хранилище, чтобы проводить по ним выборки. Замечу, что не смотря на маркетинговые заявления SnowPlow-цев, у них данные достигают возможности анализа только через 30-60 минут (задержку вносит Amazon, собирая данные со всех нодов своих хранилищ). В нашем упрощенном примере данные доступны фактически “сразу”.
Анализ и коллаборативная фильтрация
Welcome в гугл и на хабр. Лично мне импонирует технологический опыт Ivi.Ru про user-based и item-based фильтрацию, описанный здесь.
Возврат посчитанных данных о пользователе
После того, как мы посчитали данные и подобрали персональные рекомендации каждому пользователю, нужно отдать их обратно на сайты, чтобы те могли персонифицировать своё поведение для каждого пользователя. Один из простых способов это сделать – выставить HTTP-JSON API, в котором идентификатором ресурса будет идентификатор пользователя на конкретном домене (duid в терминологии нашего трекера).
Поскольку мы знаем матрицу соответствий duid-nuid (второе – кросс-доменный идентификатор), нам достаточно легко кэшировать эти данные на серверной стороне, “подкладывая” одни и те же данные под всеми значениями duid, которые нам известны по этому пользователю.
Продолжение следует.