想进游戏大厂做数据分析，绕不开笔试题这道坎。搜狐畅游的BI工程师校招题，在当年算是游戏行业里比较有代表性的：不考八股文，不背题库，而是真刀真枪地考你能不能从玩家行为数据里读出业务信号。这篇文章就围绕这套笔试题，把游戏行业BI工程师的岗位本质、题型逻辑、答题框架和容易踩的坑一次性讲透。无论你是准备投游戏公司数据分析岗，还是想转行做BI，这份拆解都能当参考模板用。
1. 先弄懂：游戏行业BI工程师到底在干什么
1.1 和互联网BI的差异：从DAU到玩家生命周期
很多人对BI工程师的理解停留在“写SQL、出报表、做看板”，这个认知放在搜狐畅游这类游戏公司里，会显得过于单薄。游戏行业的BI工程师，本质上是业务的“数据军师”，你服务的对象是游戏策划、运营、发行甚至制作人，他们每天关心的不是泛泛的“用户活跃”，而是一个个具体的版本更新、活动投放、商业化调整带来的数据反馈。
传统互联网BI看的是漏斗、转化、留存，模型相对成熟，用户路径也相对线性。游戏行业完全不一样。一个玩家从注册到流失，中间会经历新手引导、关卡推进、社交关系建立、付费试探、版本厌倦等多个阶段，每个阶段的数据特征差异极大。比如一款卡牌游戏，新手期玩家流失可能是因为某一关难度曲线陡峭，中期玩家流失可能是因为内容消耗速度跟不上产出，后期玩家流失可能是因为社交系统缺乏深度绑定。同样是“留存下降”这个现象，背后原因可能是完全不同的系统问题，这需要BI工程师对游戏本身有足够的理解力。
搜狐畅游的笔试题之所以值得复盘，是因为它把这种行业特性渗透进了每一个问题。它不是问你“如何搭建数据仓库”，而是通过具体业务场景考察你有没有能力把数据问题翻译成业务语言。这套逻辑，放到今天的游戏行业依然适用。
1.2 从笔试题反推岗位能力模型
把2019年这套BI工程师笔试题放在一起看，可以清楚地反推出当时搜狐畅游对这个岗位的期待——或者说，任何一家成熟游戏公司对BI工程师的期待都差不多。
第一层是数据处理硬技能。SQL是绝对的基础，笔试中大概率会出现数据查询、聚合、多表关联、窗口函数等考点。这一层考察的是你有没有能力在数据仓库里高效、准确地获取数据，是BI工程师的看家本领。
第二层是数据逻辑和业务敏感性。给你一份玩家行为数据，让你分析某个版本更新对留存的影响，或者对比不同渠道的付费用户质量，这种题目考察的是你面对一堆数字时，能不能形成清晰的假设、设计合理的分析维度、找到真实的影响因素，而不是简单地堆砌图表。
第三层是沟通和结构化表达能力。笔试中的案例分析题，最终要落到“你能不能在有限篇幅里把自己得出的结论说清楚”这一步。一个分析做出来，要能同时让运营看得懂、让策划知道怎么改、让制作人看到影响面。书面表达能力，本质上是结构化思维的直观体现。
所以准备笔试不要只刷SQL题，那只是入场券。真正的分水岭，在于你对游戏业务的理解深度和把数据落回业务场景的能力。
2. 搜狐畅游2019校招笔试题完整复盘与题型拆解
2.1 核心题型一：SQL取数与数据查询
这一块是BI工程师笔试的基本盘，几乎必考。2019年的题目里有几道相当有代表性，可以拿来练手。
比如一道经典题：给定玩家充值流水表（order_id, user_id, pay_time, amount, product_id）和玩家基本信息表（user_id, register_time, channel），要求统计“2019年1月1日之后新注册的玩家中，在注册后7天内有充值行为的用户数和总充值金额”。这道题看似简单，实际考查了三个关键点：时间过滤条件的写法、日期差值的计算方式、去重逻辑。
我当时在草稿纸上先写第一版，然后会追问自己：如果一个玩家有多笔充值记录，会不会被重复统计？“7天内”这个口径，是注册时间到充值时间差小于等于7天，还是按自然周算？不同口径得出的结果可能差很多。这种对口径的理解，恰恰是SQL题拉开差距的地方。
再看一道进阶题：给定玩家每日登录表（log_date, user_id, login_time），要求输出截至2019年3月31日，各账号最近连续登录天数。这道题需要用到窗口函数，先对登录记录去重，再按用户分组按日期排序，用日期减去排序序号，连续登录的日子会落在同一个分组里，最后取每个用户分组内的次数。能熟练写出这道题，说明对窗口函数和分组逻辑真正理解了。
这类SQL题的答题技巧是：先写思路注释，再写具体代码，最后写一句对结果的口径说明。阅卷人一眼就能看出你是不是真的懂，还是在背模板。
2.2 核心题型二：数据分析与业务推断
有一道记忆深刻的题，大致是给出某游戏新版本更新前后两周的玩家数据，包括DAU、次日留存率、付费率、平均在线时长、关卡通过率，要求分析版本更新的影响并给出建议。
这道题没有标准答案，考察的就是分析框架。合理的分析路径是先看整体数据是否异常，再拆维度——是全体玩家受影响，还是特定等级段玩家受影响？是iOS端受影响还是安卓端受影响？是回流玩家受影响还是活跃老玩家受影响？把这些拆完，再看关卡通过率，如果某个关键关卡的通过率下降明显，而低等级玩家集中于该关卡，那问题很可能出在难度曲线或数值平衡上。
答题时必须体现“假设驱动”的意识。先列出一组候选假设（版本适配问题、数值调整不合理、新玩法引导不足、活动扰动等），然后逐一用数据去验证或排除，剩下的最可能的那个方向，再给出可以落地的后续验证动作。这种写法，会让阅卷人觉得你真的是在做分析而不是在答题。
2.3 核心题型三：运营活动效果评估与商业化分析
游戏行业BI工程师绕不开活动效果评估。笔试题里出现过一个关于“回馈活动”的分析，说的是某次付费活动后，整体收入出现了明显拉升，写邮件总结活动效果并给出后续建议。
这个问题的陷阱在于：收入上涨可能和活动无关，只是游戏内新版本上线带来的自然波动。一个合格的分析师至少要考虑三件事：活动前后自然增长基线是多少；参与活动的用户和不参与活动的用户付费差异是否显著；活动结束以后收入有没有回落，回落到什么水平——如果掉到比活动前还低的水平，说明活动透支了玩家付费意愿，那这个活动的长期价值要打一个大大的问号。
答题中可以引入一个转化指标：活动页面曝光到付费的转化率、活动道具在付费玩家中的渗透率、活动期间的DAU付费渗透率。这些指标能判断活动对存量用户还是增量用户更有效。笔试题不需要你搭出完整模型，但你要展现出这种考虑问题的颗粒度。
2.4 数据分析报告题：结构化表达能力的试金石
最后一类题是综合报告题，类似于“给一条业务线做一个数据分析报告”。2019年的题目里有这么一道：假如你是一名BI工程师，需要在周会上向制作人汇报游戏当前的数据表现，请列出报告框架。
这道题考察的是：你能不能站在汇报对象的视角组织优先级。制作人关心的不是细节，而是核心指标是否健康、有没有需要拍板的风险点、要不要及时调整资源。所以报告框架一般应该先给结论再看明细——先讲“这一周游戏数据整体表现正常/异常”，再讲“核心原因初步判断是什么”，之后才是分模块的数据拆解和后续行动计划。
换句话说，这道题表面在考“分析”，实际在考“汇报”。数据结论要有主次、有逻辑、有行动牵引，这些才是BI工程师能不能真正融入业务决策闭环的分水岭。
3. 逐步拆解：一套可复用的笔试答题框架
3.1 拿到题目，先不要急着动手
做题最快的路径不是先写代码，而是先在草稿纸上把几件事想清楚：这个问题的业务场景是什么、分析目的是什么、数据口径是什么、最终输出的颗粒度是什么。
比如SQL题里要算“次日留存”，你要先问：对哪一天新增的用户算次日留存？只算注册当天有登录行为的用户，还是注册后任意一天有登录的都算？一个用户当天注册又换绑设备登录两次怎么算？这些口径没有统一答案，但是如果你能在答题一开始就把选定的口径写出来，阅卷人会认为你有严谨的数据习惯。数据分析题也是一样，先写明你指定的分析周期、版本边界、比较基准，用一行字把这几个前提钉死在纸面上，后面分析才有根基。
3.2 数据预处理阶段：花式脏数据防御手册
笔试虽然不会塞给你一堆乱码数据，但稍微像样点的题都会埋一两个数据陷阱。最常见的是重复记录问题，比如玩家登录表里同一天登录多次，或玩家充值表里同一订单号出现两次。复习的时候最好把去重逻辑再缕一遍：是先给订单号去重，还是先按用户去重，还是用窗口函数row_number()生成序号后筛选序号=1再聚合，要写清楚。
第二个常见陷阱是时间字段格式不统一。有的表里时间字段是字符串，有的是时间戳，有的是日期。处理不到位，做日期差计算的时候轻则结果错误，重则直接报错。答题时如果能写明时间字段的清洗规则，比如统一用的“YYYY-MM-DD”格式，精确到天，会显得很稳妥。第三个陷阱是控制变量的拆分能力。很多题目给出的数据是聚合过的，但表面看不到多个维度的交叉效果。面对这类题，最终要能识别数据粒度、明确分组口径、明确哪个表做主表，这一个思考过程比代码本身的价值更大。
3.3 从指标到洞察：一次完整的数据分析解题示范
这里用一个贴近原题的例子来演示完整分析流程。假设一款游戏在春节期间做了“登录送好礼+双倍充值返利”双活动，作为BI工程师你要在一周后评估活动效果。数据表包含三张：玩家注册表、玩家每日登录表、玩家充值流水表。
第一个步骤，先把指标框架建立起来。不能只看“活动期间收入涨了30%”就下结论，至少要拆成：活跃指标用新增登录用户数、老用户回流登录数、人均登录天数；付费指标用付费用户数、ARPPU、付费率；转化指标用从登录到点击活动页的渗透率、从点击活动页到充值的转化率。
第二个步骤，拆分用户分层。把用户按生命周期阶段分成新用户、沉默回流用户、活跃老用户三类，分别看活动在每一层用户中的效果。不同分层用户的动机和行为差异巨大，混在一起看会掩盖结构性问题。
第三个步骤，做活动前后的对比分析。不能只和活动期间比，要和活动前一个周期、去年同期的无活动周期比，排除版本更新、节日自然流量等因素干扰。有了基线，才能判断活动带来的增量到底有多少。
第四个步骤，把结果落到行动建议上。如果发现活动对老用户效果明显但没能有效激活沉默用户，就要建议加强定向触达；如果新用户付费率低但登录频次高，就要考虑是不是活动钩子引导不到位。分析报告的价值在于让业务知道下一步该怎么调整，而不是列出一堆漂亮的图表就结束。
3.4 常见笔试题型模板：直接可用的分析套路
有一部分题型出现频率高，可以提前准备模板。比如留存分析类，先看大盘留存趋势，再做按渠道、按版本、按设备纬度的拆分，再结合登录频次、关卡通过、社交行为等中间指标定位异常环节，最后根据用户调研或埋点数据做归因。
再比如付费分析类，核心思路是从“谁在付、为什么付、怎么付更多”三个角度展开。用户画像维度要做付费用户与未付费用户的分群对比；动机分析维度要看付费用户集中购买的道具品类、购买的时机、首次付费体验；放大价值维度要看不同付费区间用户的回流率、流失率、游戏时长和社交行为，以判断哪些高价值用户值得重点运营。
渠道质量评估类题用“拉新数量+留存率+30日付费率”的组合来衡量渠道用户价值，没有唯一的单一指标，因为买量场景下不同的目标渠道优化方向不同。如果你能在笔试时写出“综合ROI评估矩阵”的概念，明显比单纯给一个渠道排名更有说服力。这些模板不是让你生搬硬套，但至少能帮你在紧张的笔试时间里快速组织出结构完整的答案。
4. 版本兼容与思维陷阱：答好游戏BI题的关键细节
4.1 游戏行业数据分析的5个典型思维陷阱
复盘这套笔试题时，可以提炼出几类游戏行业数据分析中常见的思维陷阱，做笔试时容易踩，实际工作中更容易踩。
第一类是把不同生命周期阶段的用户混在一张表里分析。一款刚上线三个月的游戏和一款上线三年的游戏，用户结构完全不同。如果把新用户和老用户混在一起看活跃率和付费率，数据会非常平滑，但什么也说明不了。遇到这种情况，习惯性按注册周期分群是最起码的动作。
第二类是忽视不同数值体系对绝对指标的影响。游戏版本更新调整了数值产出后，玩家金币持有量、关卡通过率、装备获取速度等绝对值变化，可能并不是玩家行为变了，而是数值设定变了。看数据前先确认版本迭代中数值是否调整过，这是游戏BI的基本素养。
第三类是只看结论不看置信度。样本量太小时，任何波动都可能只是随机噪声。比如某天某个渠道新增用户就100个人，次日留存从40%掉到25%，这个变化根本不足为信。分析时顺手算一下样本量级，再判断要不要分析，能避免大量无意义的工作。
第四类是忽略时间窗口的“口径陷阱”。同样是“首充”，有人定义成“注册后第一次充值”，有人定义成“任意时间点第一次充值”，两者计算出来的结果方向可能完全相反。写分析结论时把口径写清楚，既是对自己负责，也是对看报告的人负责。
第五类是因果归因过于简单。数据波动永远是多因素叠加的结果，一个版本更新可能同时包含新内容、数值修改、活动开启、服务器扩容等动作。硬要把结果归因于某一个动作，很容易误导决策。合理做法是把多个因素拆开做对比分析，尽量控制变量后再下结论。
4.2 表达上常见的丢分点
笔试答题的表达方式，会直接影响阅卷人对你专业度的判断。第一个丢分点是有分析但不给结论，或者结论放在最后一段藏得太深。分析和结论是一个闭环，结论必须清晰出现在答案的显眼位置，哪怕只是一个可以做的直接动作。
第二个丢分点是堆砌数字和指标，没有主次。指标多不等于分析深，核心指标就三五个，其他都是辅助。把核心指标放在分析框架里，把辅助指标放在支撑材料里，这个层次感要分明。
第三个丢分点是忽视了“下一步”价值。分析报告应该以行动性建议结尾，下一步是继续验证还是直接上策略，不能止步于对过去的解释。这正是笔试中“报告题”和“分析题”的区别，报告题里行动建议的权重更高。
4.3 笔试作答版的“避坑清单”
整理一份笔试现场可以直接对照的检查清单，这些细节积累起来，比多刷几道题更有价值：
- 字段名和表名是否符合题目给出的命名风格，不要自己另起一套；
- 时间过滤条件是否写成闭区间，排除边界问题；
- 去重逻辑是否覆盖所涉及的表，避免出现一人多次计数的风险；
- 数值单位是否统一，是“元”还是“万元”、是“人”还是“万人”；
- 留存计算的分母用的是新用户数还是活跃用户数，口径要明确；
- 分析结论是否对应数据证据，每一句判断都找得到数字支撑；
- 建议是否具体到可以执行，比如“优化某关卡难度”“对某渠道停止投放”。
5. 从笔试到面试：面试官追问的隐藏考察点
5.1 你只写SQL，还是懂数据仓库
笔试过了之后，面试官往往会围绕你的笔试答案追问。如果你是做SQL题出身，很可能被追问“你的数据是从哪一层取的？宽表还是明细表？如果数据量超过单机查询能力你怎么办？”。这个问题背后，面试官想确认你不仅能写SQL，还知道数据是怎么加工出来的，了解分层架构、ETL调度、任务依赖这些基础概念。
如果你在笔试里提到某个业务指标，大概率会被追问“这个指标在数据仓库里怎么落地？”你可以回答：在DWD层把打点日志清洗成结构化事件表，在DWS层按用户维度和日期维度汇总成宽表，在ADS层生成具体应用指标。能把这个链路讲清楚，会让面试官认为你的数据工程素养到位。
5.2 业务题从“做完”到“做对”
面试官还喜欢追问业务题的结果。你答完“留存下降了，原因是新用户难度曲线陡”，他可能立马问你：“那你怎么证明是难度曲线的问题，而不是渠道买量质量问题？”这就是在考归因的逻辑严密性。
比较好的应对方式是把验证思路讲成闭环：第一步看新用户等级分布，如果大量新用户集中在同一关，那指向关卡问题；第二步看渠道质量，对比不同渠道新用户同期留存，如果只有某一个渠道的留存骤降，难度曲线的假设就不成立；第三步直接拉出关卡通过率的时间序列，观察在版本更新当天的跳变，来判断是版本调整导致还是渠道波动导致。每一条都指向明确的数字验证路径，面试官会自然认为你是能独立扛分析项目的候选者。
5.3 考察你的学习能力和对游戏的理解
游戏公司面试官很喜欢问一个开放性问题：“你最近在玩什么游戏？如果让你分析这款游戏当前的运营数据，你会从哪里入手？”这个问题很吃平时的积累。如果你完全没玩过游戏，很容易说空话；如果你平时有意识地拆解过游戏的运营活动和数值体系，这个问题反而是展示自己的好机会。
我见过一个印象很深的回答，候选人说自己最近在玩一款二次元卡牌游戏，发现它最近新出的角色池子流水很高，他分析是因为这个角色的技能强度和PVP环境高度契合，同时选择了在老玩家活跃度最高节点上线。他把这个判断拆成几个验证指标：角色上线后玩家通关率变化、竞技场热门阵容切换比例、该卡池付费用户与新注册用户的比例。这就是把游戏理解变成分析思路的完整能力示范，面试官很难不被这种回答打动。
6. 给准备BI工程师校招的同学的实操建议
6.1 SQL功底怎么打：每天一小时，持续一个月
SQL是BI工程师的基本功，没有捷径，但有方法。一开始不用追求刷难题，先把基础语法弄扎实：select、where、group by、order by、join的各种类型、聚合函数。这个阶段的核心是“抠细节”，搞清楚left join和inner join的区别，搞清楚group by之后select里能放哪些字段，搞清楚where和having的过滤时机。
基础语法熟了之后，集中练窗口函数：row_number()、rank()、dense_rank()、lag()、lead()、sum() over(partition by)、first_value()。这些函数在游戏数据分析里出镜率极高，比如计算玩家连续登录天数、计算每个用户在某个时间点的累计付费金额、对比玩家上次登录时间和本次登录时间的间隔。熟练以后，至少能应付笔试中80%的取数场景。
用真题练手时要留意查询效率。虽然笔试数据量不大，但能写出用索引优势、减少不必要子查询的写法，会让阅卷人觉得你有真实数据处理的经验。练习平台用LeetCode、牛客网、HiveSQL在线练习都可以，关键是每天保持手感。
6.2 业务思维怎么培养：从拆解一款游戏开始
业务思维不是看几篇文章就能有的，最有效的方式是自己选一款热门的游戏，设定一个真实的业务问题，从问题出发往前倒推分析框架。比如你选一款MOBA游戏，任务就是“分析当前赛季的玩家流失原因”。你会自然拆出这些问题：流失玩家集中在什么段位？他们在流失前的对局胜率如何？流失前是否经历过连败？连败之前是否有英雄池受限的迹象？流失玩家近一周的日均在线时长如何变化？
再比如你选一款二次元放置类游戏，任务变成“评估上周新出的限定活动效果”。你需要拆解的有：活动参与率是多少、参与用户中大R中R小R各占多少、活动道具的消耗速度、活动结束后的7日留存、活动期间付费用户中首次付费的用户占比。这些问题拆解完，你自然就对游戏的数据分析有体感了。
做这件事的价值不只是为面试，更是建立一种“业务问题—指标定义—数据验证—行动建议”的思考习惯。这种习惯一旦形成，笔试的分析题对你就只是换了个皮。
6.3 答题顺序与时间分配策略
笔试时间有限，先做自己最有把握的题，把确定的分先拿到手。我一般建议先花3-5分钟通读全卷，按自己的掌握程度把题目分成三档：第一档是必胜题，比如基础SQL取数、明确的分析计算题，优先做；第二档是有思路但需要时间组织的题，比如业务分析题；第三档是完全没把握的题，放到最后，用结构性思考多写几句话也比空着强。
单道题的时间也要控制。SQL题如果超过15分钟没思路，先放一放，说明可能卡在某个关键语法上，回头再看往往会有新发现。业务分析题一般控制在20-25分钟，留几分钟把结论写清楚。报告题虽然分值高，但也别超过40分钟，用框架化的方式先搭出主要内容，每个模块写清楚小标题和关键结论，不必面面俱到。
写第一遍的时候不要求完美，尤其是分析题的逻辑链条，先写主干再补细节。笔试更重要的是让阅卷人看到你的思维路径是否清晰、专业基础是否扎实，语句足够通顺、逻辑主线成立比华丽的炫技更重要。
6.4 复盘比刷题更重要
每做完一套题，都要认真复盘：哪道题卡了多久，卡在哪个环节，是SQL语法不熟还是业务框架不清晰，下次怎么避免。建议准备一个错题本，记录每道题的分析模板、关键指标定义、常用SQL函数写法和当时遗漏的思考维度。
复盘的时候特别要注意“对的题”也要复盘。比如一道SQL题你写对了，但如果你的代码逻辑只能在这个特定数据集上跑通，换一个真实业务场景可能就出问题。试着想一想，如果把题目里的时间范围改大、数据量增加一个量级，你的查询性能会怎样？把对题也按错的逻辑再推演一遍，才是真正的能力提升。
最后说一点心得。游戏行业的BI工程师，说到底是一种复合型角色——你既要能在数据仓库里游刃有余地取数，也要能理解策划案背后的设计目的，还要会向制作人讲清楚“到底发生了什么、为什么、怎么办”。笔试只是第一道门槛，它筛选的不是背题最熟的人，而是数据思维最完整的人。希望这篇复盘能帮你少走一些弯路，在笔试里把真实的自己呈现出来。多看几套真题，多拆解几款游戏，数据这条路，踏实走，总会到的。
