I have KPI define as MAQL

SELECT {metric/logins_per_users_-_usage}/(select count({label/transaction_date.month}))

select count({label/transaction_date.month})

This should count month based on filter (Transaction Date) selected on dashboard, derived from

{label/transaction_date.month}

But sometime it is not doing correct. For

last year

in filter it gives 12, but for last 4 quarters it output 21

Why Your COUNT of Months Is Giving Unexpected Results The issue you're experiencing is related to how GoodData's

COUNT

function resolves its context based on the visualization and data model, not simply the dashboard filter. What's Happening

SELECT COUNT({label/transaction_date.month})

uses the single-parameter version of COUNT, which dynamically determines its counting context from the visualization it's used in. [COUNT docs] The key problem is that COUNT counts unique values of the attribute that exist in the underlying data, not the number of months implied by the date filter range. So: • For "Last Year": there happen to be 12 distinct month values in your data → returns 12 ✅ • For "Last 4 Quarters": the context becomes ambiguous or resolves across multiple fact datasets, potentially joining counts from multiple contexts, resulting in 21 instead of the expected ~12 months [COUNT docs] This is a known behavior: "In cases where the context is ambiguous, the count will be computed on all particular contexts and results from all counts will be joined together." [COUNT docs] How to Fix It Option 1: Anchor COUNT to a specific dataset using the two-parameter or USING form Explicitly specify which dataset the count should resolve against:

SELECT COUNT({label/transaction_date.month}, {dataset/your_fact_dataset})

or

SELECT COUNT({label/transaction_date.month}) USING {label/your_fact_dataset.primary_key}

This removes the ambiguity and ensures the count is computed in the correct context. [COUNT docs] Option 2: Use MIN/MAX + DATETIME_DIFF If your data has records at the start and end of the selected range, you could approximate the number of months using:

SELECT datetime_diff(min({label/transaction_date.month}), max({label/transaction_date.month})) + 1

[DATETIME_DIFF approach] Important Limitation to Be Aware Of Note that MAQL metrics cannot access the dashboard date filter boundaries as variables (e.g., there is no

filter.start

/

filter.end

). The count is always derived from the data that passes through the filter, not from the filter's definition itself. [Rolling window limits] I'd recommend starting with Option 1 — specifying the dataset explicitly in your COUNT — as it's the most direct fix for the ambiguous context issue. 👍 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.

Hello Krishti, I wanted to check in and see if the response from our Support AI was helpful and clear. The explanation around COUNT context ambiguity and the suggested fixes (using the two-parameter form or the

USING

clause) covers the most likely root cause for the 21-month result. That said, if anything was unclear or you'd like help applying one of those options to your specific metric and data model, just let us know.

This helped. But still I wish we should have MAQL metrics can access the dashboard date filter boundaries as variables (e.g., there is no

filter.start

/

filter.end

)

Hi Krishti. We have gone ahead and we submitted the Product Feedback on you behalf. Please, let us know if you need further assistance.