Tracking the Kindle Fire’s Silk Browser with Google Analytics

Why Bother?

Recent reports are showing that the Kindle Fire is absolutely dominating the Android tablet market, accounting for almost a third of sales and aligning itself as a clear second to the iPad market leader. However, this may not be entirely apparent as the Mobile Devices reports in Google Analytics haven’t caught up yet to be able easily identify this growing and important segment.

However, the great thing about Advanced Segments is that if we can determine a unique set of characteristics for the device, we can segment it on our own.

Digging in: Technical details of the Kindle Fire’s Silk Browser:

Ideally we’d simply filter on the browser’s User Agent (UA), but Google Analytics doesn’t display this by default. On occasion we’ve utilized the Custom Variable feature to inject the UA into a slot, but keep in mind that this not only fills a Custom Variable slot (only five are available in the Standard (free) edition of Google Analytics), but you must truncate the UA to fit within the 128 chars allowed for a Custom Variable or it will be tossed out (the Kindle Fire’s UA is longer than 128).

The User Agent strings for the Kindle Fire’s Silk browser are as follows:

Cloud Accelerated Mode:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us;
Silk/1.0.13.81_10003810) AppleWebKit/533.16 (KHTML, like Gecko)
Version/5.0 Safari/533.16 Silk-Accelerated=true

Non-accelerated Mode:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us;
 Silk/1.0.13.81_10003810) AppleWebKit/533.16 (KHTML, like Gecko)
Version/5.0 Safari/533.16 Silk-Accelerated=false

As you see above, a User Agent based approach gives us another piece of useful information unique to the Amazon Kindle’s Silk browser–whether or not the cloud accelerated browsing mode is enabled. Ironically, tests show this “accelerated mode” is actually significantly slower, so it would be interesting to see if there was a measurable difference in visitor behavior.

However, the reality is that most accounts haven’t installed any custom code to track User Agents, so this isn’t an option. In order for us to segment this device we’ll have to understand how visits from it are recorded in Google Analytics and isolate them via an advanced segment. Based on some tests, I found Google Analytics records the visits from the current version of the Kindle Fire with the following attributes:

1. Mobile Device? = No
2. Devices Report = blank/not recorded
3. Browser = Safari (currently version 533.16, which is obviously subject to change.  No designation as “Silk” apparent at this time)
4. OS = Macintosh (Interesting to note, since this is an Android device)
5. Screen Resolution: 800×1092
6. Flash: “Not Set” by default or 10.3 r186 (if manually enabled in the browser settings)
7. Java support: No
8. Network: Wi-Fi provider, (such as Comcast)
9. Location: Wi-Fi provider (even with Silk acceleration enabled)

There was some question over whether the network based acceleration and caching would affect the location and network reports since some of the network requests are made from Amazon’s servers rather than the end device.  Of particular concern would be the UTM.gif request that provides the data (including IP address) back to Google’s servers.  Normally I would trace the HTTP requests directly, but since the Kindle doesn’t support proxy servers, we can’t utilize a packet sniffer such as Charles or Fiddler. However, we can infer from the testing above that the GIF requests do not appear to be affected since the location reports were both accurate, even in the accelerated mode.

Creating the Advanced Segment

Based on the information above, we can create an advanced segment as seen below:

Applying this to an account we can see the following reports that include only Kindle Fire based visits.  As a final sanity check, we want to ensure that the visits started after late November when the devices first began shipping to end users.

Further thoughts:

1. The Kindle will almost certainly be included soon in the Mobile Devices report so the shelf life of this is likely short, but there will always be some new gadget introduced, so the concept can be re-applied.
2. You could theoretically get false positives via a Mac user with that screen spec, but that’s highly unlikely due to the unusual screen size.
3. If you want to account for all Android devices, you have to include this segment since it’s an Android OS but incorrectly reports as Macintosh.
4. You could likely devise some filters that would output and overwrite the browser (or OS) field to accurately identify this device, but this wasn’t a priority in my work due to #1 earlier in this list.

Have any other thoughts on useful segmentation or analysis of the Kindle Fire?  Leave a comment!
Want more ways to enhance your tracking? Read more posts on custom reports.