Hi Team, I've updated the LDM to connect date filt...
# gooddata-cloud
c
Hi Team, I've updated the LDM to connect date filter to first_visit_date, and then created the new_player metrics as below snapshot. The figure is incorrect. It should be 280 based on the filter. The link is: 31. Player Summary - GoodData Cloud
k
Thinking completed Based on your screenshots and metric definition, there are a few likely reasons why you are seeing 2,954 instead of 280: 1. The Fact Filter Shifts the Date Context to the Session/Fact Dataset Your metric is defined as:
Copy code
SELECT 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`:
Copy code
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.
j
Hi Cathy, Just an advice for better visibility 🙂 You can keep the discussion in a single thread and reply with the AI hashtag mentioned in the footer of every AI message if you want to keep discussion with our AI chatbot.
Regarding the case, We checked the LDM directly amd we've noticed that "first_visit_date" exists twice on the player session table — once as a plain date column (not filterable) and once as a proper date dimension with internal id
joined_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.
c
Thanks Julius, I'll just keep the same discussion in a single thread.