Howie Schwartz: If you look at consumer time spent on mobile versus ads dollars spent on mobile, yes, there is a huge disconnect. We see it as a pretty big market today but the scale will really come over the next few years. It's early for mobile in general, and needless to say, it is much earlier on the exchange side and the RTB side.
There are multiple exchanges that we already work with today and each one of those exchanges is growing dramatically simply because there is so much inventory available. The perfect home for that inventory, in our opinion, is within RTB and is within the exchanges. We can be very picky in terms of what our clients are buying with full transparency.
The promise of transparency is something we hear a lot. What levels of transparency does Human Demand provide?
When you are running a campaign as an app developer, you see every single publisher, which basically means the app that your ads are running in. It will list the number of impressions that you serve. It will show you what we call our effective CPI -- effective cost per install -- so you know what it is costing you to acquire users per individual publisher with weekly transparency. At that point, the developer can determine clearly if they want to buy more of this or less.
Typical mobile DSP's have very, very high entry points. They are looking to work with brands that have $50,000 to $100,000 budgets, and maybe they will take a $25,000 IO. With our platform server, you could put $50 on your credit card and start running on it today.
Where does the name “Human Demand” come from? And what does that have to do with being a mobile DSP?
We work on a lot of hyperlocal campaigns and we’re building up rich media ads into our platform.
That’s where our philosophy comes in and separates us from other DSPs. Why do we call it Human Demand? We believe it's actually the first Human Demand platform instead of it being a demand side platform. Demand side platforms are typically black boxes. You have a whole bunch of rocket scientists on the right-hand side of that who hoard all of the data.
They spew out some traffic and stats and reports, but the buyer is often buried under the weight of it all. They have no ability to leverage anything from this data. So we actually flip this completely on it's head and say that you, as the advertiser, should own all of your own first party data 100 percent. It shouldn't be the right of any company to hoard that in a black box. So we give that information to a human being and we allow them to see with full transparency every publisher that they are advertising in and then make specific bid adjustments as needed.
What kind of advertisers do you generally attract?
Our focus is on app developers running install campaigns for user acquisition. We do have other non-app developer clients and brand agencies who will run local campaigns. They will run rich media campaigns so we do see some of that business.
Depending on the exchange partner, between 10- and 20 percent of the 35 billion bid requests that we process a month today have GPS, lat-long [latitude-longitude] data available. So there is a pretty big opportunity to do lat-long. Next year, we'll expand the type of customers that we're working with a little bit more, but still with a concentration on local and hyperlocal.
As a mobile DSP, do the differences between Apple’s iOS and Google’s Android systems mean anything to your business? Also, what’s your sense of the expected changes coming to the iPhone UDID, the unique device identifier, in terms of what that means as a tracking tool?
I'm really happy that Apple has finally stepped up with an advertiser ID for iOS. It's something that has been badly needed in the marketplace. When Apple was silent about that for the last nine months or so, it caused a lot of fragmentation, that forced developers to come up with hacks to the iOS system. Now that Apple has kind of spoken up and said iOS-6 will have a new advertiser ID that we're going to be able to work with as an ecosystem, it pretty much killed all of those hacks and workarounds.
What was the main problem with the hacks developers used to track users within iOS?
They all had the same privacy issues as UDID did. It was sort of like if your mom tells you not to eat a cookie after school. So you get home from school and there's a cookie jar and then there is a bowl of M&Ms. So what you do is you eat the whole bowl of M&Ms. Your mom comes home and says I thought I told you not to eat junk food. You say no, you told me not to eat a cookie. And mom says you should have known what I meant. It doesn’t matter who’s right or wrong, the basic problem still existed.
Apple told the ecosystem that device ID tracking at that level was not healthy for the ecosystem and privacy. The industry turned around and said, okay we'll just do something slightly to the left, which was just as bad, because the ODIN [Open Device Identification Number] hack, which created an ID from the Media Access Control address (MAC) and tried to muddy it to protect users from being personally identified. But it really didn’t achieve that. The MAC address has the same issues with privacy as UDID. So it was just the wrong thing to do.
What about Android? Do you see any problems or advantages working with Google’s mobile operating system?
It's actually much easier to deal with because Android's platform provides two simple options. The first thing is there is a really big difference between Apple and Google, right? Apple is a closed platform. Google is an open platform. Google is also an advertising company at their heart. Apple is not. Just because Apple bought Quattro and made iAd does not mean that Apple is an advertising company. That's why you see a difference in principle.
Google and Android support third party cookies. Safari and Apple do not.
In terms of using the mobile web, by default there is support for third-party cookies. It is not typically used for app tracking. There are kind of various technical reasons why. You don't really see the privacy issues with Android that you saw with Apple. Android ID is a much friendlier standard from the way the industry approaches it.
Google offers a tracking ID within the Google/Android market and it's passed through the application. Apple’s iTunes App Store doesn’t accept that. The benefit of that is that there are no cookies and there is actually no device ID needed. That avoids the UDID problem.