array(3) {
["ua"]=>
array(13) {
["code"]=>
string(2) "ua"
["id"]=>
string(2) "66"
["native_name"]=>
string(20) "Українська"
["major"]=>
string(1) "0"
["active"]=>
string(1) "1"
["default_locale"]=>
string(2) "uk"
["encode_url"]=>
string(1) "0"
["tag"]=>
string(2) "uk"
["missing"]=>
int(0)
["translated_name"]=>
string(20) "Українська"
["url"]=>
string(55) "https://roman.ua/ua/case/software-end-to-end-analytics/"
["country_flag_url"]=>
string(48) "https://roman.ua/wp-content/uploads/flags/ua.png"
["language_code"]=>
string(2) "ua"
}
["ru"]=>
array(13) {
["code"]=>
string(2) "ru"
["id"]=>
string(2) "45"
["native_name"]=>
string(14) "русский"
["major"]=>
string(1) "1"
["active"]=>
int(0)
["default_locale"]=>
string(5) "ru_RU"
["encode_url"]=>
string(1) "0"
["tag"]=>
string(2) "ru"
["missing"]=>
int(0)
["translated_name"]=>
string(18) "російська"
["url"]=>
string(52) "https://roman.ua/case/software-end-to-end-analytics/"
["country_flag_url"]=>
string(79) "https://roman.ua/wp-content/plugins/sitepress-multilingual-cms/res/flags/ru.png"
["language_code"]=>
string(2) "ru"
}
["en"]=>
array(13) {
["code"]=>
string(2) "en"
["id"]=>
string(1) "1"
["native_name"]=>
string(7) "English"
["major"]=>
string(1) "1"
["active"]=>
int(0)
["default_locale"]=>
string(5) "en_US"
["encode_url"]=>
string(1) "0"
["tag"]=>
string(2) "en"
["missing"]=>
int(0)
["translated_name"]=>
string(20) "Англійська"
["url"]=>
string(55) "https://roman.ua/en/case/software-end-to-end-analytics/"
["country_flag_url"]=>
string(79) "https://roman.ua/wp-content/plugins/sitepress-multilingual-cms/res/flags/en.png"
["language_code"]=>
string(2) "en"
}
}
NULL
До нас звернулася компанія Skylum (ex. Macphun) для налаштування наскрізної аналітики. Окрім зведення інформації з усіх джерел в одну базу даних, ми провели аналіз та налаштували процес підрахунку ROI.
Це дозволило компанії перерозподілити гроші на продукти, канали та кампанії з вищим ROI.
Розробка додатків для редагування фото
Macphun – розробник додатків для редагування фото переважно під операційну систему Mac OS X. Багаторічні переможці Apple Awards.
Найбільший продукт під час співпраці – набір програм Creative Kit. Також разом із партнерами компанія розробила Aurora HDR – це програма для редагування HDR фотографій.
У 2018 році під час ребрендингу компанія Macphun змінила своє ім’я на Skylum.
На сайт вели 3 глобальні джерела:
Потрапивши на сайт, користувач міг:
Таким чином у нас було 3 сценарії купівлі софту:
Перед нами стояло завдання збору інформації, об’єднання в одну базу даних за всіма джерелами, аналіз та розрахунок окупності інвестицій (Real ROI).
Часто для відстеження ефективності продажів додатків розробники готують окремі зборки (custom build) програм для кожного партнера або рекламної кампанії, де всередині інсталятора зберігається назва партнера або кампанії.
Таким чином після установки trial версії продукту користувач мітиться, як той, що скачав тріал з певного ресурсу.
Для Macphun цей варіант не підходив, тому що:
Інший наш Клієнт завдання з тріалами та custom build вирішував так:
SourceBuster
Розібравши сценарій покупки софту, ми повинні були записувати і відстежувати дії користувача на кожному етапі. Для цього прописали механізм запису даних користувача в процесі покупки софту.
Що використовували: скрипт визначення джерел залучення відвідувачів сайту SourceBuster, передачу джерел залучення відвідувачів у БД MySQL, потім об’єднання даних із процесингом FastSpring та технологію передачі даних у GA через Measurement Protocol та створення звітів у БД.
Для відстеження покупок, коли користувач йшов з сайту на Mac App Store, ми використовували Source Buster. У партнерське посилання Apple ми “зашивали” такі параметри для кожного відходу на MAS: додаток | кампанія | medium | source.
У підсумку ми отримали статистику про продаж з реклами, яка вела на сайт, у партнерському кабінеті Mac App Store:
Що допомогло зрозуміти, чи взагалі є сенс, вести користувача з реклами на сайт, і з сайту частину з цих людей виводити на Mac App Store, рентабельно це чи ні.
Мінуси продажу софту через Mac App Store:
Ми взяли рішення від компанії MacPaw. Вони написали SDK для Google Analytics та впровадили івенти всередині додатку.
Використовуючи SDK ми відстежили, які типи файлів найчастіше використовують для редагування фотографій. В описі додатку підняли їх догори, щоб користувачі швидше знаходили популярні формати.
Як згадувалося раніше, ми мали кілька варіантів конверсій: конверсія в тріал, конверсія в миттєву покупку, конверсія з тріалу в покупку; та змінних: середній чек, ціна трафіку, вартість тріалу тощо.
Для розуміння з якими продуктами та показниками потрібно працювати, ми побудували unit економіку.
Таким чином ми змогли побачити взаємозв’язок між метриками та чітко зрозуміти, як, змінюючи одну з метрик, ми впливаємо на кінцевий результат:
Коли почали працювати з проєктом, з’ясувалося, що геотаргетинг кампаній був досить широкий, так як софт продавався у всьому світі.
Склавши портрет «Ідеального покупця», ми виявили закономірності (використовуючи дані покупців та рекламних систем), які збільшували приріст у PSV
1. При виконанні дії (завантажити trial, передплата на розсилку, покупка) користувач віддає контактні дані (email)
2. За допомогою скрипта Source Buster створюється запис у БД із полями:
Користувачі використовували різні браузери для тріалу та для покупки. Таким чином, з точки зору Google Analytics 1 користувач міг мати кілька клієнтів.
Після отримання даних перед нами постало завдання по склейці користувачів.
Якщо у користувача вже була наша кука — ми не оновлювали дані за джерелом і датою, але доповнювали при необхідності дані по clientID та імейлу.
Якщо у користувача не було нашої куки, але ми знайшли userID за імейлом або clientid — вішали знайдену куку і оновлювали в БД дані по email/_ga за необхідності.
Таким чином, ми могли доповнювати дані про користувача. Розпізнавати того самого користувача, який міг приходити з кількох кампаній. Наприклад: спочатку скачав програму на комп’ютері, потім відкрив посилання у листі з мобільного пристрою.
Trial: доповнення даних про користувачів через email
Під час використання тріальної версії продукту користувач отримував різні фоллоуапи на вказану пошту. Він міг відкрити посилання на іншому пристрої або в іншому браузері – ми отримували б різні ClientId і один користувач міг би дублюватися в базі.
Впізнавали користувача з email через позначку get-параметра у листах. Щоб гарантовано “пізнати” відвідувача, у кожне посилання в листі додавався персональний параметр, який допомагав нам “впізнати” користувача.
Якщо при переході за посиланням, ми НЕ бачили своєї cookie у користувача, то відновлювали її за переданою адресою пошти в url і записували в БД новий ClientId.
Ця логіка дозволяла нам впізнавати на сайті користувача, який завантажив програму на комп’ютері, потім відкрив посилання у листі з мобільного пристрою, наприклад.
Далі відбувалася склейка транзакцій від процесингу.
1. У момент, коли відбувався продаж, процесинг передавав на наші сервери “веб-хук”, в якому передавалися (транзакція, номер, сума, товари, купони, чистий прибуток, email)
2. Ми розмістили GTM в урізаному вигляді на сторінках процесингу, який викликав:
Дані користувача після покупки записували в БД, які також прив’язувалися до конкретного UserId.
У нас була одна особливість – замість сторінки “Дякуюємо за покупку” (якої не було), ми використали сторінку процесингу.
Дуже часто користувачі залишали різні поштові адреси при замовленні тріалу/купівлі і для того, щоб користувач не дублювався в базі, треба було постійно рахувати наш ClientID, перевірити на наявність UserID + рахувати дані по поточному джерелу (для подальшого аналізу).
Для того, щоб отримати всі дані, ми на сторінці “Дякуюємо за покупку” відкривали iframe з посиланням на наш сервер. Потім передавали в get-параметрах номер транзакції та ClientID (про всяк випадок) таким чином отримуючи доступ до “наших” куків. І брали з кукі сервера source/medium/campaign із Source Buster.
Додаткові складнощі, з якими зіткнулися:
У момент покупки ми робили перевірку по ClientId (якщо нашої cookie 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.
Дані витягували з двох джерел:
Витрати — імпортували в GA за допомогою OWOX BI Pipeline
Доходи — у GA за допомогою Measurement Protocol (Revenue & Refunds), у БД за допомогою webhook від процесингу.
Після обробки ми отримували таку зведену таблицю:
“місяць залучення” – “джерело залучення” – “витрати” – “кількість нових користувачів” – “кількість покупок цими користувачами” – “дохід” – “прибуток” – “ROI”
Далі ми розширювали-доповнювали таблицю до когорти за датою залучення чи аналізу ефективності “конвертуючих” джерел.
У нас було кілька джерел даних, які потрібно об’єднати:
Розрахунок рентабельності інвестицій та маркетингового ROI
1. Створюємо ключ date, source, medium, campaign, наприклад: 201609_google_cpc_sale-30
2.Зв’язуємо таблиці та враховуємо 4 сценарії:
Як виглядали дані
У результаті нам вдалося побудувати зведену
Ми налаштували процес підрахунку Real ROI.
Виявилося, що ROI з PPC реклами позитивний, але не такий високий, як хотілося б. Це дозволило компанії перерозподілити гроші на продукти, канали та кампанії з вищим ROI.
Цитата з Forbes
«Ми особливо любимо аналітику даних, яка дозволяє кожному члену команди, включаючи дизайнерів, вимірювати успіх з огляду на найдрібніші деталі. Ми хочемо знати, чому щось спрацювало чи не спрацювало, і аналіз даних – це ключ!»
З Романом завжди приємно співпрацювати.
У Ромі підкуповує увага до деталей і орієнтація на результат
Ми знаємо як розрахувати рентабельність інвестицій у маркетинг
З 2008 року ми працювали з 281 Клієнтами і допомогли їм зробити інтернет-маркетинг ефективнішим і заробити більше.
Чому ми обрали Roman.ua?
Тому що в хорошому сенсі вони задроти.
Ми – фанати продуктивності.
Ваш і наш час коштує дорого, і ми хочемо використовувати його максимально ефективно. Будемо раді домовитись про зустріч, внести її в календар та поговорити голосом особисто чи онлайн.
Але до зустрічі нам потрібно буде підготуватись. Для цього ми почнемо спілкування по email і надішлемо вам бріф.
Українська
