Initialization options
This page refers to version 2.14.0+ of the Snowplow JavaScript Tracker.
Click here for the corresponding documentation for version 1.
Click here for the corresponding documentation for version 2.0 and 2.1.1.
Click here for the corresponding documentation for version 2.2.2.
Click here for the corresponding documentation for version 2.3.0.
Click here for the corresponding documentation for version 2.4.3.
Click here for the corresponding documentation for version 2.5.3.
Click here for the corresponding documentation for version 2.6.2.
Click here for the corresponding documentation for version 2.7.2.
Click here for the corresponding documentation for version 2.8.2.
Click here for the corresponding documentation for version 2.9.0.
Click here for the corresponding documentation for version 2.10.0.
Click here for the corresponding documentation for version 2.11.0.
Click here for the corresponding documentation for version 2.12.0.
Click here for the corresponding documentation for version 2.13.0.
The documentation listed here is for Version 2 of the JavaScript Tracker. Version 3 is now available and upgrading is recommended.
Tracker initialization is started by calling the "newTracker"
 function and takes three arguments:
- The tracker namespace
- The collector endpoint
- An optional configuration object containing other settings
Here is a simple example of how to initialise a tracker:
snowplow('newTracker', 'sp', '{{collector_url_here}}', {
appId: 'my-app-id',
discoverRootDomain: true,
cookieSameSite: 'Lax', // Recommended
contexts: {
webPage: true
}
});
The tracker will be named âspâ and will send events to the a collector url you specify by replacing {{collector_url_here}}
. The final argument is the configuration object. Here it is just used to set the app ID and the common webPage context for each event. Each event the tracker sends will have an app ID field set to âmy-app-idâ.
Here is a longer example in which every tracker configuration parameter is set:
snowplow('newTracker', 'sp', '{{collector_url_here}}', {
appId: 'my-app-id',
platform: 'web',
cookieDomain: null,
discoverRootDomain: true,
cookieName: '_sp_',
cookieSameSite: 'Lax', // Recommended
cookieSecure: true,
encodeBase64: true,
respectDoNotTrack: false,
pageUnloadTimer: 500,
forceSecureTracker: false,
eventMethod: 'post',
bufferSize: 1,
maxPostBytes: 40000,
postPath: '/custom/path',
crossDomainLinker: function (linkElement) {
return (linkElement.href === 'http://acme.de' || linkElement.id === 'crossDomainLink');
},
cookieLifetime: 63072000,
stateStorageStrategy: 'cookieAndLocalStorage',
maxLocalStorageQueueSize: 1000,
resetActivityTrackingOnPageView: true,
connectionTimeout: 5000, // Available from 2.15.0
skippedBrowserFeatures: [], // Available from 2.15.0
anonymousTracking: false, // Available from 2.15.0
// anonymousTracking: { withSessionTracking: true } // Available from 2.15.0
// anonymousTracking: { withSessionTracking: true, withServerAnonymisation: true } // Available from 2.17.0
contexts: {
webPage: true,
performanceTiming: true,
gaCookies: true,
geolocation: false,
clientHints: true, // Available from 2.15.0
// clientHints: { includeHighEntropy: true } // Optional
}
});
We will now go through the various configuration parameters. Note that these are all optional. In fact, you arenât required to provide any configuration object at all.
Setting the application IDâ
Set the application ID using the appId
 field of the configuration object. This will be attached to every event the tracker fires. You can set different application IDs on different parts of your site. You can then distinguish events that occur on different applications by grouping results based on application_id
.
Setting the platformâ
Set the application platform using the platform
 field of the configuration object. This will be attached to every event the tracker fires. Its default value is âwebâ. For a list of supported platforms, please see the Snowplow Tracker Protocol.
Configuring the cookie domainâ
If your website spans multiple subdomains e.g.
- www.mysite.com
- blog.mysite.com
- application.mysite.com
You will want to track user behavior across all those subdomains, rather than within each individually. As a result, it is important that the domain for your first party cookies is set to â.mysite.comâ rather than âwww.mysite.comâ. By doing so, any values that are stored on the cookie on one of subdomain will be accessible on all the others.
It is recommended that you enable automatic discovery and setting of the root domain.
Otherwise, set the cookie domain for the tracker instance using the cookieDomain
 field of the configuration object. If this field is not set, the cookies will not be given a domain.
WARNING: Changing the cookie domain will reset all existing cookies. As a result, it might be a major one-time disruption to data analytics because all visitors to the website will receive a new domain_userid
.
Configuring the cookie nameâ
Set the cookie name for the tracker instance using the cookieName
 field of the configuration object. The default is âspâ. Snowplow uses two cookies, a domain cookie and a session cookie. In the default case, their names are â_sp_idâ and â_sp_sesâ respectively. If you are upgrading from an earlier version of Snowplow, you should use the default cookie name so that the cookies set by the earlier version are still remembered. Otherwise you should provide a new name to prevent clashes with other Snowplow users on the same page.
Once set, you can retrieve a cookie name thanks to the getCookieName(basename)
 method where basename is id or ses for the domain and session cookie respectively. As an example, you can retrieve the complete name of the domain cookie with getCookieName('id')
.
Configuring the cookie samesite attributeâ
Set the cookie samesite attribute for the tracker instance using the cookieSameSite
field of the configuration object. The default is âNoneâ for backward compatibility reasons, however âLaxâ is likely a better option for most use cases given the reasons below. Valid values are "Strict", "Lax", "None" or null
. null
will not set the SameSite attribute.
It is recommended to set either "None" or "Lax". You must use "None" if using the tracker in a third party iframe. "Lax" is good in all other cases and must be used if not setting Secure to true.
Safari 12 Issue with SameSite cookies
It's been noted that Safari 12 doesn't persist cookies with SameSite: None
as expected which can lead to rotation of the domain_userid
from users using this browser. You should switch to cookieSameSite: 'Lax'
in your tracker configuration to solve this, unless you are tracking inside a third party iframe.
Configuring the cookie secure attributeâ
Set the cookie secure attribute for the tracker instance using the cookieSecure
field of the configuration object. The default is "true". Valid values are "true" or "false".
It is recommended to set this to "true". This must be set to "false" if using the tracker on non-secure HTTP.
Configuring base 64 encodingâ
By default, self-describing events and custom contexts are encoded into Base64 to ensure that no data is lost or corrupted. You can turn encoding on or off using the encodeBase64
 field of the configuration object.
Respecting Do Not Trackâ
Most browsers have a Do Not Track option which allows users to express a preference not to be tracked. You can respect that preference by setting the respectDoNotTrack
 field of the configuration object to true
. This prevents cookies from being sent and events from being fired.
Opt-out cookieâ
It is possible to set an opt-out cookie in order not to track anything similarly to Do Not Track through window.snowplow('setOptOutCookie', 'opt-out');
 where âopt-outâ is the name of your opt-out cookie. If this cookie is set, cookies wonât be stored and events wonât be fired.
Anonymous Tracking (2.15.0+)â
The Snowplow JavaScript tracker offers two techniques where tracking can be done anonymously. This means that no user identifiers are sent to the Snowplow Collector. By default anonymousTracking: false
.
Recommended configurations when using anonymousTracking
:
anonymousTracking: true,
stateStorageStrategy: 'cookieAndLocalStorage'
or
anonymousTracking: { withSessionTracking: true },
stateStorageStrategy: 'cookieAndLocalStorage'
or for a completely cookieless experience (from JavaScript Tracker 2.17.0+)
anonymousTracking: { withServerAnonymisation: true },
stateStorageStrategy: 'none',
eventMethod: 'post'
Client Anonymous Trackingâ
anonymousTracking: true
This mode will no longer track any user identifiers or session information. Similar in behavior to setting stateStorageStrategy: 'none'
, as it will store no values in cookies or localStorage, however by using anonymousTracking
you can toggle this behavior on and off (useful for allowing events to be sent without user identifiers until cookie banners have been accepted).
Setting stateStorageStrategy
to cookieAndLocalStorage
or localStorage
also allows for event buffering to continue working whilst not sending user information when anonymousTracking
is enabled.
Anonymous tracking can be toggled on and off. The methods to control this behavior are described here.
Full Anonymous/Cookieless Tracking (2.17.0+)â
anonymousTracking: { withServerAnonymisation: true }
Server Anonymisation requires the Snowplow Stream Collector v2.1.0+. Using a lower version will cause events to fail to send until Server Anonymisatoin is disabled.
Server Anonymisation will not work when the tracker is initialized with eventMethod: 'beacon'
as it requires additional custom headers which beacon does not support.
This mode will no longer track any user identifiers or session information, and will additionally prevent the Snowplow Collector from generating a network_userid
cookie and capturing the users IP address. The same behavior described for above for Client side Anonymous tracking also applies.
Setting stateStorageStrategy
to cookieAndLocalStorage
or localStorage
also allows for event buffering to continue working whilst not sending user information when anonymousTracking
is enabled. However for an experience that doesn't use any browser storage (cookieless), set stateStorageStrategy
to none
. This can be later toggled on, once a user accepts a cookie policy.
Anonymous tracking can be toggled on and off. The methods to control this behavior are described here.
Anonymous Session Trackingâ
anonymousTracking: { withSessionTracking: true }
This mode will continue to track session information in the client side but will track no user identifiers. To achieve this, the tracker will use Cookies or local storage. For session tracking, stateStorageStrategy
must be either cookieAndLocalStorage
(default), localStorage
or cookie
. If this feature is enabled and the storage strategy is not appropriate, then full anonymous tracking will occur.
The Snowplow JavaScript Tracker performs sessionization client side. This allows anonymous session tracking to be done using client side storage without sending any user identifier fields to the collector.
Setting the page unload pauseâ
Whenever the Snowplow Javascript Tracker fires an event, it automatically starts a 500 millisecond timer running. If the user clicks on a link or refreshes the page during this period (or, more likely, if the event was triggered by the user clicking a link), the page will wait until either the event is sent or the timer is finished before unloading. 500 milliseconds is usually enough to ensure the event has time to be sent.
You can change the pause length (in milliseconds) using the pageUnloadTimer
 of the configuration object. The above example completely eliminates the pause. This does make it unlikely that events triggered by link clicks will be sent.
See also How the Tracker uses localStorage
 for an explanation of how the tracker can later recover and send unsent events.
Setting the event request protocolâ
Normally the protocol (http or https) used by the Tracker to send events to a collector is the same as the protocol of the current page. You can force it to use https by setting the forceSecureTracker
 field of the configuration object to true
.
Setting an unsecure event request protocolâ
Normally the protocol (http or https) used by the Tracker to send events to a collector is the same as the protocol of the current page. You can force it to use http by setting the forceUnsecureTracker
 field of the configuration object to true
. If forceSecureTracker
 is activated this argument is ignored.
NOTE: This argument should only be used for testing purposes as it creates security vulnerabilities.
Configuring the session cookie durationâ
Whenever an event fires, the Tracker creates a session cookie. If the cookie didnât previously exist, the Tracker interprets this as the start of a new session.
By default the session cookie expires after 30 minutes. This means that a user leaving the site and returning in under 30 minutes does not change the session. You can override this default by setting sessionCookieTimeout
 to a duration (in seconds) in the configuration object. For example,
{
...
sessionCookieTimeout: 3600
...
}
would set the session cookie lifespan to an hour.
Configuring the storage strategyâ
Three strategies are made available to store the Trackerâs state: cookies, local storage or no storage at all. You can set the strategy with the help of the stateStorageStrategy
 parameter in the configuration object to âcookieAndLocalStorageâ (the default), âcookieâ, âlocalStorageâ or ânoneâ respectively.
When choosing local storage, the Tracker will additionally store events in local storage before sending them so that they can be recovered if the user leaves the page before they are sent.
Adding predefined contextsâ
The JavaScript Tracker comes with many predefined contexts which you can automatically add to every event you send. To enable them, simply add them to the contexts
 field of the configuration object as above.
webPage contextâ
When the JavaScript Tracker loads on a page, it generates a new page view UUID. If the webPage context is enabled, then a context containing this UUID is attached to every page view.
performanceTiming contextâ
If this context is enabled, the JavaScript Tracker will use the create a context JSON from the window.performance.timing
 object, along with the Chrome firstPaintTime
 field (renamed to "chromeFirstPaint"
) if it exists. This data can be used to calculate page performance metrics.
Note that if you fire a page view event as soon as the page loads, the domComplete
, loadEventStart
, loadEventEnd
, and chromeFirstPaint
 metrics in the Navigation Timing API may be set to zero. This is because those properties are only known once all scripts on the page have finished executing. See the Advanced Usage page for more information on circumventing this limitation. Additionally the redirectStart
, redirectEnd
, and secureConnectionStart
 are set to 0 if there is no redirect or a secure connection is not requested.
For more information on the Navigation Timing API, see the specification.
gaCookies contextâ
If this context is enabled, the JavaScript Tracker will look for Google Analytics cookies (specifically the âutmaâ, âutmbâ, âutmcâ, âutmvâ, â__utmzâ, and â_gaâ cookies) and combine their values into a JSON which gets sent with every event.
clientHints context (2.15.0+)â
If this context is enabled, the JavaScript Tracker will capture the Client Hints data made available in the browser. See here for browser support.
This is useful data to capture as browsers are moving away from high entropy User Agent strings. Client Hints offer useful information to understand browser usage without the potential to infringe on a users privacy as is often the case with the User Agent string.
This context be enabled in two ways:
clientHints: true
- This will capture the "basic" client hints
clientHints: { includeHighEntropy: true }
- This will capture the "basic" client hints as well as hints that are deemed "High Entropy" and could be used to fingerprint users. Browsers may choose to prompt the user before making this data available.
To see what will be captured please see the JsonSchema file org.ietf/http_client_hints/jsonschema/1-0-0.
geolocation contextâ
If this context is enabled, the JavaScript Tracker will attempt to create a context from the visitorâs geolocation information. If the visitor has not already given or denied the website permission to use their geolocation information, a prompt will appear. If they give permission, then all events from that moment on will include their geolocation information.
For more information on the geolocation API, see the specification.
optimizelyExperiments contextâ
If this context is enabled the JavaScript Tracker will use the window['optimizely'].data.experiments
 object to create an array of context JSONs; one for each sub-object.
To see what will be captured please see the JsonSchema file com.optimizely/experiment/jsonschema/1-0-0.
optimizelyStates contextâ
If this context is enabled the JavaScript Tracker will use the window['optimizely'].data.state
 object to create an array of context JSONs; one for each sub-object.
To see what will be captured please see the JsonSchema file com.optimizely/state/jsonschema/1-0-0.
optimizelyVariations contextâ
If this context is enabled the JavaScript Tracker will use the window['optimizely'].data.variations
 object to create an array of context JSONs; one for each sub-object.
To see what will be captured please see the JsonSchema file com.optimizely/variation/jsonschema/1-0-0.
optimizelyVisitor contextâ
If this context is enabled the JavaScript Tracker will use the window['optimizely'].data.visitor
 object to create a context JSON.
To see what will be captured please see the JsonSchema file com.optimizely/visitor/jsonschema/1-0-0.
optimizelyAudiences contextâ
If this context is enabled the JavaScript Tracker will use the window['optimizely'].data.visitor.audiences
 object to create an array of context JSONs; one for each sub-object.
To see what will be captured please see the JsonSchema file com.optimizely/visitor_audience/jsonschema/1-0-0.
optimizelyDimensions contextâ
If this context is enabled the JavaScript Tracker will use the window['optimizely'].data.visitor.dimensions
 object to create an array of context JSONs; one for each sub-object.
To see what will be captured please see the JsonSchema file com.optimizely/visitor_dimension/jsonschema/1-0-0.
optimizelySummary contextâ
Unlike previously mentioned Optimizely contexts this context doesnât attach existing in browser object, but constructs its own using only data necessary to join with exported Optimizely data.
To see what will be captured please see the JsonSchema file com.optimizely.snowplow/optimizely_summary/jsonschema/1-0-0.
We highly recommend to use this context instead of previous ones because it is has much smaller footprint and contains all necessary data.
optimizelyXSummary contextâ
Support for OptimizelyX has been introduced in the tracker, you can have a look at the JsonSchema in com.optimizely.optimizelyx/summary/jsonschema/1-0-0 to see what is being captured.
If youâre planning on leveraging the contextâs variation names, youâll have to untick âMask descriptive names in project code and third-party integrationsâ in the OptimizelyX menu -> Settings -> Privacy. Otherwise, all variation names will be null
.
parrable contextâ
If this context is enabled, the JavaScript Tracker will use the window['_hawk']
 object to create a Parrable context JSON.
To see what will captured, please see the JsonSchema file com.parrable/encrypted_payload/jsonschema/1-0-0.
POST supportâ
If you set the eventMethod
 field of the configuration object to post
, the tracker will send events using POST requests rather than GET requests. In browsers such as Internet Explorer 9 which do not support cross-origin XMLHttpRequests, the tracker will fall back to using GET.
eventMethod
 defaults to post
, other options available are get
 for GET requests and beacon
 for using the Beacon API (note: Using Beacon will store a Session Cookie in the users browser for reliability reasons described below).
The main advantage of POST requests is that they circumvent Internet Explorerâs maximum URL length of 2083 characters by storing the event data in the body of the request rather than the querystring.
You can also batch events sent by POST by setting a numeric bufferSize
 field in the configuration object. This is the number of events to buffer before sending them all in a single POST. If the user navigates away from the page while the buffer is only partially full, the tracker will attempt to send all stored events immediately, but this often doesnât happen before the page unloads. Normally the tracker will store unsent events in localStorage
, meaning that unsent events will be resent when the user next visits a page on the same domain. The bufferSize
 defaults to 1, meaning events are sent as soon as they are created.
If you have set bufferSize
 to greater than 1, you can flush the buffer using the flushBuffer
 method:
snowplow('flushBuffer');
For instance, if you wish to send several events at once, you might make the API calls to create the events and store them and then and call flushBuffer
 afterwards to ensure they are all sent before the user leaves the page.
Note that if localStorage
 is inaccessible or you are not using it to store data, the buffer size will always be 1 to prevent losing events when the user leaves the page.
Beacon API supportâ
The Beacon interface is used to schedule asynchronous and non-blocking requests to a web server. This will allow events to be sent even after a webpage is closed. This browser interface can be used to send events by setting the eventMethod
 field in the configuration object to beacon
.
Using Beacon will store a Session Cookie in the users browser for reliability reasons, and will always send the first request as a standard POST. This prevents data loss in a number of older browsers with broken Beacon implementations.
Note: the Beacon API makes POST requests.
More information and documentation about the Beacon API can be found here.
POST pathâ
The POST path that is used to send POST requests to a collector can be change with the configuration object value postPath
.
postPath
 defaults to the standard path: /com.snowplowanalytics.snowplow/tp2
Changing postPath
is non-standard behavior that does not conform to the default Collector protocol.
You must update the Collector configuration to support the new path before you send events to it with this setting. Otherwise, events will not be received by the Collector, or in some cases will be collected but will fail validation.
Make sure that requests are supported by your Collector configuration or redirected to the Collector at the correct endpoint (normally this is /com.snowplowanalytics.snowplow/tp2
).
Configuring cross-domain trackingâ
The JavaScript Tracker can add an additional parameter named â_spâ to the querystring of outbound links.
This process is called âlink decorationâ.
The _sp
value includes the domain user ID for the current page and the time at which the link was clicked (according to the device's clock).
This makes these values visible in the âurlâ field of events sent by an instance of the JavaScript Tracker on the destination page.
The enrichment process will use these values to populate the refr_domain_userid
 and refr_dvce_tstamp
 fields for all events fired on the destination page where the URL includes the _sp
parameter.
You can configure which links get decorated this way using the crossDomainLinker
 field of the configuration object.
The value should be a function taking one argument (the link element) and return true
 if the link element should be decorated and false
otherwise.
For example, this function would only decorate those links whose destination is âhttp://acme.deâ or whose HTML id is âcrossDomainLinkâ:
{
crossDomainLinker: function (linkElement) {
return (linkElement.href === 'http://acme.de' || linkElement.id === 'crossDomainLink');
}
}
If you want to decorate every link to the domain github.com:
{
crossDomainLinker: function (linkElement) {
return /^https:\/\/github\.com/.test(linkElement.href);
}
}
If you want to decorate every link, regardless of its destination:
{
crossDomainLinker: function (linkElement) {
return true;
}
}
Note that the above will decorate âlinksâ which are actually just JavaScript actions (with an href
 of "javascript:void(0)"
), or links to email addresses or telephone numbers (mailto:
or tel:
schemes).
To exclude these links, check them explicitly:
snowplow('crossDomainLinker', function(linkElement) {
return linkElement.href.indexOf('javascript:') < 0;
});
Alternatively, only count links that parse as web URLs by checking the link's hostname
.
This should automatically exclude links that don't lead simply to other web pages.
snowplow('crossDomainLinker', function(linkElement) {
return linkElement.hostname !== "";
});
Some of the above examples will also decorate any links to the same site the user is currently on. For most users we recommend explicitly allowing the list of domains you want to decorate, as well as ensuring that you only decorate links that are on a different domain to the current page.
{
crossDomainLinker: function (linkElement) {
return linkElement.hostname !== location.hostname;
}
}
If you have a shared configuration deployed across multiple sites, you may want to combine the approaches:
{
crossDomainLinker: function (linkElement) {
var networkSites = [
"mysite.com",
"sistersite.com"
];
return linkElement.hostname !== location.hostname && networkSites.indexOf(linkElement.hostname) > -1;
}
}
This allows the same list of sites to be shared between each configuration, but link decoration will only occur when links are to different sites within the list.
Note that when the tracker loads, it does not immediately decorate links. Instead, it adds event listeners to links which decorate them as soon as a user clicks on them or navigates to them using the keyboard. This ensures that the timestamp added to the querystring is fresh.
If further links get added to the page after the tracker has loaded, you can use the trackerâs crossDomainLinker
 method to add listeners again. (Listeners wonât be added to links which already have them.)
snowplow('crossDomainLinker', function (linkElement) {
return (linkElement.href === 'http://acme.de' || linkElement.id === 'crossDomainLink');
});
If you enable link decoration, you should also make sure that at least one event is fired on the page.
Firing an event causes the tracker to write the domain_userid
to a cookie.
If the cookie doesnât exist when the user leaves the page, the tracker will generate a new ID for them when they return, rather than keeping the old ID.
If a user clicks a cross-site link and the URL is decorated with their domain_userid
, and then they share that URL, other users will also have the parameters when they visit the shared page.
Because enrichment populates dedicated fields with the parameter, and it doesn't get persisted through the user's session (it is essentially only on the landing page), you can choose to hide the parameter after the first event (e.g. Page view) is fired on the destination page without needing additional modeling to stitch the IDs.
This means after the next page is tracked, if the user copies the URL after the tracking code has fired, it may not include the _sp
parameter and get copied to other users they share it with.
You can do this using the History API.
The URL updating code runs in a Tracker Callback to ensure it does not run before the page view event has a chance to capture the original URL.
snowplow('trackPageView'); // page URL is https://example.com/?example=123&_sp=6de9024e-17b9-4026-bd4d-efec50ae84cb.1680681134458
snowplow(function(){
if (/[?&]_sp=/.test(window.location.href)) {
history.replaceState(history.state, "", window.location.replace(/&?_sp=[^&]+/, "")); // page URL is now https://example.com/?example=123
}
});
This approach can work with other parameters (e.g. utm_source
) but it is not recommended unless you are sure other systems have also already captured the parameter values for their own systems.
Some systems may consider the URL update a single page application page change, and automatically fire additional page view events with this implementation, we suggest careful testing of this technique to ensure compatibility with your existing vendors.
Configuring the maximum payload size in bytesâ
Because the Clojure Collector and the Scala Stream Collector both have a maximum request size, the Tracker limits POST requests to 40000 bytes. If the combined size of the events in localStorage
 is greater than this limit, they will be split into multiple POST requests. You can override this default using a maxPostBytes
 in the configuration object.
The Clojure Collector canât handle requests bigger than 64kB. The Scala Stream Collector cannot process requests bigger than 1MB because that is the maximum size of a Kinesis record.
Automatically discover and set the root domainâ
If the optional discoverRootDomain
 field of the configuration object is set to true
, the Tracker automatically discovers and sets the configCookieDomain
 value to the root domain.
NOTE: If you have been setting this manually please note that the automatic detection does not prepend a â.â to the domain. For example a root domain of â.mydomain.comâ would become âmydomain.comâ. This is because the library we use for setting cookies doesnât care about the difference.
This will then result in a different domain hash, so we recommend that if you have been setting this manually with a leading â.â to continue to do so manually.
Configuring the cookies lifetimeâ
Whenever tracker initialized on your domain â it will set domain-specific visitorâs cookies. By default, these cookies will be active for 2 years. You can change this duration using cookieLifetime
 configuration object parameter or setVisitorCookieTimeout
 method.
snowplow('newTracker', 'cf', '{{COLLECTOR_URL}}', {
cookieLifetime: 86400 * 31,
});
or
snowplow('setVisitorCookieTimeout', 86400 * 30); // 30 days
If cookieLifetime
 is set to 0
, the cookie will expire at the end of the session (when the browser closes). If set to -1
, the first-party cookies will be disabled.
Tracking prerendered pagesâ
Some browsers can âpreloadâ pages while user typing URL in. These users not always end up in that page, however due page preloading tracker is initialized and loaded.
JS Tracker by default doesnât fire events when page is preloaded, but sets callback on visibilitychange event, which fires actual event only when page starts to render.
To explicitly enable tracking for prerendered pages you can use setCountPreRendered
 function:
snowplow('setCountPreRendered', true);
Limiting local storage queue sizeâ
Because most browsers limit local storage to around 5mb per site, you may want to limit the number of events the tracker will queue in local storage if they fail to send. The default is a max queue size of 1000, but you may wish to reduce this if your web application also makes use local storage. To do so, you should set the optional maxLocalStorageQueueSize
 field of the configuration object is set to your desired value (e.g. 500).
Reset Page Ping on Page Viewâ
By default the tracker will reset the Page Ping timers, which were configured when enableActivityTracking
 is called, as well as reset the attached Page View contexts on all future Page Pings when a new trackPageView
 event occurs. This is enabled by default as of 2.13.0 and is particularly useful for Single Page Applications (SPA), if you previously relied on this behavior, you can disable this functionality by specifying resetActivityTrackingOnPageView: false
 in the configuration object on tracker initialisation.
Skip tracking browser features (2.15.0+)â
By default the tracker will capture a number of browser features that are available. If you don't require these to be captured and would like to reduce the size of the event payload, you can choose to skip them.
When initialising the tracker, you can specify an array of features to skip.
skippedBrowserFeatures: ['realp', 'java', 'gears', 'ag']
Full list of features:
res
- Screen Resolutioncd
- Screen Colour Depthcookie
- Cookie support (if cookies enabled in tracker initialization)pdf
- PDF MimeType Support (application/pdf)qt
- Quicktime Video MimeType Support (video/quicktime)realp
- RealAudio MimeType Support (audio/x-pn-realaudio-plugin)wma
- WMA MimeType Support (application/x-mplayer2)dir
- Director MimeType Support (application/x-director)fla
- Flash MimeType Support (application/x-shockwave-flash)java
- Java MimeType Support (application/x-java-vm)gears
- Google Gears MimeType Support (application/x-googlegears)ag
- Silverlight MimeType Support (application/x-silverlight)
Set connection timeout (2.15.0+)â
When events are sent using POST or GET, they are given 5 seconds to complete by default. GET requests having a timeout is only available in 2.15.0.
_connectionTimeout_: 5000
This value is configurable when initialising the tracker and is specified in milliseconds. The value specified here will effect both POST and GET requests.
Warning: Setting this value too low may prevent events from successfully sending to your collector or the tracker may retry to send events that have already arrived at the collector, as the tracker will assume the request failed on timeout, leading to duplicate events in the warehouse. We recommend 5000 milliseconds as the minimum value and 10000 as the maximum value.