Google Analytics iPhone Model and Resolutions:
This is a useful reference table for all my analytics friends. If you’re looking for a way to figure out the iPhone models coming to your site in Google Analytics, this is what you need! Don’t use the GA reports — as they have a number of problem areas. Use this table instead:
UPDATED 5 Jan 2022:
iPhone 12 & 13/12 Pro & 13 Pro (6.1", 390 x 844)
iPhone 12 & 13 Mini (5.4", 375x812)
iPhone 12 & 13 Pro Max (6.7", 428x926)
Iphone SE 2020 (4.7", 375x667)
I’m disappointed here because it would appear Google have added a new ‘iPhone Model’ dimension to Google Analytics. That’s incredibly useful and very welcome but let me explain why it was needed.
I have been complaining that GA does NOT identify the iPhone model correctly for iPhone visitors for some time (about 3 years) and found my own workaround, using the device resolution of each iPhone to figure out the model. I come from a background of wading around in HTTP logs and looking at user agent strings, so this was familiar territory to me. I had hoped Google would fix this soon, but that was 3 years ago.
The problem with the GA identification is that it works (using Mobile Device Info for example), but only works for those users visiting a website with an ‘in app’ browser. For all other visits to a website, every iPhone would simply record as a generic “iPhone” with no model number or identification. That’s why in 95% of my data, there was no model numbering.
After much head scratching, I figured out this was down to the way GA and the security model in the browser worked. The method GA was using to get the model number, only actually worked inside the app security model. One could argue this was not the ‘fault’ of Google per se but I feel it is their ‘responsibility’ to ensure that the data they present to people in their reports is ‘meaningful’ and not ‘confusing and inaccurate’. There are plenty of other ways to identify the iPhone model that aren’t being used — so why use something that’s broken and horribly fragments and skews the data? I’d rather they didn’t do stuff like this at all, than implement it in a way where people might mistakenly trust what they are seeing.
I’m a capable analyst but I struggle to use GA (without automation) to get basic device info from my client setups. They really need to overhaul this, which is why I was delighted when I noticed the new dimension. Just one problem — they seem to have got this wrong and I’m going to help them fix it.
So take a look at that table above — those are the iPhone resolutions I’m seeing on a site. I’ve filtered out iPhone models 1–4 here (resolution is 320x480 if you’re interested). So these are the big traffic visitors I’m seeing for iOS operating system, mobile device category. So what models do these resolutions map onto?
Why don’t we try the new dimension then:
Now that looks good at first glance. Did you notice the drop in total users though? Let’s start at the bottom of the table and work our way up the resolutions.
320x480 (iPhone 1/3G/3GS/4/4S)
GA correctly identifies 320x480 resolutions as iPhone models 1–4. That looks spot on but I don’t see any point in knowing it’s anything but a 4 or less.
320x568 (iPhone 5/5C/5S)
What about the iPhone 5 models? Well — they are missing the iPhone SE, which is very popular in lots of markets. They need to fix the label here to say “iPhone 5,5C,5S,SE”. That’s an easy fix.
375x667 (various)
This one is bang on the money with the labelling and models listed but about 8K of users are missing, because they’ve been split off by adding the “(Display Zoom)” part. It’s a good intention here — because what google are trying to do is show you that some phones can be set to zoom the entire UI. For example, an iPhone 6S with zoom enabled will look like an iPhone 5 and an iPhone 6+ will look like an iPhone 6S.
I doubt this is useful for analysts or general users of GA, so why fragment just one of these buckets like this? Fix the fragmentation here and it becomes more useful and usable for all. I would advise against detecting the UI zoom, simply because the basic device ID isn’t yet set up correctly and this pollutes already dirty water.
Last bit of info — the label is wrong here and should say “iPhone 6+/6S+/7+/8+ (Display Zoom enabled)” instead of “iPhone 6/6S/7+/8+ (Display zoom enabled”)
414x736 (iPhone 6/6S/7+/8+)
The next resolution up (414x736) is just plain wrong. Firstly, Google have used the same model names in two different dimensions. How can you have one called “iPhone 6/6S/7+/8+” for 375x667 and another called “iPhone 6/6S/7/8” for 414x736 — they both can’t be true, so you now have two datapoint labels that are duplicated. That’s not good at all. Confusion reigns.
Easy way to solve this — it should say “iPhone 6+, 6S+, 7+, 8+” because that’s correct!
375x812 (missing)
Now let’s look at the next dimensionalisation — the 375x812 resolution — which is simply NOT THERE AT ALL. Because Google haven’t updated the device ID to include the X, XS and 11 Pro models, we have 58K users who just bloody vanish if you use the iPhone model dimension. I don’t like data that filters my dataset because it has holes in it. That dimension should be populated for these users but it isn’t. Bad device ID.
414x896 (iPhone XR)
Lastly, there’s the 414x896 resolution which seems to only identify the iPhone XR. My own data shows they are not identifying the iPhone 11, XS Max, 11 Pro Max for that dimension (which they should) so this is missing too.
In total, we have:
Two incorrect labels
One fragmented dimension
One duplicated label value
25% of users missing due to non identification
This isn’t optimal by any stretch. We simply cannot understand or analyse sites with high mobile traffic where we have a fundamentally broken data model!
I put out a message here to Google or anyone working on the device ID stuff to get in touch, please! Work with me and my team and we can use our testing labs to tune and verify all the GA identification so it’s actually fairly *complete* and *correct* — so everyone gets wonderful reports.
None of the new mobile device reports you are playing with make any sense, unless you fix these underlying issues with the data. I’ve written a complete article about some of the flaws and workarounds I’ve had to use but it would be great to use all this knowledge to help you actually improve the product for everyone who uses it.
I’ll do this work completely for free, as long as you can put me in touch with someone who can make this happen and that you give this to the analytics community as quickly as possible, in the form of an update.
For now, this table and these resources might be useful. This is what I now use for mapping phones:
This is an incredibly useful article:
This is incomplete but concurs with the above and what I’m seeing from testing the data:
C.