Продвижение / ROBLOX
Воронка магазина Roblox: как разделить повторные открытия и покупки
Составь план аналитики магазина, который игрок открывает несколько раз за сеанс. Раздели попытки через funnelSessionId, задай точные условия шагов и проверь, что просмотр товара не превращается в выдуманную покупку.
Выбери вопрос для повторяющегося сценария #
Представь магазин учебных предметов: игрок открывает окно, смотрит карточку, закрывает его и позже возвращается. Одной записи «игрок был в магазине» недостаточно, чтобы понять обе попытки. Первая могла закончиться просмотром, вторая — запросом покупки. Начни с вопроса, который требует различить эти посещения: на каком шаге останавливаются отдельные попытки?
Для упражнения используем условную воронку PracticeShop. Это проект измерения следующей игры, а не отчёт наших игр. Здесь не отправлялись события AnalyticsService, не проводились покупки и не менялся игровой код. Никакие цифры конверсии не заявлены. Сначала нужно договориться о смысле попытки и каждого шага, а уже затем реализовать наблюдение.
Задай начало и конец одной попытки #
Опиши правило начала: какое фактически подтверждённое открытие магазина создаёт новую попытку? Затем определись с закрытием, переходом в другой раздел и возвратом. Переключение между карточками может оставаться внутри одного посещения; это выбранное правило проекта. Не создавай отдельную попытку для каждого кадра интерфейса или изменения выделенного товара.
Для примера попытка A заканчивается закрытием магазина, а повторное открытие начинает попытку B. Такая граница помогает проверить реализацию обычными действиями. Запиши её в паспорт воронки вместе с версией. Если потом изменишь правило, старые и новые события не должны без пояснений выглядеть как один неизменный сценарий.
Открыть изображение крупнее ↗Раздели идентификатор игрока и попытки #
В повторяющейся воронке funnelSessionId связывает шаги одной попытки и отличает её от другой попытки того же игрока. Один игровой сеанс может содержать несколько посещений магазина. Поэтому «тот же игрок» и «та же попытка» — разные отношения, которые важно сохранить при чтении журнала.
Условные обозначения A и B на схеме — учебные подписи, не реальные идентификаторы. Для выбранного нового сценария нужен новый ID, а его следующие шаги должны использовать тот же ID. Две ошибки имеют противоположный эффект: постоянный ID смешивает посещения, новый ID на каждом шаге разрывает последовательность. Проверь оба случая в плане до работы с графиком.
Открыть изображение крупнее ↗Составь словарь проверяемых шагов #
Укажи номер, короткое имя и точное условие завершения каждого шага. Для примера: ShopOpened — согласованное открытие, ItemViewed — показ выбранной карточки, CheckoutRequested — начало предусмотренного процесса покупки. Названия условные; важно, чтобы два разработчика одинаково понимали, когда именно событие допустимо отправить.
Последний шаг GrantConfirmed означает подтверждённую выдачу только при наличии отдельно проверенной системы покупки и выдачи. Он не наступает от нажатия кнопки, появления платёжного окна или его закрытия. Если эта система пока не готова, ограничь учебную воронку просмотром. Полная картинка с фиктивным финальным шагом хуже честно ограниченного измерения.
| Условный шаг | Что подтверждает |
|---|---|
| ShopOpened | Согласованное открытие |
| ItemViewed | Выбранная карточка показана |
| CheckoutRequested | Начало процесса покупки |
| GrantConfirmed | Только подтверждённая выдача |
Определи серверный источник события #
Документация допускает отправку этих аналитических событий с сервера в опубликованной игре; Studio и клиент не являются средой такой отправки. Поэтому отдели интерфейсное наблюдение от серверного решения о допустимости шага. Например, сообщение о просмотре должно относиться к существующей попытке и разрешённому шагу, а не к произвольному номеру клиента.
Составь карту: условие, подтверждающий участок серверной логики, номер шага и используемый ID. Здесь нет готового кода магазина или универсального валидатора. Карта показывает, что разработчику предстоит проверить. Игровая операция и регистрация её наблюдения также различаются: аналитический вызов не должен сам выдавать товар или создавать право на него.
Проверь повтор одного шага #
Карточка товара может открыться повторно в той же попытке. Согласно документации, воронка учитывает первое появление повторённого шага, но повторные отправки продолжают расходовать лимит. Поэтому отсутствие удвоения на графике не доказывает, что обработчик вызывается только один раз или работает экономно.
В плане проверки отдельно отметь повторный показ одной карточки, выбор другой карточки и повторное открытие магазина. Это три различных действия. Записывай, какой ID и номер были использованы, и сравнивай с выбранной границей сценария. Не добавляй бессмысленные повторные отправки ради активности отчёта; каждое наблюдение должно иметь понятную причину.
Не теряй смысл пропущенных этапов #
Поздний шаг в воронке может автоматически заполнить предыдущие шаги в отчёте. Из этого нельзя заключить, что все ранние действия действительно наблюдались твоими обработчиками. Если подтверждение выдачи видно, а открытие почти не записывается, сначала проверь последовательность и условия отправки, прежде чем делать вывод о поведении игроков.
Для проверки предложи случай с отсутствующим ранним шагом и запиши ожидаемую особенность отчёта отдельно от журнала фактических вызовов. Не превращай это в инструкцию отправлять выдуманные достижения. Цель — обнаружить ошибку маршрута или неполное наблюдение. Сохрани различие между известным игровым действием и тем, что инструмент выводит из более позднего события.
Пройди два посещения по журналу #
В первом предложенном сценарии игрок открывает магазин, смотрит карточку и закрывает окно без покупки. Во втором он снова открывает магазин и начинает предусмотренный процесс покупки. Журнал должен разделять A и B и показывать порядок шагов каждой попытки. Слово «запрос» во втором случае ещё не означает оплату или выдачу.
Для каждой попытки сохрани условное обозначение, начало, использованные номера и причину завершения. Финальную выдачу записывай лишь после собственного подтверждения. Таблица содержит план и ожидания, не результаты проведённой игры. Проверку отправки автор выполняет в подходящей опубликованной среде; в статье настоящие события не отправлялись.
Читай отчёт с учётом версии и периода #
Сопоставляй отчёт со словарём шагов и версией сценария. После изменения определения открытия или переименования этапа выбери период, относящийся к нужной версии, и отметь границу обновления. Один смешанный период может скрыть изменение смысла, даже если номера шагов остались прежними.
Документация также ограничивает отслеживание последними десятью уникальными funnelSessionId на пользователя и воронку. Не используй механизм как бесконечный архив попыток и не переиспользуй старый ID ради продолжения давно закрытого посещения. Для исследовательского вывода нужны реальные данные и понятная выборка; здесь их нет, поэтому рост покупок не заявляется.
Передай понятный паспорт разработчику #
Передай вопрос, границу попытки, словарь, карту серверных условий, правила ID и журнал двух предложенных посещений. Добавь список ещё не выполненных проверок. Так другой чат сможет реализовать измерение без догадок о том, что означает «покупка», и без смешивания игровой сессии с посещением магазина.
Готовая схема измерения не гарантирует улучшения продаж и не заменяет обработку выдачи. Цели сайта измеряют другие действия и не подтверждают внутриигровую покупку. В этом материале оригинальные схемы и план проверок; нет оплаты, настоящих конверсий или изменений наших игр. Следующий шаг — проверить реализацию и только после этого интерпретировать наблюдения.
| Паспорт | Что сохранить |
|---|---|
| Граница | Начало и конец попытки |
| Словарь | Номер, имя и условие |
| Источник | Серверный участок подтверждения |
| Версия | Дата и изменение смысла |
Первоисточники
Roblox Creator Hub — Funnel eventsRoblox Creator Hub — AnalyticsService API
