英雄游戏数据分析岗秋招笔试复盘：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(f"z统计量为: {z_stat:.4f}") print(f"p值为: {p_value:.4f}") alpha = 0.05 if p_value < alpha: print("拒绝原假设，实验组和对照组存在显著差异") else: print("不能拒绝原假设，差异不显著")

但这里有一个关键得分点：不能只写p值小于0.05就完事。阅卷老师更希望看到你补充“效果量”的判断——即使差异具有统计学显著性，也要看差异在实际业务中是否真实有用。比如实验组付费率比对照组高了0.1个百分点，虽然样本量大到足以让p值显著，但对游戏收入的影响可能微乎其微，还需要结合成本评估是否值得全量上线。

3.4 业务案例题：指标异动排查的完整框架

前面提到的“次日留存率下降”就是这类题的典型代表。做这题时我采用“假设驱动+维度拆解”法。

我的答题逻辑是这样的：

1. 先确认数据是否准确：查看埋点是否正常、口径是否有变化、是否出现部分平台或渠道的数据缺失。
2. 整体趋势与异常点确认：下降是从哪一天开始的？是突然下跌还是持续下滑？跌幅大概多少？
3. 维度拆解：按渠道（安卓/iOS、广告渠道/自然量）、按用户类型（新用户/老用户）、按版本、按地区等维度拆分，找出是哪个子群体把整体指标拉低了。
4. 原因假设：基于维度拆解结果，提出可能原因。比如iOS端正常但安卓端暴跌，那可能是某渠道买量质量变差；如果是新用户体验变差，可能是新手引导环节出现问题或版本热更引入bug。
5. 验证方案：针对假设设计验证方式，比如追踪同一批新用户的后续留存曲线、检查版本分布，或者拉取Crash日志看崩溃率是否上升。
6. 输出建议：根据结论给出运营或研发侧的建议，比如回滚版本、调整投放策略、修改新手任务难度等。

这个框架不只是笔试能用，实际工作中做指标异动排查也几乎每次都用得上。准备数据分析面试时，这类题目一定要多练几个案例，做到拿到题目就能条件反射式地搭建出分析框架。

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分钟的底线——一道题超过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。