One way around this is to sandbox ads within iframes to allow them to load independently of the page content. Here’s another demo showing the same 3-second lagging ad request but this time the ad is load within an iframe, allowing the content to display unblocked.

Loading ads in iframes is nothing new, and in some cases it’s easy to do; but if you’re working with many ads per page or uncooperative ad servers, it can be more of a challenge. For instance, when there are multiple ads on a page it’s common for the ad server to have to coordinate which ads display at the same time. There may be a requirement that Advertiser A’s campaigns do not display at the same time as Advertiser B’s. Or there may be companion units that have to display at the same time. This inter-ad-unit awareness is often achieved by batching the ad requests into a single call to the ad server. But, depending on your ad server, this technique may not be compatible with iframe ad loading.

In this post I’ll show an example of how you can hack one ad server (24/7 Open AdStream) to make its single-request implementation work with iframes.

MJX

OAS has several different implementation methods (NX, RX, JX, SX, MJX), each with pros and cons. The one I’ve used the most is MJX, which allows for the greatest control over how campaigns can be coordinated with one another (companion serving, competitive serving, etc) by batching the individual ad requests into a single ad server request. This is how it works.

In the HEAD section of your page you build up a request to OAS that tells the ad server which ad positions you want, what “page” (“Page Tag” in OAS terms) the campaigns should correspond to, and possibly some other stuff like key/value pairs to achieve additional targeting layers. OAS then returns a script with a function that writes out each ad unit. It looks something like this:

function OAS_RICH(position) {
  if (position == 'Top') {
    document.write(...);
  }
 
  if (position == 'Right') {
    document.write(...);
  }
}

This function is then invoked with the corresponding position name from the various ad placements on the page (e.g., <script>OAS_RICH('Top')</script>).

Here’s an example showing a mock MJX implementation that includes 2 ads, each consisting of JS that uses document.write to write an image to the page. The first script is returned with a 2-second delay, the second script with a 3-second delay. You can see how both paragraphs of text are blocked while we wait for the scripts to return from the server.

Notice that everything is blocked, including the request for the second ad, which means the delays are compounded, which means it takes 5+ seconds for both the DomContentLoaded and window.onload events to fire.

Iframes

So at this point we have a global function, OAS_RICH(), that’s responsible for writing each ad unit. To load the ads within iframes we need to create documents for each ad position and then call the OAS_RICH() function from within the child documents.

This is fairly easy but it’s not quite as easy as just calling parent.OAS_RICH('Top') from the iframed window. Why not? Because of JavaScript’s static/lexical scoping. The document object defined in the OAS_RICH function refers to the parent window document, not the child window document invoking the function. So calling the function from within the iframe overwrites the parent document. That’s not what we want.

I don’t know of a solution to this that isn’t a hack. But maybe someone with more experience working with iframes can offer a better idea.

The easiest solution, I think, is to convert the OAS_RICH function to a string and then reevaluate the function in the context of the iframe.

var ad = parent.OAS_RICH.toString();
eval(ad);
 
OAS_RICH('Top');

This is a little funky because aside from the eval usage this reevaluation has to be done for each ad unit on the page.

Another option: In the parent document convert the function to a string, regex replace each “document” with “this.document”, and then eval the string to redefine the function. Then you can call the function using apply() within the child document and pass it the child document context. The advantage here is that the funky function->string->function action only happens once. The disadvantage is that you’re introducing a regex and manipulating the contents of the function.

Here’s an example showing how the content isn’t blocked when the iframe implementation is used. The ads load independently, the DomContentLoaded event fires right away, and the window.onload event occurs after 3 seconds instead of 5.

(As a side note, I should point out that serving expanding ad units with iframes can require extra steps to allow the creative to “break out” of the iframe.)

Get to know your 3rd party code

This is kind of hacky but it’s also not very complicated, so I think it could be a useable solution (disclaimer: I haven’t used this in Production).

However the point of the post wasn’t to deliver ready-to-paste code, but to crack open some third-party JavaScript to understand how it works and how we might bend/extend it to meet our needs. Of course you have to be very careful doing this—don’t just run around tearing up vendor code. But there’s a lot you can learn by reaching in, getting your hands greasy, and making 3rd-party code your own.

Fortunately this is easy to do. Of course you can track visits and pageviews with the standard Google Analytics implementation, but there are some app-specific behaviors we can track with just a little bit of JavaScript.

So I’m going to show some examples of how to track home screen web app activity using Google Analytics custom variables. Depending on what exactly you want to track you may consider using Google Analytics events instead, but for data directly tied to pageviews or visits I think custom variables is the cleaner choice.

Remember that custom variables definitions must be followed by a _trackPageview() or _trackEvent() request. So as far as code placement is concerned you would place the following examples after the initial Google Analytics set up snippet and before the _trackPageview() function call. Also note that each of the examples uses the same custom variable slot. You’ll want to replace these with your own slot values.

Track home screen launches

This sets a custom variable every time we detect a visit that occurs in the web app mode. This will allow you to segment the home screen web app traffic and compare it against traffic arriving through the browser.

if (navigator.standalone) {
 
  _gaq.push(['_setCustomVar',
    1,                       // Which custom variable slot to use
    'Mobile Web App',        // Custom variable name
    'Home Screen Launch',    // Custom variable value
    2                        // Sets the scope to session-level
  ]);
 
}

Track device orientation

This keeps track of whether the app is being viewed in portrait or landscape mode. Note that in this example the custom variable is defined at the page level, not the session level as in the previous example.

if (navigator.standalone) {
 
  var currentOrientation = (window.innerHeight > window.innerWidth) ? 'Portrait' : 'Landscape';
 
  _gaq.push(['_setCustomVar',
    1,                              // Which custom variable slot to use
    'Mobile Web App Orientation',   // Custom variable name
    currentOrientation,             // 'Portrait' or 'Landscape'
    3                               // Sets the scope to page-level
  ]);
 
}

Track time since last launch

This keeps track of how many days have passed since the last time the app was opened by logging a timestamp in local storage and comparing the dates whenever the app is launched. There might be a way to get at this same data just by looking at returning visitor stats in the standard Google Analytics view. Not sure though. And doing it with JavaScript is more fun.

if (navigator.standalone) {
 
  // Local storage detection
  var storage = (function() {
    var uid = new Date,
      storage,
      result;
    try {
      (storage = window.localStorage).setItem(uid, uid);
      result = storage.getItem(uid) == uid;
      storage.removeItem(uid);
      return result && storage;
    } catch(e) {}
  }());
 
  // If device has support for local storage
  if (storage) {
 
    var lastLaunch; 
 
    if (!storage.webAppLastLaunch) {
      // If app is launched for the first time    
      lastLaunch = 'First Launch';      
 
    } else {
      // Calculate days since last recorded launch
      lastLaunch =  Math.floor( ( +new Date - storage.webAppLastLaunch ) / 86400000 );
    }
 
    storage.setItem('webAppLastLaunch', +new Date);
 
    _gaq.push(['_setCustomVar',
      1,                // Which custom variable slot to use
      'Last launch',    // Custom variable name
      lastLaunch,       // "First Launch" or the number of days since last launch
      2                 // Sets the scope to session-level
    ]);
 
  }
 
}

What else?

These are just the first few ideas that popped into my head. Is there anything else that would be interesting to track?

Here’s one scenario to watch out for when developing mobile and other device-specific sites.

One redirect

If you’re redirecting a user based on the user’s device you want this redirect to happen only once. So if a user visits www.yourdomain.com and gets redirected to mobile.yourdomain.com, all links from that point on should be relative to the mobile subdomain. If you don’t do this, if your mobile site links back to the www subdomain, you tack on the wait time for the www->mobile redirect to each request. This is dumb.

You’ve probably configured your application or CMS or whatever to output relative URLs, so in most cases you should be OK (but you should check if you’re not sure.) But if your site uses a CMS where users routinely link to other pages—for instance a news site where editors link to other articles—it’s likely that these links contain absolute URLs referring to the desktop site.

That is, a link within an article that references another article may point to http://www.mydomain.com/article-2.html, as opposed to /article-2.html. Following this link from the mobile site results in another redirect. I’ve seen this on a number of mobile sites. Take a look at m.bleacherreport.com or mobile.theverge.com for live examples.

How to fix

It’s an easy thing to fix. One option is to have your CMS filter out same-domain absolute URLs before writing to the database. This is a good solution but requires that you have URL path parity between your desktop and mobile sites.

Another option is to add JavaScript to the mobile site to rewrite the links. Something like this:

// Rewrite article links to relative URLS
$('#article-body a').each(function(index, elem) {
  var oldhref = elem.href,
    newhref = oldhref.replace('http://www.yourdomain.com', '');
 
  $(elem).attr('href', newhref);
});

This requires the same sort of path parity but may be easier to implement.

That’s it

So the takeaway is to avoid cross-domain links that always redirect back to the originating domain. This can happen under various circumstances but a common one concerns mobile sites displaying content with hard-coded references to the desktop site. The solution is to ensure that all links are generated with relative URLs.

Of course you can avoid the problem entirely by not having separate device-specific sites, but that’s another matter!

Pretty slick. It anticipates a common action (right-clicking a logo to download it as an image) and it provides the most logical, most direct path possible for accessing the logo itself: clicking the logo itself.

I remembered this the other day when trying to decide how to organize navigational elements for a mobile design I was working on. I wanted to separate the principal navigation actions from the ancillary actions, but I was struggling to find an elegant way to distinguish the two. I noticed that most of the ancillary actions had to do with what I thought of as brand interaction, which is to say a sort of meta activity focused on connecting with the brand as opposed to using the app.

Hmmm. So what’s the most obvious access point for interacting with the brand?

Simple idea for a pattern

Imagine this is the navigation bar for your app or mobile site:

There are only two navigation options: a home button and a menu button that exposes a drop-down, or slide-out, or modal, etc, some form of navigation menu.

Of course at this point your eyes have raced ahead and you know that I’m lying because there are actually at least three navigation options. The logo can provide access to site actions as well:

The behavior suggested here is that tapping on the logo reveals a tray-like set of options for things like social media connection, RSS, email sign-up or contact, and app/site settings. These are all things that group together fairly well and all things that fit nicely under the “brand” label. (One exception might be the settings button, whose place in the tray is earned more for its meta-ness than brand relation.)

I like that this solution achieves the desired separation of core and auxiliary actions but what I really like is how it gives the auxiliary actions a logical home. Granted it’s not an explicit navigation option (I can hear the sirens of the Usability Police getting nearer as I type). But it’s discoverable and something I think could become quite predictable were this design pattern to become a thing.

Wait, but…

I know, website logos already perform an interaction function. They double as a homepage link. Sometimes, as is the case with this blog, there is no explicit home navigation and the logo IS the home link. It’s convenient for both site authors and users. The user expects it. It’s a best practice.

That’s all true. But I think it’s a heuristic that developed in the absence of a better alternative. Might as well the link the logo back to the homepage if you’re not going to do anything else with it. While I’m not arguing against home-linking logos, I don’t think we should write it off as a reserved behavior.

Deviating from this practice obviously raises the possibility of friction but I see it as low-cost. The user gets immediate feedback and the substituted behavior is innocuous. Also, in a mobile or app environment, where this would seem to have the most potential, the notion of a home-linked logo probably isn’t as relevant as on a desktop site.

If you know of any sites or apps doing this (I’m sure there are more than a few) please leave a note in the comments so the curious of us can have a look.

The shadowy transmission of user data that Aaron mentions raises concerns for multiple reasons. For one, end users have an interest in protecting their own privacy. Two, people who make websites have an obligation to protect user privacy for the benefit of their users (to what degree they are obliged is of course the subject of much debate).

There’s a third case that gets less attention, and it has to do with the interest that audience-monetized websites have in protecting user data for their own benefit. And I don’t mean it in the sense that honorable websites that look out for their users will be rewarded by appreciative customers. I’m referring to the importance of not letting valuable audience data escape to your competitors’ servers. That’s what this post is about.

First, I’ll restate the problem and concerned parties so you can decide if this is something you’re interested in.

Problem: Adding third-party widgets like Facebook’s Like button and Twitter’s Tweet button to your site opens up a one-way channel of data transmission between your site and the widget provider. This data allows the widget provider to know which pages on your site their users view.

Who should care about this: In the broadest sense, anyone who works on digital products. In particular, digital products with revenue streams dependent on providing third parties access to audiences. More particularly, products that generate revenue from advertising. Most particularly, the publishing industry, who, having spent the better part of the last decade hoping the internet would go away, is most vulnerable as it tries to wobble up off the mat.

What’s the big deal if Facebook knows that one of their users viewed certain pages on your site? Let’s get into it.

Free content cannot be monetized

First off let’s agree that free content is never monetized. Content you give away for free has no exchange value. That’s why it’s free. You can, of course, make lots of money offering free content by monetizing the audience that consumes your content.

Niche media markets provide an easy way to illustrate how this works. Imagine you’re in the business of selling vintage gumball machines to gumball machine enthusiasts. How do you get exposure to the small group of people interested in your product?

Ten years ago you would buy an ad in a print publication aimed at gumball machine enthusiasts. The publication would contain all sorts of interesting content for people who love antique gumball machines but the person paying for this whole operation—you, the advertiser—would obviously not be paying for the content but for access to a particular audience. And access to that audience would be worth a lot because how the hell else are you going to find those people?

For the publisher this is all good until someone else slithers into the market with a competing publication and offers access to the same audience for less.

OK, so this is Publishing 101, Advertising 101, nothing new, you already know this, everyone who works in the industry already knows it. And yet…

Who are we competing with?

Last year a financial institution invited a handful of media companies to their offices to talk about an upcoming rebranding campaign. I was in attendance and the list of invitees was made up of standard players like The Economist, Dow Jones, and Time. But there was one name that stood out from the others: LinkedIn.

I was delighted because LinkedIn’s name on the schedule was proof of something that I and one of my tech colleagues had been trying to impress upon others for awhile—that social networks like LinkedIn and Facebook are not partners with media companies, but competitors.

At first the response from some of my colleagues was one of confusion. “LinkedIn? Why are they here?” What was surprising was how quickly the confusion was dismissed and the threat shrugged off. Here we were competing for the same advertising budget on the same afternoon and yet they could still not see a social media company as a competitor. Now I was confused.

After a little discussion the answer emerged: “Yeah, but LinkedIn doesn’t write news.” Right. So as long as LinkedIn doesn’t start writing news we’re all good. Hmmm.

Fuuuuuuungibility

One of the very best pieces I’ve read on the state of online journalism is a recent article by Stijn Debrouwere titled Fungible. If you’re unfamiliar with the term, a fungible object is one that can be exchanged for another object of identical substance and value.

The article’s thesis is that “…journalism is not being disrupted by better journalism but by things that are hardly recognizable as journalism at all.” Stijn writes about how sites like Quora, Wikipedia, IMDB, and EveryBlock now fulfill many of the needs that people used to turn to journalism for. Audiences are exchanging journalism for non-journalism. And the thing is that they’re not exchanging it for something else, but for something that amounts to the same thing. (That’s the fungible part.)

Eggs

So again, it’s audience and not content that is the true business asset. Your audience, whether it’s a literal database of registered users or a free-roaming anonymous swarm of eyeballs (as is the case with most free content sites) is the thing to guard.

Mark Twain said, “Put all of your eggs in one basket—and watch that basket!” Media companies already have all the eggs in the audience basket. How well are they watching it?

This gets us back to the main point, which is that the web makes it very easy for one site to leak its precious audience data to another. All it takes is one widget, one little snippet of Javascript, to open up the gates.

Take the gumball machine example again but fast forward to the present and swap roles. Now you’re the publisher of GumballGuru.com and companies buy advertising on your site to gain access to your audience. On each of the pages on your site you have a Facebook Like button that reports back to Facebook which of their users are regular visitors to your site. This allows Facebook to build a database of people interested in gumball machines. The like button earns you some traffic from Facebook. Woot. But in exchange, you hand over your users. You squander your eggs.

Now your advertisers have another way to reach their target audience. Instead of buying ads on GumballGuru.com—as well as on your competitor GumballManiac.com—they can go to Facebook and purchase ads targeted at both users who like GumballGuru and GumballManiac. And they can do this at a much better cost.

By the way, if you don’t know, this is a real thing. You can go to Facebook today and purchase advertising exactly this way.

The sad thing is that publishers have been an accomplice to a heist they don’t yet realize they’re the victim of. It’s true that Facebook can collect this sort of data in other ways but they could never gather it so quickly and in such detail without cooperation from sites that did the hard work of building the audiences in the first place.

I’m using Facebook only as an example. It’s probably safe to say that the majority of third party widget providers are harvesting user data in some way. AddThis does, ShareThis does, Twitter does, LinkedIn does. We shouldn’t vilify them. The fact that the data is being collected doesn’t mean it’s been used in nefarious ways. You should just understand that when you add a piece of third-party JavaScript to your site, in exchange for whatever service you’re getting you’re giving the provider access to your user base.

It’s not the end of the world

I’ve painted a stark picture and admittedly reached out to extremes in an effort to clearly illustrate the problem. Not all media outfits are critically exposed to this threat. Advertisers and media agencies are not shifting their entire budgets to Facebook and LinkedIn tomorrow. There’s still question about the value of social network advertising. Journalism still has value and publishers are still more than capable of cultivating important relationships with their audiences. Facebook is not going to replace The New York Times (although it may replace GumballGuru).

The goal of this post was to draw attention to two ideas. One, that in a digital world, data about your audience IS your audience. And two, that data on the web is incredibly exposed and prone to being shared in ways even the people building the websites aren’t aware of.

What’s the solution? I have no idea. Building a fence around your product isn’t the answer. Probably the best thing to do is to continue to focus on building products that solve problems for people. Products that people will pull into their lives. While at the same time being aware of who you’re competing with and who you’re sharing data with.

That should make for a good start.