We have a lot of device "finger prints" in our system. Currently over 500k active. We've therefore not found a problem in the real world of a real device causing a problem. However we could consider how close the match is and not using it if it falls below a certain threshold.

How would you like to see the default device setup working? I think it would need to be user configurable, perhaps via an XML patch file.

Thoughts welcome.

Thank you.

James

Points 1 to 4 are pretty much what happens already today. Our approach is to ensure the distributed database (about 43k device headers) contains sufficient detail to ensure over 80m real device headers we have on the system are almost all matched correctly. If an artificial device is presented to the system such as "asjkfhkdjs" then we'll work on the assumption it's close to something we've seen before and try and match it. As it's not real we'll provide a response which may seem odd as explained in previous posts.

We've moved away from the hierarchy/fallback design of other providers because they're not as accurate at detecting real devices as seen in the "wild". We saw this first hand when trying to maintain a hierarchy model 18 months ago. We think 1) accuracy at detecting real devices, OS and browser is the most important factor in a device detection solution, closely followed by 2) being easy for developers to deploy and 3) performance. We achieve all 3 in our solutions.

As a result of all this we're working to eliminate points 5 and 6. The enhancement would need to have a scoring system and some sort of device hierarchy to fall back to if a threshold was exceeded. I'm thinking about how to do this and welcome your thoughts assuming my explanation above makes sense.

Thanks,

James