You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if the collector is configured with a list of domains, it picks the first domain which has any match with the host. It would be better if it searched for the best possible match, instead of the first match.
For example, if the collector is configured for these domains:
"domains": ["example.com", "abc.example.com"]
If the host name from the request is xyz.abc.example.com then the cookie will be set for example.com (the first match), whereas it would be better if it were set for abc.example.com (the best match).
The text was updated successfully, but these errors were encountered:
What makes abc.example.com a better match than example.com? It matches more characters, and maybe that's good, if the goal is to make the cookie as restrictive as possible. But if you are instead trying to make the cookie as permissive as possible, then the more general example.com is the better match.
Our current design favours more permissiveness. The validMatch function matches subdomains to a higher-level domain. So, if the Origin host is abc.example.com and you have example.com in the config, it will be matched, and example.com will be used as the cookie domain.
Also, I believe the example where the collector config contains a list of domains, which are subdomains of the same higher-level domain, is not how this feature is intended to be used. Rather, the goal is to have two or more completely unrelated domains, like domains: [example.com, another.com] and have the cookie domain be dynamically set to the correct value based on the Origin of the request. I'm not even sure what users would be trying to achieve with a config like "domains": ["example.com", "abc.example.com"].
not even sure what users would be trying to achieve with a config like "domains": ["example.com", "abc.example.com"]
I believe what is trying to achieve is deliberate separation of the groups of users. For example, if the companies hosting at example.com and abc.example.com are not the same company. But a single pipeline is being used to collect the behavioural data for both companies. In this case it might be desirable for domain user ids to be not shared across the domains.
But you're right it's not an expected setup, and we should dig into the use case more first before changing anything.
Currently, if the collector is configured with a list of domains, it picks the first domain which has any match with the host. It would be better if it searched for the best possible match, instead of the first match.
For example, if the collector is configured for these domains:
If the host name from the request is
xyz.abc.example.com
then the cookie will be set forexample.com
(the first match), whereas it would be better if it were set forabc.example.com
(the best match).The text was updated successfully, but these errors were encountered: