Проект

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

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

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

• Software (trial, бесплатные версии приложений)
• Реклама: Facebook, Google Ads (AdWords), 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 из названия файла
• Есть связь между триалом и запуском или покупкой, если пользователь или система не удалили инсталлятор

Решение

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 мы отследили какие типы файлов чаще всего используют для редактирования фотографий. В описании приложения подняли их наверх, чтобы пользователи быстрее находили популярные форматы.

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

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

• Увидели рентабельность продвижения тех или иных продуктов
• Посчитали, с каким средним чеком, с каким 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

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

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, данные Sourcebuster, что пользователь купил, сколько мы заработали, имейл и userid. Таким образом мы могли простроить связи между сайтом, страницей процессинга и конечной продажей в базе данных.

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

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

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

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

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

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

“месяц привлечения” — “источник привлечения” — “расходы” — “кол-во новых пользователей” — “кол-во покупок этими пользователями” — “доход” — “прибыль” — “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:

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

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

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

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

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

Результаты

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

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

Цитата из Forbes

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