Воронка обучения Roblox: как найти шаг, на котором игроки перестают продвигаться

Начни с вопроса, а не с графика #

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

Сформулируй конкретный вопрос: после какого проверяемого действия перестаёт продвигаться больше всего участников обучения? Так ты определишь последовательность событий, а затем выберешь инструмент. Не начинай с цели «отправлять побольше аналитики». Каждое событие должно отвечать на вопрос о поведении, а не просто подтверждать, что очередная функция вызвалась.

Сайт и игра измеряют разные действия #

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

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

Четыре шага учебной мастерской #

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

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

Открыть изображение крупнее ↗

Где отправлять события #

Roblox документирует LogOnboardingFunnelStepEvent для первоначального обучения и LogFunnelStepEvent для других воронок. События отправляются сервером в опубликованной игре; Studio не отправляет их в сервис. Поэтому проверка собственного обработчика с подставным отправителем не подтверждает появление данных в Creator Hub.

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

Код ниже — ModuleScript OnboardingObserver в ServerScriptService. Серверный Script создаёт observer = OnboardingObserver.new(function(player, step, name) AnalyticsService:LogOnboardingFunnelStepEvent(player, step, name) end). Вызывай observer:RecordVerified(player, step) только после настоящего подтверждения соответствующего игрового действия; на уходе вызывай observer:Forget(player). Модуль не подключает RemoteEvent и не проверяет доставку посылки вместо игры. Он проверяет порядок 1–4 и подавляет повторы внутри текущего состояния. true означает завершение локального вызова без ошибки, а не появление записи в Creator Hub. После отказа следующий шаг будет OutOfOrder, пока предыдущий не отправлен успешно: проверяй диагностику, не блокируя за неё игровую награду. Состояние не сохраняется между серверами. Локальные Luau-тесты использовали подставной отправитель; настоящие события не отправлялись.

В начале вызывающего серверного Script объяви local AnalyticsService = game:GetService("AnalyticsService") и local OnboardingObserver = require(game:GetService("ServerScriptService"):WaitForChild("OnboardingObserver")). После создания observer подключи game:GetService("Players").PlayerRemoving:Connect(function(player) observer:Forget(player) end). Встраивай RecordVerified в существующие серверные обработчики подтверждённых действий, сохраняя их собственную проверку условий.

-- ModuleScript: OnboardingObserver, in ServerScriptService.
-- Call only from server logic after a verified gameplay action.
-- This module observes progress; it never grants rewards.
local Observer = {}
local names = {"EnteredWorkshop", "OrderAssigned", "DeliveryAccepted", "RewardApplied"}

function Observer.new(send)
    assert(type(send) == "function", "Sender required")
    local lastStep = {}
    local adapter = {}

    function adapter:RecordVerified(player, step)
        if player == nil then return false, "InvalidPlayer" end
        if type(step) ~= "number" or step ~= math.floor(step)
            or step < 1 or step > #names then
            return false, "InvalidStep"
        end
        local previous = lastStep[player] or 0
        if step <= previous then return false, "AlreadyObserved" end
        if step ~= previous + 1 then return false, "OutOfOrder" end
        local ok = pcall(send, player, step, names[step])
        if not ok then return false, "SendFailed" end
        lastStep[player] = step
        -- Local call completed. This is NOT a dashboard delivery receipt.
        return true, "CallCompleted"
    end

    function adapter:Forget(player)
        lastStep[player] = nil
    end

    return adapter
end

return Observer

Не пропускай начало ради красивого результата #

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

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

Повторы и пропуски тоже влияют на смысл #

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

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

Сначала убедись, что измерение работает #

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

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

Как читать условный спад #

Допустим, в вымышленном примере в сценарий вошло 100 участников, задание приняли 60, доставку завершили 45, награду получили 40. Это не статистика нашего сайта или игр. Между первым и вторым шагом не продвинулись 40 человек, но причина из этих четырёх чисел пока неизвестна.

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

Сравнение телефона и компьютера #

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

Фильтры воронки Roblox относятся к её первому шагу; смена устройства по ходу пути не переносит весь результат в новую группу. Запиши эту особенность в интерпретации. Не утверждай, что финальный шаг обязательно выполнялся на устройстве, указанном в фильтре. Для ручной проверки интерфейса отдельно фиксируй реальное устройство тестировщика.

Измени одну конкретную вещь #

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

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

Открыть изображение крупнее ↗

Когда проблема в измерении #

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

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

Что передать другому разработчику #

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

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