Маркетинговая и продуктовая аналитика — вместе или по отдельности?
Содержание
Инструменты аналитики: выбор команды
При запросе "marketing analytics tool" Google выдаст вам 24 быстрых ссылки на страницы аналитических сервисов и точно столько же – для запроса "product analytics tool". Даже невооруженный взгляд подскажет, что некоторые из сервисов присутствуют в обоих списках. То есть Google считает содержимое некоторых страниц релевантным запросу – вне зависимости от того, ищете вы что-то для аналитики продукта или маркетинга. Солидарны ли с этим команды?
Далеко не всегда. Более того, ещё совсем недавно вполне рядовым считался примерно такой кейс:
- Команда перфоманс-маркетинга пользуется Google Analytics – поскольку большая часть закупок приходится на Google Ads. Кроме того, маркетологи привыкли работать с атрибуцией из этого приложения. А еще Google Analytics вроде как был всегда. И там много исторических данных.
- Менеджеры продуктов работают в Amplitude – там красивые и удобные отчеты для retention и работы с когортами. В Amplitude можно создавать сегменты по событиям и свойствам пользователей практически на лету. Ну и по отзывам пользовались им чуть ли не все стартапы.
- Дизайнеры и исследователи болеют за качественные исследования. Им важен живой, персонализированный фидбек. Поэтому они радеют за приложения, которые кроме собственно данных дадут записи сессий, опросы и квизы: Hotjar, Fullstory, SurveyMonkey.
- Команда роста (в случае, если она есть), конечно же, голосует за сервис, который позволит быстро проверять гипотезы – в том числе, с помощью контролируемых экспериментов и функций персонализации: Convert, Segment, VWO и другие.
В итоге в одном продукте может быть собрана солянка из 4-6 различных аналитических сервисов. У каждой из команд есть аргументы в пользу своего решения и все они выглядят, на первый взгляд, более чем разумными.
Но у этой медали (как и у всех остальных) есть оборотная сторона. Например, может вырасти нагрузка на разработку – поскольку им нужно будет настраивать интеграции и отправку одних и тех же событий в разные приложения. У разных сервисов будут разные требования по содержимому и способам отправки событий. Это обязательно нужно учитывать QA-команде во время тестирования и отладки. А еще бизнес-аналитики и проджекты должны учесть это в документации. И так далее.
В итоге создается большущее пространство для ошибки. Попробуем разобраться: стоит ли овчинка из подключения нескольких аналитических сервисов своей выделки. Или можно обойтись одним для того и другого?
Плюсы использования нескольких сервисов для аналитики продукта и маркетинга
- Каждая команда получает решение, адаптированное под ее задачи и KPI. SEO-специалист будет оценивать прирост органики в GA4 и вебмастер-сервисах, поскольку именно они являются для него первоисточниками. А еще тем, с помощью чего измеряют его (сеошника) эффективность. И весь фокус аналитического приложения, которое он использует, будет крутиться вокруг метрик и параметров органического поиска. Что крайне удобно. Крайне комфортная парадигма – не искать и формировать необходимый репорт или выгрузку, а получать все буквально сразу же, с главной страницы или дефолтного дашборда.
- Команда продукта или маркетинга выбирает приложение с фокусом на собственной экспертизе. Если для условной продакт-аналитики стандартом индустрии (пусть и с массой оговорок) является Amplitude, то тратить ресурсы на обучение и переключение контекста для другого приложения выглядит крайне сомнительной перспективой. Бизнесу как правило нужен результат, а не дискавери-процессы в сфере аналитических приложений.
- Снижается порог входа и адаптации новичков. В случае проведения AB-тестов логично отдавать преимущество тому кандидату, который знаком с текущей инфраструктурой и владеет оптом проведения экспериментов – скажем, в ABTasty или Optimizely. При таком раскладе растет вероятность того, что вновь принятый сотрудник начнет перформить с порога вместо долгого погружения в контекст работы конкретного приложения.
Но не все так гладко. У использования нескольких сервисов для продукта и маркетинга есть и свои (весьма жирные) минусы.
Минусы использования нескольких сервисов для аналитики продукта и маркетинга
- Раздутая документация. Необходимо хранить и регулярно обновлять базу знаний для нескольких приложений. Последние имеют привычку обновлять версии, документацию для API, интерфейс и прочее. Это выглядит особенно избыточно, когда команде нужно фиксировать, хранить и обновлять вводные об одном событии (например, событии регистрации) для 4-5 разных программных продуктов. На старте это не кажется проблемой, но по мере роста способно поглощать огромный объем ресурсов.
- Нагрузка на производительность вашего продукта. Традиционный способ установки аналитического сервиса – инъекция JS-сниппета в код вашего сайта или приложения. Когда таких сторонних аппок становится много, это неизбежно приводит к снижению перфоманс-метрик – например, времени отрисовки самых крупных единиц контента. Представьте, что из-за того, что вы отправляете событие регистрации в 10 разных приложений, ваши пользователи будут ждать доступа к приложению несколько дольше, чем должны.
- Сложности с передачей данных. Очень часто одному из приложений необходимо переиспользовать параметры другого. Например, сервис продуктовой аналитики хочет получить точные данные об атрибуции. А маркетинг мечтает получить данные о покупателях для более тонкого таргетинга. При этом далеко не все тулзы обладают удобным API. А это означает, что для такой связки нужно будет делать хрупкую доработку.
- Сложности администрирования. Топ-менеджмент вынужден погружаться в контекст каждого из сервисов, понимать специфику дашбордов и особенности работы с данными. Кроме того компания начинает обрастать источниками, каждый из которых в какой-то мере (далеко не самой полной) претендует на оригинальность. Это приводит к путанице и массе вопросов из серии : "А почему данные в A не совпадают с данными в B?".
- Дороговизна и недоступность. Годовая подписка на продукты уровня GA4 (в пуле GA360), Amplitude, Adobe Analytics, ABTasty будет колебаться вокруг цифры $100тыс. Стоит ли говорить о том, что в связи с текущей ситуацией в России вопрос покупки всех перечисленных продуктов закрыт или будет закрыт в ближайшие месяцы.
Самое большое недоразумение в использовании нескольких сервисов для аналитики продукта и маркетинга – это то, что они работают с одними и теми же данными в одном и том же контексте. Чаще всего это данные о событиях с вашего веб-сайта или приложения. Иногда они обогащены чем-то интересным с CRM, рекламных кабинетов, отраслевых репортов и так далее. Но практически всегда это выглядит так – какой-то из сервисов (скажем GA4, Метрика или Amplitude) просит вас отправить ему те же самые данные, что вы уже отправляете другим. А после старается замкнуть эти данные внутри своего контура.
Ваши интересы как заказчика – получать базис для качественных решений. Но к сожалению, аналитические сервисы далеко не всегда преследуют эти интересы в полной мере. Например, последняя версия Google Analytics все чаще побуждала пользователей обогащать GA4 дополнительными данными. Что наверняка полезно провайдеру. Но вы нанимаете сервис аналитики вовсе не для этого. А для того, чтобы получать более качественные продуктивные решения.
Учитывая выше сказанное, очевидно что использование одного источника данных для получения инсайтов в продукте и маркетинге очень часто является более стратегически сильным решением. Если вы формируете свой data lake (например в виде сырых событий), а потом занимаетесь тем, что решаете с помощью него свои, специфические задачи – то буквально с порога снижаете риски зависимости от политики сторонних провайдеров.
Более того, в таком случае вы легко сможете заимствовать и переиспользовать параметры продукта в маркетинговой воронке и наоборот – ведь они будут находиться в одной базе данных. И вы или ваши аналитики построят воронку с учетом конкретной атрибуции или учтут недооцененные события для узкого сегмента в кампаниях ремаркетинга.
UX Rocket
UX Rocket как раз является примером такого "озера данных" с базисом в виде сырых событий и надстройками в виде отчетов функционала под специфические задачи. Вам буквально не нужно передавать что-то из одного приложения в другое – все находится в одном месте, в виде списка событий, пользовательских параметров, предустановленных когорт и атрибутов. Вы можете обогащать данные информацией из рекламных кабинетов, профили клиентов данными из CRM и других систем, но в отличие от GA и ЯМ не рискуете тем, что вашими данными воспользуется провайдер.
В интерфейсе UX Rocket все, что нужно для аналитики, находится в нескольких понятных табах - "Дашборды", "Эксперименты", "События", "Профили" и "Отчеты". Там вы можете выбрать нужный функционал и сразу приступить к тому, ради чего пришли - получению инсайтов для принятия качественных управленческих решений. Более того, не уходя с платформы вы можете также и протестировать гипотезы с помощью функционала А/В - тестов.
Если для вас вопрос использования нескольких сервисов для продуктовой и маркетинговой аналитики выглядит избыточным – подумайте о том, чтобы использовать для этих целей один. Например, UX Rocket. Записаться на встречу с нашим менеджером и обсудить подробнее - нажимайте сюда.
Чтобы быть в курсе актуальных трендов в продуктовой и маркетинговой аналитике, А/В - тестировании, а также узнать больше о новых возможностях платформы UX Rocket, подписывайтесь на наш Telegram - канал и группу "ВКонтакте".
Проблема действительно есть и "зоопарк решений" это реальная головная боль не только маркетинга и аналитики. Хорошо структурировали тему!
Татьяна, спасибо за комментарий. Рады, что наша статья была для вас полезна!