Как создать гибкий шаблон для наглядной статистики и автоматизировать отчетность для всех участников проекта
Мы уже делились информацией о том, как построена работа нашего департамента контекстной рекламы — показывали насколько структурирован и организован процесс. Сегодня расскажем, как стандартизировали сбор данных по проектам клиентов и отчетности. Процесс упростили и теперь тратим на него меньше времени, не совершаем лишние действия, поэтому хотим поделиться, как этого достигли, и рассказать, на какие грабли наступили в процессе.
Исходная ситуация
На каждом проекте наши специалисты сталкивались с разными форматами отчетности: дашборд в Data Studio, кастомный отчет Google Analytics, документ в Google Spreadsheets или комментарий о результатах за месяц в личном кабинете (ЛК).
ЛК — разработка агентства, которая помогает клиентам видеть все действия по своему проекту. Существует также бот в Telegram, который выводит необходимую информацию в мессенджер.
Больше об ЛК вы найдёте в таких постах:
Какие проблемы это вызывало
- У project-менеджеров, тимлидов и функциональных руководителей не было быстрого доступа к результатам по проектам, так как вся информация в том или ином виде находилась в разных местах.
- У project-менеджеров, руководителей и клиентов не было понимания результативности, поскольку в используемых отчетах не было процента достижения плановых показателей. 1000 лидов ; это хорошо или плохо? Зависит от того, какое целевое значение.
- Поскольку отчеты от проекта к проекту имели разный формат, детализацию и внешний вид ; это приводило к сложностям в работе. Например, чтобы проанализировать ситуацию, тимлиду нужно было вникать в особенности разных отчетов по каждому проекту из портфеля. Это лишние затраты времени.
- На проектах, где использовались Google Таблицы, зачастую отчетность заполнялась вручную или наполовину вручную. Это неблагодарная работа, чреватая ошибками и отнимающая время, которое лучше потратить на усиление результатов по проекту.
- Когда мы переставали работать с проектом, терялась полезная статистика.
- Несмотря на огромный портфель проектов, не было возможности анализировать сводные данные по портфелю.
Требования к новому решению
Оно должно быть удобным, красивым, гибким и автоматизированным. А именно:
- Минимум ручной работы после настройки.
- Простая настройка сбора данных и визуализации. Интернет-маркетолог, не специализирующийся на веб-аналитике может сделать это без освоения новых технологий ; программирования на R или Python.
- При необходимости ; возможность видеть план/факт.
- Гибкость: возможность кастомизировать отчет под нужды конкретного проекта. Убрать ненужные показатели или добавить нужные.
- Простота дизайна. Отчет не перегружен метриками и диаграммами и не выглядит, как контрольная работа студента, изучающего работу Power Bi или Data Studio.
- Последовательный дизайн. Несмотря на некоторую кастомизацию, отчеты должны быть в едином стиле и выглядеть, аккуратно и красиво.
Итоговое решение
Сформировали такую цепочку:
Статистика рекламных кабинетов + статистика Google Analytics ; база Big Query ; отчет в Data Studio
Итоговое решение работает и состоит из таких сущностей:
Справочник проектов в Google Таблицах
Это основной интерфейс настройки нужных параметров сбора данных, который позволяет решать такие задачи:
- Указывать, по каким аккаунтам собирать данные.
2. Видеть, из какого представления Google Analytics собирать данные.
3. Понимать, какие цели в Google Analytics считаются ключевыми (по номерам).
4. Указывать, в какой валюте должен быть отчет.
5. Понимать, делать ли конвертацию валюты дохода из модуля электронной торговли.
Интернет-маркетолог при старте нового проекта добавляет в справочник новую строку и заполняет соответствующие поля. Это понятные всем Google Таблицы, и сложности с этим не возникает.
6. Основная база Big Query. Здесь собираются рекламные показатели (клики, показы, расходы) из указанных в Справочнике проектов аккаунтов.
7. База Big Query с данными кабинетов Google Ads. Со временем у нас возникла необходимость собирать и выводить статистику по конверсиям на основании тега конверсии Google Ads, а не целей и транзакций Google Analytics. Поэтому мы собираем эти данные в отдельной базе:
Ценность этой базы в том, что мы можем выводить в отчете конверсии по показам, кросс-девайсные конверсии и конверсии по модели data-driven.
8. База Big Query c данными кабинетов Facebook Ads. Глупо оценивать результативность Facebook кампаний только по Google Analytics (обрыв меток, кросс-девайсность пользователей, разные модели атрибуции).
Есть такие типы кампаний, которые не приводят к сеансам на сайте (лидформы, мероприятия, видеокампании, вовлечение). Поэтому нужно собирать данные из Facebook-аккаунтов напрямую, в том числе, с разными окнами атрибуции:
9. Google Таблица плановых показателей и комментариев. Если есть необходимость выводить в отчете сравнение плана с фактом, то интернет-маркетолог заполняет плановые показатели в документе, который создается для каждого проекта:
В этой же Google Таблице можно записывать текстовые комментарии, привязанные к определенному месяцу:
Клиенту не всегда понятно, как трактовать данные графиков в отчете. Текстовый комментарий, привязанный к выбранному в отчете периоду, позволит понять смысл за цифрами:
Механизм
- Расходы, клики и показы из рекламных кабинетов напрямую собираются R-скриптом для всех проектов агентства в единую базу в Big Query. Таким образом, учитываются все типы кампаний. Точность парсинга данных о расходах, кликах и показах выше, чем при использовании сервисов стриминга данных в Google Analytics вроде Owox или Renta, поскольку нет лишней прокладки в виде Google Analytics.
- Данные о поведении на сайте (сеансы, транзакции, нужные конверсии и доход) собирает R-скрипт из Google Analytics.
- Объединение точных расходов из рекламных кабинетов и данных о поведении из Google Analytics происходит по ID кампании. Если ID кампании не будет передан в utm_campaign корректно, то данные по расходам и поведению на сайте не сойдутся, а PPC-специалист автоматически получает задачу на исправление UTM-метки. Поэтому важно четкое следование установленным правилам нейминга и разметки объявлений.
Данные по Google Ads подтягиваются из Google Analytics. Поэтому для Google Ads не нужна UTM-метка и достаточно gclid.
- Импорт в Big Query происходит еженедельно по понедельникам за прошлую неделю в разрезе отдельных дней. Такой частоты обновления достаточно, так как решение не для оперативного отчета и мониторинга, а для еженедельной/ежемесячной отчетности.
- Визуализация происходит на базе разработанного шаблона отчета в Google Data Studio, который подключен к общей базе Big Query. Подключение ;; при помощи стандартного коннектора Big Query с использованием пользовательского запроса (custom query), в котором указано, по какому конкретно проекту нужно отображать данные:
У пользователя отчета нет доступа к статистике других проектов из Big Query.
- Возможности отчета:
- Благодаря функционалу объединения данных (data blending) в отчете есть отображение выполнения плановых показателей в % на сегодня. Плановые показатели берутся из отдельного документа. Интернет-маркетолог заполняет в начале месяца в рамках регулярной задачи.
- В шаблонном отчете подготовлены базовые таблицы и диаграммы, выведены основные показатели. Но благодаря тому, что с Data Studio работать достаточно просто, интернет-маркетолог может кастомизировать уже имеющийся шаблон. Например, подключить таблицу с данными из Facebook-кабинета с нужными показателями.
- В отчете есть возможность отображать комментарии для клиента по итогам месяца, которые маркетолог обычно пишет в нашем Личном Кабинете. Специалист вносит комментарии в документ плановых показателей
Какие проблемы возникли в процессе
- Точность расходов и независимость от Owox и других подобных сервисов требует сопоставления по ID кампании. Соответственно, если какая-то кампания размечена некорректно, то в базе не будет поведенческих данных по этой кампании.
- Скрипт сбора данных может отработать неправильно:
- собрать данные не из всех таблиц;
- может слететь токен аккаунта Яндекс. Директ или отключиться доступы к тому или иному аккаунту;
- сервер рекламной системы выдаст ошибку 500;
- будут ошибки при заполнении справочника проектов.
Несколько месяцев система работала и часто возникали несоответствия между статистикой в базе и статистикой из счетчиков и кабинетов. На отладку и поиск причин расхождения уходило много времени и сил. Доверие к системе у пользователей было подорвано.
В итоге мы решили обложить тестами почти все известные нам после первых месяцев работы возможные ошибки. Получилось около 15 различных проверок:
Мы создали специальный чат в Telegram, куда бот присылает все выявленные в процессе сбора данных. Вот эти ошибки:
Теперь мы можем сразу реагировать и переподтягивать данные после исправления ошибок.
Любимой функцией стала возможность в чате давать команду боту на пересбор по нужным проектам и генерировать токен для Яндекс.Директа:
- У Netpeak очень много клиентов в Казахстане. Многие приходят в агентство с уже внедренным модулем электронной торговли, в котором доход передается без указания currency code при отправке транзакции. Поскольку Google Analytics поддерживает не все валюты, в частности, в настройках валюты представления нет тенге, то представления чаще всего в долларах США. В результате, в Google Analytics видим правильные расходы в долларах США и многомиллионные, не конвертированные в доллар, доходы в тенге.
Разобраться с этим помогла функция, которая правильно конвертирует доход в нужную валюту.
Из какой валюты и в какую конвертировать, определяется на основании указанной в справочнике проектов реальной валюты дохода в e-commerce. На этом примере:
Мы сообщаем скрипту, что доход у нас на самом деле приходит в тенге, и мы хотим его конвертировать в доллар США, и вообще все показатели, связанные с деньгами, конвертировать в отчете в USD.
Что сейчас
- База работает стабильно, собирает данные, которым можно доверять. Мы можем удобно анализировать статистику по всем проектам портфеля:
2. Маркетологи получили шаблонную отчетность, которую легко кастомизировать под нужды проекта.
Что дальше
- Обновить логику сбора данных в таблицу Facebook и Google Ads таким образом, чтобы перезаписывать старые данные (более 28 дней назад). Это позволит учитывать конверсии, которые произошли спустя N количество дней после клика, и не попали в базу, собирающую статистику недельными отрезками.
- Внедрить отдельные базы для Яндекс. Директ и MyTarget. Ценности от этого меньше, чем от баз Google Ads и Facebook, но все равно пригодятся.
- Возможно, перейдем на ежедневный график обновления данных. Система контроля ошибок уже есть.
- Разметить проекты по тематикам, чтобы видеть тренды в той ли иной отрасли.
Команда
- Алексей Селезнев, Head of Analytics Department, сумрачный гений аналитики Netpeak.
- Алекс Айчеу, PPC Team Lead, надоедливый product owner этой истории.
Благодарим за помощь в подготовке статьи Андрея Коваля!
По теме
Диджитализация АТБ. Комплексный онлайн-маркетинг для лидера ритейла Украины — кейс
Рассказываем как выстроить комплексную диджитал-стратегию
Как улучшить оценку качества целевой страницы в Google Ads — эксперимент Netpeak
Можно ли повысить оценку качества целевой страницы , если проставить конечные URL на уровне ключевого слова? Результаты исследования.
Свежее
Как оптимизировать конверсии для страниц приложения в App Store и Google Play
Какие поля и параметры имеют больше значения и как выжать из них все
Как справляться с перегрузкой на работе — советы и действенные инструменты
В этой статье поделюсь лайфхаками, как наконец-то разобраться с входящим потоком задач и не выгореть от усталости
Как выйти на ROMI 5477,3% в первый месяц сотрудничества — кейс PUMA по email-маркетингу
И возобновить коммуникацию с клиентами после полугодовой паузы