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

Почему команды перестают доверять данным событий

Доверие рушится быстрее, чем многие команды ожидают. Продакт-менеджер открывает воронку и видит signup_started. Инженер смотрит в приложение и находит register_begin. Оба названия указывают на один и тот же момент, но отчёт теперь выглядит как будто он разделился надвое. После этого каждый показатель становится поводом для спора.

Проблема становится ещё хуже, когда одно нажатие запускает целую россыпь событий. Пользователь нажимает «Продолжить», а приложение записывает button_tap, form_submit, request_started и screen_loaded. Эти события не означают одно и то же, но команды часто объединяют их в одном отчёте. Продуктовая команда читает их как намерение пользователя. Разработка — как поведение приложения. И у обеих сторон есть своя правда, поэтому путаница не уходит.

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

Названия ещё и меняются со временем. В одном релизе используется checkout_submit. В следующем добавляется checkout_submitted. Другая команда логирует place_order_click, потому что это совпадает с текстом кнопки. В моменте каждое решение кажется безобидным. А через шесть месяцев именование событий в мобильной аналитике превращается в уборку, и никто уже не уверен, какое событие должно лежать в дашборде.

Обычно именно так и уходит доверие: не из-за одной большой ошибки, а из-за множества мелких решений по именованию, которые накапливаются. Состояния экранов, действия пользователя, сетевые запросы и повторы начинают сливаться. И тогда команды перестают спрашивать: «Что сделали пользователи?» — и начинают спрашивать: «Какому событию вообще можно верить?»

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

Начните с того, что сделал пользователь

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

Именно здесь именование событий в мобильной аналитике часто идёт не так. Команды называют события в честь кнопок, идентификаторов экранов или тикетов на трекинг, поэтому отчёты заполняются вроде btn_primary_2_tap или login_view_v3_click. Такие названия рассказывают, как приложение было собрано, а не что человек пытался сделать.

Используйте простые глаголы и не усложняйте. Здесь скучное — это хорошо. opened, tapped, submitted и retried легко читать и сложно неправильно понять. Если человек нажимает «Создать аккаунт», событие должно описывать именно это намерение, например signup_submitted, а не текст кнопки или имя компонента.

Помогает простое правило:

• вкладывайте намерение пользователя в название события
• оставляйте одно событие на одно действие
• переносите детали интерфейса в свойства
• используйте одни и те же глаголы по всему приложению

Свойства сохраняют дополнительный контекст. Вы всё ещё можете записывать, какую версию кнопки использовал человек, где она находилась или какой эксперимент он видел. Просто не тащите это в само название события. Например, signup_submitted может содержать свойства вроде button_variant: sticky_footer, screen: signup и experiment: copy_b.

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

Это ещё и снижает градус споров. Продуктовая команда видит чистую воронку. Разработка по-прежнему хранит нужный контекст в свойствах. Когда обе команды читают одно и то же событие и понимают его одинаково, доверие растёт быстро.

Разделяйте просмотры экранов и состояния экрана

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

Если смешать это в одно, отчёты быстро становятся мутными. Событие вроде signup_error_tap не говорит, открыл ли пользователь экран регистрации, увидел ли ошибку при загрузке или вызвал ошибку после нажатия кнопки. Продукт видит сломанную воронку. Разработка видит шум.

Хорошо работает простое правило:

• используйте один шаблон для просмотров экранов, например screen_view
• используйте один шаблон для состояний, например screen_state
• передавайте имя экрана одним и тем же способом каждый раз
• держите названия состояний простыми: loading, empty, error, ready

Такая структура делает воронки понятнее. Можно посчитать, сколько пользователей дошли до signup, сколько застряли в loading и сколько увидели error, не гадая, что означало то или иное событие-действие.

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

Ещё важнее согласованность между iOS и Android, чем идеальное название. Если iOS отправляет sign_up, а Android — signup_screen, дашборд дробит один экран на два. Выберите одно стабильное имя, зафиксируйте его и не меняйте, даже если текст интерфейса потом изменится.

Хороший пример — сценарий регистрации. Оба приложения могут отправлять screen_view с screen=signup, затем screen_state с state=loading, а позже state=error или state=ready. Это скучно специально. Скучные названия хорошо живут долго и сильно экономят время, когда команда разбирает падение воронки.

Разделяйте действия и результаты

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

Записывайте действие в момент, когда пользователь действует. Если человек нажал «Создать аккаунт», отправьте это событие сразу, даже если запрос провалится через секунду. Продукт сможет измерить намерение пользователя, а разработка — отследить, что произошло после нажатия.

А результат фиксируйте отдельным событием. sign_up_submit_tapped и sign_up_submit_failed рассказывают историю гораздо чище, чем одно объединённое событие. Воронки остаются читаемыми, потому что видно разрыв между действием и исходом, а не всё, слитое в одну линию.

Не тащите сетевые и серверные детали в название действия. Действие остаётся нажатием, даже если телефон потерял связь, API не ответил вовремя или сервер вернул ошибку. Добавляйте детали в событие результата с помощью свойств вроде error_type, http_status или attempt_number.

Хорошо работает простой шаблон:

• событие действия — для того, что сделал пользователь
• событие результата — для того, что вернулось от приложения
• свойства результата — для причины ошибки или деталей ответа

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

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

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

Настройте правило именования шаг за шагом

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

Именно здесь именование событий в мобильной аналитике становится проще в управлении. Вместо споров о названиях в code review вы определяете шаблон до того, как кто-то вообще отправит трекинг в прод.

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

Небольшой черновик может выглядеть так:

• signup_phone_view
• signup_phone_submit_tap
• signup_code_loading
• signup_code_sent
• signup_code_error

Выберите один порядок слов и не усложняйте. Если используете формат flow_screen_verb, придерживайтесь его. Если экраны заканчиваются на _view, а результаты — на _success или _error, не переключайтесь на полпути на названия вроде viewed_signup или error_on_code_screen.

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

Напишите несколько примеров до того, как разработчики начнут код. Продуктовая команда сможет рано заметить расплывчатые названия, а инженеры — поймать пограничные случаи до того, как они превратятся в грязные отчёты. Например, команда может увидеть, что code_resend_tap — это действие, а code_resent — результат. Их нужно держать отдельно.

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

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

Как обрабатывать повторы, не ломая воронки

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

Считайте повтор как то же самое намерение, которое случилось ещё раз. Оставляйте одно событие действия для этого шага и сохраняйте номер попытки как свойство. Первая попытка — attempt_number: 1, вторая — 2 и так далее. Так воронка остаётся читаемой, но при этом видно, как часто людям нужна была ещё одна попытка.

Хорошо работает небольшой набор правил:

• отправляйте одно и то же событие действия каждый раз, когда пользователь повторяет то же самое намерение
• храните успех и неудачу повтора в том же шаблоне результата, который уже используете
• добавляйте свойства для контекста, например attempt_number, retry_type или failure_reason

Сценарий с проверочным кодом хорошо показывает идею. Используйте verification_submit каждый раз, когда пользователь отправляет код. Оставляйте результаты как verification_success и verification_failure, независимо от того, сработало это с первого или с четвёртого раза. Если пользователь отправляет код ещё раз, отправляйте то же событие действия с attempt_number: 2. Если приложение само повторяет запрос после обрыва сети, не меняйте название события, а добавьте retry_type: auto.

Именно здесь многие команды ломают именование событий в мобильной аналитике. Они придумывают названия вроде otp_retry_submit, otp_retry_success, otp_timeout_retry и otp_resend_failed_again. Отчёты становятся труднее просматривать, а шагов в воронке появляется больше без всякой необходимости.

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

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

Простой пример на регистрации

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

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

Когда пользователь нажимает «Отправить код ещё раз», фиксируйте нажатие отдельным действием: phone_verification_resend_tap. После этого отдельно логируйте результат с помощью phone_verification_resend_success или phone_verification_resend_failure. Именно здесь именование событий в мобильной аналитике часто идёт не так. Команды объединяют нажатие и исход в одно событие, и потом уже никто не понимает, не сломалось ли приложение или пользователь вообще не пробовал.

Пользователь получает новый код, вводит его и отправляет снова. Это всё ещё должен быть тот же сценарий проверки. Запишите phone_verification_submit_tap, а затем результат, например phone_verification_success или phone_verification_failure.

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

phone_verification_screen_view
phone_verification_timeout_shown
phone_verification_resend_tap
phone_verification_resend_success
phone_verification_submit_tap
phone_verification_success

Чтобы отчёты было легче читать, добавляйте несколько свойств вместо придумывания новых названий событий. Хорошие примеры — flow_id, retry_count и error_type. Если пользователь отправляет код ещё раз, retry_count становится 1. Если повторная отправка не удалась, error_type может быть timeout или rate_limit.

Такая структура делает воронку простой: ввели номер, дошли до проверки, отправили код, закончили регистрацию. Путь с повторной отправкой остаётся внутри шага проверки и не разбивает его на лишние ветки. Продукт по-прежнему может измерять отвал. Разработка по-прежнему видит, что именно сломалось — таймаут, повторная отправка или вызов отправки. Обе команды читают одну и ту же историю из одних и тех же данных.

Ошибки, из-за которых отчёты трудно читать

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

Одна из частых ошибок — запихивать имя экрана в каждое событие действия. В итоге получаются названия вроде signup_screen_button_tap, pricing_screen_button_tap и profile_screen_button_tap. Это не три разных действия пользователя. Это одно и то же действие в трёх разных местах. Когда команды так делают, отчёты заполняются почти дубликатами, а простые вопросы начинают занимать слишком много времени.

Расплывчатые глаголы создают ту же проблему. clicked, tapped, interacted и engaged звучат безобидно, но скрывают, что именно сделал пользователь. Пользователь отправил форму, открыл меню, повторил платёж или закрыл ошибку? Если название этого не говорит, продукт и разработка будут читать один и тот же график по-разному.

Ещё одна проблема возникает, когда команды iOS и Android называют одно и то же по-разному. Одно приложение отправляет sign_up_started. Другое — registration_begin. Теперь дашборд считает один шаг двумя. После этого никто не верит итоговым цифрам, а ручная очистка становится частью каждого разбора.

Более чистый шаблон выглядит так:

• используйте одно и то же название действия на каждой платформе
• отслеживайте просмотр экрана как отдельное событие
• если нужен контекст, храните имя экрана в свойстве
• используйте конкретные глаголы вроде submit, retry, dismiss или view

Переименование событий во время релиза может сломать отчёты, даже если новое название лучше. Если версия 1.8 три дня отправляет checkout_submit, а версия 1.9 без пояснения переключается на purchase_submit, недельные графики распадаются пополам. Команда может решить, что конверсия упала, хотя на самом деле изменилось только имя.

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

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

Быстрые проверки перед релизом

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

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

Перед отправкой приложения проверьте следующее:

• каждое событие должно указывать на одно намерение пользователя. tap_sign_up понятно. signup_cta_flow — нет.
• состояния экранов должны использовать шаблон, отличный от действий. Например, держите screen_view или screen_error отдельно от tap_continue.
• повторы должны оставаться внутри того же шага. Отслеживайте повтор через свойство вроде retry_count или attempt_number, а не добавляйте новое событие в воронку.
• продукт и разработка должны пройти один и тот же пример сценария и сравнить, что они ожидают увидеть в отчётах.
• уберите любое название события, которое смешивает действие и результат в одной метке, если только это действительно не единственная метрика, которая вам нужна.

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

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

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

Что делать дальше

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

Не пытайтесь переименовать всё сразу. Обычно это создаёт недели споров и всё равно оставляет старые дубликаты. Один сценарий, один релиз, один понятный набор правил — быстрее и проще проверить.

Хороший следующий шаг выглядит так:

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

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

Держите короткий общий документ с несколькими примерами. Покажите, как вы называете действия пользователя, состояния экранов, результаты и повторы. Когда начинается новая функция, инженеры смогут следовать шаблону, а не гадать. Именно так именование событий в мобильной аналитике остаётся читаемым со временем, а не только во время уборки.

Перед каждым релизом помогает простой тест: может ли продакт-менеджер прочитать названия событий и понять воронку без просьбы о переводе? Если нет — переименуйте сейчас. Исправить названия до релиза дёшево. Исправлять сломанные отчёты после запуска — нет.

Некоторым командам полезен внешний разбор после первого черновика. Это особенно помогает, когда внутренние привычки уже запутаны или несколько приложений живут по разным правилам. Oleg Sotnikov может посмотреть ваш план трекинга и поток приложения в рамках консультации Fractional CTO и подсказать, где именование запутает воронки, повторы или отслеживание состояний экранов, ещё до того, как это превратится в шум в отчётах.