Understanding which Data Element to use in Insights

Why use the Person/Org Unit/Space Type/Asset Explores over the Location Explore? 

The Location Explores contain information about all of the above, however it can only display data of objects which have a relationship with a location. For example, a person who is assigned a location will appear in both the Person and Location Explore, but one who does not will only appear in the Person Explore. For cases where an exhaustive list of Persons/Org Units/Space Types/Assets is needed, use the respective Explore. 

Why use the Booking (All) Explore over the Booking (Historical)/Booking (Future) Explores?

The Booking (All) Explore contains past, future, as well as canceled bookings. Booking (Historical) contains non-canceled past bookings. Booking (Future) contains non-canceled future bookings. If canceled bookings need to be included and/or past and future bookings both need to be included, then the Booking (All) Explore must be used. Otherwise, you may choose between Booking (Historical) or Booking (Future), depending on your use case.

SVLive Event, SVLive Avtivity, or SVLive Activity by Hour / Sensor Event, Sensor Activity, or Sensor Activity by Hour?

The SVLive Event Explore uses the SVLive Event View, which contains raw SVLive data straight from the provider - the state of the SVLive at a single point in time. The SVLive Activity Explore uses the SVLive Activity View, which processes SVLive Event data into Start-to-End time ranges of activity on a location. SVLive Activity By Hour further processes the data into hourly intervals, where each row contains data on how a location was used in a given hour. SVLive Event is mainly recommended for logging or troubleshooting purposes, as the data is difficult to use. Deciding between SVLive Activity and SVLive Activity by Hour depends on the granularity you’re looking for - if you need to display data at a minute level, then SVLive Activity should be used. A couple examples to illustrate the difference:

• You want to count how many people appeared in an hour - The By Hour view will have a row for every hour that an attendee is detected, so it would be the recommended choice.
• You want to find the average time people start appear for the first time - SVlive Activity has the exact start and end times of detection, so it would be needed for the solution.

In most other use cases, they are interchangeable.

The same concepts apply to Sensor Event, Sensor Activity, or Sensor Activity by Hour.

Which Metrics View should I use?

The quick answer is to use Baseline Metrics - the View has been designed to provide accurate aggregations regardless of specific grouping/filtering configurations (there is one exception - The Location Type field in the Location View cannot be used in the same query as any baseline metrics). However, specific location level metrics Views (Building Metrics, Floor Metrics, etc.) can be useful in a couple of cases:

•  If you are aware of the level of location granularity in your query’s grouping and filtering configuration, you may use a location-specific Metrics View for a slight boost in query performance.  For Example, if a query is grouped by a Building Name field and there are no filters below the building level (no Floor Name Filter, No Neighborhood filter, etc.), then Building Metrics may be used.
• If a total or a percentage is needed. For instance, if a team has N workpoints, what percentage is that of the team’s floor’s workpoints?

Should I use the Building/Floor/Space/Etc. Name from Location View or the Building/Floor/Space/Etc. View?

These fields are largely interchangeable, but using the fields in the Location View provide a slight query performance boost.

What is the correct way to use Org Unit/Space Type/Person Manager fields?

Because Org Units are hierarchical structures, there are multiple Views and fields that define each Org Unit entity - whether it is Location Org Unit, Attendee Org Unit, etc. Take the following Org Unit structure:

• Location Org Unit - The direct Org Unit of the Location, as it appears in the hierarchical structure. If the Location’s Org Unit Name is “Mid-Market”, and a Location Org Unit.Org Unit Name = "Company" filter is added, the Location will not be included in the result set.
  • Location Org Unit Name/Code levels - this group of dimensions is a list of Location Org Unit Names on level 1, 2, etc. For example, the above Location’s data would appear as:
    • Org Unit Name Level 1 - Company
    • Org Unit Name Level 2 - Sales
    • Org Unit Name Level 3 - Domestic
    • Org Unit Name Level 4 - Mid-Market
    • Org Unit Name Level 5 - Mid-Market (filled in value since Level 4 is the bottom-most node)
    • Org Unit Name Level 6 - Mid-Market (filled in value since Level 4 is the bottom-most node)
    • etc.
• Location Org Unit Ancestor - The “at or below“ Org Unit of the Location. If the Location’s Org Unit Name is “Mid-Market”, and a Location Org Unit Ancestor - Org Unit Name = "Company" filter is added, the Location WILL be included in the result set, since “Company“ is an ancestor of “Mid-Market“. The Location would also be included in the results if filtering on “Sales“ and “Domestic“, since those are also ancestors, as well as “Mid-Market“.

These same concepts apply to Space Type and Person Manager Views/fields.