Refer to the Getting Started guide for the basics on how to implement SiteHound on your site.
Use these properties to configure Segment’s traits (aka properties) to pass through with tracking for pages, the user, and custom events.
sitehound.globalTraits to an object of key-value pairs to set global traits on all subsequent events in this and future sessions (as well as set as properties on the current user if any).
thisPageTraits is similar to
globalTraits, but will only be set for events during the current pageview. (These will not be set on the user, or passed with events on subsequent pages.)
pageTraits to an object of key-value pairs to track on any Pageview event we may trigger on the current page (as configured by
sitehound.trackPages above). (These will not be set on the user, or passed with any other events on this or future pages.)
alias() under various circumstances. SiteHound removes all the complexity, enabling simple user tracking without the headaches.
First, track user logins by setting
sitehound.userId on the page immediately after a user signs up or logs in. SiteHound will detect the user was previously anonymous, and handle tracking the Login event and associating all events for the current and subsequent pages with the ID provided.
If this is the first time the user has logged in, the library automatically handles aliasing the user with their previous anonymous ID so you have complete history of the trail from when the user first landed on your site through to their logged-in identity, along with all their source attribution data.
It’s recommended you set the
userId property on every page while the user is logged in (this ensures you don’t miss any one-off capture of a login). However this is not necessary, and the user will remain logged in until you specifically pass a
null or use
detectLogout, below. This conversion comes in particularly handy when your site contains a mixture of static and dynamic pages.
detectLogout to true if you wish to change from the default behaviour so that the user is logged out on the current page if you haven’t also passed in a value for
Tip: if you know your pages will display either a “sign in” or “sign out” link depending on the user’s login state, you can track logouts easily without any backend changes to your site using something like the following:
// log out the user if the current page doesn't contain our sign out link
sitehound.detectLogout = !document.getElementById('sign-out');
userIdto log the user in
userIdto null, or leave
userIdunset while setting
Any properties you set on
sitehound.userTraits will be set as global traits on the user and all their subsequent events.
userTraits is essentially the same as
globalTraits, but to ensure user properties are easily identifiable as such within your analytics tool, user traits are prefixed with “User“ to distinguish them from other traits that may be set on specific events. This means e.g. you won’t confuse “User type” with any other “Type” properties you may use to annotate particular events.
You can call
detectPage() to return the type of the current page as determined by applying the rules in your configuration. You can make use of the current page type in your code to help determine which additional properties you may wish to track on different pages - for example product IDs or category names.
detectPage() is only available once the SiteHound library has loaded and initialized, so you should wrap your code in a function and pass the function as an argument to
ready() to have it executed once detection of the current page is available.
Your custom code can conditionally set key/value pairs under
pageTraits to annotate just the event to track detection of the current page, or
thisPageTraits to annotate all events tracked on the current page view.
SiteHound is designed around the concept of mapping URLs to key events, and by default will trigger new page detection if your app updates the window location. By default hash changes are excluded, since the hash is more commonly used for it’s traditional purpose that doesn’t apply a new
You probably don’t need to update these, but if they’re here in case you do.
By default, SiteHound will not track any data if the current page is served from
localhost, an IP address, or
test subdomains. You can use these properties to override or customise these behaviours if desired.
sitehound.doNotTrack() will prevent any data or events being logged by SiteHound for this and any future sessions in the current browser (unless the user clears cookies).
By default, SiteHound reboots the session-tracking properties (
Minutes since session started,
Pageviews this session) if the user doesn’t view any pages for 30 minutes. You can set the
sessionTimeout parameter to an integer number of minutes to customise this duration.
sitehound.logToConsole = true to enable logging of informational output to the browser console that you can use for debugging/troubleshooting.
If you have pages on your site that don’t contain the SiteHound tracking code, and your users may land on them before any tracked pages, SiteHound won’t be able to detect the true landing pages. If this is the case, you can pass an array of relative URLs to
trackReferrerLandingPages and SiteHound will backfill a best attempt at the actual landing page events and properties using the referrer for any users who subsequently click directly through to a tracked page. For example:
By default the library will detect if this happens, track a warning “Tracking Debug” event with details, and not tracking a “Viewed Landing Page” event for that session.
SiteHound_Adaptor_Mylibrary and swap in the name into the call to
sitehound.load('mylibrary') - the code for the Segment analytics.js adaptor
SiteHound_Adaptor_Segment demonstrates the necessary interface you need to implement.
Next: Refer to the User Guide for how to work with the data SiteHound collects.