Продуктові метрики й аналітика

DAU, MAU, конверсія, воронка, retention, churn

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

• DAU / MAU — унікальні активні користувачі за день / за місяць. Відношення DAU/MAU (stickiness) показує, яка частина місячної аудиторії повертається щодня. 0,2 означає, що користувач заходить у середньому в 6 днів із 30;
• Конверсія — частка тих, хто виконав цільову дію, серед тих, хто міг її виконати: покупка з візитів, реєстрація з переглядів сторінки;
• Воронка (funnel) — послідовність кроків із конверсією між ними: перегляд товару → в кошик → оформлення → оплата. Воронка показує, на якому саме кроці люди відпадають. Різке падіння на одному кроці після релізу — привід перевірити саме цей крок;
• Retention — частка користувачів, що повернулися через N днів після першого візиту (D1, D7, D30). Вимірюється по когортах, тобто за датою першого візиту;
• Churn — частка тих, хто пішов за період (для підписок — скасував). Приблизно «дзеркало» retention.

North star metric — одна головна метрика, що найкраще відображає цінність для користувача (наприклад, кількість тижнів-замовлень чи хвилин прослуханої музики). Її доповнюють guardrail-метриками (швидкість, помилки, скарги), щоб зростання головної не відбувалося коштом якості.

Пастка: vanity metrics — цифри, що гарно виглядають, але не пов’язані з цінністю (загальна кількість реєстрацій, кліки). Метрика корисна, коли від неї залежить рішення.

Як тестувати аналітичні події і tracking plan

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

Tracking plan — документ (таблиця, схема), що описує кожну подію: назву, коли вона спрацьовує, обов’язкові й необов’язкові властивості з типами, платформи. Він — «специфікація» для тестування аналітики. Без нього неможливо сказати, правильно подія відправлена чи ні.

Що перевіряють:

• Спрацювання: подія йде саме тоді, коли вона має (клік «Оплатити» ≠ успішна оплата), і не йде, коли не має;
• Назва: збігається з планом і зі стилем (checkout_completed, а не CheckoutDone);
• Властивості: усі обов’язкові на місці, правильні типи (сума — число, а не рядок), валюта, ідентифікатор товару, джерело. Порожні й null теж дефект;
• Дублікати: подія не відправляється двічі при перезавантаженні сторінки успіху, подвійному кліку, ретраї запиту, поверненні «назад»;
• Ідентифікація: після входу події прив’язані до користувача, анонімна сесія коректно зв’язується з акаунтом;
• Згода (consent): якщо користувач відмовився від трекінгу, дозволені події не відправляються (до і після відмови), а після зміни рішення поведінка оновлюється. Це не лише якість даних, а й вимоги законодавства;
• Платформи: web, iOS і Android відправляють однакові назви й властивості.

Як дивитися: вкладка Network у DevTools (запити до сервісу аналітики), режим debug у самому інструменті (GA4 DebugView, Mixpanel/Amplitude live view), proxy на кшталт Charles. В автотестах можна перехоплювати запити й порівнювати з очікуваною схемою.