Із 42% користувачів сайтів знайомств, які прагнуть створити родину, лише 13% насправді заручаються або одружуються завдяки онлайн-дейтингу: цим аналітичним висновком з Laba поділився Андрій Лузан — Chief Analytics Officer AdConnect в українській продуктовій IT-компанії appflame. Андрій вже понад 8 років спостерігає за поведінкою користувачів та змінами метрик продуктів компанії. У цьому тексті він підсумовує досвід і ділиться професійними болями та мріями.
Матеріал буде цікавим для аналітиків та всіх, хто хоча б час від часу працює з даними: від SMM-менеджера, якому інколи потрібно аналізувати охоплення дописів, до власників бізнесу, що хотіли б краще розуміти потенціал та цінність, яку аналіз даних може принести їхній компанії.
*Цей матеріал є частиною спецпроєкту Laba «Інсайт за донат», де українські топменеджери діляться своїм досвідом у журналі, а Laba у вдячність за їхній час та експертизу купляє дрони для ЗСУ. Один матеріал циклу — один FPV-дрон для 3 ОШБр.
Привіт, мене звати Андрій Лузан, і я Chief Analytics Officer AdConnect в українській продуктовій IT-компанії appflame. Серед продуктів компанії — застосунки для знайомств Hily й Taimi та окремий напрям AdConnect, що спеціалізується на побудові платформ для спілкування, а також SaaS-рішень для роботи з трафіком і підвищення ретеншену користувачів.
За понад вісім років в аналітиці я пройшов чималий шлях — від двох вищих освіт (КНУ ім. Тараса Шевченка та KSE) та стажера-аналітика до керівника команди аналітиків. Зараз у моїй команді 10 фахівців (Product Analyst, Data Analyst, Data Scientist та AdTech Analyst), і щодня ми збираємо дані та досліджуємо поведінку користувачів, щоб інші відділи могли покращувати продукти компанії.
Я обожнюю аналітику, та за свій кар’єрний шлях чого я тільки не бачив. Саме це наштовхнуло мене на ідею написати цю статтю. Можу лише сподіватися, що це буде комусь корисно, комусь допоможе в роботі, а когось надихне реалізувати хоча б частину вказаних мрій.
Що найбільше болить аналітикам?
Мабуть, найнеприємніший біль аналітика — коли даних ще немає, а питання, на які дані могли б відповісти, вже є. Зазвичай це стається, коли бізнес, продукт, напрям чи фічу запустили, а аналітика до процесу вчасно не долучили. Іноді таке трапляється, коли у проєкті не до цього або немає бюджету на аналітика. А іноді — просто тому, що аналітика забули запросити на мітинг. Тоді приходиться викручуватись і знаходити спосіб оцінити потрібні значення.
Складність сучасних продуктів весь час зростає, і разом із цим загострюється потреба в оцифруванні та оцінюванні поточного стану справ. Для цього необхідні дані. Наявність потрібних даних на старті будь-якого проєкту (хоча б під’єднані Google Analytics або Amplitude) створює поле для роботи аналітика. А в перспективі — суттєво спрощує та покращує процес ухвалення рішень. Тому варто закладати аналітичний фундамент вже на старті проєкту.
Інший біль аналітиків часто криється у відчутті, що їхні старанно зібрані та проаналізовані дані залишаються непоміченими та невикористаними. Це може створювати враження, що всі години, проведені за збором, очищенням, аналізом даних та представленням інсайтів, були витрачені даремно. Це не лише демотивує аналітиків, але й не дає компанії чи проєкту здобути цінність. А ще — призводить до втрати потенційної цінності для компанії чи проєкту.
Вcе це свідчить про прогалину в комунікації та взаєморозумінні між аналітиками й тими, хто ухвалює рішення, підкреслюючи необхідність для організацій знайти способи ефективнішого використання аналітичних зусиль.
Існує ще чимало болів (зокрема й тих, які я згадуватиму в мріях нижче), але я переконаний, що якби всі залучені сторони розуміли це, їх можна було б уникнути, а разом із цим — і підвищити ефективність роботи всіх залучених сторін та досягати кращих результатів.
Мрія 1. Щоб дані завжди були повними, актуальними й консистентними (без протиріч одне одному)
Аналітика — це не тільки метрики й цифри, а й повноцінна історія на їхній основі. Дані мають бути повними та коректними, бо з огляду на них аналітик вибудовує сюжет. А в хорошому сюжеті немає прогалин чи неточностей.
Зростання кількості даних позитивно корелює з розвитком та масштабуванням бізнесу або продукту. Згадайте, колись у вас не було жодних звітів, а зараз ви тонете в них. Ви вже не можете знайти те, що вам потрібно. А ваш колега із сусідньої кімнати знайшов десь інші дані та користується ними. Розходження в даних — це постійна історія в аналітичній роботі. Причин для цього може бути кілька.
- Перша — дані взяті з різних джерел.
Наприклад, відділ продажу застосовує зручний інструмент для трекінгу даних, який використовується з самого початку проєкту, і до нього всі звикли. Менеджери звіряються з ним з операційних питань: наприклад, скільки було кліків по банеру, яка конверсія в оплату та який дохід з цих кліків.
Водночас на самому продукті, звідки йдуть ці кліки, є власна система трекінгу, на основі якої працюють інші частини продукту (наприклад, ціноутворення чи рекомендації). І часто виникають ситуації, коли команда продукту бачить одні дані, а команда продажів — інші. Це створює зайвий клопіт для аналітиків, тестувальників і інших залучених фахівців. - Друга причина — різний метод розрахунку.
Наприклад, ми завжди можемо розрахувати початок сесії: це стається, коли користувач клікає по іконці застосунку, і застосунок відкривається на повний екран. Але як виміряти час завершення сесії? Якщо, скажімо, один і той же користувач за 10 хв закриє застосунок, за 3 хв отримає сповіщення і перейде в месенджер, а за 15 хв повернеться назад. Запитання для аналітика: скільки треба чекати, щоби вважати, що сесія закінчилася?
Просте розв’язання для цих прикладів — застосування підходу Single source of truth, коли існує єдина база даних, куди стікається вся інформація про проєкт. Ця інформація обробляється і складається в потрібному вигляді. Й нею можуть користуватись усі відділи.
Можливість оцінити показники альтернативним способом — гарна підстраховка, але існування одного сховища даних, якому всі довіряють, сильно економить час на доуточнення і валідацію (коли є декілька варіантів розрахованих метрик). Це дає змогу всім бути on the same page.
Мрія 2. Розуміти, на яке все ж таки питання відповідає аналітик
Гарний аналітик відповідає не лише за свою частину роботи — він знає, що важливо для розробки, маркетингу, продакт-менеджера та користувачів. Поєднуючи всі ці потреби, він може запропонувати саме ті рекомендації, які можуть розв’язати питання. Але правильні запити аналітики отримують рідко, і це велика проблема.
Часто до аналітика приходить колега та замовляє дані, вважаючи, що вони допоможуть розв’язати якесь питання, яке лежить в його зоні відповідальності.
А коли замовник починає використовувати ці дані, раптом розуміє, що вони йому не підходять: не дають відповіді на його питання та не розв’язують проблему.
Якби замовник у ТЗ писав не ЯКІ дані потрібні, а ЯК ці дані будуть використані в його роботі, аналітик підказав би, яким набором даних можна розв’язати його проблему — та зібрав би їх.
Мрія 3. Швидко знаходити спосіб розуміти дані або відкопати «магічний сегмент»
Дуже хочеться мати магічну кулю, яка підкаже тобі причину відхилення метрики або системи від очікуваних значень та надасть вичерпну відповідь, що саме сталось і чому.
Іноді відповідь лежить на поверхні, особливо якщо в аналітика є заздалегідь підготовлений план перевірки подібних відхилень. Але деколи потрібно досить сильно закопатися в дані.
Тут на допомогу приходить сегментація і кореляційний аналіз.
Наприклад, досить давно в мене був випадок, коли трафік, який закуповує відділ performance marketing, переставав перфомити як очікувалося — за певним джерелом трафіку фінансові показники падали. З першого погляду все було нормально — конверсія в платника і дохід з першої оплати були в порядку, змін у тарифних планах не було, але далі було стрімке погіршення з платежами на продукті (оплати за користування).
Стали розбиратися глибше — й з’ясували, що частина трафіку почала використовувати для оплати на продукті подарункові карти (вони досить популярні в США). Їхня особливість в тому, що вони мають певну суму й далі не поповнюються. Відповідно, на подальші регулярні платежі від таких користувачів розраховувати не варто.
З досвідом гарний аналітик здобуває «надивленість» — коли ти бачив десятки різних варіантів того самого, але з іншими відтінками, і тому швидко розумієш, що щось пішло не так. Джерелом «надивленості» може бути як власний досвід, так і спілкування з командою, де кожен може запропонувати своє бачення причини відхилення; прочеленджити бачення інших тощо — і пазл складається!
Мрія 4. Щоб кожен колега мав зручний та автоматизований інструмент аналітики
Коли заходиш на LinkedIn, бачиш свій допис та всю динаміку реакцій на нього (9,9 тис. переглядів, майже півтори сотні кліків). Це простий та нативний аналітичний інструмент. Моя мрія — щоб схожий інструмент мав кожен співробітник у своїй роботі. Щоб цей інструмент завжди був під рукою, давав відповіді на всі питання та візуалізував потрібні дані за секунди.
Такі інструменти часто розроблюються компаніями самотужки. Також на ринку є чимало розробників із Self-Service аналітики — це коли будь-хто в компанії без підготовки може зручно взаємодіяти з інформацією і робити висновки самостійно. Найпоширенішими зараз є Tableau та Power BI.
В AdConnect ми розробляємо багато дашбордів для колег, й одна з вимог — щоб дашборди оновлювалися до 10 секунд. Тобто щоб поки завантажуються дані, колега не пішов готувати собі каву чи читати новини в Telegram :)
Але тут є низка проблем.
- Перше — обсяги даних. Це десятки терабайтів, які потрібно зберігати та обробляти на льоту. Для цього потрібні професійні Data Engineer’и.
- Друге — дашборди швидко втрачають свою актуальність. Це стається через появу нових більш свіжих даних — або ж змінюються бізнес-вимоги (значні зміни на продукті чи нова стратегія бізнесу/продукту) чи потреби в даних. Ми постійно покращуємо наші дашборди, але це динамічний процес, у якому ніколи не вдасться знайти ідеальну точку.
Мрія 5. Автоматизувати всю рутинну аналітичну роботу
Мрію розробити рішення, що автоматизують майже всі рутинні завдання аналітика і звільнять руки для складніших і більш творчих аспектів роботи з даними.
Ми вже автоматизували звіти, прогнози, рекомендації, моніторинг, альортінг за ключовими метриками та A/B-тестами. Більша частина формується та надсилається автоматично. Але що я хотів би ще автоматизувати, то це детекцію змін на пересіченні багатьох сегментів.
Наприклад, у нас є продукт, в якого 10 джерел трафіку (який закуповує performance marketing), 10 країн, 2 платформи (Android та iOS), всі гендери та 5 вікових категорій. Якщо помножити комбінаторно всі ці фактори, то вийде 1000+ сегментів. Зараз у нас є моніторинг змін, але він здебільшого ручний: 5 колег аналізують кожен свій шматочок даних та ставлять запитання для глибшого дослідження, якщо зміни стаються. Це завдання забирає 15–20 хв щодня.
Якби цей час вивільнився, аналітик зміг би досліджувати важливіші питання, знаходити важливіші зв’язки чи виявляти проблеми, неочевидні на перший погляд, а так необхідно з дня на день до пів години часу просто вдивлятися в купу даних.
Я хотів би розробити моніторинг, у якому всі ці сегменти автоматично відстежуватимуться. І якщо виникне проблема, система самостійно про неї повідомить.
Мрія 6. Отримувати швидкі результати
Мрію запускати A/B-тести, які матимуть вплив на найглибші метрики (конверсія в цільову дію, ретеншн, конверсія в оплату тощо) вже за тиждень, а не через 3–5 місяців, як того вимагає статистична значущість. І насправді таких результатів реально досягти. Є лише одне «але» — це в основному можливо лише на початкових етапах розробки продукту.
Коли продукт ще не оптимізований, бо нещодавно запустився, то куди не подивись і що не тестуй — будуть суттєві покращення.
- Перший етап розвитку аналітики на проєкті — це коли аналітик має багато «фруктів, що низько висять», тобто покращень, які приносять результат тут і зараз.
- Другий етап розвитку аналітики — коли аналітик переходить до агрегації даних, починає шукати зв’язки, які є очевидними.
Наприклад, якщо користувач отримав взаємний лайк, то ймовірність того, що він повернеться (retention rate), збільшується на 10%. Це наступний етап розвитку аналітики. - Подальший етап — коли аналітик мусить оптимізувати оптимізоване та шукати приховані (неочевидні) зв’язки. І ось тут вже можуть стати в пригоді Data Science моделі. Але навіть із DS-моделями покращення можуть бути в реальності незначними.
Мрія 7. Розробити ідеальну модель, яка пояснить все
Десь чув вислів «Будь-яка модель є неправильною, але деякі з них є корисними». Під моделлю заведено розуміти спрощену копію об'єкта або системи, яка допомагає дослідити властивості оригіналу.
Ідеальної моделі в реальності не існує, бо це був би сам оригінал. Будь-яка модель — це спрощення, що не враховує тих чи інших нюансів. Але це не заважає мені мріяти про те, щоб одного разу розробити таку модель процесу чи бізнесу, яка зможе описати 99,99% станів системи.
Хороша новина в тому, що ми все ще можемо будувати непогані моделі, які допомагають пояснювати процес, продукт, бізнес чи світ. Зазвичай непогана модель — це питання досвіду. До неї приходять еволюційно, поступово додаючи нові пазлики або прибираючи зайві. Модель покращується тоді, коли її попередня версія зазнає краху. У нас це трапляється досить часто (ледь не щомісяця) через динаміку бізнесу та змін. Тоді ми з’ясовуємо, чому попередня версія була недосконалою, і намагаємося врахувати це в новій.
Непоганою моделлю може бути як складна система метрик, так і набір двох-трьох метрик — якщо їх достатньо, щоби пояснити поведінку системи. Для аналітика важливо розуміти обмеження кожної моделі та контекст, в якому її використання є доречним та корисним.
Наприклад, в поведінці користувача дуже часто застосовується когортний аналіз (група користувачів об'єднана за датою певної події, найчастіше — за датою реєстрації). Ці когорти поводять себе доволі стало, якщо немає якихось великих змін. Тобто користувачі, які зареєструвались у квітні, за метриками активності будуть схожі на користувачів у березні (якщо в трафіку і в продукті немає різких змін). Когортний аналіз гарно поєднується з сегментацією. Використовуючи досвід минулих когорт і розуміючи структуру сегментів, можна спрогнозувати подальшу поведінку користувачів — і, відповідно, й метрик.
Мрія 8. Вирости до Data Scientist
Я регулярно співбесідую аналітиків та за роки своєї роботи найняв декілька десятків, частина з яких вже виросла до Team Lead, Head, CPO. На інтерв'ю на запитання «Чого ти хочеш досягнути?» частина кандидатів часто відповідає, що хотіла б почати з простого: розібратися в продукті чи в аналітиці, побудувати класну фічу або продукт. А потім, коли все це зроблять, вони хотіли б перейти у Data Science. Тобто наука про дані — це така вершина аналітичної кар’єри (на їхню думку). Мене це завжди тішило, адже аналітика — це по суті і є Data Science.
На мою думку, кандидати мріють про це, бо:
- за останнім опитуваннями DOU в Data Scientist продовжують зростати зарплати
- вони вважають, що їхні власні моделі значно покращуватимуться та з часом ще точніше моделюватимуть світ
Багато хто з них проходить курси з Data Science, а потім пробують використовувати ці моделі в аналітичній роботі. Як експеримент це може бути, але тут є багато підводних каменів. Щоб застосовувати будь-яку модель, потрібно розуміти межі її використання. Деколи модель із Data Science геть не підходить через неправильну екстраполяцію (як в мемі нижче), але це не заважає молодому аналітику прийти й похвалитися, що він у роботі вже може застосовувати такі просунуті моделі.
За моїми спостереженнями, такі моделі часто не доходять до продакшену: 80% лежать як R&D-дослідження.
Мрія 9. Про світ відкритих даних
Наостанок я мрію про те, що б відкритих даних ставало дедалі більше. Відкриті дані — концепція вільного доступу до певних даних для використання і розповсюдження.
З ними стає більше можливостей для розвитку нових продуктів і послуг. Застосування відкритих даних може бути корисним у різних сферах: від розвитку та масштабування бізнесу або продукту — до наукових досліджень, розробки міських планувань, стратегій сталого розвитку, покращеного моніторингу ефективності держпослуг.
Наприклад, Google Maps у співпраці з EasyWay інтегрує інформацію про громадський транспорт (деталі маршрутів, графіки, дані про перевізників тощо) та відстежує місцезнаходження в реальному часі. Цей процес дозволяє картографічним сервісам підібрати оптимальний маршрут та розраховувати ціну проїзду й очікуваний час у дорозі, а пасажирам — заощаджувати час та гроші.
Уявіть, якою б могла бути сфера медичного обслуговування, якби ми мали доступ до інформації про всі доступні послуги поряд: їхню якість, відгуки, ціну та можливість записатися на прийом. Завдяки більш усвідомленому вибору сфера розвивалася б значно швидше. А тепер уявіть, якою б могла бути ваша робота!
Я хотів би жити у світі відкритих даних, адже в такий спосіб ми відкриваємо перед собою шлях до значно ефективнішого використання даних та найсміливіших мрій. Особисто я вважаю, що мріяти не тільки корисно, а й необхідно, оскільки амбітні цілі спонукають нас до розвитку та досягнення більшого, ніж ми маємо зараз.
Було б цікаво почути, чи відкликаються вам мої 9 найголовніших ідей та які аналітичні мрії маєте ви. З великим задоволенням поспілкуюся з вами тут у коментарях під статтею або в LinkedIn.
Бажаєте отримувати дайджест статей?
