Viral Ad Network

I just got sent an interesting request from a friend of mine – he’s applying for a job and as part of the application process he’s been asked to film a job interview talking about the company, put it on YouTube, and drive traffic to it to see who can get the most views.

The result is that thousands of people will be getting emails from friends asking them to watch a video of one of their  friends recommending the company (great way to mix viral marketing and word of mouth!)

You can seem my friend Alex telling the worst joke ever here. (it’s worth it – it’s about dwarfs)

As those of you hosting syndicated Fun Units will know, your units now have their very own geo-targeting mechanism implemented to ensure that our content is shown to the right audience, and to display relevant fun stuff to the visitors of your site.

We realised that this was never announced as loudly as it should have been. Hopefully this should clarify things in enough detail and act as a reference point for you guys until it’s articulated better on the main site:

Geo-targeting allows us to continue to pay you for every view that comes to your site and clicks on our viral content. For example, if somebody from an Italian IP address visits your page, your Fun Unit will automatically display the most relevant content that we are serving for Italian users.

Many advertisers only want to pay for viewers from specific countries. By showing different ads to different users, we are able show each user the ads that will pay you the most. If we have nothing targeted at that specific country, we will show the next highest ad that is available world-wide. This ensures that you receive a payment for every click delivered through your Fun Unit, that the amount you get paid is optimised, and that your inventory isn’t going to waste.

Ker-ching!

Our main targets, based on advertiser trends from the last few months, are the UK, France, Italy, Germany and Spain. This is where we are highly likely to be serving ads at any time, so publishers with significant traffic in any of these territories will currently benefit the most from hosting a Fun Unit. But rest assured, we’re constantly looking to expand these territories and provide those of you with valuable traffic elsewhere with a unit of your own soon!

We will also continue to offer managed placements as they come in for a set time periods and targets – and for a specified price for each territory. The same principles as above will apply, but the content isn’t syndicated and rotated.

Alternatively, if you have an Ad Unit on your site, we often specifically target certain campaigns directly into units. These placements will only be shown to users when our system feels that your site will earn more by showing this site-targetted ad than by showing one that is showing across the rest of the network.

We hope this is clear. Email us at publishers@viraladnetwork.net if you need any more specific details. Also, feel free to post any feedback to us that you may have, we always want to know what we can do better, and look into giving you the things that are going to make your life easier.

Cheers,

The Viral Ad Network team.

As many people in industries such as ours will have noticed – YouTube is being slow at updating the view count for some videos at the moment. Luckily we have our own numbers to go by, so it’s not affecting us as much as it is affecting many companies, but I thought I’d put my explanation up here so we can refer people to it.

According to youtube, this seems to be due to an algorithm change made on the 25th of February. (they have made similar comments elsewhere)

Quote:

We’ve made a change in our public-facing view counts across the site
that will enable us to consistently reflect what is considered a
‘view,’ based upon video consumption, video streaming and spam
filtering. This only affects view counts from February 25 moving
forward.Implementing this change also caused view count updates to slow down a
bit in general; many people have noticed this and we’re aware of the
issue.

This raises some very interesting points (these are my observations, have not been confirmed with Google and may not reflect the opinions of Team Rubber):

First, for people who don’t deal with software like this every day (like I do for the viral ad network), I’ll explain the common way that numbers like this are updated:

• There are one or more “tracking servers”, running all over the place – these are the servers that actually record a “view”, “hit”, or “action” – and they simply record lots of information about each action, which will be looked over later.
• Every few minutes the main algorithm runs over all the data it hasn’t looked at yet and updates the numbers that are shown on the dashboards.

The important thing to notice is that the views are recorded right at the beginning and they will be updated at some point. Even if the main algorithm is stopped entirely for a few days, it will carry on in the future if you’re patient.

Prioritizing videos (”Why does this only happen once I reach 200/300 views?”)

You may have noticed that the number of views per video has always been updated quicker for videos with few views than for videos with more views. For example, a newly uploaded video will normally update it’s view count within a few minutes of a video being watched, where a video that has already had several thousand views will update it’s view count more slowly.

This suggests that when Google run their main script, they tend to update the numbers for videos with less views more often than for videos with a higher number of views – and leave the other data to be processed less often (say every few hours)

This makes a lot of sense, because people with 50 views are more likely to be watching their numbers every few minutes to see if they have another 5 views than people who have had 200,000 views – who may only care about their views increasing by 1,000. It keeps users happier.

This explains why we (and others affected by this issue) have seen view counts rising as normal until they get above 200-300 views – at which point the numbers appear “stuck”.

Balancing the work (”Why doesn’t this affect all videos?”)

Clearly a massive site like YouTube getting so many views need more than one computer running to update these numbers. I’m going to assume that Google run this over their normal map-reduce system.

They may tens, hundreds, or even thousands of computers running their view-counting algorithm (and I don’t expect to ever find out…), but all views for a video have to be counted by the same computer, so they need some manner of splitting up the millions of views they have recorded into batches of work to be done.

They almost certainly do this using some form of hash function – you can picture this as saying that every video on YouTube is grouped into various buckets – each of these buckets will have it’s views processed on the same machine (or at the same time).

The problem comes when a hash function doesn’t split up the items equally (i.e. one “bucket” has significantly more/less videos in it than another one). This appears to be the problem here – only some videos have been affected, and my assumption is that this is because one of these “buckets” has ended up with far more views than the others – meaning that one set of machines (or one job) gets over-loaded and ends up being incredibly slow.

Lessons Learned

For me, working with a similar system to the above, the number one thing that I have learned is that for tasks like this that might be incredibly sensitive to hash functions it’s not safe to assume that a hash function that’s theoretically good is going to remain good.

I don’t know if they are able to,  but the situation would be better if YouTube chose the hash function at the beginning of each main job. I.e. each time that they run the main script that updates the information on the dashboards, they chose to use a different hash function. This way, if a video ends up in a bucket that’s overloaded one time, it will end up in a different bucket next time (which shouldn’t be overloaded).

Of course, this is all theoretical, and is based on a large number of assumptions – YouTube may perform their hashing at a far earlier stage, and they may not be able to change the hash function each time they run the job.

Tim Wintle