2023年秋招投英雄游戏数据分析岗收到笔试邀请的那一刻我其实是有点意外的。说实话游戏行业的数据分析岗一向热门每年简历堆成山能进笔试已经算过了第一关。但紧接着就是紧张——笔试怎么考、考什么、难度多大网上能搜到的“数据分析面经”大多是互联网大厂的专门针对游戏公司的少之又少。我花了几天时间翻遍了能找到的英雄游戏笔试信息又结合自己之前积累的SQL、Python和业务分析底子硬着头皮上了考场线上笔试。整场考下来我的感受是题型不算偏但考察面很宽既考工具熟练度也考业务思维还掺杂了不少统计学基本功。这篇文章就完整复盘一下我的备考过程、题型拆解、答题思路和踩过的坑给接下来要投游戏公司数据分析岗的朋友做个参考。不论你是刚准备转行数据分析的新手还是已经刷过不少“数据分析面试题”的求职者这篇内容都能帮你快速定位游戏行业的数据分析笔试到底在筛什么样的人以及怎么在有限时间内把分数拿稳。1. 笔试前的准备先搞清英雄游戏和这个岗位要什么1.1 为什么游戏公司数据分析笔试越来越“重”游戏行业跟传统互联网有个明显区别——业务链路长、数据口径复杂。从用户下载游戏、注册账号、创建角色、完成新手引导到后续的日常任务、副本挑战、社交互动、充值消费每一步都在产生数据。再加上游戏版本更新频繁运营活动一场接一场数据分析师要面对的问题往往不是“缺数据”而是“数据太多怎么从中找到关键信号”。这就决定了游戏公司的数据分析岗位笔试不会只考“你会不会写SQL”这种单一维度。笔试题目通常会被设计成“你能不能从数据里发现问题、定位原因、给出方案”的综合考察。2023年英雄游戏的笔试明显也是这个思路——对比我同学投的电商、金融类岗位游戏公司的题更强调对用户行为和业务指标的理解而不是单纯的算法推导。1.2 英雄游戏秋招笔试的投递背景与岗位画像投递之前我先做了点功课。英雄游戏Hero Games在行业内属于研发发行一体的游戏公司旗下产品线涉及射击、动作、二次元等多个品类也有海外发行业务。这类公司对数据分析师的要求通常不是“只做报表”而是希望候选人能贴近业务——你要理解游戏里的核心玩法、经济系统、付费设计才能解释数据波动背后是游戏机制问题还是活动设计问题又或者是渠道投放问题。基于这个判断我给自己圈定了三个复习重点SQL必考而且是重头戏。留存、付费、漏斗、窗口函数几乎场场出现写不熟练基本告别笔试。Python主要考pandas的数据处理能力和简单的统计分析能力。重点不是要你写多复杂的算法而是能不能高效地完成数据清洗、分组聚合、检验对比。业务分析思维重点准备游戏行业常用的分析框架比如用户生命周期分析、付费转化漏斗、A/B测试设计思路。我还在网上搜了不少“数据分析笔试”和“数据分析案例”发现大多数游戏公司的题目风格都有共同点不考偏题怪题但会在业务场景里埋坑。英雄游戏的笔试也不例外。2. 题型总览线上笔试到底考了哪些板块整个笔试是线上完成考试平台会限制切屏次数进入页面后计时开始。我所在的批次整体时间是90分钟题量偏大需要严格控制节奏。大题题型大致可分为三块客观题选择题、编程题SQL/Python二选一或分设题目、业务分析主观题。2.1 客观题行测逻辑与统计基础客观题大概占了三分之一的分值形式类似行测但又不完全一样。除了常见的逻辑推理、图形推理还掺了不少统计学的基础选择题比如置信区间宽度的影响因素、p值的含义、正态分布特征、抽样方法选择等。这类题对统计学扎实的人来说是送分题但如果基础不牢很容易在几个容易混淆的概念上翻车。我记得有一道题是问“在样本量不变的情况下置信水平从95%提高到99%置信区间会怎么变化”。答案是区间变宽因为更高的置信水平需要更大的临界值。但选项中还混了一个“需要更大样本”的干扰项很多人一看到“99%”就觉得要加样本量实际上题目已经限定了“样本量不变”就要回到公式本身来判断。2.2 主观编程题SQL与Python双通道编程题有明确的分类选择——SQL题和Python题。我当时选择的是SQL为主、Python为辅因为游戏行业的数据分析日常工作中SQL是绕不开的核心工具而且笔试SQL题一般有明确的“标准答案”方向更容易得分。SQL题考得非常务实给一张用户登录日志表计算不同时间维度下的留存率给一张支付流水表算出每位玩家的首充金额和累计充值金额用窗口函数取每款游戏活跃时长的Top10用户等。这些题目我在平时练习中基本都遇到过类似版本重点就是看临场思路是否清晰、SQL语法是否熟练。Python题则是以pandas为主给一份CSV格式的游戏用户数据要求做分类汇总、缺失值处理、渠道对比甚至有一段AB测试的结果需要你用Python完成显著性检验。题目本身不要求你写出完整的项目代码但考察点很细比如分组后怎么对多列做不同的聚合计算、日期字符串怎么转换成datetime类型、布尔索引怎么写才不会报错等。2.3 业务案例题游戏场景下的分析题业务题是拉开差距的关键。这类题通常没有唯一正确答案重点看你的分析思路是否完整。英雄游戏这次考的业务题大致是“某款游戏的次日留存率在近一周内出现明显下降作为数据分析师你会如何排查原因”这道题属于典型的“指标异动排查”型问题在数据分析面试题里高频出现。回答得好不好关键在于有没有系统性的排查框架——是要先确认数据口径还是直接开始猜原因是先看整体还是先拆维度我当时按照“数据校验—维度拆解—原因假设—验证方案—结论与建议”的逻辑线来组织答案同时又结合了游戏行业的特点比如提到版本更新、渠道投放变化、竞品上线时间、大R用户流失等因素这些行业细节能明显提升答案的差异化。3. 核心考点逐题解析我认为最关键的8类题笔试之后我专门复盘了一遍所有考点最终整理出8类我认为出现频率最高、也最值得深入准备的题型。如果你也在准备游戏公司数据分析岗每类都值得单独练一练。3.1 SQL窗口函数与留存率计算SQL窗口函数是游戏数据分析岗位的“必考题”。它的应用场景非常广找每个用户的首次登录时间、计算每个用户的历史累计充值、对用户按活跃天数排序后分组等。以留存率统计为例经典的需求是已知一张用户登录日志表user_login字段user_id、login_date计算2023年8月1日新增用户在8月2日、8月3日的留存率。我的标准写法是这样-- 先找到每个用户的首日登录日期视为新增日期 with first_login as ( select user_id, min(login_date) as first_date from user_login group by user_id ) -- 再与全量登录数据关联计算每天登录是否属于“次日/三日留存” select f.first_date, count(distinct f.user_id) as new_users, count(distinct case when u.login_date date_add(f.first_date, 1) then f.user_id end) as retained_day1, count(distinct case when u.login_date date_add(f.first_date, 2) then f.user_id end) as retained_day3 from first_login f left join user_login u on f.user_id u.user_id group by f.first_date order by f.first_date这里有几个关键点值得展开。第一with first_login as (...)这种CTE写法在笔试中很讨喜因为它结构清晰、容易排查问题。很多新人喜欢直接套子查询但如果嵌套层级太深自己都容易绕晕更别说阅卷人看你的答案了。第二留存计算的核心是要先建立“新增用户基准表”再做关联。如果你不先取每个用户的首日登录日期直接用login_date分组算出来的根本就不是留存而是“每日活跃用户中次日仍在活跃的人数”那定义就全错了。第三distinct一定要加。一个用户在同一天可能登录多次不判重的话留存率会被重复计算。笔试中这种细节最容易丢分虽然SQL能跑通但结果不符合业务定义。3.2 Python pandas分组聚合与数据清洗Python题通常会提供一份数据文件比如用户基本信息表让你做一系列操作。常见考点包括缺失值处理、数据类型转换、分组聚合、交叉表、关联合并等。举个例子题目给出用户付费数据pay_data字段user_id、pay_date、amount、channel要你统计每个渠道的付费总金额、付费人数及人均付费金额。用pandas实现大概是import pandas as pd df pd.read_csv(pay_data.csv) df[pay_date] pd.to_datetime(df[pay_date]) result df.groupby(channel).agg( total_amount(amount, sum), pay_users(user_id, nunique), avg_amount(amount, mean), ).reset_index() print(result)这段代码看起来简单但笔试现场还是有不少人翻车。最容易错的是nunique和count之间的区别——统计付费人数时要用nunique因为普通count会把同一个用户的多次付费重复计算。还有一点df[pay_date] pd.to_datetime(df[pay_date])这行很容易漏掉一旦日期是字符串格式后面按月份、按周做时间维度分析时会报出一堆莫名其妙的错。我的经验是Python题不要追求“用最骚的写法”而是用最稳妥、最容易解释的写法。比如groupby().agg()这种链式写法比一行代码写超长表达式要安全得多。写完后再加一句注释说明每列的含义既方便自己检查也让阅卷人看到你的思路。3.3 AB测试结果如何用统计知识判断显著性AB测试在游戏公司非常常见——新版本技能数值改不改、活动奖励怎么发、投放素材用哪套基本都要跑实验。所以笔试里出现AB测试相关的统计题并不意外。常见的出题方式是给两组数据对照组和实验组的转化率比如付费率以及各自的样本量让你判断实验组的提升是否显著。这时候至少需要掌握两个层面的知识假设检验基本流程原假设H0和备择假设H1怎么设、显著性水平通常取多少0.05、p值怎么算、怎么下结论。两比例z检验的实现手工计算或者用Python的statsmodels库快速完成。我当时在笔试中用了statsmodels的proportions_ztest来计算大概是这样from statsmodels.stats.proportion import proportions_ztest # control: 2000个用户, 300人付费; test: 2100个用户, 380人付费 count [300, 380] nobs [2000, 2100] z_stat, p_value proportions_ztest(count, nobs) print(fz统计量为: {z_stat:.4f}) print(fp值为: {p_value:.4f}) alpha 0.05 if p_value alpha: print(拒绝原假设实验组和对照组存在显著差异) else: print(不能拒绝原假设差异不显著)但这里有一个关键得分点不能只写p值小于0.05就完事。阅卷老师更希望看到你补充“效果量”的判断——即使差异具有统计学显著性也要看差异在实际业务中是否真实有用。比如实验组付费率比对照组高了0.1个百分点虽然样本量大到足以让p值显著但对游戏收入的影响可能微乎其微还需要结合成本评估是否值得全量上线。3.4 业务案例题指标异动排查的完整框架前面提到的“次日留存率下降”就是这类题的典型代表。做这题时我采用“假设驱动维度拆解”法。我的答题逻辑是这样的先确认数据是否准确查看埋点是否正常、口径是否有变化、是否出现部分平台或渠道的数据缺失。整体趋势与异常点确认下降是从哪一天开始的是突然下跌还是持续下滑跌幅大概多少维度拆解按渠道安卓/iOS、广告渠道/自然量、按用户类型新用户/老用户、按版本、按地区等维度拆分找出是哪个子群体把整体指标拉低了。原因假设基于维度拆解结果提出可能原因。比如iOS端正常但安卓端暴跌那可能是某渠道买量质量变差如果是新用户体验变差可能是新手引导环节出现问题或版本热更引入bug。验证方案针对假设设计验证方式比如追踪同一批新用户的后续留存曲线、检查版本分布或者拉取Crash日志看崩溃率是否上升。输出建议根据结论给出运营或研发侧的建议比如回滚版本、调整投放策略、修改新手任务难度等。这个框架不只是笔试能用实际工作中做指标异动排查也几乎每次都用得上。准备数据分析面试时这类题目一定要多练几个案例做到拿到题目就能条件反射式地搭建出分析框架。3.5 游戏指标体系从活跃到变现怎么串起来游戏数据分析笔试里还有一个常被忽视的模块业务指标选择题。它可能不会单独作为一道大题出现但在客观题和案例题的背景信息里会频繁出现DAU、WAU、MAU、留存率、付费率、ARPU、ARPPU、LTV等概念。你要是不清楚这些指标的定义和用途读题阶段可能就卡住了。几个核心指标的理解我建议务必到位DAU/WAU/MAU日活跃/周活跃/月活跃用户数反映用户规模。MAU与DAU的比值可以粗略反映用户粘性。留存率新增用户在N天后仍然活跃的比例。次日留存、7日留存、30日留存各有侧重。付费率付费用户占活跃用户的比例。通常用日付费率、月付费率来观察商业化健康度。ARPU每活跃用户平均收入等于总收入除以活跃用户数。ARPPU每付费用户平均收入等于总收入除以付费用户数。ARPPU和付费率往往是跷跷板要结合着看。LTV用户生命周期价值通常用来评估获客成本和投放ROI。LTV大于CPI每安装成本时买量模型才能跑通。我当时笔试中遇到一道题大意是“某游戏月付费率上升但月ARPPU下降总收入没有明显变化可能是什么原因”。实际上这背后就是付费用户基数扩大但新增付费用户的付费能力偏弱导致平均付费额被拉低需要结合用户结构和付费转化漏斗进一步分析。这类题没有标准答案但如果你对指标之间的联动关系理解到位答起来就能有理有据。3.6 Excel数据透视表与业务分析结合虽然笔试用Excel实操的可能性不大但我还是把Excel数据分析的基本功过了一遍尤其是数据透视表、VLOOKUP、SUMIFS这类高频函数。因为在未来的面试中面试官可能会问“如果业务方临时要一份数据你怎么快速响应”虽然SQL是核心武器但Excel常常是快速产出报表的第一工具。我在准备时专门练了把一份10000行左右的用户明细表做成按渠道、按日期的交叉汇总表。熟练掌握数据透视表后这类操作可以在两分钟内完成。而且Excel的图表可视化能力也不差做一些快速探索性分析时比先写SQL再导入Python要轻快得多。3.7 数据可视化图表选择比画图更重要英雄游戏的笔试没有要求提交可视化图表但在业务题答题过程中可以用文字说明“我会上线一个折线图观察趋势变化、用堆叠柱状图拆维度、用散点图看付费与活跃的关系”。这会让阅卷人觉得你是有数据可视化sense的而不是只会跑数。我自己在准备时复习了常见的图表使用场景趋势分析用折线图适合看次日留存率按日的变化曲线结构分析用堆叠柱状图或饼图比如付费金额在不同品类的占比相关性分析用散点图比如在线时长与付费金额的关系分布分析用直方图或箱线图比如观察付费金额的分布是否偏态。3.8 数据分析思维从“跑数工具人”到“解决问题的人”最后这类型不太像是“题”但它贯穿所有题目。很多人在准备笔试时把大量时间花在刷SQL语法和Python函数上却忽略了分析思维的训练。但英雄游戏的笔试给我的感觉是它更想招“能理解游戏业务的数据分析师”而不是“只会执行指令的跑数机器”。拿业务案例题来说同样一个留存率下降的问题有人只能想到“看看是不是数据延迟、是不是报表bug”有人却能结合版本上线时间线、渠道买量节奏、竞品动作、游戏内活动日历给出多维度的排查方向。这两者的差距不在于工具熟练度而在于有没有形成“数据分析思维”。我建议准备笔试时每周花一到两天专门看“数据分析案例”和“数据分析面经”不要只看答案要拆解题主的分析过程——他是怎么从模糊的问题出发一步步定义指标、拆解维度、验证假设的。看得多了你再遇到陌生题目就不会慌。4. 时间分配与做题顺序真实考场复盘在线笔试的时间压力真的不小90分钟要完成几十道客观题外加至少4道大题。我当时差点在客观题上翻车——前10道逻辑推理题有点卡壳浪费了8分钟导致后面编程题时间被压缩。这里详细复盘一下我的时间分配供大家参考。4.1 我的时间分配明细部分建议时间实际用时策略客观题逻辑统计25分钟30分钟每道题控制在1分钟以内超过先标记跳过SQL编程题20分钟18分钟先写大体框架再补细节Python题15分钟12分钟优先用pandas完成不纠结一行流写法业务案例题20分钟22分钟按框架分点写满给出可见的行动建议检查与补充10分钟8分钟检查SQL字段名、补全业务题的细节解释总体来看我的客观题确实超时了导致检查时间偏紧。如果重来一次我会在客观题上死守25分钟的底线——一道题超过90秒没思路就直接随便选一个等做完大题有剩余时间再回头思考。4.2 最容易踩的坑这次笔试我踩过或见过的坑集中在下面几个方面。客观题死磕有些逻辑推理题是真的难短时间内根本推不出来。死磕一题会让后面的时间全面崩盘。SQL没有先理清逻辑就开写一开始我直接写关联条件写到一半发现分组维度少了只能全部删掉重来。这样既浪费时间又容易把代码改乱。正确做法是先在纸上或者心里理清思路先建新用户表、再关联、再聚合。Python题忽略了字段类型读入数据后没有第一时间检查dtypes结果日期列是object类型做排序时完全乱掉白白浪费了5分钟排查。业务题写太短很多人只写“需要排查版本更新和渠道变化”一句话就没了。其实业务题不需要多高级的结论但要展现完整的分析链条。宁可多写几步也别让阅卷人觉得你没思路。4.3 答题技巧与“偷分”方法在不确定答案的题上也有几个实用的“偷分”策略。客观题用排除法先排除明显不靠谱的选项正确率能提高不少。SQL题即使运行结果不对也要把整体思路写出来。通常阅卷是看步骤分的部分正确的逻辑也能拿分。业务题一定要分点作答把每条推测独立成段条理比文采重要。Python题在代码块边上用注释标注“此处计算每日活跃用户”“此处进行分组聚合”即使函数用错阅卷老师也能看懂你的意图酌情给分。5. 笔试后的复盘如何把笔试变成面试素材笔试交卷不等于结束。很多人考完就把题目忘了其实这是最浪费的——笔试中的题目往往就是面试官在面试中追问的起点。5.1 复盘方法论把错题变成自己的知识体系我习惯把所有笔试题目按“SQL/统计/业务”三类归档每类题目整理出一个标准答案模板。比如SQL题我会把留存计算、漏斗计算、窗口函数排名这几类整理成一份“可直接复用”的脚本统计题我会把z检验、t检验、卡方检验的适用场景和代码写法单独写在一个文档里业务题则把所有分析框架整理成“指标异动排查”“AB测试设计”“用户分层与精细化运营”三大模板。这样做的好处是在面试前集中复习时不需要重新翻遍所有资料只需要看自己整理出来的模板和错题集。效率会高很多。5.2 从笔试到面试的衔接准备英雄游戏的面试环节一般会结合笔试内容做追问。比如笔试里考了留存计算面试官很可能让你现场再写一遍并追问“如果留存数据口径发生变化怎么办”“如果某渠道次日留存率明显低于其他渠道你会怎么进一步分析”。这时候笔试准备过程中的积累就派上用场了。我在笔试后还专门准备了一个“游戏数据分析项目”的素材库把之前做过的小项目——比如分析某款游戏用户付费行为的case——反复打磨成可以口述的版本。这样无论面试官问SQL、问业务理解还是问项目经验我都能快速调动素材不至于现场卡壳。另外建议准备数据分析岗的同学不管投的是游戏公司还是其他行业都要把“商业数据分析”和“金融风控数据分析”这类不同行业的题都看一遍。不同行业的数据分析面试题风格差异其实挺大游戏行业看重用户行为与留存电商行业看重转化和复购金融风控侧重违约预测与特征工程。多跨领域看题你的分析思路会更开阔。5.3 保持题感笔试后一周内的复习节奏笔试结束后一周通常是面试邀请集中发放的时间这个阶段不要完全放松建议保持每天的“刷题手感”每天练1~2道SQL题、1道Python数据处理题再读1篇数据分析案例保持对业务场景的敏感度。我当时保持的节奏是上午做一道SQL题控制在30分钟内下午看一个业务分析案例并练习搭建分析框架晚上把当天错题或者有趣的思路记到知识库里。这样一周下来不仅巩固了笔试中暴露的问题还对后续的面试保持了持续的信心。最后分享一个笔试送分技巧说一个很少人注意但非常实用的技巧线上笔试的输入框通常不支持代码高亮所以代码的缩进和对齐完全靠手动。在写SQL和Python时尽量不要用tab键缩进改用四个空格并且每一行尽量短一点避免因为编辑器宽度问题导致代码被换行、看着很乱。阅卷人每天要批改很多份卷子一份格式整齐、有注释、有条理的回答天然会比乱糟糟的代码更有好感。我个人在实际操作中体会最深的一句话是数据分析岗笔试本质上是一场信息战。你在考前对“题型、考点、出题偏好”掌握得越充分考试中就越能从容。英雄游戏2023年秋招数据分析岗的笔试已经过去一段时间了但它带给我的经验——把工具练到条件反射、把业务框架内化成思维习惯——在后来的实习和正式工作中也一直受用。希望这篇复盘能给你提供一些查漏补缺的方向祝准备秋招的你顺利拿下心仪offer。 英雄游戏数据分析岗秋招笔试复盘：SQL、留存率与业务思维全解析
2023年秋招投英雄游戏数据分析岗收到笔试邀请的那一刻我其实是有点意外的。说实话游戏行业的数据分析岗一向热门每年简历堆成山能进笔试已经算过了第一关。但紧接着就是紧张——笔试怎么考、考什么、难度多大网上能搜到的“数据分析面经”大多是互联网大厂的专门针对游戏公司的少之又少。我花了几天时间翻遍了能找到的英雄游戏笔试信息又结合自己之前积累的SQL、Python和业务分析底子硬着头皮上了考场线上笔试。整场考下来我的感受是题型不算偏但考察面很宽既考工具熟练度也考业务思维还掺杂了不少统计学基本功。这篇文章就完整复盘一下我的备考过程、题型拆解、答题思路和踩过的坑给接下来要投游戏公司数据分析岗的朋友做个参考。不论你是刚准备转行数据分析的新手还是已经刷过不少“数据分析面试题”的求职者这篇内容都能帮你快速定位游戏行业的数据分析笔试到底在筛什么样的人以及怎么在有限时间内把分数拿稳。1. 笔试前的准备先搞清英雄游戏和这个岗位要什么1.1 为什么游戏公司数据分析笔试越来越“重”游戏行业跟传统互联网有个明显区别——业务链路长、数据口径复杂。从用户下载游戏、注册账号、创建角色、完成新手引导到后续的日常任务、副本挑战、社交互动、充值消费每一步都在产生数据。再加上游戏版本更新频繁运营活动一场接一场数据分析师要面对的问题往往不是“缺数据”而是“数据太多怎么从中找到关键信号”。这就决定了游戏公司的数据分析岗位笔试不会只考“你会不会写SQL”这种单一维度。笔试题目通常会被设计成“你能不能从数据里发现问题、定位原因、给出方案”的综合考察。2023年英雄游戏的笔试明显也是这个思路——对比我同学投的电商、金融类岗位游戏公司的题更强调对用户行为和业务指标的理解而不是单纯的算法推导。1.2 英雄游戏秋招笔试的投递背景与岗位画像投递之前我先做了点功课。英雄游戏Hero Games在行业内属于研发发行一体的游戏公司旗下产品线涉及射击、动作、二次元等多个品类也有海外发行业务。这类公司对数据分析师的要求通常不是“只做报表”而是希望候选人能贴近业务——你要理解游戏里的核心玩法、经济系统、付费设计才能解释数据波动背后是游戏机制问题还是活动设计问题又或者是渠道投放问题。基于这个判断我给自己圈定了三个复习重点SQL必考而且是重头戏。留存、付费、漏斗、窗口函数几乎场场出现写不熟练基本告别笔试。Python主要考pandas的数据处理能力和简单的统计分析能力。重点不是要你写多复杂的算法而是能不能高效地完成数据清洗、分组聚合、检验对比。业务分析思维重点准备游戏行业常用的分析框架比如用户生命周期分析、付费转化漏斗、A/B测试设计思路。我还在网上搜了不少“数据分析笔试”和“数据分析案例”发现大多数游戏公司的题目风格都有共同点不考偏题怪题但会在业务场景里埋坑。英雄游戏的笔试也不例外。2. 题型总览线上笔试到底考了哪些板块整个笔试是线上完成考试平台会限制切屏次数进入页面后计时开始。我所在的批次整体时间是90分钟题量偏大需要严格控制节奏。大题题型大致可分为三块客观题选择题、编程题SQL/Python二选一或分设题目、业务分析主观题。2.1 客观题行测逻辑与统计基础客观题大概占了三分之一的分值形式类似行测但又不完全一样。除了常见的逻辑推理、图形推理还掺了不少统计学的基础选择题比如置信区间宽度的影响因素、p值的含义、正态分布特征、抽样方法选择等。这类题对统计学扎实的人来说是送分题但如果基础不牢很容易在几个容易混淆的概念上翻车。我记得有一道题是问“在样本量不变的情况下置信水平从95%提高到99%置信区间会怎么变化”。答案是区间变宽因为更高的置信水平需要更大的临界值。但选项中还混了一个“需要更大样本”的干扰项很多人一看到“99%”就觉得要加样本量实际上题目已经限定了“样本量不变”就要回到公式本身来判断。2.2 主观编程题SQL与Python双通道编程题有明确的分类选择——SQL题和Python题。我当时选择的是SQL为主、Python为辅因为游戏行业的数据分析日常工作中SQL是绕不开的核心工具而且笔试SQL题一般有明确的“标准答案”方向更容易得分。SQL题考得非常务实给一张用户登录日志表计算不同时间维度下的留存率给一张支付流水表算出每位玩家的首充金额和累计充值金额用窗口函数取每款游戏活跃时长的Top10用户等。这些题目我在平时练习中基本都遇到过类似版本重点就是看临场思路是否清晰、SQL语法是否熟练。Python题则是以pandas为主给一份CSV格式的游戏用户数据要求做分类汇总、缺失值处理、渠道对比甚至有一段AB测试的结果需要你用Python完成显著性检验。题目本身不要求你写出完整的项目代码但考察点很细比如分组后怎么对多列做不同的聚合计算、日期字符串怎么转换成datetime类型、布尔索引怎么写才不会报错等。2.3 业务案例题游戏场景下的分析题业务题是拉开差距的关键。这类题通常没有唯一正确答案重点看你的分析思路是否完整。英雄游戏这次考的业务题大致是“某款游戏的次日留存率在近一周内出现明显下降作为数据分析师你会如何排查原因”这道题属于典型的“指标异动排查”型问题在数据分析面试题里高频出现。回答得好不好关键在于有没有系统性的排查框架——是要先确认数据口径还是直接开始猜原因是先看整体还是先拆维度我当时按照“数据校验—维度拆解—原因假设—验证方案—结论与建议”的逻辑线来组织答案同时又结合了游戏行业的特点比如提到版本更新、渠道投放变化、竞品上线时间、大R用户流失等因素这些行业细节能明显提升答案的差异化。3. 核心考点逐题解析我认为最关键的8类题笔试之后我专门复盘了一遍所有考点最终整理出8类我认为出现频率最高、也最值得深入准备的题型。如果你也在准备游戏公司数据分析岗每类都值得单独练一练。3.1 SQL窗口函数与留存率计算SQL窗口函数是游戏数据分析岗位的“必考题”。它的应用场景非常广找每个用户的首次登录时间、计算每个用户的历史累计充值、对用户按活跃天数排序后分组等。以留存率统计为例经典的需求是已知一张用户登录日志表user_login字段user_id、login_date计算2023年8月1日新增用户在8月2日、8月3日的留存率。我的标准写法是这样-- 先找到每个用户的首日登录日期视为新增日期 with first_login as ( select user_id, min(login_date) as first_date from user_login group by user_id ) -- 再与全量登录数据关联计算每天登录是否属于“次日/三日留存” select f.first_date, count(distinct f.user_id) as new_users, count(distinct case when u.login_date date_add(f.first_date, 1) then f.user_id end) as retained_day1, count(distinct case when u.login_date date_add(f.first_date, 2) then f.user_id end) as retained_day3 from first_login f left join user_login u on f.user_id u.user_id group by f.first_date order by f.first_date这里有几个关键点值得展开。第一with first_login as (...)这种CTE写法在笔试中很讨喜因为它结构清晰、容易排查问题。很多新人喜欢直接套子查询但如果嵌套层级太深自己都容易绕晕更别说阅卷人看你的答案了。第二留存计算的核心是要先建立“新增用户基准表”再做关联。如果你不先取每个用户的首日登录日期直接用login_date分组算出来的根本就不是留存而是“每日活跃用户中次日仍在活跃的人数”那定义就全错了。第三distinct一定要加。一个用户在同一天可能登录多次不判重的话留存率会被重复计算。笔试中这种细节最容易丢分虽然SQL能跑通但结果不符合业务定义。3.2 Python pandas分组聚合与数据清洗Python题通常会提供一份数据文件比如用户基本信息表让你做一系列操作。常见考点包括缺失值处理、数据类型转换、分组聚合、交叉表、关联合并等。举个例子题目给出用户付费数据pay_data字段user_id、pay_date、amount、channel要你统计每个渠道的付费总金额、付费人数及人均付费金额。用pandas实现大概是import pandas as pd df pd.read_csv(pay_data.csv) df[pay_date] pd.to_datetime(df[pay_date]) result df.groupby(channel).agg( total_amount(amount, sum), pay_users(user_id, nunique), avg_amount(amount, mean), ).reset_index() print(result)这段代码看起来简单但笔试现场还是有不少人翻车。最容易错的是nunique和count之间的区别——统计付费人数时要用nunique因为普通count会把同一个用户的多次付费重复计算。还有一点df[pay_date] pd.to_datetime(df[pay_date])这行很容易漏掉一旦日期是字符串格式后面按月份、按周做时间维度分析时会报出一堆莫名其妙的错。我的经验是Python题不要追求“用最骚的写法”而是用最稳妥、最容易解释的写法。比如groupby().agg()这种链式写法比一行代码写超长表达式要安全得多。写完后再加一句注释说明每列的含义既方便自己检查也让阅卷人看到你的思路。3.3 AB测试结果如何用统计知识判断显著性AB测试在游戏公司非常常见——新版本技能数值改不改、活动奖励怎么发、投放素材用哪套基本都要跑实验。所以笔试里出现AB测试相关的统计题并不意外。常见的出题方式是给两组数据对照组和实验组的转化率比如付费率以及各自的样本量让你判断实验组的提升是否显著。这时候至少需要掌握两个层面的知识假设检验基本流程原假设H0和备择假设H1怎么设、显著性水平通常取多少0.05、p值怎么算、怎么下结论。两比例z检验的实现手工计算或者用Python的statsmodels库快速完成。我当时在笔试中用了statsmodels的proportions_ztest来计算大概是这样from statsmodels.stats.proportion import proportions_ztest # control: 2000个用户, 300人付费; test: 2100个用户, 380人付费 count [300, 380] nobs [2000, 2100] z_stat, p_value proportions_ztest(count, nobs) print(fz统计量为: {z_stat:.4f}) print(fp值为: {p_value:.4f}) alpha 0.05 if p_value alpha: print(拒绝原假设实验组和对照组存在显著差异) else: print(不能拒绝原假设差异不显著)但这里有一个关键得分点不能只写p值小于0.05就完事。阅卷老师更希望看到你补充“效果量”的判断——即使差异具有统计学显著性也要看差异在实际业务中是否真实有用。比如实验组付费率比对照组高了0.1个百分点虽然样本量大到足以让p值显著但对游戏收入的影响可能微乎其微还需要结合成本评估是否值得全量上线。3.4 业务案例题指标异动排查的完整框架前面提到的“次日留存率下降”就是这类题的典型代表。做这题时我采用“假设驱动维度拆解”法。我的答题逻辑是这样的先确认数据是否准确查看埋点是否正常、口径是否有变化、是否出现部分平台或渠道的数据缺失。整体趋势与异常点确认下降是从哪一天开始的是突然下跌还是持续下滑跌幅大概多少维度拆解按渠道安卓/iOS、广告渠道/自然量、按用户类型新用户/老用户、按版本、按地区等维度拆分找出是哪个子群体把整体指标拉低了。原因假设基于维度拆解结果提出可能原因。比如iOS端正常但安卓端暴跌那可能是某渠道买量质量变差如果是新用户体验变差可能是新手引导环节出现问题或版本热更引入bug。验证方案针对假设设计验证方式比如追踪同一批新用户的后续留存曲线、检查版本分布或者拉取Crash日志看崩溃率是否上升。输出建议根据结论给出运营或研发侧的建议比如回滚版本、调整投放策略、修改新手任务难度等。这个框架不只是笔试能用实际工作中做指标异动排查也几乎每次都用得上。准备数据分析面试时这类题目一定要多练几个案例做到拿到题目就能条件反射式地搭建出分析框架。3.5 游戏指标体系从活跃到变现怎么串起来游戏数据分析笔试里还有一个常被忽视的模块业务指标选择题。它可能不会单独作为一道大题出现但在客观题和案例题的背景信息里会频繁出现DAU、WAU、MAU、留存率、付费率、ARPU、ARPPU、LTV等概念。你要是不清楚这些指标的定义和用途读题阶段可能就卡住了。几个核心指标的理解我建议务必到位DAU/WAU/MAU日活跃/周活跃/月活跃用户数反映用户规模。MAU与DAU的比值可以粗略反映用户粘性。留存率新增用户在N天后仍然活跃的比例。次日留存、7日留存、30日留存各有侧重。付费率付费用户占活跃用户的比例。通常用日付费率、月付费率来观察商业化健康度。ARPU每活跃用户平均收入等于总收入除以活跃用户数。ARPPU每付费用户平均收入等于总收入除以付费用户数。ARPPU和付费率往往是跷跷板要结合着看。LTV用户生命周期价值通常用来评估获客成本和投放ROI。LTV大于CPI每安装成本时买量模型才能跑通。我当时笔试中遇到一道题大意是“某游戏月付费率上升但月ARPPU下降总收入没有明显变化可能是什么原因”。实际上这背后就是付费用户基数扩大但新增付费用户的付费能力偏弱导致平均付费额被拉低需要结合用户结构和付费转化漏斗进一步分析。这类题没有标准答案但如果你对指标之间的联动关系理解到位答起来就能有理有据。3.6 Excel数据透视表与业务分析结合虽然笔试用Excel实操的可能性不大但我还是把Excel数据分析的基本功过了一遍尤其是数据透视表、VLOOKUP、SUMIFS这类高频函数。因为在未来的面试中面试官可能会问“如果业务方临时要一份数据你怎么快速响应”虽然SQL是核心武器但Excel常常是快速产出报表的第一工具。我在准备时专门练了把一份10000行左右的用户明细表做成按渠道、按日期的交叉汇总表。熟练掌握数据透视表后这类操作可以在两分钟内完成。而且Excel的图表可视化能力也不差做一些快速探索性分析时比先写SQL再导入Python要轻快得多。3.7 数据可视化图表选择比画图更重要英雄游戏的笔试没有要求提交可视化图表但在业务题答题过程中可以用文字说明“我会上线一个折线图观察趋势变化、用堆叠柱状图拆维度、用散点图看付费与活跃的关系”。这会让阅卷人觉得你是有数据可视化sense的而不是只会跑数。我自己在准备时复习了常见的图表使用场景趋势分析用折线图适合看次日留存率按日的变化曲线结构分析用堆叠柱状图或饼图比如付费金额在不同品类的占比相关性分析用散点图比如在线时长与付费金额的关系分布分析用直方图或箱线图比如观察付费金额的分布是否偏态。3.8 数据分析思维从“跑数工具人”到“解决问题的人”最后这类型不太像是“题”但它贯穿所有题目。很多人在准备笔试时把大量时间花在刷SQL语法和Python函数上却忽略了分析思维的训练。但英雄游戏的笔试给我的感觉是它更想招“能理解游戏业务的数据分析师”而不是“只会执行指令的跑数机器”。拿业务案例题来说同样一个留存率下降的问题有人只能想到“看看是不是数据延迟、是不是报表bug”有人却能结合版本上线时间线、渠道买量节奏、竞品动作、游戏内活动日历给出多维度的排查方向。这两者的差距不在于工具熟练度而在于有没有形成“数据分析思维”。我建议准备笔试时每周花一到两天专门看“数据分析案例”和“数据分析面经”不要只看答案要拆解题主的分析过程——他是怎么从模糊的问题出发一步步定义指标、拆解维度、验证假设的。看得多了你再遇到陌生题目就不会慌。4. 时间分配与做题顺序真实考场复盘在线笔试的时间压力真的不小90分钟要完成几十道客观题外加至少4道大题。我当时差点在客观题上翻车——前10道逻辑推理题有点卡壳浪费了8分钟导致后面编程题时间被压缩。这里详细复盘一下我的时间分配供大家参考。4.1 我的时间分配明细部分建议时间实际用时策略客观题逻辑统计25分钟30分钟每道题控制在1分钟以内超过先标记跳过SQL编程题20分钟18分钟先写大体框架再补细节Python题15分钟12分钟优先用pandas完成不纠结一行流写法业务案例题20分钟22分钟按框架分点写满给出可见的行动建议检查与补充10分钟8分钟检查SQL字段名、补全业务题的细节解释总体来看我的客观题确实超时了导致检查时间偏紧。如果重来一次我会在客观题上死守25分钟的底线——一道题超过90秒没思路就直接随便选一个等做完大题有剩余时间再回头思考。4.2 最容易踩的坑这次笔试我踩过或见过的坑集中在下面几个方面。客观题死磕有些逻辑推理题是真的难短时间内根本推不出来。死磕一题会让后面的时间全面崩盘。SQL没有先理清逻辑就开写一开始我直接写关联条件写到一半发现分组维度少了只能全部删掉重来。这样既浪费时间又容易把代码改乱。正确做法是先在纸上或者心里理清思路先建新用户表、再关联、再聚合。Python题忽略了字段类型读入数据后没有第一时间检查dtypes结果日期列是object类型做排序时完全乱掉白白浪费了5分钟排查。业务题写太短很多人只写“需要排查版本更新和渠道变化”一句话就没了。其实业务题不需要多高级的结论但要展现完整的分析链条。宁可多写几步也别让阅卷人觉得你没思路。4.3 答题技巧与“偷分”方法在不确定答案的题上也有几个实用的“偷分”策略。客观题用排除法先排除明显不靠谱的选项正确率能提高不少。SQL题即使运行结果不对也要把整体思路写出来。通常阅卷是看步骤分的部分正确的逻辑也能拿分。业务题一定要分点作答把每条推测独立成段条理比文采重要。Python题在代码块边上用注释标注“此处计算每日活跃用户”“此处进行分组聚合”即使函数用错阅卷老师也能看懂你的意图酌情给分。5. 笔试后的复盘如何把笔试变成面试素材笔试交卷不等于结束。很多人考完就把题目忘了其实这是最浪费的——笔试中的题目往往就是面试官在面试中追问的起点。5.1 复盘方法论把错题变成自己的知识体系我习惯把所有笔试题目按“SQL/统计/业务”三类归档每类题目整理出一个标准答案模板。比如SQL题我会把留存计算、漏斗计算、窗口函数排名这几类整理成一份“可直接复用”的脚本统计题我会把z检验、t检验、卡方检验的适用场景和代码写法单独写在一个文档里业务题则把所有分析框架整理成“指标异动排查”“AB测试设计”“用户分层与精细化运营”三大模板。这样做的好处是在面试前集中复习时不需要重新翻遍所有资料只需要看自己整理出来的模板和错题集。效率会高很多。5.2 从笔试到面试的衔接准备英雄游戏的面试环节一般会结合笔试内容做追问。比如笔试里考了留存计算面试官很可能让你现场再写一遍并追问“如果留存数据口径发生变化怎么办”“如果某渠道次日留存率明显低于其他渠道你会怎么进一步分析”。这时候笔试准备过程中的积累就派上用场了。我在笔试后还专门准备了一个“游戏数据分析项目”的素材库把之前做过的小项目——比如分析某款游戏用户付费行为的case——反复打磨成可以口述的版本。这样无论面试官问SQL、问业务理解还是问项目经验我都能快速调动素材不至于现场卡壳。另外建议准备数据分析岗的同学不管投的是游戏公司还是其他行业都要把“商业数据分析”和“金融风控数据分析”这类不同行业的题都看一遍。不同行业的数据分析面试题风格差异其实挺大游戏行业看重用户行为与留存电商行业看重转化和复购金融风控侧重违约预测与特征工程。多跨领域看题你的分析思路会更开阔。5.3 保持题感笔试后一周内的复习节奏笔试结束后一周通常是面试邀请集中发放的时间这个阶段不要完全放松建议保持每天的“刷题手感”每天练1~2道SQL题、1道Python数据处理题再读1篇数据分析案例保持对业务场景的敏感度。我当时保持的节奏是上午做一道SQL题控制在30分钟内下午看一个业务分析案例并练习搭建分析框架晚上把当天错题或者有趣的思路记到知识库里。这样一周下来不仅巩固了笔试中暴露的问题还对后续的面试保持了持续的信心。最后分享一个笔试送分技巧说一个很少人注意但非常实用的技巧线上笔试的输入框通常不支持代码高亮所以代码的缩进和对齐完全靠手动。在写SQL和Python时尽量不要用tab键缩进改用四个空格并且每一行尽量短一点避免因为编辑器宽度问题导致代码被换行、看着很乱。阅卷人每天要批改很多份卷子一份格式整齐、有注释、有条理的回答天然会比乱糟糟的代码更有好感。我个人在实际操作中体会最深的一句话是数据分析岗笔试本质上是一场信息战。你在考前对“题型、考点、出题偏好”掌握得越充分考试中就越能从容。英雄游戏2023年秋招数据分析岗的笔试已经过去一段时间了但它带给我的经验——把工具练到条件反射、把业务框架内化成思维习惯——在后来的实习和正式工作中也一直受用。希望这篇复盘能给你提供一些查漏补缺的方向祝准备秋招的你顺利拿下心仪offer。