Как создать гибкий шаблон для наглядной статистики и автоматизировать отчетность для всех участников проекта

< >

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

Исходная ситуация

На каждом проекте наши специалисты сталкивались с разными форматами отчетности: дашборд в Data Studio, кастомный отчет Google ***ytics, документ в Google Spreadsheets или комментарий о результатах за месяц в личном кабинете (ЛК).

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

Больше об ЛК вы найдёте в таких постах:

1. Личный кабинет клиента Netpeak 2.0
2. Дополнительные ценности Netpeak

Какие проблемы это вызывало

1. У project-менеджеров, тимлидов и функциональных руководителей не было быстрого доступа к результатам по проектам, так как вся информация в том или ином виде находилась в разных местах.
2. У project-менеджеров, руководителей и клиентов не было понимания результативности, поскольку в используемых отчетах не было процента достижения плановых показателей. 1000 лидов ; это хорошо или плохо? Зависит от того, какое целевое значение.
3. Поскольку отчеты от проекта к проекту имели разный формат, детализацию и внешний вид ; это приводило к сложностям в работе. Например, чтобы проанализировать ситуацию, тимлиду нужно было вникать в особенности разных отчетов по каждому проекту из портфеля. Это лишние затраты времени.
4. На проектах, где использовались Google Таблицы, зачастую отчетность заполнялась вручную или наполовину вручную. Это нeблагодарная работа, чреватая ошибками и отнимающая время, которое лучше потратить на усиление результатов по проекту.
5. Когда мы переставали работать с проектом, терялась полезная статистика.
6. Несмотря на огромный портфель проектов, не было возможности анализировать сводные данные по портфелю.

Требования к новому решению

Оно должно быть удобным, красивым, гибким и автоматизированным. А именно:

1. Минимум ручной работы после настройки.
2. Простая настройка сбора данных и визуализации. Интернет-маркетолог, не специализирующийся на веб-аналитике может сделать это без освоения новых технологий ;  программирования на R или Python. 
3. При необходимости ; возможность видеть план/факт.
4. Гибкость: возможность кастомизировать отчет под нужды конкретного проекта. Убрать ненужные показатели или добавить нужные. 
5. Простота дизайна. Отчет не перегружен метриками и диаграммами и не выглядит, как контрольная работа студента, изучающего работу Power Bi или Data Studio.
6. Последовательный дизайн. Несмотря на некоторую кастомизацию, отчеты должны быть в едином стиле и выглядеть, аккуратно и красиво.

Итоговое решение 

Сформировали такую цепочку:

Статистика рекламных кабинетов + статистика Google ***ytics ; база Big Query ; отчет в Data Studio

Итоговое решение работает и состоит из таких сущностей:

Справочник проектов в Google Таблицах

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

1. Указывать, по каким аккаунтам собирать данные.

2. Видеть, из какого представления Google ***ytics собирать данные.

3. Понимать, какие цели в Google ***ytics считаются ключевыми (по номерам).

4. Указывать, в какой валюте должен быть отчет. 

5. Понимать, делать ли конвертацию валюты дохода из модуля электронной торговли.

Интернет-маркетолог при старте нового проекта добавляет в справочник новую строку и заполняет соответствующие поля. Это понятные всем Google Таблицы, и сложности с этим не возникает. 

6. Основная база Big Query. Здесь собираются рекламные показатели (клики, показы, расходы) из указанных в Справочнике проектов аккаунтов.

7. База Big Query с данными кабинетов Google Ads. Со временем у нас возникла необходимость собирать и выводить статистику по конверсиям на основании тега конверсии Google Ads, а не целей и транзакций Google ***ytics. Поэтому мы собираем эти данные в отдельной базе:

Ценность этой базы в том, что мы можем выводить в отчете конверсии по показам, кросс-девайсные конверсии и конверсии по модели data-driven.

8. База Big Query c данными кабинетов Facebook Ads. Глупо оценивать результативность Facebook кампаний только по Google ***ytics (обрыв меток, кросс-девайсность пользователей, разные модели атрибуции). 

Есть такие типы кампаний, которые не приводят к сеансам на сайте (лидформы, мероприятия, видеокампании, вовлечение). Поэтому нужно собирать данные из Facebook-аккаунтов напрямую, в том числе, с разными окнами атрибуции:

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

В этой же Google Таблице можно записывать текстовые комментарии, привязанные к определенному месяцу:

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

Механизм

1. Расходы, клики и показы из рекламных кабинетов напрямую собираются R-скриптом для всех проектов агентства в единую базу в Big Query. Таким образом, учитываются все типы кампаний. Точность парсинга данных о расходах, кликах и показах выше, чем при использовании сервисов стриминга данных в Google ***ytics вроде Owox или Renta, поскольку нет лишней прокладки в виде Google ***ytics.
2. Данные о поведении на сайте (сеансы, транзакции, нужные конверсии  и доход) собирает R-скрипт из Google ***ytics. 
3. Объединение точных расходов из рекламных кабинетов и данных о поведении из Google ***ytics происходит по ID кампании. Если ID кампании не будет передан в utm_campaign корректно, то данные по расходам и поведению на сайте не сойдутся, а PPC-специалист автоматически получает задачу на исправление UTM-метки. Поэтому важно четкое следование установленным правилам нейминга и разметки объявлений.

Данные по Google Ads подтягиваются из Google ***ytics. Поэтому для Google Ads не нужна UTM-метка и достаточно gclid.

1. Импорт в Big Query происходит еженедельно по понедельникам за прошлую неделю в разрезе отдельных дней. Такой частоты обновления достаточно, так как решение не для оперативного отчета и мониторинга, а для еженедельной/ежемecячной отчетности.
2. Визуализация происходит на базе разработанного шаблона отчета в Google Data Studio,  который подключен к общей базе Big Query. Подключение ;; при помощи стандартного коннектора Big Query с использованием пользовательского запроса (custom query), в котором указано, по какому конкретно проекту нужно отображать данные:

У пользователя отчета нет доступа к статистике других проектов из Big Query.

1. Возможности отчета:

• Благодаря функционалу объединения данных (data blending) в отчете есть отображение выполнения плановых показателей в % на сегодня. Плановые показатели берутся из отдельного документа. Интернет-маркетолог заполняет в начале месяца в рамках регулярной задачи.
• В шаблонном отчете подготовлены базовые таблицы и диаграммы, выведены основные показатели. Но благодаря тому, что с Data Studio работать достаточно просто, интернет-маркетолог может кастомизировать уже имеющийся шаблон. Например, подключить таблицу с данными из Facebook-кабинета с нужными показателями.
• В отчете есть возможность отображать комментарии для клиента по итогам месяца, которые маркетолог обычно пишет в нашем Личном Кабинете. Специалист вносит комментарии в документ плановых показателей

Какие проблемы возникли в процессе

1. Точность расходов и независимость от Owox и других подобных сервисов требует сопоставления по ID кампании. Соответственно, если какая-то кампания размечена некорректно, то в базе не будет поведенческих данных по этой кампании.
2. Скрипт сбора данных может отработать неправильно:

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

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

В итоге мы решили обложить тестами почти все известные нам после первых месяцев работы возможные ошибки. Получилось около 15 различных проверок:

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

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

Любимой функцией стала возможность в чате давать комaнду боту на пересбор по нужным проектам и генерировать токен для Яндекс.Директа:

1. У Netpeak очень много клиентов в Казахстане. Многие приходят в агентство с уже внедренным модулем электронной торговли, в котором доход передается без указания currency code при отправке транзакции. Поскольку Google ***ytics поддерживает не все валюты, в частности, в настройках валюты представления нет тенге, то представления чаще всего в долларах США. В результате, в Google ***ytics видим правильные расходы в долларах США и многомиллионные, не конвертированные в доллар, доходы в тенге.

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

Из какой валюты и в какую конвертировать, определяется на основании указанной в справочнике проектов реальной валюты дохода в e-commerce. На этом примере:

Мы сообщаем скрипту, что доход у нас на самом деле приходит в тенге, и мы хотим его конвертировать в доллар США, и вообще все показатели, связанные с деньгами, конвертировать в отчете в USD.

Что сейчас

1. База работает стабильно, собирает данные, которым можно доверять. Мы можем удобно анализировать статистику по всем проектам портфеля:

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

Что дальше

1. Обновить логику сбора данных в таблицу Facebook и Google Ads таким образом, чтобы перезаписывать старые данные (более 28 дней назад). Это позволит учитывать конверсии, которые произошли спустя N количество дней после клика, и не попали в базу, собирающую статистику недельными отрезками.
2. Внедрить отдельные базы для Яндекс. Директ и MyTarget. Ценности от этого меньше, чем от баз Google Ads и Facebook, но все равно пригодятся.
3. Возможно, перейдем на ежедневный график обновления данных. Система контроля ошибок уже есть.
4. Разметить проекты по тематикам, чтобы видеть тренды в той ли иной отрасли.

Комaнда

• Алексей Селезнев, Head of ***ytics Department, сумрачный гений аналитики Netpeak.
• Алекс Айчеу, PPC Team Lead, надоедливый product owner этой истории.

Благодарим за помощь в подготовке статьи Андрея Коваля!