Automated metric attribution depends on a well-structured metric tree. Without one, attribution produces outputs that are technically correct but analytically useless: contribution scores for dimensions that do not actually explain the business question being asked, or decompositions that flatten a hierarchical KPI into components that do not add up to anything meaningful. A metric tree is the prerequisite that makes attribution outputs interpretable rather than just numerically complete.
This post covers what a metric tree is, how to structure one for attribution purposes, and the failure modes that cause metric trees to break down as organizations grow.
What a Metric Tree Is and Is Not
A metric tree is a hierarchical decomposition of a top-level KPI into the sub-metrics and dimensions that mathematically compose it. The word "tree" implies a strict parent-child structure where parent metrics are computed as functions of their children. The tree is a mathematical claim: "revenue equals the product of average order value and order count." If that equation does not hold in your data, the tree is wrong and attribution outputs derived from it will be wrong by the same degree.
A metric tree is not the same as a dashboard hierarchy. Dashboards group metrics by theme (acquisition, engagement, revenue) and display them together because they are related. That relationship is conceptual, not mathematical. A metric tree requires that the relationship between levels be a specific computable function, usually a sum, product, or ratio.
It is also not the same as a KPI list. A list of metrics like "DAU, conversion rate, revenue, NPS" is a collection of measures. A metric tree takes a root metric and makes explicit how each sub-metric affects it. If NPS does not have a defined mathematical relationship to revenue in your model, it is not part of the revenue metric tree, even if the business believes it influences revenue.
Types of Metric Decomposition
There are three primary decomposition structures used in practice, and the attribution algorithm needs to know which one applies to each metric in the tree.
Additive decomposition: a metric is the sum of its children. Total revenue is the sum of revenue from each product line. Order count is the sum of orders from each acquisition channel. Attribution across additive metrics is straightforward: each child's contribution is its share of the total delta.
Multiplicative decomposition: a metric is the product of its children. Revenue equals conversion rate multiplied by session count multiplied by average order value. This is the most common structure for top-level KPIs. Attribution in multiplicative decompositions requires care because a change in the multiplicative metric can be driven by changes in one, several, or all factors simultaneously, and the interaction effects need to be properly allocated.
Ratio metrics: metrics defined as numerator divided by denominator, where both numerator and denominator can move independently. Conversion rate (conversions divided by sessions), average order value (revenue divided by orders), churn rate (churned users divided by total users). Attribution on ratio metrics requires decomposing the delta of the ratio into numerator effects and denominator effects, which is a standard finite difference calculation.
For a ratio metric R = N / D, the delta can be decomposed as approximately:
delta_R ≈ (delta_N / D_baseline) - (N_baseline * delta_D / D_baseline^2)
= (1 / D_baseline) * delta_N - (N_baseline / D_baseline^2) * delta_D
= (1 / D_baseline) * delta_N - (R_baseline / D_baseline) * delta_DThe first term is the numerator contribution and the second term is the denominator contribution. Both are expressed in ratio-point units. Summing them gives the total ratio delta. Attribution systems that skip this decomposition and treat ratio metrics as atomic values produce contribution scores that do not sum to the actual metric movement, which undermines interpretability.
Dimension Layers in a Metric Tree
Each leaf metric in the tree can be further decomposed by dimensions: geographic region, device type, acquisition channel, user cohort, product category, and so on. These are not additional tree levels; they are cross-sections of the leaf metrics. The attribution algorithm applies dimensional decomposition at each leaf, then aggregates dimensional contributions up the tree according to the decomposition type (additive, multiplicative, or ratio) at each level.
The dimensions available for attribution at a given leaf are determined by what columns exist on the fact table that underlies that metric. An order count metric backed by a fact_orders table can be decomposed by any column in that table: acquisition_channel, customer_country, product_category, and so on. A session count metric backed by a different fact table has its own available dimensions, which may partially overlap with the order fact table's dimensions but will not be identical.
This is where metric tree design and data model design intersect. If you want to attribute revenue changes to the same dimensional taxonomy across the full revenue tree (acquisition channel, geography, product), those dimensions need to be consistently defined and available on every fact table that underlies a revenue tree metric. Dimensional consistency across fact tables is a data modeling decision, not an analytics decision, but it is the prerequisite for coherent tree-level attribution.
Failure Modes as Organizations Grow
The most common failure mode is metric definition drift. A metric tree defined when a company had one product line becomes incoherent when a second product line with a different revenue model is introduced. The additive decomposition of revenue assumed that all revenue components were commensurable; once a subscription component is added alongside transaction revenue, simply summing them produces a number whose attribution is not interpretable in terms of either component's drivers.
The fix is not to add the new component to the existing tree. It is to recognize that the root metric needs to be redefined: either as the sum of two distinct metric trees (transaction revenue tree plus subscription revenue tree), or with a new intermediate node that explicitly handles the composition. This is a deliberate design choice that requires organizational agreement about what the KPI means, not just a data model update.
A second failure mode is ownership fragmentation. Metric trees have owners at each level, and when different teams own different branches of the tree, the definitions can drift independently. The attribution team might define "activation" one way for their branch; the product team defines it differently for theirs. Both definitions are in the metric catalog. When a root-level KPI that depends on activation is attributed, the system has to pick one definition. If the choice is implicit, attribution results will silently reflect whichever definition the data model happens to use, and stakeholders in different teams will interpret the same output differently.
Resolving this requires governance that is organizationally uncomfortable but technically straightforward: one canonical definition per metric, with a designated owner, and a change process that requires cross-team coordination. Attribution systems can surface conflicts in metric definitions (multiple models returning different values for the same metric name) but cannot resolve them on your behalf.
Structuring a Metric Tree for Attribution Use
When building a metric tree with attribution as the primary use case, the design considerations differ slightly from a tree built primarily for reporting.
First, keep the tree as shallow as possible while still capturing the causal structure you care about. Each additional level multiplies the number of decomposition steps the attribution algorithm must perform. A tree with four levels is not four times harder to attribute than a two-level tree, but the complexity of correctly allocating interaction effects compounds. Two or three levels is usually sufficient for most attribution questions about top-line KPIs.
Second, prefer additive decompositions where mathematically valid over multiplicative ones. Additive trees are simpler to attribute, easier to explain, and less prone to interaction-effect allocation debates. Not all KPIs can be additively decomposed; revenue is typically multiplicative. But sub-metrics often can be: "new user activations" can be decomposed additively by acquisition channel, and the attribution is unambiguous.
Third, make the dimensional schema explicit in the tree definition itself, not left to discovery at query time. For each leaf metric, the metric definition should specify which dimensions are valid attribution candidates for that metric. This is a constraint on the attribution layer, not a technical limitation. It prevents attribution runs from returning contribution scores for dimensions that are present on the fact table but not meaningful drivers of the metric in question. A session count metric can technically be attributed by server region if that column is on the session fact table, but if server region has no causal relationship to session count, including it pollutes the attribution output with noise.
A metric tree that has been built with these constraints produces attribution outputs that are immediately legible to the people asking the business questions, rather than outputs that require extensive interpretation before they can be used. That interpretability is the difference between attribution that changes decisions and attribution that gets filed in a Notion doc and not acted on.