Tarn работает поверх вашего собственного хранилища событий

Подключите таблицу событий с правами только на чтение и сопоставьте её колонки с полями Tarn. Продукт сформирует запросы для проверок; писать SQL или менять систему сбора событий не требуется.

SQLСвоя БД или DWH

Что вы вводите при подключении

Мы просим доступ только на чтение. Всё, что вы введёте, шифруется перед записью и обратно не показывается.

ДвижокPostgreSQL, Redshift, MySQL, MariaDB, ClickHouse, BigQuery или Snowflake.

ДоступХост, порт, база, пользователь и пароль — либо реквизиты BigQuery и Snowflake. Пароли и ключи мы шифруем перед записью.

Таблица событийИмя таблицы, при необходимости со схемой: analytics.events.

Имена колонокКакая колонка хранит имя события, время, платформу, версию, регион, параметры и идентификатор пользователя.

Куда именно Tarn ходит

Мы вызываем только эти методы вендора — и только на чтение.

SELECT · почасовые счётчикиГруппировка по имени, часу и срезам целиком внутри вашей базы — наружу выходят только числа.

SELECT · выборка параметровСвежие строки, чтобы разобрать состав параметров и встречавшиеся значения.

SELECT · уникальные пользователиCOUNT(DISTINCT) внутри вашего хранилища: наружу выходит одно число, а не идентификаторы.

Что Tarn забирает из события

По полученным событиям Tarn рассчитывает почасовой объём и показатели по срезам. Сырые события не сохраняются.

Что нужно Tarn	Откуда берётся
Имя события — обязательно	event_name
Время события — обязательно	event_time
Платформа	platform
Версия приложения	app_version
Регион	country
Параметры	properties — json, jsonb, variant или строка с json
Идентификатор пользователя	колонку укажите сами: имени по умолчанию нет

Откуда берётся план трекинга

Tarn собирает имена событий за последнюю неделю отдельным запросом по всему периоду. Это позволяет включить в каталог и редкие события, которые могли не попасть в выборку последних строк.

Типы параметров определяются по выборке. Параметры импортируются как необязательные; нужные ограничения вы задаёте в каталоге.

Что стоит знать заранее

Мы перечисляем это здесь, а не выясняем на пилоте.

Postgres проверен с подключением к базе. Для MySQL и ClickHouse реализованы драйверы; проверка с реальными базами пока не завершена.

Для BigQuery и Snowflake проверены построение запросов и обработка ответов. Работа с реальными облачными аккаунтами ещё требует проверки.

Уникальные пользователи подсчитываются внутри хранилища запросом COUNT(DISTINCT). Tarn получает результат без списка идентификаторов.

В BigQuery и Snowflake запрос распределения событий на пользователя по умолчанию выключен, чтобы ограничить расходы на обработку данных.

Запросы ограничены по времени и числу строк. Перед подключением проверяется адрес базы; приватные и служебные адреса запрещены.

Как работает сверка с реальными данными

Что приложено к уведомлению

Как хранятся доступы к вашим системам