SPOILER ALERT: App Tagging: Can now work “zero SDK required”
- In live demonstrations to our clients, prospects and partners I show them how it is now possible to make real-time (true, Real Time) configuration to ad-tags and content in apps, to 100% of install base
- EG: Configure the AdMob interstitial Ad ID for a publisher on the sell-side or hide an offer that should not have been there in a ‘buy-side’ offer. No App Developers required to make the changes.
Evolving our AdOps Industry Approach to Apps
Having launched TagMan in the USA by loudly beating the drum about ‘tagging problems’, my new drum that I am beating loudly in market is around solving another serious problem on the horizon: The sluggish, quagmire-like restrictions that the current approach to mobile tagging has on industry growth.
The Road to Revenue Risk – Why You Need to help Curb The SDK Approach
By understanding the history of ‘why and how’ SDK risks are introduced in apps below, you can help your vendors and client partners identify and protect their business against them.
History Repeats Itself: 10 years of Growth, Bloat and Bottlenecks
2005 was a world where ‘desktops’ were the kings of online revenue stream but JavaScript tags and pixels (while needed) were sadly dragging down the progress made.
In 2009, “Tag Managers” were created to:
- Remove ‘the bottle neck’ and “IT friction” (of adding, editing & removing JavaScript tags within in an html environment) without needing to manually touch the page.
- Increase the page speedof web-based environments impacted by “tag/pixel bloat”.
- Ensure better data-fidelity through
- Data Layer Consolidation
- Conditional and Asynchronous Tag Loading (no tag shalt block another tag’s ability to collect data or show ads in a faster fashion)
This newfound ability to easily test and refine 3rd party tools in desktop web through a Tag Manager, meant that revenue could be generated via streamlined automation strategies (on web-based sites). It helped to usher-in (and now deliver much of) today’s “automated & programmatic advertising ecosystem”.
2015: It’s all about “Devices” (including your watch & TV)
Mobile devices have reached parity with desktop in terms of revenue opportunity.
New hurdles to “Testing, Scaling & Protecting Revenue Automation” in a device-driven world have arisen and… you guessed it…. the ‘SDK’ has now become the ‘new bloat/bottleneck’.
To an extent, any Tag Manager with a mobile solution should essentially have access to any data within an app and be able to pass it to any SDK or tool that requires it.
The key challenge is “how can you add/change data to an SDK, that you are pulling on the fly as your strategy evolves?
An SDK Tag Manager approach just will not work as well as Tag Managers do in desktop, as we will explain below.
Solving for the “Mobile Tagging Oops”…
For most of your mobile “Web” activity (you can consider it as HTML) [and majority of vendors that you work alongside with], most Tag Managers should be able to cover the basics of deciding ‘server-side’, what elements to load into the mobile browser or where data goes/flows and provide access to any data required.
However for native apps, the rapid pace of app development iterations and release cycles, compounded with an increase in 3rd parties to help create & monitor revenue such as:
- Buy side: Remarketing, DMP, Analytics, MVT, Personalization
- Sell Side: Ad formats such as Outbrain, Interstitials, Videos, Ad Networks, etc.
..leads to a hockey stick growth of “single-use-case SDK requirements”. All of which rely on additional code libraries being inserted into your mobile app (often faster than you can fully test/monitor).
Too Many Cooks…
When multiple SDKs are mashed together and trying to interact within your apps, you create:
- A much higher risk for crashes, bugs and deteriorating user experience.
- A very fragmented reporting/data collection challenge due to multiple iterations of SDK changes/releases (e.g. – What % of your users use stale iterations of 3rdparty deployments in old versions of your apps that are not yet updated on their device?)
- Costly agency or in-house app changes/development with each change/release.
- A delay in “time to market” through waiting for app store submission, approval and consumer update process.
Removing the “SDK Bottleneck”.
Apps account for 86 percent of total US consumer time spent on mobile (and with the Internet of Things on the horizon), so creating a faster, dynamic method of optimizing all 3rd party adtech tools (including the ability to update display and native advertising configurations on the fly) is paramount for us all in the eco-system. In return, the industry can take a step up on the “mobile marketing ladder” and finally hit that ‘year of the mobile’.
A better approach means lighter apps, faster testing, configuration and to deliver an increase in Average Revenue Per User, Customer Lifetime Value and industry innovation. This is the Ensighten Mobile promise and what other tools should strive for.
There are great blog posts out there by Mparticle (a business with a stellar part of mobile data-automation puzzle) and other’s focused on reducing the SDK bottleneck. All finding a better industry approach.
Recommendation for a Better Industry Approach To “Using Only SDKs”
Too many times I’ve seen tagging receive the lowest priority in mobile apps, often resulting in missing the release window. Due to the inherent costs of app developers and timings, many apps go out with partially and/or incorrectly tagged because of poorly thought out approaches with no thought to the runway required or ability to be agile in changes once the app is compiled and submitted to the app stores.
The challenge is that when using a “SDK in a Vacuum” approach (ie using a 3rd party’s unique SDK on an ‘as needed’ basis, you need to identify all of the tracking metrics early on in development within an app for the 3rd party tool that is being implemented. Once it has been implemented, if you wish to collect any new data or additional events, a developer needs to recompile the app, resubmit it to the appropriate app store and then wait until consumers have updated an app to the latest version. Each step can add weeks to the process, hampering progress that increasingly revolves around agile, real-time management of your assets.
At Ensighten, we believed there was a smarter way to approach this process than the existing ‘SDK in a Vacuum’ methodology and recently received a US patent for our solution to assist the acceleration of a healthier ‘in app’ eco-system for all involved. Ensighten clients get unmatched agility from our new breed of mobile solution with reduced reliance on developers to get tags in place and no need for app pushes to capture new events/data. The flexibility we bring to the table is unrivaled. With few exceptions, at any point in time we can easily plug-in to any event, or capture any data available within an app.
To SDK or Not to SDK?
I want to be clear here, I am not saying that the industry should stop using an SDK. It’s feasibly not possible to do so just yet and, without a doubt, an SDK is an incredibly powerful tool for publishers and marketers to access the benefits of 3rd party services within apps.
Each each SDK is essentially a block of 3rd party app code that is not written by your official dev team. Given that it introduces overheads such as Time to market, Correcting Simple Mistakes, Reporting Errors, Latency, App Weight Fragmentation and Disparate Data (to name just a few), we wanted to find a better approach to working with the SDK methodology when it comes to Ad Ops.
The Ensighten Mobile methodology enables publishers and marketers to automate and manage all SDK configurations in one platform, in a more agile and controlled fashion. This ‘holistic’ approach safely sidesteps 90% of the challenges normally associated with an SDK-Vacuum approach.
The real-time promise, realized by clients such as United Airlines is not based on removing your existing tech stack, [rather by implementing] our patented technology for applying changes to apps and existing SDK deployments. The changes like tracking new events, changing Ad ID in AdMob, or implementing A/B testing is in real-time across 100% of app deployments, without the need to recompile or resubmit anything to an app store.
Solution: A Mobile Library + Your Existing 3rd Party Toolkit to Remove the Vacuum
The key is simply assisting where a standard “Tag Manager” just cannot act in the same way. Ensighten Mobile’s patented technology is providing 3rd party adtech partners with real-time updates to data in an app, without needing to recompile it.
By providing access to any data within your app in real time (no need to update in app store) Publishers can now:
Power existing vendor SDKs in your app.
- g., Implement a “blank” AdMob SDK in your app, and Ensighten Mobile gives you power to control how the SDK acts in delivering ads and interstitial pages, instantly across 100% of deployments.
- Deploying and updating 3rdparty changes without an SDK
- No wait times, no delays, instant updates, maximise the amount of data collected to get the clearest picture of ROI (or not)
- Dynamically deliver user specific information into your app and into vendor SDKs to optimise ad delivery and maximise ad revenue
- Pass in new ad IDs and values to the SDK which AdMob or any AdNetwork SDK can use, to deliver the best ad to a user, based on what you already know about that user, on any page or section of your app.
There’s a great United Airlines case-study about “on-the-fly app customization” on our website if you’d like to know more, but a great next step would be to consider ‘what would you do, if you had real time access to app data ‘configuration’ and ask us how we can help.
