企业官网建设流程全解析

每年春招季总有那么几场笔试让人印象特别深，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%，样本量为10000，p值=0.04，下列哪个结论是正确的？”选项里有一条很迷惑的表述是“该策略有96%的概率是有效的”。这个表述是错的，p值不等于策略有效的后验概率。p=0.04只说明在原假设成立时，观察到当前或更极端数据的概率是4%，不能直接推出策略有效的概率是96%。

正确的叙事方式应该是：“在显著性水平0.05下，有统计学证据表明新策略的点击率不等于旧策略。”至于效果量有多大、值不值得全量上线，还要看置信区间和业务成本。

如果你在主观题里遇到“设计一个AB测试评估新推荐策略效果”，一个合格的回答至少包含四步：

1. 明确核心指标和辅助指标。核心指标可以是人均播放时长或次日留存；辅助指标包括点击率、完播率、分享率。
2. 计算最小样本量。给定基线转化率p1=8%，最小检测提升10%，显著性水平0.05，统计功效0.8，利用公式n = (Z_alpha/2 + Z_beta)^2 * 2p(1-p) / delta^2，算出每组约需要多少用户。
3. 分组方式和实验周期。建议按user_id哈希分桶，避免同一用户在不同端看到不同策略；实验期至少覆盖一周，包含一个完整周末。
4. 分析阶段用双样本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时最好加上encoding='utf-8'，必要时用engine='python'规避分隔符问题。如果数据文件是Excel格式，千万别用read_excel打开大文件，很容易卡死。

第三个坑是主观题没有“计算过程”。笔试平台一般要求你提交文字或直接在文本框里作答，如果你只给了最终结论，没有中间推导逻辑，阅卷人没法看出你的思路是否严谨。建议将关键的计算公式或分析路径也写上去，比如“用GMV下降量=老用户流失贡献+新用户降低贡献+客单价变化贡献”一层层展开。

第四个坑是过度关注技巧而忽略数据口径。很多时候，一道题没有答好并不是你不会写代码，而是你对业务口径不够敏感。比如播放时长是该算自然时间还是累计有效时间、新用户是看注册日期还是首次付费日期，这些都是必须要先跟业务方确认的。笔试里没有确认环节，所以你需要通过理解上下文来判断出题人的意图，这也是大厂数据岗面试流行“给定义再解题”的原因。

4.3 笔试后的复盘清单

不管笔试结果如何，考后复盘都是提升能力的关键环节。我每次笔完都会整理一个简单的复盘文档，包括三块内容：

• 知识盲区：哪些题是完全没有思路的，对应补哪块知识点。比如“连续登录天数”这类题如果没做出来，就把窗口函数的几种经典应用刷一遍。
• 业务理解不足：主观题里提到的业务指标，比如完播率、续费率、用户体验指标，是否理解到位。可以去网上搜一下相关产品的公开分享，形成自己的业务分析框架。
• 时间分配问题：在哪个部分耗时过多，下次如何调整策略。如果你总是卡在SQL细节上，就说明SQL基础还不够扎实，需要专项训练。

准备腾讯音乐数据分析笔试的过程，很像一次小型的项目复盘：从指标定义到技术实现，从数据清洗到业务归因，每一步都在用数据思维解决商业问题。很多人在笔试前拼命刷机器学习模型推导，结果发现实际考题根本没到那个深度，反而是基础SQL和业务分析逻辑占据了大部分篇幅。方向对了，努力才有意义。

如果你正在准备下一场笔试，建议把重心放在三件事上：一是把窗口函数、留存计算、连续行为判断这类SQL场景题做到条件反射；二是多读一些内容平台的数据分析案例，理解完播、转化、付费这几个核心指标在不同业务场景下的定义变化；三是动手写一份自己的业务分析模板，遇到任何“指标下滑/上升”的题目，都能快速套入“口径对齐—维度拆解—同期群验证—AB测试设计”的框架里。这样进了考场，你的脑子才会比手快，而不是被一堆题目追着跑。