The unique browser fallback issue

When a cookie is not accepted by a browser then a fallback value is used in order to achieve a limited uniqueness. As with any alternative method there are pitfalls and subsequent issues one needs to keep in mind, but also continuously monitor the fallback impact on unique browser count.

text

3rd party cookies

The acceptance and lifespan of a 3rd party cookie has been in decline since inception, but the notable difference is best visualized on numbers based on desktop vs mobile devices.

Mobile devices have a quite obvious rejection of 3rd party cookies hitting over 90% (note: IP + user agent string hash = fallback key "ip").

Desktop computers on the other hand tend to accept 3rd party cookies more, however the cookie lifespan is questionable on a visit to visit basis if treated as session cookies.

Browser settings to treat a permanent 3rd party cookie as a session cookie (cookie dies after visit) and cookie erasure creates a growing insecurity on the validity of unique browsers based on 3rd party cookies. 3rd party cookies are however mandatory for network summary of unique browsers...

text

1st party cookies (FPC)

Cookie rejection drops once 1st party cookie is used on mobile devices, it is no magic bullet however even if the issue has less impact.

Quite a number of smartphones are set to block all cookies ensuring these devices will never accept any cookie, no matter if it is a 1st or 3rd party cookie. In the weekly data set used still +13% block even 1st party cookies.

This means that the percentage of fallback use in the counting of unique browsers dictates the inaccuracy level caused by fallback share tainting the unique browser count.

In order to visualize how the use of a fallback identifier when counting unqiues results in quite an inflated number see the image below.

text

In this example a unique FPC value was present as a parameter value in every measurement over a week generated by a mobile device.

The device blocked the 3rd party cookie which caused an IP + user agent hash (i.e. IP in images) to be used as a fallback unique value. Since the device was an iPhone using both 3g/4g and WiFi connectivity it utilized multiple IPs, this is evident with 3g/4g unique count on the provider 3 (Swedish).

In such a case where a device jumps over multiple IPs the fallback unique count will be inflated (22 to 1)... Mobile devices do move around!

But it is crucial to also understand that the use of fallback values can undercount as well, a simple example is in a workplace environment where iPhone 6 is the corporate phone and connection to the internet is via a firewall. If all phones have the same OS update and browser version and use the same browser the number of unique browsers based on the fallback value will be... 1! So the inaccuracy depends on a few key factors.

text

Fallback inflation

The example in the last chart displays the number of daily unique identity fallback values ("ip" = IP + user agent) measured on the same device identified by the FPC value in the measurements.

The unique identity values counts up to 33 on a per day unique basis, week uniques equaled 22 for the same device. This is an example of when use of a fallback can massively inflate the unique browser count for a single device (not just mobile).

Addressing the fallback issue

There is a very apparent problem with the use of fallback uniques, if over <put acceptable value here>% of your unique browsers are based on fallback then this requires fixing.

The fallback inflation can be addressed by appending other unique values to the fallback hash. User logins will do the trick as an example. After all, a reliable count is better is it not?!?

Check your fallback ratio & secure your unique browser count!