Автоматизация мониторинга ошибок в трафике. Кейс

Как возникла такая потребность

В первой части статьи руководитель отдела аналитики «Риалвеб» Яна Саулова и веб-аналитик Илья Пахомов рассказывают, как компания создала собственную систему мониторинга ошибок и почему понадобилась ее доработка.

В «Риалвеб» на агентском аккаунте Google Analytics доступно более 700 клиентских аккаунтов. Проследить за корректной передачей данных в ручном режиме во всех аккаунтах физически невозможно. Если учесть, что у одного аккаунта Google Analytics, как правило, более двух представлений, а то и намного больше, задача мониторинга корректной передачи данных по всем параметрам без дополнительных систем автоматизации становится невыполнимой. Поэтому автоматизация мониторинга ошибок и аномалий в трафике для рекламных агентств – это острая потребность, а не просто удобный инструмент.

Почему это важно

Никому не хочется терять ценные данные – факт. Но, как показывает практика, потерять их очень просто. Например, программист «снес» кусок кода, отвечающий за воронку электронной торговли, или же изменил идентификатор кнопки, отвечающей за лид; при запуске рекламной кампании может резаться метка. Словом, причин много, а результат один – потеря данных. В режиме реального времени увидеть изменения, ведущие к ошибкам сбора трафика, веб-аналитикам крайне сложно, особенно, если представлений более тысячи, а веб-аналитиков в штате – не более 10. Тем не менее, аналитик не только анализирует полученные показатели, но отвечает и за сбор, и за корректную передачу данных в системы. Результат может быть достигнут, если все специалисты опираются на достоверную статистику и корректные данные всех систем.

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

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

• Для e-commerce интересна информация по аномалиям в воронке продаж – как с отрицательными значениями от нормы, так и с положительными. Например, если это ночь распродаж или Черная пятница – получать уведомления, как об ошибках, так и об активности на сайте, важно здесь и сейчас. Это рекламные кампании, которые требуют корректировок в сжатые сроки.

Почему возникла потребность создавать свою систему автоматизации

Во многих интерфейсах существуют свои системы оповещений. Например, в том же Google Analytics можно настроить уведомления с частотой раз в день/неделю/месяц. Но нам необходимо видеть оповещения чаще, потому что мы хотим узнавать об ошибках максимально быстро. Что важно – мы хотим видеть ошибки в любых срезах, а интерфейс Google Analytics в этом плане оказался очень ограничен. Безусловно, можно вывести все на дашборды и отслеживать там. Но простая арифметика в виде трудозатрат специалистов на вывод графиков по каждому рабочему представлению Google Analytics говорит, что эта идея не самая хорошая. Колоссальные затраты на построение дашбордов, ручной мониторинг, ручной поиск ошибок, ручные правки на дашбордах – все это нам добавит проблем и не решит существующие.

Почему изначальный вариант оказался не так удобен, как нам хотелось

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

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

Итак.

1. Проблема доступов

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

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

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

Это специальный аккаунт, который создается для доступа к сервисам Google вместо пользователя без авторизации в браузере. Ключи доступа для таких аккаунтов создаются так же, как и для клиентской OAuth2 авторизации – через Google Cloud Console. При создании сервисного аккаунта создается специального вида почта, которой нужно выдать все необходимые доступы.

2. Параметры и метрики мониторинга универсальны для всех клиентов, но значения для всех клиентов разные

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

Вот так выглядела база правил в BigQuery:

Для каждого проверяемого правила была выделена строка. Каждому клиенту соответствовала одна или несколько строк (правил).

В столбцах же содержалась информация о правиле, по которому нужно производить проверку, а именно:

• Какой показатель проверять;

• По какому знаку (больше, меньше, равно);

• По какому показателю фильтровать данные (если мы хотим проверить показатель только, например, по каналу CPC);

• Значение, с которым нужно произвести сравнение;

• Количество часов «в прошлое», за которое нужно произвести проверку.

Система мониторинга была реализована на языке Python.

1. При начале работы мониторинга с помощью библиотеки «pandas-gbq» из базы в BigQuery запрашивалась вся информация о необходимых для проверки правилах. Эта информация помещалась в Data Frame (структуру данных библиотеки Pandas для упрощения работы с табличными данными).

2. Описания правил обрабатывались и из них выделялись клиенты, по которым нужно собрать данные из Google Analytics. Далее данные по клиентам собирались из Google Analytics с помощью библиотеки «google analytics».

3. Данные, «подтянутые» из GoogleAnalytics, проверялись на соответствие указанным правилам. Для этого был разработан специальный класс, который проверял переданные ему данные на соответствие указанному правилу.

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

5. Сформированные сообщения об ошибках затем отправлялись на почту сотрудникам отдела и в Telegram.

Как уже говорилось, все правила для каждого клиента поначалу формировались вручную, «на глаз», а затем добавлялись в BigQuery посредством SQL-запроса, что привело к еще одной сложности – третьей по счету.

3. Alert (оповещение) – помощник в поиске ошибок и в то же время информационный шум.

Диапазон чисел аналитики выявляли вручную (среднее значение за n-период для каждого клиента/представления) и этот диапазон служил нормой, от которой отталкивался наш алгоритм мониторинга. Если шло отклонение от нормы в меньшую сторону – прилетал alert в чат-бот Telegram.

Например, если среднее значение сессий на платный источник Х на Y часов ниже нормы, то в чат-бот прилетало уведомление. Как упоминалось ранее, для нас важна скорость уведомлений, поэтому по основным параметрам мы получали уведомления каждые 4 часа, после расширили окно мониторинга до 5 часов, а затем по некоторым параметрам – до 10 часов.

На скриншоте alert чат-бота в Telegram, который свидетельствует нам о реальной ошибке: клиент снес счетчик Google Analytics, который был установлен в коде сайта, и за последние 5 часов не было ни одной сессии. Ошибка была выявлена в сжатые сроки, потеря данных –минимальная. Не имея такого автоматизированного мониторинга, понять в сжатые сроки, что клиент снес счетчик, – большая удача. Без системы оповещений мы узнали бы об этом в лучшем случае через пару дней, в худшем – в конце месяца.

Но, во-первых, не всегда такой alert свидетельствовал об ошибках, а, во-вторых, мониторинг не учитывал серьезные факторы, которые вели к отклонениям от нормы в меньшую сторону – сезонность, снижение рекламных бюджетов и т.д., и всё равно присылал alert, что через какое-то время изрядно замылило глаз и реагировать на них становилось все сложнее. Пример такой alert зафиксирован ниже:

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

Принудительное отключение – хорошо, но кто уведомит аналитика о том, что РК опять запущены? С одной стороны, при полученном уведомлении неплохо перестраховаться и уточнить у менеджера – точно ли отключили рекламу. Но постоянно по несколько раз в день по десяткам клиентов тратить время на подобного рода вопросы очень трудозатратно. К тому же это утяжеляет цепочку коммуникации, а наша задача состоит все-таки в упрощении работы между всеми участниками проектной группы – выносить на обсуждения уже способы решения выявленных проблем.

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

Итак, в результате первого запущенного мониторинга мы точно знали его плюсы, и, главное, минусы, поэтому в следующей системе мониторинга учли такие моменты:

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

2. Диапазон значений должен быть не средним, а гибким, основанным на ретроспективных данных;

3. Уведомления не должны приходить, если реклама была отключена в плановом режиме;

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

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

Дополнительные:

6. Диапазон значений должен учитывать факторы (сезонность, день недели и т.д.);

7. Мониторинг не должен уведомлять только об ошибках, основанных на отрицательных значениях (ниже нормы).

8. Мониторинг должен уведомлять об аномалиях трафика, и не важно, отклонения были в большую или меньшую сторону;

9. Должна быть динамика и предиктивный шаг;

10. Удобный интерфейс системы мониторинга.

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

Выводы

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

• Если вам необходимо подготовить простой и базовый инструмент для небольшого объема данных и для небольшого среза параметров по выявлению ошибок и/или аномалий в трафике – такой вариант вам подойдет и будет служить прекрасной основой;

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