每年春招季总有那么几场笔试让人印象特别深2023年腾讯音乐数据分析岗的第二批笔试就是其中之一。这批笔试整体难度中等偏上但题量密度不小覆盖了SQL、Python、统计学和业务分析四个方向跟我们平时在牛客、力扣上刷的“纯技术题”很不一样——它非常看重业务落地能力尤其是“在音乐产品场景下你如何用数据回答一个问题”。站在2024年回看这份题目其实依然有很强的参考价值。如果你正在准备腾讯系或其他大厂的数据分析笔试这篇文章会把第二批笔试的完整结构、核心考点、解题思路和一些我踩过的坑全部拆开讲清楚顺便附上一份可以照抄的复盘方案。无论你是第一次投数据分析岗还是已经面过几轮想查漏补缺都建议耐心看完。1. 整体题目结构与设计思路拆解腾讯音乐的笔试题型一般分成客观题和主观题两块。第二批笔试延续了往年风格但有一个明显变化纯计算类题目减少场景业务题占比接近一半而且在SQL题里刻意增加了一道“音乐推荐场景下的大表关联”问题明显想考察候选人在真实数据量级下处理数据的能力。1.1 题型分布与考察目标从题型维度看整体构成大概是这样的单选与多选题约15-20道覆盖概率统计、机器学习基础、业务指标理解比如“下列哪个指标更适合衡量付费会员转化效果”这类题表面考概念实际考的是业务嗅觉。SQL编程题约2-3道包含窗口函数、留存计算、连续登录判断、多表关联。其中有一道“歌曲完播率统计”的题要求基于播放日志还原每一次完整播放行为很有腾讯音乐的业务特色。Python编程题约1-2道一般不会考太复杂的算法更偏向数据处理比如用pandas做分组聚合、缺失值处理或者手写一个简单的RFM模型计算逻辑。主观业务题约2道围绕“付费用户增长”和“歌曲推荐效果评估”两个方向给你一些指标和背景要求提出分析框架、给出落地步骤。这种结构本身就能看出腾讯音乐筛选人才的逻辑技术基础扎实是底线业务理解深度是分水岭。如果你的SQL只停留在会写select join的层面笔试会非常吃力。1.2 为什么这些题目被选中腾讯音乐的数据分析岗不同于纯互联网流量分析它面对的是“内容社交付费”三重业务场景。因此大部分题目都带着明显的行业烙印。举个例子音乐产品里“完播率”和“试听比例”的关系直接关系到推荐系统的效果和版权成本分摊。一道题如果只给你一张播放记录表让你算某首歌的完播率很多人的第一反应是“播放次数/曝光次数”——但在真实场景里完播率需要区分用户主动播放和自动连播还要考虑播放时长不足5秒的无效曝光。笔试里故意留了几个数据上的“坑”例如同一用户同一首歌一天内多次播放、播放进度超过90%但没到100%怎么算这些恰恰是实际工作中每天都会遇到的定义问题。另外一个值得注意的地方是第二批笔试特别强调了“分析思路的可行性”。主观题里有一道是“付费会员的续费周期在最近三个月呈下滑趋势请给出你的分析思路。”这题没有标准答案但高分答案一定要包含阶段拆解新用户/老用户渠道差异、付费周期分层、AB测试思维同期群对比而不是简单看整体均值、以及数据验证手段。任何只停留在“提高产品质量、增加用户粘性”这类空洞回答的基本都会被刷掉。2. SQL与Python核心考点逐题拆解这一部分是笔试的硬骨头也是最容易拉分的地方。我结合自己和其他同学的回忆把几道比较有代表性的题目整理了出来并给出完整的解题链路和容易出错的地方。2.1 用户连续听歌天数的SQL解法这道题当年的高频题是“统计2023年1月每个用户连续听歌的最大天数”。输入表结构为user_id、listen_date、song_id一个用户一天内可能听多首歌需要先去重再计算连续天数。标准解法是使用窗口函数做日期排序然后通过date_sub(date, row_number)构造连续分组。核心思路是连续日期的排序序号差值是一个恒定值只要日期断了差值就会跳变。SQL可以写成WITH user_listen_unique AS ( SELECT DISTINCT user_id, listen_date FROM user_listen_log WHERE listen_date BETWEEN 2023-01-01 AND 2023-01-31 ), user_date_rank AS ( SELECT user_id, listen_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY listen_date) AS rn FROM user_listen_unique ), user_date_group AS ( SELECT user_id, listen_date, DATE_SUB(listen_date, INTERVAL rn DAY) AS grp_date FROM user_date_rank ) SELECT user_id, DATEDIFF(MAX(listen_date), MIN(listen_date)) 1 AS max_continuous_days FROM user_date_group GROUP BY user_id, grp_date HAVING max_continuous_days 2 ORDER BY max_continuous_days DESC;这里有几个需要注意的细节。首先是必须先去重否则一个用户一天听了50首歌就会被算成50条记录导致连续天数虚高。其次是DATE_SUB(listen_date, INTERVAL rn DAY)这一步如果你对rn的理解不彻底很容易搞错符号方向。实际上row_number从1开始当天日期减去rn后在一个连续的日期区间里得到的是同一个基准日期一旦日期断开基准日期也会变化分组效果自然就出来了。我在笔试时曾犯过一个错误没有处理用户跨月听歌的情况。题目给的窗口是1月但有的用户从12月29日连续听到1月5日如果只截取1月的数据这道题的连续天数就会被截断。正确的做法是保留一定的前置时间窗口或者在SQL里把边界条件写清楚否则结果会明显偏低。2.2 歌曲完播率统计的业务“陷阱”另一道高频SQL题是“给定播放记录表play_log包含user_id、song_id、play_start_time、play_duration_seconds、total_duration_seconds统计每首歌的完播率完播次数/播放次数完播定义为播放时长90%总时长”。这个需求看起来很简单但腾讯音乐笔试故意加了“同一用户重复播放”和“播放时长超过歌曲总时长”两条异常数据。如果不加处理直接相除完播率会出现超过100%的荒诞结果。一个合理的处理方式是SELECT song_id, SUM(CASE WHEN play_duration_seconds total_duration_seconds * 0.9 AND play_duration_seconds total_duration_seconds * 1.2 THEN 1 ELSE 0 END) AS finish_count, COUNT(*) AS total_play_count, ROUND(SUM(CASE WHEN play_duration_seconds total_duration_seconds * 0.9 AND play_duration_seconds total_duration_seconds * 1.2 THEN 1 ELSE 0 END) / COUNT(*), 4) AS finish_rate FROM play_log WHERE play_duration_seconds 5 -- 剔除无效播放 GROUP BY song_id;为什么要在分母里剔除小于5秒的记录因为用户可能误触、切歌这种极短播放并不代表真实的收听行为全部计入分母会把完播率拉低到失真。这也是腾讯音乐内部版权利润计算的一个基础口径问题——如果这首歌是按播放时长分成结算的无效播放直接影响成本。当然在实际工作中你不会用这么粗糙的where条件而是会建立一套“有效播放”的完整定义比如播放时长超过30秒或超过总时长10%两者取大。但笔试时需要明白出题人真正想考察的是“你是否知道数据口径会影响业务决策”。2.3 Python部分pandas数据处理与业务指标计算Python题通常会给一个CSV文件内容可能是某歌单的曝光点击转化数据要求完成三件事读取数据、清洗空值、按天统计转化率并找出异常波动日。这道题考得比较基础但很看基本功。一类常见错误是直接dropna把关键业务的空值全删了。正确做法是先判断空值比例。比如曝光渠道这一列如果空值占30%以上一般会单独标记为“未知渠道”而不是删掉但如果是“用户年龄”这种只需要用中位数填充或直接忽略的字段则可以用fillna处理。下面是一个直接可用的参考路径import pandas as pd df pd.read_csv(song_convert_data.csv, parse_dates[dt]) df[channel] df[channel].fillna(unknown) df[play_cnt] df[play_cnt].fillna(0) df[click_cnt] df[click_cnt].fillna(0) daily_stats df.groupby(dt).agg( total_expose(expose_cnt, sum), total_click(click_cnt, sum), total_play(play_cnt, sum) ).reset_index() daily_stats[click_rate] daily_stats[total_click] / daily_stats[total_expose] daily_stats[play_rate] daily_stats[total_play] / daily_stats[total_click] # 找出转化率异常低的日期 mean_rate daily_stats[click_rate].mean() std_rate daily_stats[click_rate].std() abnormal_days daily_stats[daily_stats[click_rate] mean_rate - 2 * std_rate] print(abnormal_days)笔试时如果你的时间紧张不需要做额外可视化但如果你能在答题最后补一句“结合周末效应建议对比不同星期几的转化率中位数”会显得更有业务深度。腾讯音乐的用户活跃有明显的高峰低谷周末和通勤时段的听歌习惯完全不同转化分析不考虑时间周期基本等于白做。3. 统计学与业务分析题的重点解析腾讯音乐的数据分析笔试题里统计学不会出大计算题更多是把统计学概念嵌在业务场景里考察。比如给你两个版本的推荐策略让你设计一个评估方案这背后就是假设检验和AB测试的设计。3.1 假设检验从“策略是否有效”到“样本量计算”我记得有一道选择题问的是“某推荐策略改动后点击率从8%提升到8.5%样本量为10000p值0.04下列哪个结论是正确的”选项里有一条很迷惑的表述是“该策略有96%的概率是有效的”。这个表述是错的p值不等于策略有效的后验概率。p0.04只说明在原假设成立时观察到当前或更极端数据的概率是4%不能直接推出策略有效的概率是96%。正确的叙事方式应该是“在显著性水平0.05下有统计学证据表明新策略的点击率不等于旧策略。”至于效果量有多大、值不值得全量上线还要看置信区间和业务成本。如果你在主观题里遇到“设计一个AB测试评估新推荐策略效果”一个合格的回答至少包含四步明确核心指标和辅助指标。核心指标可以是人均播放时长或次日留存辅助指标包括点击率、完播率、分享率。计算最小样本量。给定基线转化率p18%最小检测提升10%显著性水平0.05统计功效0.8利用公式n (Z_alpha/2 Z_beta)^2 * 2p(1-p) / delta^2算出每组约需要多少用户。分组方式和实验周期。建议按user_id哈希分桶避免同一用户在不同端看到不同策略实验期至少覆盖一周包含一个完整周末。分析阶段用双样本z检验或t检验同时做分层分析看效果在不同新老用户间的差异必要时使用delta method计算人均播放时长的置信区间。3.2 业务分析框架如何回答“付费率下降”这类问题继续聊那道“付费会员续费率下降”的主观题。这题看着问得宽泛实际上是在考察你拆解业务指标的系统性能力。比较好的分析框架包含如下层次第一层先定义“续费率”的口径。在腾讯音乐的场景里续费率可以是“当期到期用户中成功续费下个月的比例”也可以是“窗口期内曾为会员、窗口期末仍为会员的比例”。口径不同结论可能完全相反所以先要跟业务方对齐口径。第二层从“人-货-场”三个维度拆分。人新老用户、不同会员等级、不同付费渠道货歌单、数字专辑、个性装扮等权益的吸引力场是主动续费还是被动自动续费连续包月用户和单月购买用户天然存在差异。这种拆法不是套模板而是和音乐产品的付费逻辑强绑定。第三层做同期群分析。把每个月的到期用户按首次购买月份分组看后续续费曲线这样能区分“大盘整体下滑”还是“某个月新进来的用户质量变差”。这比单纯看整体续费率下降了多少百分比要精准得多。第四层给出验证手段。比如假设“暑期结束后学生用户的续费率明显下降”那就拉出学生用户群体和其他职业群体做对比看差异是否只存在于学生群体如果是再进一步拆“新开通用户”和“老用户”看哪个受影响更大。每一步都需要数据能验证不能只停留在猜测。3.3 业务题里隐藏的“音乐基因”我特别提醒一句腾讯音乐的笔试主观题会不自觉地渗透“音乐平台特色”。比如有一年的题是“一个歌手发布新专辑如何衡量这次发布对平台的贡献”如果你只写“看销量、看播放量”那基本就是中低分水平。更完整的思路是先看直接贡献包括专辑销量、数字专辑购买人数、播放量再看间接贡献比如歌曲进入推荐流后对人均时长的拉动、对其他歌曲的联动播放效应、用户评论区活跃度变化、甚至是对歌手粉丝拉动新用户注册的效果。如果能把“艺人发布”当成一次小型营销战役来拆把传播链路的每个环节数据都串起来答题质量就会上一个台阶。4. 实战复盘与时间管理建议笔试的时间一般在90分钟到120分钟之间题量相对紧张。我的感受是如果你在SQL题上卡了超过30分钟后面主观题基本就是仓促收尾。所以“先易后难、先业务后编程”的做题策略很重要。4.1 完整做题节奏参考我当年用的大致时间分配是这样的客观题部分20分钟如果一道概念题犹豫超过90秒先标记跳过不要耽误后面的大题。数据分析岗的客观题里偶尔会出现机器学习模型的细节题比如随机森林的特征重要性计算方式这类题如果没复习到纠结也没有用。SQL题部分35分钟先快速读表和业务背景再写代码。SQL题讲究一次跑通因为不少在线笔试平台不支持本地调试你写完之后只能点“运行”如果报错会特别浪费时间。建议提前在本地环境练熟窗口函数和日期处理函数。Python题部分20分钟pandas的代码量不会很大但要注意列的命名和数据类型有时候数据文件里的字段名跟题目描述里的不一致第一步最好先打印dataframe的dtypes确认一下。主观题部分30分钟至少留10分钟给最后的业务题别只写三五句话。面试官阅卷时最怕看到“我认为应该提高产品质量”这种既没有数据支撑也没有分析框架的空话。哪怕简单列个一二三四都比一段抒情式的自我介绍有价值。4.2 容易踩的坑和避坑技巧第一个坑是SQL执行环境不支持某些函数。有些笔试平台用的SQL引擎比较老对DATE_SUB这类函数的支持不到位或者要求必须写分号才能执行。我的建议是提前研究目标公司的笔试平台说明一般都会标明支持的SQL方言MySQL/PostgreSQL/Hive针对性准备会省很多麻烦。第二个坑是Python题的“中文路径乱码”。你本地跑得好好的一上传到笔试环境中文文件名或者中文列名就出问题。稳妥起见读取CSV时最好加上encodingutf-8必要时用enginepython规避分隔符问题。如果数据文件是Excel格式千万别用read_excel打开大文件很容易卡死。第三个坑是主观题没有“计算过程”。笔试平台一般要求你提交文字或直接在文本框里作答如果你只给了最终结论没有中间推导逻辑阅卷人没法看出你的思路是否严谨。建议将关键的计算公式或分析路径也写上去比如“用GMV下降量老用户流失贡献新用户降低贡献客单价变化贡献”一层层展开。第四个坑是过度关注技巧而忽略数据口径。很多时候一道题没有答好并不是你不会写代码而是你对业务口径不够敏感。比如播放时长是该算自然时间还是累计有效时间、新用户是看注册日期还是首次付费日期这些都是必须要先跟业务方确认的。笔试里没有确认环节所以你需要通过理解上下文来判断出题人的意图这也是大厂数据岗面试流行“给定义再解题”的原因。4.3 笔试后的复盘清单不管笔试结果如何考后复盘都是提升能力的关键环节。我每次笔完都会整理一个简单的复盘文档包括三块内容知识盲区哪些题是完全没有思路的对应补哪块知识点。比如“连续登录天数”这类题如果没做出来就把窗口函数的几种经典应用刷一遍。业务理解不足主观题里提到的业务指标比如完播率、续费率、用户体验指标是否理解到位。可以去网上搜一下相关产品的公开分享形成自己的业务分析框架。时间分配问题在哪个部分耗时过多下次如何调整策略。如果你总是卡在SQL细节上就说明SQL基础还不够扎实需要专项训练。准备腾讯音乐数据分析笔试的过程很像一次小型的项目复盘从指标定义到技术实现从数据清洗到业务归因每一步都在用数据思维解决商业问题。很多人在笔试前拼命刷机器学习模型推导结果发现实际考题根本没到那个深度反而是基础SQL和业务分析逻辑占据了大部分篇幅。方向对了努力才有意义。如果你正在准备下一场笔试建议把重心放在三件事上一是把窗口函数、留存计算、连续行为判断这类SQL场景题做到条件反射二是多读一些内容平台的数据分析案例理解完播、转化、付费这几个核心指标在不同业务场景下的定义变化三是动手写一份自己的业务分析模板遇到任何“指标下滑/上升”的题目都能快速套入“口径对齐—维度拆解—同期群验证—AB测试设计”的框架里。这样进了考场你的脑子才会比手快而不是被一堆题目追着跑。