tencent cloud

Tencent Cloud DataBuddy

ドキュメントTencent Cloud DataBuddyData GovernanceSemantic Model OverviewDefining Metrics and Dimensions

Defining Metrics and Dimensions

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-09 16:16:33
AI翻訳

Overview

This document describes how to define metrics and dimensions on a published semantic model. Metrics carry business-consumable numeric measures such as GMV, average order value, and DAU, while dimensions carry analytical slice perspectives such as region, category, and date. Metrics and dimensions are the smallest units exposed for downstream Buddy data retrieval and report display.
After creation, refer to Semantic Model Application to complete authorization and consumption.

Prerequisites

Before you start this operation, make sure the following prerequisites are met:
You have the Read Write or Read Write & Delete feature permission for Semantic Modeling → Metric Management.
You must have the Manage or CreateMetric permission on the target model (the Owner role includes these permissions by default). Otherwise, you cannot create metrics on that model.
The target model is already in the Published state.
To create a new dimension, you must also have the Read Write feature permission for Semantic Modeling → Dimension Management.

Use Limits

Limit
Description
Creation Permission
Creating a metric requires the CreateMetric or Manage permission on the model; creating a metric does not require the Select permission on the underlying table
Editing Mode
Metrics and dimensions are both edited through the YAML editor.
Dimension ACL
Dimensions do not support fine-grained ACL permissions in this release. All users with Read Write or Read Write & Delete feature permissions on "Semantic Modeling → Dimension Management" can edit and delete dimensions.

Two Types of Metrics

Metrics are business-consumable numeric measures defined on top of a model. Metrics are divided into two categories: atomic metrics and derived metrics.
Atomic metric (SIMPLE): the smallest statistical unit in a metric system, which performs aggregate calculations on a single field. For example, SUM(OrderAmount) represents the total transaction amount. Atomic metrics do not involve derived logic.
Derived metric: a metric processed from atomic metrics based on business rules, which is further divided into five types:
Filtered metric: a metric obtained by filtering atomic metrics based on specific dimensions such as time, region, or user attributes. For example, "Total Transaction Amount of Online Channels" = SUM(OrderAmount) with the filter Channel = Online.
Cumulative metric: a metric obtained by accumulating and aggregating atomic or filtered metrics over a time window. For example, "Total Transaction Amount of Online Channels in the Last 30 Days".
Period-over-period metric: a relative metric calculated by comparing cumulative metrics with data from the same period in the previous year (year-over-year) or the previous period (period-over-period). For example, "Period-over-Period Growth Rate of Total Transaction Amount of Online Channels in the Last 30 Days".
Hybrid calculated metric: a composite metric derived from two or more metrics through calculation rules such as addition, subtraction, multiplication, or division. For example, "Average Transaction Amount" = Total Transaction Amount / Number of Transactions.
Conversion calculated metric: a metric calculated from atomic or filtered metrics at different stages to measure the conversion efficiency from A to B in a process. For example, "Registration-to-Order Conversion Rate" = Number of Orders / Number of Registrations.
Aggregation methods supported by metrics include SUM, COUNT, COUNT(DISTINCT), MAX, MIN, AVG, and custom expressions.

Operation Steps

Step 1: Entering Metric Management

Enter the workspace and choose Ontology Modeling -> Metric Management from the left menu. This page displays all metrics visible to you in the current workspace in a list, with the following columns: Metric Name, Metric Alias, Metric Status, Metric Type, Derived Type, Definition, Associated Model, Source Table, Owner, and Last Modified Time.

Step 2: Initiating Metric Creation

Click + Create Metric (YAML) in the upper-right corner. A YAML editing panel slides out from the right. At the top of the panel, you are first prompted to select a data source.
Tip
We recommend using Hi Buddy to help generate metric YAML. Select the Hi Buddy entry from the left menu and describe the metric definition in natural language. For example, "Build a semantic model for sales analysis based on tables in the catalogname.olist_sales_database database, such as GMV, the number of return orders in the last 30 days, and average order value." AI then automatically analyzes the data warehouse metadata within the specified scope and generates a standards-compliant semantic model YAML file that includes metrics, dimensions, and relationship models.

Step 3: Writing the Metric YAML

Tip
Metrics referenced by the formula field in a derived metric YAML must be metrics that are already published under the same model or defined simultaneously in the same YAML. Otherwise, validation fails during publishing.

3.1 Complete YAML Example (Model + 6 Metric Types + 3 Dimension Types)

The following is a complete end-to-end example that declares a model (DEF), all six metric types (SIMPLE / FILTER / DERIVED / RATIO / CUMULATIVE / CONVERSION), and three dimension types (TIME / CATEGORICAL / DICT) in a single declaration. You can use it as a reference template when writing actual YAML files.
# ============================================================
# Complete Example of WeData Semantic Model YAML Configuration
# Version: 1.0
# Note: This YAML allows you to create semantic models, metrics, and dimensions all at once.
# ============================================================

# [Required] Configuration file version, fixed at 1.0.
version: 1.0

# ============================================================
# Semantic Model Definition (Optional)
# type: DEF - Create a model (a complete definition is required).
#       REF - Reference an existing model (only name + type required).
# ============================================================
model:
  # [Required] Model name in English, 1-50 characters, supporting letters, digits, underscores, and parentheses.
  name: ecommerce_order_model

  # [Optional] List of model aliases. Multiple aliases are supported, and commas are not allowed.
  # Defaults to name when empty. Stored as comma-separated values in the database.
  label:
    - E-commerce order model
    - order_model_alias

  # [Optional] Model description
  description: "The primary e-commerce order model, associated with the user table and the product table."

  # [Required] Model type: DEF (define a new model) | REF (reference an existing model).
  type: DEF

  # [Required for DEF] Path to the primary table data source. Format: catalogName.databaseName.tableName.
  source: default_catalog.ecommerce_db.orders

  # [Optional] JOIN table configuration. Nested JOINs are supported.
  joins:
    - name: user_table                                    # Alias of the joined table (required)
      source: default_catalog.ecommerce_db.users          # Path of the joined table (required)
      on:                                                 # Join condition (required, at least one)
        - source.user_id = user_table.id
      # Nested joins (optional)
      joins:
        - name: user_address
          source: default_catalog.ecommerce_db.addresses
          on:
            - user_table.id = user_address.user_id
    - name: product_table
      source: default_catalog.ecommerce_db.products
      on:
        - source.product_id = product_table.id

# ============================================================
# Metric definition list (optional)
# Supported types: SIMPLE | FILTER | DERIVED | RATIO | CUMULATIVE | CONVERSION
# ============================================================
metrics:
  # ----------------------------------------------------------
  # 1. Atomic metric (SIMPLE) - Basic aggregate metric
  # ----------------------------------------------------------
  - name: total_order_amount
    # [Optional] Metric alias list. Chinese characters, English letters, digits, underscores, and parentheses are supported. Commas are not allowed.
    label:
      - Total order amount
      - GMV
    description: "Calculates the total amount of all valid orders."
    # [Required] Metric type
    type: SIMPLE
    # [Required] Type parameter
    type_params:
      # [Optional] Referenced model. Specify the model name.
      # If not specified, the model defined in the current YAML is used by default.
      model_ref: ecommerce_order_model
      # [Required] Source table path. Format: catalogName.databaseName.tableName
      source_table: default_catalog.ecommerce_db.orders
      # [Required] Aggregate expression
      expr: "SUM(order_amount)"
      # [Required] Time dimension name. You must define the corresponding TIME dimension in dimensions.
      time_dimension: order_date
      # [Optional] Non-additive dimension configuration. Use this for semi-additive metrics, such as inventory snapshots.
      # non_additive_dimension:
      #   dimension: snapshot_date       # Dimension name (required)
      #   window_choice: MAX             # Window value: MIN | MAX (required)
      #   window_groupings:              # Window groupings (optional)
      #     - warehouse_id

  # ----------------------------------------------------------
  # 2. Filter metric (FILTER) - Adds filter conditions to an atomic metric.
  # ----------------------------------------------------------
  - name: paid_order_amount
    label:
      - Paid order amount
    description: "Calculates the total amount of orders in paid status only."
    type: FILTER
    type_params:
      # [Required] Filter condition expression
      filter: "status = 'PAID'"
      # [Required] List of dependent base metrics (at least one)
      metrics:
        - name: total_order_amount

  # ----------------------------------------------------------
  # 3. Hybrid calculated metric (DERIVED) - Multi-metric expression calculation.
  # ----------------------------------------------------------
  - name: avg_order_amount
    label:
      - Average order value per customer
    description: "Total order amount / Total number of orders"
    type: DERIVED
    type_params:
      # [Required] Calculation expression. Use metric names as variables.
      expr: "total_order_amount / order_count"
      # [Required] List of base metrics involved in the calculation (at least one)
      metrics:
        - name: total_order_amount
        - name: order_count

  # ----------------------------------------------------------
  # 4. Period-over-period metric (RATIO) - Time period comparison.
  # ----------------------------------------------------------
  - name: order_amount_yoy
    label:
      - Year-over-year order amount
    description: "Year-over-year growth rate of total order amount"
    type: RATIO
    type_params:
      # [Required] Calculation type: YEAR_ON_YEAR (year-over-year) | RELATIVE_RATIO (period-over-period)
      derived_type: YEAR_ON_YEAR
      # [Required] List of base metrics (at least one)
      metrics:
        - name: total_order_amount

  # ----------------------------------------------------------
  # 5. Cumulative metric (CUMULATIVE) - Time window accumulation.
  # ----------------------------------------------------------
  - name: weekly_order_amount
    label:
      - Order amount for the last 7 days
    description: "Cumulative order amount for the last 7 days"
    type: CUMULATIVE
    type_params:
      # [Required] Time window. Valid values:
      # MINUTE_5 | MINUTE_30 | HOUR_1 | DAY_1 | DAY_7 | DAY_30 | DAY_90 | DAY_180
      # WTD (week-to-date) | MTD (month-to-date) | QTD (quarter-to-date) | YTD (year-to-date) | HTD (history-to-date)
      window: DAY_7
      # [Optional] Additional filter conditions
      filter: "status IN ('PAID', 'SHIPPED')"
      # [Required] List of base metrics (at least one)
      metrics:
        - name: total_order_amount

  # ----------------------------------------------------------
  # 6. Conversion metric (CONVERSION) - Funnel conversion analysis.
  # ----------------------------------------------------------
  - name: view_to_purchase_rate
    label:
      - Browse-to-purchase conversion rate
    description: "Conversion rate from product browsing to purchase"
    type: CONVERSION
    type_params:
      # [Required] Base metric (funnel starting point)
      base_metric:
        name: page_view_count
      # [Required] Conversion metric (funnel endpoint)
      conversion_metric:
        name: purchase_count
      # [Required] Conversion entity type: FROM_ENTITY | FROM_DIMENSION
      conversion_entity_type: FROM_DIMENSION
      # [Optional] Conversion dimension (used when conversion_entity_type is FROM_DIMENSION)
      conversion_dimension: user_id
      # [Required] Calculation method: CONVERSIONS (conversion value) | CONVERSIONRATE (conversion rate)
      calculation: CONVERSIONRATE
      # [Optional] Window type: WINDOW (conversion within N time) | OFFSET (conversion at the Nth time)
      window_type: WINDOW
      # [Optional] Time window. Format: {number} {hour|day|week|month}
      window: "7 day"

  # ----------------------------------------------------------
  # 7. Conversion metric (CONVERSION) - FROM_ENTITY example
  # Associate base metrics with conversion metrics through entities (primary keys/associated keys).
  # ----------------------------------------------------------
  - name: register_to_order_conversions
    label:
      - Signup-to-order conversions
    description: "Number of conversions from registration to first order, associated through the user entity."
    type: CONVERSION
    type_params:
      # [Required] Base metric (funnel starting point)
      base_metric:
        name: user_register_count
      # [Required] Conversion metric (funnel endpoint)
      conversion_metric:
        name: total_order_amount
      # [Required] Conversion entity type: FROM_ENTITY indicates that two metrics are associated through an entity (primary key).
      # FROM_ENTITY: Two metrics are automatically associated through the same entity (such as user ID), so there is no need to specify conversion_dimension.
      # FROM_DIMENSION: You need to manually specify the conversion_dimension field to associate the metrics.
      conversion_entity_type: FROM_ENTITY
      # [Required] Calculation method: CONVERSIONS (number of conversions) | CONVERSIONRATE (conversion rate)
      calculation: CONVERSIONS
      # [Optional] Window type: WINDOW (conversion within N time) | OFFSET (conversion at the Nth time)
      window_type: OFFSET
      # [Optional] Time window. Format: {number} {hour|day|week|month}
      window: "30 day"

# ============================================================
# Dimension definition list (optional)
# Supported types: TIME | CATEGORICAL | DICT
# ============================================================
dimensions:
  # ----------------------------------------------------------
  # 1. Time dimension (TIME) - You must specify the time precision.
  # ----------------------------------------------------------
  - name: order_date
    # [Optional] List of dimension aliases. Multiple aliases are supported, and commas are not allowed.
    label:
      - Order date
      - Order time
    description: "Order creation time, accurate to the day"
    # [Required] Data source path. Format: catalogName.databaseName.tableName
    source: default_catalog.ecommerce_db.orders
    # [Required] Corresponding database column name
    col_name: created_time
    # [Required] Dimension type
    type: TIME
    # [Required for TIME type] Type parameter
    type_param:
      # Time precision. Valid values: YEAR | MONTH | DAY | HOUR | MINUTE | SECOND | MILLISECOND.
      time_precision: DAY

  # ----------------------------------------------------------
  # 2. Generic dimension (CATEGORICAL)
  # ----------------------------------------------------------
  - name: order_channel
    label:
      - Order channel
    description: "Order source channel: APP/PC/H5"
    source: default_catalog.ecommerce_db.orders
    col_name: channel
    type: CATEGORICAL
    # The CATEGORICAL type does not require type_param. Leave it empty.

  # ----------------------------------------------------------
  # 3. Dictionary dimension (DICT) - Associated dictionary table
  # ----------------------------------------------------------
  - name: order_status
    label:
      - Order status
    description: "Order status code, associated with a dictionary table"
    source: default_catalog.ecommerce_db.orders
    col_name: status_code
    type: DICT
    # [Required for DICT type] Type parameter
    type_param:
      dict_items:
      - key: Shipped
        value: Shipped
      - key: Completed
        value: Completed
      - key: Canceled
        value: Canceled
Example Description:
version: 1.0 is the configuration file version, fixed at 1.0.
When model.type = DEF, provide the complete model definition (source + joins). When it is changed to REF, only name + type are required, indicating a reference to an existing model.
The type_params structures of the six metric types vary:
SIMPLE is defined by expr (aggregate expression) + time_dimension;
FILTER adds filter conditions to the atomic metrics referenced by metrics;
DERIVED uses expr to reference other metric names for arithmetic operations;
RATIO uses derived_type (YEAR_ON_YEAR / RELATIVE_RATIO) to declare year-over-year or period-over-period comparison;
CUMULATIVE uses window (such as DAY_7 / MTD) to declare time window accumulation;
CONVERSION declares funnel conversion through base_metric / conversion_metric / conversion_entity_type / calculation / window.
The type_param structures of the three dimension types:
TIME requires time_precision (such as DAY / HOUR / MONTH);
CATEGORICAL has no type_param;
DICT declares key-value mappings through dict_items.

Step 4: Publishing the Metric

Click Publish in the upper-right corner of the editor:
1. The system first performs validation, including YAML syntax, model permissions (CreateMetric / Manage), whether the expression is executable in the underlying engine, and whether the dependent metrics exist.
2. After validation passes, the metric status changes to "Published" and the metric becomes immediately consumable in the metric management list.
3. Published metrics appear in the metric management list, can be viewed in the "Associated Metrics" Tab on the model details page, and can be consumed by other users based on Query permissions.

Step 5: Defining Global Dimensions (Optional)

Dimensions are workspace-level global dimensions. Whether created through YAML or in the "Dimension Management" tab, they are always global dimensions.
1. Switch to the Dimension Management Tab at the top of Semantic Modeling, and click + New Dimension.
2. Declare the dimension's English name, Chinese Tag, field type, source field, and other attributes in YAML.
3. Dimensions do not need to be published. They take effect immediately after being saved.
4. Reference global dimensions by name in the model YAML to avoid duplicate declarations.

Dimension Types

Dimensions are used to define analytical perspectives. Based on the business semantics of fields, common dimensions can be divided into the following categories:
Time dimension: date and time fields used to slice metrics by time windows. They support aggregation at different granularities such as day, week, month, quarter, and year, serving as the core slicing basis for trend analysis such as period-over-period comparisons and the last N days.
Example: order_date (order creation date) and pay_time (payment completion time), which are often sliced by day, week, or month.
Dictionary dimension: a dimension field with a fixed and enumerable value range, corresponding to business classification systems such as "Category" and "Brand". Its values typically come from dictionary tables or predefined enumerations, and the field value range is limited and stable, facilitating normalization and standardized management.
Example: category_name (product category), brand (brand), and gender (gender).
Generic dimension: a general-purpose dimension field used to describe attributes of business entities, without special time or dictionary semantics. Common examples include user name, age, and user ID.
Example: user_name (user name), age (age), and user_id (user ID).

Step 6: Transferring Metric Ownership (Optional)

Each metric can have only one owner, which defaults to the creator. On the metric details page, go to Caliber Name, then hover over the Owner field under Business Information on the right to display the edit icon. Click the icon, select the target owner, and submit. After the transfer, the original owner loses metric management permissions.

Metric Details Page

After a metric is published, you can click its name in the Metric Management list to go to the details page, where you can view, analyze, trace lineage, and grant authorization for the metric. The top of the details page displays basic metric information and action buttons, and the lower section is divided into four tabs: Caliber Details / Metric Analysis / Lineage / Permissions.
Top common area:
Left side: back arrow, metric name, and status badge (Published or Offline).
Breadcrumb: Semantic Modeling, Metric Management, Metric Name
Favorite button: Add to favorites for quick return.
Action buttons in the upper-right corner:
Edit: Enter the YAML editor, adjust the caliber, and publish again.
Take Offline: Set the metric status to Offline and stop external consumption.
Authorize: Open the authorization dialog to grant other users Manage or Query permissions. Note: This button is displayed only on the Permissions Tab of the metric details page.

Specification Details

The Caliber Details Tab is used to view all information about the metric definition and serves as an explanation page for what the metric is.
Caliber Description: A text description that explains the business meaning of the metric, for example, "The average number of behaviors per session, calculated as total behavior count divided by total sessions."
Calculation Caliber:
Metric type: Atomic, Filtered, Hybrid Calculation, Cumulative, Period-over-Period, or Conversion.
Model: The associated semantic model. Click it to go to the model details page.
Dependent Metrics: Derived metrics are displayed as cards, with one card for each dependent metric showing its name, status (Published or Offline), and English name.
Calculation Logic: A formula (for example, A / B) or a text description. Different calculation logic information is displayed for each metric type based on its type.
Preview SQL in the upper-right corner: displays the compiled query SQL of the metric for easier troubleshooting.
Analysis Dimensions: Lists the analysis dimensions supported by this metric. Fields include: Dimension Name, Dimension Alias, Description, Dimension Precision (such as minimum granularity), Dimension Information, Owner, Associated Fields, and Last Modified Time.
Business Information (right sidebar): Alias and Owner.
Technical Information (right sidebar): Metric Type, Metric Status, Last Updated Time, Last Updated By, Created Time, and Created By.

Metric Analysis

The Metric Analysis Tab is used to perform ad hoc queries on the current metric, verify its caliber, and quickly retrieve data. Two query modes are provided at the top:
Form Mode (suitable for users without SQL background):
Time Range: The default is the last 30 days, and you can customize the start and end dates.
Time Granularity: Day, Week, Month, Quarter, Year, Hour, and Minute (related to the minimum time granularity supported by each metric).
Maximum Records Returned: Adjustable, with a default of 30.
Dimensions: + Add dimensions and dimension values to group by the selected dimensions. Multiple selections are supported.
The Query and Reset buttons at the bottom trigger data retrieval.
SemQL Mode (suitable for users familiar with query syntax):
Write SemQL statements directly, for example:
select * from query(metric=[avg_session_behavior_count], limit=30)
The Query and Reset buttons at the bottom are also supported.
Both modes provide a Preview Query SQL entry in the upper-right corner for viewing the underlying physical SQL.

Lineage

The Lineage Tab displays the upstream and downstream data lineage of metrics, serving as a traceability page that shows where metrics come from and where they flow. It provides two views:
List mode (default): Lists upstream and downstream nodes in a list format.
Graph mode: Displays the lineage graphically, with arrows between nodes indicating the data flow direction. A typical lineage is illustrated as follows:
Upstream: Tables and views (2)  Semantic models (1)  Upstream: Metrics (2)         Current metric
┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────┐
│ Order fact table    │─>│ Customer   │─>│ metric.Session count │─>│ avg_se│
│ ODS data table    │  │ Behavior    │  │ metric.Behavior count │  │ count   │
└──────────────┘  └──────────────┘  └──────────────┘  └──────────┘
Each node supports clicking Details to go to the corresponding resource details page.
Top operations: Locate a specific node, zoom in, zoom out, fit to 1:1, and fullscreen.
Legend on the right: Lists all identifiable node types - data tables, view tables, machine learning models, metrics, semantic models, databases, NOTEBOOK, SQL, machine learning services, workflows, offline integration, and real-time integration.

Permission

The Permissions Tab is used to manage metric authorization relationships, corresponding to metric-level ACLs in the model layer.
List area:
Authorize button in the upper-right corner: Opens the authorization dialog box.
Search box: Filter by user.
Permission type filter: All permissions / Manage / Query
List columns: Authorized object, Type (User, Owner), Permission (Manage / Query), Dimension, Dimension value range (row-level permission), Grantor, Grant time, and Actions.
The Owner role is automatically granted to the creator and cannot be revoked. It is marked with an Owner badge in the list.
Authorization Dialog Box:
Field
Required
Description
Authorization subject
Yes
User, user group, or tag can be selected.
Authorized object
Yes
If User is selected as the authorization principal: a user selection panel is displayed, and user search is supported; add at least one user.
If User Group is selected as the authorization principal: a user group selection panel is displayed, and user group search is supported; add at least one user group.
If Tag is selected as the authorization principal: no authorization object needs to be selected; only select the authorization point below.
Permission point
Yes
Select at least one item; if none is selected, the submit button is grayed out and a message prompts "Please select a permission point." You can set row and column permissions for metrics that the authorization object can query.
Authorization reason
No
Multiline text for audit and business context description.
Permission Description:
Manage: Allows users to edit, publish, and take down metrics, as well as authorize other users.
Query: Allows users to query metric data and configure the dimension value range.

Creating Metrics and Dimensions via Buddy

Buddy has a built-in Skill for creating metrics and dimensions using natural language. It can identify common aggregation terms and field types, and generate YAML.

Sample Prompt for Creating a Metric

The more detailed the information you provide, the more accurate Buddy's output will be. A Prompt should include key elements such as the business meaning of the metric, its data source, model, aggregation expression, time field, filter conditions, and dependent metrics.
User input
In my olist_sales_model semantic model, add a gmv metric. The calculation logic is to sum the pay_amount field in the dlc.default_catalog.olist.orders table to calculate the total payment amount of all orders (total transaction value). Note that during calculation, exclude data from orders placed by internal customers (customer type is "internal").

Sample Prompt for Creating a Dimension

A dimension creation Prompt should include the dimension's English name and Chinese Tag, source table and field, data type, dictionary key-value pairs (if any), associated model, business description, and Owner.
User input
Create a "payment time" dimension with table name dlc.default_catalog.olist.orders, field name pay_time, minimum time granularity by DAY, indicating the actual time when an order payment is completed.

Must-Knows

To ensure that Buddy generates the expected YAML, specify key elements in the Prompt as much as possible:
1. Key Elements of Model Definition
To specify a data source, use the three-part table name format Table name in three-part notation: catalog.database.table, for example, dlc.default_catalog.olist.orders.
Field names must exactly match the actual column names in the underlying table to avoid spelling errors. If table names and field names are not specified, AI will infer them based on user input, but specifying them will produce more accurate results.
2. Key Elements of Metric Definition
Metric Description: Defines what this metric is used for, such as online channel transaction amount.
Caliber Description: Describes the business meaning, calculation logic (which can be natural language or statistical SQL), and usage scenarios of the metric. The more detailed the description, the more accurate the generated YAML.
3. Key Elements of Dimension Definition
Dimension Description: Describes what this dimension is, such as payment time and payment channel.
Source Table and Field: Use the three-part table name and actual field names as well. If not specified, AI will infer them based on the input, but specifying them will produce more accurate results.
4. Permissions and Publishing
Before generating YAML, Buddy verifies whether the current user has the CreateMetric permission on the target model. If not, the creation is denied.
After the YAML is generated, it will wait for user review and confirmation before being written. During the review, you can adjust the fields again before confirming.
After submission, the metric enters the "Published" state and can be consumed in the metric management list without any additional actions.

FAQs

Q1: Why does creating a metric show "Missing CreateMetric permission"? This indicates that you do not have the CreateMetric or Manage permission on the target model. Contact the model Owner to grant you the CreateMetric permission on the Authorization Tab of the model details page.
Q2: Can the formula of a derived metric reference metrics from other models? No. A derived metric can only reference metrics under the same model.
Q3: What should I do if metric publishing fails and shows "Expression validation failed"? Common causes include: ① A field in the expression does not exist in the underlying table. ② COUNT(DISTINCT) is not directly supported by some engines, so you need to confirm the deduplication syntax supported by the platform. ③ A function name in the custom SQL is not recognized by the engine. We recommend that you first verify that the expression can be executed by using the underlying table in the SQL editor before publishing.

References

What is a semantic model?
Create a semantic model.
Semantic Model Application
Buddy - Data Engineering Agent Overview
前の記事へ: Creating a Semantic Model次の記事へ: Creating and Managing Tag Systems

ヘルプとサポート

この記事はお役に立ちましたか？

フィードバック

キーワードで検索
    Enter keywords to search documentation