Benchmarking in Sisense

[Silutions]

What is the best approach in Sisense for sharing benchmarking information while maintaining customer confidentiality?

When I was a Sisense customer a key differentiator for us was showing our customers how their performance metrics compared to others in aggregate in the same space.  Often, but not always these 'others' were direct competitors.  So we had a significant confidentially requirement to maintain. 

Our solution was a custom Sisense plugin that bypassed Sisense data security.  It allowed us to show aggregated benchmarking data in widgets and also supported the use of dashboard filters to slice the data.  We presented the benchmark metric directly alongside the customer's metric in the same widget for easy comparison.  We had rules in our plugin that prevented the presentation of data if the number of customers/categories in that widget's dataset was less that a certain value.  This prevented a customer with few competitors in a given market segment from being able to determine their competitor's performance by filter manipulation.

There is an interesting post in the Community that describes many benchmark requirements and addresses the need for a number use cases:  Consortium Data By Masking Sensitive Values   It does not address the use case I described above.  In addition, we had large data sets so doubling the Fact rows would not have been a good solution for us.

This seems to be a reasonably common requirement for Sisense so I'm wondering how members of the community have addressed it?

Your thoughts please.

[HamzaJ]

Hi,

We faced this issue as well. I know there is a premium plugin on the Sisense marketplace which prevents over filtering without the need to break data security rules. I do not know if my own situation is similar to yours, however we addressed this in our elasticube model. In our model we categories (we have 3) the customers based on dynamic parameters (revenue last year for example) and apply a check on those categories and recategorize them in case a group has not enough members. This way we can make sure each group always has a certain amount of customers.

[Silutions]

Hamzaj,

Thanks for your reply.  Your solution works for ensuring the minimum number of customers are present in each category, but does not address the data security issue.

Thanks, Jim

[Michael-Schram]

You can deploy two, nearly identical data cubes.  The second must have the security filter column (the client's identity) removed.  Filters applied to the first cube will apply to the second cube, given the columns are present in both.  You can then have widget pairs, with one pointed at the first and one at the second.

This is a base for it but you can make it more advanced than this.

[Silutions]

Michael,

You solution works, but you could not present benchmark values in the same widget as the base values.  That would make it much harder for the end user to compare their values to the benchmark value.  A similar approach is to replicate the fact tables in the same elasticube and apply different security rules to them.  Depending you might need to replicate some Dim Tables as well.  We didn't do that in my customer days as our large fact tables were greater that 50 million rows and we didn't want to take the cube to over 100 million rows.

Thanks for your reply, Jim

[KalonWellSky · Accepted solution]

In my situation, using home health agency data, I needed to create benchmarks showing the data for the user's agency and the same data for all agencies for comparison, like average revenue per claim.  We use data security to limit the data viewed by the user to the agency they belong to using the Agency Name field.  This also constrained the benchmarks using the same formula's for "all" agencies.  To get around this, I created a copy of the table containing the secured data.  In the copy, the agency name is replaced with "Benchmarks", all other data is the same.  For every field you want to use as a filter in a dashboard, you create a table of all possible values for that field and link that table to both the main table and the copy for the associated field.  For example, for filtering on the Record Type field, you would create this table and link it to the original and the copy. 

select distinct a.[record type] from [claims] as a

Your filter would then use the field record type from this table, which is linked to both the original and copy.  This allows you to filter by the agency data and the summarized benchmark data on the dashboard when you want the benchmarks to change when the agency data changes.  Make sure to set up data security to allow for the agency name of the particular agency and the value "Benchmarks".   The user can then select "included all" for the secured field or select the allowed values and "Benchmarks"

[Silutions]

Kalon,

This seems like a good approach.

Thanks, Jim