Tracy51D
commented
1 week ago @a1ekas Our data team have tested both the UA and UACH supplied and have been unable to replicate your issue. You can see our results page here.
Open a1ekas opened 1 week ago
Tracy51D
commented
1 week ago @a1ekas Our data team have tested both the UA and UACH supplied and have been unable to replicate your issue. You can see our results page here.
a1ekas
commented
1 week ago @Tracy51D Thanks for the answer. I have a question. As you can see from my test, on 10/16/2024 the UA and UACH I provided were identified as Chrome Mobile. What could be the reason for this?
Drozdova-N
commented
1 day ago Hello,
I am also encountering an issue with detecting TwitterAndroid based on UA + CH when the TwitterAndroid substring exists in the User-Agent. In my service, which uses detection via 51Degrees (github.com/51Degrees/device-detection-go/v4) and downloads the 51Degrees database daily, UA + CH combinations containing the TwitterAndroid substring are sometimes identified as TwitterAndroid and sometimes as Chrome Mobile, depending on the version.
Additionally, I tested header examples on User-Agent Tester and received different results depending on the request format (with and without a space between the header and value).
Below are a few screenshots with examples.
Example 1
User-Agent: Mozilla/5.0 (Linux; Android 11; T671E Build/RKQ1.201112.002; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/129.0.6668.100 Mobile Safari/537.36 TwitterAndroid
sec-ch-ua: "Android WebView";v="129", "Not=A?Brand";v="8", "Chromium";v="129" sec-ch-ua-full-version:"129.0.6668.100"
sec-ch-ua-full-version-list: "Android WebView";v="129.0.6668.100", "Not=A?Brand";v="8.0.0.0", "Chromium";v="129.0.6668.100"
sec-ch-ua-mobile: ?1
sec-ch-ua-model: "T671E"
sec-ch-ua-platform: "Android"
sec-ch-ua-platform-version: "11.0.0"Example 2
User-Agent:Mozilla/5.0 (Linux; Android 13; SM-N9860 Build/TP1A.220624.014; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/130.0.6723.58 Mobile Safari/537.36 TwitterAndroid
sec-ch-ua:"Chromium";v="130", "Android WebView";v="130", "Not?A_Brand";v="99"
sec-ch-ua-full-version:"130.0.6723.58"
sec-ch-ua-full-version-list:"Chromium";v="130.0.6723.58", "Android WebView";v="130.0.6723.58", "Not?A_Brand";v="99.0.0.0"
sec-ch-ua-mobile:?1
sec-ch-ua-model:"SM-N9860"
sec-ch-ua-platform:"Android"
sec-ch-ua-platform-version:"13.0.0"Example 3
User-Agent: Mozilla/5.0 (Linux; Android 10; SM-N960F Build/QP1A.190711.020; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/130.0.6723.58 Mobile Safari/537.36 TwitterAndroid
sec-ch-ua: "Chromium";v="130", "Android WebView";v="130", "Not?A_Brand";v="99"
sec-ch-ua-mobile: ?1
sec-ch-ua-platform: "Android"
sec-ch-ua-platform-version: "10.0.0"
sec-ch-ua-model: "SM-N960F"
sec-ch-ua-full-version-list: "Chromium";v="130.0.6723.58", "Android WebView";v="130.0.6723.58", "Not?A_Brand";v="99.0.0.0" 
data51degrees
commented
4 hours ago @Drozdova-N Our team have reviewed the headers you have provided. We have noticed that in each case we have seen the user-agents before, but we have not seen that combination of user-agents and client hints shared with us.
When client hints are provided alongside a user-agent we use all available data to determine the best match. This detection is based on data that has been shared with us through usage sharing. Where we haven't received this combination of user-agent and client hints, our v4 algorithm will provide detection informed by what is available in the database. In many cases this results in correct detection but it can be less reliable which is likely why we were not able to recreate @a1ekas issue in the user-agent tester on a different day.
As we have seen the user-agent before, when this is provided alone the detection will be correct and very reliable.
Solution: Over time, we may receive this data from another source but you can improve issues like this by using the usage sharing feature yourself. Through this, the file you receive from us can be informed by data that is reflective of your environment. For more information on how to set this up here is our usage sharing developer documentation https://51degrees.com/documentation/4.4/_features__usage_sharing.html
Here is an example that has been shared with us before - https://51degrees.me/developers/user-agent-tester?headers=User-Agent%3A+Mozilla%2F5.0+(Linux%3B+Android+14%3B+SM-S918U+Build%2FUP1A.231005.007%3B+wv)+AppleWebKit%2F537.36+(KHTML%2C+like+Gecko)+Version%2F4.0+Chrome%2F127.0.6533.103+Mobile+Safari%2F537.36+TwitterAndroid%0D%0Asec-ch-ua%3A+%22Not)A%3BBrand%22%3Bv%3D%2299%22%2C+%22Android+WebView%22%3Bv%3D%22127%22%2C+%22Chromium%22%3Bv%3D%22127%22%0D%0Asec-ch-ua-mobile%3A+%3F1%0D%0Asec-ch-ua-platform%3A+%22Android%22%0D%0A
Note: The user-agent tester it requires a space between the header name and the start of the header contents. You can use the Evidence tab to confirm that the headers are being identified correctly.
Hello.
For the latest bases (we use
Enterprise-HashV41.hash) I found that there is a strange behaviour in detection ofTwitter for Android.It is similar with this https://github.com/51Degrees/data-issues/issues/2I’ve tested this across different versions of the 51Degrees device detection library for Go https://github.com/51Degrees/device-detection-go (v4.4.38, v4.4.39, v.4.4.41), and also through the online service - https://51degrees.com/developers/user-agent-tester
So, if I use only user-agent header
the detection is:
But if I use the same UA with the such client hints headers:
the detection is: