{"id":14271,"url":"\/distributions\/14271\/click?bit=1&hash=51917511656265921c5b13ff3eb9d4e048e0aaeb67fc3977400bb43652cdbd32","title":"\u0420\u0435\u0434\u0430\u043a\u0442\u043e\u0440 \u043d\u0430\u0442\u0438\u0432\u043e\u043a \u0438 \u0441\u043f\u0435\u0446\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 vc.ru \u2014 \u043d\u0430\u0439\u0434\u0438\u0441\u044c!","buttonText":"","imageUuid":""}

Почему в Google Analytics не построить аналитику с корректными данными, и как решили эту проблему в компании «Вилгуд»

Кейс пишется совместно с компанией R7K12 о том, как устроена аналитика в компании «Вилгуд», и как построить сквозную аналитику для b2b и b2c.

"Деньги любят счёт", а бизнес — контроль

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

«Нужен инструмент анализа эффективности вложений в рекламу!»

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

Компания завоевала на рынке услуг по ремонту автомобилей лидирующие позиции. Оборот компании составляет более 950 000 000 рублей за год. На момент написания кейса открыто 88 СТО Вилгуд по всей России.

На данный момент у интернет-представительства компании:

  • более 80 000 000 показов в месяц в рекламных сетях;
  • более 500 000 баннеров;
  • более 250 000 посетителей в месяц;
  • более 26 600 страниц на сайте;
  • более 6 000 посещений в день
  • более 2 000 рекламных кампаний;
  • более 170 источников трафика;
  • более 150 рекламных аккаунтов;
  • более 50 посетителей одновременно (в секунду);
  • более 18 ГБ размер хранилища данных.

Компания совместила два направления бизнеса: B2C (бизнес для потребителя) и B2B (бизнес для бизнеса). Это проекты «ВилГуд» (wilgood.ru) и «ВилГуд Франшиза» (franchise.wilgood.ru) — система развития автосервиса или создания автосервиса «с нуля». Для каждого из проектов подключен сервис сквозной аналитики «R7K12».

Компания использует такие инструменты для аналитики и контроля состояния бизнеса:

  • CRM система: 1С.
  • Сквозная аналитика: R7K12.
  • Система коллтрекинга: CoMagic.
  • Инструмент для обработки больших объёмов данных: Google BigQuery.
  • Инструмент для компоновки графиков и визуализации отчетов: Power BI и R.
  • Рекламные системы: Яндекс. Директ, Google AdWords, Facebook, Вконтакте.
  • СМС оповещения: Telegram.

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

Почему в Google Analytics не построить аналитику с корректными данными?

До подключения сервиса сквозной аналитики R7K12, построенная на базе Google Analytics, аналитика выглядела так:

Импорт расходов осуществлялся через сервис MixData.ru. Отправка данных происходила с помощью API.

Проблема №1. Квоты и ограничения API Google Analytics

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

  • Не более 50 загрузок в день на один ресурс.
  • 100 МБ на загрузку в день на конкретную дату. В это мы очень часто упирались. Потому что, если загружаем сегодня данные за вчера, то сегодня можем загрузить не более 100 МБ данных. Если же их больше 100 МБ, то завтра нужно будет продолжить.
  • 10 ГБ на ресурс. Например, сейчас у Вилгуда ~ 150-200 МБ данных в день. За неделю они с легкостью наберут 1 ГБ, за 10 недель — 10 ГБ.

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

Проблема № 2. Расхождения данных в 1С и Google Analytics

Если отправлять данные в Google Analytics в реальном времени, то между данными в 1С разница будет примерно в 40%. Почему? Для Вилгуд очень важно отделять первичные обращения пользователей. В чем возникала проблема построения отслеживания на базе Google Analytics?

Допустим, клиент зашел на сайт по рекламе Яндекс.Директ и позвонил. Определили, что его обращение является первичным. В течение дня может выясниться, что клиент уже ранее пользовался услугами сервиса, только записан в CRM под другим номером телефона. Следовательно, обращение больше не является первичным. Если бы отправка событий в аналитикс была моментальной, мы получаем такую ситуацию: обращение отправлено в Google Analytics как первичное, а по факту таким уже не является.

Получается, что если отправка в Google Analytics идет в реальном времени (real-time), то количество первичных обращений на вечер в 1С меньше, чем в Google Analytics. Данные не сходятся. Плюс приходится отправлять раз в 15 минут, чтобы данные попали в текущую сессию.

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

Проиграем ситуацию заново: клиент зашел на сайт по рекламе Яндекс.Директ и позвонил. Определили, что его обращение является первичным. В течение дня выясняется, что клиент уже ранее пользовался услугами сервиса, только записан в CRM под другим номером телефона. Отправка событий происходит у нас вечером, например, в 23:30 для пущей уверенности. Обращение больше не является первичным, следовательно в Google Analytics мы не отправляем его как первичное обращение. А если обращение все же действительно первичное?

Происходило следующее. Для компании характерна такая цепочка взаимодействия с клиентами: Яндекс.Директ > Google SEO (или Google AdWords). После того, как клиент перешел с рекламы Яндекс.Директ и оставил обращение, через какое-то время он искал сайт в поиске Google. И переходил на сайт снова с рекламы Google AdWords или органической выдачи.

И если данные в Google Analytics отправлять не моментально, то последнему непрямому источнику присваивается конверсия. В нашем случае конверсия присваивается Google SEO, хотя обращение оставил клиент после перехода с рекламы Яндекс.

Получалась некорректная статистика и в первом и во втором вариантах.

Проблема №3. Нет возможности посмотреть цели и расходы по всем параметрам

Да, расходы по кампаниям и ключевым словам мы можем посмотреть в Google Analytics. А расходы в разрезе городов? У компании Вилгуд СТО находятся по всей России! Как узнать, с какого города был визит, заявка, продажа и во сколько она обошлась нам? Такую возможность сама архитектура данных Google Analytics не предоставляет.

Также нельзя посмотреть, была ли заявка и/или продажа, и сколько на нее было потрачено денег с какой-либо рекламной сети или кампании в одном отчете! Чтобы что-то улучшить, нужно знать, что менять. Как управлять рекламным бюджетом в этом случае?

Были попытки сделать панель визуализаций с помощью Microsoft Power BI, выгружать данные из Яндекс.Директа, Google AdWords, Вконтакте, Facebook напрямую. Об этом в следующем пункте.

Проблема №4. Язык R и Power BI не тянут большое количество данных

Power BI предоставляет возможность интегрировать данные напрямую со всех необходимых нам источников (Google Analytics, Facebook, R-скрипт). Но есть ограничение — не более 100 000 строк для таблицы. Из опыта стало ясно, что этот инструмент работает лучше всего с уже сгруппированными данными.

С помощью R-скрипта была попытка собрать данные из API Яндекс.Директа по 100 аккаунтам. Она не увенчалась успехом, так как R-скрипт такое количество не тянет — виснет и падает соединение на 30-м аккаунте. И это загружались данные только по расходу. Плюс к этому нужен был коннект к Google AdWords, Facebook и т.д.

В итоге в панели Power BI можно было посмотреть разве что расход по аккаунту. И не видно было, по каким источникам были первичные обращения, а по каким их не было. По каким кампаниям были первичные обращения, по каким продажи? Если смотреть в Google Analytics — там они на другие источники (смотреть проблему №3).

И не было единой системы, где можно это наглядно увидеть. Вывод был ясен: нужен сервис сквозной аналитика.

Как же устроена сейчас аналитика компании для проектов «Вилгуд» и «ВилГуд Франшиза»?

Все вышеперечисленные проблемы, как и предполагалось, решились с подключением сервиса сквозной аналитики. Компания Вилгуд использует систему «R7K12».

Система сквозной аналитики собирает все данные воедино с CRM, рекламных систем (расходы, показы, клики), ловцов лидов, систем коллтрекинга, email-трекинга, сервиса обратного звонка, конструкторов сайтов. Все эти данные можно увидеть в интерфейсе сервиса сквозной аналитики, построив отчеты любых вложенностей. Также можно загрузить их в Google BigQuery для построения еще более гибких запросов и создания визуализаций на их основе.

В «R7K12» есть готовые интеграции на выгрузку расхода с таких рекламных систем: Яндекс.Директ, Google AdWords, Facebook, Вконтакте, Яндекс.Маркет, myTarget.

В системе также есть ряд готовых интеграций для отслеживания данных с ловцов лидов. Используемые интеграции этого вида с систем: Facebook Lead Ads и VK Lead Ads.

В R7K12 интеграция с используемым коллтрекингом настраивается в пару кликов.

В логе заявок в R7K12 можно увидеть все обращения в компанию в реальном времени: дату и время, имя, номер телефона (если это звонок или оставили номер телефона через форму), другие контактные данные, тип обращения.

Импорт расхода

Со всех рекламных сетей расход (а также клики и показы) загружается напрямую в R7K12. Интеграции создаются в несколько кликов в интерфейсе системы. Там же можно посмотреть очередь загрузки по датам и процент расхождения в данных.

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

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

Расход с рекламных систем в Google Analytics не импортируется. В этом теперь нет надобности.

Учет конверсий и продаж

Компания Вилгуд в качестве CRM использует 1С. Помимо заявок, большая часть обращений на сайт — звонки. Данные из CoMagic загружаются в 1С с помощью API.

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

Это как раз решение проблемы, которую мы описывали в пункте №2: если обращение оказывается не первичным. Тогда в CRM системе этой сделке меняют статус на “повторное обращение”. Примерно каждые 15 минут R7K12 синхронизируется 1С1С, и в итоге происходит перераспределение статусов в аналитике. Эта заявка “уходит” из столбца “Первичные обращения” в соответствующий столбец. Таким образом в системе сквозной аналитики можно наблюдать живые и точные данные по целевым заявкам и продажам.

Google BigQuery

В R7K12 есть интеграция с Google BigQuery. Все собранные данные в системе сквозной аналитике могут передаваться в BigQuery, где можно построить гибкие запросы к данным для аналитики. Вторым важным моментом в использовании данной интеграции является то, что с помощью R7K12, Google BigQuery, скрипта R и Power BI созданы панели визуализаций статистики с автоматическим ежедневным обновлением данных.

Визуализации Power BI

На данный момент прямой коннектор Google BigQuery в программном интерфейсе Microsoft Power BI в стадии разработки. Поэтому коннект построили с использованием скрипта R.

Вся статистика собирается воедино в системе R7K12, а часть необходимых данных для визуализаций передается в Google BigQuery. Затем с помощью R коннектора и SQL запросов, из Google BigQuery поступают данные в Power BI.

Пример панели визуализации Microsoft Power BI (из соображений конфиденциальности мы не можем показать аналогичную панель для проекта wilgood.ru):

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

0
17 комментариев
Написать комментарий...
Maxim Zelensky

"Но есть ограничение — не более 100 000 строк для таблицы." - а переведите это высказывание. Если речь идет о визуальном элементе "таблица", то зачем вам в Power BI (!!!) 100.000 строк? Или речь о другом?

Ответить
Развернуть ветку
Олег Басманов

то ли тянули напрямую без промежуточной бд, то ли что... я миллионами тяну из bq и нормально

Ответить
Развернуть ветку
Vladislav Volyansky

Если у вас на сайте 100 000 сеансов, то таблица с сеансами будет содержать 100 000 строк. Если больше - Power BI уже не тянет.

Ответить
Развернуть ветку
Maxim Zelensky

Я понимаю, если бы написали, что не тянет при помощи R-скрипта, так как на R-скрипты *для визуальных элементов* как раз в PBI есть ограничения (и я не уверен, что это тот случай). Но вообще для Power BI 100.000 строк - это тьфу, ни о чём.

Ответить
Развернуть ветку
Олег Басманов

Начало хорошее, а вот дальше ощущение заказухи с целью рекламы R7K12.
Вот например: "С помощью R-скрипта была попытка собрать данные из API Яндекс.Директа по 100 аккаунтам. Она не увенчалась успехом"
Скрипт значит не смог, а R7K12 смог. Как так? API для всех одно. Или вы скрипт вызывали из PowerBI и каждый раз из всех аккаунтов тянули все данные за весь период? Тогда неудивительно что вылетали по лимитам

Ответить
Развернуть ветку
Евгений Макаров

Очередная пропаганда всякой херни за деньги. R и Phyton могут все. BQ тоже не панацея тем более опять за деньги. Что мешает поднять все тоже самое без денег? )

Ответить
Развернуть ветку
Олег Басманов

ну BQ многие предпочитают чтобы не заморачиваться с администрированием собственной базы. Если это не проблема - то конечно все еще проще. А так согласен - R7K12 при наличии R/Python, не нужен

Ответить
Развернуть ветку
Евгений Макаров

Не хочу быть банальным но ClickHouse решает. Есть образы - раскатываешь на любом хостинге и вперед. Факт в том что расход прогнозируем -а в BQ часто нельзя предсказать расходы.

Ответить
Развернуть ветку
Дима Волотович

Добрый день. как с вами связаться? Есть интересная задача по консолидации больших данных и их анализа.

Ответить
Развернуть ветку
Евгений Макаров

+79036750671 лучше телеграм

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Vladislav Volyansky

Супер, я бы ещё посоветовал использовать Funnel-Based модель атрибуции для полноты данных. Рекомендую для этого сервис на букву О, но не буду его пиарить.

Ответить
Развернуть ветку
Yaroslav Biryukov

В статье есть неточности касаемо лимитов Google Analytics (https://support.google.com/analytics/answer/6016094?hl=ru) на загрузку данных о расходах.
1. Лимит 90МБ на дату. И он касается именно даты к которой относятся расходы, но никак на количество данных загруженных за день.
2. Не совсем ясно, где вы взяли лимит в 10ГБ на ресурс.

Ответить
Развернуть ветку
Dmitry Tumaykin

Добрый день!
Касательно лимитов:
На момент принятия решения о необходимости нового сервиса (r7k12) в Google Analytics, в частности в Analytics API, последней доступной версией была v2. В ней как раз были ограничения, описанные в статье:

1. Лимит 100 МБ на дату (из версии v2). Верно, этот лимит касается даты, к которой относятся расходы. И именно в него мы упирались: за один день на одну дату статистики часто не могли загрузить расходы. Поэтому на следующий день приходилось догружать данные за эту дату.

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

2. Стандартные ограничения (из версии v2):
10 Гб за ресурс
10 ГБ на набор данных

Если бы на данный момент с новой версией API мы выгружали данные в Google Analytics, мы также упирались бы в квоты.
Посмотреть ограничения v2 можно по данной ссылке:
https://developers.google.com/analytics/devguides/config/mgmt/v2/limits-quotas?hl=ru#data_import

Ответить
Развернуть ветку
Махметхажиев Алексей

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Alexey Laptev

А как у вас моделями атрибуции? Мы в https://utmstat.com/business-intelligence фиксируем first_click и last_click источник для целей и заявок в CRM, что дает более полную картину эффективности рекламных каналов.

Ответить
Развернуть ветку
Сергей Положай

1

Ответить
Развернуть ветку
Дмитрий Карпушин

Думал, что сейчас будет интересная статья с подробностями и скринами, но нет.

Согласен и с основным посылом написанного - не стоит использовать Google Analytics для сквозной аналитики (на этот счет есть хорошие доклады Ильи Красинского).
Согласен с Олегом Басмановым, что статья больше похожа на рекламу сервиса.

Вы проделали большую работу по настройке аналитики это точно.

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

Спасибо

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
14 комментариев
Раскрывать всегда