Viral Ad Network

Over the past few years, the size of websites has increased dramatically – driven partly by advertiser demand for shinier creatives, partly by a new generation of web designers who have never focused on file size, and partly by increased broadband penetration.

File size is very important.There used to be a rule of thumb that if your website didn’t load within three seconds then the user would probably leave your website – and I believe that rule still holds. For publishers, that means you are losing out on ad revenue (and visitors) by serving large file sizes.

Even if a viewer does stay on the website, a slow page can irritate the user – which can impact negatively on the brand who’s adverts are being shown.

Not only that, but many people pay for data by the Mb / Gb (especially mobile users) – sending your users larger data than they need costs them real money, and puts them off websites and advertisers.

File size is being overlooked though. If you’re from an ad agency or  a publisher, you are probably willing (and able) to pay for high-speed internet access. Website viewers, the people being advertised to, aren’t always in the same situation though.

As an example, I just opened up the website of a popular web publisher, and noticed the page (including ads) was over 8mb in size.

Here’s how long that website would take to load on a user’s computer, depending on what internet connection the user is on:

1. 8 seconds (10Mbps broadband – you’re probably on this)
2. 45 seconds (2Mbps broadband – most of your users are probably on approximately this speed)
3. 3 minutes 7 seconds (500Kbps broadband – quite a few of your users are probably on this)
4. 40 minutes (56Kbps modem – you’d be surprised how many are still on this)

Of course, people don’t just browse from their homes and offices – users browse from mobile phones and from mobile broadband.

Although mobile broadband can have very fast speeds (8Mbps), this speed goes down very fast if you’re on the move. Travelling on the train this weekend, I recorded my average broadband speed at about 120Kbps. For the page above, it takes about 20 minutes to load the page.

Here in the UK, up to 50% of users have mobile broadband – which means that 50% of viewers to this site  may be have to wait 20 minutes for a page before your ads load.

The situation gets worse in other countries. For example, in Australia the average speed is far lower. If you’re serving ads world-wide, you should be aware that they’re probably taking far longer to load in Australia than they are to users in the USA or UK.

So that’s the bad news about the industry in general, but here’s what we at the Viral Ad Network are doing about the issue:

How the Viral Ad Network reduces Ad size:

For all ads, we are able to do the following

1. We serve the majority of data through compressed protocols (See RFC 2616 – section 3.5)
2. All of our standard javascripts are made as compact as possible, using the most advanced javascript analysis tools available.
3. We only load our standard code when it’s required.
4. We split our ad serving into two parts – the part that’s the same for every ad, and the part that varies depending on which ad is being served. We tell browsers and proxies cache the former as much as possible (including across different websites), and only load the latter each time an ad is displayed.
5. Most Ethernet implementations have a MTU of approximately 1492 bytes. We endeavour to fit our initial ad code into a single TCP packet (we currently serve roughly 870 bytes of initial javascript).

In addition, for ad creatives which we have control over, we do the following:

1. For data feeds loaded from servers, we provide server-side rewriting that compacts the data as much as possible (and compresses it).
2. For images, we re-compress the images to reduce file size (Note re-compression is also a necessary precaution for security)
3. For video players we produce ourselves, we sometimes in-line any images into the swf. This reduces the number of requests that have to be made for the data.
4. We try to post-load data from the server whenever possible. This means the code required by the ad often doesn’t load until after the website and ads have loaded, and the user starts interacting with an ad.

We pushed a bunch of new features out yesterday, including:

1. More compact, faster, ads (file size for all our ads has been reduced noticeably, which should make them display faster on publisher sites)
2. Language specific targeting. Previously, users have seen ads based purely on their location. Now, ads may be targeted based on the user’s preferred language. For example, a French language ad may now be targeted at French speakers in Canada, in addition to users located in France.
3. Extra precision for targeting options – from now, certain ads may only target individual Operating Systems and devices, while this feature is in test, this may include users across 20 different operating systems.

The latest update to our dashboards brings all our publishers statistics over a greater number of date ranges.

You can now view your statistics for the past 7 days, for the past 14 days (the default), the past 30 days, or since your last payment.

As a publisher, you may sometimes wonder why your actions can take a while to show up on your dashboard.

In the interest of transparency I’ll explain how our stats systems work from a high-level, and why your payments aren’t affected by system maintenance.

When designing our ad-serving and tracking systems, our top priorities are generally:

1. Accurately recording the number of actions
2. Serving ads onto your page quickly
3. Ensuring fraudulent publishers can’t abuse our systems to take money they don’t deserve from our advertisers.

Detecting invalid actions (of which fraud is only a small minority) is not a simple task – and it can take a significant amount of computing power to analyse the volume of actions we receive.

If we attempted to categorise and analyse all actions as soon as they occurred[*] then we would struggle to serve ads (and record actions) on your websites during traffic spikes.

To avoid this (and to ensure the ad network can carry on serving during maintenance and updates), we separate our systems into (constantly running) high performance ad serving and action tracking systems (which simply record preliminary data) and systems which perform analysis of this data.

The analysis systems periodically analyse the preliminary data and use as much computing power as they have available to update our main databases. If there is not enough computing power available (or if we are in the middle of scheduled maintenance) then the analysis will wait until a later time before updating the databases.

I hope this high-level description has helped explain the delay between actions occurring and being displayed in your dashboards – and why our dashboard updates don’t affect your monthly payments.

Tim Wintle

[*] – it’s worth noting it would technically be impossible to fully analyse actions immediately – some analysis can only be done in bulk, after your actions are recorded.

I’ve just put the finishing touches to a new tutorial for advertisers

making a basic flash video ad in actionscript 3.

This tutorial includes:

1. Calling the Viral Ad Network’s tracking from actionscript
2. Embedding an image inside flash
3. Inserting a basic video into flash

At the beginning of the year I posted a link to Mashable, reporting that Twitter’s traffic was failing to increase, and had for several months.

Wondering if this was still the case, I ran my own analysis – not of the traffic to Twitter (which only Twitter themselves can measure accurately), but of the number of user accounts on Twitter – over the two year period from 29th May ‘08 – 29th May ‘10

Interestingly, I saw the same slump in new signups that Mashable had spotted on Quantcast’s traffic stats – from July ‘09 – Feb ‘10.

Even more interestingly, I found that new users suddenly jumped from Feb 2010, and have been increasing ever since!

So what’s going on here?

When we first saw traffic going down, many of us suspected that Twitter may have been approaching market saturation (the point where all people who wanted to tweet already had accounts). This suspicion seems to have been wrong.

My suspicion now is that we’re seeing the effects of two loosely-coupled markets – one, smaller, market approaching saturation; another (larger) market where Twitter is beginning to take off.

I know we have some readers who know far more about such models than I do – I’d be really interested in hearing if anyone has a good model that could explain this behaviour.

And, for completeness, here’s a chart of how the total number of users on Twitter has changed over the past two years (note this includes inactive and banned accounts).

Many people believe that the best way to spread your viral to niche interest groups in to manually target users within the niche themselves. But is this the best way to truly spread your [viral] content?

It’s a very controversial suggestion, as it goes against the perceived wisdom – but it’s not a new suggestion.

The concept was very heavily covered a few years ago in the business press (e.g. D.Watts – Harvard Business Review ‘07), although it’s been known of for far longer.

There are a couple of simplified examples in the video below:

So why do these examples work?

A social grouping consists of people who are connected to each other – assuming that your viral really appeals to that group, the task at hand isn’t being spread inside a social grouping – it’s reaching as many social groupings as possible.

You can only reach one social grouping by contacting someone inside it (if they are connected to another grouping then it’s all one grouping) – by elimination, the only option left is to target people outside of that grouping.

The great news here is that it’s cheaper to target those people – you don’t need the overhead of all the time spent searching for “the perfect seed”, you just show your viral to people.

Not only is it cheaper per viewer, but it’s almost always the case that there are more people closely connected to the grouping than there are inside it – so you’ve got a larger target to aim for with your seeding efforts.

Of course you can narrow down who you’re contacting – people are more likely to be connected to the target market if they’re in the same country, or speak the same language for example.

Other targeting methods can be used to help narrow down the target to people close to these groupings too – targeting broad categories of interests can be a very cost effective way of targeting this wider subset of people, rather than hand-picking site lists, which puts you firmly back towards only reaching the groupings around the sites you’re placed on.

That’s just about the scope of this blog post – hopefully you’ve found it interesting, feel free to comment below.

Everybody likes to think their viral creatives are going to go viral without any kind of push – but here’s the bottom line:

Summary:

How much would you enjoy reporting to your client to tell them their average cost per view was £20? (even if you don’t phrase it like that, they will be calculating it).

Including a bought spend reduces their (and your) risk – in very worst case above you’d be entering that meeting reporting an average cost per view of around 1/40th of that price – that’s 40 times more ROI for them, and a more economically viable campaign.

What’s missing from the above?

Quite a bit – for a start, the more that your content is seen, the more likely it is to get organic views – so a bought media buy makes it far less likely that you’ll be hitting anywhere close to the worst case. For simplicity I’ve left this at the most basic calculation I could.

(Disclaimer: these numbers are estimated and may not necessarily reflect real-life results, which will depend on individual campaigns)

If you are an advertiser you will probably have noticed that we completely re-built our campaign dashboards as part of our most recent updates.

As part of this push, we wanted an efficient way to insert basic Bullet charts into the dashboards.

These are simple charts to show how far a value has progressed towards it’s target as such [*]:

It sounds like a simple requirement, but there were many potential ways to generate them, and our dashboards have to be highly optimised to display quickly.

Implementation:

Here are the options I considered but ruled out:

• svg … but Internet Explorer doesn’t have support for svg.
• canvas (i.e. painting it client-side in javascript) … but Internet Explorer doesn’t have support for the canvas element.
• generate image server-side … requires an extra http request per chart, and delays load time.

This left me with two remaining options

• css / javascript / DOM manipulation …
• creating a flash / as3 movie …

I implemented both methods, but it very quickly became apparent that the javascript/css method was going to have more cross-browser issues than it was worth and be painful to test for bugs. We already require flash support on most dashboards, so I made a small flash movie.

Download (AS3 source, Binary .swf and example page):

BulletChart.swf comes in at around 1,300 bytes and should be cached by the user’s browser for further use – inserting the flashvars server-side allows you to cut down on http requests and compresses well if you have many charts on a page. It’s been thoroughly tested on Flash Player 10 and works on most versions of flash player 9.

viraladnetwork-bulletchart-1.0.tar.gz

License:

Our bulletchart is licensed under a BSD license, which allows you to use and modify it for commercial and non-commercial uses.

To Use:

Copy the .swf to your site and embed it as normal – you can use the following flashvars to configure the chart:

bartarget, barvalue, leftcolor, rightcolor, barcolor, targetcolor

To Compile from source (Linux/OSX/BSD):

Compilation requires the flex mxmlc compiler (which requires java). I believe this is the compiler used by flex builder etc, but windows users will have to play around.

It does not require the flash IDE.

# extract the archive
tar -xf viraladnetwork-bulletchart-1.0.tar.gz
# enter the new directory
cd bulletchart
# Modify the path to your flex compiler in the makefile
nano Makefile
# build the .swf
make

I hope people find this code useful while we’re waiting for the Internet Explorer team to release SVG support (SVG is expected in IE9 ).

Tim

[*] Most bullet charts show scale markers to display the current value on the chart itself, however we kept ours as clean as possible, and to leave the text in HTML for accessibility.