途虎养车数据分析笔试解析：SQL、Python与业务案例全攻略

说实话，看到“途虎养车2023秋招数据分析笔试试卷B”这个标题，很多准备秋招的同学第一反应是去找原题、背答案。但我的看法不太一样：既然是在准备数据分析岗的笔试，真正该练的不是某一道题的答案，而是这张卷子背后那套“业务题怎么拆、SQL怎么写、案例怎么答”的底层逻辑。特别是途虎这种产业互联网公司，它的笔试题往往带着很强的业务痕迹，考的不是你会多少个模型，而是你能不能把“门店订单为什么跌了”这种问题，翻译成一句一句可执行的SQL和一套有条理的分析框架。

这篇文章我打算从岗位定位、题型分布、SQL和Python的实战拆解、业务案例题的答题框架，再到最后的避坑清单，完整过一遍。不管你是第一次投数据分析岗，还是已经面了几家但总挂在笔试上，这篇内容应该都能帮你把准备思路理顺。尤其是后半部分那道汽车后市场风格的案例题，是我根据行业里真实工作场景还原的，很值得你花十分钟认真推演一遍。

1. 先搞清楚这张卷子考的是谁、为什么考

看任何一份笔试题，第一步不是急着找资料，而是先判断这家公司、这个岗位到底想要什么样的人。途虎养车的业务模式和纯互联网公司很不一样，这会直接决定整张卷子的出题倾向。

1.1 途虎的业务底色决定了出题风格

途虎养车本质上是汽车后市场的线上线下一体化平台，用户可以在App或小程序上买保养套餐、约门店、下单轮胎，然后到线下工场店去核销和履约。这意味着它的数据链路是“线上决策+线下交付”，比纯电商多了一层门店和供应链的数据。

我当年帮一个学弟复盘这套笔试时，第一件事就是让他去途虎的公开资料里翻业务结构。你会发现，数据分析岗在里面做的事，核心就几块：

• 订单分析：保养、轮胎、维修各个品类的订单量、客单价、渗透率；
• 门店运营分析：各工场店的产能利用率、技师人效、区域订单密度；
• 用户分析：新客获取成本、老客复购周期、会员生命周期价值；
• 供应链分析：库存周转、仓配时效、缺货率对订单的影响。

理解了这四条线，你就明白笔试题里为什么总是出现“门店”“保养套餐”“复购”“预约到店”这些场景词。它们不是随便给的背景，而是在考察你有没有能力把数据和业务场景对上。

1.2 一张秋招笔试卷的典型结构

根据近两年各家产业互联网公司数据分析岗的笔试习惯，再加上这份标题里“试卷B”的信息，可以合理推断整张卷子大概是这样的构成：

“试卷B”这个标签，我个人猜测有两种可能：一是途虎秋招分了技术类和非技术类两套卷，B卷针对的是偏业务方向的数据分析师；二是同一套岗位在不同批次使用了平行卷。不管是哪种，业务案例题的比重都不会低，这是产业互联网公司笔试的一个共性。

整体难度不是那种“算法题刷到吐”的风格，但非常考验你在限定时间内把业务问题结构化、再落地成代码的能力。很多人挂在笔试上，不是不会SQL，而是前15道选择题磨了太久，最后案例题只写了两行字。时间分配这件事，后面我单独展开说。

2. SQL是笔试的基本盘，先把这几类题练熟

不管热词里哪条是这个岗位的核心，只要出现“数据分析笔试”这几个字，SQL基本跑不掉。途虎这套卷子里的SQL题，风格上更接近我平时在业务分析群里看到的真实需求，而不是纯LeetCode式的技巧题。

2.1 汽车后市场场景下最高频的SQL考点

先说结论，产业互联网公司的SQL笔试题，翻来覆去就这几类：

• 聚合统计：按时间、门店、品类维度统计订单量、GMV、客单价；
• 留存计算：用户首次消费后第N天再次消费的比例；
• 漏斗转化：浏览套餐页到支付，再到线下核销的每一步转化率；
• 窗口函数：环比、累计、排名、每个门店TopN商品；
• 日期处理：DATE_SUB、DATE_FORMAT这类函数的使用。

其中最容易被低估的是漏斗转化。纯电商的漏斗到支付就结束了，但途虎还有“到店核销”这一步。如果笔试里给你一张预约表、一张核销表，让你算“预约到店的转化率”，千万别简化成订单表直接计算，要意识到线下履约环节才是这个业务的核心。

2.2 一道“门店维度KPI汇总”题解题全过程

我基于真实业务场景还原了一道很典型的题，你可以拿着练手：

现有订单表orders，字段包括：order_id（订单号）、user_id（用户ID）、store_id（门店ID）、order_time（下单时间，datetime）、pay_amount（实付金额，decimal）。品类字段category记录订单类型，包括“保养”“轮胎”“维修”。

请计算2023年1月每个门店的月度订单量、月度GMV、保养类订单占比，以及订单量的环比增速。

这道题考察的点非常综合，拆开来是四层：

第一层，最简单的聚合，按store_id分组，统计订单量和GMV。

第二层，条件聚合，占比要用SUM(CASE WHEN category='保养' THEN 1 ELSE 0 END)或者SUM(category='保养')来实现。

第三层，环比增速，这需要把2023年1月和2022年12月的数据都查出来，用窗口函数LAG来取上期值。

第四层，也是很多人容易忽略的，就是“1月怎么定义”。是下单时间在1月，还是支付时间在1月？业务上这就是指标口径问题。

一个参考写法是：

WITH monthly AS ( SELECT store_id, DATE_FORMAT(order_time, '%Y-%m') AS month, COUNT(DISTINCT order_id) AS order_cnt, SUM(pay_amount) AS gmv, SUM(CASE WHEN category = '保养' THEN 1 ELSE 0 END) / COUNT(DISTINCT order_id) AS maintenance_ratio FROM orders WHERE order_time >= '2022-12-01' AND order_time < '2023-02-01' GROUP BY store_id, DATE_FORMAT(order_time, '%Y-%m') ) SELECT store_id, month, order_cnt, gmv, maintenance_ratio, order_cnt / LAG(order_cnt) OVER (PARTITION BY store_id ORDER BY month) - 1 AS mom_growth FROM monthly WHERE month = '2023-01' ORDER BY gmv DESC;

这里有两个关键点值得说。一是窗口函数LAG的作用是按门店分区、按月排序后取上一个月的订单量，这就是环比增速的计算逻辑。二是为什么WHERE条件里要把2022年12月的数据也查出来再过滤，因为如果不先算上期值，LAG在1月这一行就是NULL，环比根本算不出来。

这道题如果满分10分，能写对group by和聚合的人大概有6分，能写出CASE WHEN条件聚合的能到8分，能想到窗口函数做环比的，基本就是这批人里的头部了。笔试的区分度就是这样拉开的，不是靠偏题怪题，而是靠在一个常见场景里把多个知识点串起来。

很多同学做这类题时有个坏习惯：上来就写SELECT，写到一半发现缺字段，又回去改。我的建议是先在草稿纸上把题目的计算逻辑拆成上面那四层，每一层需要哪些字段、最终表长什么样，列清楚了再动手写SQL。实际笔试中，这种做法比闷头写要快很多，也更能避免低级错误。

另一个容易翻车的点是GROUP BY和SELECT字段的一致性。你SELECT里出现的非聚合字段，必须出现在GROUP BY里或者被聚合函数包裹。这个规则看起来是基础，但在时间压力下特别容易忘。我见过太多人写完COUNT、SUM之后，又在SELECT里放了store_name这种没分组的字段，直接被判报错。

3. Python和Excel，数据处理基本功的分水岭

热词里反复出现Python数据分析、pandas、Excel数据处理这类关键词，映射到笔试里，就是Python题和Excel题。产业互联网公司的Python题很少让你手写机器学习算法，更常见的是给你几张业务表，让你用pandas完成合并、清洗、聚合和简单可视化。

3.1 用pandas做一份订单数据清洗

给你一个真实的场景：某个文件里存着门店的运营数据，里面有不少脏数据，比如门店ID前后有空格、时间字段是字符串、金额有负值或异常值。笔试会让你写代码把这些问题处理干净，然后按照指定维度聚合。

常规操作是这几步：

import pandas as pd df = pd.read_csv('store_orders.csv', dtype={'store_id': 'str'}) # 1. 门店ID清洗：去掉空格，统一大小写 df['store_id'] = df['store_id'].str.strip().str.upper() # 2. 时间字段解析 df['order_time'] = pd.to_datetime(df['order_time'], format='%Y-%m-%d %H:%M:%S') # 3. 剔除异常金额 df = df[(df['pay_amount'] > 0) & (df['pay_amount'] < 100000)] # 4. 去重 df = df.drop_duplicates(subset=['order_id']) # 5. 按门店和月份聚合 df['month'] = df['order_time'].dt.to_period('M') result = df.groupby(['store_id', 'month']).agg( order_cnt=('order_id', 'count'), gmv=('pay_amount', 'sum'), avg_price=('pay_amount', 'mean') ).reset_index()

每一步背后都有说头。用dtype参数指定store_id为字符串，是为了防止Excel里那种“门店ID被自动转成科学计数法”的问题，这在实际工作中很常见。时间字段用pd.to_datetime解析后，才能用dt.to_period做月份切片。金额过滤的阈值虽然看起来是拍脑袋，但这里考察的是你有没有“异常值处理”的意识，阈值本身可以讨论，完全不处理肯定是扣分的。

做完清洗后，如果笔试还要求画图，可以再用matplotlib或seaborn画个门店GMV排行，或者月度趋势线。这里不要求图多精美，关键是坐标轴标签清楚、标题明确、能看图说话。很多人在这一步栽跟头，不是不会画，而是画完之后不会解释图里的业务含义。

3.2 一道RFM用户分层实操题的讲解

RFM模型是用户运营里的经典框架，出现在数据分析笔试里的概率非常高。给定一张订单表，要求计算每个用户的R（最近一次消费距今天数）、F（消费频次）、M（累计消费金额），然后分层。

这种题考的不只是代码，更是你对业务含义的理解：

import datetime as dt snapshot = dt.date(2023, 3, 1) user_df = df.groupby('user_id').agg( last_order=('order_time', 'max'), order_cnt=('order_id', 'count'), total_amount=('pay_amount', 'sum') ).reset_index() user_df['R'] = (snapshot - user_df['last_order'].dt.date).dt.days # F和M的分位数打分 user_df['F_score'] = pd.qcut(user_df['order_cnt'], 4, labels=[1, 2, 3, 4]) user_df['M_score'] = pd.qcut(user_df['total_amount'], 4, labels=[1, 2, 3, 4])

这里有几个细节值得注意。snapshot日期是固定的，这是为了统一计算窗口，否则用户之间无法比较。pd.qcut是等频分箱，让每个分数段的人数相等，这样分层才不会被极端值带偏。分位数打分完成后，一般还会结合R、F、M三个维度把用户分成8类或更多类，比如“重要价值用户”“重要发展用户”“重要保持用户”等。

实际笔试里，代码本身可能只占一半分数，另一半看你能不能解释清楚：为什么要取四分位数而不是直接按绝对值划分？R低F高M高的用户应该怎么运营？如果你在答题里能写出“R代表流失风险，F代表忠诚度，M代表价值贡献”这类解释，整体印象分会明显不一样。

Excel在笔试中的考察方式通常更轻量，比如给一张数据透视表的需求，让你说明拖哪几个字段到行、列、值区域，或者直接用Excel公式实现某个计算。这套卷子既然用了“试卷B”这样的编号体系，大概率还是以SQL和Python为主，Excel更多是作为一种效率工具的补充。但你至少要知道VLOOKUP、SUMIFS、数据透视表这几个基本操作，万一选择题里考到，也不算意外。

4. 业务案例题，决定你能否进入下一轮

前面说的SQL和Python，其实大部分人准备两个月都能练到及格线。真正把面试者分出层次的，是最后那道业务案例大题。尤其是产业互联网公司，案例题往往不是让你写代码，而是给你一个真实的业务问题，让你给出完整的分析思路。

4.1 案例题的答题框架

我在给团队招人的时候，最怕看到一种回答：列了一堆可能原因，比如“可能价格高了”“可能竞对活动”“可能天气不好”，然后就没有然后了。这种回答确实覆盖了方向，但没有分析过程，等于没有分析。

一个合格的回答，应该分六步走：

1. 明确问题：先搞清楚要回答的问题是什么，以及当前指标是怎么定义的；
2. 搭建框架：把一个大问题拆成可量化的子问题；
3. 明确数据：针对每个子问题，需要哪些表、哪些字段；
4. 验证假设：用数据去验证，而不是拍脑袋给结论；
5. 给出结论：说明最可能的原因，并给出置信度判断；
6. 提出建议：给出可落地的下一步动作，并说明如何评估效果。

这六步不是套路，而是数据分析工作的真实流程。笔试案例题时间有限，你不可能全部展开，但至少要在答题里体现出这个链条是完整的。

4.2 一个“保养套餐转化率下降”案例的完整拆解

结合途虎的业务场景，还原一道很典型的案例题：

6月以来，“小保养套餐”（机油+机滤+工时）在App端的购买转化率从12%下降到8%，需要你分析原因并提出解决方案。

我会这样拆解：

第一步，先定义清楚“购买转化率”的口径。是曝光人数到支付人数的转化，还是加购到支付的转化？口径不统一，后面的分析全是空中楼阁。这里建议先确认当前报表里的定义，再进一步分析。

第二步，从维度拆解入手。至少要看时间趋势、渠道、用户类型、城市层级、车型这几个维度。这里不是所有维度都要列，但你要按“先看是不是整体现象，再看是哪个细分群体在恶化”的逻辑来组织。

第三步，把假设落到数据查询上。比如，如果是老用户转化率在降，就要去查老用户近期是不是收到了其他优惠券、或者到店预约名额变少了；如果是新用户转化率在降，更可能是流量结构变化，比如投放渠道变了、落地页加载变慢。再比如，如果下降集中在特定城市，就要看是不是这些城市的门店库存不足或预约排期过满，导致用户下单后无法选择合适的时间。

一个参考的分析框架是：

• 先看整体趋势是否真实：排除节假日、大促后回落等正常波动；
• 再拆维度：新客/老客、iOS/Android、不同城市等级；
• 后查漏斗：从套餐浏览页到支付页，每一步的流失率是否异常；
• 最后做归因：结合近期运营动作（价格调整、优惠策略、页面改版）来判断。

第四步，给出结论时要说清楚“最可能的原因”和“验证方法”。比如你判断主因是新客占比提升导致整体转化率被稀释，那验证方法就是拉出新老客各自的转化率对比，如果老客转化率平稳、新客转化率明显偏低，结论就成立。

这道题能拿高分的答案，往往不在于原因列得多全，而在于你能体现“从数据出发，而不是从观点出发”的思维习惯。面试官真正想看到的，是你接到一个模糊业务问题时，如何把它变成一个可量化、可验证的数据分析课题。

5. 备考节奏与现场避坑清单

讲完了具体模块，最后这部分是给准备阶段和笔试现场用的实操建议。这些内容不是我坐在书桌前想出来的，是这几年带人、参加校招评审，反复看到的成功和失败经验。

5.1 考前两周怎么准备

如果目标和时间都没问题，两周是一个比较合适的冲刺周期。我的建议是做三阶段安排。

前一周，把SQL窗口函数和聚合语法刷熟。不需要刷LeetCode那种hard题，重点练业务场景：分组聚合、日期函数、留存计算、漏斗计算。每天两道题足够，一题练聚合，一题练窗口。关键是要做到“看到一个需求描述，能很快翻译出需要哪几张表、怎么关联”。

中间三天，用pandas做两次完整的数据处理练习。找一份公开的业务数据集，自己设计清洗、聚合、分组对比三个任务，再用matplotlib画两三个图，最后用文字写出图表揭示的业务结论。这一步是模拟笔试里“代码和业务解释各占一半”的节奏。

最后两三天，集中看业务案例题。不用看太多，重点在“拆框架”。你可以拿途虎、本地生活、出行这些行业的公开案例，每次拿到问题先自己写框架，再对照参考答案，看自己漏了哪一类维度。案例题练的不是标准答案，而是思维习惯。

5.2 笔试现场最容易踩的坑

最后补一份避坑清单，这些坑我在实际评审里见过太多次了。

这里特别想强调最后那条时间分配。笔试不是高考，做题顺序并不重要，重要的是把该拿的分拿到。业务案例题分值最高，而且答个大概框架就能拿一半以上的分。如果你在前面选择题上磨蹭太久，案例题只能写两三行，那整张卷子的分就非常吃亏了。

我常跟人说，数据分析笔试考到后面，真正比的是取舍。你不需要每道题都完美，你只需要确保高价值题目拿到足够的分数。SQL题里的窗口函数如果真的想不起来怎么写，那就把group by的版本写出来，至少主体逻辑是对的。案例题就算时间不够，把“明确口径—拆维度—验证假设—给建议”这个骨架列出来，也能保住一半以上的分。

有一次我带一个学生模拟笔试，他SQL很强，但是案例题答得特别散，一会儿说价格，一会儿说天气，想到哪写到哪。我让他重新按框架组织，同样是那些内容，答案的观感完全不一样。这其实也解释了为什么案例分析题在笔试里占那么大比重：它考察的不仅是脑力，更是一种面对复杂问题时“能不能结构化输出”的职业素养。

如果你现在正要参加途虎或者其他产业互联网公司的数据分析岗笔试，我建议你拿到卷子的前两分钟，先把整张卷子翻一遍，给不同题型标记一个预期用时。这样做到后面才不会慌。另一个小技巧是，如果允许多写，案例题的每一步都可以先写标题再补充内容，即使最后没写完，阅卷人也能看出你有完整的分析意识。

最后再分享一点个人体会：笔试只是这个岗位的起点，它真正想验证的，是你有没有“把业务问题翻译成数据问题”的本能反应。SQL和pandas都可以短期突击，这种本能却需要反复在真实场景中打磨。即使这套卷子没通过，也不代表你不行，它只是在提醒你，下一次要多站在业务方的角度去理解题目背后的诉求。