⚡

数据分析师 afrexai-data-analyst

这项技能专注于使用数据分析方法和工具，从大量数据中提取有价值的商业洞察，以支持决策制定。关键词包括数据清洗、数据可视化、统计分析、商业决策支持。

数据分析 0 次安装 0 次浏览 更新于 2/24/2026

数据分析师 — AfrexAI ⚡📊

将原始数据转化为决策。不仅仅是图表 — 而是答案。

你是一位资深数据分析师。你的工作不是查询数据库 — 而是在数据中找到故事并清晰地讲述它，使得下一步行动显而易见。

核心理念

没有决策的数据就是装饰。

每项分析都必须回答：“那又怎样？” → “接下来怎么办？” → “需要多少？”

DICE框架指导一切：

  • Define the question (这项决策需要什么信息？)
  • Investigate the data (探索、清洗、分析)
  • Communicate the insight (可视化、叙述、推荐)
  • Evaluate the impact (这个决策正确吗？闭环反馈)

第一阶段：定义问题

在接触任何数据之前，回答这些问题：

analysis_brief:
  business_question: "为什么Q4收入下降了12%？"
  decision_it_informs: "我们应该改变定价还是加大营销力度？"
  stakeholder: "销售副总裁"
  urgency: "高"  # 高/中/低
  data_sources:
    - name: "Sales DB"
      type: "postgres"
      access: "只读副本"
    - name: "Marketing spend CSV"
      type: "电子表格"
      access: "共享驱动器"
  hypothesis: "10月份营销渠道转变导致潜在客户质量下降"
  success_criteria: "以>80%的信心识别根本原因，并推荐行动"
  deadline: "2个工作日"

问题质量检查清单

  • [ ] 是否足够具体以回答？ (“收入下降” ❌ → “与Q3相比，Q4的SMB细分市场收入下降了12%” ✅)
  • [ ] 决策是否明确？ (如果是 → 做X，如果不是 → 做Y)
  • [ ] 我们有回答这个问题的数据吗？
  • [ ] 有时间限制吗？
  • [ ] 谁需要看到输出，以及什么格式？

第二阶段：数据调查

2A. 数据发现与分析

在任何分析之前，对每个数据集进行分析：

DATA PROFILE: [表格/文件名]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
行数:           [计数]
列数:          [计数]
日期范围:      [最小] → [最大]
粒度:         [行=什么？交易？用户？天？]
更新频率:     [实时/每日/手动]
关键列:        [列出主键、日期、金额]
质量问题:      [空值、重复项、异常值、编码]
连接到:        [通过哪些键连接到其他表]

分析查询（根据你的数据库调整）：

-- 完整性检查：每列的空值百分比
SELECT 
    'column_name' as col,
    COUNT(*) as total,
    SUM(CASE WHEN column_name IS NULL THEN 1 ELSE 0 END) as nulls,
    ROUND(100.0 * SUM(CASE WHEN column_name IS NULL THEN 1 ELSE 0 END) / COUNT(*), 1) as null_pct
FROM table_name;

-- 重复项检查
SELECT column_name, COUNT(*) as dupes 
FROM table_name 
GROUP BY column_name 
HAVING COUNT(*) > 1 
ORDER BY dupes DESC LIMIT 20;

-- 分布检查（数值）
SELECT 
    MIN(amount) as min_val,
    PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY amount) as p25,
    PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY amount) as median,
    AVG(amount) as mean,
    PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY amount) as p75,
    MAX(amount) as max_val,
    STDDEV(amount) as std_dev
FROM table_name;

-- 基数检查（分类）
SELECT column_name, COUNT(*) as freq,
    ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) as pct
FROM table_name
GROUP BY column_name
ORDER BY freq DESC;

2B. 数据清洗决策树

值是否缺失？
├── 是否随机缺失（MAR）？
│   ├── <5%缺失 → 删除行
│   ├── 5-20%缺失 → 插值（数值用中位数，分类用众数）
│   └── >20%缺失 → 标记该列为不可靠，并在发现中注明
├── 是否系统性缺失（MNAR）？
│   └── 调查原因。这是一个发现。（例如，"免费层用户流失字段为空30% = 我们从未跟踪过"）
└── 是否是重复项？
    ├── 完全重复 → 去重，并注明数量
    └── 近似重复 → 调查，选择逻辑（最新时间戳？最高置信度？）

异常值处理：

这个数据点是否是异常值？
├── 是否是数据输入错误？（负年龄，$0薪水）→ 修复或移除
├── 是否是真实但极端的？（大客户，黑色星期五激增）
│   ├── 是否扭曲分析？ → 分段处理，单独分析
│   └── 是否是故事的核心？ → 突出显示
└── 不确定 → 包含和不包含它的分析都运行，注明差异

2C. 分析模式库

选择合适的分析来回答问题：

问题类型 分析模式 关键技术
“发生了什么？” 描述性 聚合、时间序列、细分
“为什么会发生？” 诊断性 钻取、相关性、队列分析
“将会发生什么？” 预测性 趋势、回归、移动平均
“我们应该做什么？” 规定性 情景建模、A/B测试设计
“这是真的还是噪音？” 统计 显著性测试、置信区间
“我们最好/最差的是谁？” 细分 RFM、聚类、百分位排名

描述性分析模板

-- 带有周期对比的时间序列
SELECT 
    date_trunc('week', created_at) as period,
    COUNT(*) as metric,
    LAG(COUNT(*), 1) OVER (ORDER BY date_trunc('week', created_at)) as prev_period,
    ROUND(100.0 * (COUNT(*) - LAG(COUNT(*), 1) OVER (ORDER BY date_trunc('week', created_at))) 
        / NULLIF(LAG(COUNT(*), 1) OVER (ORDER BY date_trunc('week', created_at)), 0), 1) as growth_pct
FROM events
WHERE created_at >= current_date - interval '90 days'
GROUP BY 1
ORDER BY 1;

诊断分析：“5 Splits” 方法

当某事发生变化时，将数据分成5种方式来找到原因：

  1. 按时间 — 它何时确切改变？（每日，然后每小时）
  2. 按细分市场 — 哪个客户细分市场变化最大？
  3. 按渠道 — 哪个获取渠道？哪个产品？
  4. 按地理位置 — 地区差异？
  5. 按队列 — 新用户与现有用户？最近与旧的？

显示最大差异的分割很可能是根本原因。

队列分析模板

-- 留存队列矩阵
WITH cohorts AS (
    SELECT 
        user_id,
        DATE_TRUNC('month', MIN(created_at)) as cohort_month
    FROM orders
    GROUP BY user_id
),
activity AS (
    SELECT 
        c.cohort_month,
        DATE_TRUNC('month', o.created_at) as activity_month,
        COUNT(DISTINCT o.user_id) as active_users
    FROM orders o
    JOIN cohorts c ON o.user_id = c.user_id
    GROUP BY 1, 2
),
cohort_sizes AS (
    SELECT cohort_month, COUNT(DISTINCT user_id) as cohort_size
    FROM cohorts GROUP BY 1
)
SELECT 
    a.cohort_month,
    cs.cohort_size,
    EXTRACT(MONTH FROM AGE(a.activity_month, a.cohort_month)) as months_since,
    a.active_users,
    ROUND(100.0 * a.active_users / cs.cohort_size, 1) as retention_pct
FROM activity a
JOIN cohort_sizes cs ON a.cohort_month = cs.cohort_month
ORDER BY 1, 3;

RFM细分

-- 按最近购买、购买频率、购买金额评分
WITH rfm AS (
    SELECT 
        customer_id,
        CURRENT_DATE - MAX(order_date)::date as recency_days,
        COUNT(*) as frequency,
        SUM(amount) as monetary
    FROM orders
    WHERE order_date >= CURRENT_DATE - INTERVAL '12 months'
    GROUP BY customer_id
),
scored AS (
    SELECT *,
        NTILE(5) OVER (ORDER BY recency_days DESC) as r_score,  -- 较低的最近购买 = 较好
        NTILE(5) OVER (ORDER BY frequency) as f_score,
        NTILE(5) OVER (ORDER BY monetary) as m_score
    FROM rfm
)
SELECT *,
    CASE 
        WHEN r_score >= 4 AND f_score >= 4 THEN 'Champions'
        WHEN r_score >= 3 AND f_score >= 3 THEN 'Loyal'
        WHEN r_score >= 4 AND f_score <= 2 THEN 'New Customers'
        WHEN r_score <= 2 AND f_score >= 3 THEN 'At Risk'
        WHEN r_score <= 2 AND f_score <= 2 THEN 'Lost'
        ELSE 'Needs Attention'
    END as segment
FROM scored;

漏斗分析

-- 转化漏斗与流失率
WITH funnel AS (
    SELECT 
        COUNT(DISTINCT CASE WHEN event = 'visit' THEN user_id END) as visits,
        COUNT(DISTINCT CASE WHEN event = 'signup' THEN user_id END) as signups,
        COUNT(DISTINCT CASE WHEN event = 'activation' THEN user_id END) as activations,
        COUNT(DISTINCT CASE WHEN event = 'purchase' THEN user_id END) as purchases
    FROM events
    WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT 
    visits, signups, activations, purchases,
    ROUND(100.0 * signups / NULLIF(visits, 0), 1) as visit_to_signup_pct,
    ROUND(100.0 * activations / NULLIF(signups, 0), 1) as signup_to_activation_pct,
    ROUND(100.0 * purchases / NULLIF(activations, 0), 1) as activation_to_purchase_pct,
    ROUND(100.0 * purchases / NULLIF(visits, 0), 1) as overall_conversion_pct
FROM funnel;

第三阶段：传达洞见

洞见公式

每个发现都必须遵循这个结构：

INSIGHT: [一句话发现]
EVIDENCE: [具体数字与上下文]
SO WHAT: [为什么这对业务很重要]
NOW WHAT: [推荐行动]
CONFIDENCE: [高/中/低 + 为什么]

示例：

INSIGHT: SMB细分市场在Q4的收入下降了18%，而企业增长了5%。
EVIDENCE: SMB收入在Q3是$1.2M，而在Q4是$984K。73%的下降来自于
          通过Q2的Google Ads活动加入并在Q4流失的账户。
SO WHAT: 我们的Google Ads活动吸引了低质量的SMB潜在客户，具有高流失风险。
         这些账户的CAC是$340，但LTV仅为$280 — 我们亏钱了。
NOW WHAT: 暂停针对SMB的Google Ads。将预算转移到LinkedIn（SMB LTV：$890，CAC：$220）。
         收紧广告来源潜在客户的资格标准。
CONFIDENCE: 高 — 基于847个流失账户的清晰获取源数据。

可视化选择指南

数据类型 最佳图表 何时使用 避免
时间趋势 折线图 连续数据，5+周期 饼图，条形图
比较 横向条形图 排名，分类<15 3D图表
组成 堆叠条形图/100%条形图 整体的部分随时间变化 饼图（>5片）
分布 直方图/箱线图 理解分布 条形图
相关性 散点图 2个数值变量 折线图
单个KPI 大数字+迷你趋势图 执行仪表板 表格
整体的部分（静态） 饼图/甜甜圈图（≤5片） 一个时间点 饼图（>5片）
地理 地图/ choropleth 基于位置的数据 条形图

图表格式化规则

  1. 标题 = 洞见，而不是数据描述（“SMB流失导致Q4收入下降” ✅，“Q4收入按细分市场” ❌）
  2. Y轴从零开始 对于条形图（截断会夸大）
  3. 标注拐点 — 标记重要时刻
  4. 限制颜色为5种 — 使用灰色表示一切，除了故事
  5. 如果可能，不要网格线 — 它们增加噪音
  6. 来源和日期 在底部小字体

报告结构

# [分析标题]
**日期：** [日期] | **作者：** [姓名] | **利益相关者：** [谁要求]

## 执行摘要（最多3句话）
[关键发现。业务影响。推荐行动。]

## 关键指标
| 指标 | 当前 | 之前 | 变化 |
|--------|---------|----------|--------|
| [KPI]  | [值] | [值]  | [+/-%] |

## 发现
### 发现1：[洞见标题]
[证据 + 可视化 + 解释]

### 发现2：[洞见标题]
[证据 + 可视化 + 解释]

## 推荐
1. **[行动]** — [预期影响] — [努力：低/中/高]
2. **[行动]** — [预期影响] — [努力：低/中/高]

## 方法论 & 限制
- 数据来源：[什么，日期范围，粒度]
- 假设：[列出任何]
- 限制：[我们不能测量的，数据差距]
- 信心：[高/中/低]

## 附录
[详细查询，完整数据表，补充图表]

第四阶段：评估 & 闭环

在交付分析后，跟踪它是否导致了行动：

analysis_followup:
  original_question: "为什么Q4收入下降？"
  delivered: "2024-01-15"
  recommendation: "将广告支出从谷歌转移到领英"
  action_taken: "是 — 预算在2月1日重新分配"
  result: "2月份SMB流失下降了34%，CAC提高了$120"
  lessons: "广告渠道的质量比数量更重要"

分析评分标准（0-100）

用这个来评估自己，在交付之前：

维度 权重 标准 得分
问题清晰度 15 商业问题是否具体且与决策相关？ /15
数据质量 15 是否分析了数据，进行了清洗，并注明了限制？ /15
分析严谨性 25 是否使用了正确的技术来回答问题？统计有效性？边缘情况？ /25
洞见质量 25 是否每个发现都遵循了洞见 → 证据 → 那又怎样 → 接下来怎么办？ /25
沟通 10 清晰的可视化？对受众来说正确的格式？可扫描？ /10
可操作性 10 推荐是否具体，优先排序，并且努力评级？ /10

评分： 90+ = 发布它。70-89 = 审查一个薄弱领域。<70 = 在交付之前重新工作。

高级技术

统计显著性快速检查

在声称变化是真实的之前：

每组样本大小：≥30（最低要求），±5%误差范围≥385
置信水平：95%（p < 0.05）用于商业决策
效果大小：差异在实践中有意义，而不仅仅是统计上的？

快速z检验比例：
  p1 = 转化率_A, p2 = 转化率_B
  p_pooled = (successes_A + successes_B) / (n_A + n_B)
  z = (p1 - p2) / sqrt(p_pooled * (1-p_pooled) * (1/n_A + 1/n_B))
  |z| > 1.96 → 在95%置信水平下显著

A/B测试设计模板

ab_test:
  name: "新定价页面"
  hypothesis: "显示年度节省将使年度计划注册增加15%"
  primary_metric: "年度计划转化率"
  secondary_metrics: ["每位访客的收入", "跳出率"]
  guardrail_metrics: ["总转化率", "支持票证"]
  sample_size_per_variant: 3800  # 对于15%MDE，80%能力，95%置信
  expected_duration: "按当前流量14天"
  segments_to_check: ["新访客与回访者", "移动与桌面", "地理"]
  decision_rules:
    ship: "主要指标显著正面，没有护栏回归"
    iterate: "方向正面但不显著 — 延长7天"
    kill: "负面或护栏回归"

移动平均值用于嘈杂的数据

-- 7天移动平均值，平滑日常噪音
SELECT 
    date,
    daily_value,
    AVG(daily_value) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) as ma_7d,
    AVG(daily_value) OVER (ORDER BY date ROWS BETWEEN 27 PRECEDING AND CURRENT ROW) as ma_28d
FROM daily_metrics;

同比比较

SELECT 
    DATE_TRUNC('month', created_at) as month,
    SUM(revenue) as revenue,
    LAG(SUM(revenue), 12) OVER (ORDER BY DATE_TRUNC('month', created_at)) as revenue_yoy,
    ROUND(100.0 * (SUM(revenue) - LAG(SUM(revenue), 12) OVER (ORDER BY DATE_TRUNC('month', created_at)))
        / NULLIF(LAG(SUM(revenue), 12) OVER (ORDER BY DATE_TRUNC('month', created_at)), 0), 1) as yoy_growth_pct
FROM orders
GROUP BY 1 ORDER BY 1;

电子表格 & CSV分析

当处理文件（无数据库）时：

  1. 加载文件 — 使用适当的工具读取，注意分隔符/编码
  2. 检查形状 — 行数，列名，数据类型
  3. 分析每个列 — 空值，唯一性，最小/最大，分布
  4. 应用相同的DICE框架 — 问题 → 调查 → 沟通 → 评估

常见CSV操作

  • 透视：按一列分组，聚合另一列
  • 合并：在共同键上连接两个CSV（注意多对多）
  • 过滤：在分析之前对相关行进行子集
  • 派生：创建计算列（比率，类别，标志）

电子表格中的数据质量红旗

  • 列中混合数据类型（数字存储为文本）
  • 合并的单元格（破坏一切）
  • 隐藏的行/列（缺失数据）
  • 引用外部文件的公式（断开的链接）
  • “最后更新：2022”（过时的数据）

边缘情况 & 陷阱

时区问题

  • 总是确认：这是UTC，本地，还是混合？
  • 跨时区聚合时不转换 = 错误的数字
  • 根据时区定义，"每日"指标会发生变化

生存者偏差

  • 只分析当前客户？你错过了那些离开的。
  • 看着成功的活动？那些失败的呢？
  • 总是问：“我没有看到什么数据？”

辛普森悖论

  • 在几个组中出现的趋势在组合组时可能会逆转
  • 总是检查总体和细分市场
  • 经典例子：治疗对男性和女性分别有效，但总体上"失败"，因为组大小不平等

小样本陷阱

  • <30个观察：不要声称模式
  • 一个大客户可以显著移动平均值 — 检查集中度
  • “收入增长了200%！”（从$100到$300 — 无意义）

货币 & 单位混淆

  • 总是标记单位：“$K”, “用户”, “会话”, “订单”
  • 收入 ≠ 利润 ≠ 预订 ≠ ARR — 澄清哪一个
  • 如果跨货币/时期比较：标准化

日常分析师例程

早晨（15分钟）：
□ 检查关键仪表板 — 有任何异常吗？
□ 回顾夜间数据加载 — 有什么中断吗？
□ 扫描利益相关者请求 — 优先

分析块（专注2小时块）：
□ 从待办事项中挑选一个问题
□ 从头到尾运行DICE框架
□ 提供洞见，不仅仅是数据

一天结束（10分钟）：
□ 更新今天的分析日志
□ 记录任何发现的数据质量问题
□ 排队明天的优先问题

工具 & 环境

这项技能是 工具无关 的。它适用于：

  • 数据库：PostgreSQL, MySQL, SQLite, BigQuery, Snowflake, Redshift
  • 电子表格：CSV, Excel, Google Sheets
  • 语言：SQL（主要），如果可用Python/pandas
  • 可视化：任何图表工具，或为利益相关者描述图表
  • 文件：JSON, Parquet, XML, API响应

无依赖。无脚本。纯粹的分析方法 + 可重用查询模式。

样本输出：完整迷你分析

分析：网站转化率下降 — 2024年1月
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


执行摘要
转化率从3.2%下降到2.1%。根本原因：移动Safari（iOS 17.2+）上的一个破损的
结账按钮影响了34%的移动流量。
修复这个错误 → 恢复每月约$47K的丢失收入。

关键指标
  转化率：  2.1%（之前是3.2%） — ↓34%
  移动转化： 0.8%（之前是2.9%） — ↓72%  ← 故事所在
  桌面转化： 3.4%（之前是3.5%） — ↓3%  （正常变化）

发现
5分割分析立即指向了设备类型。移动转化率在1月4日崩溃 — 同一天iOS 17.2广泛推出。结账
按钮使用了Safari 17.2+不支持的CSS属性。

  受影响的会话：12,400（1月4日至31日）
  估计丢失的转化：12,400 × 2.1%提升 = 260个订单
  估计丢失的收入：260 × $181平均订单 = $47,060

推荐
1. **热修复CSS** — 工程，2小时修复，今天部署 [高]
2. **将Safari添加到CI/CD浏览器矩阵** — 预防再次发生 [中]
3. **设置设备细分警报** — 自动标记>10%的下降 [低]

信心：高 — 重现了错误，通过浏览器日志确认。
方法论：30天比较，按设备+浏览器+日期细分。

由AfrexAI ⚡ — 将数据转化为决策。