X запустил собственную платёжку X Money

X Money от Илона Маска — новый платёжный сервис с картами Visa, поддержкой Apple Pay, Google Pay и Apple Wallet. Сейчас доступ к выпуску есть только у Premium/Premium+ пользователей в США, поэтому сервис пока нишевый, но выглядит перспективно: ранний заход может дать чистые БИНы и меньше внимания антифрода.

➡️ Читайте на сайте: https://aff.top/blog/x-zapustil-sobstvennuiu-platezhku-x-money

🧠 Ещё больше инсайтов → в канале AFF.top

GA4 vs Mixpanel: как за 7 дней собрать «единый» пользовательский профиль и не сломать отчетность

Если у вас и GA4, и Mixpanel (Amplitude/Heap часто рядом), главная проблема обычно не в настройках событий, а в том, что *один и тот же человек* в системах считается по‑разному. Результат — разные конверсии, «провалы» в ретенции и разночтения в пайплайне MQL/SQL (или RevOps-метриках). Ниже — практический план, как на этой неделе привести к единой логике идентификации.

Шаг 1. Зафиксируйте правила идентификации (один документ на 1 страницу)
Сравните, как у вас сейчас строится связка:
— user_id (устойчивый идентификатор пользователя)
— anonymous_id (анонимный идентификатор сессии/браузера)
— email/CRM id (если используете)
Сделайте одно правило, которое будет одинаковым и для GA4, и для Mixpanel:
— До авторизации: используем anonymous_id
— После авторизации: переводим в user_id и связываем с прошлым анонимным профилем (identity/link)
Если у вас нет user_id — заведите его: это ключ от аккаунта в вашей системе (не email и не device id).

Шаг 2. В GA4 проверьте, что user_id реально отправляется и активирован
— В администрировании убедитесь, что **User-ID** включен
— Проверьте, что в событиях (или отдельным механизмом) отправляется параметр user_id именно в момент, когда пользователь становится известен
— Проверьте в отчётах (в реальном времени/DebugView), что события после логина приходят с user_id, а до логина — без него
Важно: если user_id меняется (например, на email), вы получите «прыжки» профиля.

Шаг 3. В Mixpanel (и/или в вашем CDP-слое) настройте identity/link по тому же правилу
Суть та же, но реализуется иначе:
— Делайте вызов identity при логине: anonymous_id → user_id
— Убедитесь, что в Mixpanel нет параллельной логики, где вы создаете новый профиль вместо склейки
— Проверьте в отладчике: в одном пользовательском пути события до и после логина должны попасть в один профиль

Шаг 4. Нормализуйте «контрольный набор» событий (минимум 10)
Выберите события, которые ломают отчеты при рассинхроне:
— signup_started / registered (регистрация старт/факт)
— login
— trial_started (если есть)
— purchase или paid_conversion (для e-com/платежей)
— key onboarding шаг (1–2 события)
— chrg_failed / subscription_updated (если есть подписки)
Для каждого события определите:
— название (как будет в обеих системах)
— обязательные параметры (например plan, source, account_type)
— один и тот же смысл параметров (не «plan_name» в одном и «subscription_plan» в другом с разным наполнением)

Шаг 5. Сделайте «пересечение» аналитики: сравнение по одному сегменту
На этой неделе достаточно одного тестового окна (например, за последние 7 дней):
— Возьмите 1 сегмент: пользователи, которые стали user_id (авторизовались)
— Сравните в GA4 и Mixpanel:
— долю событий login
— количество зарегистрированных
— временной лаг между регистрацией и paid_conversion (если платное)
Если расхождение большое, причина почти всегда в identity/link или в том, что часть событий до логина уходит без связки.

Шаг 6. Постройте одну общую метрику, чтобы «проверить жизнь»
Возьмите метрику, которую нельзя «подогнать»:
— регистрация → активация (например, 1 ключевой onboarding шаг в течение 7 дней)
В GA4 посчитайте это через cohort/retention-логику (или аналитику по пользователям), в Mixpanel — через funnels/retention по user_id.
Цель: совпадение хотя бы в одном направлении (например, не «в 2 раза меньше» в одной системе).

Шаг 7. Документируйте расхождения и заморозьте правила на 2 недели
Создайте короткий changelog:
— какие события переименованы/перепараметризованы
— где менялась identity
— какие сегменты пока не используем для финальных решений
В 2026 году при privacy-first атрибуции и росте server-side/инкрементальности вам важно, чтобы база (пользовательский профиль) была стабильной: иначе MMM/инкрементальность будет «подтверждать» неверную первичную структуру данных.
…