Roblox 新手漏斗：找出玩家在哪一步停止前进

先提出问题，而不是先画图 #

设想新玩家在工坊领取包裹，走到站点，然后收到配送确认。作者发现会话很短，便怀疑路线太长。但玩家可能在领取前就离开，也可能不理解按钮，或完成配送后没注意到奖励。总会话时长无法区分这些情况。

先问一个具体问题：在哪个可验证动作之后，最多的新手不再继续？这个问题先确定事件顺序，再帮助你选择工具。不要把目标设为尽量多发分析事件。每个事件应回答行为问题，而不只是证明某个函数被调用。好的流程能说明玩家已经完成什么，以及接下来应该调查哪一段。

网站和游戏观察不同动作 #

点击网站上的“开始游戏”确认的是链接交互。它不证明玩家进入了服务器、完成订单或收到道具。游戏内路径需要单独测量。没有合理的关联方式时，不应把网站访客和游戏玩家混成同一漏斗。

本教程使用 Roblox 分析，不是在 Yandex Metrica 中新建目标。网站计数器保持不变。阅读攻略很久，也不能据此发送游戏内“教学完成”事件。应在动作实际发生的位置确认它。明确这条边界，能避免把网站上的一次成功点击变成虚构的游戏成就，也能让分析结论更容易理解。

定义工坊的四个阶段 #

我们提出自己的顺序：玩家进入教学场景；服务器分配首个订单；服务器确认配送；服务器实际发放首个奖励。这些是本例的设计名称，不是 Roblox 强制阶段。为每一步记录编号、稳定名称和准确的完成条件。

“显示提示”不等于“领取订单”。如果调查的是提示是否可见，可以单独记录显示，但不能代替领取动作。同样，出现宝箱不等于奖励到账。计划表应说明哪项服务器状态能证明每一步，方便另一位开发者检查埋点，而不必猜测“完成”究竟意味着什么。

打开大图 ↗

在正确环境中发送事件 #

Roblox 文档介绍了用于新手教学的 LogOnboardingFunnelStepEvent，以及其他漏斗使用的 LogFunnelStepEvent。事件由已发布游戏的服务器发送；Studio 不会向该服务发送事件。因此，用模拟发送器测试处理函数，不证明 Creator Hub 已收到数据。

把游戏条件验证和分析发送分开。服务器知道订单是否分配、配送是否被接受，可以随后记录对应阶段。客户端请求“记录第四步”不能代替这些条件。下面的学习示例从服务器逻辑接收已验证阶段，而不是设备发来的任意编号。游戏处理函数仍然负责确认实际动作。示例没有接入正式游戏。

下面代码是 ServerScriptService 中名为 OnboardingObserver 的 ModuleScript。服务器 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 仅说明本地调用没有报错，不证明报表收到数据。发送失败后，较晚阶段会返回 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 漏斗筛选归属于第一步。途中更换设备，不会将整条结果转移到新组。解释数据时要考虑这点。不要假定最后一个动作一定发生在筛选显示的设备上。手动检查界面时，应另外记录测试者实际设备；它回答的问题与分析报表中的群组归属不同。

一次修改一件具体事情 #

选择可验证修改，例如把包裹说明移近站点，领取后显示方向，或让配送确认更明显。这些是虚构工坊的设计建议，不是已经加入作者现有游戏的功能。

如果想理解某项修改，不要同时调整路线、奖励、价格和界面。保留发布时间、场景版本与步骤定义。修改后比较适当时间段及玩家组成。玩家很少时，结果可能不稳定。这里没有保证所有游戏教学成功的通用百分比。结论应说明实际样本和仍然存在的不确定性。

打开大图 ↗

识别测量本身的问题 #

如果几乎人人有奖励事件，配送记录却很少，先检查发送顺序和跳步。如果更新后混杂不同步骤名称，选取对应目标版本的日期范围。如果没有数据，检查是否发布、是否服务器执行，以及完成条件是否真的发生。

不要靠虚构成就修补报表。即使分析发送失败，游戏仍应遵守自己的规则：记录成功不是奖励条件。明确区分游戏操作完成与该操作被成功观察。一个通道失败，不能让另一个出现虚假完成。好的诊断会解释这种区别，而不是用一个统一成功标记掩盖两个状态。

准备能交接的材料 #

把阶段表、完成条件、服务器调用位置、发布日期、测试计划和真实观察交给下一位开发者。另列未知项：尚未执行的测试、未验证筛选、很小的样本或缺少数据。其他聊天就能继续研究，而不把猜测当发现。

每一步代表明确动作，并在适当环境检查发送后，这个阶段才算准备好。但它不证明教学已改善或留存已提高。本文解释测量设计与研究循环。准备草稿时没有修改正式游戏的分析，也没有修改网站目标。今后任何实现都需要自己的验证和证据。