Hi there,
Has anybody ever set up tracking in Adobe Analytics to understand which font sizes users select when browsing an app?
We can see which are the most popular screen resolutions used to browse our Android app, but are interested in font size selection specifically.
Reason for asking - we want to understand if screens are being cropped by devices, and how many users might be impacted.
Any advice/experience much appreciated!
Many thanks,
Dan
Solved! Go to Solution.
Views
Replies
Total Likes
We are tracking it... but it's the sizes declared by our own internal font size options in our apps settings... (numeric value between 1 and 6). This represents the main body font sizes. In any website/app there will be multiple font sizes in use on any page (headers, content, footer, etc)... so I guess you first need to understand what all you want to track (main content font size? or all sizes), and how to represent this information in such a way that you can use it (I recommend a specific pattern of representing the data in a prop or eVar that you can create classification rules to parse for multiple sizes tracked).
Next comes the fun part of how to get the data... I tend to work with our app developers directly, I tell them what I want, what I am trying to track and how... and we work together to figure out a context variable that they can set and when to send it.
If you don't have a setting in the app for font size, and you are trying to get this info based on the user's device settings, you will need to see if your developers can read this info and parse it into something meaningful; and that code will be different for iOS and Android. You may be able to get more data from one system or the other, and you will need to make the decision if you are okay with knowing it for only certain groups of users or not.... (assuming that this info is hard to get... you might have no issues in either OS).
Depending on your apps, you could also just see if your developers can detect content being cropped (content area larger than the visible area)? Given your use case, something like that could be used either on it's own, or in conjunction with the font size to try and determine how many people are impacted.
I hope this gives you some things to think about and to ask your developers about... good luck.
We are tracking it... but it's the sizes declared by our own internal font size options in our apps settings... (numeric value between 1 and 6). This represents the main body font sizes. In any website/app there will be multiple font sizes in use on any page (headers, content, footer, etc)... so I guess you first need to understand what all you want to track (main content font size? or all sizes), and how to represent this information in such a way that you can use it (I recommend a specific pattern of representing the data in a prop or eVar that you can create classification rules to parse for multiple sizes tracked).
Next comes the fun part of how to get the data... I tend to work with our app developers directly, I tell them what I want, what I am trying to track and how... and we work together to figure out a context variable that they can set and when to send it.
If you don't have a setting in the app for font size, and you are trying to get this info based on the user's device settings, you will need to see if your developers can read this info and parse it into something meaningful; and that code will be different for iOS and Android. You may be able to get more data from one system or the other, and you will need to make the decision if you are okay with knowing it for only certain groups of users or not.... (assuming that this info is hard to get... you might have no issues in either OS).
Depending on your apps, you could also just see if your developers can detect content being cropped (content area larger than the visible area)? Given your use case, something like that could be used either on it's own, or in conjunction with the font size to try and determine how many people are impacted.
I hope this gives you some things to think about and to ask your developers about... good luck.
Views
Likes
Replies
Views
Likes
Replies