Description

Player tags were originally created to facilitate the identification of Players for experience deployment using the Share and Deployment Console. However, with the ability for a running Intuiface experience to identify Player tags using the System Information Interface Asset (IA), the addition and removal of tags can also be used to trigger experience actions in real-time.

This article presents examples for how to manage experience content using Player tags.

Notes:

• This feature is only available to Enterprise-level Intuiface customers.
• If you wish to use Composer to test Player tag access in a running experience, you need to
  1. Install Player on the same device as Composer and activate it using your Intuiface account.
  2. Run Player at least once then log out.
  3. Assign your desired tags to this Player using the Share and Deploy Console.
  4. Done. These tags will now be accessible to experiences running in Composer on the same device. 

Scenarios and usage examples

Although there are an infinite number of scenarios for using Player tags to control experience content, they can be boiled down to one of three approaches.

• When the experience starts
  Approach: Using a non-repeating timer trigger at the experience level (i.e. in no individual scene)
• On a regular basis
  Approach: Using a repeating timer trigger at the experience level
• At a specific time of day
  Approach: Using the Clock Interface Asset at the experience level

For all of these approaches, you'll be using conditional triggers to perform a tag search. Two tag search methods are detailed below.

Simple tag search

You'll often be using conditional triggers with the "contains" operator when working with Player tags to trigger an action. This way it won't matter how many Player tags a particular Player has, nor how those tags are ordered.

Example: When starting an experience

• If the Player tags list contains tag X, then navigate to scene X
• Else if the Player tags list contains tag Y, then navigate to scene Y
• Else if the Player tags list contains.......

The example below is a modified version of the QSR Digital Menu Board and is meant to be run on two Players: one with the tag "Lunch" and one with the tag "Sides". With this technique, you can deploy the same experience to two Players but have them display different content. 

1. In Share & Deploy, add either "Lunch" or "Sides" as a tag to your Player

2. This tag will be found in the list of Player tags exposed by the "Player Tags (string)" read-only property of the System Information IA.

3. At the experience level, create a conditional version of a timer trigger that checks if the "Player tags (string)" property contains "Lunch". If it does, call the Go to scene navigation action and specify the scene named "Lunch". Add a similar conditional trigger that looks for "Sides" and calls the corresponding scene navigation.
You can run this trigger just once if the scene will never change. Alternatively, you could have this timer repeat if the scene may need to change through the course of the day.

You can download this sample experience here. 

Advanced tag search and parsing

If a simple search isn't enough for your use case and you need deeper control, consider a more generic and flexible method that treats Player tags as variables. 

Starting with our previous example, consider the potential for a large number of Player tags, many of which may be difficult to anticipate as the experience will be modified frequently. As a result, it is risky to just put the word 'Lunch' in the list of tags as that prevents it from being used to control some other, unrelated aspect of the experience.

To address this complication, create a tag like "Scene:Lunch".

• The first half of the tag acts like a variable name.
• The second half of the tag represents the variable value.

Instead of searching for "Lunch" or "Sides", 

• Search for a tag that starts with "Scene:".
• Then extract the value after the ':' sign. 

With this approach, the value "Lunch" can be used to control multiple aspects of the experience with great clarity.

The value extracted from the Player tag can be stored in a Global Variable using a Custom Script Converter.

1. Add a Global Variable and bind it to the "Player Tags (string)" property.
2. Add a custom script converter on top of this binding to retrieve the wanted tag value.

For this particular example, a way to write this script could be:

INPUT.split(',').find(item => item.startsWith('Scene:')).split(':')[1]

 Let's walk through this script using the following list of tags assigned to a Player. 

• INPUT represents the entirety of the "Player Tags (string)" and thus contains the value ChicagoHome,MainEntrance,Scene:Lunch 
• Since all tags are separated by a comma, INPUT.split(',') will create an array with the three tags
• INPUT.split(',').find(item => item.startsWith('Scene:')) will find among these 3 tags the one that starts with "Scene:" and will return it. The resulting value here will be Scene:Lunch
• .split(':')[1] returns the value after the ':' sign: Lunch. 

We then use this variable as a dynamic parameter of the Go to scene navigation action. 

With this method, you can accommodate any unforeseen experience changes as well as do other things like pass parameter values to an API request or Excel filter, change timer durations, or modify any other property that can be accessed through binding.

You can download this advanced sample here. 

Video explanation - How to use Player tags

You will find, in the Quarterly Q&A Live - Spring edition 2023 video, a detailed example of how to use Player Tags