1. 拿到试卷先别急着做题：吉比特到底在筛选什么人
前阵子帮一个学弟做秋招模拟辅导，他把压箱底的“吉比特2018秋招数据分析岗位试卷B卷”翻出来让我帮忙拆解。说实话，这份试卷虽然是几年前的老题，但放在今天看依然有很强的参考价值——不是因为题目有多难，而是因为它的出题思路非常典型地代表了游戏行业数据分析岗的考核逻辑：既考硬核的数据处理能力，又考对业务的理解深度。如果你正在准备游戏公司或者其他互联网公司的数据分析岗位，这份试卷的复盘绝对值得你看完。
1.1 从题型分布看岗位定位
拿到这种试卷，我通常会先做一件事：把整个卷面按题型和分值切一遍，看看公司想招的到底是一个“写SQL的工具人”，还是一个“能跟运营对话的决策支持者”。从B卷的常见题型分布来看，大体可以分成三大块：
- 数据处理基础（SQL、Excel、Python等工具类题目，约占总分30%-40%）
- 统计学与概率论（假设检验、分布、AB实验相关，约占比20%-30%）
- 业务案例分析（游戏留存、付费、版本评估、活动效果等开放型问题，约占比30%-40%）
这是典型的“技术+业务”双轮驱动模型。吉比特做的是游戏产品，意味着数据分析师的核心场景集中在游戏的生命周期管理上——从拉新、激活、留存，到付费、流失召回，每一个环节都需要数据支撑。所以试卷不会只考冷冰冰的代码能力，更看重你能不能把数据翻译成业务动作。
这一点和很多纯互联网公司不太一样。纯互联网公司可能更偏向流量增长、用户行为漏斗，而游戏公司一定绕不开“版本”“活动”“付费点”这三个关键词。备考时如果还在傻傻刷LeetCode，没有建立游戏业务的分析框架，大概率会在业务题上翻车。
1.2 游戏公司笔试和互联网大厂的隐形差异
很多同学在准备笔试时习惯性地按互联网大厂的套路刷题，结果到了游戏公司就懵了。我自己对比过不少公司的笔试卷，游戏公司的数据分析笔试有几个非常明显的差异：
第一，场景出题极其具体。互联网公司可能问“某App的次日留存下降，请分析原因”，游戏公司则可能问“某卡牌游戏新版本把抽卡概率从1%调到1.5%之后，首日流水翻倍但付费人数下降，请评估这个改版的健康度”。同样是留存问题，游戏公司会前置一个虚拟的世界观和商业背景，考察你在特定产品形态下的分析思路。
第二，对“数值敏感度”有隐性要求。游戏行业本身就是数值策划主导的行业，从攻击力、暴击率、掉落概率到VIP等级、月卡定价，全部是精确到小数的数值系统。笔试题目中有不少需要你手算概率或者毛估数值的场景，考察你是否具备“对数字有感觉”的基本素质。
第三，业务题没有标准答案，但有强烈的行业惯性。比如“版本更新后留存下降了”这类问题，如果你只在数据层面绕来绕去，不懂版本节奏、新功能解锁节点、玩家竞技环境等游戏特有因素，你的回答会很飘，缺少落地感。
所以拆解这份试卷时，我们的目标不是背答案，而是通过它反推一个游戏数据分析师的能力模型：SQL硬功夫打底，概率统计做骨架，业务思维做灵魂。
2. 硬核技术题拆解：SQL、概率统计到底在考什么
技术题是整份试卷的得分基本盘，也是大部分人最先动笔的部分。这类题目的特点是：看起来常规，但失分点极其隐蔽。我见过不少简历上写着“精通SQL”的同学，在笔试里被一道留存计算题卡了半小时，最后交上去的答案还是错的。
2.1 留存计算这类SQL题，考察的是数据口径理解
B卷中出现SQL题几乎是必然的，结合历年考生回忆，最常考的题型之一就是“玩家留存计算”。给你一张用户登录表或者用户活跃表，要求计算某段时间内新增用户的次日留存率、7日留存率等。这类题表面考SQL语法，实际考数据口径的掌握。
拿留存计算举个例子。假设有表结构如下：
- 用户新增表：
user_install(user_id, install_date) - 用户活跃登录表：
user_login(user_id, login_date)
要计算“2023-01-01新增用户在次日是否活跃”，很多人的第一反应是直接JOIN两张表，然后按日期统计COUNT(DISTINCT user_id)。这个方向没错，但有几个关键点很容易漏：
第一，活跃表是流水表，一天内可能有多条登录记录，一定要去重。如果一个用户同一天登录了8次，你按天join后这个用户就会出现8条记录，COUNT(*)直接翻倍。必须用COUNT(DISTINCT user_id)才能保证口径正确。
第二，join的条件不能只写“次日登录”，要用日期差做窗口。比如用DATEDIFF(b.login_date, a.install_date)=1来表示次日，这样能顺便支持后续扩展成3日留存、7日留存，只需改条件即可。
第三，从整体留存率的角度考虑，要保留新增用户全量表，用左连接。如果某个新增用户次日没有登录，他就不会出现在活跃表里，INNER JOIN会把他过滤掉，导致你的分母变小、留存率虚高。
一个可参考的标准写法如下：
SELECT a.install_date, COUNT(DISTINCT a.user_id) AS new_user_cnt, COUNT(DISTINCT IF(DATEDIFF(b.login_date, a.install_date)=1, a.user_id, NULL)) AS next_day_active_cnt, ROUND(COUNT(DISTINCT IF(DATEDIFF(b.login_date, a.install_date)=1, a.user_id, NULL)) / COUNT(DISTINCT a.user_id) * 100, 2) AS next_day_retention_rate FROM user_install a LEFT JOIN user_login b ON a.user_id = b.user_id WHERE a.install_date = '2023-01-01' GROUP BY a.install_date;这里用IF(DATEDIFF(...)=1, user_id, NULL)的方式做一个条件去重，既保留了分子，又不影响分母的统计，是笔试题里比较稳妥的写法。当然现在很多人会直接用窗口函数或者CASE WHEN来写，逻辑一样，关键是思路清晰、字段写对。
这道题给我最大的感受是：SQL语法一分钟能写完，但对“活跃流水可能重复”“流失用户不能从分母中消失”这些实际业务场景的理解，才是真正拉开差距的地方。如果你没有实际处理过游戏数据，很容易在这个看似简单的题目上翻车。
2.2 概率统计题最爱埋的坑：假设检验与条件概率
统计题在吉比特B卷里偏向“游戏化”场景包装。概率论和统计学的考察点和常规互联网笔试类似，但因为游戏数据天然带随机性——掉落概率、抽卡概率、暴击概率——所以出题角度会更显生动。
常见题目类型包括：
- 一组抽卡概率题：某SSR角色基础概率1%，加上保底机制后问期望抽数；
- 一个AB实验显著性判断：调整了关卡难度后，对比两组玩家的通过率是否显著差异；
- 一个贝叶斯条件概率题：已知某付费礼包的购买率，在用户是“活跃用户”条件下的重新测算。
这类题目的核心难点往往不在记忆公式，而在“识别出这道题在考哪个统计概念”。
举一个很典型的AB实验题思路：
某游戏对新手引导流程做了改版。对照组1000人，完成引导的人数400人；实验组1000人，完成引导的人数450人。改版是否显著提升了引导完成率？
很多人看到这个题目直接说“完成率从40%提升到45%，提升了5个百分点，效果显著”——这个答案在笔试里是要扣大分的。因为你没有排除随机波动的可能性。正确的做法是做一个两样本比例z检验：
- 计算合并比例：p = (400+450)/(1000+1000) = 0.425
- 标准误：SE = sqrt(p*(1-p)*(1/1000+1/1000)) ≈ 0.0221
- z = (0.45-0.40)/0.0221 ≈ 2.26
- 对应的p值约为0.024，小于0.05，结论是“在95%置信水平下有显著提升”
在实际答题的时候，你当然不需要写那么多计算步骤，但至少要体现“先做显著性检验，再下结论”的意识，并且最好能提到“样本量差异”“是否随机分组”等潜在问题。这样得分率会高很多。
还有一类概率题是贝叶斯，我建议你把“先验概率×似然”的标准流程熟练掌握。题目的陷阱往往在于把条件概率和联合概率混在一起。比如“玩家付费的概率是10%，付费玩家中月卡的占比是50%，月卡玩家占整体玩家的比例是8%”——求一个玩家是付费玩家的概率，实际上考的可能是贝叶斯公式的逆推，不是简单的乘法。
2.3 业务分析简答题的答题框架
除了SQL和统计，B卷通常还有一两道“大白话式”的业务分析简答题。这类题不给你数据表，只给你一个业务场景，让你用数据分析师的方式把思路和步骤写出来。
我的经验是，这类题考察的不完全是“分析能力”，更是“结构化表达能力”。有些同学业务sense其实很好，但答题时东一句西一句，没有框架，得分很低。我的建议是养成一个标准答题结构：
- 明确业务目标：这个分析的最终产出是解决什么问题，评估什么决策；
- 定义核心指标：主指标、护栏指标、过程指标分别是什么；
- 数据获取与口径：需要哪些数据表，时间窗口，用户分组口径；
- 分析方法：对比分析、漏斗分析、留存队列、回归分析还是AB实验；
- 风险与边界：分析结论的局限性、样本量、相关性不等于因果性等。
这个“五段式”框架能帮你把任何一道业务简答题都答得条理清晰。你在平时练习时就要形成肌肉记忆，上了考场才能行云流水。
3. 游戏业务题才是重头戏：付费、版本、活动里的数据分析思维
技术题决定了你的下限，而业务题决定了你的上限。吉比特B卷的业务题设置，如果和历年大厂真题对照一下，你会发现它特别偏好三个场景：版本更新评估、活动效果分析、付费体系诊断。这三个场景几乎覆盖了一款游戏商业化的核心生命周期。
3.1 版本更新效果评估类题目怎么答才不跑偏
游戏行业每隔一两周就会有一个小版本更新，每隔一两个月会有大版本迭代。所以数据分析师最经常遇到的业务问题就是“版本更新后，核心数据涨跌了，怎么评估这次改版到底好不好”。
B卷在这一类题目上的考察方式往往是给你一组前后对比数据，比如：
- 更新前：次日留存32%、7日留存15%、付费率6%、ARPPU（付费用户平均付费额）60元；
- 更新后：次日留存29%、7日留存17%、付费率5%、ARPPU 75元。
然后问你：这个版本到底是好是坏，请说明判断逻辑。
很多人的第一反应是“留存下降，所以改版失败”。但真正的数据分析师会先拆开看：
第一，先看核心用户是谁。次日留存下降，可能被新进用户质量的波动干扰，而7日留存上升说明中后期内容对老玩家更友好。如果这是针对成熟玩家的养成系统改版，次日留存的微弱下降是可以接受的。
第二，付费率和ARPPU要放在一起看。付费率从6%降到5%，ARPPU从60元涨到75元，说明免费玩家里本来就不付费的那部分没有受太多影响，而付费玩家的付费深度被激活了。在收入公式（流水=DAU×付费率×ARPPU）中，如果整体流水反而上升，那这个版本在变现侧就是健康的。
第三，要提出一个验证方案，而不是只看结果。更专业的回答会提到“用同期进行的分层对比来排除事件干扰”，比如把版本更新前新增的用户和版本更新后新增的用户做增量对比，或者用ARIMA模型做一个反事实预测，看实际值是否偏离预测区间。
这道题的核心考点是：分析师不能只看一个指标，而要看一个系统。游戏版本改版很少出现全指标普涨或普跌，大多数情况是此消彼长，你要能判断这种消涨是否是战略上可接受的。当年我做过一次版本评估，主策见面第一句话就是“你别告诉我次留跌了，你告诉我这个版本对哪些人是好的”——这句话我一辈子忘不了，也是游戏数据分析最真实的写照。
3.2 活动效果与付费分析的常见陷阱
活动效果分析是游戏数据分析的另一个高频业务题。比如出个首充双倍活动，或者节日限定卡池，B卷可能会问“活动上线后流水涨了50%，这个活动到底算不算成功”。
这类题最经典的陷阱叫做**“把活动增量当成活动全量”**。
一个活动上线期间，流水里既有自然流量带来的自然流水，也有活动拉动的增量流水，我们做效果分析时真正关心的是增量那部分。如果你只是看“活动期间的流水流水大于活动前”，很容易把季节性自然增长、版本更新拉动等混淆在里面。
正确的开放思路是：用活动前一段时间的日均流水做基线，再排除其他变动因素（比如是否有新角色上线、是否有大版本同步发布），然后计算活动期间超出基线的部分，再扣除参与活动的用户中原本就会付费的自然消费。更进一步，还要分析活动的“前置拉动”和“后置透支”——很多玩家会为了活动提前囤积资源、延后付费，导致活动前后流水出现一个低洼期，这部分效应不剔除，你的活动ROI就是虚高的。
付费分析与活动分析常常合并考察。我对这类题的建议是：牢记“用户分层”这四个字。把所有玩家按新老、付费/免费、活跃/沉默做过交叉分组，再看每组在活动前后的行为变化。不要直接拉出一个总量就说好说坏，那大概率会被追问到露出马脚。
3.3 这类题的高分答题结构
如果你在考场上真的遇到一道完全没见过的游戏业务题，别慌，直接用下面的结构来组织答案：
- 先定义“什么叫好”：给成功下一个可量化的定义，这个定义要包含业务目标和用户价值，不要只盯流水；
- 再拆解“变化的来源”：从用户结构（新增、回流、老用户）和付费结构（首付、复购、大R）两个维度拆解变化来源；
- 然后给出“验证方法”：提到AB测试、分组对比、时间序列、漏斗分析等具体方法；
- 最后阐述“下一步建议”：基于可能的结论，给出运营、策划、投放不同侧的建议。
这套结构其实是数据分析师日常汇报的基本功，笔试只是把它压缩到一个小时以内。平时练题时你就能用这个框架去套各种场景，练多了自然形成条件反射。
4. 复盘之后的核心经验：这些坑我当年都踩过
笔试复盘的价值不仅在“看懂答案”，更在于“看懂坑”。我见过太多人笔试挂掉，不是因为知识储备不够，而是倒在时间管理、答题顺序和表述不清晰这些“非知识项”上。把自己真实踩过的坑拿出来说说，希望能帮你避开。
4.1 时间分配失误：死在简答题上
我自己早年参加笔试时就犯过一个特别蠢的错误：拿到卷子之后从头做起，在一道SQL留存的题目上死磕了35分钟，结果后面的业务分析题只剩十分钟，完全是手忙脚乱地糊上去的。出考场我才意识到，那道SQL题即便写得完美，分值占比也不超过20%，而业务题写得好不好，直接决定面试官愿不愿意跟你聊下一轮。
这里分享一个我后来一直在用的做题顺序：
- 花2分钟通读全卷，把每道题的分值和难度快速评估一遍；
- 先做自己最有把握的题，把分拿到手；
- 再做业务分析题，因为这类题需要的大脑清醒度最高，放到后面容易思维混乱；
- 最后做技术题里需要手写代码或SQL的部分，这类题一旦卡住果断跳过，不能恋战。
这个策略不是万能的，但能保证你不会“因小失大”。考场上最可惜的不是不会做，而是会的没时间写。
4.2 答题顺序和不必要的炫技
我在模拟批改的时候发现一个常见问题：很多考生喜欢在SQL题里写窗口函数、在统计题里写一堆公式推导，展示自己“很懂”。但笔试阅卷是一个快速扫描的过程，面试官更关注的是清晰的逻辑，而不是花哨的语法。
比如SQL题的答案，与其写一个3层嵌套的复杂子查询，不如拆成两个清晰的临时表，或者用注释标明每一步的意图。面试官在有限时间里能快速理解你的思路，比什么都重要的。
统计题的格式也很重要。“z=2.26, p=0.024, 拒绝原假设”这15个字，比写了一整页的公式计算过程得分更高。记住：职场里的数据分析是做决策辅助，不是写论文，清晰和能让别人看懂永远是第一位的。
另外，业务题切不可用“可能”“也许”“大概是这样”这类模糊词。做出判断要有依据，哪怕是虚拟数据也要用具体指标支撑。面试官最怕的就是一个数据分析师讲了一堆“我猜感觉应该是”。
4.3 给后来人的准备清单
最后，把这份试卷的价值转化成一个真正可落地的准备清单。如果你正在准备游戏公司数据分析岗的笔试，建议按以下四个方面准备：
第一，SQL熟练度必须达到“闭着眼写留存”的程度。留存、漏斗、LTV、付费率、ARPU、ARPPU……这些游戏行业最常用的指标口径，全部要能用SQL实现。刷题时别只刷LeetCode上的数据库题，要专门找游戏业务数据集来练。
第二，统计学的核心概念要能“手算且解释”。假设检验、t检验、z检验、卡方检验、AB实验的原理和适用条件要烂熟于心。不仅要会算，还要能解释给策划和运营听。能把“p值小于0.05，所以我们认为这个差异不是随机波动”这句话讲得让非技术同事也听懂的，才是真正的本事。
第三，建立“游戏业务分析框架”。围绕生命周期运营，梳理出拉新→激活→留存→付费→传播每个环节中，数据分析师要关注的核心指标、分析维度和常见业务问题。比如拉新阶段看渠道质量和获客成本，留存阶段看新用户首日体验和关卡难度曲线，付费阶段看付费渗透率和复购曲线。
第四，做一次“模拟真题演练”。找一套完整的游戏数据分析笔试题，严格按90分钟时间模拟考试。做完之后别急着对答案，先自己复盘一遍：每道题的思考路径是否清晰、逻辑是否闭环、有没有跳步。然后再对照参考答案或找人批改。
根据我个人的实操体会，游戏数据分析岗位笔试的难度其实没有想象中高，但它对“这行当到底在解决什么业务问题”这件事的要求是隐性而持续的。如果你只是把数据当工具，那考完试也就结束了；但如果你真的理解游戏产品靠什么赚钱、靠什么留住人，那么这份试卷只是一块敲门砖，你会在后面的面试和实际工作中越走越顺。
