Hi, our LDM uses a single shared Date dataset (blue table) for "Starts_at" date that’s connected to multiple fact tables — including

session_tracks

,

event_sessions

, and others. When building metrics, I need to apply a date filter (e.g.

BETWEEN THIS(DAY, -6) AND THIS(DAY)

) only to the starts at -

session_tracks

table, but because all these tables share the same Date dimension, any filter on

{label/Date.Day}

currently affects all of them. Could you please confirm the correct MAQL syntax to scope a metric’s date filter specifically to the

session_tracks

dataset (for example, using

{dataset/session_tracks}

), so that the filter applies only to session tracks data and not to event data?

New message text here

Hi Raffaella, if you share the same Date dimension across multiple date dimensions, it is automatically applied to all connected datasets. You can tell to a specific metric that you do not want the filter is applied by using a MAQL construct WITH PARENT FILTER EXCEPT

WITH PARENT FILTER EXCEPT {label/date}

this will cause that this one metric will ignore a date filter. But you can not disable it for a whole table universally. Another option if you sometimes need to filter by the date everywhere and sometimes not would be to introduce another date dimension to your data model (connected to the same physical date column in your datasource) that would be only connected to the table you want to filter.

Just to confirm, is the suggestion of using BY {dataset...} not correct?

_When building metrics, I need to apply a date filter (e.g.

BETWEEN THIS(DAY, -6) AND THIS(DAY)

) only to the starts at -

session_tracks

table, but because all these tables share the same Date dimension, any filter on

{label/Date.Day}

currently affects all of them._

But I assume you still want to apply the date filter to the other tables at some other cases, right? You would need to use

WITH PF EXCEPT {label/Date.Day}

to all the other metrics but they you would have no way how to filter them by date… I think changing the LDM is really the best option here.

This is a specific metric for a specific report, there is no dashboard with parent filter here. I want to be able, when there is a shared data dimension across tables, to just look at a specific table e.g. session tracks, otherwise the data will not be reliable. Is the only way to do this to make changes to the data model? I would like to avoid this and cause breaking changes to customers' workspaces.

and in this specific metric are you combining data from both datasets and only want to filter by date in one of them? could you maybe share the metric and some brief description what it should be doing so we can try to help with that specific metric?

Thanks Michael, The report is a weekly users activity report, and I am using the tables Users and Session tracks (which include starts_at.day date dimension) The metric should be: SELECT COUNT({metric/count_of_active_users}) WHERE {label/starts_at.day} BETWEEN THIS(DAY, -6) AND THIS(DAY) But I have no way to specify this should look at session tracks only

and the inner metric (

{metric/count_of_active_users}

) is looking into both

session_tracks

and

event_sessions

tables? do you want the date filter to be applied on session_tracks only? or the count itself? I am trying to understand how the date filter is now causing it to filter both tables.

I want to make sure the count only takes into account starts_at value for session tracks, e.g. the metric only returns the count of active users who had a session track started in the last 7 days.

that should be automatic if the date is connected to session_tracks in the data model and if nothing in your specific metric or this specific report is taken from the event_sessions, the system will not apply filter to it. could you maybe share the relevant part of the data model (how the date and those two tables are connected) and how the

{metric/count_of_active_users}

is defined? for COUNT, if the counted attribute appears in multiple tables in the data model because of the references, you can use the optional second parameter of the COUNT function to ensure in which table to apply the count.

Hi Raffaella, we are wondering if you need further assistance after Michal's helpful explanation.