The flow of collecting user data on your website is:
A user accesses your website. Treasure Data checks to see if a td_ssc_id cookie exists for the user.
If yes, activities are tracked through Treasure Data SDK that is installed on your website
If no, and consent has been granted, Treasure Data SDK creates a first party, server-side cookie for the user
Treasure Data records users' consent response. In your configuration of the Treasure Data SDK, you specify where the user consent is stored. By storing the consent on the user's browser, the user is not asked for tracking permission each time they access your website and the consent record persists as specified in the cookie document on your website.
The user grants permission to track. A Treasure Data API on your webpage requests a unique ID from Treasure Data.
Treasure Data sends a unique ID back to your webpage. Server-side cookies can be set to persist for up to two years.
The td_ssc_id for the user is stored in the cookie document on your website and, if configured in the Treasure Data SDK, tracking of activities performed by the user is recorded in your CDP account.
You complete the following sections to enable server-side tracking of first party cookies:
Basic knowledge of Treasure Data
A subdomain (DNS) under your primary website
For example, change //cdn.treasuredata.com/sdk/2.5/td.min.js to //cdn.treasuredata.com/sdk/3.0.0/td.min.js.
Setting Up the NS Record in Your DNS
The Treasure Data server-side tracking requires that the server create first party cookies under a subdomain of the primary website. You must add an NS record in your subdomain that points to the Treasure Data server-side cookie service. The NS record points the name of the subdomain to Treasure Data name servers.
primary website: www.example.com
Generally, follow the procedures for your website configuration to add an NS record. Your Treasure Data Customer Success Representative provides the details on the Treasure Data server records that you are to use. You might specify more than one record for redundancy and speed up the DNS lookup (you can pick the name server that’s physically closest to the browser).
Configuring the JS SDK to Collect and Store First Party Cookies
As the website server developer, you install TD JS SDK and configure function calls to fetch a Treasure Data-generated ID for each user who visits your website. The function calls are basically API requests to Treasure Data's server-side cookie. The ID that server-side cookie returns to your website is saved on the end-user's browser.
Parameters and functions include:
sscDomain: String | (String) => String | null. Top-level domain of your website.
sscServer: String | null. The subdomain you create on your website to connect to Treasure Data.
You can view a TD JS SDK overview and installation walkthrough. Also, review the video Implementation for GDPR for a description of the TD JS SDK function that helps you to comply with privacy regulations and requirements.
For more information on installing TD JS SDK see Getting Started with Website Tracking. As part of the instructions, Enable Tracking Events by Individual, is key to enabling tracking of first-party cookies.
Embed the JS Code to Call the Server Side Cookie
The JS code for the server that will contain the cookie sets a cookie on the given subdomain as a parameter. The unique id for each end user visitor persists for 2 years unless the user clears their cookies.
When users revisit the site later, they are recognized as the same user.
Ensure your Treasure Data account is set up to import data from your webpage.
The following code example illustrates the parameters and functions that you configure on your website:
Modify Your Existing JS SDK to Establish a Connection
Update the existing JS SDK coding on your website, adding the required parameters and functions, as shown in the preceding section.
Then, in Treasure Data, ensure that the database table that receives the first-party cookie data includes a column for the td_ssc_id. The column is required when events are being recorded into an existing table:
Specifying the Consent Record Location
Typically, consent is stored in the browser as a client-side cookie, for example, in document.cookie. Treasure Data provides a new location option for consent. The location is in the user's local storage.
In the JS SDK specify
When end-user accepts consent, the consent is saved in the end user's local storage.