Real time bidding takes lead in digital advertising

Now the two, strolling along hand-in-hand, would seem like a no-brainer but it isn't as easy a match as we'd imagine and here's why: Firstly what constitutes mobile? Are we talking feature phones, smartphones, laptops with 3G cards or tablets? All these devices are streets apart in underlying function so let's simplify it and assume we are only dealing with mobile phones. In this regard we'll still be faced with two scenarios: Ads being injected into mobile applications and ads being injected into a website viewed on a mobile browser.

RTB ads inside a mobile application

In this scenario ads get rendered and displayed within a mobile application. The whole concept of RTB as a page loads is still taken into account but with one major downside - no cookies. Cookies are basically the heart that makes RTB engines beat and without historical data RTB is rendered ineffective. Obviously what is required is some form of unique identifier that will allow ad exchanges to solve the user identity problem, allowing data driven targeting at a much more specific level, yet still protecting user privacy.

RTB ads within a mobile browser

RTB works fairly well within a mobile browser, cookies are used to allow data driven ads to be delivered and websites will generally recognise that you're on a mobile browser and format an ad to nicely fit your screen.

What is totally mind-boggling and obviously a massive disadvantage is the lack of dedicated mobile specific ad sizes within the major ad exchanges such as Google, Rubicon and Pubmatic. Sure they support the 320x50 ad size but that is very limited to smart devices and doesn't resize proportionately to the other IAB standard mobile ad sizes 300x50, 216x36, 168x28 and 120x20.

Another limitation when comparing mobile to web is the use of single sign-on. This is obviously vital for users to be recognized effectively and allowing data driven ads to be delivered across multiple devices. On mobile phones in particular, many browsers don't support the use of single sign-on and on the devices that do, users often don't use this functionality as they don't rely on their browsers for multiple functions such as email, social media, streaming services, etc.

This is mainly due to the fact that mobile apps are more popular for the use of these services. I mentioned that cookies are used to deliver data driven advertising down to mobile devices but cookies expire and it seems like a missed opportunity when you're dealing with something as personal as a mobile device, as mentioned in the previous scenario a more permanent unique identifier would be much more beneficial.

It's at this point in the article that things get positive. At Shinka we work very closely with Mxit and have a great relationship with the company as its official sales house. Mxit, as an application is really unique in the sense that is sits between being a mobile application and a mobisite.

Advertising potential

What gives Mxit so much advertising potential is how easily it can be to get around the limitations mentioned in my earlier scenarios. Firstly, a unique identifier: Mxit has several parameters that can be used to uniquely identify users. Secondly, cookies: Mxit supports cookies (at least on the mobi-portal API). But who needs cookies when you can use a unique identifier that doesn't expire? Lastly, cross device user detection: once again Mxit provides a unique identifier that allows user detection no matter what device they login from.

This is just the tip of the iceberg, there's heaps of other data and analytics that could be used by a data management platform to push into demand-side platforms that would allow effective and relevant audience segmentation and retargeting. Advertising on mobile portals is a bit of a catch-22 for portal publishers because on one hand it offers fantastic revenue opportunities but on the other it can affect user experience. Publishers need more users to generate more traffic but users won't want to come to a portal if they feel they are being bombarded by advertising.

Nobody wants advertising to be intrusive and to negatively affect user experience but by ensuring ads are relevant and targeted to the right audience it's a win-win situation for both users and publishers.

Currently there are two technical roadblocks that we need to get around to ensure an effective RTB solution would run within Mxit: Firstly, the potential latency from making an ad request to global data centers; and the time in milliseconds required for RTB to take place and an ad to be delivered. The biggest roadblock however, will be ensuring ad exchanges see Mxit traffic as relevant mobile traffic. But, at the end of the day, successful campaigns are measured in good conversions... and conversions don't lie.