Cathy Liu
09/09/2026, 4:38 AMkapa.ai
09/09/2026, 4:38 AMSELECT count(PLAYER ID {label/PLAYER_ID}) WHERE Turnover_ps {fact/DTM_PLAYER_SESSION_DETAILS_AGG.TURNOVER} > 0
By adding WHERE Turnover_ps > 0, the metric context involves the DTM_PLAYER_SESSION_DETAILS_AGG fact table.
• If that table connects to a general activity/session date dimension, or if filtering on this fact scopes the calculation to records where players had turnover in that period, it may evaluate against activity dates rather than strictly filtering players whose first_visit_date falls in the period.
• Try checking the count without the fact filter first to see if the base count matches:SELECT COUNT({label/PLAYER_ID})In GoodData, COUNT automatically counts distinct values of the attribute [COUNT aggregation].
2. The Dashboard Widget Date Dimension Mapping On a dashboard, the common date filter applies to a widget based on the date dataset configured on that widget [Primary vs Additional Filter]:
1. Edit the dashboard and click on the New Players # headline widget.
2. In the right-hand panel, check the Filter by date setting.
3. Ensure the date dimension selected for this widget is specifically your first_visit_date dataset (not another date dataset like Session Date or Transaction Date).
3. Resolving the Context with USING If PLAYER ID connects to both your player dimension (with first_visit_date) and a session/activity dataset, the calculation path may be ambiguous [Specifying COUNT Context Resolution with USING]. You can explicitly enforce that the count resolves through `first_visit_date`:
SELECT COUNT({label/PLAYER_ID}) USING {label/first_visit_date.date}
_(Replace {label/first_visit_date.date} with the specific date attribute or dataset identifier from your first_visit_date date dimension)._
Next Steps If the count remains incorrect after verifying these settings, resolving the exact relationship paths and data model requires inspecting your workspace directly.
To help the Support team investigate, please add the following details to this thread:
• The exact workspace ID (a73625a4a0c54c408112daeb13296852) and confirmation of permission to inspect via admin/impersonation.
• The name/identifier of the specific date dimension you want to drive this KPI.
• A description or screenshot of the relationships connecting PLAYER ID, first_visit_date, and DTM_PLAYER_SESSION_DETAILS_AGG in the LDM Modeler.
Support Options • Community support (Startup & Professional):
You are already in the right place! The GoodData Support team monitors this Slack and a team member will join the conversation when human review is needed, so please keep the discussion and post the requested details directly in this thread. You can also visit the Community Forums.
• 24/7 Support (Enterprise plans):
If your account tier includes 24/7 Support or this is a Severity 1 (L1) critical issue, you can also reach out via:
◦ Submit a Ticket
◦ Email: support@gooddata.com
◦ Phone: +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.Julius Kos
09/09/2026, 9:25 AMJulius Kos
09/09/2026, 9:27 AMjoined_date, displayed in the UI as "first_visit_date".
I believe that the second one is what you need.
The "New Players #" widget's date filter is currently bound to BUS_DATE (activity date), not joined_date — that's why it returns players active in the period instead of new players.
I would suggest to try this: on that widget, switch "Filter by date" from BUS_DATE to joined_date ("first_visit_date"). Then optionally add a second (additional) date filter on BUS_DATE for the same period — note this isn't about requiring activity (a player whose first visit is in the period is active by definition), it's to pin the Turnover_ps > 0 condition to that period. Without it, turnover is evaluated across all of that player's sessions ever, which barely matters for "last month" but will over-count for historical months. No MAQL change needed either way.
One side note worth passing to whoever owns the LDM: that table has no grain defined and exposes player-level values (lifetime_turnover, lifetime_visits, current_points_balance) as facts, so any SUM over them will be inflated.
If this doesn't help, feel free to send us direct URL into the report in question and describe what is the current behavior vs what you would like to see.Cathy Liu
09/11/2026, 2:30 AM