Как настроить пользовательские события (Event Definitions) в Trigly
Создание кастомных событий, валидация properties, системные vs пользовательские события. Полный контроль над event tracking.
Что такое Event Definitions
Event Definitions — это схемы пользовательских событий в Trigly CDP, которые описывают название, тип, допустимые свойства (properties) и правила валидации для каждого события. Без чёткой структуры событий данные быстро превращаются в хаос: разработчики отправляют одни и те же действия под разными именами, теряются обязательные параметры, аналитика становится бесполезной.
Event Definitions решают эту проблему: вы один раз описываете схему события, а Trigly проверяет каждый входящий вызов на соответствие. Это особенно критично, когда над проектом работает несколько разработчиков или подключены внешние интеграции.
Все события хранятся в ClickHouse — колоночной базе данных, оптимизированной для аналитики. Данные партиционируются по месяцам и хранятся 365 дней (TTL). Это позволяет обрабатывать миллионы событий в секунду и строить сложные аналитические запросы без нагрузки на основную базу PostgreSQL.
Системные события
Trigly автоматически трекает события по всем подключённым каналам коммуникации:
Email-канал:
email.sent— письмо отправленоemail.opened— письмо открыто (tracking pixel)email.clicked— клик по ссылке в письмеemail.bounced— письмо не доставлено
SMS-канал:
sms.sent— SMS отправленоsms.delivered— SMS доставлено
Push-канал:
push.sent— push-уведомление отправленоpush.clicked— клик по push-уведомлению
Кампании:
campaign.launched— кампания запущенаcampaign.completed— кампания завершена
Системные события нельзя удалить или переименовать. Они доступны во всех аналитических отчётах и могут использоваться в условиях динамических сегментов и триггерных цепочек Flow Builder.
Создание кастомного события: пошаговая инструкция
Шаг 1: Перейдите в Event Definitions
Откройте CDP в боковом меню, затем выберите раздел "Event Definitions" (Определения событий). Здесь вы увидите список всех системных и пользовательских событий.
Шаг 2: Создайте новое определение
Нажмите "Создать" и заполните форму:
- Name (системное имя):
purchase— используется в SDK-вызовах, только латиница, snake_case - Display Name (отображаемое): "Покупка" — показывается в интерфейсе Trigly
- Description (описание): "Клиент совершил покупку на сайте" — помогает команде понять назначение события
- Properties schema — описание ожидаемых свойств:
revenue(number) — сумма покупкиitems(array) — список SKU товаровorder_id(string) — уникальный ID заказаcurrency(string) — валюта (RUB, USD)
Шаг 3: Настройте валидацию
Для каждого свойства укажите, является ли оно обязательным. Например, order_id и revenue — обязательные, а currency — опциональное с дефолтным значением "RUB".
Шаг 4: Сохраните и проверьте
После сохранения событие появится в списке и станет доступным для отправки через SDK.
Отправка событий через SDK
JavaScript SDK (клиентская сторона)
// Базовый вызов
trigly.track('purchase', {
order_id: 'ord-123',
revenue: 5990,
items: ['sku-001', 'sku-002'],
currency: 'RUB'
});
// Событие просмотра товара
trigly.track('product_viewed', {
product_id: 'prod-456',
category: 'Обувь',
price: 3990
});
// Событие добавления в корзину
trigly.track('cart_add', {
product_id: 'prod-456',
quantity: 1
});
Server-side API
POST /api/v1/sdk/track
X-API-Key: your-api-key
{
"customer_id": "uuid-клиента",
"event_name": "purchase",
"properties": {
"order_id": "ord-123",
"revenue": 5990,
"items": ["sku-001", "sku-002"]
}
}
Для массовой отправки используйте batch-эндпоинт /api/v1/sdk/batch — до 100 событий за один запрос.
Примеры полезных кастомных событий
Вот набор событий, который покрывает типичный e-commerce сценарий:
| Событие | Properties | Применение |
|---|---|---|
purchase |
order_id, revenue, items | RFM-анализ, LTV-предсказания |
product_viewed |
product_id, category, price | Товарные рекомендации |
cart_add |
product_id, quantity | Триггер "брошенная корзина" |
cart_abandon |
cart_value, items_count | Ретаргетинг через fallback-цепочку |
signup |
source, utm_campaign | Анализ источников трафика |
subscription_change |
plan, mrr | SaaS-метрики |
Советы и лучшие практики
-
Используйте snake_case для имён —
product_viewed, неProductViewedи неproduct-viewed. Это обеспечит единообразие в ClickHouse-запросах. -
Всегда передавайте revenue для транзакционных событий — это позволяет Trigly автоматически рассчитывать RFM-сегменты, AI-скоринг и LTV-прогнозы.
-
Не дублируйте системные события — не создавайте кастомное событие
email_opened, если Trigly уже трекаетemail.opened. -
Ограничивайте количество свойств — 5-10 свойств на событие достаточно. Избыток свойств замедляет аналитику и усложняет поддержку.
-
Документируйте назначение — заполняйте описание (description) для каждого события. Через полгода никто не вспомнит, зачем нужно событие
cx_flow_v2.
Распространённые ошибки
- Разные имена для одного действия: один разработчик отправляет
buy, другой —purchase, третий —order_completed. Договоритесь об именовании заранее, закрепите в Event Definitions. - Отсутствие revenue в событиях покупки: без этого поля не работают RFM-анализ и AI-предсказания.
- Передача PII в properties: не отправляйте пароли, номера карт и другие чувствительные данные. ClickHouse не предназначен для хранения PII.
- Слишком частые события: трекинг каждого скролла на странице создаст миллионы бесполезных записей. Отправляйте только значимые бизнес-действия.
Ожидаемые метрики
После настройки Event Definitions вы сможете отслеживать:
- Количество событий в день/неделю/месяц — через аналитику CDP
- Уникальные клиенты по событию — сколько клиентов совершили действие
- Конверсия между событиями — например,
product_viewed→cart_add→purchase - Revenue per event — средний чек для транзакционных событий
- Тепловая карта активности — через heatmap-аналитику по часам и дням
Часто задаваемые вопросы
Сколько кастомных событий можно создать?
Ограничений нет. Однако рекомендуем держать список в пределах 20-30 определений для удобства управления. Каждое событие должно нести бизнес-ценность.
Можно ли изменить схему события после создания?
Да, вы можете добавлять новые свойства в любой момент. Удаление существующих свойств не повлияет на уже записанные данные в ClickHouse — они сохранятся в исходном виде.
Как события влияют на AI-скоринг?
Trigly извлекает из ClickHouse ML-фичи на основе ваших событий: частота покупок, средний чек, разнообразие категорий, время последней активности. Чем больше качественных событий вы отправляете, тем точнее работает AI-скоринг и предсказание оттока.
Следующие шаги после настройки Event Definitions
Когда базовые события определены и данные начали поступать, переходите к следующим этапам:
Построение воронки конверсии
Определите ключевую цепочку событий для вашего бизнеса. Для e-commerce это обычно: page_view → product_viewed → cart_add → purchase. Для SaaS: signup → feature_used → subscription_change. Настройте аналитику конверсии между этапами — это покажет, где вы теряете клиентов и на каком шаге нужно усилить коммуникацию.
Привязка событий к триггерным цепочкам
Каждое событие может стать триггером для автоматической цепочки в Flow Builder. Типичные сценарии:
cart_abandoned→ цепочка возврата корзины (email через 1 час, push через 4 часа)purchase→ post-purchase серия (благодарность, запрос отзыва, cross-sell)product_viewed(3+ просмотра одного товара) → персональное предложение со скидкой
Обогащение AI-моделей
Чем больше качественных событий вы отправляете, тем точнее работают предиктивные модели Trigly. ML-фичи извлекаются автоматически: частота покупок, средний чек, разнообразие категорий, время между визитами. После накопления 3-месячной истории модели предсказания оттока достигают точности 80-85%.
Документация для команды
Создайте внутренний документ с полным списком событий, их назначением и обязательными свойствами. Поделитесь с разработчиками и аналитиками. Это предотвратит появление дубликатов и обеспечит единообразие данных при масштабировании команды. Стандартизированная система событий — это язык, на котором говорят маркетинг, продукт и аналитика; без него каждая команда работает со своей версией данных. Начните с создания 5-7 ключевых Event Definitions уже сегодня — через 30 дней накопленных данных будет достаточно для запуска первых триггерных цепочек и построения воронки конверсии.
Готовы стандартизировать event tracking в вашем проекте? Создайте первое Event Definition прямо сейчас или изучите другие возможности Trigly CDP для управления клиентскими данными.