Продуктовая аналитика

Продуктовая аналитика — это дисциплина и категория инструментов, сфокусированная на отслеживании и анализе того, как реальные пользователи ведут себя внутри программного продукта — на какие функции они нажимают, какие потоки завершают или бросают, как использование меняется со временем, — в отличие от маркетинговой/веб-аналитики (отслеживающей источники трафика и просмотры страниц) и бизнес-аналитики (отслеживающей выручку и финансовые показатели). Специализированные инструменты продуктовой аналитики — Amplitude, Mixpanel, Heap и open-source PostHog — построены вокруг модели данных «событие»: каждое значимое действие пользователя (`signed_up`, `created_project`, `invited_teammate`, `upgraded_plan`) отслеживается как дискретное, привязанное к пользователю событие с временной меткой, и аналитики строят воронки, кривые удержания по когортам и отчёты о принятии функций поверх этого потока событий, а не полагаясь на обычные подсчёты просмотров страниц. Именно этот событийный подход делает возможным ответить на специфичные для SaaS продуктовые вопросы, на которые традиционная веб-аналитика ответить не может: «какой процент пользователей, завершивших 3-й шаг адаптации, активируется в течение 7 дней?» (вопрос воронки), «пользователи, освоившие функцию X в первый месяц, удерживаются ли лучше на 6-й месяц, чем те, кто её не освоил?» (вопрос когорты), или «какое конкретное действие внутри продукта лучше всего предсказывает превращение пользователя в платящего клиента?» (именно тот анализ, который определяет хорошую метрику активации). Современные платформы продуктовой аналитики всё чаще объединяют воспроизведение сессий (просмотр анонимизированной записи того, что именно сделал/нажал сбитый с толку пользователь) и фича-флаги/A-B тестирование вместе с базовой аналитикой, поскольку все три дисциплины питают одну и ту же базовую цель — понимание и улучшение поведения пользователя внутри продукта — из одних и тех же данных о событиях. Конкретный пример: продуктовая команда инструментирует своё приложение так, чтобы при каждом экспорте отчёта пользователем срабатывало событие `report_exported`, помеченное свойствами вроде `{report_type: "sales", format: "pdf", user_plan: "pro"}`. В PostHog они строят воронку `signed_up` → `created_first_report` → `report_exported` и обнаруживают, что лишь 18% новых регистраций когда-либо доходят до шага экспорта — а разбивка по когортам показывает, что пользователи, экспортирующие отчёт в первую же сессию, удерживаются в 3 раза лучше через 90 дней, чем те, кто этого не делает. Этот единственный вывод — раскрытый только потому, что отслеживались сырые поведенческие события, а не просто просмотры страниц, — становится основой для переработанного потока адаптации, который сразу же подталкивает каждого нового пользователя экспортировать пример отчёта. Распространённая ловушка внедрения — несогласованное именование событий и схем свойств в кодовой базе, когда несколько инженеров со временем инструментируют отслеживание (`report_exported` против `Report Exported` против `export_report`, все описывающие одно и то же действие), что незаметно дробит то, что должно быть одной чистой воронкой, на несколько неполных — поэтому зрелые команды поддерживают задокументированную спецификацию «плана отслеживания», которой должно следовать каждое новое событие перед выпуском.