Hello, we've been hitting HTTP 400 errors when combining measures from two different fact datasets in a single query. We did some testing to narrow it down and wanted to get your input on best practices. The error is: "Aggregation dimension is not comparable to the dimensionality of the subtree" We found that cross-fact queries work when two fact datasets share a row-level key dimension (one fact row maps to exactly one row in the other fact). But they fail when the two facts only share a higher-level grouping dimension, even when both fact datasets have their date instances wired directly on the fact. A few questions: 1. Is that behavior expected? Is cross-fact querying only supported when the shared dimension is at row-level grain? 2. If combining measures from facts that share a higher-level dimension isn't supported natively, what's the recommended pattern? Pre-aggregating in dbt into a single denormalized fact before it lands in GoodData? 3. Does GoodData have any native LDM construct for this (multi-source datasets, etc.) that we might be missing before we go down the ETL route? Thanks!

Cross-Fact Query Behavior in GoodData Great questions — let me address each one based on what the knowledge sources cover. 1. Is that behavior expected? Yes, this is expected behavior. GoodData can only combine objects from different datasets when they are connected through a single, unambiguous relationship path and share a compatible grain. When you add attributes or facts from datasets that are at different grains — or where the only shared dimension is at a higher level of aggregation than the individual fact rows — GoodData will hide or reject the combination to prevent incorrect results. [Community Slack] The core rule is: fact datasets should not be connected directly to other fact datasets, and relationships must allow a single, clear path between the objects you want to analyze together. [Community Slack] 2. Recommended pattern when facts only share a higher-level dimension The knowledge sources confirm that without a proper model relationship, combining such data is not directly supported in GoodData metrics or visualizations. The recommended approaches are: • Pre-join / pre-aggregate in your data source or ETL (e.g., dbt): Create a single denormalized fact or a pre-aggregated table at the shared grain before it lands in GoodData. This is described as the "most robust solution." [Community Slack] • Create separate metrics and accept limitations: You can build separate metrics for each fact dataset, but you won't be able to compute derived metrics (like averages across both) in a single visualization unless the datasets are related. [Community Slack] • Use a shared conformed dimension: Extract the shared higher-level grouping into a dedicated dimension dataset and reference it from both fact tables. This is the standard pattern for enabling cross-fact filtering and visualization. [Community Slack] 3. Native LDM constructs to consider before going the ETL route There are a couple of native GoodData features worth evaluating: • Data Blending (Multiple Data Sources in LDM): GoodData supports blending metrics from different data sources in a single visualization using shared conformed dimension attributes (e.g., a common date dimension or a shared primary key dimension). Metrics are aggregated independently per source and then joined after aggregation on the shared dimension. [Advanced Modelling Use Cases]Key limitations of data blending to be aware of: ◦ Only fact-based metrics can be used. ◦ Metrics can only be sliced/filtered using attributes that are references to common dimension datasets present in each data source. ◦ Only one data source change is allowed in a single relationship path. [Advanced Modelling Use Cases] • Aggregate Awareness: If your use case involves pre-aggregated tables (e.g., monthly summaries), GoodData's Aggregate Awareness feature can route queries to the most efficient pre-aggregated dataset. However, note it currently only supports additive metrics (

SUM

,

MIN

,

MAX

) — not

COUNT DISTINCT

or

AVERAGE

. [Aggregate Awareness] Summary I'd suggest first trying the shared conformed dimension approach in the LDM before committing to ETL denormalization — it may resolve your issue without additional data movement. If the grain mismatch is fundamental, pre-aggregating in dbt to a single fact at the shared grain is the most reliable path. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed., with interactive elements

@kapa.ai A couple of follow-ups: 1. On Data Blending: this only applies when combining metrics from different database connections (e.g. Snowflake + BigQuery), right? If all our fact tables live in the same Snowflake connection, data blending isn't relevant to our situation? 2. On the pre-aggregate in dbt path: if we build a denormalized daily fact table in dbt that combines invoice revenue and labor hours at a shared grain, and register it as a single GoodData dataset, would that resolve the cross-fact issue and allow those metrics to be queried together in one visualization?

Follow-up Answers 1. Data Blending and Same-Connection Fact Tables You are correct in your understanding. Data Blending in GoodData is specifically designed for combining metrics from different data sources (i.e., different database connections). The knowledge sources describe it as a feature for creating visualizations using metrics "computed from multiple data sources" and blending them via shared conformed dimension attributes. [Advanced Modelling Use Cases] If all your fact tables live within the same Snowflake connection, Data Blending is not the relevant feature here — your cross-fact grain issue is a standard LDM modelling problem, not a multi-source one. 2. Pre-aggregated dbt Fact Table as a Single GoodData Dataset The knowledge sources do not explicitly describe this exact dbt-to-GoodData registration pattern, so I want to be transparent about that limitation. However, based on what the knowledge sources do confirm: • GoodData metrics and visualizations rely on relationships defined in the LDM, and combining data from unrelated datasets is not natively supported without a defined relationship path. [Community Slack] • The recommended and "most robust solution" for combining data from unrelated tables is to pre-join in the source or ETL process so that the data arrives in GoodData already at a shared grain. [Community Slack] • GoodData's fact dataset model requires that all facts in the same fact table are at the same level of detail (grain) and from the same business process. [Fact Concepts] So logically, if you build a single denormalized daily fact table in dbt that combines invoice revenue and labor hours at the same grain, and register it as a single GoodData dataset, this aligns with GoodData's recommended data modelling practices and should resolve the cross-fact dimensionality issue — since both metrics would now live in the same dataset with no cross-dataset join required. The one caveat from the knowledge sources worth keeping in mind: > "Make sure that facts placed in the same fact table are at the same level of detail (grain) and from the same business process. If two events occur at different times, they belong in different fact tables." [Fact Concepts] So as long as invoice revenue and labor hours are genuinely at the same daily grain and represent the same business process, the pre-aggregated dbt approach is the right path forward. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

Hi Nick, great follow-ups, and you're spot on on both counts. On Data Blending, since everything lives in the same Snowflake connection, this isn't the right tool for your situation. Your case is a standard LDM grain problem, not a multi-source one. On the dbt pre-aggregated table, yes, that approach will work. If you build a single denormalized daily fact table combining invoice revenue and labor hours at the same grain and register it as one GoodData dataset, both metrics live in the same dataset with no cross-dataset join required, which should resolves the dimensionality issue entirely. Please give a try or test it and let us know if that helps.