I see in the JS tracker docs there are options to have a client hints context enabled.
But is this client hints data fed into the yauaa enrichment so that it can make better analysis of the user agent?
Otherwise, any folks analyzing event data have another place to look for user agent data and having to merge and consolidate this info.
Hi @anteup no the client hints data is not fed into the yauaa enrichment.
But, there was a conversation about this idea recently over in this github issue. It seems like it would be possible, so this might get implemented in future.
I would be interested to hear your experience of using client hints, and if you find the yauaa enrichment has limitations. It might lend some weight behind the idea to add support for client hints in Enrich.
Most of it is driven from seeing the UA parsing changes since we’ve upgraded the enricher and are using yauaa.
For example, this UA string:
“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36”
in yauaa gives:
“operatingSystemNameVersionMajor”: “Unknown ??”
whereas in the old parser, it would have returned something like “Windows 10”
Indeed, even the latest yauaa parser at https://try.yauaa.basjes.nl/ which I assume is version 7.6, will at least parse out that it’s a Windows OS:
“Name Version Major Windows NT ??”
Because of that, I’m deep down a rabbit hole of User agent strings 
High entropy client hints will, I hope, get us back to high quality and more trustworthy data about user devices.
Bumping the yauaa library in the enricher from 5.x to 7.x would help , i.e. Unknown ?? → Windows NT ??
Integrating the client hints headers to yauaa would be really nice
Finally, I haven’t found it yet, but can the collector be configured to ask for client hints in the response headers - high entropy or otherwise?
Hi @anteup,
Currently it is not possible to configure the collector to ask for client hints. But I think this would be a really nice feature, and very important so that Snowplow can track the highest quality behavioural data.
I opened a Github issue to get this implemented in the collector. We are likely to make a new collector release within the next couple of weeks, so I will do my best to get this feature implemented for that release.
Downstream in Enrich, I would also like to get this one implemented so that the client hint headers are then fed into the yauaa enrichment.
I can update this thread when I have any new information.
I looked into this a bit further…
I think the collector is not the right place to implement this feature. It’s because the collector typically is served on a different origin from the website with the tracking. E.g. if your website is at example.com then your collector might be at collector.example.com.
By default, browsers do not send high-entropy client hints to cross-origin domains. So even if the collector responds with the Accept-CH, it would be ignored by the browser.
Sites can opt-in to send high-entropy client hints to the collector, by using either a Permissions-Policy header:
Permissions-Policy: ch-ua-bitness=(self "https://collector.example.com")
…or by putting a meta tag in the html:
<meta http-equiv="delegate-ch" content="sec-ch-ua-bitness https://collector.example.com;">
But that is not a change we can make in the collector itself.
I agree, still, that we need to make a change to the yauaa enrichment. So it uses the high entropy hints if you can get them sent to the collector.
Hi @anteup we have now released Enrich version 3.6.0 which adds support for feeding client hints to yauaa enrichment. I updated the yauaa enrichment docs page with instructions for how to get it working on your site.
Thank you!
Just to clarify - the new enricher/YAUAA is not taking client hints values from the JS tracker is it? This is solely from HTTP headers?
In that case, I’ll have a chat with the teams owning the server headers or meta tags on pages to see about getting this tested.