, обновлено — 7 июля 2019 18 мин на прочтение

Кейс. Как настроить сквозную аналитику для software разработчиков

Проект

Macphun — разработчик приложений для редактирования фото преимущественно под операционную систему Mac OS X. Многолетние победители Apple Awards.

Самый крупный продукт во время сотрудничества — набор программ Creative Kit. Также совместно с партнерами компания разработала Aurora HDR — это программа для редактирования HDR фотографий.

В 2018 г. в ходе ребрендинга компания Macphun сменила свое имя на Skylum.

Команда

  • Роман Рыбальченко — консультант и growth hacker
  • Илья Бабак — аналитик и PPC специалист на стороне Клиента
  • Alex Tsepko — COO Macphun
  • Маркетологи, разработчики, QA на стороне Клиента

Задачи

  • Научиться точнее считать ROI по рекламе и cross promo для разных инструментов: Google AdWords, Facebook, Bing и affiliate marketing
  • Посчитать, как повышает рентабельность рекламы цепочка «оставил email ради триала и купил позже один из продуктов»
  • Сделать атрибуцию покупок из рекламы с точки зрения источника привлечения лида, а не источника, который дал покупку (снижение веса условно-бесплатных поддерживающих каналов — email, ремаркетинг, соцсети, органика)
  • Объединить в аналитике действия вокруг пользователя, чтобы точнее считать LTV, ROI
  • Иметь возможность лучше использовать ремаркетинг и персонализацию. Эффективнее делать персональные предложения на сайте (апгрейд, кросс-сейл, персональные скидки)
  • Понять, стоит ли раздавать бесплатно софт для генерации лидов, покупают ли они потом и окупают ли рекламу, которая была запущена на бесплатную раздачу (giveaway)

Сценарии покупки

На сайт вели 3 глобальных источника:

  • Software (trial, бесплатные версии приложений)
  • Реклама: Facebook, Google Ads, Bing и т.д.
  • Email база подписчиков

Попав на сайт пользователь мог:

  • Перейти на Mac App Store (достаточно ограниченный с точки зрения отслеживания эффективности) и купить «урезанную» версию программы
  • Скачать trial на сайте
  • Совершить покупку Pro-версии сразу на сайте

Таким образом у нас было 3 сценария покупки софта:

  1. Зашел и купил сразу
  2. Зашел → Trial → Покупка с email, ремаркетинга, push
  3. Зашел → Trial → Покупка другого софта на другом сайте с email, ремаркетинга, push

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

Особенности проекта

Перед нами стояла задача сбора информации, объединения в одну базу данных по всем источникам, анализ и расчет окупаемости инвестиций (Real ROI).

Часто для отслеживания эффективности продаж приложений разработчики готовят отдельные сборки (custom build) программ для каждого партнера или рекламной кампании, где внутри инсталятора хранится название партнера или кампании.

Таким образом после установки trial версии продукта пользователь метится, как скачавший триал с определенного ресурса.

Для Macphun этот вариант не подходил, потому что:

  • Отвлекал разработчиков от исправления ошибок и разработки функций и новых продуктов
  • Инсталлятор весил ~200 Мб, что делало генерацию custom build и подписание его ключом разработчика (чтобы операционная система не ругалась) достаточно ресурсоемкой задачей
  • Это не решало задачу, когда пользователь качал триал на сайте, использовал одно приложение, а потом покупал другое приложение на другом сайте (например, качал триал Creative Kit на сайте macphun.com, а покупал c email-рассылок Aurora HDR на сайте aurorahdr.com)

Другой наш Клиент задачу с триалами и custom build решал так:

  • Сервер зашивает userid в название файла
  • После инсталляции и первого запуска программа ищет инсталлятор в папке Downloads и выцепляет userid из названия файла
  • Есть связь между триалом и запуском или покупкой, если пользователь или система не удалили инсталлятор

Таким образом, для этого проекта мы приняли решение не использовать custom build.

Решение

SourceBuster

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

Что использовали: скрипт определения источников привлечения посетителей сайта SourceBuster, передачу источников привлечения посетителей в БД MySQL, потом объединение данных с процессингом FastSpring и технологию передачи данных в GA через Measurement Protocol и создание отчетов в БД.

Mac App Store

Для отслеживания покупок, когда пользователь уходил с сайта на Mac App Store мы использовали SourceBuster. В партнерскую ссылку Apple мы «зашивали» такие параметры для каждого ухода на MAS: приложение | кампания | medium | source.

В итоге, мы получили статистику о продажах с рекламы, которая вела на сайт, в партнерском кабинете Mac App Store:

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

Минусы продажи софта через Mac App Store:

❌Apple забирает процент комиссии
❌Mac App Store продает базовые и более дешевые версии продуктов в отличии от сайта
❌Версии, расположенные в Mac App Store, были достаточно ограничены по аналитике и сбору данных пользователей (кампании были иногда длинные, а Mac App Store партнерская статистика не поддерживала длинный идентификатор, в отличии от SourceBuster

Функции, которыми пользуются в софте. Их влияние на покупку

Мы взяли решение от компании MacPaw. Они написали SDK для Google Analytics и внедрили ивенты внутри приложения.

Фичи, которые используют в софте

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

Популярные форматы файлов

Сходится ли математика?

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

Для понимания с какими продуктами и показателями нужно работать мы построили unit экономику.

Пример таблицы unit экономики

Таким образом мы смогли увидеть взаимосвязь между метриками и чётко понять, как, изменяя одну из метрик, мы влияем на конечный результат:

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

Методы, которые мы использовали для повышения эффективности рекламных кампаний

Метрика Per Session Value (PSV)

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

  • Мы проанализировали Per Session Value (показатель, который включает в себя средний чек, кол-во посещений, конверсии). Просчитав таким образом рентабельность таргетинга. В результате составили “белый список” локаций, состоящий из 10-15 стран, так званный Tier 1, на которые распределяли основной бюджет.
  • Просчитали Per session value в разрезе версии операционной системы и в разрезе новизны, стоимости, функций устройства . “Переиграли” стратегию ретаргетинга (чем новее и дороже устройство пользователя, чем свежее «операционка», тем больше вероятности совершения покупки)

Портрет «идеального покупателя»

Составив портрет «Идеального покупателя» мы обнаружили закономерности (используя данные покупателей и рекламных систем), которые увеличивали прирост в PSV

Читай также: «Как составить портрет покупателя и повысить эффективность маркетинга»

Дополнение и уточнение Базы Данных о пользователе

1. При выполнении действия (скачать trial, подписка на рассылку, покупка) пользователь отдает контактные данные (email)  

2. С помощью скрипта Sourcebuster создается запись в БД с полями:

  • email
  • userid
  • source, medium, campaign, content, term (данные о откуда пришел пользователь)
  • clientid

Пользователи использовали разные браузеры для триала и для покупки. Таким образом, с точки зрения Google Analytics 1 пользователь мог иметь несколько clientid.

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

Данные, которые мы использовали для «склейки» пользователей:

  • наличие нашей куки
  • поиск в базе по clientid и полученному email
  • персональные ссылки в email

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

Если у пользователя не было нашей куки, но мы нашли userID по имейлу или clientid — вешали найденную куку и обновляли в БД данные по email/_ga при необходимости.

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

Trial: дополнение данных о пользователях через email

Во время использования триальной версии продукта, пользователь получал различные фоллоуапы на указанную почту. Он мог открыть ссылку на другом устройстве либо в другом браузере — мы бы получали разные ClientId и один пользователь мог бы дублироваться в базе.

Узнавали пользователя из email через пометку get-параметра в письмах. Чтобы гарантированно “опознать” посетителя, в каждую ссылку в письме добавлялся персональный параметр, который помогал нам «узнать» пользователя.

Если при переходе по ссылке, мы НЕ видели своей куки у пользователя, то восстанавливали её по переданному адресу почты в url и записывали в БД новый ClientId.

Эта логика позволяла нам узнавать на сайте пользователя, который скачал программу

на компьютере, потом открыл ссылку в письме с мобильного устройства, например.

Дальше происходила склейка транзакций от процессинга.

Склейка транзакций от процессинга:

1. В момент когда происходила продажа процессинг передавал на наши сервера “веб-хук”, в котором передавались (транзакция, номер, сумма, товары, купоны, чистая прибыль, email)

2. Мы разместили GTM в урезанном виде на страницах процессинга, который вызывал:

  • коды ремаркетинга
  • коды GA & EEC
  • iframe с сервера с номером транзакции и Clientid на страницы “спасибо за заказ”

Покупка

Данные о пользователе после покупки записывали в БД, которые также привязывалась к конкретному UserId.

У нас была одна особенность — вместо страницы “Спасибо за покупку” (которой не было), мы использовали страницу процессинга.

Очень часто пользователи оставляли разные почтовые адреса при заказе триала/покупке и для того, чтобы пользователь не дублировался в базе надо было постоянно считать наш ClientID, проверить на наличие UserID + считать данные по текущему источнику (для последующего анализа).

Для того, чтобы получить все данные, мы на странице “Спасибо за покупку” открывали iframe со ссылкой на наш сервер. Потом передавали в get-параметрах номер транзакции и ClientID (на всякий случай) таким образом получая доступ к “нашим” кукам. И брали из куки сервера source / medium /campaign из SourceBuster

Дополнительные сложности, с которыми столкнулись:

  • «Урезанный» GTM на страницах процессинга без дебага
  • Формы оплаты: одноразовая, рассрочка, подписка («нанизывали» покупки на первоначальный источник привлечения лида. Так как пользователь при первой покупке ввел данные своей платежной карточки и продолжал приносить прибыль ежемесячно)
  • Междоменное отслеживание, недотрек и прочие радости сложных интеграций :)

В момент покупки мы делали проверку по ClientId (если нашей куки userID не было) и записывали в отдельную таблицу транзакцию с данными по источникам, временем/датой и привязкой к ClientId.

После получения веб-хука, проводилась дополнительная проверка по базе userID по имейлу. Если мы находили пользователя, то связывали покупку с существующим userID, если нет — создавали новый и по возможности сразу же “вешали” нашу куку покупателю (или вешали на следующем посещении).

При повторных платежах (покупки в рассрочку либо по подписке), суммы дохода привязывались к userID через поиск по ID оригинальной (первой) транзакции + информация про платеж отправлялась по measurement протоколу в GA (использовали ClientId и источники первой транзакции).

Объединение данных из разных источников

На странице «спасибо» у процессинга есть clientid и transactionid — это ключи.

На странице iframe с нашего сервера, кроме clientid есть source, medium, campaign…, по которому пришел пользователь.

В вебхуке есть transactionid и состав транзакции, сумма заработка и email пользователя.

Объединение данных из разных источников

По этим всем ключам мы дополняли данные и склеивали их воедино в БД.  Итого в БД был clientid, transactionid, данные Sourcebuster, что пользователь купил, сколько мы заработали, имейл и userid. Таким образом мы могли простроить связи между сайтом, страницей процессинга и конечной продажей в базе данных.

Построение отчета и анализ

Для расчетов реального ROI мы использовали надстройку Power Query MS Excel.

Данные вытягивали из двух источников:

  1. GA — источники трафика, расходы и прямые продажи, даты
  2. БД — результирующая таблица “дата попадания в базу” — “первый источник” — “дата покупки” — “сумма дохода”

Доходная и расходная часть

Расходы — импортировали в GA c помощью OWOX BI Pipeline

Доходы — в GA c помощью Measurement Protocol (Revenue & Refunds), в БД с помощью webhook от процессинга.

После обработки, мы получали такую сводную таблицу:

“месяц привлечения” — “источник привлечения” — “расходы” — “кол-во новых пользователей” — “кол-во покупок этими пользователями” — “доход” — “прибыль” — “ROI”

Далее мы расширяли-дополняли таблицу до когорты по дате привлечения либо для анализа эффективности “конвертирующих” источников.

Читай также: «Расчет рентабельности инвестиций и маркетингового ROI»

Объединение данных

У нас было несколько источников данных которые нужно объединить :

  • GA costs: data, cost, source, medium, campaign
  • GA revenue: data, transactionid, revenue, source, medium, campaign
  • БД: data, transactionid, revenue, source, medium, campaign

Для объединения данных мы использовали Microsoft Power Query в Excel:

Склейка ( merge) таблиц

1.Создаем ключ date, source, medium, campaign, например: 201609_google_cpc_sale-30

2.Связываем таблицы и учитываем 4 сценария:

  • продажа есть в GA, но нет в БД
  • есть в БД и GA
  • есть в БД, но нет в GA (по основному сайту)
  • есть в БД, но нет в GA (продажи другой программы на другом сайте)

Как выглядели данные

«Сырые» данные
«Склееные таблицы»

В итоге у нас получилось построить сводную

Сводная

Результаты

Мы настроили процесс подсчета Real ROI.

Оказалось, что ROI c PPC рекламы положительный, но не такой высокий, как хотелось бы. Это позволило компании перераспределить деньги в продукты, каналы и кампании с более высоким ROI.

Цитата из Forbes

«Мы особенно любим аналитику данных, которая позволяет каждому члену команды, включая дизайнеров, измерять успех учитывая самые мельчайшие детали. Мы хотим знать, почему что-то сработало или не сработало, и анализ данных — это ключ!»

Отзыв сооснователя и генерального директора проекта
Отзыв: It’s always a pleasure to collaborate with Roman
Читать полностью
Смотри все отзывы
Главный операционный директор о нашем сотрудничестве
Отзыв: В Роме подкупает внимание к деталям, и ориентация на результат
Читать полностью
Смотри все отзывы
Нужна настройка веб-аналитики?
Мы знаем как рассчитать рентабельность инвестиций в маркетинг
Читай также:

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

11 октября 2017 Секрет Фирмы

Как делать подкасты — опыт Романа Рыбальченко c кейсом «Продуктивный Роман»

15 декабря 2017 AIN.ua

Роман Рыбальченко о 7 факторах стресса и как с ними бороться

27 июля 2017 Лайфхакер

Кейс читателя: Почему мы потеряли клиента, несмотря на успешное продвижение его интернет-магазина

19 мая 2015 vc.ru

20 лучших подкастов на тему маркетинга, рекламы и PR

13 октября 2019 Pressfeed
avatar
Вадим Ошкало
Руководитель intimo.com.ua

Cистемность — это «религия» Романа. Так что работая с Roman.ua Вам прийдется её принять и получить все вытекающие бонусы.

Все отзывы 82

Мы помогли более 200 Клиентам. Слово «Клиент» мы всегда пишем с большой буквы.

  • Macphun
  • Intimo
  • Prom.ua
  • Autoportal.com
  • Київстар
  • Kingston
  • SemRush
  • Dobovo
Работаем удаленно и в офисе в Киеве.

Любим путешествовать и увеличиваем продажи Клиентам по всему миру.