Роль Event API в персонализации
Рекомендательная система знает о пользователе только то, что ей передали. Если событие потеряно — модель не знает о просмотре товара, не учитывает брошенную корзину, не видит покупку. Event API — канал передачи этих данных.
Каждое событие описывает конкретный факт: кто, что, когда и в каком контексте сделал.
{
"event_type": "add_to_cart",
"user_id": "u_12345",
"anonymous_id": "sess_abc",
"timestamp": "2024-11-15T14:32:01Z",
"item_id": "sku_98765",
"item_category": "running-shoes",
"price": 8990,
"quantity": 1
}
Платформа обрабатывает этот поток в реальном времени: обновляет affinity-профиль, пересчитывает сегменты, готовит обновлённые рекомендации для следующей страницы.
Типы событий в e-commerce
| Событие | Сигнал для системы | Вес |
|---|---|---|
| view | Интерес к товару | Слабый |
| wishlist_add | Намерение купить | Средний |
| add_to_cart | Сильное намерение | Сильный |
| purchase | Подтверждённый спрос | Очень сильный |
| search | Активная потребность | Средний |
| review | Постпокупочный опыт | Средний |
Схемы интеграции
Client-side. JS-сниппет на странице перехватывает клики и отправляет события напрямую из браузера. Просто интегрировать, но уязвимо к блокировщикам рекламы (~15–30% пользователей) и потерям при медленном соединении.
Server-side. Backend отправляет события в API после обработки транзакции. Надёжно для критичных событий — purchase не может потеряться из-за UX-проблем. Сложнее интегрировать, требует доступа к бэкенду.
Гибридная схема. Client-side для поведенческих (view, click), server-side для транзакционных (purchase, payment_completed). Оптимальный баланс надёжности и скорости интеграции.
Важно: для корректной атрибуции конверсий в A/B тестах purchase-событие обязательно должно содержать идентификатор сессии или experiment_id. Иначе невозможно атрибутировать покупку к конкретному варианту теста.