im looking for some help on computed attributes. I have created an attribute that compares two numeric columns against each other and returns a string. This works fine at a row level but then breaks when i want to count how many of each result i get? does the BY keyword work in computed attributes

Thinking completed Computed Attributes: Counting Results Yes, the

BY

keyword is supported in computed attributes, but let me clarify how it works and what might be causing your counting issue. How BY Works in Computed Attributes The

BY

clause controls the evaluation grain of the computed attribute — it's most relevant when your computed attribute is based on a metric (an aggregated value), not a raw fact or attribute comparison. [Evaluation Context] For example, if your computed attribute compares two numeric columns at a row level (using facts), the expression would look something like:

SELECT
  CASE
    WHEN {fact/column_a} > {fact/column_b} THEN "A is higher"
    WHEN {fact/column_a} < {fact/column_b} THEN "B is higher"
    ELSE "Equal"
  END

This should work as a row-level computed attribute returning a string. Counting Results To count how many rows fall into each category, you would use a standard

COUNT

metric alongside the computed attribute as a slice/breakdown in your visualization. For example:

SELECT COUNT({dataset/your_dataset})

Then slice the visualization by your computed attribute. The computed attribute acts like a regular attribute for slicing and filtering purposes. [Computed Attributes] Possible Issues A few things that could cause problems when counting: 1. Beta limitations: Computed attributes are currently in Beta, and some unsupported combinations can return incorrect results silently rather than throwing an error. [Current Limitations] 2. Missing values: If there is no data for a computed attribute value, that value may be missing from the result even when Show missing values is enabled — this is a known Beta limitation. 3. ID conflicts: Avoid using a computed attribute ID that is identical to an attribute or label ID used in the same visualization, as this can cause unexpected behavior. 4. Ambiguous COUNT context: If your

COUNT

is ambiguous (e.g., the attribute spans multiple datasets), you may need to use the two-parameter form of COUNT or the

USING

clause to make the context explicit. [COUNT] When BY Would Help If you were basing your computed attribute on a metric rather than raw facts,

BY

would let you pin the evaluation grain. For instance,

BY {label/row_id}

would ensure the comparison happens at the row level regardless of how the visualization is broken down. [Evaluation Context] Could you share more detail about how your computed attribute is defined and how you're trying to count the results? That would help narrow down the exact cause. If the issue persists after reviewing the above, please add the following details to this thread so the Support team can investigate: • Your computed attribute MAQL expression • The COUNT metric or visualization setup you're using • Any error messages or unexpected results you're seeing Community support (Startup & Professional): You're already in the right place — the GoodData Support team monitors this Slack and a team member will join if human review is needed. You can also visit the Community Forums. 24/7 Support (Enterprise plans): If your account includes 24/7 Support or this is a Severity 1 issue, you can also submit a ticket, email support@gooddata.com, or call +1 (415) 200-0194. 👍 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 Chris, we have reviewed our AI Assistants response and confirmed its feedback. Please feel free to let us know if you have any further questions and our team will be happy to help, or please feel free to write our AI Assistant again directly if you need any further help too.

Thanks the BY Keyword fixed it

Great, happy to hear that! 🙂 👍