Overlays
An overlay is an indexable data structure holding pre-aggregated values.
Overview
Overlays are a type of analytic object that contain already-aggregated values and are used for benchmarking data and measuring KPIs, among other uses. Because overlays contain aggregated data, there is no information about individual data points.
In non-overlay data, metrics calculate aggregated values using data records. For example, non-overlay data for your organization's headcount is calculated by counting all active employees in your organization for the selected time period. In overlay data, your organization's headcount for a specific period is calculated for each department before sending data to Visier. This means that Visier will only have the aggregate headcount value for the period that you sent data for.
Overlays represent either subject-like data or event-like data. The data can be additive or non-additive, and the overlay retrieves data values through lookup (find the value in the data ) or rollup (add all the data values). In this article, you will learn about the different overlay types and settings so that you can work with overlays in Visier.
Tip: To learn more, take the Visier University eLearning courses: Creating and configuring overlays and Understanding Visier's data architecture.
Subject-like overlays
A subject-like overlay represents the state of a subject through aggregated data in a metric, where each record represents the subject's state at an interval defined by the start and end of the validity for the subject.
Example: A subject-like overlay representing headcount where the validity start is January and the validity end is February.
The following table represents the original data.
| EmployeeID | Location | Gender | Validity Start | Validity End |
|---|---|---|---|---|
| Jack | Canada | Man | January | February |
| Joe | Canada | Man | January | February |
| Ross | Canada | Man | January | February |
| Sara | Canada | Woman | January | February |
| Mike | US | Man | January | February |
| Sue | US | Woman | January | February |
| Sun | US | Woman | January | February |
The following table shows the same data as an overlay representing headcount.
| Location | Gender | Validity Start | Validity End | Headcount |
|---|---|---|---|---|
| Canada | Man | January | February | 3 |
| Canada | Woman | January | February | 1 |
| US | Man | January | February | 1 |
| US | Woman | January | February | 2 |
In the above table, the pre-aggregated data shows that the headcount of men in Canada during the period of January to February is 3. Because it is an overlay, there is no information about the individual subjects anymore. That is, you can't discover that those three individuals are Jack, Joe, and Ross. The overlay only represents the aggregated values for each combination of dimensions (location, gender, and time).
In this example, the overlay granularity is monthly. If you want to view the headcount for a particular day (lower granularity) or an entire year (higher granularity), the platform finds the state of the records that correspond to that time. In this example, if you query the headcount of men in Canada on January 6, the headcount will still be 3.
Event-like overlays
An event-like overlay represents an event’s value through aggregated data in a metric, where each overlay record represents a period. The length of the period is determined by the overlay’s data granularity. For instance, if the Effective Date of the event record is January 2018 and the granularity of the overlay is monthly, it represents January 2018 to February 2018. However, if the granularity of the overlay is yearly, it represents January 2018 to January 2019.
Example: An event-like overlay representing retirement count where the event record is in January.
The following table represents the original data.
| Retired EmployeeID | Location | Gender | Effective Date |
|---|---|---|---|
| Jack | Canada | Man | January 3 |
| Joe | Canada | Man | January 5 |
| Ross | Canada | Man | January 1 |
| Sara | Canada | Woman | January 10 |
| Mike | US | Man | January 27 |
| Sue | US | Woman | January 5 |
| Sun | US | Woman | January 14 |
The following table shows the same data as an overlay representing retirement count.
| Location | Gender | Effective Date | Retirement Count |
|---|---|---|---|
| Canada | Man | January | 3 |
| Canada | Woman | January | 1 |
| US | Man | January | 1 |
| US | Woman | January | 2 |
In the above table, the pre-aggregated data shows that the retirement count of men in Canada during the period of January to February is 3 people, considering that the overlay granularity is monthly. Similar to the subject-like overlay example above, there is no information about the individual subjects in the overlay data. The overlay only represents the aggregated values for each combination of dimensions (location, gender, and time).
Any queries for a granularity lower than the event-like overlay’s actual granularity result in N/A values. In this example, the granularity is monthly. If we query the events that happened on January 6, the query is a lower granularity than the overlay granularity and the result is N/A.
Queries for a higher granularity result in the values summed together. For example, if the Retirement Count overlay is monthly and we know the count of January and February, then a query requesting the count for a period of January 1 to February 28 will result in the sum of the two month values.
Additive and non-additive overlays
The data in overlays is either additive or non-additive.
- Additive: The aggregated data is summed across time datasets. For example, company cost data is additive because it sums each department's costs and other types of spending to add up to the total company cost.
- Non-additive: The aggregated data is valid over a range of time and remains constant through all datasets. For example, employee engagement data is non-additive because values are not calculated and are only relevant to a specific time period.
Lookup overlays and rollup overlays
The behavior of overlay aggregation is either lookup or rollup. Both lookup and rollup aggregation work with subject-like and event-like overlays. The behavior defines how the values aggregate in a hierarchy.
The main difference between a lookup overlay and a rollup overlay is how the data is presented.
- A lookup overlay expects every row to have data so the platform can "look up" values in the data.
- A rollup overlay expects only the required columns to have data, and all other columns must be blank so the values "roll up" into the final value.
Lookup overlays
In lookup overlays, every intersection in the overlay has a value that is individually provided and retrieved. The values are looked up directly from the data. This means that data is provided for every value you want to use. For example, if you want to look up the retirement rate for all locations in January, a lookup overlay requires data that only contains values for the columns "Effective Date" and "Retirement Rate". The "Location" and "Gender" columns for that row must be blank. A blank row indicates all members are included.
Example: A lookup overlay for retirement in January.
The following table represents the original data provided for a lookup overlay.
Note: Blank values represent all members, such as all locations or all genders.
| Location | Gender | Effective Date | Retirement Rate |
|---|---|---|---|
| January | 13% | ||
| Man | January | 9% | |
| Woman | January | 8% | |
| Canada | January | 1% | |
| Canada | Woman | January | 4% |
| Canada | Man | January | 7% |
| US | Man | January | 4% |
| US | Woman | January | 1% |
Based on the original data in the table above, the following table represents the retirement rate in January looked up by location.
| Location | Retirement Rate | Notes |
|---|---|---|
| All | 13% | The overlay looks for a row that is blank for both location and gender. Gender must be blank to indicate all genders are included. |
| Canada | 1% | The overlay looks for a row that contains Canada and a blank value for gender. |
| US | N/A | The overlay looks for a row that contains US and a blank value for gender, but it does not exist in the data. |
Based on the original data in the first table above, the following table represents the location values filtered by employees who are men looked up by the overlay.
| Location | Retirement Rate | Notes |
|---|---|---|
| All | 9% | The overlay looks for a row that contains a blank value for location and the value man. |
| Canada | 7% | The overlay looks for a row that contains the values Canada and man. |
| US | 4% | The overlay looks for a row that contains the values US and man. |
Rollup overlays
In rollup overlays, the data only provides values for dimension members. The platform performs calculations on the data to determine other values. For example, if a dimension in an overlay is Location, values are provided in a rollup for the members "Canada" and "US". Other values are calculated by rolling up the values for dimension members. For example, if you wanted to know the values for all locations, the values for Canada and US are rolled up to a total value. Values that are rolled up are summed.
Rollup overlays are validated to optionally exclude or include aggregated member record values if the record also has values for one or more children.
- Exclude data-provided aggregate values: You can choose to exclude records to prevent the rolled up value from using both the data-provided aggregate value and the values from its child members. The rolled up value will not be equal to the sum of its children's values. For example, Taylor and Cindy each have a headcount of 15 and both report to Ryan. The data contains an aggregated value for Ryan's headcount, a total of 30. To prevent the overlay from rolling up the values to 60, you can exclude the data-provided aggregate value of 30.
- Include data-provided aggregate values: You can choose to include data-provided aggregate values. You may want to do this when the data includes both aggregated and non-aggregated values, and you want to roll up every provided value. For example, Sam and Katy each have a headcount of 10 and both report to Jack. Jack has an additional 5 direct reports, so the overlay should roll up all the headcount, a sum of 25, assigned to Jack's organization.
Example: A rollup overlay for retirement in January.
The following table represents the overlay data for retirement.
| Location | Gender | Effective Date | Retirement Count |
|---|---|---|---|
| Canada | Man | January | 2 |
| Canada | Woman | January | 4 |
| US | Man | January | 3 |
| US | Woman | January | 1 |
The following table represents the above January retirement data in a rollup overlay.
| Location | Retirement Count | Notes |
|---|---|---|
| All | 10 | Aggregated from 2 men and 4 women in Canada, and 3 men and 1 woman in US. |
| Canada | 6 | Aggregated from 2 men and 4 women. |
| US | 4 | Aggregated from 3 men and 1 woman. |
Data schema
Each analytic object has different data schema requirements based on the object's attributes. For example, a subject called Pet may have the attributes Name, Breed, and Age. To load data for Pet, the data file must have columns for Name, Breed, Age, and EventDate (required for loading data).
To get the schema for an object, do any of the following:
- You can use the Direct Data Intake API to retrieve the schema for any object in your production environment. For more information, see Direct Data Intake API.
- Download the Application Definition and refer to the Display Name, Data Type, and Data Format columns. For more information, see Download the Application Definition.
After you know the data format for the object you want to load data into, you can send data files to Visier. For more information about data files, see Data File Guidelines. You have many options for sending data to Visier. For more information, see Data In.
Should I create an overlay?
Tip: Before creating a new object, check whether your Visier solution already contains the overlay you want. To find all the overlays in your solution, do any of the following:
- In a project, on the navigation bar, click Model > Analytic Objects. You can then filter the list of objects by overlays and review the list.
- Download the Application Definition and refer to the Overlays sheet. For more information, see Download the Application Definition.
- Use Visier APIs to retrieve all overlays. For more information, see Data Model API.
If you're creating new objects for your analytic model, you might wonder when to create an overlay as opposed to a subject, event, or internal comparison. If your object meets any of the following guidelines, an overlay is probably the right object for your data.
- The object stores aggregate values for a population. It doesn't store individual members' attribute values.
- The object contains aggregated data that Visier can compare against metrics and concepts.
- The object isn't connected to any other analytic objects.
- The object doesn't require access to the Detailed View visual.
For example, let's say you want to analyze the results of your organization's engagement score, however, the results must be aggregated for confidentiality reasons. In this scenario, you would send Visier your organization's pre-aggregated engagement score data, which could then be loaded into an overlay object. The engagement data could have its own attributes to describe the data; for example, Engagement Organization to see engagement scores for each department in your organization.
After you determine that you want to create a new overlay, you can create the overlay in a project in Model > Analytic Objects.
Next steps
Now that you have a stronger understanding of overlays, you can move on to creating and configuring overlays in your analytic model.
You can also continue learning about the analytic model by exploring more topics. For more information, see Understand Visier's Analytic Model.