搜狐畅游数据分析师笔试复盘：SQL、概率统计与业务思维全解析

2019年秋招我参加了搜狐畅游的数据分析师笔试到现在回想起来那套题给我的收获比后来很多面试都要大。当时投递的是游戏事业部岗位名字写的是数据分析师但实际做的工作会横跨用户研究、商业分析、运营数据支撑三条线所以笔试题的覆盖面也特别广从SQL到概率统计从业务感觉到逻辑推理一张卷子基本把数据分析师的核心能力摸了个底朝天。这篇文章把这套笔试的考察逻辑和典型题目重新复盘一遍重点不是说“当年考了什么”而是告诉你这些题背后到底在考察什么能力、怎么准备才能不踩坑。如果你是准备投游戏行业数据分析岗的应届生或者刚转行想做数据方向这份拆解应该能帮你在笔试环节少走不少弯路。1. 先从笔试说起畅游数据分析岗到底在考什么1.1 为什么一份笔试值得专门复盘很多同学会觉得笔试题就是“过场”真正决定offer的是面试。但游戏行业不太一样尤其是搜狐畅游这种体量的公司研发、运营、市场都在用数据做决策数据分析师入职之后是要直接对接业务线出报表、做专项分析的基础不扎实的人进来会非常痛苦。所以笔试这关刷人特别狠考察的也不是你会不会背概念而是你有没有真正做过数据相关的事情。我当年那套题做完之后最大的感受是它不考“你知道多少”而考“你遇到一个实际问题时能不能用数据思维把它拆明白”。这个区别特别重要后面我会结合题目细说。另外畅游笔试还有一个特点就是题目特别贴近真实的游戏业务场景。你会发现它很少出那种完全脱离行业的通用题而是会把具体的游戏活动、充值数据、用户留存这些场景直接丢给你让你在游戏语境下做分析。所以如果你完全不了解游戏行业的常用指标和业务逻辑哪怕技术底子不错也会在业务分析题上吃大亏。1.2 笔试结构导读四个模块的能力布局根据当年参加笔试的回忆和后续跟其他候选人交流这套题大致可以分为四个模块每个模块对应一种核心能力。这里我整理一下你也可以当成一份自检清单来看。模块考察方向题目形式过关标准SQL与数据提取数据基础能力写SQL、改错SQL能写出逻辑正确、性能合理的查询概率与统计数据理论基础计算题、概念题算得对、能解释结果业务与商业分析业务理解能力案例分析、指标拆解有分析框架、有落地结论逻辑与估算综合思维能力估算题、陷阱题逻辑自洽、能意识到前提假设别小看这个结构它其实反映了一个数据分析师完整的工作链条从数据库里取数、到用统计方法处理数据、再到结合业务解释数据、最后形成决策建议。如果你在任何一个环节偏科笔试都会被放大出来。下面的内容我就按这个模块顺序把各部分的典型题目和解题思路展开讲。2. 必考的SQL题不仅要写得对还要写出最优解2.1 从“留存用户统计”看窗口函数的使用畅游笔试的SQL题是实打实要手写的而且只给你一张表、一个业务场景让你自己决定怎么查。其中有一道特别典型的题目背景是一个游戏有玩家登录表 login_log包含字段 uid、login_date让你统计每个玩家在2024年1月的连续登录天数并且要求输出连续登录天数大于等于7天的玩家名单。这道题的第一步是搞清楚什么叫“连续登录”。如果用户1月1日、1月2日、1月3日登录那么连续登录天数是3。但如果1月3日没登录1月4日登录了那1月1日到1月2日算一段连续1月4日开始算新的连续段。这道题的通用解法是用窗口函数 row_number() 对每个用户的登录日期排序然后用 login_date 减去排序序号得到一个分组标识凡是连续登录的日期减去同一个序号得到的结果是相同的再用这个标识分组计数就可以了。我当时的写法是先对每个 uid 去重 login_date然后with tmp as ( select uid, login_date, date_sub(login_date, row_number() over (partition by uid order by login_date)) as grp from ( select distinct uid, login_date from login_log where login_date between 2024-01-01 and 2024-01-31 ) t ) select uid from tmp group by uid, grp having count(1) 7;这里有个隐藏考点为什么先要去重因为一个人一天可能多次登录如果不去重直接算同一个日期会占据多个排名位置导致“连续”判定出错。这一步是典型的业务理解考察SQL本身不复杂但很多人会因为没做去重而扣分。接着可以追问一步如果要求统计连续登录天数最长的玩家呢那就要把每个用户的每个连续段的长度都算出来再取最大值。这个延伸在面试中也很常见建议自己动手把两张表的基础版本练熟。2.2 一道典型的活动付费关联查询拆解第二道SQL题考的是表关联背景大概是活动表 activityactivity_id, activity_name, start_date, end_date玩家付费表 payuid, pay_time, pay_amount。让你统计2024年春节期间参与过活动且有付费行为的玩家数量以及这些玩家的平均付费金额。这道题表面上看是简单的 join但其实有坑。坑在于活动时间跨多天而且一个玩家可能在活动开始前就付费、也可能活动期间付了多次。正确的口径是先筛选在活动时间范围内有付费记录的玩家然后去重计数而不是用 join 完之后直接 count(*)因为 join 会把一个人付费多次的记录都展开导致计数重复。常见的错误写法是select count(uid), avg(pay_amount) from activity a join pay p on p.pay_time between a.start_date and a.end_date;这样写有多重问题如果同时有多个活动同一个付费记录会被多个活动匹配到导致重复计数如果同一个人付费多次uid 会被统计多次。正确思路是先把活动时间范围提取出来或者用子查询先限定付费记录的时间范围select count(distinct p.uid), avg(p.pay_amount) from pay p where exists ( select 1 from activity a where p.pay_time between a.start_date and a.end_date );还有一个更隐晦的点avg 函数在没有记录时返回 null如果加 group by 也可能产生空行需要在写完后检查一下边界条件。笔试时间有限做完这类查询之后一定要在草稿纸上用几行数据做一遍推演别直接交卷。2.3 SQL笔试的常见“隐形扣分点”很多人觉得自己SQL没问题但实际上笔试扣分往往不是语法错误而是“业务口径”搞错了。结合畅游这套题我整理了四个常见的隐形扣分点。第一忘了去重。游戏业务中的数据天生有重复的可能性登陆日志、付费明细、道具产出都可能出现相同的记录所以写查询时要想清楚在哪个字段、哪个维度上去重。第二对时间字段的处理不严谨。比如统计“当天”的数据到底是凌晨0点到0点还是按服务器开服时间算是自然日还是滚动24小时这些都要根据场景来判断。第三分组粒度搞错。很多分析需求表面上是“求玩家数”但内部有多个维度比如按渠道、按服务器、按活动如果不把 group by 的粒度定清楚结果就会张冠李戴。第四忽略 null 值和空值。left join 之后某些 key 对应的字段是 null如果直接用这个字段做计算或者过滤结果就会莫名其妙丢数。我那时候就栽在第三点上交卷前检查才发现自己把分组维度搞粗了赶紧改了过来。如果你现在准备这类笔试建议平时练习的时候刻意给自己设置“口径陷阱”模拟真实业务中模糊的需求描述这样上考场才能反应够快。3. 概率与统计题游戏数值背后的基本功3.1 抽卡概率期望计算期望值到底怎么算才对游戏行业的数据分析师跟电商、金融数据岗有个很大的区别就是会和游戏的数值系统打交道而概率题几乎必考。畅游笔试中就有一道关于抽卡概率的题目场景是某卡池中 SSR 的出货概率是 1.5%并且有保底机制前 89 次没出金第 90 次必出金。问题是求玩家抽到第一个 SSR 的期望次数。乍一看这个题很简单很多人会直接说期望是 1/0.015 约等于 66.7。但这个答案忽略了保底机制带来的截断效应。因为有保底实际分布不是几何分布而是“第90次必定成功”所以期望次数要按截断几何分布来计算。计算方式是把第 1 到第 89 次按普通概率计算第 90 次把前面失败的概率全部折叠进来也就是其中 P(Xk) 在前89次等于 0.015 × (0.985)^(k-1)而 P(X90) (0.985)^89。期望 E(X) Σ [k × P(Xk)]k从1到90。我当时没有用计算器但是把式子分解做了估算答案是期望大概在 70 次左右比无保底的 66.7 略高。这个结果看起来反直觉但原因在于保底条件把原本可能超过90次的尾部概率全部压到第90次而第90次本身权重很大所以期望被抬高了。出题人真正的意图不是让你背公式而是看你能不能理解概率分布的截断和保底条件对期望的影响。还有一个扩展点是关于玩家感知的。游戏公司设计卡池时会同时关注“期望”和“保底位置”因为玩家更关心的是“我最倒霉要抽多少次才出货”这决定了玩家的付费意愿和吐槽点。数据分析师如果只能算期望看不懂分布百分位数就很难支撑数值策划的迭代需求。3.2 AB测试的显著性检验为什么p值不能说明一切畅游笔试里有一道和 AB 实验相关的简答题背景是运营做了一个新的首充双倍活动对照组约有 5000 人实验组约有 5100 人实验组的付费率是 4.8%对照组是 4.2%运营认为活动有效但分析师需要验证这个差异是否显著。题目问你会怎么做并要求写出假设检验的思路。这道题考察的不仅是你会不会算 z 检验而是你有没有完整的 AB 测试框架。第一步要明确原假设和备择假设原假设是两个付费率相同备择假设是实验组付费率大于对照组。第二步要确定显著性水平一般取 0.05。第三步计算合并比例和标准误差构造 z 统计量。我按 p10.048、p20.042、n15100、n25000 估算了一下z 值大概在 1.46 左右单侧检验 p 值约 0.07没有达到 0.05 的显著性水平所以结论是“有正向趋势但样本量不足以支撑显著性判断”建议延长实验周期或增大样本量。但这个题最坑的地方在最后一道追问如果 p 值显著了能说明活动一定有效吗正确答案是不能还需要排除混杂因素。比如实验组是否被分到了更多高活跃用户、活动期间是否有其他版本更新、两个组是否同时接受过其他运营触达。没有做好随机分流的 AB 测试p 值再小也可能只是系统偏差的体现。踩过这类题目的坑之后我强烈建议准备数据分析岗笔试的同学把“假设检验流程”和“AB测试的局限性”当作一个专题来复习这是游戏行业数分工笔题的高频考点。4. 业务分析题游戏数据分析师的核心竞争力4.1 从“付费率下降”谈分析框架笔试的业务分析题通常是给一个现象让你分析可能的原因并提出解决思路。畅游当年的题目我记得很清楚某游戏在一个版本更新后新用户次周付费率下降了5个百分点假设你是数据分析师要怎么排查这个问题。这类题的难点在于它没有标准答案考察的是分析框架。我当时的思路分四步先确认数据口径判断是哪个用户群在下降再拆维度从渠道、机型、地区、新手流程完成度等角度对比锁定下降集中在哪个细分人群然后查版本变更看看新手引导、首充活动、付费点位置是否有调整最后结合用户行为看关键路径的漏斗数据比如是否首充入口曝光下降、付费引导弹窗点击率是否降低。一个比较加分的回答是补充“对比分析”的思路。比如用去年同期、上个版本同期、下降前的稳定期做横向对比排除季节性因素。同时要提出“同环比结合”版本刚上线时的突发下降和持续下滑的处理方式完全不同前者更像bug或配置错误后者更像设计或经济系统问题。这道题能看出你是否具备真正的业务敏感度。很多应届生会陷入一个误区一上来就说要做回归分析、上机器学习模型但实际业务里第一件事永远是定位问题、确认口径复杂模型是后面才需要考虑的事情。4.2 留存异常的排查思路另外一道业务题是关于留存率的说的是一个新版本次日留存率从35%降到28%研发认为是数据统计问题运营认为是版本内容不受欢迎产品则怀疑是渠道买量质量下降问你作为分析师怎么判断谁说得对。这道题非常好的地方在于模拟了真实工作中“多个业务方各执一词”的场景。作为数据分析师你不能谁声音大就听谁的而是要用数据来收敛问题。我的分析框架是先做分渠道拆分因为买量质量下降这个假设最容易被验证。如果只有某个买量渠道的新用户次日留存下降而自然量留存保持稳定那这个问题大概率来自渠道侧。反过来如果所有渠道的新用户留存都在下降那更可能是版本本身的问题。接下来要看版本渗透率如果新版本覆盖了大部分用户并且老用户留存也在下降那就更支持“版本内容问题”的判断而不是单纯的用户质量问题。还可以进一步看用户的详细行为路径比如新用户在首日是否卡在某个新手引导步骤、是否频繁闪退、是否在某个玩法入口流失率显著偏高这些都能为研发定位bug或为运营优化活动提供线索。我在答题时特意强调了一点数据分析师在业务争议中要扮演“中立裁判”的角色不要预设立场也不要被业务方的利益绑定带偏。这个观点后来在面试复盘时被面试官提到过说明他们确实在意候选人面对业务压力时是否能保持客观。4.3 一个万能的分析框架以及它的使用边界多次刷笔试题之后我总结出一个在业务分析题里非常实用的四层框架描述现状、诊断原因、提出建议、评估效果。所有业务分析题都可以按这个顺序展开。描述现状就是要说清楚数据口径、对比基准和变化幅度诊断原因就是拆维度、拆漏斗、做相关性分析提出建议要落到具体的运营动作或产品改动评估效果是说怎么验证你的建议是否有效比如再开AB测试、设置核心指标监控。但我要强调一下这个框架的使用边界。它适用于执行层面的业务分析题比如付费率下降、留存波动、活动效果不佳。但如果题目考察的是策略层面的问题比如“要不要做某个新玩法系统”那光有分析框架是不够的你还需要有行业认知和玩家心理的理解。别把所有希望押在一个万能的框架上框架只是兜底的思考工具真正拉开差距的是你对业务细节的敏感度。这个道理我也是做了多个游戏项目之后才想明白的。笔试阶段其实答出框架就能拿大部分分数但如果你想拿满分甚至给面试官留下深刻印象就一定要在框架之外加入一两个具体的、可操作的分析细节比如“我建议先看新手教程第三步到第四步之间的人数流失”这种细节才显得你真的理解业务。5. 逻辑与产品思维题数据之外的综合能力5.1 估算题从“一个服务器的日活”看拆解能力畅游笔试还有一类题比较特别就是估算题。当时有一题是估算一下一款长线运营的MMO游戏单个服务器一天的日活跃用户数大概是多少。这种题在数据分析岗位的笔试里越来越常见因为它考察的是拆解能力、逻辑自洽能力和对业务的常识感。估算题没有标准答案关键是把拆解过程展示清楚。我当时是这么拆的先设定单服可容纳的同时在线人数上限假设是3000人再考虑MMO类游戏用户的在线时长平均每天在线2-3小时那么一天24小时分成约8个时段每个玩家在一天内可能集中在晚间3小时上线这样单服日活大约是同时在线峰值的2到4倍我取了一个中间值估到单服日活6000到10000人。拆完之后我补充说明这只是基于粗略假设的数量级判断实际还要看游戏类型、开服时长、用户重合度。答案本身不是重点面试官想看的是你有没有“把未知问题拆成已知问题”的能力。如果只会说“我不知道”这道题就零分如果能把假设写出来、分步骤演算哪怕数值差得远也能拿到大部分分数。准备这类题目我建议平时多做一些类似练习比如估算北京一个月能卖出多少杯奶茶、一个视频App一天能产生多少条弹幕。关键是养成“先定假设、再分步演算、最后说明误差来源”的表达习惯。5.2 指标题每天活跃用户到底怎么算还有一道题让我印象很深问的是“某游戏产品的日活跃用户数是100万请给出你的判断和验证方式”。实际上这是在考察指标的可靠性。数据分析师不仅要会算指标还要知道指标在什么情况下会失真。当时我列出了几种可能造成虚高的情况比如数据统计时把不同端的同一用户重复计数了比如爬虫或脚本刷量造成虚假活跃比如渠道刷量买量里面掺水再比如时间窗口选得不好比如把时区搞错把凌晨的海外用户算到了另一天里。验证方式包括用多端去重逻辑核对、看活跃用户的人均使用时长的分布是否异常、按IP或设备型号分布做异常检测等。这道题给我的启发是数据分析师不只是写SQL的还得有产品思维和数据质量意识。你给出的任何一个数字背后都可能藏着一整套埋点、清洗、加工的逻辑数字一旦失真决策就会跟着跑偏。笔试考这个其实是在筛选那些“会对数字保持警惕”的人而不是盲目相信数据的人。这种题在后续的面试中也经常被问到比如“如果你发现上报的数据和后台不一致你怎么排查”。所以建议准备的时候把数据质量相关的基础知识补一补包括埋点校验、去重逻辑、异常值检测。6. 复盘2019畅游笔试那些考完才想明白的事6.1 时间分配失误盘点说实话当时走出考场我最大的感受就是时间不够用。这套题的题量比预想的大尤其是SQL和业务分析题每一道都需要大段的思考和书写如果前面在概率计算题上磨太久后面就很容易草草收尾。复盘下来我觉得比较合理的时间分配是如果笔试总时长是120分钟SQL题控制在40分钟以内概率统计35分钟以内业务分析题30分钟剩下的15分钟留给检查。因为SQL题分值高且客观性强错了就是错了值得多花时间保证正确率业务分析题虽然分值高但只要框架清楚、逻辑完整不必追求字数多。我当时犯的另一个错误是在一道多选题上反复纠结浪费了差不多10分钟后来才发现那道题根本不需要全部答对只要写清楚理由也能拿分。很多选择题看起来是单选但题面里写着“以下哪些合理”实际上属于多选或半开放题不能按传统选择题的思路去对待。6.2 后来者应该怎么准备游戏数分笔试如果你也想投游戏公司的数据分析岗我建议准备过程分成三个阶段。第一阶段打基础把SQL窗口函数、留存计算、漏斗分析、假设检验这些核心知识点过一遍边学边在本地建几张表做练习这个阶段大概需要两到三周。第二阶段做业务题可以找一些游戏公司的历年笔试回忆题或者自己做两个完整的游戏数据分析案例比如分析一个游戏活动拉收效果、评估一个版本更新后的用户流失重点练分析框架和表达这个阶段需要长期积累但笔试前至少集中练习一周。第三阶段模拟笔试严格控制时间用A4纸手写SQL和分析思路提前适应考场节奏。题库方面没太多必要花大钱买资料网上能搜到的历年面经、笔经非常多关键是分类整理并且每道题都自己亲手做一遍。只看不写等于没看数据分析是技能型的科目技能只能靠练不能靠背。还有一个容易被忽略的点一定要提前了解游戏行业的常用指标和术语。比如DAU/WAU/MAU的含义、ARPU与ARPPU的区别、LTV和CAC的关系、次留/7留/30留的行业基准、付费渗透率、付费率与付费用户人均付费额的关系。如果你在笔试里能自然地使用这些术语并且能解释它们之间的逻辑阅卷人一眼就能判断你是不是对游戏数据有真正的了解。6.3 笔试之外的隐性考察从答题习惯看专业素养最后想聊一个很多人注意不到的层面就是阅卷人其实会通过你的答题过程来推断你的工作习惯。字迹工整、步骤清晰、公式写全、单位写对的人大概率在工作中也是一个注重细节、逻辑严谨的人。笔试时我特意把每一步计算都在草稿纸上写清楚然后在答题纸上保留关键推导过程而不是只写一个最终答案。尤其是估算题我把每个假设、每步运算都列了出来阅卷人即使不认同我的最终数值也能看到我的思路是完整的。另外如果题目里给了具体数值记得在答案里带上单位比如“人”、“元”、“天”不要只写一个数字。这种细节看着不起眼但在跟业务方沟通时极其重要数据分析师输出的任何结果如果不带单位和口径都有可能被误解。还有一个小建议做题的时候不需要把题目条件抄一遍但一定要圈出题目的关键限制条件。比如SQL题里的时间范围、概率题里的保底机制、业务题里的“新用户”和“次周”这种限定词漏掉一个限制条件整道题的口径就全变了。养成圈条件的习惯会让你的做题正确率提升一个档次。准备数据分析师方向的校招很多时候不是比谁聪明而是比谁准备得细。我自己把这一套笔试复盘完最大的收获是认识到数据分析师不只是技术工种更是连接数据与业务的桥梁。拿到任何一道笔试题先想清楚出题人想要考察什么能力再动笔去答这种“从需求出发”的思路本身就是数据分析师最核心的素质。希望这份复盘能帮你在下一场笔试里少踩几个坑。