As a salty industry veteran, I've seen my share of industry firsts. From serving Flash ads for the first time at AdKnowledge to integrating Invite Media within the Google / DoubleClick stack, I've been part of some tectonic ad industry shifts. Here's how we hacked together the "piggybacking" functionality of the Atlas Universal Action Tag, allowing for explosive growth of ad networks and heralding the age of the TMS, DMP, and so many other acronyms.
In early 2005, I joined AvenueA from Atlas. Technically, I was an internal transfer as AvenueA had built and spun off the Atlas ad server--with both companies operating under the aQuantive umbrella. I became one of the in-house Atlas ad server experts, but also discovered that AvenueA was far advanced in how they used Atlas compared to other clients. An uber-flexible platform, and a team where many different people contributed to a solution--tag management was thus born.
Here's how we did it.
Media buying circa 2005 was simple compared to today--with three main avenues (pun intended) available to buyers: Search, Display Direct, and Display Ad Network buys. Ad Networks were becoming ubiquitous, with two main flavors: Performance networks and Audience networks. Both would provide a pixel for implementation on the client's site, either to measure conversions or to collect a list of cookies for retargeting users later. In turn, this bewildered advertisers who had to implement tags directly on their sites and take the agency's word for these being innocuous ad beacons. I remember how Starwood, one of our clients, had a dozen unique tags on their site--Ad.com, Tacoda, Specific Media, BlueLithium, Tribal Fusion, and so many others.
At the time, Atlas Action Tags were simple but had one feature we exploited for piggybacking. These were designed to function as IMG SRC tags but also featured an option called "External Action URL" which could be used to enter a landing page, in the event someone wanted to track conversion on click. In these rare cases, we would manually change the IMG SRC code to HREF and the Atlas tag would redirect to whatever destination was entered into the "External Action" field.
With ad network pixels, we quickly discovered we could paste a single IMG SRC pixel into the field--but what about hosting multiple pixels? Enter a wonderful (albeit slightly strange) feature of Atlas called "Direct Served Files."
Direct Served Files were used primarily in hosting components of a Rich Media creative. For example, to serve a Flash creative we would create an HTML wrapper that pulled in SWF and backup GIF from Direct Served Files. Direct Served files meant hosting only, no counting.
Here's the full workflow we hacked together in order to create the industry's first container tag, by taking advantage of "External Action URL" and of "Direct Served Files":
Step 1: Create a blank HTML document, simply with opening and closing <html> tags.
Step 2: Paste in Ad Network pixels! We quickly learned to label these with comments, and to watch for secure / non secure protocol.
Step 3: Save the HTML file with pixels, and upload the file to Direct Served Files. I remember a giddy sense of excitement when we learned that yes, Direct Served Files would accept *.HTML files.
Step 4: Take the URL of the file hosted on Direct Served Files, and implement as External Action URL in the Action Tag. Problem is, we quickly discovered that this didn't actually fire the ad network pixels when we left the Action Tag as IMG SRC.
A decade plus, even with the advent of Programmatic, the industry is still relying on pixels and tags. (hopefully for not much longer!) What was exciting about the invention of the UAT was that it was done organically, via the power users of Atlas. A few years later, TagMan, BrightTag, and several others were born as standalone tag management solutions. Tag-based DMPs were quick to follow. Yet, we were first with the Atlas UAT.
To view this article in its entirety, visit LinkedIn.