Skip to content

Attribution Metric Rules

Overview

Multidimensional attribution does not support every metric. The system uses a set of rules to determine whether a metric can be used for multidimensional attribution analysis. The decision process has two steps: blacklist exclusion -> attribution rule matching.

Decision Process

Metric -> Blacklist check (not attributable?) -> Attribution rule matching (ADD / MUL / DIV / MIX) -> Is the rule enabled?

  1. The system first checks whether the metric matches the blacklist. If it does, the metric is directly determined to be unsupported for attribution.

  2. If the metric does not match the blacklist, the system matches attribution rules in priority order: addition (ADD) -> multiplication (MUL) -> division (DIV) -> mixed (MIX).

  3. The matched rule type takes effect only if it is included in the backend enabled_attribution_rules configuration. By default, only ADD is enabled. Configure ALL to enable all rule types.

1. Metrics That Do Not Support Attribution (Blacklist)

The following metric types are blocked by blacklist rules and cannot be used for multidimensional attribution.

1. Atomic Metrics Whose Aggregate Function Is Not in the Allowlist

For aggregate functions used in atomic metric expressions, only the following four functions are allowed for attribution:

Allowed Aggregate Function Description
SUM Sum
COUNT Count
COUNT_DISTINCT / COUNTDISTINCT Distinct count

If another aggregate function is used, such as AVG, MAX, MIN, or PERCENTILE, attribution is not supported.

Example: avg([t_order/amount]) -> not supported; sum([t_order/amount]) -> supported

2. Derived Metrics That Contain Multi-Layer Time Limits (PreAggs)

If a derived metric definition contains preAggs (pre-aggregation or multi-layer time limits), attribution is not supported.

Example: a derived metric that adds another aggregation layer on top of a time limit, such as "monthly average daily order volume", belongs to multi-layer time limits.

3. Derived Metrics That Contain Derivations (Indirection)

If a derived metric definition contains indirection, such as an indirect derivation for period-over-period comparison, attribution is not supported.

Example: a metric configured with a "same period last month" derivation -> not supported.

4. Composite Metrics Whose Expression Contains Function Calls

If the formula expression of a composite metric contains function calls (CALL_OP nodes), attribution is not supported.

Example: IF([Metric A] > 100, [Metric B], [Metric C]) -> contains an IF function and is not supported.

2. Metrics That Support Attribution and Attribution Types

After the blacklist check passes, the system further determines the metric's attribution type. The attribution type determines the analysis method used during factor decomposition.

1. Addition Attribution (ADD)

Applicable scope: the default attribution method for most metrics.

  • Atomic metrics: atomic metrics whose aggregate function is SUM / COUNT / COUNT_DISTINCT match the addition rule after passing the blacklist.

  • Derived metrics: derived metrics with a normal time limit (period) and without preAggs or indirection.

  • Composite metrics: composite metrics whose expressions contain only + and - operations.

Example: [Order Volume] + [Refund Order Volume] -> addition attribution

2. Multiplication Attribution (MUL)

  • Composite metrics: composite metrics whose expressions contain only * operations.

Example: [Average Order Value] * [Customer Count] -> multiplication attribution

3. Division Attribution (DIV)

  • Composite metrics: composite metrics whose expressions contain only / operations.

Example: [Total Amount] / [Order Count] -> division attribution

4. Mixed Attribution (MIX)

  • Composite metrics: composite metrics whose expressions contain a combination of multiple operations among +, -, *, and /.

Example: [Unit Price] * [Quantity] + [Shipping Fee] -> mixed attribution

3. Backend Configuration

Whether an attribution rule type takes effect is controlled by the Nacos configuration item:

# Attribution Metric Rules
enabled_attribution_rules=ADD

# Enable addition and division
enabled_attribution_rules=ADD,DIV

# Enable all attribution types
enabled_attribution_rules=ALL

Even if a metric passes rule matching, if the matched attribution type is not in the enabled list, the system still returns "attribution not supported".

4. Decision Flowchart

                        ┌──────────────┐
                        │ Input metric │
                        └──────┬───────┘
                               │
                    ┌──────────▼──────────┐
                    │ Determine metric type│
                    └──┬───────┬───────┬──┘
                       │       │       │
                ┌──────▼──┐ ┌──▼───┐ ┌─▼────────┐
                │ Atomic  │ │Derived│ │ Composite│
                └──┬──────┘ └──┬───┘ └──┬────────┘
                   │           │        │
          ┌────────▼────┐  ┌──▼─────────▼──────────┐
          │ Aggregate    │  │ Contains preAggs /    │
          │ function in  │  │ indirection / function?│
          │ allowlist?   │  └──┬────────────┬───────┘
          └──┬──────┬───┘     │            │
             │      │         │            │
          Yes│   No │      No │         Yes│
             │      │         │            │
             │  ┌───▼───┐    │     ┌──────▼──────┐
             │  │Unsupported│ │     │ Unsupported │
             │  └───────┘    │     └─────────────┘
             │               │
             └───────┬───────┘
                     │
          ┌──────────▼──────────┐
          │ Composite metric:   │
          │ analyze operators   │
          │ ┌─────────────────┐ │
          │ │ Only +- -> ADD  │ │
          │ │ Only *  -> MUL  │ │
          │ │ Only /  -> DIV  │ │
          │ │ Mixed   -> MIX  │ │
          │ └─────────────────┘ │
          │ Atomic/derived -> ADD│
          └──────────┬──────────┘
                     │
          ┌──────────▼──────────┐
          │ Attribution type in │
          │ enabled_attribution │
          │ _rules config?      │
          └──┬──────────────┬───┘
          Yes│           No │
             │              │
      ┌──────▼──────┐  ┌───▼───┐
      │ Attribution │  │Unsupported│
      │ supported   │  └───────┘
      └─────────────┘

5. FAQ

Q: Why can SUM atomic metrics be used for attribution, while AVG metrics cannot?

A: The core of multidimensional attribution is decomposing an overall metric value across dimensions, which requires the metric value to be additive. SUM and COUNT satisfy "whole = sum of parts", while AVG, MAX, and MIN do not. After decomposition, the overall value cannot be mathematically reconstructed.

Q: Can a derived metric with a time limit, such as "orders this month", be used for attribution?

A: Yes. As long as the derived metric does not have multi-layer time limits (preAggs) or derivations (indirection), it is not blocked by the blacklist and can be used for attribution normally.

Q: Can the composite metric [Metric A] / [Metric B] be used for attribution?

A: It depends on the backend configuration. This metric matches the division attribution (DIV) type, so enabled_attribution_rules must include DIV or ALL for it to take effect. The default configuration enables only ADD.