AdWonder Blog

Chaos Is Good For You: Using Random Numbers To Achieve Predictable Results

Code & files written using ActionScript 3.0

Sample files compatible with Flash CS3 or CS4

Screenshots from Flash CS4

Today’s entry isn’t going to focus on any broad concepts as much as a simple trick that can in many instances greatly reduce the amount of work required to achieve some fairly common requests.

What we are going to go over today is the use of random numbers to achieve both weighted and even rotations.

Rotations of what? I’m glad you asked.

Rotations, be they even or weighted, can be applied to just about anything in an ad:

• Videos
• Copy/Text
• Images
• Entire SWFs

Caveat Emptor: While rotation of most any elements can be handled using these functions, always discuss the best way to execute any rotated content during kick-off calls and with your EW CSS, as you want to ensure that all tracking and metrics tied to rotated content meet the specifications of the campaign at hand.

To achieve rotation with even distribution [all choices have an equal chance of being selected], all we really need to do is generate a random number, which in ActionScript will be a random decimal between 0 & 1, multiply it by the total number of choices we want to pick from and round the result either up or down, depending on if we want 1->n selection, or 0->n-1 selection.

Doing a weighted distribution is more complex and requires setting the weights for each individual selection. We will be using an array for this, and the array length will be the same as our number of choices. Each entry in the array will correspond with that choice’s percentage chance of being selected. For example, if choice 1 has a 14% weighting, the first entry in the weight array would be 14. It is extremely important that all your weights add up to exactly 100, and also that you have exactly as many array entries as you do possible choices, otherwise you will get, well, random outcomes, which ironically is not the point in using random numbers.

Once we have the weight array in place, we need a function to handle the weighted distribution based on that array, and our random number. We will use a for loop to traverse our weight array, and we will use a check variable to increment as we go through and use it to compare to our random number. What we are going to do is take the increment the check variable with each array value divided by 100 [converting it to 0->1 instead of 0->100], and see if our random number falls between the last percentage and this percentage, and if so, return what array index we are on.

So, if our first entry in the weight array is 14, our check variable will increment to 0.14, and if the random number is less than that, it will return 1, since our random numbers falls between 0 and 0.14, which it has a 14% chance of doing, as we wanted. If it is not less than 0.14, and the second entry is 20, it will then increment the check variable to 0.34, and if our random number is less than 0.34 [and obviously greater than 0.14, otherwise it would have returned already], then it will return 2…and so on and so forth. That is why it is important that your array values add up to 100 and you have the same number of values as you specified as the choices to rotate between: if it’s off, you will either overweight the first choices and underweight/eliminate the last choices, or you could not have a return at all…and neither of those outcomes would bode well for the ad.

So now that we can generate either even or weighted rotations, what can we do with it?

Well, if we have an ad that shows a video, but we actually have 5 different videos available for use, we can rotate between them to keep the ad fresh for a longer flight by making sure users don’t always see the same one.

If we have 4 different blocks of copy text and we want to rotate between them, we can do that as well, again ensuring a longer shelf life without the content getting stale.

Let’s say we have 3 entirely different ad concepts that all fall under the same umbrella/media buy. Rather than building 3 ads out and having the ads rotated through an ad server, we can build one ad that loads 1 of the 3 SWFs based on the rotation, and we can even use panel-based tracking to ensure you still get the metrics broken down per concept.

We can even take this approach a step further, and let’s say we have been rotating between 3 concepts for 2 months of a 6-month campaign, and we know that we are getting the best results from concept 2, with concept 3 getting slightly fewer results, and concept 1 is trailing pretty far behind. We can actually update the ads to use weighted rotation and go with, say, a 10/50/40 rotation to optimize the impressions to deliver more of the better performing concepts. In this example, it is imperative that you discuss this on the kick-off call and work through this with your CSS to ensure that everything is properly setup from the very beginning, and make sure the units go through another round of QA after changing to weighted rotation in order to avoid any lapses/disconnects in reporting data that may result from changing unit functionality mid-campaign.

Is this the silver bullet that will allow you to cut your work load in half, grow back your hair, or help you lose 45 pounds without leaving your desk or giving up ‘D4′ from your favorite vending machine? No. But with careful planning, and a little forethought, random numbers will allow you to provide end users with a [predictable] varied experience without exponentially increasing your workload or watering down the experience.

The End

VPAID Creatives: Getting In-stream Ads and Players to Play Nice

Haven’t we all heard “Do I look fat?” as one of the worst phrases a husband can hear coming from his wife? Even if he politely answers or refuses to say a thing, the situation can lead to a breakdown in communication and a long night of explanation. The same thing can be said about the relationship between a video player and an in-stream ad…well, at least the communication breakdown part.

While having video players of every different shape, size and functionality is great for the user and the publisher, this creates a nightmare for the ad network and rich media provider. Imagine a worker that only spoke Italian working happily in a factory with other Italian speakers. Suddenly, the worker is moved to a factory with workers only speaking German. Much like the worker, ads built for one publisher’s player only work in one given situation and have a hard time communicating with other players. This limits scalability for both the player and the creative. So what is going to make different ads and players communicate instead of awkwardly standing around like they are in a seventh grade dance?

The IAB committee, which Eyewonder serves on, is continually developing Video Player-Ad Interface Definition (VPAID) standards for in-stream advertisements. VPAID provides the necessary standardized communication between the player and ad creative. After months of defining the specifications, EyeWonder is currently working on providing the first test VPAID creatives to the IAB committee. Those creatives support traditional linear ads (pre-rolls) and non-linear ads (tickers) as well as linear interactive ads (a cross between a linear pre-roll with the interactivity of a non-linear ticker). The creatives call a standard set of methods and events defined by VPAID. The great thing is that any video player supporting the VPAID standard will be able to run EyeWonder VPAID ads.

Having this wonderful communication between the player and ad benefits everyone in the process of in-stream advertising. The publishers supporting VPAID don’t worry about needing to build “one-off” solutions to run ads because the ad is guaranteed certain functionality from the player. Agencies and networks can use the creatives over multiple sites and players. While there are still more scalability issues (such as creative sizes, programming language differences and sequencing), the VPAID creative goes a long way in creating a more scalable in-stream ad solution.

Rotating content within a single banner unit

Code & files written using ActionScript 3.0

Sample files compatible with .flash CS3 or CS4

Screenshots from AdWonder for CS4

Download the .fla files for this exercise here.

Everyone knows how ads work on a site; they are all in a rotation and if you refresh the page, you’ll get a different ad. This can be done either with equal distribution or they can be “weighted,” which is where one ad may show up 40% of the time and 6 others may show at 10% of the time each.

What happens if you want to apply the same concept within a single ad? Maybe you have a large media buy with 100% placement on a portal, but you don’t want people to see the exact same content over and over, or maybe you just have a really long flight and you’d like to keep things fresh within the one ad unit rather than having to pull ads down and put up new ones or traffic out multiple units for the site to rotate between. Whatever the reason, it can be done, it can be effectively, and it can be made to work with most any criteria you’d like.

Let’s start off by building out a simple banner ad, but make it modular to allow for easy modification for various rotation schemes.

We’ll open up one of our AdWonder Banner templates [this one is a 300x250 banner unit built out in AS3], and take a quick look at the timeline.

We’ll leave the timeline alone for the most part, but what we do want to do is delete the ew clickthru layer, as well as clear out the corresponding code in the as layer, and then we want to replace that layer with a ‘container’ layer with a blank MC named ‘container’ in it, as shown below:

What we essentially have now is a shell that we will use to control the ad content, and then all the various content [however many different possibilities we have] will be built out in separate ..flas, and loaded in at runtime into the container layer.

Next, we’re going to define the criteria for our rotation, which can be even distribution, weighted distribution, calendar based, or with the help of your AdWonder Component Specialist, you can even use cookies to do sequential sequencing, so a user who has never seen the ad before will get ‘part 1′, and a user who has seen it will get ‘part 2′.

For the sake of demonstration, we’ll pick something a bit more exciting and go with weighted distribution that is calendar aware. Next we’ll need to determine how many states we need the ad to have; we’ll pick 5 just for fun.

Now, the first thing we want to do is create all 5 of our states in separate ..FLA files. Since this is a technical tutorial, we’re not going to try and win any art class awards with it, and will just denote all our states with different text and colors. We’re going to be promoting the release of a fictitious movie: Poorly Animated Kitty Goes to the Store. So, we will have 2 states we want rotated between leading up to the release, 1 state we want shown the day of the release, and 2 states we want rotated between for the remainder of the flight following the release date. Our 5 .FLAs can be seen below: 

Now, as you may have noticed, our fictitious movie is slated for release on July 21st 2009 [nevermind that they never release movies on a Tuesday], so what we want to do is set the a to rotate the 2 ‘pre’ units until then, show the 1 ‘now’ unit on the 21st, and rotate the 2 ‘post’ units after that. Let’s also assume that we like ‘pre2′ better than ‘pre1′, and want to rotate ‘pre2′ @ 75% and ‘pre1′ @ 25%, and a similar setup with the post units, so ‘post1′ will be @ 60% & ‘post2′ will be @ 40%. So, what we need is a system that first determines which of the 3 date periods the ad is in, and then perform the weighted rotation accordingly, so our AS will look as follows [explanation a bit further down]: 

This code defines the launch date, pulls the system clock from the user at runtime to figure out ‘today’ and generates a random number between 0 & 1 to use later for rotation 

This step is optional, but it saves time in the long run, and would be much more useful if we were doing something more complicated 

This is where we use getTime [which converts a date to milliseconds for easy comparison] to compare today to the release date and determine what state we need, and then within the proper date states we use our weighted distributions to determine which state we should be loading, and finally, we use EW.loadContent to load the proper SWF into our container movieclip, which we put in the container layer earlier.

Now all that’s left is a real quick setup of the ad in the AdWonder Component by making a new ad: 

 Making it a 300×250 banner and choosing our main .FLA and a failover image: 

 Adding our assets [the 5 .FLAs for the various states]: 

And publishing our ad out to view it in all of its glory: http://apps.eyewonderlabs.com/adWdrVideoSpace/ad/66703/approvalJSTags.html

*Note - you can adjust your system clock to test the states before, on or after july 21, 2009

Where to next? Well, from here you can add in all your different content into the different state .FLAs, and you can even track in conjunction with each loadContent call in order to see how many impressions get served each state, and this also lends itself well to tracking ads by panel, but that will be another discussion for another day.

Using Cross-Domain Policy Files in EyeWonder Ads

Deceit, Treachery and Other Flash-Based Drama

A while back, I worked on an ad featuring dynamic content supplied by a third-party database. The goal was simple: load a list of stores, each store’s information and a selection of products available at each location.

When I tested the ad from within Flash, it worked fine—better than fine, in fact. The progress bar I had included showed the status of information coming from the database; all the store locations, product data and images appeared neatly in a list without so much as a hiccup. All was right with the world.

Or so I thought…

I published my files through AdWonder and waited to see the fruits of my labor brought to life on the staging server, heralding a milestone in the project and the end of my workday.

The basic ad loaded fine, but when the product list appeared, it was empty. The progress bar refused to budge, complacently sitting at 0%.

Perplexed, I tested again from within Flash. The data showed up perfectly. Perhaps I had imagined the issue—it wouldn’t be the first time.

I uploaded the ad once more. Again: no data. A knot formed in my stomach…What was I not seeing? Had I offended the Flash gods?

After a few rounds of forehead-to-desk interaction, it dawned on me that I had not discussed the issue of Flash security and cross-domain policy files with the client. After checking the third-party server, my suspicions were confirmed: no crossdomain.xml file was present, and Flash Player refused to grant access to the data my ad so desperately yearned for…

“Et tu, Flash Player?”

I sent a quick e-mail to the client, and within minutes, we had the crossdomain.xml file formatted and in place on their server.

Hoping that was the only cause of the problem, I hit the “Publish” button in AdWonder, and sat with bated breath…the tension was overwhelming as I watched the browser window open and begin loading the ad.

The progress bar, once woefully unresponsive, began to move…

“SHAZAAM!” as my co-worker John would say. A digital cornucopia of products appeared before me! All neatly displayed in the ad—names, prices, thumbnails, the whole glorious lot.

Problem solved. Much rejoicing.

What are they and how are they used?

Cross-domain files are small XML documents that reside in the root directory of a remote server and grant access to SWF files on various other domains. Flash Player uses these to determine if a SWF file at one location may access content on that particular server.

These files play an essential role in EyeWonder creatives that run on dynamic data from a remote database. Because the SWF files reside on the eyewonder.com domain, they must be granted access to the remote Website’s content via the crossdomain.xml file in order to function.

While many websites already have cross-domain files already in place, it never hurts to double-check a remote domain that you plan to interact with. The quickest way to check is by going to the root domain in a browser and adding “crossdomain.xml” to the end of the URL:

http://www.mywebsite.com/crossdomain.xml

If your ad requires access to a third-party domain, check with the tech support contact at the Website to see if they have a cross-domain policy file set up. If not, ask them to add one and to allow access from “*.eyewonder.com” and “*.eyewonderlabs.com”. This will ensure smooth sailing when it comes time to publish your ad.

The XML Code

Cross-domain files can be formatted a number of ways, but they all do pretty much the same thing. The XML markup is fairly straightforward:

<cross-domain-policy>

<site-control permitted-cross-domain-policies=”master-only”/>

<allow-access-from domain=”mywebsite.com” />

</cross-domain-policy>

In its simplest form, it allows a SWF file that reads it to access content from the domain “mywebsite.com”. The individual XML tags are described below.

1. <site-control permitted-cross-domain-policies=”master-only”/>

Tells Flash Player that this policy file is the only crossdomain.xml file that should be acknowledged and obeyed.

2. <allow-access-from domain=”mywebsite.com” />

Specifies the actual domain a SFW must be on in order to access this domain’s content.

You can add multiple access tags to give more flexibility as to who may access content on your domain, like so:

<cross-domain-policy>

<allow-access-from domain=”projects.mywebsite.com” />

<allow-access-from domain=”blog.mywebsite.com” />

<allow-access-from domain=”misc.mywebsite.com” />

</cross-domain-policy>

This means that Flash Player may read content that specifically resides on the domains “projects.mywebsite.com”, “blog.mywebsite.com”, and “misc.mywebsite.com”. It also means that Flash Player may not access data on other sub-domains of mywebsite.com. For example, a SWF file would not be able to read content from “apps.mywebsite.com”, since it is not explicitly listed in the XML file.

Alternately, you can use the “*” symbol before the “.mywebsite.com” to allow access to data on any sub-domain of a specific root. The above XML is shown below with the shorthand notation.

<cross-domain-policy>

<allow-access-from domain=”*.mywebsite.com” />

</cross-domain-policy>

This would grant Flash Player access to any sub-domain on the “mywebsite.com” root.

Further Reading

Cross-domain policy file specification

http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html

Policy file changes in Flash Player 9 and Flash Player 10

http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html

IAB VAST and VPAID

EyeWonder is closely engaged with the IAB to help define standards related to in-video advertising. We sit on the IAB’s Digital Video Committee and were present during the drafting of the “Digital Video Ad Formats and Best Practices” along with the “VAST” XML tag standard. We have expanded UIF to support VAST pre-roll and wrapper tags in the newest Framework 2.7. We are also on the Digital Video Player-Ad Interface Definition (VPAID) subcommittee, involved with drafting a new ad to player communication standard.

EyeWonder has also been certified for adherence with VAST and VPAID standards. Because VPAID is essentially just an ad to player communication layer (much like the EyeWonder UIF was), we think we can help speed up adoption by providing some of the “glue” that can be used to hold this into the video player. There is a lot of additional code that publishers would otherwise need to write to hook VPAID in.

In-Stream 2.0

EyeWonder is well known for in-page units; however, we also have a wealth of experience with in-video advertisements as well, dating years back. In 2007, we decided to push the envelope far by working on interactive in-stream. So, you may be asking why and how we approached it.

The challenge of in-stream and our solution

By 2007, a few forward-thinking publishers had already created their layer for interactive ads to communicate with the player; however, advertisers needed to build a creative differently for each publisher even in that case. Therefore, publishers were having trouble selling their inventory. That was the challenge we saw that needed to be addressed.

As a result, we began the initial development of the Universal In-Stream Framework (UIF). UIF was created to solve the problem of a lack of a standard way to communicate between interactive advertisements and the video player. To put things in context, this was before the discussion of VAST and VPAID had even begun (more on that in a future blog).

Creative

Based on research of what works and what doesn’t, we came up with a few engaging interactive in-video ad formats. There were more we experimented with, though we settled on what had the most appeal and what people were most ready for. We also developed templates to help creative agencies build creatives through the AdWonder Flash Component. At the top of the list of interactive formats are:

• Interactive linear
• Ticker
• Bug

The most exciting format to me right now is the interactive linear format because although we have linear ads, the interactive linear ads are still not too far off what people are used to, but allow full interactivity. I’ll be covering the interactive linear format in a later blog entry.

Tickers and bugs are non-linear formats that allow ads to be present during content video playback in an unobtrusive manner. If the user is interested, the user can expand the ad to do more.

New Ad Formats Announced and Google Expands Its Inventory

Recently the Online Publisher Association (OPA) http://www.online-publishers.org/newsletter.php?newsId=499&newsType=pr announced three new creative sizes to help avoid ad clutter on a publisher’s page and to help advertisers emphasize their brand prominently on the page. With these new units being featured prominently on the publisher’s pages, you can be sure your client’s brand is front and center and not lost in a clutter of different ad units.

The proposed new units will be available come July for sale through the publisher’s direct sales team. EyeWonder will be introducing templates for these new creative units in the near future, and test tags are available currently and can be provided by contacting pubgroup@eyewonder.com. The new units and their sizes are:

• The Fixed Panel (recommended dimension is 336 wide x 860 tall), which looks naturally embedded into the page layout and scrolls to the top and bottom of the page as a user scrolls
• The XXL Box (recommended dimension is 468 wide x 648 tall), which has page-turn functionality with video capability
• The Pushdown (recommended dimension is 970 wide x 418 tall), which opens to display the advertisement and then rolls up to the top of the page

These new units will allow for richer creative executions, and we will be glad to help your creative team realize the full potential of each of the new unit sizes. If you are a publisher, our publisher team will be available to help identify the best way to incorporate these new format sizes into your pages.

In other new developments, Google announced recently that they are expanding their product offering across their Google Content Network (GCN) and accept expandable creative. EyeWonder is fully certified to 3^rd party serve these units across their ad network, and the benefit provided by Google’s method is that they use a friendly iFrame to serve each of the units, which eliminates the need for each of their publishers to post an interim file. What this means to you is that you will see a higher reach and metrics due to every site having the ability to serve expandable creative correctly.