In addition to collecting behavioral data related to a user's visit, the Lytics JavaScript tag can also be configured to deliver real-time profile information back to the browser. By default, Lytics only returns the current audiences the visitor is a member of. However, through field whitelisting, additional data from the visitor’s profile can be returned. Listed below are the core methods available for understanding your website visitors.

NOTE: Please ensure that you have access to an experienced JavaScript developer. Though most installations are straight forward, Lytics support may not be able to make recommendations or provide troubleshooting assistance as we do not have domain knowledge or access to your web property's unique source code.

• Lytics Anonymous ID
  • Get current ID
  • Set ID to custom value
• User Attributes & Audience Membership
  • Initializing callbacks
  • Response handling
  • Audiences cached as cookie
• Custom User Identifier

Each time the Lytics JavaScript tag is loaded it will attempt to identify the visitor. This is done through a variety of means, first of which is the first-party _uid cookie. A unique identifier is generated and stored in the browser. This _uid is then included as part of the outbound payload in all collect methods from the JavaScript tag aiding in identity resolution. In some cases, it is necessary for a developer to access and/or manipulate this ID. In those cases there are two methods available. Please note, manipulating the _uid is an advanced feature and can have a significant impact on how your profiles are compiled. Use at your own risk.

Because getting the unique identifier can be an asynchronous process, you must pass a callback function with the request. Upon completing the lookup, this callback function will be called and passed an attribute which represents the visitor’s unique identifier.

jstag.getid();

jstag.setid('mynewvalue');

Because loading of the current user's profile is done in real-time, a request to our profile API is required. This request is handled asynchronously as to never negatively impact your web properties. As such, it is recommended that access to this profile is always handled through our callback. This ensures you receive the expected result and do not run the risk of race conditions or other browser issues related to asynchronous requests. For use cases that can't support an asynchronous call, please see audiences cached as cookie below for an alternative option.

To initialize a callback add the custom parameter handler:

<script type="text/javascript">
  !function (l, a) { a.liosetup = a.liosetup || {}, a.liosetup.callback = a.liosetup.callback || [], a.liosetup.addEntityLoadedCallback = function (l, o) { if ("function" == typeof a.liosetup.callback) { var i = []; i.push(a.liosetup.callback), a.liosetup.callback = i } a.lio && a.lio.loaded ? l(a.lio.data) : o ? a.liosetup.callback.unshift(l) : a.liosetup.callback.push(l) } }(document, window);
</script>

Followed by the registration of your callback function. In practice these two lines of JavaScript can exist within the same <script> tag.

<script type="text/javascript">
  window.liosetup.addEntityLoadedCallback(function (data) {
    console.log(data.segments);
  });
</script>

Once the profile has been loaded, your callback function will be called and passed a data object. By default, this data object will only contain the audiences the visitor is a member of and have also been enabled for API access. In addition to audience membership, any whitelisted user fields will also be available on the object.

{
  "email": "[email protected]",
  "segments": [
    "all",
    "employees",
    "known_users"
  ]
}

Some use cases require zero latency, which means Lytics can't depend on the milliseconds required to identify and return the visitor profile in real-time. For this type of use case, Lytics caches the visitors audience membership as a cookie each time it is loaded. This means that as long as the visitor has visited at least one page from your site in the past, you will have access to recent audience membership details. To access this first-party cookie, please consult the documentation for accessing browser cookies in your language of choice.

The generated cookie will be configured as follows:

// NOTE this is an example in JavaScript and not production tested code. Use at your own risk.
function getCookie(name) {
    var v = document.cookie.match('(^|;) ?' + name + '=([^;]*)(;|$)');
    return v ? v[2] : null;
}

var audiences;
var ckieValue = unescape(getCookie('ly_segs')); // the raw cookie value

try {
  audiences = JSON.parse(ckieValue);
}
catch(error) {
  console.error(error);
}

console.log(audiences);

// sample output
{
  "audience1": "audience1",
  "audience2": "audience2"
}

In some cases it is desired to use an identifier different than the Lytics cookie, for example userid for a logged in user. Doing so is as simple as once again ensuring the custom parameter handler has been initialized just as it was before the callback.

Note: this only needs to be done once, not before each call.

Then you will need to set a field name, which refers to the name of the Lytics field you are matching against and a value, such as the actual userid.

<script type="text/javascript">
  !function (l, a) { a.liosetup = a.liosetup || {}, a.liosetup.callback = a.liosetup.callback || [], a.liosetup.addEntityLoadedCallback = function (l, o) { if ("function" == typeof a.liosetup.callback) { var i = []; i.push(a.liosetup.callback), a.liosetup.callback = i } a.lio && a.lio.loaded ? l(a.lio.data) : o ? a.liosetup.callback.unshift(l) : a.liosetup.callback.push(l) } }(document, window);
</script>

<script type="text/javascript">
    window.liosetup.field = "userid";
    window.liosetup.value = "myactualuserid";
</script>

When using custom identifiers, it is important that the above information is loaded prior to loading the core Lytics tag as the profile is only requested once and will default to _uid if another parameter has not been set.