Как мы строили аналитику для маркетинговых квизов: архитектура, метрики и выводы

В этой статье я хочу поделиться подходом к аналитике, который мы использовали в проектах с высокой нагрузкой и сложной воронкой. Мы собирали данные, строили агрегации, тестировали гипотезы и постепенно пришли к системе, которая работает без перекосов в производительность и даёт понятные ответы на вопросы бизнеса.

Материал будет полезен тем, кто строит аналитику в своих продуктах, особенно если вы работаете с воронками, большими объёмами событий или маркетинговыми инструментами.

Архитектура сбора данных

Первое, что мы сделали — отказались от идеи хранить все данные в одной таблице. Это ограничивает гибкость и создаёт проблемы с производительностью.

Мы разделили данные на три слоя.

• Слой событий. Каждое действие пользователя фиксировалось как отдельное событие. Это дало возможность анализировать любые сценарии без привязки к заранее определённым метрикам.

• Слой агрегаций. Сырые события мы хранили ограниченное время. Для быстрых ответов мы строили агрегации — по дням, часам, устройствам, источникам трафика. Это позволило показывать дашборды без тяжёлых запросов к сырым данным.

• Слой витрин. Это подготовленные данные для конкретных отчётов. Например, воронка или распределение по каналам. Они обновлялись раз в сутки и использовались для большинства интерфейсов.

Структура события

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

Это позволило быстро менять структуру без миграций. Например, когда мы добавили utm-метки, нам не пришлось пересоздавать таблицу.

Важное решение — мы не стали хранить user-agent целиком. Вместо этого мы парсили его на стороне клиента и передавали уже готовые поля: браузер, версию, операционную систему, тип устройства. Это сократило объём хранимых данных и упростило аналитику.

Обработка событий

Мы разделили обработку событий на два потока.

• События, которые должны быть видны сразу, шли в агрегации с минимальной задержкой. Например, запуски и завершения обновляли дашборд в реальном времени.

• События для глубокого анализа накапливались и обрабатывались пачками через очереди сообщений. Это снижало нагрузку и позволяло делать сложные выборки без ущерба для производительности.

Агрегации мы строили по нескольким измерениям: дата, час, тип устройства, источник трафика, кампания. Это покрывало большинство запросов без необходимости обращаться к сырым данным.

Метрики: что мы считали и зачем

Общие метрики

Визиты и уникальные посетители. Мы разделили эти показатели сразу, потому что они дают разную информацию. Визиты показывают активность, уникальные посетители — охват. Разница между ними показывала, сколько пользователей возвращается.

Завершения. Для квизов это отправка заявки. Мы зафиксировали это как целевое действие и считали все остальные метрики относительно него.

Среднее время прохождения. Эта метрика оказалась полезным индикатором сложности. Мы заметили корреляцию между временем и качеством трафика: если время падало, а конверсия росла, это часто означало, что трафик стал более целевым.

Соотношение запусков и завершений. Мы считали, сколько пользователей начало прохождение и сколько дошло до конца. Разница между этими числами показывала основной объём потерь.

Воронка

Воронка стала самым информативным блоком. Мы разбили путь пользователя на этапы и на каждом считали процент потерь.

Мы использовали два уровня детализации. Первый — общая воронка из четырёх этапов: открыл, начал, дошёл до конца, отправил форму. Второй — детальная воронка по каждому вопросу.

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

На каждом этапе мы считали три показателя: количество дошедших, процент отказов и среднее время прохождения. Вместе они давали полную картину.

Временная аналитика

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

Почасовой график показывал два-три пика активности в течение дня. Дневной — позволял увидеть, что в выходные конверсия падает. Это позволило скорректировать рекламные ставки.

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

Маркетинговая аналитика

С помощью utm-меток мы разделили трафик по каналам, кампаниям, ключевым словам и креативам.

Мы выделили несколько уровней анализа.

• Точечные показатели: лучший источник по конверсии, лучший источник по количеству заявок, лучший креатив, лучшая кампания.

• Распределение: доля каждого канала в общем потоке заявок.

• Соотношения: трафик к заявкам по каждому источнику и кампании.

• Детальные списки: топ-10 креативов и ключевых слов.

Это дало возможность понять, какие источники приносят не просто трафик, а реальные заявки. Оказалось, что каналы с самым большим трафиком часто давали самую низкую конверсию, а небольшие источники — наоборот.

А/Б-тестирование

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

Мы сравнивали версии по нескольким параметрам: конверсия, отказы, время прохождения, соотношение начал и завершений.

Если разница была статистически значимой, мы принимали решение. Без тестов любое изменение оставалось гипотезой. С тестами — решением, основанным на данных.

Анализ структуры квиза

Мы также анализировали содержимое квиза: как распределяются ответы на вопросы, какие варианты выбирают чаще, какие вопросы пропускают.

Если вариант выбирали редко, это часто означало, что он нерелевантен или сформулирован неясно. Если пользователи часто оставляли свои ответы вместо выбора из списка, это означало, что предложенные варианты не покрывают их потребности.

Для числовых вопросов мы смотрели не только на среднее значение, но и на распределение. Если все ответы сгруппированы в узком диапазоне, аудитория однородна. Если разброс большой — аудитория разная.

Формы связи

Форма заявки оказалась самым проблемным этапом. Мы анализировали время заполнения и отказы на каждом шаге формы. Если пользователи часто уходили на первом шаге, проблема связана с восприятием формы. Если на втором — с финальным действием. Мы также сравнивали разные формы между собой. Разница в скорости заполнения и уровне отказов показывала, какая форма работает эффективнее.

Что не сработало

Не все метрики, которые мы добавили, оказались полезными.

Среднее количество шагов не давало нужной информации — оно зависело не от сложности, а от того, где пользователь выходил из квиза.

Время на странице для квизов тоже оказалось слабо связанным с качеством — пользователи могут долго думать над вопросом или отвлекаться.

Выводы

Аналитика не должна быть сложной. Она должна быть понятной и помогать принимать решения. Если данные не дают понимания, куда двигаться дальше, они бесполезны. Если они показывают, что именно нужно изменить, — они становятся инструментом управления. Хорошая аналитика — это не набор графиков. Это система, в которой каждый блок отвечает на конкретный вопрос, а все вместе они складываются в полную картину. Такую, которая позволяет не просто наблюдать за происходящим, а управлять им.