Digital Fulcrum

Three Pillars of Success: People

blineweaver — Mon, 20 Feb 2012 16:01:15 +0000

We introduced the 3 Pillars of Success (People, Process and Technology) several weeks ago, to ultimately discuss each one in detail, and in my opinion, the People Pillar is the most important pillar.

With fantastic people in your organization, you can overcome just about anything. Whether it is a lack of standard/repeatable processes or poor technology, great people always find a way to overcome. Granted, lacking in the other areas and expecting your people to overcome is not ideal, but more often than not, your people do overcome for deficiencies in other areas. However, the reverse does not hold true where great technology or process will make up for unqualified people, it just doesn’t work that way.

Ad Operations is a great example of People overcoming technology or process challenges to get the job done. Just take a look at your organization. Many organizations today are using out of date technology or inefficient processes, yet your people still get the job done. The most prominent technology within Ad Ops is MS-Excel. Excel is so widely used because the processes and technology that Ad Ops personnel need are not available within their organization, thus organizations “make do” with Excel, rather than invest in the best tools and processes available to help their people.

Assuming everyone is in agreement that the People Pillar is the most important pillar of your organization; it begs the question “Are you investing in your people”? Hopefully the answer is yes, but far too often what should be a booming “yes” is more of a meek “well, we are just too busy to deal with this right now”. It’s not a conscious decision to NOT invest, but it is a lack of decision because it never seems like the right time to take proactive steps. If that is the case, then shame on you. Your people matter and when they walk out the door every evening, that is your most valuable asset heading home. It doesn’t take much to get them a refresher training course, develop basic on-boarding materials for new hires, invest in new technology to save them time (alright, sometimes new technology is expensive) or do any number of things to make their lives easier.

Does your team have the right mix of skills to be effective?
Do junior folks see a clear career ladder within ad ops?
Do senior folks feel challenged?
Are your people cross trained to be able to help one another?

All of these are questions that deserve a resounding “YES”, but far too often are ignored which is why it is critically important for organizations to proactively invest in their people. They need not be expensive or time consuming, but as the saying goes, “Tiny Hinges Swing Big Doors”, so get started in investing in your People today!

TagMan and Digital Fulcrum Join Forces to Optimize Performance of 3rd Party Tags

klefew — Thu, 09 Feb 2012 17:04:37 +0000

Integrated Solution Gives Brand Marketers Faster Page Load Times and a Superior Online Experience

NEW YORK, NY – February 9, 2012 – TagMan (www.tagman.com), the global leader in tag management, announced today an exclusive strategic partnership with Digital Fulcrum (www.digital-fulcrum.com), provider of the Ghostwriter web performance optimization technology.

Through the partnership, TagMan is further expanding its tag management functionality to deliver optimal page performance for all types of tags, combining its unique ability to support any type of tag with Digital Fulcrum’s expertise in performance management.

“By joining forces with the leader in tag management technology, we’re able to bring improved site performance to a much broader market,” said Kevin LeFew, managing partner for Digital Fulcrum. “Our solution, combined with the services and metrics that TagMan delivers, creates an incredibly valuable tool that improves user experiences, better informs decision making, and ultimately drives revenue. We are pleased to be collaborating on enhanced services for marketers and publishers alike.”

The partnership will bring even stronger performance optimization to TagMan clients for their third party marketing tags. TagMan’s flexible system already can serve tags asynchronously, which allows tags to load independently of the page content rather than blocking it. TagMan also offers a solution to accelerate the loading of blocking (synchronous) tags using its patent pending smart loading approach (see our recent Tag Loading Whitepaper). Ghostwriter extends this solution further by allowing synchronous tags to be executed asynchronously without modifying the code, which enables TagMan to be used asynchronously with any third party tag.

“We’ve seen the majority of our current vendor base tags, which exceed 250, were written before browsers started to implement HTML5 features like asynchronous JavaScript,” said Paul Cook, CEO and founder of TagMan. “We’ve worked hard to optimize the dynamic loading of these synchronous tags, and Ghostwriter provides another alternative. Integration with Ghostwriter has helped us reach our target of support for any tag within an asynchronous container, allowing companies to de-couple their tags from their website performance and something alternative Tag Management Systems simply cannot do.
“No longer will marketers need to sacrifice functionality and page performance for their third party tags,” he continued. “They’ll have access to better data, faster page loading, and the freedom to work with any vendor. We are very excited by this partnership and it is already live and integrated for several clients.”
TagMan can be found on Twitter at www.twitter.com/tagman, and also has a LinkedIn page at http://linkd.in/yYGKEV. You can read the company’s blog at http://blog.tagman.com/.

About TagMan
TagMan is the global leader in tag management, with the industry’s most mature and proven platform for the enterprise. Since launching the first, independent tag management platform in 2007, TagMan has helped over 100 customers solve tagging, site performance and attribution-related challenges. With over 250 vendor tags currently implemented, the award-winning TagMan platform provides customers like Travelocity, Virgin Atlantic, Subaru and others complete agility in managing existing partners and working with new technologies without the burden of costly implementation projects and resources. More information is available at www.tagman.com.

About Digital Fulcrum
Founded by a team of online advertising experts with years of experience in facing publisher challenges, Digital Fulcrum is dedicated to providing its clients with superior services and solutions. GhostWriter is a transformational, patent pending, Web Performance Optimization solution that allows publishers, marketers and others to optimize, inspect, manipulate and monitor like no other. Digital Fulcrum is also in a deep partnership with AdMonsters providing all services offered via Admonsters Professional Services (APS) for North America.

Contact us today to learn more about what Digital Fulcrum can do for your business. www.digital-fulcrum.com or email to: info@digital-fulcrum.com. You can find our blog at http://digital-fulcrum.com/blog/.

3 Pillars of Success: People, Process and Technology

blineweaver — Mon, 06 Feb 2012 01:56:05 +0000

For many of you, this is not new, but it is definitely true and worth repeating. For any project or organization to be successful, there must be the right balance of People, Process and Technology.

As Ad Operations professionals, you are constantly faced with doing more with less and are far too often placed into a reactive posture, when to truly drive revenue you need to be in a proactive posture. Think of it is a 3-legged stool, where all 3 legs are important and if any 1-leg is missing the stool just won’t work. Well, this is exactly the same for your organization. If you don’t have the right people, the job won’t get done. If you don’t have the right process, the job won’t get done. If you don’t have the right technology, the job won’t get done. All 3 of these legs are important and it is incumbent on you as ad operations leaders to insure all 3 legs are strong and able to support and proactively drive your organization forward.

Over the next several weeks, we’ll take each of these pillars and talk about them in greater detail, but in the meantime, I challenge each you to take a step back and think about your specific situation and answer the following questions:

- Do I have the right people to deliver today as well as in the future?

- Do I have the right processes in place to get the job done today as well as in the future?

- Do I have the right technology to execute?

- What do my people need to get their jobs done better, faster, more accurately, etc.?

- Does my technical infrastructure align to and support the needs of my organization?

- Do I have consistent and repeatable processes in place and are they as efficient as possible?

Weigh in and tell us, of People, Process and Technology, what do you feel is the most important to your organization.

Digital Fulcrum Presents at the University of Virginia

blineweaver — Tue, 08 Nov 2011 01:51:16 +0000

Just the other week, a few of us had the privilege of going to Charlottesville to talk to a class of undergraduate students at the University of Virginia. Granted, any excuse to get back to UVA is always great, but on this occasion it was an opportunity to talk about Web Analytics, Online Ad Operations, and Web Performance (specifically our GhostWriter WPO product) with a 4^th year class at the McIntire School of Commerce (undergraduate business school at UVA).

It was great to see students taking an interest in our space, and the questions they were asking were fantastic. The core of our visit was to discuss web and data analytics, but nothing was off limits and the students were really engaged and eager to better understand the ad operations ecosystem. Questions ranged from how to make sense of it all to what will it look like in 2 years and it was truly a pleasure to talk about our space and know that some of today’s brightest college students are eager to jump into the world of ad operations and related technologies. The students were quick to confirm that speed matters and a poor user experience is unacceptable from a users’ perspective, providing further confirmation that GhostWriter is a welcome solution when addressing page load times and bad ads.

To learn more about our visit to UVA, see the related McIntire blog post.

Component Level Real-User Monitoring

Will Alexander — Thu, 12 May 2011 16:18:40 +0000

GhostWriter lets you prioritize when and how you load third-party content, like ads. Your users see what they’re looking for sooner which increases engagement and improves your search engine rankings.

One of the ways it does this is by introducing a smarter replacement for the standard document.write method. Couple this intelligent proxy with GhostWriter’s hooking mechanisms and you can measure the performance of individual components from the end-user perspective and send this data to a system like Google Analytics.

The reports lets you see a list of all third-party resources.

TYPE://URL Total / Unique Views Total/Avg Time (ms)

Our post last week talked about the startOffset and loadTime events; however, we’ve now added the componentLoad and componentTimeout events to this page. Here’s an overview of what each one means:

startOffset — The time it took for the ad to start loading
loadTime — Once the ad started, how long the daisy chain of scripts took
componentLoad – Individual load times for each resource the ad referenced
componentTimeout – Resources whose load time exceed our threshold

Let’s see how we can use these event metrics to identify the performance of our ads. Unlike existing real-user monitoring services, we’ll show you how to get actionable insights out of this information.

This screenshot shows each of those metrics for the 160×600 position. Clearly we have a problem — average load time is over 18 seconds!!

Drilling down we can see the distribution of load times. In the left-most column we have a time bucket. We’ve set the middle column to show us the total number of events while the third shows the percentage contribution.

For the most part, this ad loads just fine — 88% of the time it finishes in under 1s.

So why is our average load time 18s??

Switching the top-right drop-down menu to show each bucket’s contribution to the overall Event Value makes it easy to see why — The 30s bucket contributed to 94% of the total event value!

At this point, we still have no idea what actually caused this latency. With other real-user monitoring services this is where the road ends. You know there’s some kind of intermittent issue that’s seriously affecting a small percentage of your end users, but nothing else.

Sometimes knowing something’s broken is more frustrating than not knowing at all. Was it your ad server? A third-party tag? Call to a remnant provider? Existing solutions treat third-party content as a black box. You can see how long it took to go through it, but you have no idea what happened while you were in there.

GhostWriter pries the lid off the box and let’s you finally see inside!

Drilling down into the componentLoad event, we can see the problem is due to a SCRIPT from the URL digital-fulcrum.com/gw/t/ads/ad14.js. The last column of that row shows the average load time was 31.6 seconds!! We can also see all of the URL’s that were loaded into that position and determine if any of them are contributing to the problem.

Please Note: We’ve blurred out the actual URL’s since we deliberately induced some of this latency. These numbers are not indicative of actual service levels.

Beyond just performance data, the report helps you understand the variety of sources loading on your pages. Fine-grained ad targeting or use of a remnant network masks a lot of these providers in synthetic transaction waterfall data. As we’ve mentioned, GhostWriter’s unique ability to simulate the document.write method unlocks this level of detail.

This kind of insight helps you enforce service level agreements, can help determine inventory impact when modifying your site layout, helps identify and correct problems being experienced by actual end-users and extends your monitoring coverage to every page, user and component!

Moreover, you can use your existing tools! GhostWriter isn’t limited to just Google Analytics reporting. It can send the data anywhere you want like another analytics tool like Omniture or a Network Monitoring Service like EM7, BMC or Nagios.

Your users hold you responsible for the performance and availability of the third-party content on your site! Isn’t it time you monitored that content with the same level of detail, frequency and precision you apply to your own systems?

Let us show you how GhostWriter can increase engagement, improve search engine rankings and allow you to become proactive in your relationship with third-parties. Download the sample code or submit your URL. Take complete control of your site!

Got ad performance problems? Find out!

Will Alexander — Fri, 06 May 2011 04:06:59 +0000

We saw that Google Analytics now supported Page Load Time metrics out-of-the-box and started thinking about how we might be able to use GhostWriter’s insights into third-party content (read: ads) performance to give users of both GhostWriter and Google Analytics highly granular performance measurements.
GhostWriter’s hooks allow you to execute custom call back functions at the beginning and end of each ad call. The hook records the timing of each of these events and submits custom events to Google Analytics using its _trackEvent() method. We’re using this page to test.

Ad Load Time Reports

Check out this eye candy. All Event values are in milliseconds.

Average loads times:

Distribution of ad load times

Load Time distribution for the 728×90-1 position

Ad Position Starting Times

You can also see start offset times — the difference between the start of the page and ad loading.

Average start time by position

Start time distribution for 300×250-1 position

No Ghostwriter? No problem …

If you’re willing to put in some extra work, you can collect these metrics even if you’re not a GhostWriter customer. You’ll need to add a new

WARNING: It is NOT sufficient to simply add the tracker.end() calls after your ad loading code. It must be in a separate script block.

This will let you start collecting the start offset and load time metrics for the ads on your page; however, you’ll be limited to just being able to collect this data. With GhostWriter, however, you will soon be able to get what I know you’re really after.

Analyzing The Entire Chain

Knowing start and end times for the ads on your page is great. The only problem is, you have no idea why some ads are slower. GhostWriter can fill that knowledge gap, giving you a breakdown of the URLs that contributed to an ad’s slowest. With this data, you can actually troubleshoot reports of Your ads are making the site slow using empirical evidence.
Our GhostWriter bubbles page shows a little bit of what we mean. After loading the ads, little “bubbles” appear above each one that tell you the start and end times for the entire ad. These two metrics are what we’re reporting into GA today. Expanding the bubbles, however, shows the entire daisy chain of delivery — It captures the load times for every SCRIPT, IMG, IFRAME and EMBED element along with the URL.

We’ll be reporting this level of detail shortly and let you identify which domains contribute most to latency. It’s a great way to keep an eye on your third-party content providers, many of whom have an SLA guaranteeing a certain quality of service.

We know you’re excited so we’ll get back to work!

If you’re interested in monitoring third-party content but not letting it impact the performance of your content, check out how GhostWriter puts you in complete control and check out our Free Trial

Auto Semi-Colon Insertion and Closures

Will Alexander — Wed, 26 Jan 2011 15:22:28 +0000

I was working on a Javascript library, applying what I thought was an innocuous change to remove an unnecessary closure.

The original code looked like this.
Foo= (function(){ return function($){alert($)} })() (function(){ /* ... */ })();

I re-factored to remove the first closure. Suddenly, the Foo() function was executing before any code actually ran Foo(). What’s more, the Foo() variable was no longer defined.
Foo= function($){ alert($); } (function)(){ /* .... This was untouched */ })();
If you run this simple example it becomes clear what had happened: Instead of assigning the function declaration to the Foo variable, the parentheses around the bottom closure was causing the function to run inline, passing the closure as its argument.

This is one case where automatic semi-colon insertion (ASI) failed me. Normally when you assign a function to a variable, the ending } triggers ASI; however, in this case, since the next non-whitespace character was a ( ASI was not performed and instead the function was executed. Adding a semi-colon to the first line fixed the issue.

When I first started writing Javascript something similar happened to me. At the time I remember un-doing a bunch of changes until I finally got it to work properly; however, it always bothered me that I couldn’t figure out the root cause. Now I’m convinced it was a similar issue.

I’m not sure what the exact rules are for ASI and whether or not its implemented the same in all browsers. Given this is only the second time I’ve run into it, I assume it’s rather consistent; however, the lesson I learned is this: Always terminate variable assignment with a semi-colon!

Gecko and WebKit To Iframes: “Freeze! Or you’ll reload!”

Will Alexander — Mon, 20 Dec 2010 20:31:52 +0000

iFrames aren’t evil, just misguided

I’ve always looked at iframes with a great deal of skepticism. They seem like something of an intruder, delivered from their own domain and free to embed whatever content they see fit. Browsers implement a great deal of cross-domain security to prevent your page from peeking into an iframe and vice versa, but these interlopers always seem to figure out how to work around it, even if it’s just a simple window.top.location.href=”…”; Beyond the security issue, they seem to exhibit some quirky behavior in Firefox especially, which sometimes decides to switch iframe content. I’ve seen iframes that were meant to contain ads contain raw JSON data show up in Firefox. It didn’t come as any surprise to me then when I discovered another quirky behavior. In both Gecko and WebKit, whenever you move an iframe, it will reload!

Have a look at this page, which uses a Dart tag to embed an ad that contains an AdKeeper button. Open the Net tab in Firebug before you click the button to move the iframe. You can see that appending the iframe to another element triggers the entire frame to be reloaded!

http://digital-fulcrum.com/movieiframes

When might iframes be moved?

To mitigate the impact of slow-loading third-party ads (no first-party content is ever slow, right?) a lot of sites are using a technique where the ads are placed at the bottom of the page. To accomplish this, two DIV elements are used along with two SCRIPT tags. The first DIV is where the ad would normally load and where it will eventually be placed. The second DIV is the container into which the ad actually is loaded. The first script tag loads the ad and the second script tag moves it. Here’s a simple example.

Loads and loads of Content

Okay, but so what?

Not only does this technique require considerable effort to implement, if the ad that gets written contains a third-party iframe tag, there’s a good possibility that impression will be counted twice on the third-party server. This is going to cause some significant reporting discrepencies and click-thru percentage is going to be inaccurate.

If you’re looking to prevent ads from slowing down your page, are concerned about the compatibility and performance issues inherent to friendly-iframes I would not recommend this approach. Instead, take a look at Ghostwriter, a solution that gives you the best of both worlds.

Internet Explorer’s Native Support for Script Pre-Fetching

Will Alexander — Fri, 08 Oct 2010 20:08:06 +0000

Script pre-fetching seems to be a hot topic these days. Steve Souders’ ControlJS and LABjs from Getify both provide this capability and Stoyan Stefanov recently posted a mechanism for accomplishing this in FireFox.

What is pre-fetching?

Simply put, pre-fetching scripts is used to accomplish two things which are somewhat related:

Download a script now so you can execute it at a later point in time.

Download scripts in parallel but control the order in which they execute.

Delayed Execution

For the first case, if you don’t need to run a script, you shouldn’t run it. Scripts take time, no matter how well they’re written, and if there’s no reason to run something, don’t bother. Stoyan points out an excellent use-case: Auto-completion. If you’re using JSONP to provide auto-completion data the script you attached to auto-complete “Hello” is no longer useful when the adds “World” to the search.

Current versions of FireFox (<3.5) enforces strict script execution order. This makes pre-fetching JSONP scripts an imperative. If you just blindly attached a script with the URL “/autocomplete?s=hello” and it takes 10 seconds to load, it doesn’t matter if “/autocomplete?hello+world” only takes 1: The user waits ten seconds.

Steve uses a dynamic menu as his example. There’s no reason to run an expensive menu initialization routine unless the user provides some indication they’re going to interact with it.

Managed Execution

We all know parallel downloading is a Good Thing; however, this is surprisingly difficult to achieve when it comes to loading scripts that have dependencies. If ScriptB requires ScriptA execute first, and you attach them both at the same time, there’s no guarantee that, in IE and WebKit, the scripts will execute in the necessary order. Firefox, with its FIFO execution requirement, makes this somewhat easier, but comes at a significant expense.

Pre-Fetching Implementations

All of these libraries attempt to work around these limitations using what everyone agrees are simply browser hacks. Instead of creating the script and attaching it like you would normally do, they pre-fetch the URL by creating either a non-script element such as an IMG or OBJECT, or, in the case of LABjs, a script element with an invalid type. They assign the real URL to the src attribute of this element and register for the onload event. Once this event fires, it’s assumed the script is in the cache and, when execution of this script is desired, they create an additional SCRIPT element and insert it into the DOM.

The code might look like this:

So … What’s the problem?
For the most part, these work fine; however, this code makes one significant assumption: That the URL will be cached once it’s downloaded as an Image. What happens if the script is uncacheable? Catastrophe! Best case scenario is the script is requested again and the user just experiences a delay. If,however, you’re using pre-fetching to implement dependency management (like LABjs), the execution order can no longer be managed and there’s potential your menu code will fail miserably.

There are a number of reasons the script might not be cached: Maybe it’s got a Cache-Control: no-cache header or it has no cache-control header. In the latter case, browsers employ a heuristic to determine freshness that relies on the last modified header. Even if you’ve set cache-control headers properly, IE is notoriously quirky when it comes to

The Solution (at least for Internet Explorer)
In the preFetchScript() function above, we don’t need to add the Image to the DOM for the browser to begin fetching the URL. In Internet Explorer, the same holds true for a SCRIPT tag: The URL is fetched immediately upon assignment of the src attribute.

I seem to remember pre-fetching image scripts being all the rage back in the 90′s when JavaScript first came out (I think they called it DHTML…I’m actually kind of new to the JavaScript party and, until about 3 years ago, was a sysadmin and one of those JavaScript haters. At some point, I plan to write Perl a break-up letter). So the fact that the URL gets fetched immediately shouldn’t come as any shock.

It also turns out that, while IE will fetch the URL when the src attribute is set, it won’t actually execute the script until the element is added to the DOM. This makes sense: It would be shocking to say the least if a pre-fetched image was displayed to the user before appended to the document. In this way, scripts behave the same.

It turns out native support for script pre-fetching has been in Internet Explorer and staring us in the face for over a decade: The readyState property and corresponding readystatechange event. Here’s a new pre-fetch script which takes advantage of this IE-specific behavior. This function, when run in IE, will pre-fetch a script but not execute it:

function prefetchScriptIE(url, callback){ var script= document.createElement("script"); script.onreadystatechange= function(){ if(this.readyState == "loaded"){ callback(); } } script.src= url; return script; } var menuUrl= "menuscript.js", menuScript= prefetchScriptIE(menuUrl, function(){ /* Voila!!! menuscript.js has been loaded. No matter what cache quirks were applied, we will never re-request */ document.body.appendChild(menuScript, function(){ initMenu(); }); });

It’s no wonder this hasn’t been fully explored: IE’s readystatechange event is unique (only Opera does the same) and it pisses newcomers off that there’s no onload event like everything else. Moreover, it’s not easy to know why the value for the readyState property can seemingly be either “loaded” or “complete” and still mean the same thing.

The reason for the former is, in my opinion, a flaw in the other browsers. The State Pattern is a much more appropriate model for network resources and a singular “onload” event that’s fired once is too limiting. The reason for the latter is slightly more complicated. Scripts that are in the cache will immediately transition to the “loaded” state. When a script that’s in the cache is immediately added to the DOM, IE doesn’t fire the readystatechange event when it transitions to the complete. This is confusing, but insures the event doesn’t fire consecutively.

Another advantage to this is that the pre-fetched script can be added to the DOM at any time if we detect we want to execute it as soon as it finishes. “Inferior” pre-fetching techniques require the pre-fetch finish to guarantee that, if it can be cached, it’s not re-fetched if we decide to make the script while the pre-fetching is still being done.

Unfortunately, for the other browsers, there’s no way to work around this at the moment. Newer FireFox and WebKit builds allow you to serialize execution via an async=false property. While this solves the issue for dependency management (kind of, it introduces a single queue for all synchronized execution some that, as dynamic script use continues to grow, will IMHO, prove to be its downfall), it provides no relief if you’re using pre-fetching to defer execution. Here’s an example of a synchronized execution queue for Internet Explorer:
http://digital-fulcrum.com/executionorder

In short, I find IE’s model to be more than sufficient to handle the various use-cases pre-fetching satisfies. AT a minimum, it should be the de-facto pre-fetching model for Internet Explorer. Best-case, it’s adopted by the W3C as an HTML 5 standard and lays to rest all problems with dynamic script management once and for all!