企业官网建设流程全解析

讲个挺反直觉的事：游戏公司招BI工程师，笔试里几乎不考BI工具操作，考的全是SQL、业务口径和案例分析。我拿到这份搜狐畅游2019校招BI工程师笔试题时第一反应是"怎么没有Power BI实操题"，后来做完才明白，工具这东西入职一周就能学会，但数据思维、业务理解、代码功底，才是校招阶段最难补的短板。

这篇内容主要面向两类人：正在准备BI工程师或数据分析师校招的同学，想了解游戏行业数据岗位笔试风格的人。我会按当年这份笔试题的类型分布，把SQL题、指标体系题、可视化工具题和开放分析题的备考逻辑拆开讲清楚，顺带把Power BI连接MySQL时Import和DirectQuery的区别、帆软BI考试的学习路径、以及那道让很多人意外的"C#实现"题一起复盘。

1. 游戏公司招BI工程师，笔试到底想筛什么样的人

1.1 游戏业务里的BI岗位画像：不是报表员

很多同学对BI工程师的理解停留在"做报表的"，这个认知在校招笔试里会吃大亏。游戏公司的BI团队，核心职责是把游戏里的埋点数据、服务器日志、付费流水，转化成运营和策划能直接做决策的结论。说白了，BI工程师是"带着业务问题的数据库专家加可视化工程师"。

搜狐畅游这种做端游和手游发家的公司，业务线很长，从游戏研发到发行、运营都有数据需求。BI工程师日常工作大概是这几类：

• 每日核心KPI看板维护，DAU、留存、付费收入往下钻到各渠道、各服务器、各版本
• 版本更新或活动上线后的效果复盘，比如新英雄上线后玩家付费率有没有变化
• 异常数据排查，比如某渠道新增用户暴涨，是买量作弊还是自然增量
• 临时取数需求，运营一句话，你就要写SQL从几亿行日志里把数捞出来

所以笔试考察的不是"你会不会用某个BI工具"，而是三件事：第一，能不能用SQL从大数据里准确取出数据；第二，能不能用正确的业务口径把数据算成指标；第三，能不能用可视化工具或代码把结论清楚地表达出来。这正好对应一份BI报表从数据到决策的完整链路。

1.2 四类题型的考察逻辑

从当年那场笔试来看，题型分布大致是这样的：

这里有个容易被忽视的细节：笔试题目里出现"C#实现"这类要求，并不是要你做一个完整的系统，而是考察编程基础和逻辑思维。BI工程师虽然平时写SQL和做报表，但经常要自己写脚本处理数据、对接接口，所以有编码能力的人会更受欢迎。后面我会单独展开这道题。

2. SQL题没有"标准答案"，但判卷人看的是这三层

2.1 手写SQL：用户表、订单表、活跃表的三表联查

游戏公司的SQL题，翻来覆去就是围绕用户、活跃、付费这三张主题表出题。我按记忆中的数据模型，模拟一个典型的笔试题场景。

假设数据库中三张表结构如下：

• user_info（用户表）：user_id,first_login_time,channel
• login_log（活跃日志表）：user_id,login_date,server_id
• order_info（订单表）：order_id,user_id,pay_time,pay_amount

一道典型的题目：计算2024年1月1日当天新增用户中，截至1月7日的累计付费金额，以及其中在1月7日当天有活跃行为的付费用户数。

这类题目考察的是多表关联的方向和聚合层级。常见做法是：

SELECT SUM(o.total_amount) AS accumulate_revenue, COUNT(DISTINCT paid_active_user_id) AS paid_active_user_cnt FROM ( SELECT user_id FROM user_info WHERE first_login_date = '2024-01-01' ) new_users LEFT JOIN ( SELECT user_id, SUM(pay_amount) AS total_amount FROM order_info WHERE pay_time BETWEEN '2024-01-01' AND '2024-01-07' GROUP BY user_id ) o ON new_users.user_id = o.user_id LEFT JOIN ( SELECT DISTINCT user_id FROM login_log WHERE login_date = '2024-01-07' ) active ON new_users.user_id = active.user_id LEFT JOIN ( SELECT user_id FROM order_info WHERE pay_time BETWEEN '2024-01-01' AND '2024-01-07' ) paid ON new_users.user_id = paid.user_id GROUP BY 1;

等等，这个写法为了演示子查询嵌套复杂了，而且paid_active_user_id需要在子查询中带出来。实际笔试中更推荐先按维度拆解再合并的做法：

SELECT SUM(pay_amount) AS accumulate_revenue, COUNT(DISTINCT pay_user_id) AS paid_user_cnt FROM ( SELECT u.user_id, o.pay_amount, CASE WHEN l.login_date IS NOT NULL THEN o.user_id END AS pay_user_id FROM user_info u LEFT JOIN order_info o ON u.user_id = o.user_id AND o.pay_time BETWEEN '2024-01-01' AND '2024-01-07' LEFT JOIN login_log l ON u.user_id = l.user_id AND l.login_date = '2024-01-07' WHERE u.first_login_date = '2024-01-01' ) t

注意这里的关键点：第一个LEFT JOIN的条件要把时间范围写在ON里面，而不是写在WHERE里面。如果写在WHERE里，LEFT JOIN就变成了INNER JOIN，新增但没付费的用户会被过滤掉，累计付费金额没错，但你统计的基数就不对了。这类细节就是判卷人分辨"背过题"和"真懂"的地方。

2.2 窗口函数：连续登录天数和首充复充间隔

另一类高频SQL题是窗口函数。游戏数据分析里，连续登录天数直接关系到玩家粘性判断，首充到复充的间隔时间关系到付费养成体系的设计。

连续登录天数有个经典解法：用login_date减去ROW_NUMBER()的序号，如果日期是连续的，相减得到的日期值就相同。模拟题目：找出每个用户最长的连续登录天数。

WITH t1 AS ( SELECT user_id, login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) AS rn FROM login_log ), t2 AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL rn DAY) AS group_date FROM t1 ) SELECT user_id, COUNT(*) AS continuous_days FROM t2 GROUP BY user_id, group_date HAVING COUNT(*) >= 3;

笔试时能写出ROW_NUMBER()和DATE_SUB这两步，基本就能拿分。如果再加一层，让你统计"连续登录3天及以上的用户里，有多少人发生了付费"，这就是留存的复合分析，考的是窗口函数和JOIN的组合使用。

单日活跃、次日留存、7日留存在游戏行业算得极其频繁。有些同学会直接SELECT COUNT(DISTINCT user_id)然后LEFT JOIN，但数据量大时COUNT(DISTINCT)代价很高，笔试中如果特意问了"如何优化"，可以提APPROX_COUNT_DISTINCT或基数估计的思路，这是加分项。

2.3 判卷人真正看的：去重、NULL、表连接方向

我说句实在话，绝大多数校招考生写的SQL，功能上都能跑通，但细节上一塌糊涂。笔试判卷通常按采分点给分，以下几个坑踩中一个，分数都会打折。

第一，去重粒度。COUNT(user_id)和COUNT(DISTINCT user_id)结果可能完全不同。活跃日志表里一个用户一天可能有多条登录记录，你需要明确题目问的是"登录次数"还是"活跃人数"。

第二，NULL值处理。SUM遇到全是NULL会返回NULL而不是0，如果报表里出现空值，前端展示就是空白。建议用COALESCE(SUM(x), 0)，这几乎是生产环境写报表的标配。

第三，连接方向。判断用LEFT JOIN还是INNER JOIN，核心看主表是谁。以"新增用户为分析主体"就应该以用户表为左表，用LEFT JOIN去外连订单和活跃；以"所有订单交易分析"就应该以订单表为左表。方向搞反，人数和金额都会对不上。

第四，时间边界。BETWEEN是闭区间，pay_time BETWEEN '2024-01-01' AND '2024-01-07'会包含1月7日0点0分0秒之后的所有数据，但如果pay_time是DATETIME类型，而字段里存的是'2024-01-07 23:59:59'，也是要包含的。实际业务中更稳妥的写法是pay_time >= '2024-01-01' AND pay_time < '2024-01-08'。

3. 业务题不是考概念，是考"口径判断力"

3.1 游戏行业绕不开的五个核心指标

BI工程师和数据分析师的差异在于，BI更贴近数据和报表层，所以对指标的定义要非常敏感。游戏行业笔试必考的五个指标是：DAU/WAU/MAU、留存率、付费率、ARPU/ARPPU、LTV。别以为记住公式就够了，笔试一定会换个场景问你如何定义。

DAU在游戏行业有一个常见歧义：游客账号算不算活跃用户？不同游戏类型答案不一样。重度MMORPG通常要求登录后创建角色才计入DAU，而休闲游戏可能把打开App就算。答题时不要一上来就写"DAU = 当日去重登录人数"，要先声明范围，比如"按常规口径，以当日有登录行为的player_id去重计数，不包含游客"。

留存率的计算最容易被"新增用户"定义坑到。如果渠道商给你导入一批激活但未创角的用户，这批人算不算新增？游戏公司通常以"创角"为准，因为激活不代表真正进入了游戏世界。

3.2 指标口径的歧义：一题三解是常态

笔试里经常出现这种开放题："某版本更新后，运营反馈新用户付费率下降了，你如何分析？"

这就是经典的口径判断题。第一层要确认"新用户"是什么口径——当日新增用户、7日内新增用户，还是某个渠道导入的新增用户？第二层要确认"付费率"是什么口径——当日新增用户当日付费率，还是当日活跃用户中发生过付费的占比？第三层还要确认对比基准——是和上个版本比，还是和去年同期比，还是和同渠道历史比？

我当年备考时总结了一个答题结构：先列出你能想到的所有口径，然后根据业务场景选择最合理的一组假设，最后说明"如果按A口径是下降，按B口径可能没有下降"。这个作答方式在笔试和面试里都很讨喜，因为数据岗位最重要的能力之一就是识别"同一个词在不同语境下的不同含义"，避免分析做到一半发现口径对不上。

3.3 ARPU和ARPPU：公式差别很小，业务意义差别很大

ARPU（Average Revenue Per User）是所有用户的人均收入，ARPPU（Average Revenue Per Paying User）是付费用户的人均收入。这两个指标在游戏行业一定要分清，因为它们反映的问题完全不同。

• ARPU = 总收入 / 活跃用户数，反映整体变现效率
• ARPPU = 总收入 / 付费用户数，反映付费玩家群体的客单价

举个例子，一款游戏月收入1000万，月活跃用户100万，本月有付费行为的用户5万。那么ARPU = 10元，ARPPU = 200元。如果做活动后ARPU上升但ARPPU下降，说明可能是付费人数增加了，但人均付费金额变低了，这时候要看活动设计的拉新客效果，而不是简单地认为收入健康。

笔试中如果只写公式不给分析，最多拿一半分。判卷人想看到的是你能不能从数字差异中读出业务含义，这决定了你入职后能不能和运营说到一起去。

4. 工具题：Power BI、帆软和那只"拦路虎"C#

4.1 Power BI Desktop 连接MySQL：导入模式与DirectQuery的本质区别

热点词里有个问题非常典型："Power BI如何连接MySQL，导入和DirectQuery区别是什么"。这几乎是BI工具面试必问题。

Power BI Desktop连接MySQL有两种模式，分表在"获取数据"连接界面里叫Import（导入）和DirectQuery（直接查询）。

笔试可能会进一步问：如果你的报表需要在每天早上8点定时展示前一天的核心数据，选哪种模式？我的答案是Import。因为数据是确定时间点的历史数据，导入模式刷新一次就够，查询快，用户体验好。如果业务要实时监控当前在线人数，那就必须用DirectQuery，但要注意MySQL服务器的并发压力，最好设计查询只返回聚合后的结果，不要让报表去拉全表明细。

另一个易混淆点：DirectQuery在Power BI里不是所有数据源都支持同样的功能，MySQL连接时有些高级特性（比如增量刷新配合）不如导入模式灵活。生产环境的常见做法是"明细数据走数据仓库，BI连接数仓表用导入模式"，这样既能保证性能又能控制数据库压力。

4.2 帆软BI和FineReport：笔试面试常问的差异

热点词里的"帆软bi考试"说明帆软认证在求职圈有相当热度。帆软旗下有两个产品：FineBI和FineReport，很多同学分不清，笔试一旦考到这个就会卡壳。

FineBI是自助式BI分析工具，面向业务人员做探索式分析，核心是拖拽生成图表、创建数据模型，适合"数据不知道应该怎么分析，想自己探索看看"的场景。FineReport则是专业报表工具，面向技术人员做固定格式的报表，比如中国式复杂报表、带复杂表头和单元格合并的财务报表。

有一个记忆技巧：FineReport的"Report"是报告，是设计好的固定样式，比如每周给管理层发的经营分析报表；FineBI的"BI"偏商业智能探索，是让业务自己玩数据的。如果题目问"运营部想要每周固定发一份收入周报，同时希望平时能自己灵活分析数据，应该用哪个产品"，答案是两个都要用：Fixed报表用FineReport，灵活探索用FineBI。

帆软有FCP认证（FineReport Certified Professional和FineBI Certified Professional），分初级、资深、高级。对校招而言，初级或资深认证是加分项，但含金量远不如SQL和业务分析能力。我把备考位次排在最后，因为笔试的工具题通常只是简答或选择题，真正的重头戏一直是SQL和业务题。

4.3 "使用C#实现"到底想考什么

这份笔试题最让人意外的应该是出现"C#实现"相关要求。毕竟BI工程师日常和SQL打交道更多，为什么突然要写C#？

其实这是.NET技术栈在公司里的延续。搜狐畅游很多内部系统是基于.NET开发的，报表平台、数据分析平台会有大量C#代码。BI工程师如果只会SQL，遇到这些平台的二次开发需求就束手无策，所以笔试加一道编程题，本质上是想确认你有没有面向对象编程的基础。

这类题的难度通常不会太高，考察点一般是循环、集合、字符串处理、文件读写这种基础能力，不会考设计模式或并发编程。比如类似"给定一个DataTable，筛选出某列值大于100的行，按另一列分组求和，输出到CSV"。

我当时在草稿纸上的思路是：先写一个假设，然后用循环和字典模拟分组求和，最后用StreamWriter写入文件。关键是让判卷人看到你具备基本的代码组织能力，代码能不能直接跑反而在其次。C#不是所有BI岗都会考，但如果简历上写了"熟悉C#"，笔试出现这道题就说得通了，所以备考时至少要会写简单的类和LINQ操作。

5. 案例题和开放题，要拿分靠框架而非"灵光一现"

5.1 给一款游戏搭运营看板，第一屏放什么

开放题里经常出现"请设计一个运营看板"或"第一屏放什么指标"。这种题没有标准答案，但可以通过结构化的答题框架拿分。

我建议按四步走：先明确业务目标，再定核心指标，然后列下钻维度，最后说明决策动作。举个例子，假设要为一款手游做日常运营看板：

第一屏应该放的是"最高优先级监控指标"，不是所有指标。我的习惯是中间一大块DAU趋势和收入趋势，左上角是今日关键指标卡，右侧是最新版本/活动数据，底部是异常数据预警列表。你要让看板在10秒内能回答"今天到底行不行"，而不是让运营在一堆图表里找结论。

5.2 "付费收入下降"的排查模板

另一类高频开放题是"收入下降了，怎么分析"。我推荐用五步排查法，笔试时按这个结构作答，逻辑清晰且不容易遗漏。

第一步，数据校验。先确认数据口径有没有变化，比如是否有渠道接口调整、埋点缺失、服务器异常导致数据漏采。没有这一步，后面分析再漂亮也可能白搭。

第二步，维度拆分。把收入按时间、渠道、服务器、版本、用户类型拆分，定位下降主要集中在哪个维度。时间维度还可以继续拆到小时，区分是某个晚上8点突然下降还是整体缓慢下滑。

第三步，同期对比。和前一天、前一周同期、上月同期对比，排除周期性波动。游戏行业寒暑假、周末的波动都很明显，不能拿工作日和周末直接比。

第四步，业务归因。结合运营动作，比如是否版本更新、活动结束、某道具下架，或者是否有竞品上线导致玩家流失。

第五步，输出结论和方案。BI分析不能只停在"发现下降"，要给出建议：是调整活动周期、修复关卡难度，还是排查渠道问题。

这个框架在校招笔试里非常能打。判卷人看几十份卷子，谁在认真分析、谁在凑字数，一眼就能看出来。

6. 我带着笔试考点做BI，实际工作中验证出的优先级

6.1 入职后才发现，笔试果然是最温柔的考验

说实话，笔试里的SQL题虽然吓人，但数据量、表结构、字段语义都是设定好的，不会有歧义。实际工作里的数据质量参差不齐，埋点漏报、字段名混乱、口径变更，才是真正的日常。

我带新人的时候反复强调三个习惯：第一，写SQL永远先加条件限制，不要上来就SELECT *，养成指定字段的习惯；第二，交付任何数据结论前，先跟前一天数据做对比，波动超过20%就要查；第三，把常用的指标口径沉淀成文档，否则三个月后你自己都忘了当初怎么算的。

笔试里学的窗口函数，在工作中的实际使用频率比想象中高得多。留存分析、漏斗分析、用户路径分析，几乎离不开LAG、LEAD、ROW_NUMBER。准备笔试时多刷窗口函数，性价比极高。

6.2 校招备考的三个月，时间分配建议

如果你离校招季还有三个月，我建议这样安排：

工具部分不需要贪多。Power BI Desktop入门一天就能上手，帆软FineBI的练习版下载后也能快速搞定基本操作。笔试里工具题通常只占一小部分，别把大量时间花在学高级可视化技巧上。

6.3 最后几点提醒：别在简历上给自己挖坑

简历上写"精通Power BI"的同学，面试官一定会追问行级别安全（RLS）、DAX上下文、DirectQuery的坑，答不上来就很尴尬。建议改成"熟悉Power BI，能完成数据清洗、建模和报表开发，了解导入与DirectQuery差异"。这样既诚实又保证安全。

笔试时如果遇到C#题，实在写不出来也不要留空，哪怕只写思路和关键伪代码，也比空白强。校招笔试不是选满分选手，而是筛选有潜力的候选人，你能展示出清晰的思维过程，分数就不会太差。

另外，字迹一定要工整，手写SQL时括号、关键字、逗号的位置要清晰。判卷人面对几十份卷子，一份看不清的答案不可能给高分。

我在实际带人时还发现一个规律：笔试SQL题做得好的同学，入职后通常能快速胜任日常取数工作；而业务案例分析答得好的同学，往往在和运营、策划的沟通中更顺畅。两者各有价值，但长期来看，业务理解力决定了你能走多高，SQL能力决定了你起步多快。所以备考时别把时间全砸在写SQL上，留出一部分时间多看游戏行业的数据分析案例，对笔试和面试都是隐性加成。