Configuration & Config Commands
Configuring the tracking SDK
The tracking SDK can be configured at any time by providing an object with the desired settings (see list below). However, some settings like apiKey need to be set as the first command when initialising the SDK.
This is why a configuration command with this configuration is already included in the HTML Snippet (or GTM Tag Template) and it can be expanded with additional configurations.
Reading the Configuration
The current configuration and its values can also be read by using a callback command. Note that the configuration can not be changed by manipulating the returned configuration, but must be configured as described above.
To read the current configuration or just insert a custom operation into the command queue, you can use a Callback Command. These take a function as argument, which will inserted and executed via the command queue. The function will be called with an immutable copy of the current (at time of execution) configuration.
Possible Configuration Properties:
Property | value type | default value | description |
| String |
| The Tracking API Key of your company. The first command of the SDK must set this value. |
| String | The CrossEngage Tracking API to which all tracking requests are being made. Usually this should not be changed. | |
| Javascript Object |
| This configuration can be used to add specific properties and values to all tracking events that get passed to the tracking API. The properties will be added to the properties part of the payload of the request. |
| String |
| The xngGlobalUserId by which the user is tracked globally within the system. If this value is not set, it will be set automatically after the first request to the CrossEngage API, assigning the user this id. When set, it will add a cookie to the users browser to store this setting and apply it on the next page load. It is not recommended, but for very specific use cases this value can be manually overwritten as well. |
| Boolean or String |
| As cookies are used to track a user across sessions, these cookies are always set to a specific domain. Usually this is the exact (sub)domain that the tracking SDK has been loaded on. If you want the cookie to be set on a higher domain level or even the root domain, this setting can be used either by providing the exact domain name that the cookie should use or the boolean value true to let the SDK identify and use the root domain automatically. |
| String |
| The sessionId by which the users current session is tracked globally within the system. If this value is not set, it will be set automatically after the first request to the CrossEngage API, assigning the user this id. When set, it will add a cookie to the users browser to store this setting and apply it on the next page load. It is not recommended, but for very specific use cases this value can be manually overwritten as well. |
| Boolean |
| By default, the tracking SDK displays a variety of usable errors and warnings in the developer console of the browser, if required. These errors and warnings can be disabled entirely, allowing only low level Javascript runtime errors to pass. |
| Boolean |
| By default, the tracking SDK will be in a non-tracking mode. It will execute and run all its internal code logic and functions, but will not make any http request to the CrossEngage tracking API. This configuration will allow requests to the API when enabled, which is required for user tracking. When true, it will add a cookie to the users browser to store this setting and apply it on the next page load. |
| Boolean |
| By default, polling is disabled if no onsite, exit intent or browser notification integration is enabled. With this config, the polling can be enabled to e.g. allow fixing wrongly merged users. |
Last updated