Как разработчик систему продуктовой аналитики Posthog подключал25.07.2024 15:16

Когда наш продукт (протокол рекуррентных криптоплатежей на NodeJs, React) вырос, возникла необходимость подключить систему продуктовой аналитики, чтобы понимать, что и как делают наши пользователи. В статье хочу рассказать об опыте подключения и использования системы аналитики Posthog. Думаю, статья будет полезна разработчикам, впервые подключающим аналитику, техдиректорам и менеджерам для оценки потенциальных сроков и рисков.

Выбор инструмента

Как водится, вначале мы подключили Google Analytics, и даже залогировали определенные события. Но в процессе работы стало понятно, что нужно ее менять. Во-первых, GA4 не заточена под продукт, а больше под веб-аналитику. Во-вторых, ее юзабилити под большим вопросом. В-третьих, завязываться на монополиста, особенно в крипте — не самая лучшая идея (децентрализация все-таки, вспомним client diversity — всегда выбираем наименее распространенное решение). И в-четвертых, хотелось выбрать опенсорс решение, которое можно будет перетащить на собственный сервер в случае чего.

Выбирал между опенсорсными umami, matomo, plausible, posthog. Первый выбор всегда очень субъективен — продукт еще не попробовал, зазывающие сообщения с сайта не в счет. У всех примерно около 20к звезд на Гитхабе. Исключил matomo (может, зря) — первый коммит 2011 год, побоялся что старовата и много легаси — в итоге остановился на posthog (в разработке с 2020 го). Подкупило позиционирование — сразу про developers (а я разработчик) –, а также конкретика на главной странице — оцените — «код — вместо тысячи слов».

Конкретика, какие фичи есть и как выглядит

Конкретика, какие фичи есть и как выглядит

И сразу код – и это все на главной странице!

И сразу код — и это все на главной странице!

Первые шаги

Стандартно, создал проект, подключил в приложение скрипт аналитики.

d5c3d97924b22083ff8252261bf0e952.png

Можно подключать через голый JS (см. выше), можно через библиотеку языка, который вы используете. Порадовала документация, где есть описания для более чем десятка языков и технологий. Да, все это «одно да потому», и можно дойти самому, но удобно прочитать непосредственно про свою технологию.

8475d0320983dc36ff571066304d7326.png

В настройках проекта можно включить

  • Autocapture (по умолчанию логгировать клики, ввод текста, смены фокуса)

  • Heatmaps (тепловые карты, где можно посмотреть, куда чаще всего смотрят/кликают пользователи).

  • Можно сразу отфильтровывать «внутренних» пользователей, чтобы не сбивали статистику

678ed18ff6c3d9a87e1dc05a33ccf894.png

  • Session replay (запись сессий, чтобы посмотреть видео, как себя вели пользователи).

И множество других настроек, довольно понятных.

Первым делом я хотел разделить разные окружения, чтобы не смешивать данные локального тестирования и облачных окружений development/stage/production. Оказалось, на free плане только один проект, поэтому я подался на стартап программу, в рамках которой дали еще $50K кредитов, которые нам, конечно же, пока не пригодились. Posthog тарифицируется согласно использованным ресурсам (usage-based), до определенного предела не платите ничего — на текущий момент бесплатны (за месяц) до 1 000 000 событий (events), до 5000 записей (session replays), 1 000 000 флагов (feature flags), 250 ответов опросов (surveys).

Особенность — в рамках стартап программы нам дали $50K кредитов на год с момента одобрения, а кредиты нам по факту не нужны, т.к. мы в пределах бесплатного плана пока. Сейчас бы я подался на стартап программу только тогда, когда не влезаю в free план, чтобы год начался как можно позже.

Начало работы

Мы составили эксельку с событиями, которые нужно отправлять в аналитику, и прикрутили вызовы posthog в коде в нашем Реакт-приложении.

fc7d258ead4eeaeed2a8c5249e8509ed.png

А вот как отправляется событие в posthog (очень стандартно, события и его свойства): 

posthog.capture('payment_success', {
    price: 1599,
    plan_id: 'XYZ12345',
    frequency: 'monthly',
    features: {
        'SSO': true,
        'Custom branding': true,
        'Custom domains': false,
    }
})

Воронки

Первым делом я построил воронку по событиям. Все оказалось довольно интуитивно понятно.

Платежная воронка – от просмотра страницы до успешного платежа

Платежная воронка — от просмотра страницы до успешного платежа

Построенная воронка. Синий – общее, фиолетовый – мобильные пользователи, зеленые - десктоп, красные – планшет

Построенная воронка. Синий — общее, фиолетовый — мобильные пользователи, зеленые — десктоп, красные — планшет

Веб-аналитика

Второй частый запрос — посмотреть, кто открывал мое приложение и откуда. Тоже интуитивно понятно и просто.

cdfffd68b8c7ccf03a40e08777ecd2ff.png

A/B тестирование

Много слышал про A/B тестирование и впервые реализовал его руками. В posthog это делается на основе feature flags (не знаю как лучше перевести на русский, будет просто флаг). То есть вы создаете, например, эксперимент с флагом signup-button-color, который возвращает цвет кнопки для текущего пользователя. Он будет возвращать значение либо control (это нельзя изменить), обозначающее дефолтный (зеленый) цвет, либо red, blue. По умолчанию распределение будет 33,3% на каждый из флагов (конечно, проценты можно поменять в настройках). В ходе эксперимента мы задаем, конверсию в какое событие мы измеряем:

Значения флагов эксперимента

Значения флагов эксперимента

Воронка эксперимента

Воронка эксперимента

В коде фронтенда у вас будет код что-то вроде (псевдокод): 

const variant = useFeatureFlagVariantKey('signup-button-color');
const color = variant === 'control' ? 'green' : variant;

signUpButton.color = color;

Далее отправляете события как обычно и posthog считает, где лучше конверсия. Подробности можно прочитать в официальной документации. Что мне нравится — любая документация покрывает сразу все языки и среды разработки (см. рисунок ниже, выбираешь язык и получаешь сниппеты для него).

код сразу для всех языков

код сразу для всех языков

Бутстрапинг флагов (feature flags bootstrapping)

На текущем шаге может показаться, что все очень просто и безоблачно :) на самом деле это не так, есть множество нюансов. Мне нужен было сделать A/B тест с редиректом — направлять пользователя на одну или другую страницу в зависимости от значения флага. Проблема в том, что posthog запрашивает флаг с некоторой задержкой на клиенте, поэтому мгновенный редирект невозможен. Для этого используется бутстрапинг флагов:

  1. При первой загрузке страницы серверная часть приложения запрашивает значения всех флагов для пользователя. Тут есть 2 варианта:

    1. Пользователь не новый — в браузере лежит cookie с distinct_id пользователя.

    2. Новый пользователь — мы вручную генерируем distinct_id пользователя функцией crypto.randomUUID ().

      Мы получаем флаги для полученного в варианте 1 или 2 distinct_id, далее устанавливаем их значение в cookie.

  2. На клиенте, в инициализации posthog, достаем значения флагов из куки и соответственно, имеем в наличии его значение сразу же, не дожидаясь еще одного запроса на удаленный сервер posthog.

Все бы хорошо, но у нас был фронтенд на create-react-app без серверной части…

bbac7ce2cb7a047eb12c5d8203884293.png

Миграция на Next.js

Пришлось мигрировать проект на nextjs 14, к тому же у нас в планах был SSR (серверный рендеринг), пришлось совместить. За основу взял инструкцию с сайта некста, она в принципе ничего, но основное время ушло на то, чтобы использовать сущесутвующие клиентские компоненты/страницы (например, использующие useEffect или компоненты типа web3modal, которые используют useEffect). Я подгружал клиентские компоненты в серверных страницах (из папки app AppRouter) через динамический импорт, ниже сильно упрощенный код: 

import dynamic from "next/dynamic";
import Loader from "src/components/Loader";


// динамически подгрузить клиентский компонент
const TariffPlanPage = dynamic(() => import("src/pages/TariffPlan"), {
  ssr: false,
  loading: () => ,
});

type ParamsType = {
  params: { 
      // входные параметры для страницы
  };
};

export default async function Page({ params }: ParamsType) {
  const { pageParam1, pageParam2 } = params;

  // загрузить данные
  const response = await fetch('https://myapi/v1/data');
  const data = await response.json();

  // показать клиентскую страницу с загруженными данными
  return (
    
  );
}

Миграция на Next.js заняла примерно 2 недели (не сильно большой проект) без опыта его предыдущего использования. Далее использовал nextjs middleware по инструкции posthog, чтобы забутстрапить флаги и сделать A/B тест на редирект.

Из нюансов, мне нужно было устанавливать флаг только для тех пользователей, которые открыли определенный URL для редиректа. Сложность в том, что нужно было делать это на сервере при первом обращении, когда у posthog еще нет данных, что это за пользователь и с какого URL он зашел. В таком случае можно самостоятельно задать свойства (overriding server properties), чтобы вернуть нужное значение флага.

Разное

Текущее

Есть удобные инструменты, такие как Activity (можно посмотреть поток происходящих событий), People (пользователи).

Список активности – Activity

Список активности — Activity

Пользователи – People

Пользователи — People

Удобно использовать posthog как хранилище данных на лендингах и в экспериментах — просто отправить событие с атрибутами пользователя (например, имя или email), а потом экспортировать в CSV — например, чтобы посмотреть, кто оставил контакты.

У нас в платежке пользователь авторизуется по адресу кошелька. В процессе работы поняли, что забыли писать адрес кошелька в событие, чтобы идентифицировать пользователя.

Reverse proxy

Столкнулись с тем, что плагины типа Adblock блокируют обращения к серверам posthog. Чтоб пофиксить сделали reverse proxy (в данном случае через Next.js) — это когда posthog обращается вместо us.i.posthog.com обращается к нашему серверу, а сервер обращается уже к облаку.

Выводы

Минусы

Стабильность. Даже в процессе написания статьи я получал «A server error occurred», когда пытался получить данные. Иногда подглючивает UI, приходится перезагружать страницу. Не работал с большими объемами данных, как себя поведет — пока сказать не могу. В целом, есть ощущение, что продукт сыроват. Возможно, более зрелые системы не имеют таких недостатков.

Плюсы

Интуитивная понятность UI и концепций. После GA4 думаешь, что аналитика — это очень сложно. После posthog — что все очень просто и понятно. Действительно ориентация на разработчиков — документации много и в ней много конкретики, кода. Хорошая бесплатная поддержка — к каждой статье можно оставить комментарий и автор статьи быстро отвечает. Понятная цена и наличие стартап программы.

Результат

Подключение аналитики заняло примерно недели три, при кажущейся простоте. Система работает и собирает данные, накапливаем данные для A/B оптимизации.

Возможно, кому-то могло показаться, что статья уж больно ванильная :) Заверю, что я с posthog никак не аффилирован, просто описал свой опыт. Надеюсь, вы почерпнули что-то полезное. Будет интересно узнать про ваш опыт с аналитикой, особенно по другим системам — делитесь в комментариях.

Минутка PR. Веду тг‑канал Web3 разработчик. Пишу небольшие заметки (не часто) о задачах по блокчейну/крипте, которые решаю. Буду рад видеть среди подписчиков!

© Habrahabr.ru