Documentation / Product / Features / Lytics JavaScript Tag / Using Version 3

Accessing Visitor Profiles

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.

Table of Contents

Lytics Anonymous ID

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 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.

Get current ID

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(function(id){
    // do something with the id here
    console.log(id);
});

Set ID to custom value

jstag.setid('mynewvalue');

User Attributes & Audience Membership

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 in local storage below for an alternative option.

Initializing callbacks

To initialize a callback simply add a listener on the entityReady function:

<script type="text/javascript">
    var myCallbackFunction = function(profile){
        // do something here with the profile
        console.log(profile.data); // log full data object
        console.log(profile.data.user.segments); // log array of audiences the visitor is a member of
    }

    jstag.call('entityReady', myCallbackFunction); // register the listener
</script>

Response handling

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"
  ]
}
{
    "data": {
        "user": {
            "email": "[email protected]",
            "segments": [
                "all",
                "employees",
                "known_users"
            ]        
        },
        "experiences": [{
            "experience_id": "f53e136b35c498ac944b56a0658ab672",
            "experience_slug": "sample_2",
            "priority": {
                "campaign": -1,
                "stage": -1,
                "experience": -1
            },
            "aggression": 0,
            "provider_id": "93058311a5dc432323114466d0f5ac3c",
            "provider_slug": "custom",
            "attributes": ["universal_experience"],
            "stage_conversion_id": "",
            "ancestors": [],
            "recommendation_collection_id": "",
            "conversion_rate": 0,
            "tags": [],
            "decision_segment_id": "a03333377b6e563363f97dcddb77306d",
            "target_segment_id": "5207e1bb073323117953cfae6fc98298"
        }, {
            "experience_id": "6bca1598ffebf92fcf4e1a44b33a1444",
            "experience_slug": "welcome_email_with_content_recommendations",
            "priority": {
                "campaign": -1,
                "stage": -1,
                "experience": -1
            },
            "aggression": 1,
            "provider_id": "4dd4a2b6e5ebb85688d4b561afe830a2",
            "provider_slug": "sendgrid",
            "attributes": ["transactional"],
            "stage_conversion_id": "",
            "ancestors": [],
            "recommendation_collection_id": "",
            "conversion_rate": 0,
            "tags": [],
            "decision_segment_id": "abc6397b1e2688d772b1fdaf1518b5cf",
            "target_segment_id": "1545437f6a57174ade05dde8fd3abfbd"
        }],
        "errors": null
    }
}

In the example above the three audiences in the segments array have been enabled for API access and the email user field has been explicitly whitelisted for the account.

Audiences cached in local storage

In version 3 of our tag by default Lytics caches the visitor's audience membership in local storage instead of a cookie. A forthcoming integration has been planned to support writing a cookie as well to facilitate some edge use cases but in the case of zero latency needs, local storage represents a better, more scalable storage solution for this type of data. In order to access the cached values on page load before the Lytics JavaScript tag has loaded the profile:

var audiences = localStorage.lytics_segments; // JSON stringified array of audience slugs

Custom User Identifier

In some cases it is desired to use an identifier different than the Lytics cookie, for example userid for a logged in user. This configuration option is available by defining byFieldKey and byFieldValue on the entity key of the core Lytics JavaScript tag configuration.

{
    entity: {
        byFieldKey: 'FIELDNAME',
        byFieldValue: 'FIELDVALUE,
    }
}