We Love the Mess of Ad Tech and Wouldn’t Want it Any Other Way
My introduction to ad tech (roughly): “Ad networks are a mess, you wouldn’t believe what a technical mess the industry is”.
That was in my first meeting with David Cancel (then at Lookery, who since founded Performable, acquired by Hubspot) as I was bouncing an idea off of him that touched on the edges of the ad tech space.
Fast forward 6 months from then (almost exactly two years ago), I got a Twitter DM from David: “Friend is starting a new startup in the ad space. Looking for a CTO and/or help. Any interest?”
About a month later I was the CTO of Yieldbot.
Two years on I can say he was definitely right, ad tech is a mess. Part of it is how it’s evolved and part of it is structural and baked into its nature.
I’ll step it up and say this: ad serving may be the most complex distributed application there is.
The proof is in explaining why.
You Control Almost Nothing
There are so many degrees of freedom it can make your head spin.
You basically have a micro-application running embedded in a variety of site architectures each with their own particular constraints, whose users are distributed around the world running all manner of execution environments (browsers).
If you are creating a destination site, that keeps your team’s hands full. If you’re serving ads, that’s just a warmup. Because you also don’t control the site architecture that you are embedded in.
You might need to sit behind any number of ad servers the publisher might be running everything through.
You might be in iframes on the page.
You might need to execute code in specific places relative to other ad serving technology also embedded on the page.
Navigation through the site may or may not involve full page refreshes.
But that’s not all…
Distributed Worldwide with Time Constraints
Remember those environments you don’t control? They are the customers’ websites, and they don’t want their users’ UX degraded.
Serve ads, optimize it for relevance, and don’t slow down page load times.
Most websites have some level of focused geographic distribution to their users. Even if it’s as broad as US or even US+Europe.
But for ad serving, your user base is the set of users aggregated across all of the sites using your service. The world is your oyster. And the footprint of what you need to service. Quickly.
But wait! There’s more!
Content Relevant To The User At That Moment
At least if you want to be as cool as Yieldbot.
Look, a CDN serving up a static image can satisfy all of the above if all you want to do is serve the same image to every user across all of your customers’ websites.
Scattershot low value ads picked fairly at random would approximate that level of ease as well.
But there’s no sport (or value) in that!
Our goal here is actually to serve content that is the most relevant to what the user is doing at that particular moment. When done right (we do), everyone wins.
So - simply serve the content that best fits what the user is doing at that moment, where they came from, and what they’ve expressed interest in *right now*, on whatever they happen to be running on, and wherever they happen to be. And make it snappy, would ya?
We Wouldn’t Want It Any Other Way
So, that’s what I signed up for - and I love it. And so does the rest of the Yieldbot team.
We started our first intent-based ad serving on a live site a couple months after coding started and started learning real world lessons immediately. And 20 months later it’s still going.
I’ve always loved to work on systems with complex dynamics, so considering all of the above it’s not that surprising I ended up finding my way to ad tech.
What I love about building Yieldbot technology? All of the above is only half the story. We also do Big Data(tm) analytics for our system to learn the intent of the users coming to our publishers’ sites. We provide them visualizations and data views that teaches them what the intent to their site is. And *then* we enable them to serve ads that make that intent actionable.