推广 / ROBLOX

Roblox 商店漏斗：区分重复访问与购买结果

为玩家在同一游戏会话中多次打开的商店规划分析。用 funnelSessionId 区分每次尝试，定义可以观察的步骤，并避免把查看商品写成尚未确认的购买。

更新日期: 2026-10-08

选择一个重复流程问题 #

设想练习道具商店：玩家打开窗口、看一张商品卡、关闭，然后稍后回来。一条“来过商店”的记录无法说明这两次尝试。第一次可能止于浏览，第二次可能到达购买请求。先提出需要分开访问的问题：每次尝试在哪一步停止继续？

这里使用虚构的 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 events
Roblox Creator Hub — AnalyticsService API