The SDK generates a TLTSID cookie for capturing session data. If the top-level domain changes the SDK generates a new TLTSID cookie value. This causes separate sessions to be created in IBM Cloud and breaks the customer's journey.

An IBM Cloud hosted cookie will allow seamless integration of data across multiple top-level domains and provide insight for the entire customer's journey.

Research:
IBM Cloud has a kill switch URL (ex: https://collector.tealeaf.ibmcloud.com/collector/switch/4290bd7effdc4248a4fa8f8384a3ab29) that receives the app key and returns a 1 or 0 in the pages response.

IBM Cloud needs a cookie URL (ex: https://collector.tealeaf.ibmcloud.com/collector/cookie/4290bd7effdc4248a4fa8f8384a3ab29)
that receives the app key, generates a cookie unique to that app key and browser session, and returns the MD5 hash of that cookie in the pages response.

The SDK can then be configured to get the pages response and set it as the TLTSID cookie before initializing. The session state is maintained by the browser and the pages response will remain the same across all domains using the SDK with the customer's app key.
This means the same TLTSID cookie value will exist for each domain.

I have already built an on PREM solution that allowed the customer to host a TealeafCookie.aspx page in their own environment and verified that IBM Cloud sessions were captured with data from multiple domains.