Як правильно налаштована аналітика допомагає швидко приймати ефективні рішення

Маєте велику кількість джерел аналітичних даних, які щодня перевіряєте? Не можете чітко визначити, чи окупаються маркетингові активності загалом? Так, це задачі із зірочкою. Але їх можна вирішити. Як саме — розказуємо на прикладі цього кейса.

Zakaz.ua є не лише сервісом з доставлення продуктів до кінцевих споживачів, а й зручним майданчиком для продажів серед великих торгових мереж. Для ключових партнерів команда проєкту створює окремі посадкові сторінки на субдомені zakaz.ua. А ще відкриває рекламні кабінети та запускає окремі рекламні кампанії — отже має безліч джерел інформації.

Зазвичай показники доходу зберігаються в CRM, джерела трафіку ― в системах аналітики, а витрати на рекламу ― в рекламних сервісах. Отже, щоб команда проєкту мала змогу оперативно приймати бізнес-рішення, нам потрібно було об'єднати всі ці дані у єдину систему, налаштувати щоденне автоматизоване оновлення таких звітів, а також залишити можливість фільтрації даних в розрізі партнерів.

Оскільки до старту наших спільних робіт інхаус-команда бренду вже налаштувала окремі звіти даних CRM, звіти рекламної активності для кожного кабінету партнера та Google Analytics 4, яка поєднувала дані застосунку та сайту, — нам залишилося поєднати дані з усіх джерел в один дашборд та автоматизувати сам звіт.

НАЛАШТУВАННЯ НАСКРІЗНОЇ АНАЛІТИКИ

Зазвичай такі великі бізнеси, як zakaz.ua, мають безліч джерел даних — отже, їм вже не обійтись без наскрізної аналітики.

БІЗНЕС-ПРОБЛЕМА КЛІЄНТА

Дані про конверсії з рекламних кабінетів (Google Ads, Facebook тощо) відрізнялись від даних з Google Analytics.

ПРИЧИНА

Різні моделі атрибуції, що діють у рекламних кабінетах за замовчуванням.

РІШЕННЯ

Агрегувати дані різних звітів в один та поєднати в ньому дані про витратну та дохідну частини.

РЕЗУЛЬТАТ

Можливість для клієнта налаштувати системи розрахунку та статистику за статусами замовлення з внутрішніх систем обліку.

ЗБІР ТА ПОЄДНАННЯ ДАНИХ

Дані аналітики та CRM-системи ми поєднали за номером замовлення, а дані про витрати з даними аналітики та CRM — за джерелом.

‍Щоб гарантувати регулярне оновлення інформації у звітах, написали Python-скрипти, які забезпечили щоденне оновлення даних з усіх джерел, залучених клієнтом. Щодо рекламних кабінетів — більшість з них мали відкритий API, який ми використали, аби зібрати відомості про витрати.

Для стягування даних можна використовувати готові конектори, але ми цього не робимо з міркувань безпеки. Враховуючи, що вони зазвичай потребують щомісячної плати за користування, написання власних скриптів допомагає заощаджувати витрати на підтримку наскрізної системи.

ПРОБЛЕМА КЛІЄНТА

В деяких випадках реклама для групи партнерів здійснювалась з одного облікового запису. Виокремити дані щодо витрат за кожним з партнерів можна було лише за назвою рекламної кампанії.

РІШЕННЯ

З боку клієнта — стандартизувати назви рекламних кампаній, з нашого боку — забезпечити парсинг назв кампаній.

Для поєднання та зберігання даних ми обрали сховище BigQuery від Google Cloud. Це рішення дозволяє обробляти великі об’єми даних, не переймаючись щодо підтримки серверної інфраструктури.

‍Ключова перевага Google Cloud — інтеграція з Google-сервісами (Google Ads і Google Analytics 4) та додаткові можливості опрацювання даних. Наприклад, для сховища можна написати скрипт певних дій з даними, й сервіс буде виконувати його за графіком.

‍Щоб клієнту було зручно аналізувати дані за кожним з партнерів — ми також додали до загального звіту фільтри за партнерами.

КАСТОМНА АТРИБУЦІЯ «LAST NON-PUSH NON-DIRECT CLICK»

Окремим викликом для нас стала розбудова моделі атрибуції.

ПРОБЛЕМА #1

Джерела конверсій в інтерфейсі GA4 за замовчуванням відображаються за моделлю атрибуції «Data-driven», яка в сирих даних не надає інформацію щодо джерела. Натомість вона відображає джерело окремого сеансу та перше джерело користувача.

Важливою частиною роботи нашої команди було врахувати вплив допоміжних каналів на замовлення з сайту. У випадку zakaz.ua допоміжні канали — це ті, які впливають на прийняття рішення щодо замовлення, але не є основним джерелом залучення трафіку (наприклад, push-повідомлення).

РІШЕННЯ

В рамках проєкту ми будували атрибуцію власноруч. З одного боку, вибір такої моделі атрибуції ускладнює процес розбудови наскрізної аналітики, але серед переваг — її можна опрацювати й кастомізувати відповідно до потреб бізнесу та перевіряти правила призначення джерел.

ПРИКЛАД

Push-повідомлення ― корисний інструмент для повернення користувачів до сервісу, однак він не є джерелом залучення нових клієнтів. Тому і правила його відображення як «джерела покупки» мають відрізнятися від тих, що діють для інших джерел трафіку.

Щоб дослідити вплив інструменту на покупку та взаємодію з іншими джерелами трафіку, ми виокремили його конкретною метрикою і виключили при визначенні останнього вагомого джерела покупки.

Також, за нашим досвідом, дані з джерел Facebook та Apple Search Ads можуть некоректно відображатися у Firebase і не передаватися до Google Analytics 4. Тож для уточнення джерела покупок з мобільного застосунку ми залучили додатковий сервіс, який інтегрується з цими рекламними кабінетами, — AppsFlyer.

Оскільки AppsFlyer зареєструвала 2204 покупки з каналу Apple Search Ads, а Firebase лише 21, ми доповнили дані з платформи мобільної аналітики.

ПРОБЛЕМА #2

Ми будували наскрізну аналітику, спираючись на дані GA4, але збір даних у цей сервіс налаштували набагато пізніше, ніж в Universal Analytics. Отже, базуючись на розподілі даних за джерелами лише на GA4, ми були суттєво обмежені під час аналізу історичних даних.‍

РІШЕННЯ

Щоб розширити можливості для вибору періоду аналізу, ми вивантажили історичні дані з Universal Analytics та об’єднали їх з даними з GA4.

АВТОМАТИЗАЦІЯ ЗВІТУ З ДАНИМИ МЕДІЙНОЇ РЕКЛАМИ

‍ПРОБЛЕМА

До початку робіт звіти щодо медійних кампаній інхаус-команда формувала вручну. Це суттєво обмежувало можливості клієнта в оперативному опрацюванні даних та прийнятті на їх основі ефективних рішень.

РІШЕННЯ

Ми автоматизували збір даних з сервісу CampaignManager360, доповнили його метриками з DisplayVideo360 та візуалізували це все в BI-системі Tableau.

Для візуалізації даних ми рекомендуємо клієнтам обирати серед трьох BI-систем:

Оскільки ще до початку робіт вся внутрішня звітність клієнта була в Tableau, задачі з візуалізації закривались саме в цій BI-системі, а ще частина робіт з візуалізації закривались на стороні інхаус-команди бренда.

РЕЗУЛЬТАТИ НАШОЇ РОБОТИ

Ми налаштували для бренду єдину систему наскрізної аналітики з щоденним автоматизованим оновленням даних. Тепер вона агрегує дані з різних джерел: аналітичні системи, рекламні кабінети та дані внутрішнього обліку і дозволяє відстежувати ефективність усіх каналів.

‍В цій системі також побудована кастомна модель атрибуції, що дозволяє коректніше порівнювати дохід і витрати на рекламну активність.

Ми дуже задоволені результатом. Це був свого роду виклик, бо ми маємо безліч джерел даних, велику кількість рекламних кабінетів, свої особливості роботи. Разом з командою аналітиків Promodo ми впоралися із дійсно великим проєктом. Зараз уся необхідна нам інформація відображається у єдиній системі із найважливішими параметрами, необхідними для подальшої розбудови. Дякуємо за залученість та невпинний пошук нових кастомних рішень.

— Євген Нетреба, CMO zakaz.ua