Англійська для PostHog Analytics
Вивчіть англійську лексику щодо аналітики продуктів PostHog: події, воронки, когорти і прапорці можливостей, з поясненнями для розробників і команд продуктів.
PostHog поєднує аналітику продукту, прапорці можливостей і повтор сеансу в одному інструменті, що означає, що його словник охоплює кілька дисциплін одночасно. Бути точним про різницю між «подією», «фунтом» і «кохортою» зберігає обговорення з менеджерами продуктів, засновані на тому, що дані насправді показують, а не на нечітких враженнях. Цей підручник містить основні терміни.
Ключовий словник
** Подія ** — одна дія з відстеженням (наприклад, signup_completed або button_clicked ), надіслана з програми до PostHog, основний об’ єкт, з якого буде побудовано всі аналізи.
- “Ми не маємо події для кнопки « експортувати », отже, на даний момент ми не маємо інформації про те, як часто використовується ця функція.” *
** Летючий канатик ** — послідовність подій, які аналізуються разом для вимірювання швидкості перетворення від одного кроку до наступного, що показує, де користувачі відмовляються від перегляду. “В канаві показано 40% падіння між «додано до кошика» і «початок оплати» — це крок, який ми повинні розслідувати спочатку.”
** Кохорта ** — збережена група користувачів, визначена за спільними властивостями або поведінкою (наприклад, « зареєстровано за останні 30 днів » або « використано функцію X »), використовується для аналізу сегментів. “Порівняємо утримання між когортою, яка використовувала новий поток введення, і когортою, яка використовувала старий.”
** Прапорець можливості ** — перемикач, який керує тим, чи буде можливість видимою для певного користувача або групи, використовується для поступового розгортання, A/ B- тестування і аварійних перемикачів. “Ми відправили переробку за прапорцем можливостей, щоб ми могли спочатку розгорнути її для п’яти відсотків користувачів і стежити за помилками.”
** Повторення сеансу ** — записане, повторюване відтворення фактичного сеансу користувача, яке використовується для перевірки того, що саме відбувалося з користувачем, без необхідності повідомляти про ваду.
- “Замість того, щоб вгадувати, що не так з квитком підтримки, давайте просто витягнемо повтор сеансу для сеансу цього користувача.” *
** Крива збереження ** — діаграма, на якій показано відсоток користувачів, які виконали початкову подію, які повертаються для виконання наступної події з плином часу.
- “Крива утримання сплющена на третьому тижні, що свідчить про те, що користувачі, які залишаються довго, мають тенденцію залишатися довго.” *
Звичайні фрази
- Чи це подія дійсно спалахує, чи ми не маємо інструментів на цій кнопці?»
- «Де найбільший спад у цьому воронці, і чи є у нас гіпотеза чому?»
- Чи можемо ми побудувати когорту для користувачів, які потрапили в цю помилку, щоб ми могли побачити, що ще вони мають спільного?
- Чи була ця функція зафіксована, або вона була відправлена всім одночасно?»
- Давайте потягнемо кілька повторів сеансів, перш ніж ми припустимо, що це поширена проблема. “
Приклади висловлювань
Пояснення плану розгортання у перегляді проекту: “Ми заблокуємо це за прапорцем функції, починаючи з десяти відсотків користувачів, і ми будемо спостерігати за льотком і кількістю помилок перед збільшенням відсотка розгортання.”
Звітування про відсутність даних: “Ми не можемо відповісти на це питання збереження, тому що подія ‘feature used’ не інструментована — нам потрібно додати виклик відстеження, перш ніж ми зможемо побудувати когорту.”
Обговорення проблеми користувацького інтерфейсу з колегою: “Я отримав три повтори сеансів від користувачів, які відмовилися від платежу, і всі три отримали одну і ту ж помилку підтвердження на формі карти - це, ймовірно, справжня причина, а не загальне тертя при оплате.”
Професійні поради
- Використовуйте “event”, коли обговорюєте дані, що стежать, і зарезервуйте “action” для опису того, що користувач зробив у загальній розмові — змішування їх робить неясним, чи щось насправді інструменталізовано.
- При повідомленні про проблему з футером, назвемо ** точний крок **, де відбувається відключення, а не кажучи «повернення пошкоджено» — це негайно фокусує розслідування.
- Використовувати ** « когорта » ** замість « сегмент », коли мова йде про групу, визначену PostHog, відповідно до термінології інструменту у письмових звітах.
- Визначте, чи є можливість за прапорцем під час обговорення нового випуску — це змінює те, як слід розглядати звіт про ваду.
Практичні вправи
- Поясніть у двох реченнях, чому стік є більш корисним, ніж один відсоток перетворення для знаходження проблеми UX.
- Напишіть одне речення, в якому описати відсутню подію, що блокує аналіз.
- Опишемо вашими словами, як прапорець можливості і когорта можуть бути використані разом під час поетапного розгортання.
Розширення Вашої комунікації: нюанси для не-національних розробників
Зрозуміти термінологію PostHog - * події *, * воронки *, * когорти *, і * функція прапори * - є ключовим для ефективного співробітництва. Але це не тільки про знання визначення; це про використання їх точно в професійному контексті, особливо при спілкуванні з носієм англійської мови в оглядах коду, розмовах Slack або описах Pull Request. Багато розробників, які вивчають англійську, вважають, що тонкі відмінності у фразуваннях можуть призвести до непорозумінь і затримок. Давайте розглянемо, як переміщатися по цих нюансах.
Однією з ключових областей є рівень деталізації. Рідні носії англійської часто очікують певного рівня ясності при описі технічних питань. Наприклад, замість того, щоб просто сказати «Ця подія не запускається», що може бути цілком прийнятним у швидкому повідомленні Slack, ви можете сказати: «Я дослідив подію user_signup і здається, що вона не запускається під час початкового завантаження сторінки через потенційний конфлікт з сторонньою бібліотекою аналітики. Підозрюю, що неправильний параметр налаштування викликає фільтр, який перешкоджає запису події у журнал.» Такий рівень докладності показує ретельність і допомагає переглядачеві швидко зрозуміти проблему і зрозуміти, які дії слід виконати. Аналогічно, при написанні опису PR для реалізації прапора функції, уникайте нечітких тверджень, таких як « Реалізований прапор функції ». Замість цього, чітко сформулюйте * чому * прапор необхідний (« Для A/B тестування нового потоку впровадження »), * як * він реалізований (наприклад, « Використання posthog.flags.enable('new_onboarding', true) »), і його запланований вплив (« Це дозволить нам виміряти залучення користувача з оновленим досвідом впровадження »).
Іншим частим викликом є вираз критичності або невідкладності відповідно. Фрази на кшталт «невідкладно» можуть здатися надто драматичними і, чесно кажучи, часто не є справді невідкладними. Замість крику “ТУРБЕННО! Подія не запускається!», більш професійним підходом буде «Пріоритет 1: Подія checkout_success не запускається для користувачів, які завершують поток покупки. Це впливає на нашу здатність точно відстежувати показники конверсії і вимагає негайного розслідування. » Це передає серйозність без використання гіпербол, робить ваше повідомлення більш вражаючим і, ймовірно, отримає негайну увагу.
Нарешті, пам’ ятайте, що коротка і точна мова дуже цінується. Уникайте надто складних структур речення або жаргону, якщо це можливо. Сфокусуйтесь на передачі основної інформації чітко і прямо. Правило 1: чи може хтось, хто не знайомий з PostHog, зрозуміти суть проблеми, виходячи лише з вашого повідомлення?
# Example PostHog CLI command to check flag status
posthog flags list --name new_onboarding
Ця проста команда показує, як можна посилатися на певний прапорець можливості у повідомленні, надаючи конкретний контекст для інших. Це про будівництво спільного розуміння через чітку і професійну англійську.