JavaScript SDK
Collect your web activity
Key features
- To comply with regulations, all the collected data (session, pageviews…) is kept in the browsers cache (and not dispatched) until user consent is gathered.
- You can setup a custom tracking subdomain to improve data collection.
- Rimdian only uses 1st party cookies
- You can activate cross-domain tracking to avoid counting same users twice between your domains (i.e: blog.website.com → shop.website.com)
- Time spent on every page is accurately recorded by taking care of window focus
- Anonymous user IDs are automatically merged with authenticated identities when provided
- User activity can be signed with an HMAC key to protect yourself from malicious data injections
- You can provide a list of ignored web origins in order to avoid triggering new sessions, which is useful if you redirect your customers to an external payment service (Paypal…)
- The SDK automatically attaches context (current
user
,session
,device
…) to every event (pageview
,cart
,order
…) in order to self-heal the dataset in case of missing or “out-of-order” data points - The SDK will automatically reconciliate user identities passed in URLs (cross-device reconciliation)
General behavior
When a new an anonymous visitor (= that is not logged in your website) lands on your website, the SDK will generate a random user ID, start a new session and save it in a cookie.
Basic browser capabilities are collected: user-agent, screen resolution, language and if an ad-blocker is detected.
As soon as you allow it, the SDK will start dispatching data to the server.
When an anonymous user authenticates himself on your website, you can provide its authenticated user ID to the SDK and its anonymous identity will be merged with his authenticated identity.
A new session starts when the previous one expires (30mins of inactivity) or when a new page of your website is loaded from a different origin (i.e: the referrer has a different domain, or the utm_source
/ utm_medium
parameters have changed).
Installation
The SDK should be initialised between the HTML <head>
and </head>
tags. It is synchronously loaded but it will wait for your web page to be ready before doing any work. Its impact on your website performance is negligible.
Example:
Usage
User consent
Most regulations (GDPR…) allow you to collect web user activities on your website as long as the data is not merged with another dataset and is used to produce anonymous statistical aggregations.
In such situation you can dispatch the collected data before collecting user consent on your cookie banner.
To start dispatching data to Rimdian use the JS function:
On-site personalisation & marketing
As soon as you want to see the navigation history for a specific user in order to customise its on-site experience, you will have to collect his consent_personalization
. The consent_personalization
field also unlocks a user centric view in the Rimdian Console.
For marketing & advertising purpose, you have to collect his consent_marketing
.
If your user accepts the whole “cookie banner”, you can use the consent_all
field.
To unlock a user centric view in Rimdian, use the following JS function:
Users authentication
As soon as a user is authenticating himself on your website, and you know its user ID, you can provide it to the SDK like this:
Dispatching data
By default, all the collected data is kept in the browsers cache. To dispatch it to Rimdian, via your tracking subdomain, use the following function:
User context
You can enrich the user profiles, when they are logged in, or when they give their email to sign up for your newsletter like this:
Pageviews
You can track the current page view with the trackPageview()
function.
Ecommerce
Shopping cart
To track the current shopping cart, use the following function:
Order
Once a customer placed an order you can call the following function:
Don’t forget to also send the shopping cart concerned by that order and provide the order_external_id
field in the trackCart()
function. See above.
Cross-domain tracking
To maintain consistency between your domains and subdomains, you can provide a list of the concerned domains in the config of the SDK.
By doing this, every time a user will go from https://blog.website.com
to https://shop.website.com
, its user ID & device ID will be passed into the URL of the destination page and prevent the SDK counting the same user twice and start a new session.
Example of configuration:
The parameters passed into the destination page are:
_did=xxx
for the device ID_uid=xxx
for the user ID_auth=true
if the user ID is authenticated_uidh=xxx
for the user ID HMAC if provided
Cross-device reconciliation
To significantly increase your cross-device reconciliation rate, and improve the quality of your multi-touch attribution results, we encourage you to put the following parameters into all the URLs of the emails/SMS sent to your customers.
When they will open your emails/SMS on an anonymous mobile device, it will be automatically merged into their authenticated user profile.
All the following parameters are optional:
_authuid=xxx
for the authenticated user ID_uidh=xxx
for the user ID HMAC if provided_email=johndoe@gmail.com
for the user email address_emailmd5=xxx
for the MD5 hash of user email address_emailsha1=xxx
for the SHA1 hash of user email address_emailsha256=xxx
for the SHA256 hash of user email address_telephone=+33600000000
for the phone number in E164 international format
Examples:
Session filtering
Every session become a touchpoint in the multi-touch attribution models, that will receive credits for conversions, and help measuring the performance of your trafic channels.
It’s mandatory to filter out the sources of trafic that don’t contribute to your conversions, especially the payment gateways/redirections during checkout.
Otherwise a new session will start after your customer paid his order and some credits will be attributed to your payment provider.
Example of filter: