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

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

Изображение: YummyBuum/shutterstock.com

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

Тепловая карта кликов

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

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

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

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

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

Зачем нужны события?

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

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

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

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

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

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

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

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

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

  1. Конверсия в оплату через разные каналы привлечения помогает оптимизировать маркетинговые кампании.
  2. Конверсия в оплату, основанная на источниках создания заказа, указывает на наиболее эффективные пути к оплате.
  3. Конверсия, зависящая от того, кем создан заказ — менеджером Работа.ру или рекрутером, — дает понимание внутренней эффективности процессов.
  4. Конверсия заказов, оплачиваемых по счету или картой, выявляет предпочтения пользователей и проблемы с различными способами оплаты.

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

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

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

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

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

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

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

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

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

Почему не стоит собирать все события подряд?

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

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

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

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

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

Порядок заведения событий

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

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

1. «Что именно нужно собирать?»

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

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

Соискатели

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

Рекрутеры

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

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

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

  • События на мобильных платформах должны заводиться одновременно и единообразно для Android и iOS.
  • События на мобильных платформах регистрируются не только в аналитическом хранилище данных, но и в Appmetrica.
  • События на web-платформах отправляются не только в аналитическое хранилище данных, но и в Yandex.Metrica.
  • События, относящиеся к одинаковым сущностям и сценариям, должны содержать одинаковые параметры на всех платформах. Например, событие показа поисковой выдачи в Android должно содержать те же параметры, что и на сайте, за исключением параметров, специфичных для платформы (например, UID).
  • Каждое действие пользователя должно быть отдельным событием.
  • Название события состоит из трех частей, разделенных нижним подчеркиванием: CATEGORY_ACTION_LABEL (категория, действие, метка), и пишется капсом. Если необходимо, части названия могут содержать дефис для разделения слов, например: HEADER_CLICK_CREATE-RESUME. Таким образом, любой, кто видит название события, даже не будучи аналитиком или разработчиком, может примерно представить, что оно может означать.

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

В реестре событий представлено описание всех событий, отправляемых в базу данных аналитики. Существуют отдельные страницы для 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 идеальной платформой для хранения и анализа больших объемов данных, обеспечивая быстрый доступ к информации и снижение операционных издержек.

Как тестировать отправку и приемку событий?

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

  1. Проверка отправки событий с фронта. Ее можно выполнить непосредственно в браузере, используя инструменты разработчика для мониторинга сетевых запросов. Это позволит увидеть, что события действительно отправляются с клиентской стороны.
  2. Соответствие описанию в реестре событий. Необходимо удостовериться, что структура и содержание отправляемых событий точно соответствуют тому, что задокументировано в реестре событий. Это обеспечивает согласованность данных между тем, что предполагается отправить, и тем, что действительно отправляется.
  3. Проверка записи событий в базу данных. Если событие ушло — не факт, что оно дошло и записалось в БД, поэтому необходимо тестировать не только отправку, но и приемку событий. В результате осуществляется контроль, что события попадают в соответствующие поля и таблицы базы данных, и что данные сохраняются без искажений или потерь.
  4. Тестирование приемки событий контейнером. Это шаг включает в себя проверку, что система аналитики не только получает события, но и корректно их обрабатывает. Необходимо убедиться, что события интегрируются в аналитическую систему так, как это предусмотрено, и что система способна адекватно реагировать на поступающие данные.

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

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

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

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

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

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

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

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

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

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

Решение

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

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

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

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

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

Решение

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

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

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

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

Решение

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

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

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

Решение

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

Почему ошибки в аналитике стоят дорого?

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

1. Рабочее время сотрудников

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

2. Потеря данных и искажение фактов

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

3. Проблемы с качеством рекомендаций

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

4. Негатив от пользователей

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

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

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

Опубликовано 07.06.2024

Похожие статьи