吉比特数据分析笔试复盘：SQL、统计与游戏业务题全拆解

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 (400450)/(10001000) 0.425标准误SE sqrt(p*(1-p)*(1/10001/1000)) ≈ 0.0221z (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层嵌套的复杂子查询不如拆成两个清晰的临时表或者用注释标明每一步的意图。面试官在有限时间里能快速理解你的思路比什么都重要的。统计题的格式也很重要。“z2.26, p0.024, 拒绝原假设”这15个字比写了一整页的公式计算过程得分更高。记住职场里的数据分析是做决策辅助不是写论文清晰和能让别人看懂永远是第一位的。另外业务题切不可用“可能”“也许”“大概是这样”这类模糊词。做出判断要有依据哪怕是虚拟数据也要用具体指标支撑。面试官最怕的就是一个数据分析师讲了一堆“我猜感觉应该是”。4.3 给后来人的准备清单最后把这份试卷的价值转化成一个真正可落地的准备清单。如果你正在准备游戏公司数据分析岗的笔试建议按以下四个方面准备第一SQL熟练度必须达到“闭着眼写留存”的程度。留存、漏斗、LTV、付费率、ARPU、ARPPU……这些游戏行业最常用的指标口径全部要能用SQL实现。刷题时别只刷LeetCode上的数据库题要专门找游戏业务数据集来练。第二统计学的核心概念要能“手算且解释”。假设检验、t检验、z检验、卡方检验、AB实验的原理和适用条件要烂熟于心。不仅要会算还要能解释给策划和运营听。能把“p值小于0.05所以我们认为这个差异不是随机波动”这句话讲得让非技术同事也听懂的才是真正的本事。第三建立“游戏业务分析框架”。围绕生命周期运营梳理出拉新→激活→留存→付费→传播每个环节中数据分析师要关注的核心指标、分析维度和常见业务问题。比如拉新阶段看渠道质量和获客成本留存阶段看新用户首日体验和关卡难度曲线付费阶段看付费渗透率和复购曲线。第四做一次“模拟真题演练”。找一套完整的游戏数据分析笔试题严格按90分钟时间模拟考试。做完之后别急着对答案先自己复盘一遍每道题的思考路径是否清晰、逻辑是否闭环、有没有跳步。然后再对照参考答案或找人批改。根据我个人的实操体会游戏数据分析岗位笔试的难度其实没有想象中高但它对“这行当到底在解决什么业务问题”这件事的要求是隐性而持续的。如果你只是把数据当工具那考完试也就结束了但如果你真的理解游戏产品靠什么赚钱、靠什么留住人那么这份试卷只是一块敲门砖你会在后面的面试和实际工作中越走越顺。