Restricted Metrics and Restricted Schemas for Surveys

Overview and One Model Design of Restricted Metrics

Restricted Metrics in One Model were designed to support customers that have survey data and need to limit the threshold of respondents based on stated anonymity disclaimers when conducting the survey.  For example, only display Employee Engagement Scores in a chart when there are 8 or more (this number is configurable) people in the segment of data in a chart or table.

While we recognize customers may have other use cases for restricting data more broadly (i.e. diversity, country, etc.), One Model does not currently support these use cases with the current design of Restricted Metrics.

The Restricted Metric design currently accommodates data from a single table (table based metric), and the restriction cannot be applied to a calculated metric. It is not recommended to restrict a metric where the numerator is based on a span of time metric (event based table) and the denominator is based on a point in time metric (period based table). For calculated metrics, where the customer is calculating a percent of the whole (i.e. % Favorable, %Agree, etc), the One Model team may recommend data staging tables so the metric is created as a table based metric which allows for the restriction on the denominator.

Restrictions on survey data will need to be completed by the One Model team. This functionality is not available to customer admins or partners because there are situations in which customer admins do not have the ability or authorization to see this data.  As part of many company surveys, the company advises employees that no-one from the company will see the individual employee level results of the survey, and in some cases a non-disclosure agreement (NDA) has been signed between One Model, the customer and the survey vendor. Please work with your Customer Success Team if that is the case. 

Restricted Schemas and Processing Script Restrictions

In situations where customers, even customer admins, are not allowed to see details on the survey data, the data will be put into a restricted schema. The restricted schema will only be accessible to One Model team members when creating metrics. 

If data is restricted at the schema level or in the processing script, customer admins will not be able to create or edit metrics and will only be able to access survey data at the aggregate level. One Model can apply restrictions on the metrics while customers can create non-restricted metrics if it’s in an unrestricted one.schema.

Data Sources - Putting data in a Restricted Data Source

If only One Model users can access data, when setting up the Data Source for the Survey data, the Data Engineer will select Restricted Data. Customers will not be able to see this check box in the data source set-up.

This means that this data will be inaccessible to download for customers in File History (once that capability is available to customers) and Data Destinations. A Data source does not need to be set as restricted  to restrict it in the processing script or set a restriction on a metric, but this should be done to ensure that restrictions are applied everywhere.

Data Processing - Putting Data in a Restricted Schema

If only One Model users can access data, when defining Fact and Model tables, the Data Engineer will use the “is restricted” and “in custom_schema” syntax to specify that the Table should be restricted, and what schema it should go in. An example is

survey:
    create fact is restricted
    from ${survey_data}
    keys(${survey_data}.person_id, ${survey_data}.effdt)

If the data source is set as a restricted schema, this flag should be manually specified in the processing script if the Fact or Model table has any of the data that needs to be restricted. This data will then be inaccessible to customers in Explore and Data Destinations.

One Model users will see the schema in Explore only when creating metrics. The schema will show as a lock box to indicate it is in a restricted schema.

Creating a Restricted Metric

One Model users will have a section called Restriction when setting up Metrics that only One Model users will see. The Restriction section is only available on table based metrics.

• Apply Restrictions to this Metric? The first option will be to check if a restriction applies to the metric.  It is a check box.
• Restricted On. This will identify the column in the table that the One Model user needs to apply the restriction on. That column will need to exist in the table that the survey metric is being calculated on. 
  • For example, if you were restricting an Average Survey Score metric, the metric would be surveyscore (average) and the restriction would be the personid in the same table.
    It is important to note the restriction and the metric need to be in the same table and why current functionality of metric restrictions does not support use cases outside of survey metrics.
• Condition. This identifies how to apply the restriction. While it may seem counter-intuitive, the metric restriction will most often be applied as GreaterThanOrEqual. This means that the metric will only show results where there are more than the count.
• Count. This is the actual restriction. It can vary by metric and will work in conjunction with the condition.

Note: 

• If a restriction has been applied to a table-based metric and it is a non-restricted fact table, the customer admin will see that metric and can update it, if they have permission to Create/ Edit Metrics. 
• If a restricted metric is in a restricted fact table the metric will not show in Create/ Edit Metrics for customer admins.
• If you’re not using a restricted fact table, our recommendation is to ensure that you’re including descriptions and organizing metrics in a way that makes it very clear that a restriction is applied.

Using Restricted Survey Metrics

Users that have been permissioned Restricted Survey Metrics will be able to see and use them throughout the One Model product like any other metrics,  except when the conditions to meet the restriction are applied, the data will show null.

Below is a view of a Restricted and Non-Restricted Survey Metric, side by side, where no restriction is being applied. The condition applied to this Restricted Survey Metric is GreaterThanOrEqual to 5.

This is the same for a smaller population of 14, where if I look at it by some Job Categories, I have one where I can see results, but others where it’s 0.

When I remove the non-restricted metric, I get only the Job Category that has enough respondents. There’s no indication that those other groups were included, but are restricted.