Hotjar мобільний SDK: де ламається збір теплових карт
Теплові карти застосунку ламаються тихіше, ніж на сайті: збір подій формально триває, звіт відкривається, але картинка не збігається з реальністю.
Майже весь брак дають три причини — втрачена прив’язка до елементів, обірвані сесії на слабкій мережі та розповзається розмітка екранів після релізу.
Перший збій — події не прив’язуються до елементів. Мобільний інтерфейс збирається з перевикористовуваних контейнерів, у яких немає стабільних ідентифікаторів: обробник стоїть на кореневому шарі, і натискання йде в нього, а не в конкретну кнопку. У звіті такі кліки згортаються в одну точку, і карта показує активність там, де її немає.
Другий — втрачені сесії. Події накопичуються в буфері й вирушають пакетами, а якщо мережа зникла, застосунок пішов у фон або система вивантажила процес, буфер зникає.
Без запису на диск і повторного надсилання втрачається до третини сесій, причому нерівномірно: випадають саме довгі сценарії, де користувач іде в підекран і повертається.
Третій — розмітка екранів після оновлення інтерфейсу. Якщо прив’язка тримається на позиції елемента в дереві, перестановка блоків зсуває всі ключі, і дані попередньої версії накладаються на нову.
Лікується стабільними ключами на кожному інтерактивному елементі та версією схеми екрана в самій події — старі й нові зрізи більше не змішуються.
Розбираємо, як це закривається: де потрібні правки в обв’язці мобільного SDK, де — у розмітці екранів, а де — у прийманні та зберіганні подій.
Що дає коректна теплова карта в застосунку
Поекранна теплова карта відповідає на питання «куди натискають», але не на питання «чому не доходять».
Коли події прив’язані до стійких ідентифікаторів елементів, а не до координат дотику, збір дає наскрізний шлях користувача: видно екран входу, повернення назад і крок, на якому воронка екранів обривається. Знаходиться не «негарна кнопка», а конкретний перехід, що втрачає помітну частку аудиторії.
Якість даних тримається на двох речах — прив’язці до елементів інтерфейсу та єдиній схемі найменування подій. Без них карта бреше системно: прозорі зони з’являються там, де фактично лежить перекривальний шар, а «мертві» області — там, де розмітка просто не спрацювала.
Помилкова розмітка небезпечніша за її відсутність: вона дає впевнені, але неправильні рішення. Типовий збій — елемент перейменували або перенесли, подія продовжує йти на стару прив’язку, і команда оптимізує блок, якого в поточному збірці вже немає.
На нових версіях інтерфейсу поведінка розмітки має бути передбачуваною: перед релізом звіряємо події з деревом екранів, і розходження ловиться до викладки, а не через тиждень за дивними цифрами.
Збір організовуємо на боці застосунку, а Hotjar використовуємо як вітрину — карти, записи сесій і воронки в одному вікні. Тоді рішення щодо інтерфейсу спираються на дані, а не на здогадки.
Способи збору: хмарний сервіс, власний збір, гібрид
Вибір способу збору поведінкових даних диктує не зручність панелі, а те, які події застосунок готовий віддати назовні й що з ними дозволено робити далі.
Хмарний сервіс аналітики бере приймання, зберігання та візуалізацію на себе, але накладає свої правила на склад подій і частоту їх надсилання.
Власний збір подій знімає ці правила, зате додає власний конвеєр приймання, сховище та відмалювання карт — це окремий контур в експлуатації. Гібридна схема ділить потік: знеособлена телеметрія йде в хмару, чутливі події залишаються всередині периметра.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарний сервіс аналітики | Теплові карти та записи сесій потрібні швидко, своєї інфраструктури немає | Обмеження збору: частину подій доводиться відкидати, дані лежать на боці постачальника |
| Власний збір подій | Жорсткі вимоги до зберігання та складу даних, нестандартна розмітка нативних екранів | Своє приймання, сховище та візуалізація, потрібна команда на підтримку |
| Гібридна схема | Частина метрик потрібна швидко, частина не повинна покидати контур | Складніше узгодити схему подій і прибрати дублі між контурами |
Hotjar — приклад хмарного шляху: у мобільному застосунку він дає менше, ніж у вебі, бо нативні екрани доводиться розмічати вручну, а карти будуються за обмеженим набором подій. Якщо такої повноти достатньо, хмара виграє за строками; якщо ні — рахуємо гібрид або власний збір.
Впровадження збору теплових карт: етапи робіт
Теплова карта викривляє картину, якщо дотики прив’язані до координат екрана, а не до елементів: на іншій роздільній здатності, у темній темі або після переверстки точки з’їжджають і малюють неіснуючі проблеми.
Тому збір не вмикають одним перемикачем, а розгортають кроками — від аудиту до регламенту для команди, яка додаватиме події далі.
- Аудит розмітки. Проходимо екрани та стани: що розмічено, де події дублюються, де губляться на переходах між вікнами та після авторизації.
- Схема подій. Єдиний довідник: ім’я, параметри, момент надсилання, прив’язка до елемента. Правила найменування фіксуємо відразу — інакше за одним тапом з’являться п’ять різних подій.
- Налаштування збору. Підключаємо Hotjar у тестовій збірці, вмикаємо запис сесій і карти дотиків за довідником, перевіряємо на реальних пристроях і версіях системи, а не лише в емуляторі.
- Контроль повноти. Звіряємо потік із продуктовою аналітикою: частка дотиків, що дійшли, пропуски на переходах, розходження між платформами.
- Приймальна перевірка. Прогін за чек-лістом на релізній збірці: втрата мережі, відмова надсилання, оновлення екрана. Збір не повинен блокувати інтерфейс і розтягувати час відгуку.
- Передача команді. Документація з розмітки та регламент ревізії перед релізом: хто додає подію, де її перевіряє і коли видаляє застаріле.
Далі схема живе за цими правилами, а не за смаком окремого розробника: нові екрани розмічуються так само, застарілі події видаляються. Тому карти залишаються читабельними через десяток релізів, а не перетворюються на набір несумісних даних.
Схема подій, маскування полів і регламенти
Схема подій — такий самий артефакт проєкту, як конфігурація збірки: вона передається разом із кодом, а не залишається в листуванні. Нижче склад комплекту, за яким інженер вмикає збір за день, а аналітик будує звіти без правок у застосунку.
- Реєстр подій: ім’я, сенс, екран, місце виклику, склад властивостей і відповідальний. Кожне ім’я звіряється з реальною версткою, щоб у схемі не залишилося мертвих подій.
- Правила найменування: шаблон «розділ_дія_результат» у нижньому регістрі, ліміт довжини, заборона скорочень і версій в імені — інакше одна дія обростає дублями й воронка не сходиться.
- Політика маскування: перелік полів, які не йдуть у відкритому вигляді — телефон, пошта, платіжні реквізити, вільний текст. Для кожного вказано спосіб заміни на маску або незворотний хеш і точка перевірки до надсилання.
- Політика збору: що пишеться до згоди, як враховується відмова, скільки живуть вивантаження й як видаляються за запитом.
- Карта екранів і переходів: ключові маршрути розмічені, видно, де сценарії розходяться між платформами і які шляхи не покриті.
- Регламент змін: у документа є версія й власник, правка схеми йде разом зі зміною інтерфейсу, застарілі події виводяться з обігу за планом.
- Інструкція з перевірки: як переконатися, що подія йде з потрібними властивостями, і як вимкнути збір у внутрішній збірці.
Окремо фіксуємо, які звіти в Hotjar будуються на цих подіях, — щоб панель не перетворювалася на звалище.
Кейс: частка втрачених сесій упала до одиниць відсотків
У застосунку з щільним потоком користувачів запис сесій доходив фрагментами: перехід у фон, зміна орієнтації екрана й швидкі переходи між розділами обривали запис.
У звітах із теплових карт бракувало частини натискань — за вимірами губилося близько 40% подій, а в окремих сценаріях ланцюжок розпадався на середині. Команда ухвалювала рішення за викривленою картиною: «мертві» зони на карті виявлялися ділянками, де даних просто не було.
Що змінили
Збір перевели на Hotjar не «як є»: кожному екрану присвоїли стабільний ідентифікатор, а ключові дії розмітили окремими подіями зі зрозумілими іменами.
Це прибрало прив’язку до номера екрана в навігації — раніше після перейменування розділу події з’їжджали в чужу гілку й статистика змішувалася. Окремо налаштували поведінку при обриві зв’язку: записи ставляться в чергу й ідуть на сервер за наступного запуску, а не зникають.
Метрики до і після
Частка втрачених сесій упала з 40% до 3-4%, повнота ланцюжка екранів у ключовому сценарії зросла з 58% до 96%. Розмітку нового екрана тепер випускають за один-два дні замість двох тижнів: ідентифікатори та події описуються декларативно, без правок у коді навігації.
Клас відмов «сліпі зони в аналітиці» закрито — теплові карти будуються на безперервних записах. Перевірка змін в інтерфейсі йде за фактичною поведінкою, а не за здогадками про те, куди користувач «мав» натиснути.
Що робити, якщо Hotjar уже розгорнуто в застосунку?
Якщо Hotjar уже розгорнуто, перевстановлювати нічого не потрібно — питання в діагностиці. Найчастіше дані неповні не через інструмент, а через порядок ініціалізації: збір піднімається пізніше за перший екран, і частина переходів минає раніше, ніж відкрився сеанс.
Перевіряємо по порядку: чи стартує збір до відмалювання першого екрана, чи передається ідентифікатор екрана в усі переходи, чи не глушить надсилання згода на обробку даних, чи не дублюються події при поверненні з фону. Такий прогін відокремлює хибні спрацювання від реальних прогалин у розмітці.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Точкова правка розмітки | Збір працює, але екрани та елементи названі довільно | Старі зрізи залишаються, але погано зіставляються з новими |
| Перескладання подій на поточному шарі | Структура екранів змінилася після релізу | Потрібен єдиний довідник імен і правки в кількох місцях |
| Перехід на інший збір | Можливостей поточного не вистачає: немає потрібних карт, високе навантаження | Потрібен період паралельного збору для звірки |
| Власний шар аналітики | Потрібен повний контроль над даними та вивантаженням | Підтримку беремо на себе, зростають вимоги до супроводу |
Міграцію розмітки робимо без обриву історії: імена екранів і елементів фіксуємо в довіднику, старі події не видаляємо, а позначаємо, новий збір вмикаємо за перемикачем. Так з’являється період паралельних даних, де видно, що розходження в поведінці, а не в розмітці.
Сумніви щодо точності даних і приватності
Запис дотиків у мобільному застосунку відновлюється за координатами жестів, а не за відеопотоком екрана. Якщо елемент відмальований нативним шаром поверх вікна, на тепловій карті він з’явиться, але прив’язка до вузла інтерфейсу зсунеться — і карта почне брехати.
Тому ми звіряємо розмітку екранів з ієрархією представлень і позначаємо контейнери явними ідентифікаторами: тоді записи одного й того самого екрана лягають в одну карту, а не в п’ять різних.
З приватністю працюємо на рівні збірки: значення полів введення маскуються й не покидають пристрій, назовні йде лише факт заповнення.
Екрани з платежами, документами та особистим кабінетом потрапляють до списку винятків, а старт збору Hotjar прив’язаний до згоди користувача — до його підтвердження запис не запускається взагалі.
Запис сповільнить застосунок?
Надсилання даних іде асинхронно й пакетами, а не в момент дотику. На слабких пристроях ми обмежуємо частоту опитування й вимикаємо зняття важких екранів, тому на час відгуку впливає не збір, а сам розбір записів у звітах.
Персональні дані можуть потрапити в запис?
Технічно — лише те, що розробник не замаскував. Ми проходимо по всіх формах і списках, позначаємо поля з іменами, телефонами та адресами як приховані, а доступ до перегляду записів видаємо за ролями й обмежуємо терміном зберігання.
Чи зросте розмір збірки?
Бібліотека мобільного SDK — це частки відсотка від ваги застосунку. Приріст заміряємо до релізу в тестовій збірці й, якщо він виходить за обумовлений поріг, переносимо ініціалізацію у відкладений запуск.
Обговоримо задачу — повернемося з оцінкою та планом робіт
Щоб повернутися з планом впровадження та оцінкою робіт, а не із загальними словами, нам потрібно зрозуміти, як влаштований ваш застосунок і що ви хочете побачити в даних.
Розкажіть задачу: які питання про поведінку користувачів залишаються без відповіді й які рішення ви збираєтеся ухвалити за підсумками — від цього залежить схема розмітки та глибина запису сесій.
Корисно дізнатися до початку:
- платформа й актуальна гілка фреймворку, чи є нативні вставки та модулі різними мовами;
- що вже розмічено й куди збирається аналітика — щоб не дублювати події та зберегти наступність звітів;
- ключові сценарії за пріоритетом: реєстрація, оплата, пошук, оформлення замовлення — під них налаштовується запис і воронки;
- вимоги приватності: які поля не можна записувати, чи потрібні маскування та явна згода користувача;
- доступи: репозиторій або архів проєкту, тестові збірки, обліковий запис у Hotjar з правами на проєкт, канал для збірки та розповсюдження білдів;
- обмеження релізного циклу — як часто викочуєтеся й чи є вікна, куди можна вбудувати зміни.
У відповідь ви отримаєте план впровадження за етапами з порядком робіт і залежностями, оцінку робіт за трудозатратами та склад матеріалів, що передаються: конфігурацію проєкту, схему розмітки подій, політику маскування чутливих даних, інструкцію для команди та нотатки з експлуатації.
Опишіть задачу у зручному вигляді — коротким листом або дзвінком на 30 хвилин. Ми поставимо уточнювальні запитання й повернемося з планом та оцінкою.
