HTML and CSS Reference
In-Depth Information
window.addEventListener('online', checkOfflineStorage);
window.addEventListener('offline', checkOfflineStorage);
document.addEventListener('DOMContentLoaded', AdInit, false);
</script>
Let's review the code example. Again, it's very similar in setup as the click tracking example, but now once you're
inside the adInit function, you set up your touch event listeners for the ad environment and also an event listener
for the online/offline state by calling window.addEventListener("online", checkOfflineStorage, false); . Next
you call the checkOfflineStorage function to determine whether there has been any stored offline activities. Inside
checkOfflineStorage , you initially check whether the user has a network connection and whether there are items
stored in the localStorage object. If there's network but no storage, you simply log to the console by writing console.
log('No offline metrics stored') . However, if there are items that are stored in localStorage , you loop through
them all by grabbing their key/value and passing them to a function called fire . Now, inside of the fire function,
you check to see whether you need to clear the storage after you fire off the tracking calls, by writing if (clear ===
true) . Now, you'll create image objects and add the URL request to the tracking server by setting that value to the
Image 's source attribute. Lastly, once you've fired off all the calls, you set a timeout to call the function clearStorage ,
which will clear the user's browser of all localStorage tracking calls. Now there is a lot going on in the code, so I
suggest following along in your favorite text editor and checking all the logs in your favorite browser's web inspector.
Keep in mind that this technique is becoming increasingly important for digital magazines and publications where
everything gets cached to a user's device. Using HTML5's offline detection through JavaScript, you can handle metrics
accordingly; in addition to the previous XMLHTTPRequest method, you can ensure the user is truly connected or not.
For mobile folks working with SDK vendors such as AdMarvel or Medialets, there's a good chance they can
provide the caching of offline metrics for you. As an ad designer, you'll most likely just need to call specific SDK
methods, and the SDK will handle that for you. In addition to that, the MRAID working group has tossed around the
idea of including a standard way for implementing offline tracking, but the reality is that the space is too young to be
standardized just yet. Just take a look at the quote from the MRAID API documentation:
Rich Media Ads that can work while the device is without network connectivity need the ability
to store and later forward metrics about how and when users interact with the ad. MRAID has
the potential to provide common APIs to facilitate storing and forwarding of ad impression
delivery, view, and other metrics from the SDK back to the ad server. However, until measurement
methodologies and the metrics themselves are standardized (for example by the ongoing IAB/MMA/
MRC In-App Ad Measurement Guidelines project), adding measurement functionality to MRAID
would be premature. The MRAID working group expects that this capability will be evaluated and
potentially added to MRAID as part of a future version 3.0 release.
MRAID Working Group
MRAID's working group has a good approach, and I think it's often better to see all the proposed solutions before
setting a single solution in stone and calling it a standard. Will it be HTML5 and the various JavaScript APIs that allow
for standardized offline tracking? Or will it be something else with SDK involvement only? Perhaps a mixture of both?
In the meantime, clients will ask you for this, and it will eventually become a standard operating procedure in the
online advertising space. For now, you'll have to come up with your own homebrewed solutions like the one outlined
previous, or you can even look to lightweight JavaScript libraries such as Lawnchair ( http://brian.io/lawnchair ) for
what you need.
Lawnchair is seemingly a possible answer to client database storage because it uses a simple name/value pair
assignment through JavaScript and retrieves values through JSON. It also can be equipped with many adapters
to fail gracefully to other client-side storage technologies if some browsers don't accept others. This means it will
use blackberry-persistent-store , DOM storage, WebSQL, and IndexDB, to name a few. Lawnchair eases the
fragmentation between the storage technologies as well as gives developers an easy approach for saving values. Plus,
 
Search WWH ::




Custom Search