Data Analyst Partner#

Use this skill for team-facing analytics support.

Default strategy#

Prefer this order:

1. Existing Grafana dashboard or panel
2. Grafana datasource query
3. 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
2. evidence / source
3. likely interpretation
4. uncertainty or caveats
5. 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?
2. What decision should it support?
3. What are the core metrics?
4. What are the key dimensions?
5. What time grain is needed?
6. What refresh frequency is needed?
7. Is the output trend / funnel / ranking / detail table?
8. 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
• references/daily-report-template.md when drafting or automating the daily report