Create an Overlay
Learn how to
Overview
Like other analytic objects, overlays consist of several attributes that define the object and its data. Many overlays contain simple properties, dimensions, and member maps. For example, the Engagement overlay has simple properties like Population and Overall Score, dimensions like Engagement Gender and Engagement Location, and member maps like Engagement Gender Comparison and Engagement Location Comparison.
In an overlay, member maps allow you to compare aggregated overlay data to the data associated with subjects or events. For example, the Engagement Location Comparison is a member map that maps members of the Engagement Location dimension to the Location Hierarchy dimension associated with the Employee subject. This allows you to analyze Engagement data compared to Employee data. If there are unmapped members in the overlay dimension, those records won't show up in the solution experience.
Note:
- You may use a shared dimension instead of a member map to compare overlay data to subject or event data if the dimension members from both data sources are the same. If there are differences in the values, it may be difficult to use a shared dimension to compare the data. For more information, see Dimensions.
- If you're using a parent-child dimension and need to map direct report values, you must use a member map.
- If you're creating multi-level leveled dimensions, we recommend using a member map.
Create an overlay
- In a project, on the navigation bar, click Model > Analytic Objects.
- Click Create Analytic Object.
- In Analytic object type, select Overlay.
- Type a display name and description.
- When finished, click Create.
Configure an overlay
To configure an overlay, do the following:
- Create properties in the overlay. Properties in Visier should align with data for the overlay; for example, the Overall Score property in the Engagement overlay should align with engagement score data from the source file's column. For more information, see Properties.
- Create dimensions in the overlay. Dimensions in Visier should align with data for the overlay; for example, the Engagement Location dimension in the Engagement overlay should align with location data in the engagement source file. For more information, see Dimensions.
- Do one of the following:
- Create and configure member maps. Member maps connect overlay-specific dimensions to corresponding dimensions in other subjects or events; for example, you can map Location Hierarchy and Organization Hierarchy to an Engagement overlay by creating the member maps Engagement Location Comparison and Engagement Organization Comparison and mapping those hierarchies to the Engagement Location and Engagement Organization dimensions. For more information, see Create a Member Map.
- Connect a shared dimension to the overlay. Shared dimensions connect overlay data to subject or event data that contain matching dimension members. For more information, see Create a Leveled Dimension or Create a Parent-Child Dimension.
Tip:
- If your overlay data doesn't match the subject or event data, use a member map. For example, if the Gender values in the overlay are M and F but the Gender values in the Employee subject are Man and Woman, use a member map.
- If your overlay data matches the subject or event data, use a shared dimension. For example, if the Gender values in the overlay are M and F and the Gender values in the Employee subject are also M and F, use a shared dimension.
- Map data values to attributes in the overlay. Each overlay has mandatory attributes and optional attributes that are mapped to columns in the overlay data; for example, the EventDate attribute is mapped to the Date column in the overlay source data. For more information, see Mappings.
- Define the settings in the overlay. Each overlay has settings such as the time model and aggregation type; for example, engagement data is subject-like and aggregated using lookup behavior. For more information, see Overlay settings below.
Overlay settings
The overlay settings allow you to modify its categorization and treatment of values.
Tags
Tags are user-defined categories that group content in the solution. A tag can apply to multiple object types, including analytic objects, metrics, and guidebooks. A user may filter for objects with a particular tag throughout the solution. For this setting, add tags to identify the object as part of a specific content category. For more information about tags, see Create and Assign Tags to Content.
Example:
The Compensation tag is used for the Pay Change Events metric, the Total Cost of Workforce concept, the Compensation Type dimension, and the Compensation Payout event. This tag therefore groups these objects together as relating to compensation. The Compensation tag itself is allocated to the Talent module, meaning it exists within that solution.
Time model
The time model defines how overlay values are handled. This setting primarily defines what values are shown when selecting multiple time periods in the solution. This depends on whether the overlay holds event values or subject values.
When selecting multiple time periods, one expects event values to be aggregate but only the latest subject value to be shown. The platform generalizes this split with two options for the time model. Use:
- Each value equals a period for event values.
- Each value equals an interval for subject values.
An overlay value equals a period when it represents an event, such as the Expenses overlay, which represents the aggregated values of expense events. These values are valid for an instance but the platform displays them for the period of the granularity of the overlay.
An overlay value equals an interval when it represents a subject, such as the Engagement overlay, which represents the aggregated values of engagement for the Employee subject. These values represent the state of a subject and is valid over an interval.
Aggregation
There are two options for overlay aggregation: rollup and lookup. The types define how the values aggregate in a hierarchy.
- Rollup: Non-leaf intersections in the overlay are derived from their descendants. Select rollup if the values can be aggregated.
- Lookup: Every intersection in the overlay has a value that is individually provided and retrieved. Select lookup if the values cannot be aggregated.
Example:
The Engagement overlay has "lookup" aggregation because individual records exist for every intersection in the overlay. Engagement data cannot be rolled up since the combined value is not a sum of the subgroups.
Contrastingly, the Revenue overlay is "rollup" aggregation because data is derived from descendants, depending on the data schema.
Overlay category
The overlay category defines the type of data for the overlay. For this setting, refer to the following overlay categories and their definitions to choose the one you need.
- Business outcome: Defines KPI data for historical or correlation analysis.
- Plan/budget: Defines future goals or plans.
- External benchmark: Defines known values that are externally collected, government-provided, or internally generated.
- Visier Benchmark: Defines aggregated data provided by Visier that is appended to the tenant data version. Only applicable to Visier-generated overlays.
- Other: No category is defined.
Data version settings
Visier allows each analytic object to override the globally-defined end date.
The end date config type sets the upper limit of selectable time periods in the solution experience. For example, if the end date config type is End of previous month and the current month is February, your users can select data up to the end of January in analyses and visualizations.
You can set the end date config type at the tenant level and per analytic object.
- Tenant level: The end date config applies to all analytic objects.
- Per analytic object: Overrides the tenant end date config for a specific analytic object.
Example: Let's say you load Employee data on the 15th of every month, Applicant data every Wednesday, and Requisition data every Friday. In this example, Applicant and Requisition have new data every week, whereas Employee has new data once a month. We can set the tenant end date config type as End of previous week, and then set an end date override for Employee as End of previous month. This allows your users to select dates up to the end of the previous week for Applicant and Requisition, and up to the end of the previous month for Employee. Without the Employee override, users could select dates for Employee up to the end of the previous week, but Employee data isn't loaded weekly so the visualizations would be blank.
To override the tenant end date config type for a specific analytic object:
- In a project, on the navigation bar, click Data > Tenant Settings.
- Select a data category.
-
In Settings, turn on Enable end date overrides on individual analytic objects.
Tip: If disabled, all analytic objects use the latest upload to determine the data end date. If enabled, each analytic object uses the latest upload for data that populate the object. For objects that aren't updated frequently, we recommend that you set object's end date config type to Use timestamp of source for a specific analytic object.
Let's say you loaded Employee Engagement data on July 31 and Employee data on September 20. Enable end date overrides on individual analytic objects is turned on, but there are no overrides for Employee Engagement or Employee specifically. Both objects use the tenant-level end date config type, but Employee Engagement uses July 31 as the latest upload, whereas Employee uses September 20 as the latest upload. If the tenant-level end date config type is End of previous month, then Employee Engagement's end date is June 30 and Employee's end date is August 31.
- On the navigation bar, navigate to Model > Analytic Objects.
- Select an analytic object.
- In Settings, under Data version settings, turn on Use default.
- In End date config type, select an end date config type from the list.
The following table describes each of the end date config types. To illustrate each end date config type's behavior, the example columns show what date is available to select if today is June 29, 2017 but the latest upload was April 30, May 2, or June 9.
|
End date config type |
Description |
Example 1: Latest upload on April 30 |
Example 2: Latest upload on May 2 |
Example 3: Latest upload on June 9 |
|---|---|---|---|---|
|
Auto detect from data |
Use the date of the latest data point in the upload, including dates in the future. For example, let's say the latest data point in each example upload is April 30, July 1, and June 30, respectively. We recommend Auto detect from data as the default tenant-level end date config type. |
April 30 |
July 1 |
June 30 |
|
End of current month |
Use the end of the month of the latest upload. |
April 30 |
May 31 |
June 30 |
|
End of previous day |
Use the end of the latest upload minus one day. |
April 29 |
May 1 |
June 8 |
|
End of previous week |
Use the last Sunday of the latest upload. |
April 23 |
April 30 |
June 4 |
|
End of previous month |
Use the last day of the previous month of the latest upload. |
March 31 |
April 30 |
May 31 |
|
Use source timestamp |
Use the exact time of the latest upload. |
April 30 |
May 2 |
June 9 |
|
Use timestamp of source for a specific analytic object |
Use the exact time of the latest upload that contains the data for a specified analytic object. For example, use the time of the latest upload for Employee data. Let's say the latest Employee upload was on March 8. |
March 8 |
March 8 |
March 8 |
|
Use timestamp of current run |
Use the current time. |
June 29 (current time) |
June 29 (current time) |
June 29 (current time) |
|
End of current day |
Use the end of the current date. |
June 29 (end of day) |
June 29 (end of day) |
June 29 (end of day) |
|
End of previous month (if first load of month) or previous day |
Use the last day of the previous month if it's the first upload of the month. For all other uploads, use the end of the previous day. For example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
April 29 (end of previous day) |
April 30 (end of previous month) |
June 8 (end of previous day) |
|
End of previous month (if first load of month) or week |
Use the last day of the previous month if it's the first upload of the month. For all other uploads, use the end of the previous week. For example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
April 23 (end of previous week) |
April 30 (end of previous month) |
June 4 (end of previous week) |
|
End of previous month (if first load of month) or use source timestamp |
Use the last day of the previous month if it's the first upload of the month. For all other uploads, use the exact time of the latest upload. For example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
April 30 (time of latest upload) |
April 30 (end of previous month) |
June 9 (time of latest upload) |
|
End of current month (if last day) or previous month |
Use the end of the month of the latest upload if it's the last day of the month. If it's any other day of the month, use the last day of the previous month. |
April 30 (end of current month) |
April 30 (end of previous month) |
May 31 (end of previous month) |
|
End of previous month (if first load of month) or current month |
Use the last day of the previous month if it's the first upload of the month. For all other uploads, use the last day of the current month. For example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
April 30 (end of current month) |
April 30 (end of previous month) |
June 30 (end of current month) |
|
Allow future data |
Use the furthest date in the upload. For example, let's say there is a future start date of July 1 in all example uploads. Caution: Do not use for subject and overlay data. |
July 1 |
July 1 |
July 1 |
|
Last specified day of the week |
Use the latest week day, as specified, of the latest upload. For example, use the latest Wednesday of the latest upload. |
April 26 (latest Wednesday) |
April 26 (latest Wednesday) |
June 7 (latest Wednesday) |
|
Later or last specified day of the week or end of previous month |
Use the latest week day, as specified, of the latest upload without going beyond the previous month. For example, use the latest Wednesday of the latest upload without going beyond the previous month. |
April 26 (latest Wednesday) |
April 30 (end of previous month) |
June 7 (latest Wednesday) |
|
End of current month (if within five business days to end) or previous month |
Use the end of the current month of the latest upload if the upload is within five business days of the end of the month. Otherwise, use the last day of the previous month of the latest upload. |
April 30 (upload is within 5 days from end of month, use end of current month) |
April 30 (upload isn't within 5 days of end of month, use end of previous month) |
May 31 (upload isn't within 5 days from end of month, use end of previous month) |
|
End of previous month (if first load of month) or last specified day of the week |
Use the last day of the previous month of the latest upload if it's the first upload of the month. Otherwise, use the latest week day, as specified. For example, use the latest Wednesday of the latest upload. In this example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
April 26 (latest Wednesday) |
April 30 (end of previous month) |
June 7 (latest Wednesday) |
Default metric
The default metric associated with an analytic object is used to generate system alerts and prevent an empty state for charts when your users switch between dimensions that have no relationship to the metric.
If enabled on a subject, default metric allows you to view the subject's history in Detailed View.
After onboarding data, the default metric is an easy way to quickly verify that the data for an object was loaded as intended. For this setting, select a metric that will act as the default metric for the object in visualizations and will be available as a data overview in Studio dashboard.
Example:
The Employee subject's default metric is Headcount. Because Headcount is a default metric for Employee, the system generates an alert for Headcount to ensure its values remain consistent and expected. When new employee data is loaded, the Headcount metric can be viewed in the dashboard as a quick way to discern if the data is accurate.
Support value property
The support value property is an optional setting for benchmark overlays. A support property must be defined in the overlay to use best-fit functionality with benchmark values. This works as a tie breaker if multiple slices have the same number of valid records. The best fit works best with base metrics on lookup overlays and is thus optional for rollup overlays.
An overlay with a support value property set will return the most specific population—that being the smallest value of the support value property. For this setting, select a benchmark property to be the support value property.