Аудит отслеживания событий в приложениях, созданных ИИ, которым можно доверять

Почему аналитика ломается в приложениях, созданных ИИ

Плохая аналитика обычно не маскируется. Вы увидите конверсию оформления заказа выше 100%, случайный всплеск в 3 часа ночи или воронку, где все «просматривают цены», но почти никто не «начинает пробный период». Иногда ключевой шаг полностью отсутствует, так что панель показывает аккуратную историю, которой на самом деле не было.

Прототипы, сгенерированные ИИ, часто поставляются с неполным трекингом: цель была «сделать, чтобы работало» для демо, а не «сделать измеримым» для продакшна. Инструмент мог скопировать сниппет трекинга на одну страницу, но не на другие, отправлять события из нескольких мест или смешать старые и новые имена событий после рефакторинга. Он также может триггерить события в неправильный момент — например, отслеживать «purchase» при клике на кнопку, а не после успешной оплаты.

Это быстро ломает принятие решений. Если регистрации учитываются многократно, вы можете решить, что онбординг в порядке, и тратить деньги на рекламу. Если пробные периоды недоучитываются, вы поменяете цену или удалите функции, которые не были проблемой. Если атрибуция запутана, можно приостановить хорошую кампанию и удвоить ставку на плохую.

Надёжная аналитика проста по сути: одно и то же действие пользователя порождает одно и то же событие, один раз, с одинаковым смыслом. Вы должны уметь объяснить, где оно вызывается в коде, воспроизвести в тестовом аккаунте и увидеть соответствие тому, что пишут логи приложения и база данных.

Когда что‑то выглядит странно, сделайте быструю проверку реальности. Срабатывает ли событие только после успеха (а не на клик)? Не срабатывает ли оно дважды (клиент и сервер, или два слушателя)? Совпадает ли имя на всех страницах и в разных окружениях? Совпадают ли счёты с источником истины, например таблицей заказов? Не раздувают ли числа боты, повторы или перезагрузки страниц?

Если вы унаследовали приложение, созданное инструментами вроде Bolt, v0 или Replit, такие проблемы — обычное дело. FixMyMess часто видит трекинг, переплетённый с UI, дублированные обработчики и события, которые срабатывают даже при неудачных запросах.

Решите, что вам действительно нужно измерять

Прежде чем править код или дашборды, определите, что в вашем продукте означает «реальный прогресс». Многие AI‑сгенерированные приложения терпят неудачу в аналитике, потому что пытаются отслеживать всё и сразу, но пропускают те действия, которые объясняют рост и доход.

Начните с небольшого набора бизнес‑критичных действий. Для многих продуктов это варианты регистрации (аккаунт успешно создан), активации (первое значимое действие), покупки (проведена оплата или стартует платный план), удержания (пользователь возвращается и повторяет ключевое действие) и иногда рефералов/шеринга.

Опишите каждое событие одной фразой, отвечающей на два вопроса: когда оно срабатывает и почему это важно. Пример: signup_completed срабатывает после подтверждения email, потому что это самая ранняя точка, где мы можем доверять, что аккаунт реальный.

Выберите стиль именования и придерживайтесь его. Простые читаемые имена лучше умных трюков. Выберите формат (например verb_noun), держите согласованное время и избегайте имён, похожих на UI‑элементы (например, blueButtonClick).

Разделяйте действия пользователя и системные события. Действие пользователя — «создал проект» или «начал пробный период». Системное событие — «отправлено письмо» или «получен webhook». Если смешать их, воронки перестанут означать то, что вы думаете.

Опишите также, что значит успех для каждого события. Это может быть счёт, конверсия или время до действия. Это упрощает будущие аудиты, особенно если вы унаследовали запутанный код, сгенерированный ИИ, и нужно доказать, что пользователи действительно сделали.

Сопоставьте события с реальными действиями пользователей

Хорошая аналитика начинается с простой карты: что делает реальный человек шаг за шагом и что вы ожидаете зарегистрировать на каждом шаге. Если пропустить это и сразу браться за дашборды, вы будете измерять клики, которые ничего не означают.

Запишите ключевые пользовательские потоки простым языком. Ограничьтесь действиями, которые действительно важны, а не каждой кнопкой. Типичный набор: первый визит, регистрация, вход, ваша основная функция (то самое действие, которое доказывает ценность) и оформление заказа.

Для каждого шага зафиксируйте три вещи: (1) ожидаемое имя события, (2) момент его срабатывания, (3) где оно должно срабатывать (клиент, сервер или оба). Это превращает «трекер сломан» в конкретную вещь, на которую можно указать и исправить.

Краевые случаи — место, где приложения, созданные ИИ, часто расходятся с реальностью. Модальное окно может отправлять событие при открытии и снова при отправке. Редирект может дублировать просмотры страниц. Многошаговая форма может логировать завершение на каждом шаге, потому что состояние сбрасывается.

При картировании каждого потока отметьте кейсы для тестирования: обновление или кнопка «назад», повторные попытки (двойной клик, повторная отправка, повтор платежа), медленная сеть, ненадёжное соединение и различия между мобильными и десктопами.

Пример: пользователь регистрируется, перенаправляется на дашборд, затем приложение восстанавливает сессию при загрузке. Если и обработчик успеха регистрации, и код восстановления сессии отправляют signup_completed, воронка покажет два события регистрации на одного человека.

Поймите, откуда идут события

При аудите трекинга первая задача проста: найти точную строку кода, которая отправляет каждое событие. В AI‑сгенерированных приложениях эта строка может быстро меняться, когда инструмент перезаписывает компоненты, добавляет хелперы или дублирует логику.

Клиентские vs серверные события

Клиентские события (браузер или мобильное приложение) лучше подходят для действий в UI и контекста: клики, просмотры страниц и шаги форм. Они показывают, что пользователь видел и делал, но их проще блокировать или терять (адблокеры, ошибки скриптов, ненадёжная сеть).

Серверные события (ваше API, фоновые задания, webhooks) подходят для того, чему вы должны доверять: успешные платежи, изменения подписок или создание аккаунта. Их сложнее подделать и они обычно надёжнее, но они могут упустить намерение в UI (например, пользователь пытался оплатить, но бросил процесс).

В AI‑сгенерированном коде события часто триггерятся из повторяющихся мест: обработчики UI (onClick, onSubmit), хуки и эффекты (useEffect), обёртки API, менеджеры состояния и общие утилиты вроде универсальной функции track().

Дубликаты обычно происходят от кода, который выполняется чаще, чем вы думаете: ререндеры, которые привязывают обработчики заново, множественные слушатели на одно действие, optimistic‑логирование в UI вместе с подтверждением от сервера, или повторные запросы, которые логируют каждую попытку.

Отсутствующие события встречаются реже заметно, но не реже: ранние return перед вызовом трекинга, исключения, которые пропускают строку, скрипты, блокируемые браузером, или гонки, когда приложение уходит со страницы до отправки события.

Быстрая проверка здравого смысла: если «Signup Completed» отправляется из эффекта React, зависящего от состояния пользователя, обновление страницы может вызвать его снова. Если же событие отправляется только с сервера после создания записи пользователя, оно сработает один раз, но вам всё равно может понадобиться отдельное событие «Signup Started», чтобы понять отток.

Пошагово: аудируем одно событие end-to-end

Выберите один пользовательский поток и держите его узким. Хорошее начало — регистрация, затем подтверждение email (если есть), затем первое ключевое действие (например, создание проекта или сохранение черновика). Когда вы доверяете этому потоку, всё остальное даётся легче.

Перед тестом запишите, чего вы ожидаете простыми словами: какое событие должно сработать, когда именно и что оно должно содержать. Это минимальная полезная спецификация события.

Вот рабочая end‑to‑end процедура, которая работает даже в запутанных кодовых базах, сгенерированных ИИ:

1. Пройдите поток как реальный пользователь и смотрите события в режиме реального времени по ходу действия.
2. Останавливайтесь в каждом месте, где должно сработать событие, и подтверждайте, что оно срабатывает именно в этот момент.
3. Повторите одно и то же действие дважды, чтобы поймать двойную отправку. Один клик — одно событие.
4. Откройте полезную нагрузку события и проверьте базовые поля: user_id (или anonymous_id), session_id, план или тариф, источник (web/app/referral), имя экрана/страницы и любые состояния ошибки.
5. После обработки убедитесь, что то же событие появляется в отчётах с теми же счётами и разбивками.

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

По мере перехода к следующему потоку ведите заметки: имя события, ожидаемый момент, фактический момент, дубликаты, отсутствующие свойства и файл или компонент, который, по-видимому, отвечает за это.

Найдите дублирующую отправку и пропущенные события

Дубли — один из самых быстрых способов потерять доверие к цифрам. Начните с сравнения того, что вы видите в дашборде, и того, что можете воспроизвести вручную.

Как заметить дубликаты (и почему они появляются)

Дубли обычно выглядят как одинаковые события с одинаковыми ключевыми свойствами, отправленные в течение секунды-двух. Просмотры страниц, которые растут, хотя вы не навигировали — ещё один признак.

Типичные красные флаги: повторяющиеся идентичные события, воронки, где поздние шаги имеют больше завершений, чем ранние, внезапные всплески, не соответствующие трафику, и метрики, сильно меняющиеся при обновлении страницы.

Причины в AI‑сгенерированных приложениях часто просты: циклы ререндеров в React, трекинг добавлен и в компонент, и в глобальный обработчик, слушатели привязаны дважды или сетевые ретраи повторно отправляют одно и то же событие без идемпотентности.

Как заметить пропущенные события

Пропущенные события проявляются как провалы в воронке, которые не совпадают с пользовательским тестированием. Если вы можете реально выполнить «Добавить в корзину», а воронка показывает большой утёк, значит трекинг либо не срабатывает, либо срабатывает только иногда, либо срабатывает раньше, чем действие действительно завершено.

Частые исправления просты: добавьте защиту, чтобы событие могло сработать только один раз на действие; дебаунс кликов; переместите трекинг в один уровень (часто — в финальный обработчик submit); добавьте идемпотентный ключ (например, order_id или request_id), чтобы ретраи не создавали дубликаты; и отслеживайте после успеха, а не на клике (особенно для auth и платежей).

Подтвердите исправление, прогнав тот же поток ещё раз и сравнив до и после. Также протестируйте в медленной сети — именно там дубли и пропуски чаще всего скрываются.

Проверьте идентичность, сессии и атрибуцию

Если графики «в целом правильные», но воронки неправильные, часто виноваты идентичность и сессии. AI‑созданные приложения часто смешивают клиентские трекеры, библиотеки авторизации и быстрые правки, которые не согласуют, кто такой пользователь.

Идентичность: выберите один источник правды

Определите единый надёжный user ID и применяйте его везде. В большинстве приложений это означает отслеживание анонимно до завершения входа/регистрации, затем переход на стабильный внутренний user_id (не email, не display name).

Обычная ошибка — неправильное объединение анонимных и авторизованных пользователей. Пример: пользователь приходит анонимно, регистрируется, выходит, затем входит снова в новой вкладке. Если код повторно использует старый anonymous ID, вы можете объединить двух разных людей в один профиль или разбить одного человека на нескольких.

При тестировании идентичности проверьте несколько сценариев: регистрация и обновление страницы (ID должен оставаться стабильным), выход и повторный вход (logged-in ID должен быть тем же), то же действие в новой вкладке (один пользователь с двумя сессиями, а не два пользователя), и инкогнито или второй девайс (не объединяйте без реальной авторизации).

Сессии и атрибуция: держите просто

Пределы сессии должны соответствовать реальному поведению: новая сессия после долгой паузы, а не после каждого обновления. Если трекер создаёт новую сессию на каждом reload, вы надуваете «новые сессии» и ломаете воронки.

Для атрибуции регулярно фиксируйте базовые значения: источник, кампания и реферер при первом значимом заходе. Сохраняйте их раз за сессию (или по первому касанию) и переиспользуйте, вместо того чтобы перечитывать URL на каждой странице. Это предотвращает случайную перезапись при навигации, оплате или возврате с внешнего провайдера.

Проверьте свойства событий и безопасность данных

Хорошие имена событий — это только половина дела. Если свойства неряшливы или опасны, ваши графики будут врать, и вы можете создать проблему с конфиденциальностью, не заметив этого.

Начните с короткого строгого набора обязательных свойств для каждого события. Храните только то, что реально используете в отчётах, воронках или тревогах. Лишние поля кажутся безобидными, но быстро превращаются в несогласованный мусор.

Простой список обязательных полей может выглядеть так:

• user_id (или anonymous_id, если пользователь не вошёл)
• source (откуда началось действие, например "pricing" или "settings")
• plan или product_id (только если вы это используете)
• value (число, в одной и той же единице измерения)
• environment (prod vs staging)

Затем проверьте типы и согласованность. В одном приложении value: "19.99" приходит как строка, в другом — value: 19.99 как число, а в третьем — value: null, когда UI падает. Выберите один формат, примените его и решите, что делать при отсутствии данных (отбрасывать событие, ставить дефолт или помечать как неверное).

Безопасность данных — это без вариантов. События логируются, воспроизводятся в инструментах отладки и хранятся долго. Просканируйте клиентские полезные нагрузки и серверные логи на предмет паролей, одноразовых кодов, reset‑ссылок, access‑токенов, API‑ключей, полных номеров карт, CVV, банковских реквизитов, сырых тел запросов с секретами или «debug»‑полей, которые копируют целые объекты.

Делайте события ошибок полезными, но безопасными. Вместо дампа стэков и payloads захватывайте то, что помогает исправить проблему: где упало (экран, шаг, имя эндпоинта), что видел пользователь (короткое сообщение) и безопасный код ошибки.

Согласуйте дашборды с правдой

Дашборд полезен, только если каждый график отвечает на один чёткий вопрос. Если график смешивает цели (например, «регистрации и активации»), становится трудно заметить, когда трекинг сломан. Сначала подпишите вопрос, затем убедитесь, что формула графика соответствует определениям событий.

Простая привычка, которая сохраняет дашборды честными — писать однострочное определение под каждой ключевой метрикой. Пример: «Активированные на этой неделе = пользователи, которые завершили онбординг И создали первый проект». Это заставляет думать ясно и избегать «приблизительных» шагов в воронке.

Прежде чем доверять цифрам, проведите проверку согласованности:

• Подтвердите, что каждый график использует одно событие (или чётко определённый набор) и один временной интервал.
• Проверьте фильтры (окружение, платформа, страна, версия приложения) — они могут случайно скрывать или дублировать данные.
• Убедитесь, что шаги воронки соответствуют 1:1 вашей таксономии событий.
• Добавьте хотя бы одну внешнюю проверку здравого смысла (подсчёты базы данных, серверные логи, выгрузки платёжного провайдера).
• Решите, как вы исключаете ботов и внутренний трафик, и зафиксируйте правило.

Пример: дашборд показывает 1,200 «Новых регистраций» вчера, но в базе данных только 900 записей пользователей. Это часто значит, что событие регистрации срабатывает и при «account created», и при «email verified», или оно ретраивается при обновлении страницы. Исправьте событие так, чтобы оно срабатывало один раз (по возможности на сервере), затем обновите график, чтобы считать только скорректированное событие.

Пример: исправляем сломанную воронку регистрации и оплаты

AI‑созданное приложение показывает 90% конверсию регистрации в дашборде, но доход остаётся плоским. Основатель думает, что проблема в маркетинге. На самом деле числа врут, потому что воронка склеена из копированных сниппетов и смешанных клиентских и серверных трекингов.

Что мы нашли в данных

«Signup Completed» срабатывал дважды у многих пользователей: при отправке формы и снова при редиректе на welcome‑страницу. Некоторые пользователи запускали его в третий раз при обновлении.

В то же время «Payment Confirmed» не учитывался для большой части реальных покупок. Чекаут был на сторонней платежной странице, но приложение никогда не записывало финальный webhook успеха как событие, поэтому дашборд не мог связать регистрации с платящими пользователями.

Результат предсказуем: события регистрации раздуты из‑за дублей на клиенте, подтверждение оплаты недосчитано, и воронка выглядела здоровой, хотя бизнес — нет.

Как мы исправили

Мы переместили «Signup Completed» в один обработчик, который срабатывает только после того, как сервер подтвердил создание записи пользователя. Затем сделали серверное событие «Payment Confirmed» идемпотентным (один и тот же purchase ID учитывается только один раз), чтобы ретраи и повторные отправки webhook не создавали дубликаты дохода.

Для проверки мы прогнали небольшой набор тестовых пользователей (новый браузер, возвращающийся браузер, медленная сеть) и сравнили реальные регистрации в базе с событиями Signup Completed, успешные списания с Payment Confirmed и счёты шагов воронки до и после.

После исправления конверсия регистрации упала до более реалистичного уровня, и воронка показала истинный провал на оплате. Решения стали проще: правим фрикции в чекауте, а не тратим бюджет на рекламу.

Быстрые проверки и следующие шаги

Если вы сделаете только одну вещь на этой неделе, проверьте несколько действий, от которых зависит бизнес (регистрация, активация, оплата, апгрейд). Маленькие ошибки здесь могут сделать каждый отчёт непредсказуемым.

Используйте этот чеклист для любого ключевого события:

• Срабатывает один раз (нет двойной отправки при обновлении, назад, ретраях или при одновременной отправке с клиента и сервера)
• Срабатывает в нужный момент (после фактического успеха, а не при клике)
• Имеет правильные свойства (plan, price, currency, screen, reason for error) и без мусорных значений
• Имеет правильную идентичность пользователя (стабильные ID, без случайного слияния или разделения)
• Появляется в дашборде так, как вы ожидаете (счёты совпадают с реальными действиями, которые вы можете воспроизвести)

Как только событие станет «правдой», опишите его простыми словами: имя события, когда оно срабатывает, обязательные свойства и что никогда не должно быть включено (пароли, полные токены, сырые данные карт). Эта одна заметка делает будущие изменения безопаснее, особенно когда код редактирует ИИ.

Чтобы предотвратить дрейф, делайте небольшую ежемесячную проверку: перепройдите топ‑события end‑to‑end в staging или тестовом аккаунте, сравните небольшую выборку реальных сессий с суммами в дашборде, проверьте недавние изменения в коде, касающиеся трекинга или auth, и удалите события, которыми никто не пользуется.

Если ваше приложение было сгенерировано Lovable, Bolt, v0, Cursor или Replit, обзор трекинга на уровне кода стоит того. Эти проекты часто заканчивают с дублирующимися обработчиками, смешанным клиент‑сервер трекингом и багами идентичности, которые проявляются только при реальном трафике. Если хотите вторую точку обзора, FixMyMess (fixmymess.ai) может начать с бесплатного аудита кода, чтобы точечно выявить дубли, пропуски и риски утечек данных перед масштабированием.