Hello, We are having an issue where GoodData is duplicating fields for some reason in filters. We looked into invisible characters and other issues in our ETL process but it is coming out as these prompts are unique despite there being 10+ versions of the same value showing up in the filter. Using Google Chrome inspector and looking to see what the values are we are seeing this: • are client name good for outdoor or patio use$24 • are client name good for outdoor or patio use$26 • are client name good for outdoor or patio use$67 • are client name good for outdoor or patio use$223 • are client name good for outdoor or patio use$225 • ... Any idea what is going on here? This should be just one unique value of "are client name good for outdoor or patio use" Oddly charts are displaying it properly without any issues of looking like there are duplicates

Duplicate Values in Attribute Filters What you're seeing is the Improved Attribute Filters behavior in GoodData. The

$24

,

$26

,

$67

, etc. suffixes you're observing in the Chrome inspector are the primary label (unique ID) values being used internally to distinguish what appear to be duplicate secondary label values. Here's what's happening: • Your "Prompt" attribute likely has a primary label (a unique identifier, e.g.,

prompt_id

) and a secondary/display label (the human-readable prompt text like

"are [client name] good for outdoor or patio use?"

). • Multiple records share the same display text but have different underlying primary keys (hence the

$24

,

$26

,

$67

suffixes you see in the inspector). • GoodData's improved attribute filter now shows each unique primary key value separately, even when the secondary display label is identical, so users can distinguish between them. [Improved Attribute Filters] This also explains why your charts look fine — they aggregate correctly using the primary keys under the hood. The filter UI is just now exposing that there are genuinely multiple distinct records with the same display text. [Object Labels and Filters] What to do 1. Verify your data: Check whether your source data truly has multiple rows with the same prompt text but different IDs. If so, this is correct behavior — they are distinct records. 2. If the duplicates are unintentional in your data: Fix the ETL/data source so that identical prompt texts map to a single unique ID. 3. If you want to display them merged in the UI (using the secondary label for filtering): Use the

enableDuplicatedLabelValuesInAttributeFilter

prop with

displayAsLabel

in the GoodData UI SDK, defining the filter by the primary label while displaying the secondary label:

<AttributeFilter     filter={newPositiveAttributeFilter(Md.PromptId.Default, ["your_id_value"])}     onApply={this.onApply}     enableDuplicatedLabelValuesInAttributeFilter={true}     displayAsLabel={Md.PromptId.PromptText.attribute.displayForm} />

[Attribute Filter Docs] In short, the

$24

,

$26

, etc. are primary key suffixes — GoodData is correctly identifying these as separate entities. The root cause is likely that your data has multiple distinct records with the same prompt text. 👍 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.

@kapa.ai this is not happening for any of our other clients that are built the same way. So believe this is a bug

The knowledge sources do not contain enough information to confirm whether this is a confirmed GoodData bug, and I wouldn't want to speculate. However, based on what you've described — the same setup working correctly for other clients but not this one — here are some things worth investigating before escalating as a bug: 1. Check the data for this specific client: Even if the ETL process is built the same way, it's possible that this particular client's data has genuinely duplicate prompt records with different primary keys. The

$24

,

$26

suffixes confirm GoodData is seeing distinct primary key values. 2. Compare the LDM/metadata: Verify that the attribute definition (primary vs. secondary label configuration) for this client's workspace matches the others exactly. A misconfigured

displayAsLabel

or incorrect label assigned as primary could cause this. [Object Labels and Filters] 3. Check the filter context definition: As seen in similar cases, the filter context may be incorrectly referencing the secondary label ID instead of the primary label ID. The primary label must always be used as the attribute ID in the filter context. [Community Slack] If after checking all of the above the issue still appears to be inconsistent and unexplained, I'd recommend opening a support ticket with GoodData and providing: • The workspace/dashboard links for both the affected and unaffected clients • A comparison of the LDM attribute definitions • The raw data counts for the affected prompt values This will give GoodData support the best chance to identify whether it's a genuine bug. 👍 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 Mark, Could you send the workspace URL where the "Prompt" filter shows the duplicates? Also worth knowing: does that client's workspace use a User Data Filter (row-level permission filter)? And if you have a link to a similar client workspace where it works fine, that'd help me compare. Feel free to use DM. In similar cases, this has come down to something specific to one workspace - either a permission filter or a primary key setup issue rather than a bug.

@Shamil Akhmadyshev thank you for looking into. you can find it here: vision.lqdigital.com/workspace/b6ba16e523684743a95585103ba0e82d/dashboards#/dashboard/0640dea9-6dda-4daa-b5c6-0eea07a9e532

Hi Mark, thanks for your patience. Some of your responses are being loaded twice into the citations data. For about 1 in 4 responses, there are two rows for the same response: one with the clean question text, and one with the same question but a number stuck on the end (like "...outdoor or patio use$225"). Because the system treats those as two different-looking values, both show up separately in the filter, which is why you're seeing so many near-identical entries. This also explains something else worth flagging: on your Mention Rate report, one of the rows showed 112.5%. A mention rate can't actually go above 100%, so that's a sign the same duplicate rows are quietly inflating your numbers there too — it's just less visible than in the filter list, since percentages average things out instead of listing every row. This isn't a GoodData platform issue — it's happening upstream, in how responses get loaded into your citations data. It would be worth having your data/ETL team check for duplicate response entries and make sure each response only gets written once.

@Shamil Akhmadyshev our team is looking into rebuilding our ETL/join in GoodData. We didn't have this issue in the past, so the "Improved Attribute Filters" aren't an improvement for us. haha. thank you

Thanks for confirming, and glad the explanation helped clarify things. Good luck with the ETL/join rebuild - Just let us know if there is anything else we can help you here!