The digital marketing landscape is a vastly changing one and in recent years we have seen two trends emerge almost simultaneously: Real-Time-Bidding (RTB) has taken off and completely changed the face of digital advertising, and the rise of mobile has forever altered user’s interaction with digital content.
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 a 3G card 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 bidding real-time 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 recognize 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 320×50 ad size but that is very limited to smart devices and doesn’t resize proportionately to the other IAB standard mobile ad sizes 300×50, 216×36, 168×28 and 120×20. 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 the 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 them as their official sales house. Mxit, as an application is really unique in the sense that is sits between being a mobile application and a mobi site, 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.
Kevin Dayton is co-founder of Shinka.
