Події, властивості й користувачі

Подія — це запис про те, що щось сталося. Кожен рядок логу подій відповідає на три запитання:

• хто: user_id, акаунт, який це зробив;
• що: назва події, як-от app_opened чи expense_added;
• коли: event_time, записаний в UTC, щоб телефони з різних часових поясів стали в один ряд.

Решта колонок — властивості події: подробиці саме цього моменту. Для expense_added вони кажуть, як внесено витрату (manual, receipt_scan, recurring) і на яку суму. Для settle_up_recorded вони містять суму та settlement_id. Колонка може бути порожньою, якщо до цієї події вона не стосується.

Корисна звичка — перш ніж щось рахувати, прочитати рядок як повне речення: «u020 вручну вніс витрату на 91 дол. у застосунку на Android о 18:12 UTC 4 червня». Якщо речення не складається, ти ще не знаєш, що саме рахуєш.

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

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

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

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

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

Чому це важливо: властивість події відповідає на «що сталося», властивість користувача — на «хто це зробив». Більшості продуктових запитань потрібні обидві, наприклад «чи додають люди з платних соцмереж більші витрати?» Береш події, знаходиш кожен user_id у таблиці користувачів і групуєш за властивістю користувача.

Більшість запитань поєднує обидві таблиці. «Чи додають люди з платних соцмереж більше витрат, ніж запрошені?» потребує витрат із логу подій і каналу з таблиці користувачів.

Стандартний хід — об'єднання (join) за user_id:

1. береш потрібні події, тут expense_added;
2. для кожного рядка шукаєш його user_id у таблиці користувачів;
3. додаєш потрібну властивість користувача, тут acquisition_channel;
4. групуєш й рахуєш за нею.

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

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

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

Ще два правила тримають лог придатним роками:

• Називай події як об'єкт плюс дієслово в минулому часі, однаково на всіх платформах: expense_added, group_created, invite_accepted. Якщо Android пише addExpense, а iOS — expense_added, кожен звіт показує дві половинки одного числа, поки хтось не помітить.
• Записуй те, від чого залежить рішення, а не кожне натискання й екран. Кожна подія має лишатися правильною в кожному релізі, і хтось має її перевіряти. Перегляд екрана заслуговує на подію, лише коли він потрібен для запитання, як-от показ paywall, бо важлива конверсія з нього.

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

Багато продуктових фактів ідуть парами: стан і момент, коли він змінюється.

• Бути на Halves Plus — це стан. Він належить людині як властивість користувача, наприклад plan = plus, щоб будь-який звіт можна було розбити на безплатних і платних користувачів.
• Почати тріал, перейти на оплату, скасувати — це зміни. Кожна стається в один момент, тож кожна є подією: trial_started, subscription_started, subscription_cancelled зі своїм часом.

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

Протилежна помилка — зберігати лише стан. Якщо є plan = plus, але нічого не записується в момент зміни, ти знаєш, хто платить сьогодні, але не знаєш, коли людина почала, тож не побудуєш воронку тріалу і не виміряєш конверсію за 7 днів.

Про кожен рядок питай: хто або що його спричинило? Зазвичай відповідь дає колонка platform.

Події застосунку (ios, android) записує телефон, коли людина щось робить. Вони фіксують реальні дії, але телефон без зв'язку може надіслати їх на хвилини чи години пізніше, а видалений застосунок останніх подій не надішле взагалі.

Серверні події (server) записує бекенд. Вони не губляться через поганий зв'язок, тож добре підходять для грошей і підписок. Але деякі з них стаються, коли застосунку ніхто не торкається. У Halves передплатники Plus можуть зробити рахунок регулярним, як-от оренду, і сервер додає таку expense_added за розкладом о 06:00 UTC, поки користувач, можливо, спить.

Тож platform = server з entry_method = recurring нічого не каже про те, чи людина користувалася Halves того дня. Якщо рахувати «людей, які додали витрату» просто за рядками, ці автоматичні витрати роздувають число. Щоб знати, чи людина користувалася продуктом, шукай її власні події із застосунку, як-от app_opened.

Коли відомо, що частину рядків спричиняє система, простий підрахунок змінює зміст. «Скільки людей користувалися Halves?» — це не «скільки id користувачів трапляється в лозі».

Надійна послідовність для невеликого уривка:

1. Відфільтруй рядки, які спричинила людина: тут platform дорівнює ios або android.
2. Випиши різні значення user_id, що лишилися, щоб кожна людина рахувалася один раз, скільки б рядків у неї не було.
3. Порівняй з нефільтрованим списком, щоб побачити, хто випав і чому.

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

Запиши, яке з них ти показуєш у звіті. Наступного уроку такі самі рішення визначать, скільки активних користувачів минулого тижня потрапить у звіт: 22, 19 чи 17.

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

У Halves у розрахунку беруть участь двоє. Платник його записує, а коли інша людина підтверджує, її телефон ще раз записує settle_up_recorded. Обидва рядки мають той самий settlement_id: s004 від u013 о 12:27 і від u014 о 21:22, обидва на 185 дол. Кожен рядок правдивий, але на запитання «скільки розрахунків?» відповідає кількість різних значень settlement_id: три рядки, два розрахунки. З грошима так само: три рядки дають у сумі 437 дол., а платежі — 185 + 67 = 252 дол.

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

Як це складається докупи: читай кожен рядок як речення; властивості кажуть, що сталося і з ким; колонка платформи — хто спричинив рядок; id — що таке одна одиниця. Далі урок Загальна кількість, унікальні користувачі й пастки підрахунку перетворює це прочитання на підрахунки.