Загальна кількість, унікальні користувачі й пастки підрахунку

З одного логу виходять два підрахунки, і вони відповідають на різні запитання.

• Загальна кількість подій рахує рядки: кожну подію, разом із повторами. Експорт Halves за минулий тиждень має 147 рядків.
• Унікальні користувачі рахують людей: кожного, хто має хоча б один рядок, один раз. У тому самому експорті їх 22.

Різницю створюють активні користувачі. У u014 цього тижня 12 рядків, а в u005 — один. У загальній кількості подій u014 важить удванадцятеро більше, а в унікальних користувачах вони важать однаково.

Тому загальна кількість подій може рости, коли база користувачів стоїть на місці. Якщо одна людина відкриє застосунок на десять разів більше, загальна кількість зросте на 10, а унікальні користувачі не зміняться. Графік «подій за тиждень», що йде вгору, каже, що продуктом користувалися більше, а не що ним користувалося більше людей.

Перш ніж рахувати, вирішуй, чи запитання про людей («скільки людей користувалися?») чи про дії («наскільки активно користувалися?»). «Активні користувачі» — це завжди запитання про людей.

Активність має означати, що людина щось зробила, а «користувачі з будь-яким рядком у лозі» — це інше число. Як показав урок Події, властивості й користувачі, деякі рядки записує сервер без участі людини.

У лозі минулого тижня 22 різні user_id. Троє з них, u001, u005 і u015, з'являються лише через понеділкові регулярні рахунки (platform = server, entry_method = recurring): за тиждень вони жодного разу не відкрили застосунок. Вони важливі як платні передплатники Plus, але активними не були.

Просте правило для Halves, яке можна перевірити: відкрив застосунок хоча б раз за тиждень (app_opened). Підрахунок різних user_id серед рядків app_opened дає 19, як і 22 − 3.

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

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

У нього впізнаваний патерн. У лозі Halves за минулий тиждень два акаунти мають по 20 рядків, і кожна витрата — рівно 1 дол.: тестувальники додають дрібні суми, щоб перевірити, що застосунок працює.

Очевидне рішення — прапорець is_internal. Але прапорці ставлять люди, а люди забувають. Прапорець ловить u019; у u002 поле is_internal порожнє. Його видають acquisition_channel = staff і поведінка.

Тож підрахунок іде так: 19 людей відкрили застосунок, 18 після видалення акаунта з прапорцем і 17 після видалення всіх акаунтів команди. Число 18 не виглядало б хибним, і саме тому воно небезпечне.

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

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

Надійне правило виключення має три частини:

1. Кілька ознак, поєднаних через АБО. У Halves: is_internal = true або acquisition_channel = staff. Кожна ловить те, що пропускає інша.
2. Записаний список. Тримай виключені user_id і причину для кожного в одному місці, яким користуються всі, щоб двоє аналітиків не фільтрували по-різному.
3. Регулярна перевірка. Раз на тиждень чи місяць шукай нові акаунти з тестовим патерном: багато дрібних круглих витрат, реєстрація з офісної мережі, командний домен пошти. Додавай їх до списку.

Тоді правило стає частиною винятків метрики, записаних поруч із числом: «без акаунтів команди (прапорець або канал staff)». Хто перерахує за тим самим правилом, отримає той самий результат.

Якщо сумніваєшся, покажи, скільки акаунтів прибрав фільтр. «17 користувачів, виключено 2 акаунти команди» викликає правильні запитання, а мовчазне 18 — ні.

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

Theo хоче «витрати, додані минулого тижня» для сторінки в магазині застосунків. У лозі 60 рядків expense_added. Дві групи з них додали не клієнти в застосунку:

• 5 регулярних рядків, створених сервером (u001 двічі, u005, u015 двічі);
• 20 рядків від двох акаунтів команди, по 10.

Групи не перетинаються, тож 60 − 5 − 20 = 35 витрат, доданих людьми.

Зверни увагу, що змінилося, а що ні. Тут правильно рахувати рядки, бо кожну витрату записано рівно один раз. Різні id не потрібні; треба прибрати рядки, яких не створював жоден клієнт. Чи правильні рядки, чи різні id, залежить від того, як записують подію, а не від типу числа.

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

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

Витрати Halves добре це показують. Без акаунтів команди 40 сум expense_added за минулий тиждень починаються з 6 дол. і тримаються біля 100 дол. або нижче, плюс три регулярні рахунки, які додав сервер: 420, 420 і 650 дол. Середнє — 3 251 ÷ 40 = 81,28 дол.; медіана, між 20-м і 21-м значеннями, — 40,50 дол. Витрату на 81 дол. більшість людей ніколи не додає.

Обирай показник за запитанням. Для «типової витрати» чи «типового користувача» подавай медіану. Коли важить сума (гроші, що пройшли через застосунок, вартість на одну витрату), правильне середнє, бо середнє × кількість повертає суму. В обох випадках кажи, що це за число і що рахували: якщо прибрати ще й серверні рядки, лишиться 35 витрат, доданих людьми, з медіаною 39 дол. і середнім 47,66 дол.

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

У лозі минулого тижня 11 рядків розрахунків. Різні id ідуть від s001 до s008, тож платежів було 8; три з них (s003, s004, s007) підтвердили, і вони трапляються двічі. Перевірка: 8 + 3 = 11.

Тут рядки завищують підрахунок, тож виправлення протилежне до випадку з витратами: рахуй різні settlement_id, а не рядки.

Те саме з грошима. Сума amount_usd по всіх 11 рядках — 1 484 дол., а вісім платежів разом — 1 010 дол. Підтверджені платежі додано двічі.

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

Ті самі 11 рядків розрахунків дають три чесні числа:

• 11 рядків: те, що записав лог, корисно лише для налагодження;
• 8 платежів: різні settlement_id, відповідь на «скільки було розрахунків?»;
• 9 людей: різні user_id з будь-якого боку, відповідь на «скільки людей брали участь у розрахунку?»

Людей може бути більше, ніж платежів, бо в одному платежі двоє учасників, і менше, коли та сама людина розраховується кілька разів; цього тижня в Halves u013 і u014 трапляються двічі. Жодне з чисел не краще. Вони відповідають на різні запитання.

Пастка — фраза на кшталт «розрахунків на користувача». Вона може означати платежі, поділені на активних користувачів, або частку активних, які розраховувалися, або платежі, зараховані лише платникові. Кожне прочитання дає інше число з тих самих даних.

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

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

• Рахуєш людей (активні користувачі, люди, які розраховувалися, люди, які бачили paywall): рахуй різні user_id. Одна людина — один раз, скільки б рядків у неї не було.
• Рахуєш речі, які можуть записатися кілька разів (розрахунки, підтверджені обома сторонами, повторені покупки): рахуй різні значення власного id цієї речі, як-от settlement_id.
• Рахуєш дії, записані рівно один раз (додані витрати, відкриття застосунку): рахуй рядки, прибравши ті, яких не спричинив жоден клієнт.

Потім фільтруй: прибирай серверні рядки, коли йдеться про людську активність, і всі акаунти команди, з прапорцем чи без. Для Halves за минулий тиждень це дає 17 щотижневих активних користувачів, 35 витрат, доданих людьми, 8 розрахунків і 9 людей, які розраховувалися.

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