Navigating Downside Of Responsive Design
Our readers want to get our content everywhere, and so our content has to look great everywhere. Simple right? Readers are using multiple kinds of devices, also, everything from iPhones and huge Android phones to tiny tablets and every browser resolution you can dream up to interact with our content.
How do publishers keep up? It’s no longer enough to simply have a single mobile site or even a single tablet site.
For our own solution, Shaw Media, the 163-year-old, family-owned, 100+ print and digital publication company that operates in Illinois and Iowa, opted to move quickly into the responsive design space. It solved our problem of looking great on every device. But there was a downside: responsive design has also created as least as many problems as it has solved. The redesign created issues for us ranging from traffic analytics to ad inventory reporting, page performance and vendor integrations.
Responsive is an approach to Web design that results in a single website that will look great on any range of devices. From the largest “phablet” one can find to the smallest, oldest computer monitor, publishers only have to update the site once. This is often accomplished by laying out a website with a fluid, grid-based template style.
Among the Shaw sites, for example, one can see this in action by visiting nwherald.com or mysuburbanlife.com on a desktop and dragging the lower corner of the browser window slowly inward. At certain sizes, the same page collapses and rearranges itself. Visiting the page from one’s computer and then from one’s smartphone further illustrates this dynamic.
On the upside, now that our 25-plus websites are responsive, we only need to post a story for one site once, thereby creating more time in editorial to produce and traffic relevant information. It also allows our teams to share on social media without worrying about what sort of device from which a user will view it. We can more effectively optimize and promote our websites on search engines by having a single site, and we are able to serve ads across all platforms with one campaign and effectively target devices as well as geography within our ad server.
But as mentioned, there was a four-part downside, starting with traffic analytics. Going responsive has helped us to grow our mobile audience since a mobile reader can now get to any content currently on our sites. One problem that has arisen, though, is accurately counting that growth.
In the past, we had a separate mobile site and a separate tablet site for each core news site. A script would then shuffle people to the appropriate viewing experience. We found that there was some duplication and there was an omission of devices and users happening within the reporting suite of Google Analytics.
Investigate how mobile sites counted
Our takeaway: publishers with mobile sites now who are considering a switch to responsive should take some time investigating how their mobile sites are counted in relation to their desktop site and make any changes needed to the site’s traffic reports at least a month before the switch.
Ad serving has been greatly streamlined by moving to responsive. However, internal reporting on the inventory became more confusing. We use Google DFP for Small Business to serve our local display ads. What we learned on reporting is that it counts an impression when a page with its ad tag is loaded regardless of whether an ad is served or not. So the ads that we enter are all served properly and on time, but historical reporting becomes hard to distill.
This is a problem for all responsive sites that use DFP since all of the scripts load when every page is loaded. Some of the pages are from regular computers so they don’t require serving an ad to the extra mobile ad spot. Google reports them all as an impression, even though an ad was clearly never served. One solution to this problem that we’ve found is to use a device detection script to decide what ad tags to load at the outset of the session.
Another issue we found was that responsive sites load slower on the phone than a mobile-only site. Since a website is loading the full site’s java scripts, the mobile page loads tend to be a little slower than the previous mobile-only site design had been.