Use server-side first party cookies to identify and track users on your website. You can create and collect first party, server-side cookies through Treasure Data's JavaScript SDK.
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 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 configured to persist for up to two years, though Chrome and Edge clamp any cookie's actual lifetime to a maximum of 400 days regardless of the configured value — see About Treasure AI and Cookie Tracking.
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.
Set up of this feature requires that you know how to configure in HTML and JavaScript. Additionally, you need to have:
Basic knowledge of Treasure Data
Basic knowledge of Treasure Data JavaScript SDK
A subdomain (DNS) under your primary website
Treasure AI recommends you verify the implementation of any new features or functionality at your site using the Treasure Data JavaScript SDK version 3,4 from 2.x version.
Safari has detected CNAME cloaking on subdomains delegated to a third party's name servers — the exact pattern this feature relies on — since Safari 14 (November 2020), and added IP-address cloaking detection in Safari 16.4 (April 2023). When WebKit's heuristic flags the subdomain this way, it caps the td_ssc_id cookie to 7 days instead of the up-to-2-year lifetime described above. This affects every WebKit-based browser on iOS (Chrome, Firefox, and others), because iOS requires them to use Safari's WebKit engine. Separately, on Chrome and Edge outside iOS, td_ssc_id isn't subject to cloaking detection, but it's still clamped to a maximum of 400 days under the updated cookie specification (RFC 6265bis), regardless of its configured two-year expiration. See About Treasure AI and Cookie Tracking for how this compares to Chrome, Edge, and Firefox.
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.
For example:
primary website: www.example.com
subdomain: ssc.example.com
ssc.example.com.
NS
ns-###.awsdns-##.com.
ns-####.awsdns-##.co.uk.
ns-###.awsdns-##.net.
ns-###.awsdns-##.org. 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).
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.
useServerSideCookie: Boolean
setSignedMode() function
trackPageview() function
set() function
You can view a Treasure Data JavaScript SDK quickstart. Also, review GDPR Support in Treasure AI for a description of the JavaScript SDK function that helps you to comply with privacy regulations and requirements.
For more information on installing the JavaScript 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.
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 is configured to persist for 2 years unless the user clears their cookies — though Chrome and Edge clamp the actual lifetime to a maximum of 400 days regardless of this configured value (see Known Limitation).
When users revisit the site later, they are recognized as the same user.
Ensure your Treasure 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:
<html>
<head>
<script type="text/javascript">
!function(t,e){if(void 0===e[t]){e[t]=function(){e[t].clients.push(this),this._init=[Array.prototype.slice.call(arguments)]},e[t].clients=[];for(var r=function(t){return function(){return this["_"+t]=this["_"+t]||[],this["_"+t].push(Array.prototype.slice.call(arguments)),this}},s=["collectTags","addRecord","blockEvents","fetchServerCookie","fetchGlobalID","fetchUserSegments","fetchPersonalization","resetUUID","ready","setSignedMode","setAnonymousMode","set","trackEvent","trackPageview","trackClicks","unblockEvents"],c=0;c<s.length;c++){var o=s[c];e[t].prototype[o]=r(o)}var n=document.createElement("script");n.type="text/javascript",n.async=!0,n.src=("https:"===document.location.protocol?"https:":"http:")+"//cdn.treasuredata.com/sdk/4.4/td.min.js";var i=document.getElementsByTagName("script")[0];i.parentNode.insertBefore(n,i)}}("Treasure",this);
</script>
</head>
<body>
<script type="text/javascript">
var td = new Treasure({
database: "YOUR_DATABASE",
writeKey: "YOUR_API_KEY",
host: "us01.records.in.treasuredata.com",
startInSignedMode: true,
sscDomain: "YOUR_SSC_DOMAIN", // ex) example.com
sscServer: "YOUR_SSC_SERVER", // ex) ssc.example.com
useServerSideCookie: true,
});
td.set("$global", "td_global_id", "td_global_id");
td.fetchServerCookie(successCallback, errorCallback);
function fireEvents() {
td.trackPageview("YOUR_TABLE");
}
function successCallback(result) {
// result === Server Side Cookie
td.set("$global", { td_ssc_id: result });
fireEvents();
}
function errorCallback() {
// Track events, even if the server-side cookie does not work
fireEvents();
}
</script>
</body>
</html>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:

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 storeConsentByLocalStorage: true.
When end-user accepts consent, the consent is saved in the end user's local storage.
