This has been an interesting question for me lately as the buzz of our network and Yield Manager platform has grown. Increasingly I am coming across publishers who have heard of Yield Manager and are very excited about the potential it has to offer. Yield Manager has proved to a very beneficial tool for many of our clients who have allocated the time to learn the product. This is a great situation for a sales rep to be in:  a great product, satisfied users that are spreading the word, and inbound leads who are extremely excited. I have had referrals come in and leads handed to me where it seemed as though the contract was already signed. A sales rep’s dream, right? 

Not so much the case.

I find myself in a position that I have never really been in before as a sales rep–telling clients “no”. Saying “I’m sorry, but this product just isn’t the right fit for you” is not something I was accustomed to saying but is a situation I have found myself in lately. I have worked for companies where the mantra seems to be “ABC. Always Be Closing!” Sometimes I have felt like I was force feeding clients just to make a sale. Not at Right Media.

My job is to recruit new publishers to our vastly expanding network and sell our Yield Manager platform. There are a few things that have made this job enjoyable:  We have multiple products that I believe will extremely benefit our various clientele, I consistently see results that support what we “pitch” to people, and most importantly, my boss is ok with me being honest and saying “no” to people. The Right Media network and Yield Manager platform are flat out awesome, but Yield Manager is not necessarily the right fit for everyone. The core functionality applies to everyone, auctioning every single impression and always serving the highest paying ad. However, there is additional functionality that many pubs, who are looking for a solution that is less hands on and less to manage, just don’t need.

The great thing about Right Media is that the company has decided that there can be a better product for a portion of our clientele and “until we build it, let’s be open and honest with people. If the current product isn’t the right fit for you, it’s not the right fit. We will make you something better.” (www.rightmedia.com/symple/)  It’s a great feeling to be able to sit down with a client, analyze their needs and wants, and give them an honest answer about what is right for them. If the product fits, let’s go for it. If it doesn’t, let’s find another solution.

The question:  When should I tell a customer no? 

The answer:  When it’s in their best interest.

Wow!  What a novel idea!

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.

• There are minor glitches in new APIs implemented last week (bad naming of methods, methods placed in wrong service, etc). This needs to be fixed.
• Finish security layer and make ready SOAP API for the production.
• Start publishing docs on SOAP API: top level description of services, perhaps examples of usage.
• If time permits add versions of APIs which allow to use codes instead of numeric IDs.

Marketer Seth Godin has written a new free ebook called Flipping the Funnel. The book is about using new web tools to empower your customers into spreading the word about your company/service/tool. We’re already using one of his suggestions in having an open blog to allow people to participate, link to the blog, and take part in the discussion.

However, what I’m wondering is if there is anything we should be thinking about to build in the product to allow customers to spread the word? The first thing that comes to my mind is an easy way to export/post their reporting data into their blog to show their users. You’d be surprised how many bloggers enjoy sharing this kind of data with their users.

Another idea would be to have a tool that actually maps out or visually displays their increased CPMs as they ad more competition into their advertising mix. If that visual display could be exported, it’s another thing people could show and discuss. And it educates our customers and their audience.

The WeBreakStuff blog has a series of posts focused on building web applications.  It looks like it’s just started over the last month, but there are some good insights for us to consider.

So far we’ve followed the advice well by considering our audience and not relying on anyone else’s APIs that could break or change.  However, if some other ad networks out there did provide APIs for allowing users to access their reporting data however they wanted, we’d be able to do some cool things.  The post on the beta tag is also interesting and we should start to consider whether we bother with a “beta” label or not even when we’re publicly available.  For more on betas for new web applications, check out Mike Arrington’s post at TechCrunch.