ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

吉比特2018秋招数据分析笔试题详解与答题思路

吉比特2018秋招数据分析笔试题详解与答题思路 “吉比特2018秋招数据分析岗位试卷A卷”光看这个名字经历过校招的朋友应该就能闻到那股熟悉的硝烟味。吉比特作为国内老牌游戏厂商旗下有《问道》《不思议迷宫》等产品他们对数据分析师的考察在当年的校招里算是相当有代表性的不跟你玩虚的直接拿业务场景和真实数据思维来筛人。我去年帮几位学弟学妹复盘过这套题自己也把能找到的版本重做了一遍今天就把这套卷子的拆解、核心考点和解题思路完整写出来。不管你是正在备战游戏行业数据岗还是想看看厂商笔试到底考什么这篇都值得你花十分钟读完。1. 试卷整体设计与考察思路拆解1.1 吉比特笔试的定位不考“刷题家”要招“业务脑”2018年那会儿数据分析岗的笔试题型已经分化得很明显了。一类是互联网大厂通用卷上来就是海量SQL、概率论、机器学习模型推导恨不得让你手写一个GBDT另一类就是吉比特这种游戏厂商的定制卷它的核心诉求是你能不能理解游戏业务能不能用数据回答“玩家为什么流失”“这个活动该不该做”“广告投放效果怎么评估”这类问题。这套A卷的整体结构可以概括为“三三制”大约三分之一的基础统计与概率题三分之一的数据处理与SQL题还有三分之一是业务场景分析题。前两部分是门槛用来筛掉基本功不扎实的人最后一部分才是真正的分水岭用来筛掉只会跑数、不懂业务的人。换句话说这套卷子考察的不是你背了多少公式而是你在面对一个游戏业务问题时能不能搭建出清晰的分析框架。1.2 为什么这套题至今仍有参考价值有人可能会说2018年的题都过去这么多年了游戏市场都变了好几轮还有什么参考价值我的看法恰恰相反。数据分析这个岗位的笔试题淘汰的速度远没有技术框架那么快。吉比特这套卷子里考察的留存率计算、付费转化漏斗、AB测试的显著性判断、用户分群分析这些知识点到今天依然是游戏数据分析的核心。更重要的是这套卷子代表了一类经典的出题风格有限时间内用有限的题目考察你对业务指标的定义能力、对数据的敏感性、对分析方法的理解深度。这种“少而精”的考察方式比砸一百道选择题让你刷手速要高明得多。你只要把这类题目吃透再去做其他游戏厂商的数据岗笔试基本就是降维打击。1.3 试卷已知考点范围与题型分布根据我收集到的信息和多位参加过笔试的同学回忆这套卷子的题型大致分布如下选择题/填空题考察统计学基础包括均值中位数众数的使用场景、正态分布的性质、置信区间的含义、相关性与因果性的区别等。SQL/数据处理题考察查询编写能力涉及多表关联、聚合函数、窗口函数的初步使用以及数据清洗的常规思路。案例分析题给出一个游戏业务场景比如新版本上线后次日留存下降要求你梳理分析思路、定义指标、给出数据需求并提出优化建议。开放论述题考察对数据分析岗位的理解、常用分析模型如漏斗模型、RFM模型的应用场景、以及如何向业务方呈现分析结论等。这个结构在当年的游戏厂商笔试题里非常典型。接下来我逐个模块拆解核心知识点和答题要领。2. 核心知识点解析与答题要点2.1 统计基础模块概念辨析是重灾区这个模块的题目看似简单实际上陷阱非常多。我印象最深的一道题是“某游戏近30天的人均付费金额为100元付费用户人均付费为200元请问总体付费率是多少”这道题看似给足了条件实际上“人均付费金额”的分母是全体用户还是活跃用户题干里没有说清楚如果直接拿200除以100得出50%的付费率就掉进出题人的陷阱了。正确的思路是先明确各指标的分母定义人均付费金额 总付费金额 / 总用户数付费用户人均付费金额 总付费金额 / 付费用户数。如果前者是100元后者是200元那么付费率 付费用户数 / 总用户数 100 / 200 50%这个结论是对的但前提是你得能写出这一步推导而不是凭直觉蒙一个答案。另一个高频考点是“幸存者偏差”。有一道题给了一个数据某版本更新后高等级玩家的付费率提升了10%低等级玩家付费率下降了5%但整体付费率却提升了。问你如何解释。很多人会想当然地说“说明新版本对高等级玩家有利”但实际上这很可能是辛普森悖论的变体——高等级玩家的用户占比在更新后变大了或者高低等级用户的划分标准本身在更新前后发生了变化。答题时如果能把这个层面讲清楚会显得非常有数据敏感度。2.2 SQL模块窗口函数和分析思路要一起考吉比特的SQL题不会出那种“三表关联查出所有满足条件的记录”的纯机器式题目而是会把业务条件揉进去。比如我见过一道真题要求从一张登录日志表和一张充值表中统计“每个玩家在首次充值前的7日内是否至少有3天登录过”。这个题其实分几步走先用充值表找出每个玩家的首次充值时间然后用登录日志表和这个时间匹配筛选出首次充值前7天的登录记录接着按玩家分组统计登录天数再过滤出天数大于等于3的玩家。这里有两个关键点值得注意。第一时间条件要写对是“首次充值前的7日内”这个“前”和“7日”的边界定义要明确到底是含当日还是不含当日按自然日算还是按24小时滚动算第二如果只用基础SQL处理“首次”这个概念会比较绕用窗口函数ROW_NUMBER()按玩家分组、按充值时间排序然后取排名为1的记录思路会清晰很多。这种题考察的其实是业务分析思维的SQL化你脑子里先得有分析框架然后才能用代码实现。MySQL 8.0之后的窗口函数或者Hive、Spark SQL里常见的row_number()、lag()、lead()在游戏数据分析场景里使用频率极高尤其是计算留存、计算连续登录天数、计算首充时间这类经典问题。建议备考时一定要把针对这类场景的SQL写法练熟光靠刷LeetCode数据库题是不够的LeetCode那些题偏重语法缺乏业务浓度真实笔试题更看重你能不能把业务语言翻译成SQL逻辑。2.3 业务分析模块框架感和指标定义能力决定上限案例分析题是这套卷子里最见功力的部分。一道经典的题目是这样的“某游戏上线了一个新活动活动期间付费收入明显上升但活动结束后一周日活跃用户数DAU比活动前下降了5%。数据分析师需要给出结论。”这种题没有标准答案但阅卷人能从你的答题结构里看出你是“取数工具人”还是“分析师”。我的答题框架建议分四层第一层验证数据的真实性。先确认活动期间和活动后的DAU统计口径是否一致有没有数据缺失、埋点异常、渠道结算延迟等问题。这个步骤很多人会忽略但对游戏行业来说数据口径不一致的情况太常见了版本更新、SDK切换、渠道归因逻辑调整都可能造成数据波动。第二层拆解DAU下降的结构。DAU 新增用户 回流用户 活跃老用户。下降的5%到底来自哪部分如果是新增用户减少那是买量投放停了还是有渠道结算问题如果是老用户流失那要结合留存率曲线看是从活动期间就开始流失还是活动结束后才出现第三层结合活动机制做因果推断。活动是否透支了玩家的游戏时长或付费意愿活动奖励是否加速了游戏内容消耗导致玩家在活动后进入了内容真空期这些都需要通过分组对比来验证比如参加过活动和没参加过活动的用户其活动后留存差异是否显著。第四层给出可落地的建议。如果判断是内容消耗过快导致流失建议是加快版本更新节奏或者设计长线目标如果是活动疲劳建议是调整活动频率和投放力度。这个框架的核心逻辑就是“先验证后归因再优化”。你能不能在卷面上把这个思考过程写清楚比最终有没有得出一个“正确”结论重要得多。因为真实的数据分析和解题不一样永远没有一个唯一正确解你的价值在于提供一个有逻辑支撑、可验证、可迭代的结论。3. 实操过程与核心环节实现3.1 从一道SQL真题看完整解题流程为了让大家更直观地感受这套卷子的实战难度我拿出道我当时反复练过的题完整走一遍解题流程。题目大概是这样的表1login_log用户登录日志字段有uid用户ID、login_date登录日期格式YYYY-MM-DD。表2payment充值记录字段有uid用户ID、pay_time充值时间格式YYYY-MM-DD HH:MM:SS、amount充值金额。要求统计每个用户的首次充值日期及其在首次充值前7天内不含首次充值当日的登录天数。我们来分步拆解。第一步从payment表里取出每个用户的首次充值时间SELECT uid, MIN(pay_time) AS first_pay_time FROM payment GROUP BY uid;这里用MIN函数取最小值是最直观的首次充值时间。如果充值记录表里有大量历史数据先用子查询过滤掉测试账号比如uid小于某个值或者uid在测试白名单中效率会更高。第二步把首次充值时间转成日期并和登录日志关联SELECT a.uid, DATE(a.first_pay_time) AS first_pay_date, COUNT(DISTINCT b.login_date) AS login_days FROM (SELECT uid, MIN(pay_time) AS first_pay_time FROM payment GROUP BY uid) a LEFT JOIN login_log b ON a.uid b.uid AND b.login_date DATE_SUB(DATE(a.first_pay_time), INTERVAL 7 DAY) AND b.login_date DATE(a.first_pay_time) GROUP BY a.uid, DATE(a.first_pay_time);这一步有几个细节需要说明。用LEFT JOIN而不是INNER JOIN是为了保留那些在首充前7天完全没有登录记录的玩家他们的登录天数为0在后续分析中也是重要的对比组。日期过滤条件里用的是和也就是左闭右开区间这是为了防止重复计算边界日期。如果想把首充当日也算进去直接把改成就行。第三步如果还要统计“首充前7天登录天数3的用户占比”就在外层再套一层SELECT COUNT(DISTINCT CASE WHEN t.login_days 3 THEN t.uid END) / COUNT(DISTINCT t.uid) AS pct_3plus_days FROM (上述查询结果) t;这道题做完之后你会发现自己对“窗口函数是不是一定比子查询好”“LEFT JOIN和INNER JOIN在业务计算中的差异体现在哪里”这些问题的理解都加深了一层。说实话这种题目刷一遍比干看十篇SQL教程都有用。3.2 业务案例分析题的标准作答结构再回到那类最让我头疼、也最能拉开差距的案例分析题。给大家一个我后来总结出来、并且在多次面试中验证过好用的答题模板明确问题。把题目里模糊的表述转化成可分析的问题。比如“分析新版本上线后次日留存下降”要先定义“新版本上线时间”“次日留存的统计口径”“对比基准是上线前一周还是前一个月”。搭建指标体系。针对问题选择核心指标和辅助指标。次日留存率是核心指标但还不够还要看新增用户次留、老用户次留、按渠道拆分的次留、按机型拆分的次留等维度才能定位下降的来源。提出假设。根据业务经验列出可能导致下降的所有假设一般要写三到五个比如版本适配问题、新玩家引导流程变化、核心玩法改动的学习成本、渠道投放结构调整、竞品同期上线等。设计验证方案。针对每个假设说明需要用哪些数据验证。比如验证版本适配问题要看崩溃率是否上升、不同机型的次留是否有显著差异验证引导流程变化要看新手关卡完成率是否下降、新手阶段的流失是否集中。给出结论和行动建议。如果你的时间只够做一次分析你会优先做哪些验证你希望业务方采取什么行动建议要具体不能只是一句“优化用户体验”而要是“建议回滚新手引导的第2步改为原有方案并继续观察3天”这种可执行的方向。这个模板最核心的价值是让阅卷人一眼看到你的思维路径。很多人在回答这类问题时喜欢直接给结论比如“应该把活动奖励调高”这就显得非常业余。数据从业者应该时刻记得任何洞察都要基于数据和验证而不是拍脑袋。3.3 工具准备与答题时间分配心得吉比特这套卷子我印象中是笔试加一轮专业面笔试时间一般在60到90分钟。这个时间对题量来说并不宽裕因为我记得有同学反馈说案例分析题写到一半时间就到了。所以我的建议是拿到试卷先把所有题都浏览一遍心里对难易程度有个谱统计基础题如果30秒内没有思路先跳过把时间留给后面的大题SQL题如果写不出来完整正确的代码就写思路和解法步骤甚至用伪代码也行。阅卷人最怕的是看到你整道题空白只要你对业务分析有思考、有步骤、有框架就算查不到“正确答案”也能拿到不少分。工具方面笔试的时候一般会给一个在线的SQL编辑环境或者支持本地的Python环境。不管用哪种都要提前准备好思维模板SQL的日期处理函数、字符串处理函数、常用的窗口函数Python的pandas读写数据、groupby聚合、merge拼接这些操作要特别熟练因为现场去查函数的语法非常浪费时间。平时练习建议用本地MySQL或者SQLite搭一套模拟数据把各种查询练熟形成肌肉记忆。我当时是建了一个模拟游戏登录和充值的数据集反复练习了留存率、LTV生命周期价值、ARPU每用户平均收入、付费率这些经典指标的计算SQL后来遇到笔试题基本都能做到条件反射级别的反映。4. 常见问题与排查技巧实录4.1 概念题“翻车”现场最容易踩的三个坑第一均值、中位数、众数的选择问题。游戏行业的付费数据是典型的右偏分布少数大R玩家的付费金额极高直接拉高了均值。如果要描述“大多数玩家的付费水平”用中位数或分位数更合理。笔试中如果出现“某游戏付费用户平均付费100元但大多数付费用户付费低于50元如何解释”答案就是数据分布右偏均值被极端值拉高了。第二相关性和因果性的混淆。这是老生常谈但真的每次考试都会考。比如“我们发现游戏等级越高的玩家在线时长越长因此提升等级会延长玩家在线时长”这个逻辑就是错的。等级高和在线时长长只是相关关系可能是反向因果在线时长长的玩家自然升级快也可能是混淆变量对游戏认同度高的玩家既升级快又在线久。正确的做法是控制变量或者做随机分组实验。第三置信区间的误读。很多人在解释置信区间时会说“有95%的概率真实值落在置信区间内”这个说法在严格统计学意义上是不准确的。置信区间的含义是如果我们重复抽样很多次每次构造一个置信区间那么大约95%的区间会覆盖真实值。这个区别在选择题里经常作为干扰项出现。答题时如果能把“置信水平是对方法而言不是对某个具体区间而言”这个点写出来非常加分。4.2 案例分析中常见的逻辑漏洞案例分析题要写得有说服力还要避开几个常见的逻辑漏洞。第一个是“只看总盘不看结构”。比如DAU下降了5%你不看新增、回流、老活跃分别怎么变化就下结论说活动透支了用户这就太着急了。有可能你的老用户活跃其实还涨了纯粹是买量投放停了导致新增下降。第二个是“忽视时间窗口的影响”。游戏行业特别明显——周末的DAU和付费天然高于工作日月底和节假日活动密集时数据也有周期性波动。如果你拿活动后一周的DAU和活动前一周比而这两周恰好横跨了周末和工作日错位那结论就完全没有说服力。比较严谨的做法是打同比即对比上个月同期或者上个同类型活动周期的数据。第三个是“不做分组对比”。想知道一个活动是不是带来了用户增长最理想的方式是分组对比把用户随机分为活动组和对照组看两组在活动周期内的DAU/付费差异。游戏行业做不了完全的随机分组时也要尽量用PSM倾向得分匹配、双重差分DID这类准实验方法或者至少做“参与活动用户”和“未参与活动用户”的基线对齐确保两组在活动前的核心指标上没有显著差异。笔试中如果你能主动提出用AB测试或者DID检验因果那已经是超出大多数考生的水平了。4.3 关于SQL查询结果“看着对其实是错的”排查经验SQL题的排查也是一门学问。我自己刚学SQL的时候最爱犯的错误就是关联字段没加条件限制导致笛卡尔积爆炸算出来的数据大得离谱。排查这类问题的经验是先用SELECT *LIMIT 10查看中间结果确认关联字段值是否符合预期再用COUNT(*)核对各阶段的数据量看明显不合理的地方在哪里最后检查关联字段的数据类型是否一致比如uid在A表是字符串、在B表是整数隐式类型转换可能导致关联不到任何记录。还有一类是时间边界问题。每次做“近7天”“当月”“上周”这类计算时都要先明确时间起点是当天0点还是当前时刻区间是左闭右开还是全闭。同一份数据换一个时间口径结果可能差20%。笔试中如果对口径有疑问可以写一行注释说明自己的假设这种严谨性反而能给阅卷人留下好印象。用窗口函数或者CASE WHEN配合日期函数去做区间判断可以降低边界出错的概率。4.4 备考资源与刷题优先级基于这一整套试卷的分析我给大家一个备考资源的使用优先级优先级一SQL刷题重点练JOIN、子查询、窗口函数、日期处理四类题。渠道方面LeetCode数据库题库可以刷但更需要找一些“业务题”来练比如各类游戏厂商的笔经、牛客网上的历年真题。优先级二统计学基础题重点掌握描述统计、假设检验、相关与回归、概率论基础推荐《白话统计学》这本书讲得非常通俗。优先级三业务分析思维重点练习漏斗分析、留存分析、活动评估、用户分群四类场景。推荐阅读《精益数据分析》中关于指标树和虚荣指标的章节对建立分析思维很有帮助。优先级四Python/Excel数据处理如果在笔试中允许用Pythonpandas是必备技能。Excel的数据透视表、VLOOKUP、SUMIFS这类基本功也建议保持熟练很多公司的笔试是允许用Excel完成数据处理的。如果你时间有限我强烈建议把SQL优先级提到最高。根据我对历年游戏行业数据岗笔试题的观察SQL题几乎是送分题练熟了就是稳定拿分项。统计学和业务分析需要长期积累短期想突击上来比较难但是SQL完全可以在两周内通过密集练习实现质的飞跃。5. 这套试卷背后的行业风向与长期能力建设5.1 从吉比特看游戏数据分析师的“能力画像”把这套卷子做透了你会发现它其实画出了游戏行业对数据分析师的能力期待。第一你必须懂数据技术SQL溜是基本要求Python最好也会一些第二你必须懂游戏业务知道什么是次日留存、什么是LTV、什么是付费渗透率知道这些指标之间的逻辑关系第三你必须有框架思维拿到一个模糊的业务问题能自己把它定义清楚然后设计出分析方案。这个能力画像并不是吉比特独有的它几乎是国内游戏厂商数据岗的统一标准。从腾讯的IEG到网易游戏再到后来的米哈游、鹰角这些公司数据岗笔试题的底层逻辑都差不多区别只在于题材包装和业务场景的差异。所以这套卷子虽然年头不短了但用来做基本功训练和笔试摸底性价比极高。5.2 分析思维不是笔试完就丢的技能这套卷子里考的很多内容后来我在真实的工作中也频繁用到。比如SQL里那次首充前7天登录天数的统计后来我把它改造了一下就变成了“首充用户在首充后7日内的流失风险预警”的核心口径。再比如案例分析里讲的活动透支问题后来我在评估一次大型促销活动时曾用分组对比的方法验证了活动用户的后期留存是否显著低于非活动用户结论直接影响了后续活动的排期设计。说这些是想告诉大家笔试不仅仅是找工作的敲门砖它其实是一次强制性的知识体系梳理。你为了备考学到的每一个分析方法、刷过的每一道SQL题在未来两三年内都会以某种形式出现在你的工作里。认真对待每一次笔试准备真的是在为自己的基本功账户存钱。5.3 持续积累的三个方向如果你已经过了笔试这一关进入面试环节还有三个方向建议持续积累第一个方向是AB测试的实操细节。面试官特别喜欢问“如果样本量不够怎么办”“如果组间流量不均匀怎么办”“显著性水平怎么选”这类问题。光会说“做AB测试”是远远不够的你需要能说出最小样本量计算公式、常见的分层分流方法、以及如何利用AA测试验证分流均匀性。第二个方向是数据可视化和结论呈现。游戏行业的决策者大多不是数据背景出身你辛辛苦苦分析了十页报告如果第一页没有把核心结论用一句话讲清楚那这十页就白写了。平时可以多练习用一张图和一句话向别人解释你的分析结果这种能力面试时很难临时表演全靠日常积累。第三个方向是业务敏感度。面试官问“你怎么看这个版本更新”时不要只说“要看次留和付费”而要能结合版本内容、用户分层、渠道特点做出具体的分析预判。这个能力没有捷径只能通过多玩、多看行业分析文章、多和产品运营同事聊天来慢慢养。我自己的习惯是每周挑一款游戏的新版本更新公告自己先写一份“如果我是这个版本的数据分析师我会关注什么”的分析备忘再和实际数据对比验证。坚持三个月业务敏感度会有质的提升。说到底吉比特这套秋招题只是你数据分析职业生涯里很小的一站。但它考察的那些东西会陪你走很远。希望这篇拆解能帮你在备考路上少走点弯路把时间花在真正重要的地方。
返回列表