Analysing your knowledge about your users. What do they tell you? Know your target audience and their capabilities!

In case you are using a service that handles your e-mail send out, you should already get information like that nicely presented, but how does it work?

Every e-mail send out gets a unique token, that is also reflected in links and images inside the email. It has several purposes:

a) One image serves as indicator that the e-mail was opened/seen/received by human - will referrer to it as ‘open’

b) Every click on a link inside the e-mail can be tracked to the source of that e-mail - will referrer to it as ‘click’

The unique token makes it distinguishable to filter multiple opens & clicks for one e-mail.

There is different main use in the data, depending on your job role ;-), me as a tester: what does the user tell me about his used technology; marketing campaign manager: How successful is the e-mail in terms of clicks/interactions?

What data is used? How to get it? It is the header information, that is send to the web-server, when either a) or b) is requested https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

See headers from your browser: http://www.delorie.com:81/some/url.txt

Example:

GET /some/url.txt HTTP/1.1
Host: www.delorie.com:81
Connection: keep-alive
Upgrade-Insecure-Requests: 1

User-Agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
DNT: 1

Referer:
http://www.delorie.com/web/
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en;q=0.9,en-US;q=0.8,de;q=0.7

Another nice playground to play with it on your own: https://canarytokens.org -> Custom Image Web Bug Or your own simple http server to dump request headers with phyton: https://gist.github.com/phrawzty/62540f146ee5e74ea1ab

Interesting fields for a) are: ‘User-Agent’ & ‘X-Requested-With’ and in case b) ‘User-Agent’ & ‘Referer’; let’s take a detailed look onto each:

  • i) 'User-Agent' In case of a) we get an insight into which e-mail client is used to display the e-mail - there might be a bias in numbers, since not all clients load images in e-mails per default, for details see https://litmus.com/blog/the-ultimate-guide-to-email-image-blocking The string needs to get processed by a library to make use of it and to cluster the result. My personal favourite is https://github.com/piwik/device-detector, it is open source and you are able to contribute your findings, beside that I found it very good from the analysing result. I would also see potential to use it with Piwik Analytics, by feeding the strings into it https://piwik.org/ To see a comparison of many available libraries at once, see this project: http://useragent.mkf.solutions/ where you also get the idea of what information is relevant to extract.
    In case of b) there should not be any surprises if you already do website analytics, the interesting part for me was in case a) to get insights into e-mail client distribution. It shows on which clients, devices the e-mail is displayed. To get an idea about mobile operating system versions see: https://developer.apple.com/support/app-store/ and https://developer.android.com/about/dashboards/index.html You could somehow also come to some conclusions by https://emailclientmarketshare.com/, but I feel much more confident when I analyse the real traffic. It serves answers to the question how much effort _we_ should spend on fixing display issues for some rare clients.

  • ii) 'X-Requested-With' This is more a side-effect, that only works on Android, but you get the e-mail client app id from there for case a). There is a bunch of apps out there where you could, as a first idea, make assumptions from the download numbers in the app store, but with that header field we can do better. It is a misuse to the original purpose of that field, but what do we care if it gives us some insights ;-) explanation here: http://www.justincarmony.com/blog/2015/03/11/X-Requested-With-AJAX-Requests-and-Android-WebViews/ : "When using a WebView in Android, it will send the name of the app (i.e. com.example.app)."

  • iii) 'Referer' In case of b) we can proof the use of a web-mail frontend, since the header field contains the domain, e.g. gmx.com / web.de - that are the obvious ones. For some domains it is not decidable just from the domain, you need to visit it, to see that e.g the OX App Suite https://en.wikipedia.org/wiki/Open-Xchange, or Outlook on the web https://en.wikipedia.org/wiki/Outlook_on_the_web is used - which are the most common ones with diverse domains. </ul> All this combined gives you information like this: Relative numbers from December 2017 from loading the open image from emails send out by a social business network based in and user base from german speaking countries.
    Android client apps used for reading emails:
    com.samsung.android.email.provider 4%
    com.android.email 3%
    com.microsoft.office.outlook 2%
    de.gmx.mobile.android.mail 1%
    de.web.mobile.android.mail 1%
    com.yahoo.mobile.client.android.mail 0.6%
    com.google.android.gm 0.5%
    de.telekom.mail 0.5%
    		 Operating systems used for reading emails:
    iOS 40%
    Windows 22%
    Android 16%
    Gmail Image Proxy 10%
    Mac 9.5%
    GNU/Linux 0.5%
    Windows Phone 0.2%
    Ubuntu 0.1%
    BlackBerry OS 0.1%
    		 Web-frontends used:
    FreeMail (web.de, gmx.net) 10%
    live.com 3%
    yahoo.com 1%
    t-online.de 1%
    OX App Suite 0.6%
    freenet.de 0.3%
    1und1.de 0.3%
    bluewin.ch ~0.1%
    What Gmail Image Proxy is about: https://litmus.com/blog/gmail-adds-image-caching-what-you-need-to-know Mobile/desktop ration: 54 % mobile devices, 33 % desktop More insights can be gained to take a look on the user agents used when clicking links inside the email - to weight out the bias of clients not loading the open image. ~20% of all send emails are opened - based on the open image was loaded, ~3,5% have clicks. One interesting story came from user complains, telling us by using OX App Suite, e.g vodafone.de they are seeing just a white page on opening the email. At the time of the report there exists no easy free possibility to get hold of an account for verifying and seeing the error on a system for debugging. I ended on installing the free available OX App Suite on my own system http://oxpedia.org/wiki/index.php?title=AppSuite:Open-Xchange_Installation_Guide_for_CentOS_7 and feeding emails into it and viewing them from a Windows system with Internet Explorer. It wasn't smooth to get it running, but straight forward with the recipe - in the end the error was reproducible. As of today it is much easier to test your emails with OX App Suite, just get an account here: https://freemail.ox.io This was the 5th and last article for now about testing e-mails.