Сьогодні багато сервісів оренди застосунків для арбітражу трафіку пропонують свої послуги дуже дешево або навіть безкоштовно. Порівняно новий гравець ринку "Banda Apps" зробив це своєю фішкою, свого часу здивувавши багатьох конкурентів настільки, що невдовзі й вони перейшли на безкоштовну модель. Економіку пояснюють дуже просто: раніше сервіси оренди були жадібними й вимагали оплату за кожен інстал, але крім орендної плати вони, виявляється, завжди заробляли на органічному трафіку. Мовляв, магазини застосунків, бачачи, що трафік на застосунку росте й росте, починають самі просувати його в рекомендаціях, а цей трафік сервіс оренди монетизує на свою користь.
Звучить, звісно, логічно, але на практиці органічний трафік в арбітражних застосунках потрібно розглядати разом із двома сусідніми темами: втратами атрибуції та банальним шейвом, тобто фактично крадіжкою.
Що таке органіка в застосунках
У класичному сенсі органічний трафік — це встановлення з Google Play або App Store, які не прив'язані до рекламної кампанії. Вони з'являються, коли користувач сам знайшов застосунок через пошук або рекомендації.
Для сервісу оренди це цілком справедливе джерело доходу, але для орендаря питання в іншому: чи не забирає сервіс частину цінного трафіку під виглядом органіки або технічних розбіжностей.
Справжня ASO-органіка потребує збігу кількох факторів: зрозумілого пошукового попиту, релевантної назви, сторінки застосунку, що добре конвертує, стабільного життя в сторі й достатнього обсягу встановлень. У арбітражних застосунків із цим зазвичай складно, вони рідко схожі на нормальний ASO-продукт. Їм потрібно жити довше, проходити модерацію і не виглядати надто очевидно. Тому замість прямої назви гри або бренду часто з'являються варіації назв, спокійна графіка й уникнення будь-яких ключів у меті.
Звідси головний висновок: органіка можлива, але її не можна приймати на віру тільки тому, що сервіс так називає частину трафіку.
Чому органіку складно перевірити
Передусім варто зауважити, що йдеться лише про нативні застосунки й залив за неймінгом — той тип трафіку, де атрибуція виконується за допомогою MMP-систем, таких як AppsFlyer, Adjust та інших.
Уся справа в маршруті трафіку й будові сучасних рекламних мереж:
- Користувач бачить рекламний креатив. У цей момент рекламна мережа відправляє подію "impression" в MMP. Разом із цією подією MMP отримує інформацію про користувача, але не про рекламну кампанію.
- Користувач переходить за рекламою і встановлює застосунок. Одночасно з цим MMP отримує подію "click", аналогічно з інформацією як на кроці 1.
- Користувач запускає застосунок. Модуль MMP, інтегрований у застосунок або на бекенді сервісу оренди, передає інформацію про встановлення на бекенд MMP для зіставлення.
- MMP запитує у джерел трафіку підтвердження й дані про кліки/покази, тому що більшість джерел трафіку, такі як Meta, Google, TikTok, є SRN — Self-Reported Network, вони самі вирішують, чи належить встановлення до однієї з їхніх рекламних кампаній. Детальніше про це можна прочитати у статті "Ad Platforms vs MMP vs First-Party Data".
- Після отримання даних MMP повертає інформацію сервісу оренди.
При цьому крок 4 може займати досить багато часу. У документації MMP, як правило, це питання делікатно оминають, хоча в рекламних матеріалах AppsFlyer заявляє наявність real-time attribution. Однак розуміння "real-time" на dashboard для маркетолога і "real-time" для неймінгу в арбітражі — це зовсім різні речі: на практиці атрибуція може займати і 5, і 20 секунд, а іноді й кілька хвилин. Чи буде застосунок до останнього показувати екран завантаження, очікуючи атрибуції й ризикуючи втратити умовно "органічне" встановлення?
Тому, коли сервіс пояснює низьку ціну застосунку "органікою", варто уточнювати деталі:
- за якими запитами застосунок отримує органічні встановлення;
- чи бачить орендар десь лог встановлень за своїм неймінгом на стороні сервісу оренди;
- чи бачить орендар звіти про органічний трафік з MMP;
- хто і як монетизує користувачів без атрибуції;
- як поводиться застосунок, якщо під час першого запуску він не встиг отримати атрибуцію встановлення, але до наступного відкриття вона з'явилася;
- чи можна викупити органіку по потрібних GEO.
Якщо відповідей немає, це не доводить обман. Але це означає, що сервіс оренди не до кінця розкриває карти.
Органіка, дефолт і містрекінг — не одне й те саме
Важливо розділяти кілька різних потоків.
Органіка — користувач сам знайшов застосунок у сторі й встановив його без реклами.
Дефолт — потік користувачів, яких система маршрутизації або атрибуції не змогла впевнено прив'язати до конкретного орендаря, баєра чи кампанії.
Містрекінг — технічна помилка атрибуції: клік, встановлення або відкриття були, але трекер, MMP, застосунок або проміжна логіка не зв'язали події коректно.
Помилки при заповненні неймінгу — явище, залишене за межами цієї статті, але цілком поширене. Завжди перевіряйте правильність заповнення неймінгу, а ще краще тестуйте правильність напрямку за неймінгом самостійно.
Звичайні розбіжності — нормальна різниця між рекламним кабінетом, трекером, MMP, стором і внутрішньою статистикою. Такі розбіжності бувають навіть у білих продуктах і не завжди означають, що хтось забирає трафік. Наприклад, дві рекламні мережі можуть записати одне й те саме встановлення собі на різних підставах: скажімо, встановлення відбулося завдяки кліку по рекламі Google і було атрибутоване click-through, але раніше користувач бачив рекламу цього ж продукту в Instagram, тому одночасно встановлення отримало атрибуцію view-through. MMP виконав дедуплікацію подій і вибрав тільки одне джерело відповідно до своїх налаштувань.
Проблема ринку оренди застосунків у тому, що часто всі ці потоки приховані від орендаря. Ви бачите, що частина користувачів не дійшла до вашої статистики, а далі починається питання інтерпретації: це реальна органіка, дефолт, втрата атрибуції чи шейв вашого трафіку.
Чи можна атрибутувати 100% трафіку
Ні. На практиці 100% атрибуція недосяжна.
Причини різні: затримки подій, обмеження iOS, SKAN, браузерні переходи, редиректи, VPN, антифрод, поведінка користувача після встановлення, помилки SDK, проблеми з naming-логікою, кешування і банальні збої інтеграцій. Навіть якщо сервіс оренди працює чесно, частина трафіку все одно буде губитися або потрапляти в невизначений потік.
Тому коректне питання звучить не "чи є втрати", а "який рівень втрат нормальний для моєї зв'язки". Для Android і iOS цей рівень може відрізнятися. Для різних джерел, GEO і типів кампаній — теж.
Якщо на невеликому обсязі ви втрачаєте кілька відсотків, це може бути звичайною технічною реальністю. Якщо на стабільному обсязі втрати стають двозначними й повторюються за одним патерном, це вже привід розбиратися глибше.
Як вимірювати втрати
Починати варто не зі звинувачень, а з вимірювань. Мінімальний набір:
- Звірити дані рекламного джерела, трекера, MMP і статистики сервісу оренди.
- Дивитися окремо Android і iOS, тому що атрибуція й обмеження відрізняються.
- Розбивати дані за GEO, джерелом, кампанією і баєром.
- Перевіряти naming і маршрутизацію на тестових кампаніях із невеликим контрольованим обсягом.
- Порівнювати частку неврахованого трафіку на різних сервісах за схожої структури закупівлі.
Важливо дивитися не тільки на відсотки, а й на гроші. Якщо оборот невеликий, навіть неприємні розбіжності можуть бути дешевшими за власну розробку. Якщо оборот великий, ті самі 5-10% перетворюються на суму, яку вже не можна ігнорувати.
Окремо варто питати сервіси про дефолт: чи існує він, хто його монетизує, чи можна викупити потрібні країни, чи є фіксована подобова ціна і які звіти доступні.
Які є альтернативи оренді
Оренда застосунків залишається зручним рішенням: швидко, зрозуміло, без власної команди розробки й проблем із публікацією. Але якщо економіка впирається у втрати атрибуції, з'являються альтернативи.
Перша — приватний застосунок під одну команду. Це дорожче, але дає більше контролю над трафіком, naming-логікою і монетизацією дефолту. На жаль, сервіси оренди рідко погоджуються на такі умови, і справа тут не в привабливості шейву, а в тому, що заробіток із застосунку в оренді зазвичай вищий.
Друга — викуп дефолту по потрібних GEO. Такий варіант може бути компромісом, якщо сервіс готовий продавати цей потік прозоро, і такі сервіси є в каталозі.
Третя — власна розробка. Вона дає максимум контролю, але потребує грошей, людей, акаунтів, дизайну, публікації, підтримки й постійної заміни застосунків. І найголовніше: експертизи, яка набувається ціною власних проб і помилок, і не безкоштовно, звісно. Для багатьох команд це не економія, а новий головний біль.
Четверта — PWA. У PWA немає стора і класичної атрибуції, тому частина проблем зникає. Натомість з'являються інші обмеження: менше системних можливостей, слабша фільтрація ботів і нижча довіра порівняно з нативним застосунком.
Іноді найкращий варіант — нічого не змінювати. Якщо вам потрібно багато застосунків для in-app, UAC або тестів, а обсяг поки не виправдовує власну інфраструктуру, оренда може бути раціональною навіть із неминучими втратами.
Що далі
Органіка в арбітражних застосунках — не міф, але й не універсальне пояснення низьких цін. Чим дешевше сервіс віддає Android або iOS застосунки, тим уважніше варто дивитися на обсяг втрати трафіку.
При виборі сервісу корисно порівнювати не тільки ставки й платформи, а й прозорість: що відбувається з неатрибутованим трафіком, які звіти доступні, чи можна викупити дефолт, як влаштована маршрутизація і які втрати вважаються нормою.
Для первинного порівняння можна використовувати каталог сервісів оренди застосунків, але фінальне рішення все одно варто приймати за своїми цифрами після порівняння кількох сервісів.