Responsive Design ExampleOver the last year or so Respon­sive Web Design (RWD) has gained siz­able atten­tion within the web world.  With the ris­ing tide of smart­phones and tablets and the vast vari­ety of screen sizes these devices rep­re­sent, com­pa­nies are look­ing for eas­ier and more effec­tive ways of pro­vid­ing their con­tent across mul­ti­ple screens.  Although RWD does have its imple­men­ta­tion chal­lenges, by and large it is seen as the panacea to the multi-screen headache.  Inter­est­ingly enough, when list­ing out the prac­ti­cal chal­lenges of insti­tut­ing RWD on a large scale, very few have men­tioned the impact of RWD on web ana­lyt­ics.  In this post I will dis­cuss this prob­lem and some best prac­tices in imple­ment­ing ana­lyt­ics on web sites using RWD.
The Basics — RWD Lay­outs
Before div­ing into the ana­lytic chal­lenges of RWD sites, lets take a step back and get a bet­ter fla­vor for the dif­fer­ent types of RWD lay­outs and how they differ.

In gen­eral, there are three types:  Basic Fluid Lay­out, Adap­tive Lay­out, Respon­sive Lay­out.  If you’re on a desk­top or lap­top com­puter, look at the web site exam­ples below and adjust the win­dow screen-size width and see the sub­se­quent impact on dis­played content.

  • Basic Fluid Lay­out
    Con­tent con­tin­u­ally flows or adjusts in a word-wrap fash­ion as screen width is increased or reduced.  There are no “dis­tinct” dif­fer­ences in con­tent pre­sen­ta­tion.  Web Site Example
  • Adap­tive Lay­out
    There are pre­de­fined sizes where dif­fer­ent lay­outs are trig­gered.  These are called break points.  Typ­i­cally there are three or four break­points to accom­mo­date desk­top, tablet and mobile screen sizes.  Web Site Example
  • Respon­sive Lay­out
    This is a hybrid of Basic Fluid Lay­out and Adap­tive Lay­out.  There are pre­de­fined break points, how­ever in between these break points con­tent will flow to expand or con­tract.  Web Site Example

Cur­rently, most RWD web sites use Respon­sive Lay­out since it offers a best-of-both-world expe­ri­ence.  Con­tent snaps into the appro­pri­ate approx­i­mate posi­tion for a device type (e.g. Tablet) and then fine-tuned adjust­ments are made for the exact screen size on a par­tic­u­lar device (e.g.  iPad Mini: 1024×768 | Nexus 7: 1280×800).
Impact of RWD on Web Ana­lyt­ics
Think about your reac­tion when you are typ­ing on a key­board with­out look­ing at your hands nor the words being typed-out when you sud­denly real­ize that your fin­gers are mis­aligned on the home keys (“asdf” and “jkl;”)?  All your care­fully crafted words or code appear as cryp­tic gobbly-goop.   This hap­pens because your cen­tral point of ref­er­ence (i.e. the place­ment of your hands) is mis­aligned.  The same thing hap­pens when we are exam­in­ing web ana­lytic data from our RWD web site but haven’t accounted for what par­tic­u­lar RWD expe­ri­ence was pro­vided to a given user.  Just like one-size web con­tent won’t fit all screen-sizes, the same “one-size” approach to web ana­lyt­ics on RWD sites won’t yield accu­rate insights into user expe­ri­ence and the down­stream impact on con­ver­sion or engage­ment.  For exam­ple, if you’re look­ing at the aggre­gate data on a con­ver­sion fun­nel for a RWD site and entry to that fun­nel was a but­ton on the home land­ing page, you could eas­ily miss that cer­tain device screen-sizes don’t cor­rectly show or place the but­ton.  For­tu­nately, it is rel­a­tively easy to account for a few impor­tant RWD data ele­ments, as I will dis­cuss next.
Ana­lytic RWD Best Prac­tices
There are three dimen­sions that should be tracked for RWD web sites (assum­ing a Respon­sive Lay­out is being used):
1) Ren­dered Expe­ri­ence accord­ing to set break points (e.g. Smart­phone, Tablet, Desk­top)
2) Screen Size for the win­dow or view­port (e.g. 1024×768)
3) Ori­en­ta­tion (e.g. Por­trait vs. Land­scape).
For sim­plic­ity set these vari­ables in Site­Cat­a­lyst to eVars on each request (props can be used in addi­tion to eVars, if needed).

Although it’s beyond the scope of this post to go into details on how to cap­ture these three dimen­sions, for sim­plic­ity I’ll show a brief JavaScript s_code example.

//Rendered Experiences (with specific break points)
if (document.documentElement.clientWidth >= 320 && document.documentElement.clientWidth <= 480) {
if (document.documentElement.clientWidth >= 768 && document.documentElement.clientWidth <= 1024) {
if (document.documentElement.clientWidth >= 1224) {

//Screen Size
s.eVar27=document.documentElement.clientWidth + 'x' + document.documentElement.clientHeight;

case -90:
case 90:

//NOTE:  Please adjust selected eVars as well as specific break points to match your current needs.

It should be noted that RWD web sites typ­i­cally use Media Queries within CSS to detect and trans­form the lay­out of web pages.  A chal­lenge lies in that there are no well estab­lished means for JavaScript to com­mu­ni­cate with Media Queries (although there are a few emerg­ing approaches on how to bridge this gap).  For the sake of sim­plic­ity and brevity, I’ve lever­aged the DOM in the above code exam­ple to approx­i­mate what is done with Media Queries to detect screen sizes.

Some may be won­der­ing why we need to cap­ture screen size when that infor­ma­tion is avail­able out-of-the-box within Site­Cat­a­lyst reports.  There are some cases where the screen size that’s shown in report­ing (derived via the user-agent) and what the actual screen size is are dif­fer­ent.  For exam­ple, the iPad Mini and iPad2 will both appear as 1024×768 within out-of-the-box reports even though the iPad2 actu­ally has a screen size of 2048x1536.   The rea­son for this dif­fer­ence in this par­tic­u­lar exam­ple is that Apple uses the exact same user-agent on these two devices.
Report­ing Exam­ple
To illus­trate the type of analy­sis that can be done with these RWD dimen­sions, let’s look at fun­nel con­ver­sion for a Tablet ren­dered expe­ri­ence and sub-relate screen size (we eas­ily could have looked at ori­en­ta­tion instead).


Look­ing at the Com­plete / Start con­ver­sion ratio, we can quickly see where things are going great (960×1024) and not so great (720×1024, 600×800) within the Tablet RWD expe­ri­ence.  With this infor­ma­tion I would go through the fun­nel on the respec­tive devices (if not pos­si­ble, then sim­u­late RWD expe­ri­ence on a desk­top web browser) and look for clues on why a dif­fer­ence exists and what could be done to improve con­ver­sion.  How­ever, keep in mind there could be other fac­tors at play (e.g. bezel size) for a par­tic­u­lar device that pos­i­tively or neg­a­tively impact con­ver­sion that may not be tied directly to RWD.

Although the pri­mary pur­pose of this post is to exam­ine the impact of RWD on ana­lyt­ics and solu­tions to over­come these chal­lenges, the pre­vi­ous report­ing exam­ple illus­trates the power of ana­lyt­ics on RWD.  Whether quickly spot­ting prob­lem areas or find­ing screen sizes that out­per­form the rest, ana­lyt­ics is a valu­able feed­back tool in doing RWD opti­miza­tion.
Addi­tional Con­sid­er­a­tions
Below are addi­tional items you may want to con­sider with RWD and mobile optimization.

Full Site “Fail” Events
Although not directly related to RWD, often on mobile opti­mized sites exists a “Full Site” link where the user is taken to the desk­top expe­ri­ence.  If you haven’t already, an event should be cap­tured when this link is touched upon.  In real­ity, such an action by the user should be con­sid­ered a “mobile-optimization-fail” event.  If the mobile user can’t find or do what he or she is ulti­mately want­ing on your opti­mized site, you as a web ana­lyst should be aware of such actions.  By hav­ing this met­ric within your reports along with the con­text of what the user was doing up until they touched on the full site link (and even bet­ter what he/she did after­wards), you can poten­tially find areas of improve­ment that will reduce the like­li­hood of users aban­don­ing your mobile opti­mized ship.

Big Screen Sizes
Since the pur­pose of my blog is to focus on mobile web ana­lyt­ics and opti­miza­tion, I focus on smaller screens (com­pared to desk­top) as it relates to RWD.  How­ever, in real­ity RWD can equally accom­mo­date “real big” screens and not just small ones.  Whether in liv­ing rooms on Ultra HD (aka 4K) dis­plays (3840×2160) or new Retina dis­plays by Apple (2880×1800), there is a lot of valu­able real-estate that can be uti­lized (and mea­sured) that shouldn’t be left as extra-wide margins.

Pixel Den­sity
Although not included as a base-line RWD dimen­sion as dis­cussed pre­vi­ously, pixel den­sity is a grow­ing area of impor­tance than can impact user expe­ri­ence (e.g. touch tar­gets) and con­ver­sion.   You may want to include this dimen­sion if the web expe­ri­ence you have crafted war­rants it.