Кейс з декількох FinTech проектів
Аналітика інсталів мобільних застосунків через веб-сайт
Трекінг каналів інсталів мобільних застосунків у платформах AppsFlyer та Adjust
Як ми забезпечили коректний трекінг каналів інсталів мобільного застосунку у воронці web-to-app
Це рішення must have для проектів, де користувачі встановлюють застосунок не одразу, а після взаємодії з веб-сайтом.
Ви зможете точно вимірювати ефективність джерел встановлення мобільних застосунків у MMP AppsFlyer та Adjust, а для реалізації ми використовуємо лише GTM — без залучення розробників і втручання у код веб-сайту.
Костянтин Черниш
Co-Founder "Power-UP"
Що таке web-to-app
і чому це важливо
У багатьох мобільних проєктах використовується так звана W2A (web-to-app) воронка. Це коли користувач спочатку потрапляє на сайт, а потім переходить з нього на сторінку встановлення застосунку в App Store або Google Play.
Такий сценарій особливо характерний для рекламного трафіку у нішах, де важливо отримати "якісні" завантаження застосунку та/або залучити вузьку цільову аудиторію. Іноді необхідно вести користувача спочатку на сайт, для ознайомлення з продуктом/сервісом.
Воронка працює наступним чином: спочатку клієнт бачить оголошення, відкриває сайт, ознайомлюється з продуктом, а вже потім переходить до встановлення застосунку і реєструється/робить покупки у застосунку.
Якщо на цьому шляху не налаштовано правильне відстеження, аналітична система не зможе "зв'язати" інстал з рекламною кампанією. У результаті такі інстали у платформах MMP (Mobile Measurement Partner) AppsFlyer або Adjust будуть зараховані до органічного або прямого трафіку, а не до того джерела, яке насправді привело користувача. Це значно спотворює оцінку ефективності каналів і ускладнює прийняття рішень щодо інвестицій у рекламу.
Проблема стандартних скриптів трекінгу
1
Робота стандартних скриптів
Ми протестували готові рішення, які надаються популярними аналітичними платформами AppsFlyer та Adjust. Основна логіка його роботи полягає в тому, що deep-link формується "в моменті" — на основі UTM-міток поточної сторінки. Скрипт зчитує мітки одразу після завантаження, підставляє їх у посилання на App Store або Google Play, і все.
2
Недоліки стандартних скриптів
Якщо користувач не одразу переходить зі сторінки входу до сторінки встановлення застосунку, а натомість переглядає інші сторінки сайту, то мітки зникають. У результаті deep-link формується без параметрів і установка не буде пов’язана з джерелом трафіку.
3
Недоліки стандартних скриптів
Скрипт не зберігає інформацію про джерело між сесіями. Наприклад, якщо користувач спочатку зайшов за рекламою, але не встановив застосунок, а повернувся на сайт наступного дня без міток (через прямий візит), то цей повторний захід буде зарахований як direct. Попередній рекламний контакт не буде врахований взагалі
Рішення
1 При першому візиті на сайт UTM-мітки зчитуються та зберігаються в cookie браузера. Це дозволяє не втратити джерело трафіку, навіть якщо користувач взаємодіє з кількома сторінками.
2 При кожному наступному заході скрипт перевіряє:
• Якщо поточне джерело — прямий захід, але в cookie збережено попереднє джерело, буде використано саме його.
• Якщо збережене джерело також є прямим, інформація не передається.
• Якщо користувач заходить з нового рекламного каналу, збережене джерело оновлюється.
3 На основі актуального джерела трафіку формується deep-link. Усі зовнішні посилання на сайті (наприклад, кнопки “Завантажити застосунок”) автоматично підміняються на ці динамічні deep-links із параметрами. Таким чином система аналітики отримує правильну інформацію про канал, що привів користувача.
Найважливіше: всю цю логіку вдалося реалізувати повністю без участі розробників. Впровадження було здійснено виключно через Google Tag Manager, що дозволило швидко протестувати і масштабувати рішення без втручання у код веб-сайту.
Дане рішення працює з такими платформами мобільної аналітики, як AppsFlyer і Adjust, — після коректного формування deep-link посилань дані про джерело трафіку коректно передаються в атрибуційну систему, що забезпечує точну звітність у панелях цих сервісів.
Висновки
-
Стандартні скрипти трекінгу не гарантують збереження джерела трафіку у web-to-app воронках.
-
Втрата UTM-міток під час навігації сайтом або при повторних візитах призводить до некоректної атрибуції інсталяцій і подальших подій.
-
Інтегроване стороннє рішення дозволило зберігати та оновлювати інформацію про джерело на рівні cookie та передавати її у deep-link.
-
Уся реалізація була виконана без залучення розробників, за допомогою Google Tag Manager, що спростило запуск і підтримку.
-
Це значно покращило точність аналітики та дозволило об’єктивно оцінювати ефективність рекламних кампаній.
Якщо ваші користувачі встановлюють застосунок не одразу, а після взаємодії з веб-сайтом, і ви хочете бачити реальну ефективність своїх джерел встановлень застосунку, — подібна реалізація є необхідною умовою для точного вимірювання результатів у платформах мобільної аналітики (в нашому випадку AppsFlyer або Adjust).