Как мы строим сквозную маркетинговую аналитику

Мы строим аналитические космолёты aka «маркетинговые DWH» уже около 7 лет очень известным и любимым потребителями компаниям. И тут один интересант нас попросил: опишите, пожалуйста, кейс как вы это делаете. А я даже не знаю, что можно писать про такое. Я взял и написал, что мог за полчаса. Не могу понять, кому-то вообще такое интересно?

Аналитика в цифровом маркетинге строится на 3 больших кусках:
— хранилище расходов aka косты Берём по API данные по дням или делаем инструмент для ручной загрузки, если эти данные нельзя выгрузить (например, по рекламе в чужом контенте). Дальше эти данные могут быть разложены в любой временной интервал

— хранилище данных о пользователях и их заказах/заявках/звонках/прочих полезных бизнесу действий (тут не знаю какой aka) и разных сущностях, например, географии Здесь строится вокруг внутреннего айди пользователя или номера телефона. Если авторизация проходит по номеру телефона, то это великолепно позволяет связывать воедино сайт и приложение с КЦ. Все заказы, звонки, заявки складываются в этот айди и можно построить аналитику не по заказам в финансовой логике, а по людям (что важнее)

— хранилище атрибуций aka сорсы Самый сложный момент здесь — это понять, когда пользователь становится пользователем. Часть бизнесов считает, что во время первого заказа. И можно было бы это засчитать за утверждение, если бы пользователи не попадали в брендовый поиск или ретаргетинг, которые правильно считать не каналами привлечения, а «сервисными» для сохранения «прогретых» пользователей. В целом не так важно, какое событие для методологии подсчета пользователей мы выберем, важно, собрать все предшествующие этому визиты для веба. И в этом случае мы в построении отчетов можем исключить все сервисные каналы и посмотреть, кто или что привело пользователя к целевому действию или первый раз на сайт

Когда эти 3 куска объединяются складывается т.н. сквозная аналитика. Она позволяет посмотреть, например, - сколько рекламное объявление привело денег, а не куки-файлов или установок
- рассмотреть как один канал, считающийся убыточным, на самом деле работает в плюс для бизнеса
- ответить на вопрос Генерального Директора: «Вот у нас там в мае пользователей был горбик относительно линии. Это всё потому что мы использовали ту мою гениальную идею кислотного креатива или кто-то чихнул рядом с дата-центром?»

Мы считаем, что первична работа с данными. Но мы не уважаем «программистский» подход, поэтому помогаем строить на основе этих данных дашборды. Наши аналитические космолёты — это хранилища данных, которые уже превращены или их можно превратить в сводные таблицы внутри BI-инструментов, а потом с помощью них нарисовать красивые кругляшки и графички.

Наш «продукт» — это не SaaS-решения. Если вы хотите за небольшие деньги получить и интегрировать их со своей административной панелью (CMS), то это великолепный путь, чтобы начать путь в сквозной аналитике. У всякого рода Rickов и RoiStatов (и даже вроде уже у Яндекс Метрики) есть готовые решения и связка сервисов займет у вас минуты. Но местами эти сервисы хромают на 2 ноги в скорости, большие таблицы раскаляют докрасна ваш ПК, интерфейсы как на уроке по информатике из 90х. А ещё они слабо покрывают случаи, когда вы выходите чуть дальше базового функционала. А если у вас есть мобильное приложение, то они вам и вовсе не помогут.

Наши решения подстраиваются под задачи пользователей. Часто грандиозные планы на космолёт на первой встрече заменяются всего лишь несколькими гугл-таблицами. И для небольших команд и малых по объему бизнесов — это временное решение становится постоянным. Да, люди иногда действительно не хотят переезжать, потому что их «устраивает», а не потому что нет денег :) Например, это будет актуально для бизнесов с очень коротким циклом принятия решения. А для бизнесов с долгим принятием решения может сэкономить деньги, потому что т.н. сквозная аналитика в этом деле не работает и не сработает, работает «достаточность» этих отчетов. Скорее всего наши космолёты не будут нужны и тем, у кого количество покупок измеряется как «одна в пять лет».

В целом успех в быстроте строительства нашего решения находится внутри бизнеса заказчика. С одной стороны нужно, чтобы данные о заказах, собирались и обогащались. С другой стороны при работе с чатом и КЦ важна простановка статусов заказов и чеклисты. Именно тогда, а не потому что у нас люди МГУ закончили, мы сможем отделить дубли от реально новых заказов. И понять, привлекает ли чат клиентов, или пора его всё-таки отдать в баловство для ИИ. Здесь мы иногда вовлекаемся и пытаемся навести порядок: когда-то успешно, когда-то нет.

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

Кайфом в нашем решении большом или упрощенном становится то, что у вас больше нет:
— файлов «аналитика-презентация(1).xlsx(1).xslx»
— захламленной папки загрузки с еще более страшными названиями — ВПР-а, который ломается на маке
А у вас есть: — закреп с несколькими ссылками, куда можно отослать или привести за собой любимого коллегу — прозрачность — порядок, а вместе с ним почёт и уважение коллег (мало ли вам это нужно)

И ведь вроде не рокетсайенс же, да?