75 помилок під час ASO-оптимізації та аналізу її результатів

«Вчіться на чужих помилках — ви ніколи не зможете прожити достатньо довго, щоб зробити їх усі своїми руками» — цим правилом ми в RadASO користуємось завжди і вам рекомендуємо. Саме тому в цій статті зібрано ТОП розповсюджених помилок в ASO-оптимізації, яких варто уникати. 

Загальні помилки, спільні для Apple App Store і Google Play

Помилка #1. Використовувати однакову стратегію для просування застосунку в App Store та Google Play

Стори мають абсолютно різні алгоритми, починаючи від різних полів (title, subtitle), які індексуються, тому і стратегії для просування у сторах будуть значно відрізнятись. Наприклад, в кожному з сторів індексуються різні елементи:

Тобто в Google Play індексується Title, Short description та Full description. В App Store - Title, Subtitle та Keywords field.
В тому числі, в Google Play індексуються відгуки, а також відповіді на них. 
В App Store є скріншоти в пошуку, на відміну від Google Play (крім брендових запитів). Це лише деякі приклади відмінностей між сторами, на які слід звертати основну увагу.

Помилка #2. Не перевіряти конкуренцію та попит у ніші

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

Основне, що треба зрозуміти після вивчення ніші:

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

Провівши аналіз обсягу ніші, ви зможете побачити, скільки інсталлів та прибутку в якій країні мобільні застосунки даної ніші отримують. На основі цього ви зможете розставити пріоритети для просування свого мобільного застосунку на ті чи інші країни.  

Помилка #3. Використовувати стратегії SEO для просування мобільного застосунку

SEO дуже відрізняється від ASO, тому не можна користуватись однаковими підходами. Просування мобільного застосунку — це не просування вебсайту!

Так, у деяких випадках покупка трастових посилань може спрацювати для мобільних застосунків, але це стосується лише Google Play і не є загальною практикою. 

Крім того, ASO-оптимізація — це не лише оптимізація текстових метаданих. А також постійна робота з графікою та додатковими складовими — наприклад, з рейтингом та оцінками, із позиціюванням застосунку в інших розділах сторів (топ категорії, застосунок дня, вибір редакції та ін.).

Помилка #4. Не проводити локалізацію під певні регіони

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

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

Помилка #5. Чекати від ASO швидких та неперевершених результатів

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

Головна мета ASO-оптимізації — підняти видимість та покращити конверсію застосунку, зробити його привабливим для користувачів та зрозумілим для пошукових алгоритмів сторів. 

Помилка #6. Зробити разову ASO-оптимізацію і на цьому зупинитись 

Необхідно постійно слідкувати за позиціями, популярністю ключових запитів, сезонністю, конкурентами, трендами у ніші, змінами у поведінці користувачів і т.д., та регулярно оновлювати метадані і графіку.

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

Помилка #7. Не використовувати саджести (пошукові підказки) під час збору семантичного ядра

Для збору семантичного ядра в сторах є підказки, які треба використовувати та просуватись по ним. 

Часто користувачі не вбивають запит повністю, а натискають на пошукові підказки, які пропонують стори. Тому для отримання позицій по цим підказкам, треба додати їх у метадані. 

Помилка #8. Не використовувати додаткові джерела маркетингу

Щоб ASO приносило гарні результаті, потрібно працювати з додатковими джерелами трафіку, аби підвищити впізнаваність та популярність бренду — наприклад, Search Ads, Google Ads, Facebook Ads, реклама в застосунках. 

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

Крім того, загальний обсяг трафіку з інших джерел буде позитивно впливати на індексацію.

Помилка #9. Не аналізувати відгуки і не відповідати на них

Відгуки — важливий фактор для ранжування та конверсії застосунку. Ми вже писали про їхній значний вплив на ASO. 

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

Помилка #10. Не приділяти увагу зафічереним відгукам

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

Помилка #11. Не працювати над покращенням рейтингу

На основі оцінок формується рейтинг застосунку. А рейтинг — один із важливих факторів ранжування та впливу на конверсію. Оптимальний рейтинг в обох сторах не повинен бути нижче 4*, а краще — 4,5*. Тим паче в Google Play є фільтр, скориставшись яким, користувачі у видачі бачитимуть лише застосунки звідповідним показником рейтингу.

Тому точно не буде зайвим налаштувати у застосунку pop-up форму з проханням поставити оцінку. 

Запрошувати оцінку варто на тому етапі, коли користувач повністю задоволений застосунком.

Завжди важливо звертати увагу на якість застосунку, з яким ви працюєте. Коли застосунок сам по собі недопрацьований, та у ньому виникає багато багів, користувачі будуть ставити низькі оцінки. За рахунок цього буде низький рейтинг, поганий ретеншн всередині і позиції будуть погані відповідно. Особливо оцінки впливають на позиції в Google Play).

Помилка #12. Ігнорувати дані з аналітики та MMP

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

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

Помилка #13. Не проводити аналіз ASO-оптимізації та не коригувати плани

Після кожної ітерації метаданих слід проводити аналіз — що спрацювало, що ні, в разі необхідності треба змінювати плани щодо опрацювання тих чи інших локалей. Крім того, варто корегувати плани щодо усіх каналів просування: Search, App Referrer, Web Referrer, Search Ads в App Store.

А також Search, Explore і Third-party Referrals в Google Play.

Помилка #14. Не слідкувати за оновленнями сторів

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

Аби нічого не пропустити, вступайте у групу RadASO й ASO Stack Slack та слідкуйте за оновленнями. 

Помилки у текстовій оптимізації. App Store

Помилка #15. Не використовувати найбільш популярні релевантні ключові запити у полі Title

Title — найбільш значуще поле в App Store, тому сюди треба намагатись додати найпопулярніші із релевантних запитів, щоб зайняти високі позиції.

Помилка #16. Не заповнювати поле Subtitle

Проаналізувавши велику кількість застосунків, ми помітили закономірність, що поле сабтайтл залишається незаповненим — тим самим ви втрачаєте додаткових 30 символів для ключових слів.

Помилка #17. Невірно вписувати ключові слова у поле Keywords

Прописувати треба не словосполучення, а окремі слова. Їх слід прописувати без пробілів через кому (keyword1,keyword2,keyword3):

Помилка #18. Не використовувати пряме входження ключового слова

Важливо потрібний ключовий запит застосовувати без зміни закінчення, відмінку і т. д. У деяких випадках стор може проіндексувати певну словоформу (найчастіше англійською), але це можна виявити тільки в результаті експериментів.

Помилка #19. Не використовувати всі доступні символи у полях, що індексуються

Доступна кількість символів у полях: 

• Title — 30; 
• Subtitle — 30; 
• Keywords — 100. 

Помилка #20. Дублювати ключові слова у різних полях

Уникайте вживання одних і тих самих ключів у різних полях. По-перше, повтор ключів не посилить їхню значимість. По-друге, якщо ви запит помістите і в title, і в subtitle, або в полі ключів — невідомо, звідки саме стор проіндексує його.

Помилка #21. Використовувати бренди конкурентів у видимій частині метаданих

У Title та Subtitle заборонено використовувати чужі бренди. Однак окремі слова застосовувати можна, якщо вони загальні. 

Наприклад, є запит з високою популярністю «Sysco delivery». Щоб використати його, можна delivery помістити в тайтл, а sysco — у поле ключових слів. Таким чином ви зможете зайняти певну позицію за цим запитом і не порушите правила стору.

Помилка #22. Віддавати перевагу брендовим запитам конкурентів замість загальних ключових слів

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

Тому варто спочатку використати усі загальні популярні ключові слова, а вже потім — чужі бренди.

Помилка #23. Використовувати в метаданих нерелевантні ключові запити

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

І навіть якщо вам вдасться отримати високу позицію за нерелевантним запитом, все одно встановлень з цього ви не отримаєте.

Помилка #24. Використовувати безкоштовні стоп-слова

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

Помилка #25. Використовувати один і той самий запит у множині та однині

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

Помилка #26. Не використовувати кросс-локалізації

У деяких країнах діє одночасно 2-3 локалі, а в США — навіть 10. Варто задіювати усі крос-локалі при оптимізації. Таким чином ви отримаєте в кілька разів більше місця для ключових слів. Бiльш детально про покриття локалей — тут.

Помилка #27. Використовувати в метаданих назви категорій, підкатегорій та імені розробника

Apple автоматично індексує застосунки по назві категорії, підкатегорії а також імені розробника. До того ж слово «free» автоматично присвоюється всім застосункам із категорії безкоштовних. 

Помилка #28. Ставити назву невідомого бренду на початок Title

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

Помилка #29. Робити тайтл та сабтайтл нечитабельним, без пробілів та розділових знаків

Title та Subtitle мають бути зрозумілими для користувачів, а не просто набором ключових запитів. Щоб заголовок та підзаголовок виглядав привабливо, використовуйте розділові знаки («-,» «&,» «:» та інші), а також пробіли між словами.

Помилка #30. Використовувати входження слів із одного ключового запиту в різні локалі

Наприклад:

Помістивши viettel в одну локаль, а post — в іншу, ви не будете ранжуватись по запиту viettel post в жодній із локалей.

Помилка #31. Вважати, що ключі в Subtitle мають сильніший вплив на ранжування, ніж у полі Keywords

Сильніший вплив має лише поле Title, водночас Subtitle та Keywords — рівнозначні. 

Помилка #32. Додавати у Title лише пряме входження ключового запиту, без додаткових слів

Точна відповідність заголовка пошуковому запиту не дає переваг.

Тому, наприклад, якщо вам потрібно використати ключовий запит «Merge stories», краще додати додаткові ключі, щоб покрити більше запитів.

Помилка #33. Використовувати автопереклади (або машинні переклади) — стосується обох сторів

Справа в тому, що машинний переклад може перекладати одне й те ж саме слово по-різному, і в кожному випадку можлива різна популярність запитів:

*SAP — Search Ads Popularity, показує популярність запит

Помилки у текстовій оптимізації. Google Play

Помилка #34. Не використовувати ключові запити у полях Title, Short Description, Full Description

У Google Play ці поля індексуються, тому варто вписувати в них релевантні популярні ключові запити.

Помилка #35. Переспам ключових слів у полі Full Description

Загальна рекомендація — у повному описі слід використовувати ключове слово один раз на 250 символів.

Помилка #36. Невірна частота входження ключових запитів у повному описі

Частота входження ключових запитів це кількість разів, що їх вводять у пошук за певний період (зазвичай протягом місяця). Перевірити цей показник можна за допомогою тула Apptweak чи Wordcounter. 

Оптимальні показники по основним ключовим запитам: 

• count — не менше трьох;
• density — не нижче 2%. 

Помилка #37. Не структурувати текст у повному описі

Повний опис користувачі читають дуже рідко, тим не менш необхідно структурувати інформацію правильно, розставивши акценти на важливих деталях.

Також такий опис краще считується алгоритмом Google Play.

Помилка #38. Не перевіряти опис в Google Natural Language

Перевірка потрібна, щоб зрозуміти, як алгоритми стору сприймають ваш текст, та до якої категорії відносять. Оптимальний показник Confidence — не менше 0.9.

Помилки при роботі з графікою в App Store та Google Play

Помилка #39. Не проводити аналіз конкурентів

Перш за все, переходячи до роботи з графікою — проведіть ресьорч ніші: 

• які спільні акценти використовуються у більшості застосунків;
• які кольори переважають;
• що показують на перших скріншотах;
• на чому акцентують увагу. 

Наприклад, дуже важлива композиція у графічному ASO.

Помилка #40. Робити нерелевантну іконку

Іконка повинна або асоціюватись з брендом, або відображати суть застосунку. 

Наприклад, ось з перших трьох іконок одразу зрозуміло, що застосунок призначений для озвучування тексту, з останньої — зовсім ні.

Помилка #41. Використовувати багато дрібних елементів на іконці

Іконка повинна бути мінімалистичною, тому що дрібні елементи будуть створювати зайвий «шум» та відволікати увагу. 

Невдалий приклад:

Помилка #42. Писати невідомий бренд на іконці

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

Один із таких прикладів:

Помилка #43. Приділяти більше уваги «красі» скріншотів і водночас не робити того, що може вплинути на конверсію

На скріншотах цього застосунку зробили акцент саме на візуальному оформленні, тобто намагались зробити «красиво». 

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

Помилка #44. Робити кепшени занадто довгими

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

Помилка #45. Взагалі не використовувати кепшени

За допомогою вірно сформульованих написів ви зможете привернути увагу користувачів до необхідних функцій або переваг. 

Помилка #46. Неправильно підбирати фон та не виділяти мокапи

Правильний вибір фону та виділення мокапів впливатиме на візуальне сприйняття застосунку.

Помилка #47. Чергувати горизонтальні та вертикальні скріншоти

Помилка #48. Робити скріншоти неінформативними та незрозумілими

Помилка #49. Не виділяти за допомогою зумування основні елементи, на які необхідно звернути увагу

Помилка #50. Не показувати основний функціонал та переваги застосунку на перших скріншотах

Перші 2-3 скріншоти — основні. Саме на них звертають увагу користувачі, і ваша задача — донести основну інформацію за декілька секунд та переконати, що ваш застосунок вартий встановлення.

Помилка #51. Не проводити регулярні A/B тестування графіки

Немає меж для прекрасного — якою б бездоганною не здавалась би вам ваша графіка, завжди можна знайти нові ідеї для її вдосконалення. Для A/B тестування необхідно використовувати вбудовані інструменти в Google Play Console і App Store Connect.

Помилка #52. Не змінювати графіку під час сезонних свят або подій

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

Помилка #53. Завершувати тест графіки передчасно

Не можна зупиняти тест або випускати реліз застосунку, поки не буде видно достатньо однозначний результат. Тримати тест варто не менше 7 днів, очікуючи Confidence на достатньо високому рівні. 

Приклад результату тесту в Google Play:

Приклад результату тесту в App Store:

Помилка #54. Одночасно змінювати декілька графічних елементів

Важливо усі зміни вносити поступово і відстежувати результати. Наприклад, не можна одночасно змінювати іконку і скріншоти. Якщо ви це зробите, не буде змоги точно зрозуміти, що і як саме вплинуло на конверсію. 

Краще змініть іконку, зачекайте мінімум тиждень, подивіться, як змінилась конверсія. І вже після цього завантажуйте нові скріншоти та аналізуйте подальші зміни. Або навпаки.

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

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

Але якщо захочете одночасно змінити і фон, і перші скріншоти, і кепшени — ви не знатимете достовірно, що саме вплинуло на конверсію. Тому всі зміни на скріншотах повинні бути поступовими, обгрунтованими та спланованими. 

Помилка #55. Не формулювати конкретні гіпотези при покращенні скріншотів

Коли ви роздумуєте над тим, як покращити скріншоти — спочатку сформулюйте чіткі гіпотези: що хочете зробити, як хочете зробити, і який результат це може принести. І вже потім поступово тестуйте кожну зі сформульованих гіпотез.

Помилка #56. Не тестувати відео

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

Інші помилки. App Store

Помилка #57. Не використовувати буст від Apple під час запуску застосунку

Буст полягає в тому, що Title застосунку з’являється в саджестах (пошукових підказках) при введенні першого слова з нього в строку пошуку.

Тому першим словом в тайтлі має бути популярний і релевантний ключ. Для цього вірний формат тайтлу під час першого релізу має такий вигляд:

<ключові запити> — <бренднейм>

Буст працює лише перший тиждень після публікації застосунку у країні.

Помилка #58. Не запускати In-App Events та не використовувати ключові запити у полях, що індексуються

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

Індексуються наступні поля:

• назва івенту (30 символів);
• короткий опис події (50 символів).

Помилка #59. Не використовувати промо-покупки (Promoted in-app purchases) та ключові запити у назві

Користувачі можуть знайти вбудовані покупки прямо в App Store та підписатись перед завантаженням застосунку. 

Рекламні покупки, як і івенти, відображаються на сторінці застосунку, можуть відображатись у результатах пошуку, а також у розділах «Сьогодні», «Ігри» чи «Застосунки». 

У промопокупках індексується лише Title, максимальна кількість символів в якого — 30 символів. Сюди варто додавати популярні ключові запити, по яким ви вже знаходитесь на високих позиціях. 

Помилка #60. Не запускати ASA (Apple Search Ads)

Завдяки рекламі в сторах (ASA) можна покращити результати ASO-оптимізації. Завдяки Apple Search Ads є можливість:

• захистити свій бренд та показувати рекламу по запитам конкурентів;
• отримувати встановлення за тими запитами, за якими не вдається вийти на перші позиції за допомогою ASO;
• знаходити нові пошукові запити через Discovery Campaigns та розширювати семантичне ядро;
• відстежувати коефіцієнт конверсії по запитам.

Інші помилки.Google Play

Помилка #61. Не використовувати ключові слова у відповідях на відгуки

В Google Play відгуки індексуються, так само як і відповіді на них — тому це гарний спосіб просуватись по необхідним запитам.

Помилка #62. Не використовувати надписи на скріншотах з ключовими запитами

Є теорія, що в деяких випадках індексуються надписи на скріншотах в Google Play. Тому це також може бути додатковим способом просування застосунку по необхідним ключовим запитам. 

Поглиблюйтесь у вивчення просування мобільних застосунків та опановуйте професію «ASO-фахівець» з нуля разом з Choice31.

Помилка #63. Не запускати Google UAC

Google UAC (Universal App Campaigns) — додатковий спосіб просування застосунку. Така реклама показується всюди в Play Store, а також у пошуці, Google Play, YouTube, Discover в пошуці Google та контекстно-медійній мережі Google, щоб представити застосунок потрібній аудиторії. ASO необхідне для рекламних кампаній, тому що, основуючись на метаданих та скріншотах, Google розуміє, про що ваш застосунок, а також, де і як його просувати. Реклама необхідна для ASO, щоб підтримати та посилити органічну оптимізацію, збільшити видимість застосунку.

Лише поєднання ASO і UAC можуть принести максимальну користь та прибуток для розробника.

Помилка #64. Не використовувати Promotional Content 

Promotional Content (LiveOps) у Google Play — це контент всередині застосунку, великі оновлення або обмежені за часом події у застосунку, які ви можете демонструвати користувачам у Google Play, щоб підвищити залучення користувачів, стимулювати продажі та знизити відтік користувачів.

Рекламний контент може відображатись на вкладці «Ігри», на вкладці «Події», на сторінці зі списком магазинів або в результатах пошуку.

Ця функція дозволяє розробникам просувати різні події в додатку, вставляти глибоке посилання в подію та отримувати підвищення видимості у Play Store як для нових, так і для постійних користувачів.

Запускати Promotional Content важливо, тому що буде вплив на Explore трафік, так як застосунок з'явиться у підбірках.

Помилки ASO-спеціаліста при аналізі результатів

Помилка #65. Невірно вибирати період після релізу для моніторингу зміни позицій застосунку

В App Store зміни позицій після релізу варто відстежувати уже через 1-2 дні. У Google Play навпаки, відстежувати результати треба не раніше, ніж через 2 тижні після оновлення метаданих. 

Помилка #66. Аналізувати тільки позитивні зміни позицій

Важливо моніторити усі зміни — не тільки покращення позицій, а й їх погіршення:

 _{*Search Ads Popularity (SAP) — показує популярність запиту від 5 до 99.}

В App Store у випадку, якщо після релізу ви втратили позицію по релевантному запиту через те, що прибрали її з метаданих, необхідно зробити повторну ітерацію з ним, щоб повернути втрачені позиції (на це є 2 тижні):

Помилка #67. При зміні видимості застосунку приписувати цю заслугу виключно собі, як ASO-спеціалісту

Коли ASO-спеціаліст бачить зміни органічних показників, наприклад, їх зростання, варто спочатку детально розібратись, з чим це зростання пов’язано.

Перш за все, треба подивитись, за якими саме запитами відбулось зростання, а потім вже — з яких причин. 

Тут є кілька варіантів: 

• це заслуга ASO-спеціаліста, тобто покращення видимості відбулось в результаті зміни входження запиту в метадані;
• це може бути пов’язано зі зміною популярності даного ключа, і тоді це точно не заслуга ASO-спеціаліста. 

Для прикладу розглянемо зростання видимості застосунку по 2 запитам на основі EDI-графіку (Estimated Daily Impressions):

По першому запиту видимість змінилась саме після релізу, тому що вдалося зайняти високу позицію в результаті включення запиту в метаданих:

А по другому бачимо зростання популярності:

Помилка #68. Аналізувати лише кількість, а не якість нових позицій

Нові позиції для покращення видимості застосунку — це добре, проте треба ще враховувати, наскільки вони якісні.

Звісно, від позицій в ТОП-1 ви отримаєте один профіт, а від позицій в ТОП 2-3, чи 4-5 він уже буде зовсім інший:

До того ж, варто розуміти релевантність ключового запиту вашому застосунку. Наприклад, якщо по застосунку з тематики купівлі криптовалюти ви займете високу позицію по запиту Delta Airlines — чи принесе це вам інсталли, а тим паче покупки?

Помилка #69. Аналізувати лише кількість показів і не звертати увагу на кількість встановлень.

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

Помилка #70. Вважати, що зростання видимості застосунку по джерелу Browse, або зростання позиції в категорії напряму впливає на органіку

App Store Browse — це трафік з категорій, фічерінгу, добірок. Багато спеціалістів вважають, що дане джерело впливає на App Store Search, проте цей вплив лише опосередкований. Так, якщо користувачі часто зустрічають застосунок у різних добірках, вони можуть почати частіше його шукати через пошук, але прямого зв’язку тут немає. 

Позиція в категорії та по джерелу Browse піднімається за рахунок збільшення кількості встановлень застосунку із різних джерел:

Units (Web Referrer, App Referrer, Browse, Search, Search Ads)

Позиція застосунку в категорії:

Помилка #71. При аналізі зміни кількості показів по джерелу Search не звертати увагу на інші джерела трафіку

Маркетингова активність, результатом якої є трафік із джерел Search Ads, Web Referrer, App Referrer, призводить до зростання популярності бренду. Це, у свою чергу, також відображається на Search:

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

Помилка #72. При аналізі зміни конверсії не звертати увагу на інші джерела

Наприклад, в одному із застосунків ми оновили скріншоти 13.09, тепер спробуємо проаналізувати, як це вплинуло на конверсію:

На графіку бачимо зниження показнику конверсії із показів у встановлення, однак з 12.09 бачимо, що було збільшення показів із ASA:

Покази із ASA дублюються в органіку, а встановлення — ні. Так як зростання рекламних показників почалося якраз приблизно близько дати релізу з оновленням скріншотів, зниження конверсії після нього може бути пов'язане саме з цим.

Помилка #73. Не звертати увагу на сезонні або тимчасові події

На трафік застосунку часто впливають зовнішні фактори або сезонні події, які необхідно враховувати при аналізі. Для прикладу порівняємо трафік застосунків у категорії Shopping напередодні Чорної п’ятниці. 

Таким був графік минулого 2021 року (Чорна п’ятниця припала на 26.11):

Бачимо, що ще кілька днів після Чорної п’ятниці трафік у ніші ще тримався на високому рівні.

Тепер розглянемо цьогорічний трафік. Чорна п’ятниця була 25.11.2022:

На графіку чітко видно, що 24.11 відбувається падіння трафіку під впливом ракетних обстрілів України з боку росії. 

Тобто, при аналізі трафіку завжди важливо розуміти, що на зміни показників можуть вплинути певні сезонні або тимчасові події. 

Помилка #74. Не звертати увагу на циклічність

В деяких застосунках спостерігається явно виражена циклічність, тобто зростання і падіння трафіку може спостерігатись в певні дні тижня:

Тому для об’єктивності варто порівнювати зміни не просто до/після, а саме аналогічні періоди з урахуванням днів тижня або місяця.

Помилка #75. Прив’язуватись тільки до певного проміжку часу

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

Наприклад, у даному застосунку у нас був реліз 22.12, і ми хочемо подивитись зміни. На момент аналізу у нас пройшло приблизно 3 тижні. За логікою ми повинні вибрати період три тижні до і 3 тижні після. Ось що бачимо в такому випадку:

Видно, що покази застосунку збільшились. Але якщо подивитись більший проміжок часу, картина зовсім інша:

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

Висновки

Отже, як бачимо, в ASO-оптимізації, так як і в аналізі її результатів існує велика кількість помилок, які можуть впливати на процес просування застосунку у сторах. Сподіваємось, наша стаття буде корисною, і допоможе вам їх уникати.