A Custom Tracking Domain (CTD) is a Bloomreach Engagement subdomain you own that serves Bloomreach's tracking API, so the tracking cookie is set server-side through an HTTP response header instead of by JavaScript. On Safari, HTTP-set cookies aren't subject to the same seven-day cap that applies to JavaScript-set ones.
Category
Bloomreach infrastructure, Safari ITP
Also known as
CTD; Bloomreach CTD; custom tracking subdomain
Two DNS panels side by side. Left, CNAME: a single record pointing the subdomain at Bloomreach, marked with the Safari 7-day cap (Pink). Right, NS delegation: four name-server records, marked clean of CNAME cloaking (Teal) but with a conditional 'IP must align' note tied to Safari 16.4. Below both, a dig command comparing the subdomain and root A-records.
Example
Bloomreach’s default tracking cookie, __exponea_etc__, is a first-party cookie set by JavaScript. On Safari that’s the problem: ITP has capped JavaScript-set first-party cookies at seven days since 2019.
Picture a subscriber who signs up on Monday and returns the following Wednesday, nine days later, adds a product to the cart, and leaves. The cookie expired on day eight, so Bloomreach sees a brand-new anonymous visitor with no email attached. No cart-recovery email fires, despite that person having subscribed a week earlier.
This isn’t an edge case. Safari was around 55% of US mobile browsing and roughly a third of US traffic across all devices at the end of 2024 (StatCounter). For a Safari-heavy retailer, the seven-day cap quietly strips recovery revenue from a large share of the audience.
NS vs CNAME, and the Safari 16.4 trap
Setting up a CTD is a DNS decision, and the two options don’t behave the same on Safari.
CNAME records are the easy setup: one record pointing your subdomain at Bloomreach. It works as DNS, but Safari has detected CNAME cloaking since Safari 14 (2020) and re-applies the seven-day cap to cookies set this way. CNAME partially mitigates ITP, not fully.
NS delegation hands the subdomain’s whole DNS zone to Bloomreach’s name servers, which avoids the CNAME-cloaking signal. It’s the stronger option, and it still isn’t the end of the story. In April 2023, Safari 16.4 added a second rule: if the subdomain’s A/AAAA records resolve to an IP whose first half doesn’t match the first half of your main site’s IP (the first 16 bits for IPv4, the first four groups for IPv6), the cookie is capped at seven days regardless of CNAME or NS. NS delegation doesn’t automatically escape it, because the resolved IPs are Bloomreach’s and usually sit in a different range than your site’s. The rule isn’t in Safari’s public release notes; it’s documented independently by Snowplow, Stape, and addingwell.
So a correct setup has a verification step most guides skip. After delegation, check the IP alignment:
If the first two octets match, Safari treats the cookie as first-party and the full expiry holds. If they don’t, you’re still capped at seven days on Safari 16.4 and later, and server-side tracking or a different hosting topology may be the better path.
When CTD is worth it
CTD isn’t a default. It involves DNS changes, SDK reconfiguration, and a migration path for existing cookies, so it earns its place only under certain conditions.
It’s worth it when a meaningful share of traffic is Safari (iOS-heavy markets like the US, UK, Nordics, Australia), when your Bloomreach use cases depend on recognizing returning visitors (cart and browse abandonment, lifecycle triggers, multi-session segmentation), and when the customer journey spans days or weeks rather than a single session.
It’s not worth it when your use cases are single-session and transactional, when Safari is under roughly 10% of your users, or when you don’t control the DNS for your main domain. One side benefit when you do set it up: serving Bloomreach from your own subdomain raises the floor on ad-blocker resistance, since many blocklists target Bloomreach’s default domains by name. It isn’t bulletproof, because determined blockers match content signatures rather than URLs, but it reduces outright blocking.
In practice
The IP-alignment check after NS delegation is the step most setups skip. If Safari visitors keep coming back as new after a week, the dig comparison above is the first place to look: matching the relevant IP prefix is a necessary check, not a guarantee; if it mismatches, expect Safari to cap the cookie at seven days on Safari 16.4 and later, even with delegation done correctly.dig comparison above is the first place to look. More on how we approach this.