Forum Discussion

Anonymous's avatar
Anonymous
Not applicable
6 years ago
Solved

Calculating Rolling Sum But Can't Remove Duplicates

Hello, I've written this function meant to calculate the total number of users on a rolling basis over the last 7 days. The only issue I have now is that if someone used it on more than one day, it ...
  • Anonymous's avatar
    Anonymous
    6 years ago
    // First of all, you should not store all data
    // in one table. That's not only Bad Practice...
    // it's also dangerous and leads to subtle bugs
    // you'll not be able to spot. Please ALWAYS
    // use correct star- or snowflake-schemas.
    // Second, you are counting same users many times
    // because you're iterating dates and for each
    // such date you are doing a distinct count
    // of the users... but on the currently iterated
    // day. What you should do instead is you should 
    // select the whole period at once and then
    // do a distinct count of users.
    // The measure should most likely be only shown
    // when only one day is visible in the current
    // context, therefore it must check for the
    // number of days visible.
    // The most important table in all models is
    // a date table (Calendar). So, please make sure
    // you're doing it RIGHT.
    // If you have a CORRECT model, the calculation
    // proceeds as follows:
    
    [7D Rolling Count] =
    var __oneDayVisible = hasonevalue( Calendar[Date] )
    var __lastVisibleDay = max( Calendar[Date] )
    var __periodToCountOver =
    	datesinperiod(
    		Calendar[Date],
    		__lastVisibleDay,
    		-7, day
    	)
    var __result =
    	calculate(
    		distinctcount( FactTable[UserId] ),
    		__periodToCountOver
    	)
    return
    	if( __oneDayVisible, __result )

     

    If you want to learn a bit about CORRECT MODELS, you can try these:

    https://www.youtube.com/watch?v=78d6mwR8GtA

    https://www.youtube.com/watch?v=_quTwyvDfG0

     

    Creating DAX on INCORRECT or MESSY models is not only difficult. It's also error-prone. Good model = simple, fast DAX. Bad model = complex, slow DAX. Easy as that.

     

    Best

    D