Від чотирьох інтерв’ю до продуктової метрики: мій перший експеримент із PostHog

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Всім привіт! Мене звати Ігор Рудь. Я розвиваю Pass YEVI — це EdTech-стартап для підготовки до ЄВІ та ЄФВВ з інформаційних технологій (наразі). Зараз одним з наших безкоштовних продуктів є Telegram-бот, який щодня надсилає студентам навчальні завдання з обраного напряму.

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

Telegram-бот

Перед тим, як перейти до PostHog, потрібно зрозуміти коротко про що проєкт, які є дані, і що я вже вимірюю.

Для Pass YEVI я створив Telegram-бот, в якому щодня можна отримувати до 3 задач на день з обраного напряму: англійська (ЗНО з англійської на мінімалках), ТЗНК (тест на логіку та письмо) або ЄФВВ з IT (іспит на 140 з IT, математики, кібербезпеки, і т.п.). Таким чином, студент отримує безкоштовно різні задачі з підготовки до іспиту, з нормальними поясненнями, а я отримую дані та події (events), які прилітають у PostHog. Win-Win.

Навіщо взагалі події, коли є база даних, — хтось може запитати. З однієї сторони так, але на перевагу такому сервісу, як PostHog є як на мене кілька серйозних переваг:

не потрібно навантажувати базу даних, постійними подіями
не потрібно будувати гарні та складні дашборди в адмінці
це безкоштовно (до якогось моменту)

Які події вже є в системі (у хронологічному порядку):

daily_task_delivered (задача прилетіла)
task_answered (відповів на задачу)
extra_daily_task_requested (запросив ще одну задачу)
three_tasks_completed (три задачі виконано за lifetime користувача, але з назви через два місяці мені було не зрозуміло про що ця подія, поки не відкрив код і перевірив, тому раджу давати назви подіям більш конкретно 🙂)

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

Розмова з користувачами

Відразу, як тільки студенти почали користуватись ботом, через деякий час, я почав робити криві cust-dev. Інакше кажучи, я почав питати, що їм подобається, що можна зробити краще, а що їх взагалі бісить і це потрібно прибрати. На той момент, чотири студенти відповіли, що вони не розуміють, чому приходить лише одна задача на день. Так, зрозуміло, що чотири студенти, це небагато, але коли на той момент в боті всього скажімо було до 10 користувачів, то ця частка активних (!) користувачів була суттєвою. І залишити їхнє прохання було б грубою помилкою.

Реалізація фічі

Отже, я вирішив додати три задачі на день. А чому відразу не було зробити це; ще краще: чому не додати 100500 завдань на день; та інші питання можуть логічно виникнути. Насправді, я дуже не хочу, щоб практика в Telegram-боті перетворювалась на щось довге та нудне.
По-перше, три завдання на день підтримують інтерес студента, дефіцит породжує бажання повертатись (моя гіпотеза). По-друге, основним продуктом буде адаптивна онлайн-платформа, яка буде набагато потужніша, ніж сам бот для підготовки до іспитів, бот скоріше для легкої розминки повторенням чогось знайомого, ніж для вивчення нових тем, або серйозної практики.
Тому, подумавши на той момент з Fable, як краще це зробити і надумали: якщо студент дійсно хоче отримувати 3 задачі на день, нехай покаже свій намір (intent) і натисне на кнопку: «Отримати ще одну задачу →», ніж відразу спамити трьома задачами на день. І як на мене це було правильним рішенням, тому що на цю кнопку додатково ми додали відстеження події — extra_daily_task_requested.

Перегляд метрик і рішення залишити фічу

Цю фічу я випустив 28 серпня цього року, з того моменту до 13 вересня, 9 із 12 користувачів, які виконали першу щоденну задачу, запросили другу — 75%. 8 із 12 дійшли до завершення третьої — 67%. А серед дев’яти користувачів, які хоча б раз попросили додаткову задачу, 7 із 9 (78%) користувалися цією можливістю щонайменше у два різні дні.
Перед релізом я не зафіксував конкретний поріг успіху — це одна з моїх помилок цього експерименту. Але у цьому випадку, на основі проведених інтерв’ю та фактичного використання цієї фічі користувачами я вирішив її залишити.

Коротко про PostHog

Я не пов’язаний із PostHog і не отримую грошей за його згадку тут (а хотілось би 😄). Але PostHog, дійсно чудовий сервіс зі щедрими лімітами на місяць. Отож, PostHog дає вам розуміння, що ваші користувачі роблять у додатку на основі ваших подій (events).

Ліміти на місяць (безкоштовно)

1 000 000 подій на місяць
1 000 000 запитів для feature flags
1 000 000 рядків у їхньому сховищі даних
5 000 відтворень сеансів

Простота налаштування

Окрім ручного налаштування, PostHog має свого Wizard, який встановить все це за вас. Переважна більшість популярних фреймворків та мов програмування мають відповідні SDK та бібліотеки.

Сторінка з Install PostHog.

MCP із коробки

Можна встановити MCP для вашого улюбленого агента: Claude, ChatGPT, Codex, VSCode чи Cursor або взагалі використовувати PostHog AI на десктопі.

Простота у використанні та витонченість інтерфейсу

Це інтерфейс, в якому можна розібратись з AI-агентом максимум за один день. Основні інструменти — це тренди, воронки, утримання (retention) та лояльність користувачів (user stickiness). Для мене цих інструментів поки вистачає з надлишком, налаштувати їх досить просто, якщо у вас правильні події з правильними властивостями (properties).

Ну, а також в них прикольний маскот :-)

Чому не Google Tag Manager?

Насправді, тут не стоїть питання «або-або», скоріше «та-та». Тобто Google Tag Manager (GTM) може надсилати події з вашого вебсайту в PostHog, а в ньому ви вже аналізуєте їх, і приймаєте рішення. Тобто PostHog для продуктової аналітики, а GTM — доставляє дані, збирає їх, але в них наскільки мені відомо немає таких потужних можливостей як у PostHog. Хоча, GTM і не обовʼязковий, якщо у вас є вже PostHog. Просто надсилайте події в коді, наприклад ось як у класі нижче, який реагує на подію в коді «AnswerRecorded» і як лістенер асинхронно надсилає цю подію в PostHog:

final readonly class CaptureAnswerRecorded implements ShouldQueue
{
    public function __construct(
        private AnalyticsContract $analytics,
    ) {}

    public function handle(AnswerRecorded $event): void
    {
        $properties = ['context' => $event->context, '...' => '...'];

        $this->analytics->capture($event->user, AnalyticsEventEnum::TaskAnswered, $properties);

}
}

Висновки

Звісно, що вибірка з 12 користувачів надто мала для статистично надійних висновків. Тому я сприймаю ці числа не як доказ ефективності фічі, а через призму раннього продуктового сигналу. Цей сигнал підсилює те, що потреба спочатку з’явилася в розмовах із користувачами, а потім проявилася в їхній поведінці.

А що ви використовуєте для продуктової аналітики, та як у вас влаштований цей процес? Пишіть у коментарях 👇