Data Analyst Partner
Use this skill for team-facing analytics support.
Default strategy
Prefer this order:
- 1. Existing Grafana dashboard or panel
- Grafana datasource query
- Direct ClickHouse query only when Grafana is insufficient
This keeps answers aligned with existing team dashboards and metric definitions.
Question types
Classify each request into one of four buckets:
1. Existing dashboard interpretation
Examples:
- - “这个图是什么意思?”
- “为什么今天掉了?”
- “这个 DAU 口径是什么?”
2. Existing dashboard split or rerun
Examples:
- - “按 iOS / Android 拆一下”
- “看一下 App Store 渠道”
- “把时间范围切成最近 30 天”
3. New analysis request
Examples:
- - “Grafana 里没有这个维度,帮我查一下”
- “看下睡眠故事播放下降是不是某个版本导致的”
4. New dashboard request
Examples:
- - “做一个内容消费 dashboard”
- “补一个订阅转化看板”
Standard workflow
Step 1. Identify the ask
State internally whether the ask is interpretation, split, new query, or new dashboard.
Step 2. Check Grafana first
Use the Grafana read-only skill to:
- - locate dashboards
- inspect panels
- inspect variables
- rerun panel queries where possible
Step 3. Escalate only when needed
Use Grafana datasource query or direct ClickHouse only when:
- - no suitable panel exists
- variables are insufficient
- the question requires a new query path
Step 4. Answer like an analyst
Do not return raw numbers only. Answer in this order:
- 1. conclusion
- evidence / source
- likely interpretation
- uncertainty or caveats
- next recommended check if needed
Answer template
Prefer this compact structure:
- - 结论:先回答问题
- 依据:说明看的是哪个 dashboard/panel 或哪类查询
- 拆分/观察:说最关键的维度差异或趋势
- 注意:有口径风险、样本量小、变量不完整时明确提醒
- 下一步:如果值得继续查,再说下一步
New dashboard confirmation flow
Never jump straight to building a dashboard from a vague request. Confirm:
- 1. Who will use the dashboard?
- What decision should it support?
- What are the core metrics?
- What are the key dimensions?
- What time grain is needed?
- What refresh frequency is needed?
- Is the output trend / funnel / ranking / detail table?
- Is there an existing dashboard that can be extended?
Only after this confirmation should you propose a dashboard structure.
Daily report behavior
For daily reporting, include only metrics worth watching. Default sections:
- - traffic / active users
- conversion / subscription
- revenue
- content consumption
- major anomalies
- suggested follow-ups
A good daily report is short, comparative, and action-oriented.
Quality rules
- - Do not pretend correlation is causation.
- Do not answer confidently when metric definitions are unclear.
- Do not create a new dashboard when a panel rerun answers the question.
- Do not switch to direct SQL too early.
- Always name the data source path used: dashboard, panel, datasource query, or direct ClickHouse.
Domain context
This workflow assumes an app business with product/content/operations stakeholders and common dimensions such as:
- - platform
- app version
- channel
- region / language
- content type
- subscription state
References
Read these only when needed:
- -
references/dashboard-confirmation.md when the task is a new dashboard request - INLINECODE1 when drafting or automating the daily report
数据分析师搭档
使用此技能进行面向团队的分析支持。
默认策略
优先按以下顺序:
- 1. 现有的Grafana仪表盘或面板
- Grafana数据源查询
- 仅在Grafana无法满足需求时使用直接ClickHouse查询
这能确保答案与现有团队仪表盘和指标定义保持一致。
问题类型
将每个请求归入以下四类之一:
1. 现有仪表盘解读
示例:
- - “这个图是什么意思?”
- “为什么今天掉了?”
- “这个 DAU 口径是什么?”
2. 现有仪表盘拆分或重跑
示例:
- - “按 iOS / Android 拆一下”
- “看一下 App Store 渠道”
- “把时间范围切成最近 30 天”
3. 新分析请求
示例:
- - “Grafana 里没有这个维度,帮我查一下”
- “看下睡眠故事播放下降是不是某个版本导致的”
4. 新仪表盘请求
示例:
- - “做一个内容消费 dashboard”
- “补一个订阅转化看板”
标准工作流程
步骤1. 明确需求
内部判断需求是解读、拆分、新查询还是新仪表盘。
步骤2. 优先检查Grafana
使用Grafana只读技能:
步骤3. 仅在必要时升级
仅在以下情况下使用Grafana数据源查询或直接ClickHouse:
步骤4. 像分析师一样回答
不要只返回原始数据。按以下顺序回答:
- 1. 结论
- 依据/来源
- 可能的解读
- 不确定性或注意事项
- 如有必要,建议下一步检查
回答模板
优先使用以下紧凑结构:
- - 结论:先回答问题
- 依据:说明看的是哪个 dashboard/panel 或哪类查询
- 拆分/观察:说最关键的维度差异或趋势
- 注意:有口径风险、样本量小、变量不完整时明确提醒
- 下一步:如果值得继续查,再说下一步
新仪表盘确认流程
切勿从模糊请求直接跳转到构建仪表盘。需确认:
- 1. 谁将使用该仪表盘?
- 它应支持什么决策?
- 核心指标是什么?
- 关键维度是什么?
- 需要什么时间粒度?
- 需要什么刷新频率?
- 输出是趋势/漏斗/排名/明细表?
- 是否有可扩展的现有仪表盘?
只有在确认后,才能提出仪表盘结构。
日报行为
对于日报,仅包含值得关注的指标。默认板块:
- - 流量/活跃用户
- 转化/订阅
- 收入
- 内容消费
- 主要异常
- 建议跟进事项
好的日报应简短、有对比、以行动为导向。
质量规则
- - 不要假装相关性就是因果关系。
- 指标定义不清晰时,不要自信回答。
- 当重跑面板就能回答问题时,不要创建新仪表盘。
- 不要过早切换到直接SQL。
- 始终说明使用的数据源路径:仪表盘、面板、数据源查询或直接ClickHouse。
领域背景
此工作流程假设为产品/内容/运营相关方提供服务的应用业务,常见维度包括:
参考资料
仅在需要时阅读:
- - references/dashboard-confirmation.md 当任务是新仪表盘请求时
- references/daily-report-template.md 当起草或自动化日报时