You can run Hightouch Events on a custom domain by setting up a proxy. When using a proxy, clients send their event data to your domain rather than directly to Hightouch. This lets you have more control over your data.
Select a certificate that corresponds to the CNAME you entered
Supported HTTP versions
Enable HTTP/2 and HTTP/3
Default root object
Leave this blank
Standard logging
Off
IPv6
On
Then, point your clients to the CNAME you configured. If using the JavaScript snippet, you can do this by replacing cdn.hightouch-events.com in the body of the snippet with your CNAME.
Intelligent Tracking Prevention (ITP) is an automatic feature of the Safari web browser, designed to limit user tracking. More specifically, the program is designed to prevent analytics libraries from using client-side Javascript to correlate user sessions. ITP configures the Safari browser in the following ways:
Third-party cookies are blocked by default.
First-party cookies (and localStorage) have a default expiry of 7 days.
A user revisiting a website will restart the 7 day expiry.
Unfortunately, most analytics libraries persist session information by:
Storing an identifier in a Cookie.
Storing an identifier in localStorage.
A legacy analytics installation, one not working to mitigate ITP, will collect less accurate session data for Safari users. For example, a single user visiting a website on both 01/01/2023 and 01/15/2023 will look like two different users. After Safari deletes the first cookie on 01/08/2023, the web SDK will be forced to make a new cookie and a new identifier for the session occurring on 01/15/2023. Downstream, your warehouse will likely see these sessions as two different users. This simple inaccuracy may impact otherwise useful metrics generated from analytics tracking.
When properly configured, Hightouch Events can store session identifiers outside of ITP's 7 day expiry. It does this by using first party, HTTPOnly cookies. These are not subject to Safari's 7 day expiry. These types of cookies are generally used for logging into a website and are less likely to be limited, even when dealing with anonymous users.
These "server cookies" must follow several rules put in place by ITP:
The server providing the HTTPOnly cookie must be on the same domain as the website.
If the server is on a subdomain of the website, its IP address must match the IP address that served the main HTML document.
In practice, this means that ITP mitigation requires customers to host some sort of web service responsible for returning HTTPOnly cookies to the browser. The service does not need to be complex; Hightouch has numerous example servers. The most important part of this HTTPCookieService is that it must be a first party service: routing a subdomain via DNS will not suffice.
In order for the HTTPCookieService to serve first party, HTTPOnly cookies, you'll need one of the following:
A webserver that handles both your HTML documents and your API. This would mean building the HTTPCookieService functionality into your regular webserver. As an example, you might already have a Java Spring server for handling regular website requests.
A reverse proxy that can forward path-dependent requests to different servers. This requires proxying your domain to both an HTTPCookieService and your regular webserver. As an example, you might already have something like NGINX that proxies HTML requests to one place and API requests to another.
A CDN that can run programmatic logic when matching certain path-dependent requests. If you already have a CDN, you may be able to add custom handlers without standing up new servers. This can be achieved with a variety of technologies like Amazon's Cloudfront, Lambda@Edge, or API Gateway. Cloudflare Workers can also work.
The Events SDK expects to interact with a customer's HTTPCookieService that implements a specific spec for two routes. You can name the endpoints whatever you want, as long as you configure the client SDK to call those endpoints.