Back to Details

sf-datacloud-analytics

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

sf-datacloud-analytics

sf-datacloud-analytics

Use this skill for the Data 360 reports and dashboards plane.
Beast references:
  • Beast preflight: docs/beast-preflight.md
  • Phase proof matrix: docs/phase-proof-matrix.json
  • Public operating model: docs/operating-model.md
  • Developer Guide index: docs/data360/developer/index.md
  • Proof ledger: docs/proof-ledger.md
  • Public LLM map: docs/llms.txt
  • Limits source precedence: docs/data360/limits-source-precedence.md
  • For exact Salesforce behavior, fetch official Help/Developer docs on demand with 
    sf-docs
    .
  • For endpoint shape, use OpenAPI from the official spec or the user-supplied Swagger before writing payloads.
本技能适用于Data 360报表与仪表盘领域。
Beast参考资料：
  • Beast预检查：docs/beast-preflight.md
  • 阶段验证矩阵：docs/phase-proof-matrix.json
  • 公开运营模型：docs/operating-model.md
  • 开发者指南索引：docs/data360/developer/index.md
  • 验证台账：docs/proof-ledger.md
  • 公开LLM映射：docs/llms.txt
  • 限制源优先级：docs/data360/limits-source-precedence.md
  • 如需了解Salesforce确切行为，可通过
    sf-docs
    按需获取官方帮助/开发者文档。
  • 在编写负载前，优先使用官方规范中的OpenAPI或用户提供的Swagger来确定端点格式。

Production Workflow

生产工作流

  1. Identify the analytics source:
    • single DMO
    • related DMOs through a custom report type
    • calculated insight object
    • semantic data model
    • consumption / billing dashboard
  2. Confirm reportability, data space access, and folder permissions.
  3. Pick the report grain and grouping before building charts.
  4. For calculated insights:
    • measures are aggregates
    • dimensions are groupings
    • reports are summary-style
    • non-aggregatable measures require all required dimensions
    • details-only export and row-level formulas are restricted
  5. Build dashboards from validated reports, not directly from untested query assumptions.
  6. Test dashboards with a business user and a non-admin user.
  7. After policy changes, refresh dashboards or clear cache before concluding governance is wrong.
  8. Package/report distribution uses semantic model or Data 360 packaging rules where applicable.
  1. 确定分析数据源：
    • 单个DMO
    • 通过自定义报表类型关联的多个DMO
    • 计算洞察对象
    • 语义数据模型
    • 消费/计费仪表盘
  2. 确认可报告性、数据空间访问权限和文件夹权限。
  3. 在构建图表前选择报表粒度和分组方式。
  4. 针对计算洞察：
    • 度量值为聚合值
    • 维度为分组项
    • 报表为摘要样式
    • 不可聚合的度量值需要包含所有必填维度
    • 仅详情导出和行级公式会受到限制
  5. 基于已验证的报表构建仪表盘，而非直接基于未测试的查询假设。
  6. 联合业务用户和非管理员用户测试仪表盘。
  7. 策略变更后，先刷新仪表盘或清除缓存，再判断治理规则是否存在问题。
  8. 打包/报表分发时，适用语义模型或Data 360打包规则。

Design Rules

设计规则

  • Use the semantic layer when multiple teams need one governed KPI definition.
  • Use calculated insights when the report metric needs heavy joins, windows, or multidimensional measures.
  • Query Editor validates SQL and data assumptions; Data Explorer validates DLOs, DMOs, CIOs, and data graphs before reports consume them.
  • Profile Explorer is the validation surface for unified profile views and related Lightning apps.
  • Treat Tableau Semantics as the governed source for metrics used across reports, Tableau Next, AI, and apps.
  • Treat analytics as its own serving path. Query Editor success is a useful control, but reports, dashboards, semantic models, Tableau-style consumption, cache, refresh cadence, and target-user governance must be validated directly.
  • Avoid dashboards that mix incompatible grains without clear labels.
  • Keep row counts, refresh cadence, and credit/usage implications visible to admins.
  • Treat query, report, dashboard, and semantic model design as credit-sensitive: filter early, select only necessary fields, avoid high-cardinality scans, and validate expected consumption impact when the workload is large or recurring.
  • For executive dashboards, include metric owner and data freshness.
  • 当多个团队需要统一的受治理KPI定义时，使用语义层。
  • 当报表指标需要复杂关联、窗口函数或多维度量值时，使用计算洞察。
  • 查询编辑器验证SQL和数据假设；数据资源管理器在报表使用DLO、DMO、CIO和数据图谱前对其进行验证。
  • 配置文件资源管理器是统一配置文件视图及相关Lightning应用的验证界面。
  • 将Tableau Semantics视为跨报表、Tableau Next、AI和应用使用的指标的受治理数据源。
  • 将分析视为独立的服务路径。查询编辑器执行成功是一项有用的控制手段，但必须直接验证报表、仪表盘、语义模型、Tableau风格消费、缓存、刷新节奏和目标用户治理规则。
  • 避免混合不兼容粒度且未标注清晰标签的仪表盘。
  • 向管理员展示行计数、刷新节奏和信用/使用影响。
  • 将查询、报表、仪表盘和语义模型设计视为对信用敏感的操作： 尽早过滤数据，仅选择必要字段，避免高基数扫描， 当工作负载较大或重复运行时，验证预期的消费影响。
  • 针对高管仪表盘，需包含指标所有者和数据新鲜度信息。

Validation Gates

验证关卡

  • Report totals match a control query or source system export.
  • Filters and dashboard components preserve the intended grain.
  • Data space and governance policies are verified with target users.
  • Admin report-builder visibility is not treated as runtime access proof.
  • Dashboard loads acceptably and avoids excessive high-cardinality groupings.
  • Calculated insight reports follow CI report limitations.
  • 报表总计与控制查询或源系统导出数据匹配。
  • 筛选器和仪表盘组件保留预期的粒度。
  • 与目标用户验证数据空间和治理策略。
  • 管理员报表构建者的可见性不能作为运行时访问权限的证明。
  • 仪表盘加载速度符合要求，避免过多高基数分组。
  • 计算洞察报表遵循CI报表限制。

Handoffs

交接路径

  • Metric modeling -> sf-datacloud-semantic-layer
  • CI-backed reports -> sf-datacloud-calculated-insights
  • Permission troubleshooting -> 
    sf-permissions
    companion skill when available
  • Data 360 policy behavior -> sf-datacloud-governance
  • 指标建模 -> sf-datacloud-semantic-layer
  • 基于CI的报表 -> sf-datacloud-calculated-insights
  • 权限排查 -> 若可用，使用
    sf-permissions
    配套技能
  • Data 360策略行为 -> sf-datacloud-governance

Output Format

输出格式

Report:
  1. source object/model
  2. report type
  3. grain and groupings
  4. measures/KPIs
  5. dashboard components
  6. permission/folder setup
  7. validation query/results
  8. limits and consumption notes
报表：
  1. 源对象/模型
  2. 报表类型
  3. 粒度和分组方式
  4. 度量值/KPI
  5. 仪表盘组件
  6. 权限/文件夹设置
  7. 验证查询/结果
  8. 限制和消费说明

Doc-Synced Notes

文档同步说明

<!-- SF_DOC_SYNC_START:analyze-data -->
<!-- SF_DOC_SYNC_START:analyze-data -->

Analyze Data from Data 360

从Data 360分析数据

Distilled from official Salesforce sources only.
Sources:
  • Help "Analyze Data from Data 360" section
  • developer.salesforce.com/docs/data/data-cloud-dev/guide/dc-cost-usage.html — Cost and Usage
  • developer.salesforce.com/docs/data/data-cloud-query-guide/references — Query Data in Data 360
Two report types in Data 360:
TypeSourceBest for
Standard ReportOne DMO, semantic model, or CIOSingle-source analysis (Engagement, Account, CI metric)
Custom ReportUp to 4 related DMOsJoined views (Individual + Engagement + Order + Product)
Beyond 4 DMOs, push the join into a Calculated Insight or Semantic Model and report on the result.
Reportable surfaces (priority order):
  1. Semantic Model metrics — best for governed cross-team KPIs.
  2. Calculated Insights — best for heavy joins, windows, custom logic.
  3. Standard DMOs — Profile, Engagement, Other categories all reportable with appropriate licensing.
  4. Data Lake Objects (DLOs) — limited reporting surface; prefer DMO.
Dashboard limits to know (Salesforce platform-wide):
  • Dashboard component cap: 1,000 groupings per component.
  • Report viewer rows: 2,000 rows displayed.
  • Summary/Matrix grouping cap: 2,000 groupings.
  • Analytics REST API: 2,000-row limit per call.
  • Calculated Insights API: 4,999 rows per query call (different limit).
Analytics tool integration:
ToolHow it consumes Data 360
Data 360 Reports & DashboardsNative reporting on DMOs/CIs/semantic models — no external license
Tableau NextPersonalized contextual insights, deep Data 360 integration
Tableau (legacy)JDBC + Tableau Semantics; full visualization platform
CRM Analytics"Direct Data for Data 360" — real-time queries, no preload
Power BI XMLAXMLA endpoint via the Microsoft Power BI XMLA Connector
Custom appsConnect API + Query API for embedded analytics
KPI Dashboards (consumption insights):
  • Data 360 emits credit consumption events across these usage families:
    • Analyze and Predict — batch + streaming CIs.
    • Act — data queries (reports, dashboards), streaming actions.
    • Segment and Activate — segment processing, activations.
  • A single feature can consume from multiple usage types simultaneously.
  • Reference the Data 360 Billable Usage Types page in Help and the Data 360 Limits and Guidelines page when sizing dashboard refresh cadence.
  • Build a dedicated "Data 360 Consumption" dashboard early — make credit usage visible to admins before scaling.
Standard DMOs heavily used in dashboards:
  • Engagement: Email Engagement, Web Engagement, Product Browse, Order
  • Profile: Individual, Account, Contact Point Email/Phone/Address
  • Service: Case, Service Appointment
  • Consent: Consent Log, Communication Subscription Consent
Best practices:
  • Build the validation query in Query Editor first; compare to the report total before publishing.
  • Filter early — top-of-report filters reduce credit consumption more than dashboard-level filters.
  • Avoid 
    SELECT *
    in custom report types; explicit fields preserve FLS and reduce credit usage.
  • Tag every published dashboard with metric owner, data freshness, and refresh cadence.
  • For executive dashboards, prefer semantic-model-backed reports — the metric definition is governed and shared.
  • Test dashboards with a business user AND a non-admin user; admin view is not governance proof.
Calculated Insight report restrictions:
  • Non-aggregatable CI measures require all CI required dimensions to be present in the report grouping.
  • Detail-only export from a CI report can be restricted.
  • Row-level formulas on CI fields can be restricted; build derived measures in the CI itself.
Semantic Model analytics:
  • Tableau Semantics provides metric governance — same metric definition across Tableau, Tableau Next, AI prompts, and CRM Analytics.
  • Use it for "single source of truth" KPIs.
  • See sf-datacloud-semantic-layer for authoring details.
<!-- SF_DOC_SYNC_END:analyze-data -->
仅提炼自Salesforce官方来源。
来源：
  • Help文档中的“从Data 360分析数据”章节
  • developer.salesforce.com/docs/data/data-cloud-dev/guide/dc-cost-usage.html — 成本与使用情况
  • developer.salesforce.com/docs/data/data-cloud-query-guide/references — 在Data 360中查询数据
Data 360中的两种报表类型：
类型数据源适用场景
Standard Report单个DMO、语义模型或CIO单源分析（参与度、客户账户、CI指标）
Custom Report最多4个关联DMO关联视图（个人+参与度+订单+产品）
若关联DMO超过4个，需将关联逻辑整合到计算洞察或语义模型中，再基于结果制作报表。
可报告界面（优先级排序）：
  1. 语义模型指标 — 最适用于受治理的跨团队KPI。
  2. 计算洞察 — 最适用于复杂关联、窗口函数、自定义逻辑。
  3. 标准DMO — 配置文件、参与度及其他类别均支持报告，需具备相应许可。
  4. 数据湖对象（DLO） — 报告界面有限；优先使用DMO。
需了解的仪表盘限制（Salesforce全平台）：
  • 仪表盘组件上限：每个组件1000个分组。
  • 报表查看器行数：显示2000行。
  • 摘要/矩阵分组上限：2000个分组。
  • Analytics REST API：每次调用2000行限制。
  • Calculated Insights API：每次查询调用4999行（不同限制）。
分析工具集成：
工具如何消费Data 360数据
Data 360 Reports & Dashboards基于DMO/CI/语义模型的原生报告 — 无需外部许可
Tableau Next个性化上下文洞察，深度集成Data 360
Tableau（旧版）JDBC + Tableau Semantics；完整可视化平台
CRM Analytics"Data 360直接数据" — 实时查询，无需预加载
Power BI XMLA通过Microsoft Power BI XMLA连接器连接XMLA端点
自定义应用连接API + 查询API实现嵌入式分析
KPI仪表盘（消费洞察）：
  • Data 360会在以下使用类别中生成信用消费事件：
    • 分析与预测 — 批量+流式CI。
    • 执行 — 数据查询（报表、仪表盘）、流式操作。
    • 细分与激活 — 细分处理、激活操作。
  • 单个功能可能同时消耗多种类型的信用。
  • 确定仪表盘刷新节奏时，参考Help文档中的Data 360计费使用类型页面以及Data 360限制与指南页面。
  • 尽早构建专用的“Data 360消费”仪表盘 — 在扩缩容前让管理员可见信用使用情况。
仪表盘中常用的标准DMO：
  • 参与度：邮件参与度、网页参与度、产品浏览、订单
  • 配置文件：个人、客户账户、联络点邮箱/电话/地址
  • 服务：案例、服务预约
  • 同意：同意日志、通信订阅同意
最佳实践：
  • 先在查询编辑器中构建验证查询；发布前与报表总计进行对比。
  • 尽早过滤数据 — 报表顶部的筛选器比仪表盘级筛选器更能减少信用消耗。
  • 在自定义报表类型中避免使用
    SELECT *
    ；明确指定字段可保留FLS并减少信用消耗。
  • 为每个已发布的仪表盘添加指标所有者、数据新鲜度和刷新节奏标签。
  • 针对高管仪表盘，优先使用基于语义模型的报表 — 指标定义受治理且可共享。
  • 联合业务用户和非管理员用户测试仪表盘；管理员视图不能作为治理合规的证明。
计算洞察报表限制：
  • 不可聚合的CI度量值要求报表分组中包含所有CI必填维度。
  • CI报表的仅详情导出可能受到限制。
  • CI字段的行级公式可能受到限制；应在CI中构建派生度量值。
语义模型分析：
  • Tableau Semantics提供指标治理 — 在Tableau、Tableau Next、AI提示和CRM Analytics中使用相同的指标定义。
  • 适用于“单一事实来源”KPI。
  • 关于创作细节，请查看sf-datacloud-semantic-layer
<!-- SF_DOC_SYNC_END:analyze-data -->