先说结论这套笔试题比我想象中要“实”。整体不考死记硬背的概念题SQL、Python、统计概率和业务分析四条线穿插着来题量不算大但每一道题都带着明显的业务场景。如果只是刷题没做过真实项目有几个地方会比较吃亏。我当时拿到卷子的第一反应是掌阅这轮的笔试筛的不是“写过多少题”而是“能不能用数据解决阅读产品的问题”。下面按我的回忆顺序把这套题拆开揉碎讲一遍包括题型分布、每道题背后的考察意图、我当时怎么答的、哪些地方答得不好以及考完之后的复盘心得。这份复盘适合两类人一类是正在准备内容平台或App方向数据分析岗面试的另一类是已经拿了笔试通知、想提前知道掌阅笔试风格的朋友。1. 笔试整体情况与考察版图先说基本信息掌阅2025届春招数据分析岗笔试线上限时完成总时长大约90分钟共四大题型分别是SQL编程题、统计学/概率题、Python编程题以及一道开放的业务案例分析题。整体难度跟互联网大厂的标准校招笔试比属于中等偏上但它有一个很突出的特点——题目基本都挂在掌阅自身的业务场景上看书、听书、会员、付费章节、推荐曝光这些关键词反复出现。你要是对数字阅读行业完全没概念直接裸考会有点懵。具体题量分布大概是SQL两道每题约15分钟、统计概率三道每题约8分钟、Python两道其中一道综合性较强约20分钟、业务案例一大题约30分钟。时间分配上SQL和业务题是大头统计和Python题属于“会就会、不会想破头也没用”的类型。我自己的感受是这套卷子重点筛三样东西数据提取能力能不能用SQL准确算出一堆指标尤其是涉及留存、复购、漏斗这类多表关联的场景。统计推断基本功假设检验、贝叶斯、抽样误差这些不是考公式默写而是让你判断业务场景该用什么方法并说明理由。业务落地思维给你一个不那么完整的数据表或业务描述你能不能把它抽象成可量化的指标体系和归因框架。提醒一句笔试系统是可以在线运行代码的但环境里没有现成的数据集SQL题和Python题都是“给你表结构 几行示例数据你编写完整代码”。也就是说它更看重你写出来的代码逻辑是否清晰、是否考虑边界情况而不是跑出某个标准答案。2. SQL手撕题留存率、漏斗与埋点表的坑这套题的SQL部分算是全卷最“硬核”的模块。两道题都来自用户行为分析的真实场景而且表结构设计得比一般的刷题网站要复杂一些。2.1 第一题阅读用户7日留存计算题干大致是给定一张用户活跃记录表 user_active包含字段user_id, active_date, platform要求计算每位用户的“首次活跃日期”然后统计在首次活跃后的7天内第1天到第7天即自然日差异小于等于6且大于等于1再次活跃的人数占比。输出要求按首次活跃日期分组给出首日活跃人数、7日内回访人数、7日留存率。这道题考的是老生常谈的留存计算但它设了两个陷阱。第一个陷阱是“7日内”的定义。很多人会写成 datediff(active_date, first_date) 7这包含了当天的重复活跃导致计数虚高。正确做法是把 diff 控制在 1 到 6 之间或者写成 1 diff 7。第二个陷阱是首次活跃日期怎么算如果用户在同一天有多个平台的多条活跃记录直接 group by user_id 取 min(active_date) 没问题但你要是忘了去重后面 join 活跃表的时候会出现一对多的行数膨胀留存率直接算错。我的参考答案思路是这样with first_dates as ( select user_id, min(active_date) as first_date from user_active group by user_id ), base as ( select first_date, count(distinct user_id) as new_users from first_dates group by first_date ), retained as ( select a.first_date, count(distinct f.user_id) as retained_users from first_dates f join user_active a on f.user_id a.user_id and a.active_date between date_add(f.first_date, interval 1 day) and date_add(f.first_date, interval 6 day) group by a.first_date ) select b.first_date, b.new_users, r.retained_users, round(r.retained_users / b.new_users, 4) as retention_rate from base b left join retained r on b.first_date r.first_date order by b.first_date这里有个小细节用 count(distinct user_id) 而不是 count(user_id)。因为同一用户在一天内可能有多条活跃记录不去重会直接放大基数。另一个细节是 join 条件里用between date_add(...) and date_add(...)它比写成datediff(a.active_date, f.first_date) between 1 and 6在索引利用上更友好。笔试时如果你没有实际运行环境这俩写法都说得通但要给面试官留一个“我考虑过性能”的印象。2.2 第二题阅读/听书双场景漏斗分析这道题给了一张行为埋点表log_id, user_id, event_name, page_name, event_time和一张书籍信息表book_id, category, is_free, price要你统计某个月份内在“书籍详情页→开始试读→进入付费章”这条关键路径上的转化率并且按书籍分类展示同时标注各环节的流失人数。这道题的难点有两个。一个是事件流时序的判断——用户可能先看详情页、退出去、过几天又回来你怎么定义“一条漏斗路径”我当时说明限制在同一自然日内按 user_id 分组将 event_time 升序排列用 lead() 窗口函数把相邻事件拼在一起只保留“详情页后面紧接着是试读、试读后面是付费章”的连续路径。另一个难点是多张表关联后是否需要去重尤其是同一本书同一天被同一用户反复试读这会造成漏斗步骤间的计数错配。我当时的解题框架是with logs as ( select user_id, event_name, book_id, event_time, row_number() over (partition by user_id, date(event_time) order by event_time) as rn from user_event_log where event_name in (view_detail, start_try_read, enter_pay_chapter) and event_time 2025-03-01 and event_time 2025-04-01 ), step_path as ( select user_id, book_id, max(case when event_name view_detail then 1 else 0 end) as has_view, max(case when event_name start_try_read then 1 else 0 end) as has_try, max(case when event_name enter_pay_chapter then 1 else 0 end) as has_pay from logs group by user_id, book_id ) select case when has_view 1 and has_try 1 and has_pay 1 then 完整付费 when has_view 1 and has_try 1 then 试读未付费 when has_view 1 then 仅看详情 end as funnel_step_desc, count(distinct user_id) as user_cnt from step_path group by funnel_step_desc笔试当时我特别强调了“同日”限制和“同一本书”这个维度其实是在向阅卷人传递一个信号我清楚埋点数据有多脏不会拿原始数据直接一把梭。这类漏斗题在真实业务里非常常见但标准答案并不唯一关键是你的定义口径必须自洽。3. 统计概率与A/B实验概念不需要背但逻辑链要完整统计部分一共三道题题型跨度比较大从贝叶斯计算到假设检验再到模拟实验设计每一道都踩着数据分析师的核心能力线。3.1 贝叶斯新功能灰度放量的决策判断第一题是经典的“某功能灰度放量已知1%用户会主动反馈问题而在反馈问题的用户中80%确实是bug导致在未反馈用户中有5%也存在bug”。问现在随机抽到一个用户他确实遇到了bug但他没有主动反馈的概率是多少刚开始读题容易懵但它本质上是条件概率题。记A为“遇到bug”B为“主动反馈”。题干给了 P(B|A)0.8不要仔细读它是说“反馈问题的用户中80%确实是bug导致”这其实是 P(A|B)0.8而不是 P(B|A)。真正需要求的是 P(未反馈 | 遇到bug) 1 - P(B|A)。但P(B|A)并没有直接给题目给的是 P(A|B) 和总体的反馈率 P(B)1%以及 P(A|未反馈)5%。这时候要设一元方程设总用户数为N遇到bug但没有反馈的用户数为x遇到bug且反馈的用户数为y。由 P(A|B)0.8 知 y 0.8 * 1% * N 0.008N。又由未反馈用户中有5%存在bug知 x 0.05 * 99% * N 0.0495N。于是 P(有bug但未反馈) x / (x y) 0.0495 / (0.0495 0.008) ≈ 0.8609。也就是说遇到bug却没有反馈的用户比例高达86%这个结果其实在提示产品经理不要依赖用户主动反馈来判断bug影响面。我当时在答题框里把推导步骤写全了还额外补了一句“这个题在实际业务中提醒我们反馈用户只是冰山一角bug影响面的评估需要抽样检测而非只看工单量”。笔试这种开放性的补充其实能加分因为阅卷人知道你不是死记硬背。3.2 假设检验付费转化率下降的显著性判断第二题给了一个业务场景6月份付费章点击率是6.2%7月份做了改版后是6.0%要你判断这个下降是否显著并说明需要什么数据、用哪个检验方法。这道题没有给你样本量是开放性设问。我的回答是需要拿到两个月每日的付费章曝光量和点击量也就是分母分子然后建议用两比例的z检验two-proportion z-test因为它对二值数据点击/未点击很直接计算量小。如果端侧用户差异很大比如改版只在一部分用户中生效那应该改为A/B实验框架来做。我还补充了几个跟检验有效性相关的细节一是分母构成是否一致如果7月的曝光里新增了大量免费书城流量这些流量的用户付费意图弱会拉低整体点击率造成“辛普森悖论”式的假阴性二是要不要做连续性校正三是如果样本量很大即使0.2个百分点的差异也可能显著但商业上可能可忽略所以要算效应量。这个题其实考得挺深的它看你在拿到“不显著的下降”或“显著的下降”之后敢不敢对业务下结论。3.3 抽样方法与样本量估算要点第三题是关于抽样调查的当某书城的月活跃用户约2000万要做一个满意度调研希望置信水平95%抽样误差不超过±2%问至少需要多少样本另外还问如果想比较不同年龄段用户的满意度差异该用什么抽样方式。第一个问直接用样本量公式 n (z^2 * p * q) / e^2。p和q最保守取0.5z在95%置信水平下取1.96e取0.02算出 n ≈ 2401。如果考虑到有限总体修正因为抽样比很小结果基本还是2400出头。这个题我不光写了公式还备注了如果预估满意度在50%左右波动风险最大所以取0.5是最稳妥的。第二个问是分层抽样。我当时回答先把用户按年龄段分层再按各层人数比例分配样本量这样能保证每个年龄段的估计精度层内用简单随机抽样。我还加了一句如果某些年龄段用户占比特别小可以对该层做超额抽样数据分析时再用权重调整回来避免小年龄段样本太少导致子组分析不可用。这种细节往往是区分有没有真实做过调研的关键。4. Python实战题数据清洗与分组业务的综合性考察Python部分两道题一道是基础的数据清洗另一道是业务场景的综合性处理。这种题跟纯刷LeetCode不一样它不考算法复杂度考的是你用pandas处理不规整数据时的熟练度。4.1 数据清洗把所有脏数据的坑一次性踩完题目给了一张CSV文件模拟表包含阅读记录字段user_id, device_id, start_time, end_time, chapter_id, read_duration_sec, amount_paid。要求完成以下清洗任务删除 user_id 为空或全为空格的行将 start_time 和 end_time 统一为YYYY-MM-DD HH:MM:SS格式并将非法日期置为缺失read_duration_sec 为负数或超过24小时的视为异常值置为缺失对缺失的 read_duration_sec用该用户同设备的历史平均时长填充最终按 user_id chapter_id 去重保留 read_duration_sec 最大的记录每个小问都不难但组合在一起考了pandas的基本功、判断逻辑和边界意识。我当时写的核心片段是这样的import pandas as pd import numpy as np df pd.read_csv(read_log.csv) df[user_id] df[user_id].astype(str).str.strip() df df[df[user_id] ! ] df[start_time] pd.to_datetime(df[start_time], errorscoerce) df[end_time] pd.to_datetime(df[end_time], errorscoerce) df[read_duration_sec] pd.to_numeric(df[read_duration_sec], errorscoerce) df.loc[(df[read_duration_sec] 0) | (df[read_duration_sec] 86400), read_duration_sec] np.nan df[avg_duration] df.groupby([user_id, device_id])[read_duration_sec].transform(mean) df[read_duration_sec] df[read_duration_sec].fillna(df[avg_duration]) df df.sort_values(read_duration_sec, ascendingFalse).drop_duplicates( subset[user_id, chapter_id], keepfirst )这道题最值得注意的地方是填充策略。如果你的 fillna 逻辑和“按用户和设备分组求均值”绑在一起在缺失严重的用户组里用户自己的历史均值也是NaN这时真实业务中常见做法是用全局或类目均值兜底。我额外加了一步fillna(全局中位数)。面试官看到这种“兜底思路”会知道你处理过真实脏数据而不是只会调API。另外去重时用 sort_values drop_duplicates keepfirst 是惯用法但如果你想展示更强的窗口函数功底也可以写成df[row_num] df.groupby([user_id, chapter_id])[read_duration_sec].rank(methodfirst, ascendingFalse) df df[df[row_num] 1]笔试时写哪种都行关键是注释里说明逻辑让阅卷人看懂你的思路链。4.2 业务场景题给阅读时长做分层并分析付费转化第二题比较综合题干是有一张用户阅读行为表和一张付费表要求按用户总阅读时长将用户分为四层高活跃10小时、中活跃1-10小时、低活跃1小时以内、无阅读0小时。然后计算各层的付费人数占比。最后还要你说明这个分层的优点和可能的改进方向。这道题其实有两个层面。技术层面是pandas的分箱操作。我当时用了 pd.cut 和 pd.mergeimport pandas as pd read_df pd.read_csv(user_read_time.csv) pay_df pd.read_csv(user_pay.csv) read_df[total_hours] read_df.groupby(user_id)[read_duration_sec].sum() / 3600 bins [-1, 0, 1, 10, float(inf)] labels [无阅读, 低活跃, 中活跃, 高活跃] read_df[active_level] pd.cut(read_df[total_hours], binsbins, labelslabels) merged read_df.merge(pay_df, onuser_id, howleft) merged[is_paid] (~merged[pay_order_id].isna()).astype(int) result merged.groupby(active_level, observedTrue)[user_id].nunique().reset_index(nameuser_cnt) pay_cnt merged[merged[is_paid] 1].groupby(active_level, observedTrue)[user_id].nunique().reset_index(namepay_user_cnt) result result.merge(pay_cnt, onactive_level, howleft) result[pay_rate] result[pay_user_cnt] / result[user_cnt]业务层面才是这题的胜负手。阅读时长和付费意愿正相关但高活跃用户可能因为“一直在看书但不花钱”而拉低付费率因为阅读时长高本身说明他在大量使用免费内容。所以我在分析里又说了一句建议考察“时长分层之外是否应该叠加品类维度”比如高活跃但只看免费小说的用户和中等活跃但看出版书、知识付费的用户商业价值完全不同。这种跨维度的思考在笔试里很加分说明你不只会写代码还能基于业务逻辑提出改进方案。5. 业务案例题新书推荐位怎么评估和分析最后的大题是开放性案例分析掌阅App首页的小说推荐位进行了一次改版把原本按编辑推荐排序的“本月新书”模块改成“个性化推荐”上线一个月后需要你设计一套分析方案评估改版效果。这题非常经典几乎可以套用到任何内容产品上但要想答得出彩必须结合“阅读产品”的特点。我当时的回答分成了四个部分。5.1 确立北极星指标和辅助指标我没有一上来就写指标体系而是先提了一个前提推荐位改版的本质是优化“人与内容的匹配效率”所以核心指标应该同时看供给端和需求端。北极星指标我选的是“人均有效阅读时长”——理由是这个指标比点击率更能反映用户是否真正找到了想看的书因为小说和出版书的阅读周期长只有完整读下去才是真正的价值单纯的点击率很容易被标题党拉高。辅助指标我列了三个方向消费类模块点击率、人均曝光书籍数、封面点击率、试读转化率、付费章购买转化率留存类次日活跃率是否因首页变得更“对胃口”而提升内容丰富度新书的曝光集中度基尼系数避免推荐系统只推少数头部书5.2 实验设计与分组逻辑这个模块是必答项。我当时写道建议做层面上的分流实验用户进入实验之前按user_id取模分流避免同用户在不同端看到不同推荐逻辑造成体验割裂。对照组保留旧版编辑推荐实验组用个性化推荐观察期至少14天因为阅读行为不像电商有强烈的首日冲动新书的发现到深化阅读往往需要几天。如果时间允许还要做互斥和占比检验防止两组的用户在首页推荐位上互相污染。如果真的只能全量上线那就用断点回归或上线前后的同期对比但必须在报告里显著标注因果推断的局限。5.3 数据口径与潜在陷阱这个部分是我答这题时比较得意的地方因为一般的笔试题几乎不会主动让人去反思“指标本身可能骗人”。我在答题时写了三个坑点击率上升不代表体验变好可能只是推荐算法把用户吸引到了更猎奇的内容上但完读率显著下降。人均有效阅读时长上升也可能是用户沉浸在“无限流爽文”里付费转化却变差这时候要看会员续费率防止平台的长期价值被消耗。新书推荐位的“新书”定义要统一是上架30天内还是90天内否则对比组内的流量结构不同指标差异没有解释力。这个“指标失效”的视角我建议所有准备数据岗笔试的人都提前想一遍因为面试官后面追问的逻辑往往就藏在这些反例里。5.4 结论呈现方式最后一部分是输出层。我写的是用图表而不是大段文字做一张“实验前 vs 实验后”的核心指标对比表并标注置信区间和p值同时按用户新老、内容品类、性别年龄做分层拆解看看哪个群体贡献了主要提升如果实验组整体没有提升但在某一类用户上有显著改善那结论不是“放弃改版”而是“缩小应用到特定人群”。这种“不是非黑即白”的思维方式几乎每一个面试官都会认可。6. 复盘与准备建议从笔试到面试的衔接策略整套题答下来我的体感是它不追求题量而是每道题都给你大量空间去展示业务理解。如果你只是像刷LeetCode一样刷SQL和Python能过第一关但很难拿高分如果你的回答里带有“业务场景之外还考虑了什么”很容易跟其他人拉开差距。笔试后的几天里我认真做了个复盘总结了几个准备方向愿意分享给正在准备的朋友。6.1 SQL和Python的基本功是底线但不能只会“默写”这句话我反复想强调现在绝大对数校招笔试的SQL题已经不会给你纯粹的“订单表查询”了它会给你书城、小说、会员、章节、充值记录、阅读进度等多张表表之间关系复杂字段命名也未必规范。如果你不亲手搭建过一个小型数据库、塞进几万条模拟数据去练很容易在表关系上卡壳。我在笔试前一晚把经典的用户留存、复购间隔、RFM分层、连续登录天数这几类场景用SQL各写了一遍笔试时看到留存题基本不用想就能动手。Python部分同理不要只刷力扣用pandas把一份包含重复值、缺失值、异常日期、字符串格式混乱的CSV数据完整清洗一遍比你写一百道算法题都管用。具体地我建议练习这些场景重复值去重时保留哪一行、不同列的缺失值用不同策略填充、时间戳时区统一、长表和宽表的相互转换、分组后的排名和窗口偏移。6.2 统计知识要形成“业务条件反射”很多校招生的统计基础停留在“背公式”层面一碰到应用题就不知道用什么检验。我的经验是准备的时候不要只看课本要自己给自己出题比如“阅读时长提升0.5分钟能不能说明改版有效”“付费率下降0.3个点要不要立刻回滚”。常见的统计考点就是样本量估算、假设检验、置信区间、贝叶斯公式、回归模型的基本假设。你要能做到看到业务场景直接在3秒内判断该用z检验还是t检验样本是独立的还是配对的数据是比率还是均值。这种条件反射只能靠不断的场景化练习建立临时抱佛脚很难。6.3 作品集和业务案例比证书值钱笔试只是第一关如果能附上一份自己的分析报告——哪怕是自己在Kaggle或GitHub上做的一个内容平台用户分析项目——在面试时会有奇效。掌阅这种偏向阅读产品的公司非常看重你对内容生态的理解。我自己在笔试前做过一个小项目用公开的阅读App评论数据做情感分析和付费点挖掘这个项目在面试时被反复追问面试官很感兴趣甚至在追问过程中直接探讨了产品功能优化建议。这个经历让我深刻体会到作品集不是用来炫技的而是让面试官看见“你会怎样思考业务问题”。6.4 笔试现场的时间分配策略考场上最容易犯的错是“死磕某道题”。我自己在统计题的第二题想了太久导致后面Python题时间偏紧。复盘后我认为最合理的时间分配应该是拿到卷子先花2分钟通读全部题目把每道题的预估时间和难易度标出来然后按“熟悉题优先、分值大题次之、开放性题最后”的顺序来做。像业务案例题它最不值得一上来就写长篇大论因为它的产出是思路不是代码可以留到后面梳理清楚再答。如果时间不够用5W2H框架答一个精简版也比直接空白强很多。6.5 一份能直接用的问题排查清单我还整理了一份笔试和面试过程中经常遇到的问题清单纯属个人经验整理可以按图索骥自查问题类型典型表现排查思路SQL结果与预期不符留存率虚高检查是否漏掉当天去重、分组维度是否多余、join是否放大行数Python运行报错pandas类型转换失败先打印dtypes用pd.to_datetime加errorscoerce兜底统计检验选择模糊不知道是用z检验还是卡方检验看变量是均值、比率还是频数先判断数据类型再选工具业务指标异常点击率涨了但付费跌了分层看流量结构变化警惕辛普森悖论时间分配失控最后大题草草收尾提前规划好每题时间按分值决定投入7. 一点个人感受笔试不只是做题而是职业思维的同频测试这套卷子做完后我最大的感受是掌阅的数据分析笔试其实是在找能与业务一起思考的人。它不需要你背出多么高深的算法公式也不需要你掌握多复杂的机器学习模型但你必须理解一个阅读产品是怎样运转的——用户为什么要打开它、为什么愿意为某一章付费、什么样的人会连续几十天读书、什么样的内容注定推了也没人看。只要你的思维能贴着这些真实业务走答题就会顺很多。最后再分享一个小技巧笔试前哪怕只有半小时也去把掌阅App打开关注书城首页的推荐位、阅读结束后的挽留弹窗、会员开通入口的位置。这些细节不一定会出现在卷子上但它们会在你答题时变成一种直觉让你在面对业务案例时自然而然地提到“这个模块的下一步分析应该看什么”。这种贴近产品的体感是任何刷题都替代不了的。