В рамках спецпроекта Product Analytics Champions рассказываем, как и зачем используют S2S обогащение Amplitude через стандартные API.
Что такое S2S события и зачем они нужны
Межсерверные (server-to-server или S2S) события позволяют отслеживать кастомные события и параметры через HTTP запросы. Они часто используются в мобильной атрибуции, например, в Appsflyer или в Adjust.
При этом S2S события можно использовать и в Amplitude. Для прометки большинства событий, их свойств и параметров пользователей достаточно стандартного SDK Amplitude. К S2S событиям стоит прибегать при импорте данных из других систем, которые сложно передавать напрямую в Amplitude.
Примеры использования такой интеграции:
1. Можно отправлять свойства пользователей из CRM (например, количество покупок или дату регистрации на сайте/приложении) даже для тех тех, кого еще нет в Amplitude. После того, как они появятся в Amplitude, данные по ним смэчатся по user ID. Это полезно на начальных этапах, когда еще не все пользователи появились в Amplitude.
2. Можно передавать события "выкупа заказа", например, для приложений с самовывозом, чтобы события самого заказа в приложении дополнялись еще событиями финальной оффлайновой точки воронки.
Хотим рассказать, как это способ используется в Лиге Ставок. Мы широко применяем сервис продуктовой аналитики Amplitude для анализа поведения пользователей. Например, это помогает нам сокращать количество ошибок и увеличивать конверсию в регистрацию. При этом мы собираем дополнительные данные по пользователям в CRM и других системах. Их нет в Amplitude, но с ними можно анализировать большее количество срезов, чем есть в разметке.
Так в Лиге Ставок создали систему межсерверного (S2S) обогащения Amplitude через стандартные API, чтобы глубже анализировать поведение и свойства своих клиентов.
Что нужно для такого обмена данными
1. Определите параметры, которые вы хотите дополнительно передавать в Amplitude для работы с функциями сервиса и уже существующими событиями/свойствами пользователей. Например:
Категории по доходу и другая финансовая информация
Конверсии, которые не покрываются разметкой (например, переходы на сторонние web-view из приложения)
2. Определите источники данных:
CRM
Системы веб-аналитики
Внутреннее хранилище данных (DWH)
И другие
3. Python 3.7 (и выше) для настройки передачи данных.
Инструкция по настройке s2s передачи данных
У Amplitude есть свой API выдачи сырых данных по проекту. Подробную документацию по нему можно найти по ссылке. Для пуша событий мы используем https://api2.amplitude.com/httpapi или будущие обновления из документации, обычно они идут с приставками 2, 3 и т.д. Для обогащения профиля пользователя берем точку https://api2.amplitude.com/identify. Ключ авторизации берется из настроек проекта в Amplitude:
Код. Стоит отметить, что в Лиге Ставок намеренно пишут простые агенты, понятные даже начинающим аналитикам.
Шаг 1. Агент доставки s2s событий
Для создания агента понадобится всего две библиотеки:
import amplitude
import pymssql
В нашем случае источником выступает MSSQL хранилище данных. По умолчанию библиотека Amplitude позволяет вам отправлять события, аналогичные SDK разметке. Формируется JSON с вашим набором данных и отправляется в API Amplitude, все просто.
Несмотря на то, что в мы в Лиге не стали писать код с нуля и используем готовую библиотеку, нам пришлось ее немного изменить. А именно — добавить точку отправки профиля клиента. Далее будет описан пример корректировки библиотеки, но, конечно, лучше написать своей параметризованный код.
Переходим к корректировкам в библиотеке. Изменения коснулись блока AmplitudeLogger, где заменили ссылку https://api2.amplitude.com/httpapi на https://api2.amplitude.com/identify:
class AmplitudeLogger:
def __init__(self, api_key, api_uri="https://api2.amplitude.com/identify"):
self.api_key = api_key
self.api_uri = api_uri
self.is_logging = True
Теперь все сообщения пойдут в API обогащения профиля пользователей. Также нам пришлось исключить (закомментировать) блок названий типа событий. Он уже не требуется при доставке профиля пользователей. Исходный вариант блока:
event_type = kwargs.get('event_type', None)
if self._is_None_or_not_str(event_type):
return None
event["event_type"] = event_type
После исключения/закомментирования:
#event_type = kwargs.get('event_type', None)
#if self._is_None_or_not_str(event_type):
#return None
#event["event_type"] = event_type
Блок свойств события заменяем на свойства клиента. Исходный блок:
event_properties = kwargs.get('event_properties', None)
if event_properties is not None and type(event_properties) == dict:
event["event_properties"] = event_properties
Заменяем на:
user_properties = kwargs.get('user_properties', None)
event["user_properties"] = user_properties
Шаг 2. Настройка передачи событий в Amplitude
Cкриптом передаем наши s2s обогащения профилей, где USERID это ваш ключ клиента между системами. Например:
amplitude_logger = amplitude.AmplitudeLogger(api_key = "Ключик")
# собираем событие на примере обогащения CRM категорий
event_args = {"user_id": str(USERID),
"user_properties":{"CRM_Segment":str(SEGMENT), "CRM_Group": str(GROUP), "CRM_Level": str(LEVEL)}}
event = amplitude_logger.create_event(**event_args)
# отправляем в Amplitude
amplitude_logger.log_event(event)
Готово! Данные должны отображаться в Amplitude:
Шаг 3. Очередь доставки
У нас такой подход: запросил запись на отправку -> отправил -> зафиксировал в очереди, что отправлено.
Пример получения записи для отправки профиля. Используется singlе обработка результата из 4 столбцов. Далее полученные данные раскладываются и передаются уже в s2s запросе, на примере выше.
conn = pymssql.connect(server, user, password, database)
cursor = conn.cursor()
query = "СЕЛЕКТ таблицы или ВЫЗОВ процедуры"
cursor.execute(query)
for row in cursor:
USERID = row[0]
SEGMENT = row[1]
LEVEL = row[2]
GROUP = row[3]
conn.commit()
conn.close()
Именно так проходит обогащение данных в Amplitude в Лиге Ставок.
В будущих обновлениях спецпроекта мы расскажем, как команда маркетинга использует сервис продуктовой аналитики в своей работе.
А здесь можно посмотреть, кто нам нужен в команду, в том числе по продукту и аналитике, например, Руководитель направления DWH или Head of Product Department