企业官网建设流程全解析

作为参加过2020年那波校招的老学长，现在回头看小红书这套数据分析笔试题卷一，还是很有感触。当时互联网大厂的数据分析岗还远没有现在这么卷，但小红书这套卷子已经出得相当有水平，既考基本功，也考业务sense，到现在依然有很强的参考价值。

我印象最深的是，这套卷子没有堆砌那种"茴字的四种写法"式的偏题怪题，而是把真实业务场景拆成了一道道考题。你如果只看书不刷题、只知道概念不会算数，基本会做得很难受。但如果平时有认真做过业务分析、写过SQL、跑过实验，又会觉得每个题都似曾相识。

这篇文章我不打算只贴答案，而是想从"这套题到底想考察什么"出发，把卷子里的SQL题、统计概率题、业务case题逐类拆开讲透，顺带把我当年踩过的坑和后来的复盘思考都整理出来。不管你是正在准备校招，还是想转行做数据分析，这份拆解应该都能帮你在备考时少走很多弯路。

1. 笔试题的整体设计与考察逻辑

1.1 小红书想要什么样的数据分析师

分析2020年这套笔试题，不能只看题目本身，要先搞清楚小红书作为一个内容社区，对数据分析师的能力预期到底是什么。小红书的业务核心是内容生产和消费，背后牵扯到推荐算法、社区治理、广告变现、电商闭环等多条线。数据团队并不是单纯地跑数，而是需要能深入理解内容生态和数据指标之间的因果关系。

从卷子能明显看出来，小红书要的不是纯统计背景的"书呆子"，也不是只会写SQL的"取数机"，而是能同时理解业务语言和技术语言的人。这导向了三个层面：业务上懂社区产品的核心指标，技术上能熟练处理用户行为数据，方法上懂AB实验和因果推断的基本逻辑。

所以卷一里SQL题占大头，因为它是最朴素的取数能力体现；统计题紧跟其后，因为实验评估是互联网决策的根基；业务开放题压轴，因为高阶分析师的价值恰恰在于从数据波动中定位业务问题。

整套卷子难度梯度也设置得比较合理。前几题是送分的基础查询，中间是窗口函数和留存计算这类进阶SQL，后面就是概率计算和开放业务题。你如果从头做到尾，会感觉是在模拟一个从"取数"到"分析"再到"给建议"的完整工作流。

1.2 题型分布与题量节奏

一套线上笔试通常会有8到12道题，限时90到120分钟。按我当时的经验，卷面结构一般可以划分为四个模块：SQL与数据查询、统计概率与AB实验、业务分析与case题、以及少量Python/Excel实操题。

各模块的权重也反映出岗位的侧重方向。SQL基本功占比最高，大概在30%到40%之间；统计概率其次，约25%到30%；业务分析题约20%到25%；工具实操和开放题占剩余部分。这样的设置是在考察"一个初级数据分析师入职后能不能快速上手干活"，因为入职前半年做的最多的事，就是写SQL、看数、帮业务方做复盘。

时间分配上，这里有个我特别想提醒的坑。大多数人会按顺序从前做到后，结果在中等难度的SQL题上死磕太久，导致最后的大题只剩十几分钟。我的建议是拿到卷子先花3到5分钟快速浏览全部题目，把业务case题的思路关键词先写在草稿纸上，然后按"先易后难"的顺序做题，把能拿的分先稳稳拿到手。

2. 高频考点与核心知识点解析

2.1 SQL：内容平台的"查数"基本功

小红书这套卷子里的SQL题，场景基本都是围绕内容社区展开的。典型场景包括：统计社区某天的发帖量、计算用户的次日留存率、找出连续活跃N天的用户、分析某个话题页的曝光到互动的转化漏斗。

这些场景看起来简单，但每道题背后都有一个关键的知识点，而其中最核心的就是窗口函数。比如计算"每个用户最后一次访问的页面"，常规group by之后你会发现拿不到访问时间对应的页面信息，这时候就要用row_number()配合partition by来实现。还有"每个话题下互动量排名前3的内容"，同样依赖rank或dense_rank这类窗口函数。

我建议备考时把窗口函数的用法练到条件反射的程度，特别是这几类：row_number()用于编号、rank()和dense_rank()用于排名、lag()和lead()用于取前后行、sum() over ()用于计算累计值。笔试中只要出现分组排序和连续性问题，八成都要用到它们。

另一个必考重点是去重。很多同学刚学SQL的时候会用count(user_id)去统计用户数，但这在行为日志表里是大忌，因为同一个用户可能有多条记录。正确做法是count(distinct user_id)。而另一个容易错的地方是count(字段)和count()的区别。count()统计的是行数，count(字段)则会自动跳过null值，这两个结果在字段为null的时候会不一样，踩过一次就很难忘。

2.2 统计概率：绕不开的AB实验思维

统计概率题在小红书的笔试里不只是算概率，而是几乎全部指向实验设计和效果评估。这也符合互联网公司的实际情况，改个推荐策略、换个交互样式，都需要通过AB实验来验证效果，数据分析师就是实验的设计者和评估者。

这里的高频考点集中在几个方向：假设检验的基本流程、p值和置信区间的解读、第一类错误与第二类错误的区别、样本量的估算，以及辛普森悖论这种容易迷惑人的反直觉问题。

特别是第一类错误和第二类错误，笔试里很喜欢用业务场景来考。比如"我们要上线一个新功能，你更担心把没效果的功能误判为有效，还是把有效的功能误判为无效"。前者是第一类错误，会浪费研发资源去做一个假效果；后者是第二类错误，会错过一个真实增益。不同业务阶段对两类错误的容忍度不同，这就要结合业务成本去回答，不能只背定义。

还有一类容易被忽视的考点是辛普森悖论。它说的是：整体趋势和分组趋势不一致的现象。笔试题可能会这样出：某推荐策略改动后，整体点击率上升了，但分设备类型看，iOS和安卓的点击率都下降了，请问这是怎么回事？答案核心在于样本结构发生了变化，新策略让低点击率设备（或低点击率时段）的流量占比大幅提升，从而拉高了整体均值。这种题考的就是你有没有对数据进行分层观察的意识。

2.3 业务思维题：从数据到决策的临门一脚

业务开放题是最能拉开分数差距的部分。它没有唯一答案，但阅卷人能从你的回答里看出，你是只会算数的工具人，还是真的理解业务的数据分析师。

以小某书这样的内容社区为例，业务题通常会围绕几个主题来出：社区核心指标体系怎么搭建、某个指标突然波动怎么归因、一次运营活动怎么评估效果、要不要对某个用户群体做激励。这些题目的共同点是：需要你把一个模糊的业务问题转化成可以度量的数据问题。

我发现很多同学在回答这类题时，最大的问题是"只给结论，不给过程"。比如问"DAU下降了怎么分析"，有的人会直接说"可能是因为竞品上线了新功能"。这种答案没用，因为没有任何数据支撑。正确做法是把问题层层拆解，给出可验证的假设和对应的数据指标，最后落到明确的下一步动作。

一个比较好用的答题框架是：先定义问题、确认口径，再拆解指标、定位异常，然后提出假设、用数据验证，最后给出建议并设计监控方案。笔试题只要遵循这个框架，就算数据假设不够精准，框架的完整性也会给你带来可观的分数。

3. 典型真题实操拆解

3.1 一道SQL题：计算连续活跃天数

连续活跃类题目在各大厂笔试里出现频率高到什么程度呢，几乎可以当成必考题来准备。题目通常会这样描述：给定用户登录表user_login，字段为user_id和login_date，请统计连续活跃3天及以上的用户数。

这个题的经典解法我直接写出来。思路是利用"日期减去行号"的分组技巧：如果用户在某段时间内连续登录，那么login_date减去一个递增的行号后，得到的分组日期是相同的。核心SQL如下：

-- 先对每个用户的登录日期去重排序 with tmp as ( select user_id, login_date, row_number() over (partition by user_id order by login_date) as rn from ( select distinct user_id, login_date from user_login ) t ) -- 用日期减行号得到分组标记，统计组内天数 select user_id, date_sub(login_date, interval rn day) as group_id, count(*) as active_days from tmp group by user_id, date_sub(login_date, interval rn day) having count(*) >= 3;

这里有个特别容易踩的坑，就是登录表里可能出现同一天多条登录记录。如果你不去重就直接做row_number排序，同一个日期会被编成多个行号，导致本来连续的日期被错位拆开，结果就会算错。所以最稳妥的做法是先对(user_id, login_date)做distinct，再进入后续计算。

如果笔试里没有要求你写出完整SQL，而是给了一个结果表让你判断是否正确，那你也要留心连续活跃的定义。是"连续3天每天都有登录"，还是"3天内累计登录3天"，这两个口径如果没定义清楚，写出来的答案完全不一样。遇到这类题，先跟自己确认口径永远是第一优先级。

3.2 一道业务题：DAU环比下降的归因分析

这类case题几乎每场笔试都会出现，只是包装不同。我见过很多版本的问法，比如"某内容社区DAU环比下降5%，请给出归因分析思路"。回答的好坏很能体现分析功底。

我在笔试里给出的回答思路是这样的。第一步，先确认数据的真实性，不要上来就分析业务波动。要检查是否有数据上报延迟、埋点变更、口径调整，排除数据本身的问题，这是很多新手容易忽略的一步。

第二步，做指标拆解。DAU可以拆成新用户和老用户两部分，老用户又可以分为回流用户和留存用户。环比下降5%到底是新用户减少导致的，还是老用户流失加剧导致的，要先分清楚。进一步还可以拆到端（iOS/Android）、版本、渠道去定位下降的主要群体。

第三步，结合已知业务动作和外部环境提假设。比如近期是否上线了新的推荐策略、是否调整了推送频次、是否遇到了竞品的强运营活动、是否是节假日或开学季等周期性波动。每个假设都对应着可验证的数据指标。

第四步，落到行动建议。比如，如果定位到是新用户次留下降，就要进一步看新用户的注册流程、首刷内容质量、关注的博主数量等；如果是老用户流失，就要看高价值用户的流失预警和召回策略。这样整个回答就是完整的、可执行的，而不只是停留在"可能是什么原因"的层面。

3.3 一道概率统计题：AB实验的样本量估算

假设检验和样本量估算在笔试中出现很频繁，以一道常见的题为例：某个按钮的点击率基线是10%，想通过实验检测出1个百分点的提升，在显著性水平0.05、统计功效80%的条件下，每个分组大概需要多少样本量？

样本量估算公式可以写成：

n = ((Zα/2 + Zβ)^2 * p * (1 - p)) / (p1 - p0)^2

其中p0是基线转化率0.10，p1是预期转化率0.11，所以分母就是0.01的平方，即0.0001。Zα/2在双侧0.05显著性水平下约为1.96，Zβ在80%功效下约为0.84，所以分子约为(2.8)² x 0.10 x 0.90。

算出来大约是7.056除以0.0001，等于70560人。考虑到AA分组和可能存在的样本波动，实际投放时通常会再加10%到20%的余量。

这个计算过程看似复杂，但笔试考的核心不是你的算术能力，而是你有没有样本量估算的概念。很多同学在回答时只会背公式，却在解读结果时翻车。要记住，样本量越少，实验越难检测出小提升；如果想要检测更小的提升幅度，样本量就需要大幅增加，这也是为什么很多产品实验都跑不满预期效果的原因之一。

3.4 一道实操题：用Excel快速完成数据检查

不要觉得Excel题简单，它考查的其实是指标口径理解和数据敏感度。这类题通常会给出一个内容数据明细表，字段包括笔记ID、曝光量、点击量、点赞量、收藏量、评论量，然后要求计算"点击率"和"互动率"。

这里最大的坑就是口径陷阱。点击率的分子是用点击量还是点击用户数，分母是用曝光量还是曝光用户数，不同口径算出来的数字差异很大。做内容平台的数据分析师，一定先明确：曝光是次数还是人数，点击是去重用户数还是总点击次数。如果题目没说明，就要主动假设并注明，这也是在考察你能不能独立处理工作中的口径模糊问题。

实操上，Excel数据透视表是处理这类题目最顺手的工具，拖拽几下就能算完。如果你熟悉pandas，用groupby也能快速验证结果。笔试中往往时间紧张，我建议熟练掌握其中一种工具即可，不必在多个工具间反复切换浪费时间。

4. 常见失分点与避坑清单

4.1 三个最冤的失分点

回顾我当年和身边同学做笔试的情况，发现失分最可惜的往往不是不会做的题，而是会做但没做对的题。第一个高频失分点是忽略题目中的业务限定条件。比如题干说"只要注册超过30天的用户"，结果SQL里没有写这个过滤条件，整个统计口径就错了。

第二个失分点是对null值的处理不当。很多人会理所当然地认为count(user_id)就能统计出所有用户，但当user_id为空时计数结果与count(*)会不一致；同样地，用left join关联表之后，右表字段也会出现null，如果不处理就直接参与计算，结果会偏差得很离谱。

第三个失分点，也是最常见的，是业务题只写结论不写分析过程。笔试的阅卷规则大多是按点给分，你多写一个合理的假设就多一分希望。空泛地说"要提升内容质量"，不如具体到"建议观察新品类的供给量变化对完播率的影响"。数据分析师最重要的能力就是"让结论变得可验证"，这个思维从笔试开始就要建立。

4.2 答题节奏与检查策略

笔试题量大且时间紧，很多人在考场上会慌，一慌就容易在细节上翻车。我自己后来的答题策略是严格的三轮法。第一轮，快速扫题，先把所有确定能做的题写完，不纠结格式，核心结果写出来就好。第二轮，回头处理略有把握但需要思考的题，这类题往往是窗口函数题和应用型统计题。第三轮，重点攻坚最难的开放题和没做出来的题，这时候哪怕只能写出思路框架也要写上，因为开放题按点给分，有一定框架就比空白卷好很多。

检查环节同样重要，但不要全面重做，而是重点检查几个容易出错的地方：SQL里的条件字段是否写全，group by字段是否与select中的非聚合字段一致，去重逻辑是否考虑到了null，以及公式计算中的单位是否统一。这些细节只要多花三分钟检查一遍，就能挽回很多不必要的失分。

4.3 容易被忽视的细节

笔试中的一些细节往往决定成败。SQL题中，日期边界是最容易被忽视的。如果统计的是当天的数据，要明确login_date是date类型还是datetime类型。如果你用login_date between '2020-01-01' and '2020-01-02'，这会把1月2日当天凌晨的数据也包含进来，得到错误结果。datetime类型应该用>= '2020-01-01' and < '2020-01-02'这样的左闭右开区间。

统计题里，写完p值计算后记得写结论，比如"p值小于0.05，拒绝原假设，说明改动有统计显著性"。很多同学算完就停了，漏掉结论而白白丢分。case题中，列指标时不要只写一个指标名称，还要说明为什么要看这个指标，它在整个业务逻辑里能说明什么问题。这个"所以呢"的追问，是数据分析师和取数工最本质的区别。

5. 从一套笔试题延伸到工作能力与备考方法

5.1 笔试复盘对后续面试和工作的启发

有些人觉得笔试只是入职的敲门砖，过了就完了。但后来我进了互联网公司做数据分析，再回头看这套卷子，才明白笔试题目设计其实是工作场景的高度浓缩。SQL题的背后是日常取数和报表开发，统计题的背后是每天要做的实验评估，业务题的背后是周报月报里的指标异动归因。

所以备考笔试的过程，本质上是提前演练未来的工作方式。我建议不要只满足于做对题，而是在每次刷完题后追问三个问题：这个题对应什么业务场景？如果数据出现异常我会怎么排查？我要向业务方输出什么结论和建议？养成这种思考习惯之后，不管是笔试的开放题还是面试的case面，你都会比那些只会背题库的人从容很多。

5.2 备考时间线与训练建议

如果你从零开始准备数据分析岗笔试，我给一个三个月的大致规划。第一个月打基础，集中在SQL和统计学，SQL要刷完窗口函数、多表关联、去重与聚合这几大板块；统计学重点放在描述统计、假设检验、置信区间和AB实验设计。第二个月做专项练习，开始刷业务case题，每天拆解一个常见的业务问题，比如留存下降、转化率低、活动效果不明显，把它写成结构化的分析思路。第三个月进入模拟冲刺，严格按照考试时间做整套模拟卷，训练答题节奏。

工具方面不用贪多。SQL就用你最顺手的MySQL或Hive语法练习，Python重点掌握pandas的数据清洗和聚合操作，Excel会数据透视表和常用函数就够了。我在实际笔试中最常使用的还是SQL加Excel的组合，Python更多是处理更复杂的数据清洗和建模场景时才用得上。

案例分析方面，平时可以多读一些行业分析报告和公开的数据复盘文章，注意观察别人是如何拆解问题的。比如看一个内容平台的月报，不要只记数字，而要思考它为什么选择这些指标，这些指标之间有什么勾稽关系，如果其中某一个突然变化，会牵动哪些其他指标。这种刻意练习对提升业务感很有帮助。

5.3 笔试中值得长期保留的好习惯

最后分享几个我后来一直保留的习惯。第一个习惯是任何分析项目都先写口径说明，把自己的假设和指标定义放在最前面，避免后面分析跑偏。第二个习惯是每做一个case，最后都要落到一个具体的"建议动作"，哪怕这个动作只是"建议增加一个新的监控指标"，也要比空泛的"继续观察"好得多。

第三个习惯是维护一份错题本。我把所有笔试和练习中做错的题按类型归档，比如SQL类型、统计类型、业务逻辑类型，并标注错误原因。这个习惯帮我避开了很多重复踩坑，准备面试时也很有用，翻一遍错题本就能快速回顾自己的薄弱点。

从我后来参与校招简历筛选和面试的经验看，笔试成绩确实是进入面试的重要参考，但它考察的远不只是"会不会做题"，而是你有没有结构化思考问题的能力。如果你正在准备校招或转行数据分析，建议不要迷信"刷完几百道题就能过"，把心态放平，重点放在理解题目背后的业务逻辑和提升自己的分析框架上，一套题吃透，好过十套题囫囵吞枣。