Как избежать распространенных ошибок при работе с событиями

Автор: Александр Тыртов — Ведущий продуктовый аналитик Работа.ру.

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

На скрине — тепловая карта кликов на главной странице, по данным Яндекс.Метрики. Эта карта показывает, на какие элементы и области страницы пользователи кликают наиболее часто. Как можно увидеть, разделы «Компании» и «Блог» популярны в значительно меньшей степени в сравнении с поиском и формой авторизации.

Выглядит красиво? Безусловно. Однако, стоит помнить, что полный анализ пользовательской активности только с помощью тепловых карт невозможен, так как они не показывают причины выбора пользователей, не различают случайные и целенаправленные действия, не позволяют увидеть последовательность действий или анализировать активность конкретных пользователей или их сегменты.

Так что же такое это самое «событие»?

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

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

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

Почему события так важны?

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

Для поиска ответов на подобные вопросы аналитик разрабатывает дашборд, основываясь на событиях со страницы регистрации. Чаще всего такая визуализация представляется в виде воронки, которая служит ключевым инструментом для выявления критических точек взаимодействия. Используя такие воронки, можно оценить конверсию на каждом этапе, что позволяет продуктовой команде делать выводы и генерить гипотезы для улучшения общей конверсии, увеличения числа регистраций и, соответственно, потенциального дохода. Анализ конверсии успешных регистраций из разных рекламных кампаний позволяет маркетингу сэкономить бюджет, отключив неэффективные кампании.

Также важно провести анализ заполнения полей регистрационной формы, чтобы понять, на каких этапах «отваливаются» пользователи.

К примеру, пользователи могут прекращать регистрацию на этапе ввода пароля, если требования к его сложности слишком высоки.

Как обычные пользователи становятся платными клиентами?

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

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

События и AB-тесты

Для проведения AB-тестов продуктовая команда регулярно улучшает продукт, внедряя новые функции. Предположения для усовершенствований базируются на данных аналитиков о поведении и проблемах пользователей. AB-тесты позволяют оценить, как нововведения влияют на работу продукта и его восприятие пользователями, подтверждая или опровергая их эффективность.

Суть AB-тестов заключается в разделении пользователей на группы: одна из них видит стандартный вариант продукта (контрольная группа «A»), а другая — измененный (группа «B»). Анализируются как основные, так и дополнительные метрики, полученные в ходе теста.

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

Какую пользу принесла рекламная кампания?

События играют ключевую роль в оценке эффективности рекламных кампаний, начиная с основных параметров (трафик, цена одного клика, кликабельность (CTR) и т.п.). Эти данные помогают аналитикам измерять и сравнивать результаты различных кампаний.

А еще события позволяют оценить стоимость действия пользователя (CPA), что является супер-важным показателем для оценки эффективности кампаний. На основании CPA можно принимать решения о прекращении неэффективных рекламных активностей, увеличении бюджета для успешных кампаний и оптимизации расходов на рекламу.

Одним из важных аспектов является возможность сегментировать пользователей на основе их действий, что помогает лучше понять, кто составляет целевую аудиторию и как отличается поведение различных сегментов. Кроме того, параметры событий помогают выявлять фрод в действиях пользователей и оценить целесообразность и объем выплат сторонним рекламным агентствам.

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

1. Важность специфических параметров в событиях.

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

2. Объем сохраняемых данных.

В 2022 году отмеченные события сгенерировали более 1,5 млрд строк данных, что занимает на жестких дисках 691 Гигабайт. Если бы мы сохраняли вообще все события без отбора, стоимость хранения данных значительно бы возросла. Это не только привело бы к значительным финансовым затратам на хранение, но и могло бы вызвать проблемы с нехваткой места на серверах, как это произошло при случайном добавлении полного текста вакансий в данные событий поиска. Это пример того, как избыточный сбор данных может привести к неоправданно высоким затратам и техническим проблемам.

Синхронизация и стандартизация работы между различными отделами — довольно сложный вопрос, но, если им не заниматься, это может привести к большим проблемам. Именно поэтому еще в 2020 году отдел аналитики Работа.ру, в сотрудничестве с продуктовой командой и отделом разработки создал специальную инструкцию для унификации процесса создания и управления событиями, обеспечивая их корректное заведение и последующую обработку данных. Такое решение позволяет всем участникам процесса работать в рамках единой системы и способствует более эффективному взаимодействию и анализу.

Переходим к основным вопросам

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

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

Заведение нового события в проект начинается с задания, которое ставит менеджер по продукту в трекере задач. Аналитик может предложить изменения или уточнения, а затем оформляет описание события в реестре и координирует разработку с продуктовой командой.

Соискатели

Соискатели активно взаимодействуют с сайтом: они ищут вакансии, создают резюме, откликаются на объявления, звонят работодателям и выполняют множество других действий. Работа с событиями осуществляется как в web-, так и в app-аналитике, при этом подходы к сбору и анализу данных в этих направлениях остаются схожими, несмотря на различия в интерфейсах и возможностях.

Рекрутеры

Рекрутеры также активно участвуют в процессе подбора персонала: они публикуют вакансии, работают с базой данных резюме, обрабатывают поступающие отклики и следят за новостями в индустрии. В настоящее время рекрутеры используют web-аналитику, но в будущем возможно внедрение мобильных приложений, аналогичных тем, что есть у конкурентов.

Правила написания тех. задания

При написании ТЗ на событие мы соблюдаем следующие правила:

Описание событий в реестре событий

В реестре событий представлено описание всех событий, отправляемых в базу данных аналитики. Существуют отдельные страницы для B2B-направления, web-B2C и app-B2C.

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

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

После определения, какие данные необходимо собирать, следующим шагом является разработка механизма их отправки. События могут отправляться как с клиентской стороны (фронтенд), так и с серверной (бэкенд).

Отправка событий с фронта обычно связана с пользовательскими взаимодействиями (клики по кнопкам или ссылкам, заполнение и отправка форм и т.п.). В этих случаях основной объект, с которым работают аналитические системы, — ивент, который представляет собой описание произошедшего события и в виде JSON-пакета отправляется в аналитическую базу данных в ответ на действие пользователя. JSON-пакет содержит поля, описывающие детали совершенного действия.

Web-аналитики могут наблюдать отправку событий с фронта непосредственно в браузере. Однако проверить отправку событий с бэкенда в веб-интерфейсе невозможно — здесь требуется просмотр событий непосредственно в базе данных для оценки их качества и полноты.

Эта информация подчеркивает важность правильной настройки событий, чтобы обеспечить точность и надежность собираемых данных.

После того как мы определили, что собирать и как отправлять, следующим важным вопросом становится выбор места для хранения событий. Они должны быть направлены в специализированную базу данных аналитики. Для этих целей мы используем сервер ClickHouse, который обладает рядом значительных преимуществ для обработки больших объемов данных.

Особенности ClickHouse:

1.Высокая скорость обработки запросов

ClickHouse способен обрабатывать SQL-запросы с агрегацией данных за два года в среднем за 20-30 секунд, несмотря на то, что размер таблицы составляет 6 млрд строк.

2. Эффективное сжатие данных без потери производительности

В этом году наша команда успешно сжала таблицу с событиями с 2 ТБ до 691 ГБ. Общее количество строк в таблице составило 6 477 891 779, столбцов — 69. Такая оптимизация позволяет значительно сократить затраты на хранение данных, снижая общие расходы компании.

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

Проверка корректности отправки и приемки событий является критически важной для обеспечения точности данных аналитики. Этот процесс включает несколько ключевых шагов:

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

Роль аналитика в тестировании событий

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

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

Как тестировать успешную запись данных в аналитическую базу данных?

Для тестирования корректности записи событий в аналитическую базу данных, необходимо в первую очередь обеспечить доступ к этой базе. Тестирование обычно начинается с выполнения простых SQL-запросов, которые проверяют основные условия, такие как наличие и корректность заполнения обязательных полей события. Это позволяет убедиться, что событие не только успешно попадает в базу, но и содержит все необходимые параметры для последующего анализа.

Такая проверка является экономически выгодной, так как позволяет быстро выявлять и исправлять ошибки, предотвращая долгосрочные проблемы с качеством данных, что в итоге сокращает время и ресурсы, требуемые для анализа и принятия бизнес-решений.

Проблема 1: «отсутствие данных в базе при новых событиях».

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

Решение

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

Проблема 2: «событие уходит на платформе, данные есть, но они не корректные».

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

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

Решение

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

Проблема 3: «отсутствие событий в базе данных».

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

Решение.

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

Проблема 4: «ситуация с удалением события: вызов для аналитика».

Событие было удалено — это сценарий, который может вызвать значительные трудности для аналитика, особенно когда требуется срочно подготовить анализ и ответить на вопрос: «Почему падают метрики?».

Решение.

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

Ошибки в аналитических данных могут обходиться компании очень дорого по множеству причин:

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

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

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

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

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

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