企业官网建设流程全解析

先说一个结论：这套小红书2020校招数据分析笔试题，绝不只是考你会不会写SQL、知不知道几个统计公式。它更像是一道筛选器，把“能取数”和“能解决问题”的人分开。我拿这套题反复刷了三遍，越刷越觉得它代表了一批互联网公司数据分析校招题的典型风格：题目看似基础，但每一问都往业务底层逻辑上引。

这也是我把它当成教学样本的原因。无论你面的是内容社区、电商还是本地生活，这套题里的考察逻辑都通用，值得认真拆一遍。这篇文章，我会从出题人的视角还原这套题的考察点，用具体题目讲解题思路，最后再聊几个备考时最容易踩的坑。

1. 笔试整体设计与考察逻辑拆解

1.1 这不是考代码，是考业务落地能力

拿到卷子第一感受是：题目量不大，但每道题都有“身份”。比如一道SQL题，它不会让你单纯把两个表join起来，而是会写成“某内容社区用户每天登录一次，登录后产生的行为记录在另一张表，请计算最近7天活跃用户的次日留存率”。表面考join和date_diff，实际考你懂不懂“活跃用户”和“留存用户”的业务定义。

很多人在这一步就栽了。不是不会写SQL，而是不知道为什么要用count(distinct case when ...)而不是直接count(distinct user_id)。实际上，留存率的计算有两个隐含口径：分母是“某日活跃用户”，分子是“这些用户中次日仍活跃的人数”，这两个口径在SQL里如果不写成清晰的子查询，结果一定错。

我复盘下来的感受是：出题人默认你具备入门的工具能力，但更想知道你能不能把模糊的业务问题转化成可执行的取数逻辑。这套题刚好就是围绕这个底层逻辑设计的。

1.2 四个核心考察维度

整理卷面，四个维度最醒目：

这四个维度不是简单的知识考点，而是数据分析师日常工作的四类场景：接需求取数、看数据报告、做AB实验、支持决策。所以如果你只是为了“刷题”而刷题，收获会非常有限；你得把这些题当成一个个“小型项目”去推演，才能把这套题的价值吃透。

2. 核心题型解析与答题框架

2.1 SQL题：先讲清楚口径，再动手写代码

这套题的SQL部分，最典型的一题是涉及用户活跃和内容互动表的两表关联。我建议不管题目怎么变，都按三步来写：

1. 先定义口径：“活跃用户”是哪张表？去重键是什么？“次日留存”的时间窗口怎么算？如果是跨天凌晨，怎么处理？
2. 再搭框架：先用子查询算出“基准日活跃用户集合”，再关联“次日活跃集合”，最后聚合得到留存率。
3. 最后只写必要字段，别一上来就select *，既跑得慢，思路也不清晰。

拿一个简化版题目举例：表A记录了用户登录日志login_log(user_id, login_date)，表B记录了用户对内容的点赞记录like_log(user_id, like_date, content_id)。现在需要统计2020年6月每日活跃用户中，当天有过点赞行为的人数占比。

我当时写的参考答案是这样的：

with active as ( select distinct user_id, login_date from login_log where login_date between '2020-06-01' and '2020-06-30' ), liked as ( select distinct user_id, like_date from like_log where like_date between '2020-06-01' and '2020-06-30' ) select a.login_date, count(distinct a.user_id) as active_users, count(distinct if(l.user_id is not null, a.user_id, null)) as liked_users, count(distinct if(l.user_id is not null, a.user_id, null)) / count(distinct a.user_id) as liked_ratio from active a left join liked l on a.user_id = l.user_id and a.login_date = l.like_date group by a.login_date;

这里有个关键点：关联条件必须同时包含user_id和日期，不然会出现跨天错配。很多人只join user_id，结果把“历史点赞用户”误算进“当日点赞用户”，结论直接失真。

2.2 业务思维题：指标异动分析是必考题

问卷里有一道“某内容社区7日用户活跃数明显下降，请分析原因”的题。这是典型的指标异动分析，回答质量差距极大。差的回答一上来就说“可能是竞品上线了”“天气变差了”，全是猜测；好的回答会先确认数据是否真实，再拆维度，再提假设，再设计分析方案。

我常用的拆分框架是：

• 先看数据本身的准确性：是不是埋点漏了？是不是报表口径变了？是不是节假日/周末因素？
• 再拆维度：新老用户、渠道来源、设备类型、地区、内容品类。
• 再看行为路径：是新增少了？还是老用户回访少了？是登录环节流失，还是首页推荐点击率下降？
• 最后给验证方案：需要哪些数据来验证，下一步怎么查。

比如“新用户少了”，可以拆为新用户下载量、注册转化率、首刷内容消费情况。任何一个环节松动都可能影响活跃数，不能说“我觉得是投放少了”，要有数据佐证。

出题人看到能按这个流程展开的答案，哪怕最终的结论是“需要进一步排查”，也会认为你有分析框架，比直接给一个武断结论强很多。

2.3 概率统计题：掌握基础模型，别陷进复杂计算

概率统计部分，这套题考得不算偏，但很讲究“统计思维”。比如有一道题提到“抽奖活动的中奖率是1%，100个人参加，至少一人中奖的概率”，这题用1 - (0.99)^100算就行，约等于63.4%。看似简单，但很多人会凭直觉答“100%”或“1%”，说明对概率的乘法原理不够敏感。

再比如假设检验部分，我看到题目的倾向是：比起让你手算t值，更希望你能够解释p-value的含义、区别“统计显著”和“业务显著”。这种题就是提醒你，平时做AB实验不能只看p值，还要看效应量、置信区间、样本量是否足够。

实用建议：把二项分布、正态分布、条件概率、贝叶斯公式、假设检验这几块吃透，配合一些商业案例去理解。比如“先验概率”可以用推荐系统冷启动来解释：没有行为数据时，我们默认新品目的点击率接近类目平均，这就是先验；有了用户行为，后验概率会更新，这就是贝叶斯更新。把这个逻辑想通了，比硬背公式有用得多。

3. 拆一道典型题：留存率计算的完整推演

3.1 从SQL到业务口径的全流程

这套卷子里有一道留存题让我印象很深：给了用户注册表和登录表，要求计算注册用户次日、7日、30日留存率。很多人第一反应是直接对登录表做日期差，但注册表里有注册日期，两表关联时容易多算。

正确做法是：

1. 以注册表为主表，保留注册日期reg_date。
2. 去关联登录表，统计每个用户在注册后第N天是否有登录行为。
3. 用datediff(login_date, reg_date) = N判断是否构成N日留存。
4. 汇总得到retained_users / total_registered_users。

一段参考SQL如下：

with reg as ( select user_id, date(reg_time) as reg_date from user_register where date(reg_time) between '2020-05-01' and '2020-06-30' ), login as ( select user_id, date(login_time) as login_date from user_login where date(login_time) between '2020-05-01' and '2020-07-31' ) select r.reg_date, count(distinct r.user_id) as new_users, count(distinct if(datediff(l.login_date, r.reg_date) = 1, r.user_id, null)) as day1_retained, count(distinct if(datediff(l.login_date, r.reg_date) = 6, r.user_id, null)) as day7_retained, count(distinct if(datediff(l.login_date, r.reg_date) = 29, r.user_id, null)) as day30_retained, count(distinct if(datediff(l.login_date, r.reg_date) = 1, r.user_id, null)) / count(distinct r.user_id) as day1_retention_rate from reg r left join login l on r.user_id = l.user_id and l.login_date >= r.reg_date group by r.reg_date;

注意l.login_date >= r.reg_date这个条件，目的是防止把注册前的登录记录也算进去。这类细节最能体现一个数据分析师的基础扎实程度。

3.2 留存的业务解读比SQL更重要

SQL写出来只是第一步，面试官真正想看的是你对数字的解释。如果次日留存是40%、7日留存是20%、30日留存是10%，这个留存曲线说明什么？它说明用户首日体验还行，但一周内流失严重，产品激活和长期价值有提升空间。

这时候你就要能引出“激活漏斗”：注册后有没有完成关注、有没有刷到感兴趣内容、有没有产生互动。每一个环节都可能影响后续留存。

再看留存曲线形态：如果7日留存和30日留存差距不大，说明留下来的用户是相对忠诚的，核心问题可能出在新用户首次体验；如果曲线一直陡降，说明产品没有形成使用习惯，需要靠内容和通知机制来拉回用户。

这些分析在卷面可能只是一个小问，但把它答全了，面试官会认为你真的理解“留存”这个指标背后的产品含义，而不只是会跑数。

3.3 案例题：估算题的“量级感”是核心

估算题在这套卷子里也出现了，典型问法是“估算一个城市每月活跃的内容创作者数量”。这种题没有标准答案，考察的是量级感和拆解逻辑。

我记得当时是这么拆的：某城市常住人口约2000万，假设目标App渗透率20%，月活跃用户400万。创作者是活跃用户中的少数，假设5%的人每月至少发布一次内容，那么创作者约20万。再考虑创作者中更活跃的头部人群，比如每周发布一次的人大约占创作者总数的10%到20%，那么核心活跃创作者在2万到4万之间。

这个答案对不对不重要，重要的是你能不能在60秒内给出一个有理有据的数字区间。面试官最怕的是你支支吾吾说“我不太了解这个行业”，其实只要你敢拆、敢假设，哪怕结果偏了一倍，也能接受。关键是展示出逻辑链条。

4. 备考建议与常见问题排查

4.1 刷题时最容易踩的五个坑

我见过不少候选人刷题很努力，但效果很差，其实都踩了类似的坑。我把最常见的五个列出来，你对照一下自己有没有中招。

第一个坑是只刷题不总结框架。今天做一道留存题，明天做一道漏斗题，两道题看起来不一样，其实底层都是“按用户维度去重 + 时间窗口条件”。如果你能抽象出通用模板，后面遇到类似题就很快。我自己的做法是，每道SQL题做完后，再写出一个“通用版逻辑”，下次遇到同类型题目直接套。

第二个坑是忽略业务口径。比如“活跃用户”可以有多种定义：启动过App算活跃，还是有过浏览行为算活跃？不同公司定义不同。做笔试题时，题目没给出明确定义时，你要主动说明“我默认活跃用户是当天有启动行为的用户”，这既是严谨，也是向面试官展示你的业务意识。

第三个坑是统计题只记公式不理解原理。p-value < 0.05意味着什么？很多人说是“原假设为假的概率”，这表述不严谨。p-value是在原假设为真的前提下，观察到当前或更极端数据的概率。如果概念本身糊了，案例分析中的AB实验题肯定答不好。

第四个坑是案例分析没有结构化。不少人的答案像聊天记录，想到哪说到哪。建议用分层方式：目标拆解、数据获取、分析维度、验证方法、落地建议。哪怕结论不够漂亮，结构完整就很加分。

第五个坑是眼高手低，只看题不做题。数据分析笔试和面试，很多时候拼的是临场反应。你看一遍答案觉得“哇，明白了”，但关上答案自己写一遍，可能卡在下笔的第三行。所以一定亲手敲代码、亲手写出分析框架，而不是停留在“看懂”的层面。

4.2 面试官真正想看的答题习惯

从我身边做面试官的朋友那里听到的反馈是：他们一般不看候选人的“最终答案”有多完美，而是看中间有没有体现思考过程。比如SQL题里，你有没有先写注释说明逻辑？有没有处理空值？有没有考虑到数据去重？这些都反映出你平时写数据的习惯。

案例分析题也是一样，你能快速列出“待验证假设清单”比直接给一个结论更有价值。因为真实工作中，领导抛给你一个问题，你不可能立刻有答案，你需要的是一个可执行的探索路径。笔试时候你呈现这个路径，面试官就会认为你“能上手干活”。

还有一点很隐晦：卷面书写和代码格式。很多人觉得代码能跑就行，但面试官看卷面时，第一眼看到的是缩进、字段命名、可读性。你写一坨没有格式的SQL，即使逻辑对了，也会让面试官怀疑你的工程素养。建议平时就养成字段别名清晰、子查询分层的习惯，这不是形式主义，是真能减少出错率。

4.3 复习优先级与时间分配建议

如果你的目标是在未来两三个月内完成笔试类面试，时间分配可以按下面这个比例来：

• 30%给SQL练习，重点是窗口函数、多表join、留存漏斗类问题。
• 20%给业务分析框架整理，把常见的指标异动、产品功能评估、活动效果复盘各总结一套模板。
• 20%给概率统计基础，主要复习描述统计、假设检验、贝叶斯、常见分布。
• 15%给案例分析题，结合自己投递的公司业务做针对性练习。
• 15%留给自己复盘试卷和模拟考，不要一上来就海量刷题，而是做一套、复盘一套、沉淀一套。

这里尤其想说一下复盘的重要性。做完一套题，不要只看自己错在哪，而是把正确思路写下来，然后试着自己从零推导一遍。过两天再做一次，看能不能在更短时间内独立完成。这个过程虽然累，但能真正把“看会”变成“会做”。

5. 再补几个现场答题的小技巧

最后分享几个我实际做题时积累的小技巧。

第一，遇到任何指标题，先写出口径假设。就算题目已经给定了定义，你也别嫌多事，加一句“我这里按题目定义，活跃用户为当日有登录行为”，既避免歧义也向面试官展示你的专业习惯。

第二，遇到分析题，先画框架再填充。你可以在草稿纸上简单列一下：背景、目标、数据范围、分析方法、可能结论。这样回答时不会乱，也不会漏点。

第三，遇到不会的题，不要硬编数字。估算题可以往合理区间靠，但统计题如果你不知道某个公式，可以坦白说“这个点我目前掌握得不够，但我可以基于已有的知识给出我的推导思路”。面试官也是人，能理解“不会但会思考”和“不会又装懂”的区别。

第四，多选题和开放题，注意时间控制。笔试时间是有限的，不要一道题卡住就反复想，先把会做的做完，再回头啃难题。数据分析笔试的容错率并不高，会的题拿满，不会的题保基本分，是个不错的策略。

第五，心态上别把笔试当考试，当作一次模拟真实工作的推演。这种心态转换听起来有点虚，但确实管用。你把题目当成“leader临时丢来一个需求”来处理，思考方式就完全不一样了。

这套小红书2020校招数据分析笔试题，我建议你多刷两遍，每次都会有不同的收获。第一遍检验知识盲区，第二遍训练答题速度，第三遍重点打磨业务思维的表达。只要你能把一套题吃透，再去面对其他公司的笔试题，思路会清晰很多。