mcpField
L
looker-studio-bigquery

looker-studio-bigquery

github.com/akillness数据与数据库53389 次安装4 天前更新
代码仓库

关于 looker-studio-bigquery

用于在经过整理的 BigQuery 数据上规划 Looker Studio 利益相关方报告的技能。它将仪表板、刷新、性能、受众拆分和导出决策归入明确的报告类型。

主要功能

  1. 01将报告需求归入五种类型
  2. 02规划仪表板结构与 KPI 映射
  3. 03指导刷新与成本决策
  4. 04按受众拆分报告
  5. 05规划导出和 Connected Sheets 交接

适用场景

  1. 01设计 PM 或运营 KPI 仪表板
  2. 02排查缓慢或昂贵的营销报告
  3. 03为不同利益相关方拆分过载仪表板
  4. 04规划带 Sheets 交接的每周高管报告

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/akillness/jeo-skills --skill looker-studio-bigquery

安装后在 Claude Code 中输入/looker-studio-bigquery确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

loop-results.md
SKILL.toon
evals/
evals.json
references/
dashboard-delivery-checklist.md
intake-packets-and-route-outs.md
modeling-refresh-and-cost.md
modes-and-routing.md

详细介绍

Looker Studio + BigQuery

当最终交付物是基于 BigQuery 的一份可信利益相关方报告包时，请使用此技能。

looker-studio-bigquery 负责以下场景的报告层：

  • PM / ops KPI 评审看板
  • 已在 BigQuery 中建模的产品漏斗、留存和发布看板
  • 营销 / GTM 渠道和收入报告
  • 游戏 / 实时运营 / 业务遥测评审看板
  • 基于整理后数据在 Looker Studio 中进行刷新、成本、受众和导出交接决策

需要时，请先阅读以下支持文档：

何时使用此技能

  • 用户明确需要 Looker Studio / Data Studio + BigQuery 方面的帮助。
  • 数据已存储在 BigQuery 中，或看板明确基于经过整理的 BigQuery 表 / 视图。
  • 主要工作是看板结构、刷新 / 成本方案、面向特定受众的交付，或便于导出的报告。
  • 请求涉及 KPI 看板、PM / ops 评审、营销 / GTM 报告、产品概览看板，或游戏 / 业务遥测看板。
  • 真正的风险在于看板可信度、刷新设计或受众混杂导致内容膨胀，而不只是原始 SQL 解读。

何时不使用此技能

  • 主要工作是解释 KPI 为何变动或数据集意味着什么 → 使用 data-analysis
  • 主要工作是反复查找异常，或跨指标 / 事件进行可复用的规则扫描 → 使用 pattern-detection
  • 主要工作是遥测可靠性、告警或埋点覆盖率 → 使用 monitoring-observability
  • 主要工作是选择完整的 BI / 语义平台 → 使用 survey
  • 主要工作是广泛的 GCP / 引导配置 / 部署工作 → 先转交给相关基础设施技能

说明

步骤 1：讨论图表前，先选定一个主要报告包

将请求归纳为一个报告包。

looker_studio_bigquery_packet:
  primary_packet: dashboard-spec | slow-dashboard | refresh-shape | audience-split | exec-handoff
  audience: executive | pm-ops | product-analytics | marketing-gtm | game-liveops | mixed | unknown
  source_shape: curated-table | view | scheduled-query-output | materialized-view | mixed | unknown
  freshness_need: near-real-time | hourly | daily | weekly | unknown
  trust_risk: low | medium | high

准确选择一个 primary_packet：

  • dashboard-spec — 构建或重新设计利益相关方看板
  • slow-dashboard — 修复缓慢、昂贵或脆弱的看板
  • refresh-shape — 决定采用实时、定时、快照还是 BI Engine
  • audience-split — 将一份负载过重的报告拆分为面向不同受众的产物
  • exec-handoff — 提供精简看板，以及用于评论和审批的导出 / 表格 / 幻灯片交接方案

如果两个报告包似乎都合适，请选择优先消除最大交付风险的那个。

步骤 2：有意保持看板精简

设计版块前，请先回答以下问题：

  1. 此看板支持什么评审流程或决策？
  2. 哪张表 / 视图是事实来源？
  3. 哪些指标应放在 BigQuery 中，而不是使用报告级公式？
  4. 谁负责数据新鲜度、可信度检查和注意事项？

如果请求仍依赖原始事实表、不稳定的联接或模糊的指标定义，请明确指出，并将建模工作前置，在完善看板前完成。

步骤 3：围绕报告包设计，而不是泛泛讨论 BI

按照 references/intake-packets-and-route-outs.md 中的报告包指南执行。

报告包的最低要求：

  • dashboard-spec → 页面结构、KPI 集合、图表与问题的对应关系，以及 BigQuery 契约
  • slow-dashboard → 瓶颈排查顺序、上游预计算方案，以及一项最短路径修复
  • refresh-shape → 结合实际评审频率，选择实时、定时还是快照
  • audience-split → 按利益相关方的评审流程、信任需求和细节深度拆分产物
  • exec-handoff → 精简看板，以及 Connected Sheets / 导出 / 幻灯片交接方案

不要给出泛泛的图表清单。

步骤 4：提供交付简报

使用以下结构：

# Looker Studio Delivery Brief

## Primary packet
- Packet: ...
- Audience: ...
- Confidence: high | medium | low

## Review ritual and question
- Ritual: ...
- Decisions supported: ...

## BigQuery contract
- Source table/view: ...
- Grain: ...
- Core dimensions: ...
- Core metrics: ...
- Freshness / owner / caveats: ...

## Recommended dashboard shape
- Pages or sections: ...
- KPI and chart-to-question mapping: ...
- Filters / drilldowns / export needs: ...

## Refresh, cost, and trust plan
- Preferred refresh shape: ...
- Heavy logic to move upstream: ...
- Trust or caveat notes: ...

## Recommended next artifact
- Choose one: dashboard spec | SQL handoff list | refresh decision memo | audience split brief | export / Connected Sheets handoff

## Route-outs
- Upstream modeling / KPI interpretation / anomaly hunting / observability / platform comparison as needed
步骤 5：如实转交
  • 如果用户需要数据集推理或 KPI 解释，转交给 data-analysis。
  • 如果用户需要重复异常检测或可复用的指标规则，转交给 pattern-detection。
  • 如果用户需要遥测覆盖、告警或对埋点的信任，转交给 monitoring-observability。
  • 如果用户需要更全面的 BI 或语义平台决策，转交给 survey。

示例

示例 1：PM / 运营仪表板构建

输入

在 BigQuery 每周 KPI 的基础上，用 Looker Studio 构建一份适合领导层查看的 PM 评审仪表板。

输出概要

  • 数据包：dashboard-spec
  • 仪表板结构：KPI 记分卡 + 主趋势图 + 一个下钻视图 + 负责人 / 数据新鲜度说明
  • 下一项交付物：dashboard spec
示例 2：运行缓慢的营销看板

输入

每当有人操作筛选器，我们的营销漏斗仪表板就会变得很慢，而且成本很高。

输出概要

  • 数据包：slow-dashboard 或 refresh-shape
  • 主要建议：在调整样式之前，先在 BigQuery 中预计算反复使用的漏斗逻辑
  • 下一项交付物：refresh decision memo 或 SQL handoff list
示例 3：面向混合受众的仪表板

输入

一个看板要同时服务高管、PM、增长团队和实时运营团队。我们应该继续修补它吗？

输出概要

  • 数据包：audience-split
  • 建议：根据决策惯例和信任需求拆分交付物
  • 下一项交付物：audience split brief
示例 4：支持批注的交接

输入

领导层想要每周看板，但他们仍会在评审前先在 Sheets 中为数字添加批注。

输出概要

  • 数据包：exec-handoff
  • 建议：保持仪表板精简，并明确定义导出 / Connected Sheets 的交接方式
  • 下一项交付物：export / Connected Sheets handoff

最佳实践

  1. 从当前数据包入手，而不是从图表类型入手。
  2. 尽可能将繁重逻辑放在 BigQuery 中。
  3. 根据实际评审惯例确定数据新鲜度，而不是假设所有内容都必须实时更新。
  4. 当一个交付物不断吸纳彼此冲突的需求时，按受众拆分仪表板。
  5. 在每次重要的仪表板交接中注明负责人、注意事项和信任约定。
  6. 优先选择转交，而不是把分析、异常排查或可观测性工作都塞进这项技能。

参考资料

评论

支持 Markdown