Mixpanel vs GA4 в крупном ритейле: как «сошлись» воронки и научились считать выручку по когортам

Mixpanel vs GA4 в крупном ритейле: как «сошлись» воронки и научились считать выручку по когортам

Контекст
В ритейле к 2026 году все сложнее “доверять одной цифре”. Причины банальны: приватность-first аналитика давит на точность last-click; креативы генерятся быстрее, чем меняются схемы атрибуции; средний чек уходит вниз на фоне экономии; и ключевой вопрос уже не «сколько лидов», а «что реально дало выручку и удержание».

Мы взяли реальный типовой кейс для крупного магазина (e-com/marketplace-логика) — условно похожего на Lamoda по масштабу каталога и циклу покупки. До проекта у команды было два “мира”: GA4 как источник отчётов по событиям, и Mixpanel как более удобный инструмент для продуктовых воронок/когорт. На практике это обернулось проблемой: воронки между системами не совпадали, и никто не мог честно ответить руководству, почему конверсия в покупку “то растёт, то падает” — или где именно ломается путь пользователя.

Задача
Свести разногласия в аналитике к измеримым правилам. Конкретно нужно было:
— выровнять определение ключевых событий (view_item, begin_checkout, purchase) и их параметры
— договориться о едином пользовательском идентификаторе (сессия/пользователь/устройство)
— построить в обеих системах согласованные воронки и когорты, но при этом не потерять скорость продуктовой аналитики
— перейти от “срезов по дням” к метрикам, которые объясняют влияние на выручку и retention

Решение
1) “Контракт событий” между GA4 и Mixpanel
Сначала сделали таблицу соответствий: названия событий, обязательные параметры и их типы. Например:
— view_item: item_id, category_id, price_at_view
— begin_checkout: order_intent_id (создаётся на фронте), payment_method_preference
— purchase: order_id, revenue, currency, item_count

Важно: в GA4 и Mixpanel события должны приходить с одинаковыми параметрами. Иначе когорта “разъезжается” даже при одинаковом названии события.

2) Единый ключ для объединения данных
Определили “пользователя” как комбинацию: логин (если есть) + идентификатор устройства (если нет). Дальше в Mixpanel строили продуктовые траектории, а в GA4 — отчётность для бизнес-метрик, но обе системы опирались на один и тот же identity layer.

3) Атрибуция без иллюзий last-click
С учётом privacy-first сделали так: маркетинговые кампании фиксировались через utm/канальный классификатор, но расчёты “дало выручку” стали строиться через когорты и инкрементальность (incrementality) на уровне групп/периодов, а не через цепочку последнего клика. Там, где требовалось “сколько именно продаж”, использовали серверную доставку событий и согласованную модель по окнам (например, 7/30 дней для возвратов).

4) Разрулили mismatch в воронках через тестовые сценарии
Поставили 20–30 сценариев “контролируемых путей”: просмотр → корзина → начало оформления → оплата → возврат. Для каждого сценария ожидали одинаковые шаги в обеих системах. После этого выявили две причины расхождения:
— purchase в одном инструменте уходил с revenue параметром, а в другом — без него (из-за другой схемы маппинга payment)
— begin_checkout считался дважды из-за повторного вызова API при редких сетевых сбоях (Mixpanel это показывал сразу, GA4 “сглаживал”)

Результат
После выравнивания:
— воронка “begin_checkout → purchase” перестала расходиться: отклонение между GA4 и Mixpanel сократилось с ~12–18% до ~2–3% на уровне недельных срезов
— расхождение по revenue исчезло: суммарная выручка по purchase совпала в пределах 1–2% с финансовой сверкой (по данным бэкенда)
— когорты начали вести себя предсказуемо: retention в 30 дней перестал “скакать” из‑за смены идентификаторов и дубликатов событий
— скорость принятия решений выросла: если раньше на разбор “почему цифры разные” уходило до 2 недель, то после контракта событий и контрольных сценариев — до 2–3 рабочих дней
…