Banner Ad: Please Fix Your Pacing Algorithm
Decorative Header Image

The Privacy Pendulum

Last October Yieldmo hosted a client summit in Park City, Utah. I was fortunate enough to kick off the first day with a trip down memory lane… privacy memory lane. Often I find myself acting as Internet historian since I’ve been enamored with the thing since the late 80s, logging on to the local BBS and playing Trade Wars 2002 late into the night.

Foucault’s Pendulum, credit: sylvar

At the summit I traced back online advertising’s rise to the creation of the humble cookie in 1994. It was a seminal moment for the web as it allowed a browser to maintain state between web pages. I rambled on through a series of events, highlighting each milestone’s impact on advertising as well as noting the privacy implications. As the years went by, society at large took notice of the wealth of information being distributed across the globe and eventually cried out loud enough to force governments and large companies to address their concerns.

I documented swings between discrete tracking and privacy safeguards in a post on The Drum called The Privacy Pendulum. I’m finally posting the unabridged text here, enjoy.

The Humble Cookie

The year was 1994. I was a student at the Illinois Institute of Technology and had switched majors to Computer Science. The Internet, with a capital I, had me in its grasp. I was enamored with all things web. Looking back I think I must have been easily impressed, because gray backgrounds with blue and black text don’t seem all that impressive today. The promise of the web was readily apparent, though. It just needed a few more features to really take off.

1994 was also the year Lou Montulli, a Netscape engineer, invented the cookie. He wasn’t trying to open the door to an industry to revolve around audience tracking and targeting. He just wanted a shopping cart to work properly on the web.

Read more

Non-addressable is a “today” problem

Hero image for BlockThrough Podcast about non-addressable audiences

I sat down (virtually) with Neera Shanker from Blockthrough in December. We discussed a few market trends like non-addressable audiences, privacy regulation and the platform giants (Apple and Google).

In this episode, I actually know wtf I’m talking about. It’s only my second attempt at guesting on a podcast. And the first time I really had the appropriate expertise on a subject.

Here I’m talking about ad-tech and how non-addressable audiences (no cookie IDs and such) are an important area of focus. Many online publishers are not giving this topic enough attention. If that kinda thing is interesting to you, or you just like hearing the sound of my voice, give it a listen.

Tune in to learn about how I got started in ad tech waaaaaay back in 1997. The internet was a different place back then. It’s striking to remember how a small operation could have a large impact.

Then you’ll hear about my work at Yieldmo, my day job. Hint: I really like my job. In my best radio voice I talk about my typical day, challenges I’m helping to overcome, and how we measure success.

Finally, I evangelize the need for non-addressable solutions in the market. It’s a big issue that will require investment (time and money) in order to future-proof the industry.

If you’d like to grab the podcast in your favorite app, jump over to buzzsprout for the links.

Real-Time Bidding: The Stack Class Video

You may have heard of this being referred to as Stack Class. These white-board sessions originated in the early days of Real-Time Bidding (RTB), before the dark times… before The Empire, er.. Header Bidding. Before Header Bidding.

This video is a little dated, but it covers the technical basics of RTB. I’ve been toting it around for years privately. I figured it’s about time to set it free.

I called it Stack Class in the beginning because I was describing all the components of Real-Time Bidding, you know… the stack upon which everything is built. In this video you’ll find SSPs, DSPs, user synchronization (cookies?!%$#@!), bids, responses, PMPs, ad markup… you know, all the things.

Is it Fraud? Illustrating some marginal to bad practices in ad-tech

A couple weeks ago I was looking over geographic location data to inform the return on investment of an advertising campaign. A significant portion of metropolitan data was showing a large percentage of the users sitting in the exact same location. It was as if they all checked-in on their apps while they were standing at the center of the city. That seemed unlikely. Was there something wrong with the data? Well, yes and no. More importantly: was it fraud?

Was it fraud? Welcome to the gray area of ad-tech. eMarketer shows that display advertising fraud loss is hovering around $6 billion worldwide. They likely derived this data from very black and white definitions of what is and what isn’t fraud. In this post I’ll be lining up not only explicitly fraudulent behavior, but also some marginal tactics of media owners, supply side companies, advertisers and demand side companies to illuminate the fringes of acceptable behavior.

Read on for geo stuffing, bid caching and more…

Pacing Algorithm for Advertising Campaigns and Inventory Allocations

I was trying to figure out what to do with my Sunday. My options were: build a little header bidding ad server plugin for WordPress; run, sleep and eat; or write up some blog post on a pacing algorithm, because people still seem to be producing crappy ones. Since you’re reading this, you can probably guess which choice I made. I mean, it’s not the first post I’ve written on the subject.

It showed up again last week. I didn’t expect it, but I guess I never do. A saw-tooth pattern on a chart, indicative of a capping of sorts. A chart that says, “I want a thing to happen, but only so much.” In this case it was a traffic allocation. This was a surprise.

A little (bad pacing algorithm) history

Most of the time when I run into a bad pacing algorithm it’s in the form of a campaign trying to limit itself. It only needs to acquire a few thousand impressions every five minutes, for example. So the hastily written algorithm might divvy up the impression allocation into five minutes buckets. Effectively that’s 12 buckets every hour. So it takes an hour’s worth of impression needs and divides it by twelve. One twelfth of the impressions are purchased every five minutes. Unfortunately at that point it switches to a simple counter that says, “for the next five minutes buy impressions until the number purchased reaches 1/12th of what I need in this hour.”

You end up with a purchase graph that looks like this.
Sawtooth Pattern exposes a bad pacing algorithm

See that blue spiky thing? That’s the one that’ll get ya. Read on to find out how this impacts the industry and how to fix it