Recently the New York Times had an article about fake items being sold on eBay and how eBay is handling these problems, which was very interesting, and especially of interest to us, as we increasingly focus on how to regulate our marketplace. We are often compared to eBay, as we both have online marketplaces – essentially facilitating transactions between buyers and sellers.  However, the article also includes some important features about eBay that help to highlight differences between Right Media and eBay.  

In the article, eBay maintains that it has expertise only about the marketplace, “‘We never take possession of the goods sold through eBay, and we don’t have any expertise,’ said Hani Durzy, an eBay spokesman. ‘We’re not clothing experts. We’re not car experts, and we’re not jewelry experts. We’re experts at building a marketplace and bringing buyers and sellers together.’”*  Right Media, on the other hand, is responsible for the creatives, the goods that are at the center of the transactions in the marketplace, and we are experts in our marketplace content - online advertising. 

To better understand Right Media’s focus on regulating our marketplace, as opposed to the more laissez-faire attitude of eBay, it is important to underline another difference in how the two marketplace technologies handle the transactions.  eBay facilitates the transaction between buyer and seller, but is not involved with the item in a transaction - they do not decide what items a buyer bids on, what amount buyers bid, or transfer the item between the two parties. 

Yield Manager, however, is directly involved in each transaction between an advertiser and a publisher, acting as a proxy for the two parties in every transaction - determining the price bid by an advertiser, which bids a publisher should consider (for example a publisher who sets their profile to not accept creatives with adult content, would not see bids from those creatives), and serves the creative to a site.  The advertisers and publishers do not personally select which individual creatives will be shown to the impression or where that impression will occur. 

Because of our level of involvement in marketplace transactions, we realize that it is incumbent upon us to make sure that all of the creatives and the publisher sites are properly classified, in order to protect our clients’ interests.  Currently, much of this classification has been self-reported by publishers and advertisers, with an additional check by Right Media for certain types of creatives and content, and until recently this has worked well.  However, as we have an increasing number of users and transactions, there have unfortunately been more incorrect or dishonest self-reported content descriptions - essentially the same as the fraud on eBay.  We are well aware that we need to tackle these issues and are applying our industry expertise to formulate the best way to protect everyone’s interests in the Yield Manager Marketplace.

* Katie Hafner, “Seeing Fakes, Angry Traders Confront EBay,” New York Times, January 29, 2006, http://www.nytimes.com

Some of you may have wondered how the wonderful software that powers Yield Manager is created. A lot of people imagine that the people who do the tech work at RightMedia are geeks who wear pocket protectors and sit in front of terminals in dark rooms. Well, that’s mostly true (I have a very stylish pocket protector by the way). But we’re people too. We struggle with problems, make mistakes and then try to blame them on the new guy just like you do. I’m going to try to walk you through the process of solving a problem and implementing a solution.

The Problem: Finding Out Who Dunnit

A lot of clients had been asking for a way to view who had made what changes to a given line item, and for some information about what those changes were. Ed Kozek (director of UI development) tasked me to implement a solution. We saw two potential ways to solve the problem:

1) Store a message in the system anytime that someone made a change involving line item and display it to users
2) Parse the records in the database to try and find changes involving a line item and information about the change

Yield Manager is a very complex application. There are hundreds of different files and thousands of places within those files where someone could make a change. So instead of spending time going through all of these files and trying to add messages, we decided to parse the database logs so that we could better spend that time drinking coffee and playing video games online. (Note to Ed: that was a joke.). Seriously, we decided that our resources would be better spent working on the many features that have a more direct impact on providing business value to our clients. So I was left with what seemed like a relatively straight-forward task. We already log every query that gets run on the database. All I had to do was turn that record into something “human readable”. Simple right?

The Plan: “It All Seemed So Simple Then”

In our database we store the actual SQL queries used to make changes, like these…

DELETE FROM offer_type_table WHERE id=’2918′
INSERT INTO offer_type_table (id, offer_type_id) VALUES (2918, 1)
INSERT INTO offer_type_table (id, offer_type_id) VALUES (2918, 29)
INSERT INTO offer_type_table (id, offer_type_id) VALUES (2918, 33)

…and I have to turn them into (somewhat) friendly text like…

“Joel Hoard modified offer type targeting - Set to exclude: Adult, Mixed/unknown, Casino/Gambling”

Not fun, but I’m a developer right? I mean, this is what we do. I’m going to try to spare you the boring technical details and stick to the boring process details. Our initial plan seemed to be holding up…take the query statements and turn them into text. I spent about four hours getting to that point and went to check how things were coming along. I managed to turn the four statements above into:

Joel Hoard removed offer_type_table targeting.
Joel Hoard modified offer_type_table targeting - Adult
Joel Hoard modified offer_type_table targeting - Mixed/unknown
Joel Hoard modified offer_type_table targeting - Casino/Gambling

So far, not so good.

This was still far off from my goal of: “Joel Hoard modified offer type targeting - Set to exclude: Adult, Mixed/unknown, Casino/Gambling”

After I had played around with it, I realized that the statements in the database didn’t have a one-to-one relationship with the actual changes made by users. I also had to deal with turning table names into names of things that people could recognize. And I had to figure out if people were including or excluding. My simple task had become something of a bigger problem, and all of our SmartPeople(tm) were using their brain power to decipher the mysteries of other, more mission critical tasks. So I had to go back to the drawing board a bit.

The Issues: “Houston, we have a problem.”

I’m glancing over the intricacies of turning a SQL INSERT statement into text of any kind…it was not easy. It’s not the kind of thing that’s covered in college textbunqiue

unqiueunqiueooks or certification courses. I also skipped over the details of gathering and organizing all of the data and all the different database tables I used to look up information.

I did this for two reasons. First, to spare you the “boring details” (though I’m sure this article is boring enough already). And secondly and most important, because the obscure technical references and jargon that we use are our primary means of keeping our jobs. If I explained the details of solving these technical problems, then you would understand that there is no “Magic” in computer programming…just a careful application of logical rules and experience. We programmers like to utilize what we call “Shock & Awe” to make something that is actually relatively straight forward seem confusing and magical. Then you don’t question us when we say that something simple will take a week. (Heh. Just kidding, Ed.)

So I came up with a system to try and match up the groups of database commands by the table they dealt with and the time that the change occured. This is not an exact science. In fact it’s not science at all. It’s more like a sleight-of-hand show. The whole thing is what we call a “hack”: a solution put in place because we don’t have the resources available to do it the “proper” way.

I can turn “offer_type_table” and “frequency_table” into “offer type” and “frequency” by removing “_table”. I can do a decent job of grouping changes together (with 98% or so accuracy) and I can look up the include/exclude information based on the names of the tables involved. But the problems arise when the table involved isn’t “frequency_table” but “frequency_target_table” or “table_frequencies”. Or when the include/exclude information is stored in table A for one type of change and table B for another type of change. Since there are no hard rules to work with, all I could do was work with general rules and add solutions for unique situations as I see them. And for every one unique problem I fix, someone submits a bug report with two new ones. I was trying to be careful to not show INACCURATE information, which can do more harm than no information at all, while still trying to provide a workable solution.

The (Partial) Solution: “Run away! Run away!”

After about a week of this, Ed put an end to the madness. We had a solution that does a decent job of showing history. At least there are dates and names, though the text may not provide any value. This was, pretty much, what people were asking for. If it came down to it, we can always look up the database commands and figure out exactly what happened for serious issues (which we have done). While I would have liked to have worked on the problem until I came up with an ideal solution, my time was demanded on other projects and we had something that met the basic needs of the customers.

In the future we’ll hopefully get to revisit this project and use more accurate methods of logging line item activity. I would personally like to see it at the point where you can view exactly who added/remove/set/included/excluded what on a
given line item. We have a lot of issues that are higher priority right now, but the framework is in place to re-visit and complete this project.

So what did we learn here?

1. Developers are people too. We make mistakes and get overwhelmed just like anyone else. Patience from all parties involved is appreciated.
2. A lot of times there are no guidelines. These are real world problems that no class or textbook can prepare you for. More often than not it’s a few dozen of us trying to keep up with the demands and innovation of thousands of users.
3. Joel has a snazzy pocket protector.
4. Do not mess with the boss. They are not known for playing around. A few wise cracks in a blog entry will get you a lot of extra projects.

I hope this gave everyone some insight into how features are developed at RightMedia.

PS - As I was writing this, I discovered that the line item history barely works at all. At some point we changed something in the database and most of the functionality died. The funny thing is that no one noticed or said anything for at least two months. I guess the plus side of getting put on the low priority projects is that no one notices when you screw up.

In an article entitled “eBay Pitches eBiz, Big Advertisers Consider Online Media Auction Service,” Joe Mandese discusses the history of attempts to create auction exchanges for media, and a presentation given recently by eBay on the topic.

Since we’re not exactly publicity hounds, no one can blame Joe for not touching on the fact that we’ve built exactly what the article describes—the first and only active exchange marketplace for advertising—the Yield Manager Marketplace.

Those who know us know that we’ve been talking about this concept, and building an exchange marketplace, for the last 2 years. An article like this makes me wonder if we’re not a little too conservative when it comes to communications. The fact of the matter is that we’re operating an exchange for online media through which over 35 billion impressions will be bought and sold this month—people should know about it! Still, I’m glad that the topic is finally getting more attention.

The fact that this is being talked about is good for our industry. The more we discuss the inefficiency in today’s models of buying and selling advertising, the more likely we’ll be as an industry to find a solution that actually addresses the problem.

Kudos to those driving this discussion forward. 

One big struggle for publishers is managing their daisy chain. The need to constantly re-order and gather data from multiple sources takes incredible amounts of time away from site and business development resources. One complication that many may not be aware of is how accurate the data is that they are using to make these decisions.

With Yield Manager, I was able to do some research on this to find some surprising results. 

This case study involves real data from a YM publisher who is trafficking in 3^rd party tags from another network not affiliated with YM. Using the competition and auction capabilities of YM, the publisher wants this 3^rd party advertiser to serve when it is predicted to be the highest paying ad at the time of the ad call. Since it is critical that the 3^rd party numbers that are transferred to YM have minor discrepancies, we wanted to see just how accurate the data was coming from the 3^rd party network reporting. 

We will assume that the number of ad calls sent to the 3^rd party network is accurate based on YM reporting. When we compare the YM impressions to the 3^rd party network, we see the following:

We instantly see that the number of impressions being reported, even when you factor in the expected defaults that were served, is substantially lower than the number of ad calls sent to this network from YM. Over 30% of the impressions sent were not reported. This tells you that the eCPM being reported is not accurate and you are allowing lower paying ads to take precedence over other ones which would possibly pay higher. You can see by the next graph that the eCPM that YM is basing its auction on is very inflated because of the huge discrepancy of impressions being reported:

When you keep going down the path of discovery here, you end up on the bottom line, which is revenue. Using simple math to turn impressions and eCPM into revenue, you can see how much opportunity is being lost by allowing the 3^rd party numbers to dictate better delivery over other advertiser who would really pay more:

After all is said and done, this publisher was sending impressions to this network expecting about $75 from this 3^rd party network. The end result was really only $42. That lost revenue could have been and should have been monetized better. It is pure speculation why 3^rd party networks would use these reporting practices. They may want to maintain a consistent eCPM so that publishers will put them in their chain based on “this network pays me 0.30 and this one pays me 0.15”  If those numbers slip to their real amount, that network would be moved down the chain. Networks probably rely on the publisher not looking deep into the numbers and just accept what they are told and get paid what they say they are due. 

One way that we would like to add clarity to this process and aspect of the publisher business is by creating a new tool called sYMple (name change pending). This product will be able to gather and accurately monetize all of the networks in your chain. The mystery of not knowing which will pay better on a day to day basis will no longer be guess work. We will be able to determine an aggregate value of your entire chain and run the auction accordingly, giving the publisher the highest paying ad at the time of ad call, with reporting and ad serving features that can accommodate everyone they work with. There are many more exciting ideas we have for this product, so stay tuned as it is developed and rolled out to Right Media publishers, existing and new. 

The more time I spend in the online media industry (and at Right Media), the more I see parallels between an online network and a financial market. The chasm between an efficient market such as NASDAQ and the online media network space is equally apparent.

So, what parallels can be drawn between a financial market like the NASDAQ and an online media network, or even the aggregation of all the media networks? 

In the coming weeks/months, I’m going to dig into this more. I’ll look at the impact on buyers and sellers from a macro and micro perspective. Feel free to email me if you read this and find it interesting or worth discussing/arguing. My email is my first name, then @rightmedia.com.

Chapter 1 - Networks as Market Makers

Before coming to online media, I worked for Citigroup in the Debt Derivatives group in New York. Derivatives are financial instruments that increase or decrease risk based on the buyers/sellers view of a market. Each party in the transaction is attempting to minimize risk while maximizing return on investment (ROI). For example, if I own millions of dollars in GM bonds, and I believe that GM defaulting on their bonds will cause me to lose money, I can buy a derivative, or ‘protection,’ from a seller to cover a portion or all of the loss in the event of default. This protection comes at a price which is negotiated between buyers and sellers, either through a trading platform or through a customized financial agreement. The seller earns money by offering the protection and assuming the risk, and the buyer minimizes risk (loss of value) by ‘passing’ it to another party. Financial markets such as the NASDAQ, Instinet or even creditex.com thrive by serving both parties fairly based on their needs and outlook.

Much like a NASDAQ, an online media network facilitates transactions of somewhat standardized products between buyers and sellers. The network operates like a broker/dealer, such as Smith Barney, by aggregating supply and servicing the buyer directly or through their intermediary (an agency). Advertisers buy media to maximize ROI (through users’ actions or brand positioning), and attempt to minimize risk through targeting buys (content or behavioral), centralized ad serving, standardization of contracts and ‘optimization’ (which I’ll be writing about more later).