Growth, first and foremost, is a mindset. Tech choices will seldom be the most impactful decisions when it comes to driving growth, but poor tech choices or improper configuration of tools will definitely inhibit what a growth team can do, instead sowing confusion and frustration within the organization.
Common frustrations caused or exacerbated by a suboptimal tech stack include:
- Inaccurate or inconsistent data, leading to the team not trusting the data coming from analytics.
- Inability to measure the results of experiments including AB tests, leading to a lack of clarity about the right direction to take.
- Marketing channels or monetization options being unavailable or ineffective due to missing or mis-configured SDK integrations, leading to marketers unable to do their job properly.
- Over-measurement at too early a stage: it’s good to think about what constitutes Minimum Viable Analytics when the app is still iterating toward product-market fit.
To avoid these kinds of frustrations, we’ve added a layer to the Mobile Growth Stack that addresses the most important tech choices to consider early — or regret later.
The Tech Layer of the Mobile Growth Stack
The Tech Layer was added to the Mobile Growth Stack in 2017
In this article, I’ll cover some of the common tech choices facing any company or individual building and launching a mobile app. I’ll outline why companies implement certain technology to drive growth of the app and the benefits of including such technology in a new app from the start.
The App Itself: Native vs Cross-Platform
One of the first considerations on the list is likely to be that of the underlying technology platform on which to base the app. Assuming the app needs to support both iOS and Android, there will be a consideration of whether to build native apps (in Swift / Objective C for iOS and Java for Android), or build on a platform that can deploy to both of these targets from a common code-base.
Apps developed natively typically provide more complete access to the underlying OS and hardware features and ultimately give more control to the developer when it comes to fine-tuning and debugging. The trade-off is typically time & cost of development, which can be significantly higher when developing natively.
Cross-platform development has come a long way since the ‘worst-of-both-worlds’ solutions that produced ugly hybrid apps. These days, it’s often impossible to distinguish as an end user between games or apps developed cross-platform in Unity, ReactNative or Xamerin vs those developed natively.
Cross-Platform: Pros and Cons
Pros
- Rapid application development and iteration (typically faster / fewer resources needed than building and maintaining two native apps, though set-up may take more investment initially)
- Parity between iOS and Android experiences is far easier to maintain due to shared codebase
Cons
- Bugs in the developer platform may be tough / impossible to fix (lack of control over your own apps)
- Interoperability: Not all 3rd party tools and SDKs will play nicely with the chosen cross-platform solution.
The last point (interoperability) is one good reason to consider the tech layer holistically, rather than making choices in isolation that may introduce limitations. If selecting a cross-platform solution, check in advance that the other tools and services (attribution, marketing automation, etc.) that have been selected play nicely and include the relevant SDKs for the platform.
Multiplexers are Awesome (but expensive)
Multiplexers such as Segment.io and MParticle deliver a flexibility that mobile marketers once only dreamed of. Once an app is integrated with such a solution, events and properties can be fired once and then sent server-to-server to any number of other services, which can be enabled with a few clicks from a dashboard. Multiplexers enable teams to be significantly more nimble when trying out new tools: they can often be tested within hours rather than days or weeks and often obviate the need for additional SDK integrations or new app store releases.
Costs are not insignificant, but can be considered in the context of saved time and possibly more leverage in price negotiations with other technology partners, since competing solutions can often be evaluated in parallel.
Install Attribution
Those unfamiliar with the mobile ecosystem often fail to consider mobile install attribution — tracking the source of app installs — prior to launch. In the early days of an app, before product-market fit is established and if no significant paid UA (user acquisition) is planned, it might be feasible to postpone attribution tracking, or to get by with using Apple Campaign Links. But once you get serious about driving traffic to your app (regardless of organic or paid), attribution becomes a necessity to understand where the most valuable users are coming from.
Trying to ‘roll your own’ attribution tracking is really not an option at this point: simply go with one of the established players such as Adjust, AppsFlyer, Kochava or TUNE; these services are integrated with all of the major ad networks and traffic sources (with the exception of TUNE which is not an official Facebook Measurement Partner).
For next-level attribution, cost aggregation and more advanced analysis, an aggregator such as Singular or a more flexible data layer such as Tenjin can confer some additional advantage. These advanced services are more likely to add value once performance marketing spend starts to scale up, rather than in the early days.
App Analytics
Tracking behavior of users within the app is critical for making product improvements, gaining insights about users, as well as reporting internally and to investors.
Building excellent behavioral analytics, including event-tracking and a UI that supports ad-hoc funnel creation, cohort retention tables and other important data visualizations is likely to be a huge distraction, particularly for a small team. This kind of behavioral analytics capability can be licensed pretty affordably in the form of robust solutions such as Amplitude or Mixpanel and can even be found for free in the form of Flurry.
Even if a commercial analytics tool is used to get up and running fast, it’s still advisable to maintain internal data warehouse of (at least) entities like users and key engagement events, such that ad-hoc SQL queries can be run, dashboards can be created on top of them (using tools such as chartio or tableau) and for internal reporting and monitoring; this core company data should be owned, protected and mined by the company, rather than fully outsourced.
(I go into more detail on how to approach app analytics in my post Minimum Viable Analytics.)
A/B Testing Framework
In order to A/B test new product features, UX tweaks, marketing campaigns, and user communications, tools or frameworks can help immensely in configuring test and control groups, measure the impact on the relevant metrics and conversion goals, and report results.
It’s worth noting that in early days, there may not be enough traffic to the app in order to run timely A/B tests inside the product; in such cases, A/A testing is a more practical — albeit considerably reliable — approach. As such, in-app A/B testing is often something that doesn’t make sense for very early products that are building a user base from scratch with only organic traffic.
Off-the-shelf tools such as Apptimize, Splitforce and Optimizely take a lot of the effort out of running native app A/B tests, and can reduce the risk of statistical errors creeping in through poor experimental setup.
Once products reach a certain scale, most companies take the decision to apportion users into experimental groups and measure the results using an in-house experimental framework that can be used across all platforms, devices and systems and can avoid cross-contamination when multiple experiments are running simultaneously.
Marketing Automation
Channels such as Email, Push Notifications and In-App Messaging can be used by growth marketers to increase engagement and retention within the product from the moment it goes live, but only if these levers for growth are enabled. Building behaviorally-targeted life cycle campaigns involves more than the simple ability to send a message via one or more of these channels: it requires the ability to segment users based things they have or have not done within the app, as well as to measure the results of these campaigns so that they can be improved or scaled.
Engineering-heavy teams tend to either assume that this kind of functionality is easily hand-rolled, downplay the importance of measurement and iteration, or — most often — both. Having decent re-marketing capability (i.e. ability to communicate with existing users) available at launch significantly increases the capability of a growth marketer to influence product success and drive up growth metrics.
Tech choices range from all-in-one solutions such as Localytics, Leanplum and Mixpanel, which offer deep analytics as well as marketing automation, to leaner marketing-focused solutions such as AppBoy that are lighter on analytics, focusing instead on extended marketing capabilities. Cheaper, more lightweight solutions exist in the form of OneSignal, DeltaDNA, etc. which provide teams on a tight budget with some basic capabilities and there are many other solutions in between. The bravest developers with a lot of time on their hands might try to build their own marketing stack on top of the bare-bones low level platform that Firebase provides, though they will certainly have their work cut out.
Deep Linking
While linking between sites on the web is a ‘solved problem’, the technical complexities of linking into native mobile apps (and associated tracking of referrers) have led to solutions such as Yozio, Branch and Deeplink.me which simplify the process of building and maintaining ‘smart links’ for use in emails, digital campaigns, invites and shares.
Even if the app doesn’t contain individual ‘content’ elements that would be good candidates for individual deeplinks (and possible associated mappings between website and mobile app), it’s worth considering that there may be key screens or features within the app that could be linked from push notifications, emails or other places. If this is the case, these link destinations will need to be explicitly created/handled by the app.
Basic deep linking and deferred deep linking capabilities come included with attribution tracking providers such as the ones listed earlier in this article, as well as with Firebase. These are often more than enough for developers to leverage the power of deep links and ensure basic tracking and linking functionality is in place. However, dedicated deep-linking products like Branch take the feature set and data reporting to the next level of sophistication and may make life easier for growth marketers to do more experimentation.
Monetization
If any form of non-native advertising is planned within the app, it will be necessary to implement one or more monetization SDKs. The choices are numerous, to say the least, and definitely outside the scope of this article to cover in detail. Some common partners for monetizing via in-app advertising include Twitter’s MoPub, Google’s DFP, Facebook Audience Network. Video advertising from platforms such as Vungle, AdColony and AppLovin are particularly performant in many cases compared to more traditional display advertising formats.
Given the dizzying array of options out there, it may make sense to use a mediation partner that can provide inventory from many networks through a single SDK integration; SuperSonic Ads (now part of ironSource) and Fyber are good places to start, though many more options exist.
It should be noted that serving adverts in the product may adversely affect performance, specifically with regards to increased data usage (and associated battery drain), though this might be a welcome trade-off if such an integration brings in revenue with relatively little development effort or maintenance required.
Summary
Building an app with growth in mind requires the integration and proper configuration of numerous 3rd party services and (possibly in-house developed) enabling technology. The new Tech Layer of the mobile growth stack encourages holistic consideration of these technologies and in particular how they can be effectively leveraged by activities in the other layers of the stack to impact growth KPIs.
For more granular coverage of the entire mobile SDK ecosystem, check out MParticle’s excellent Periodic Table of SDKs.
If you found this post useful, feel free to tap ❤ and spread the word.
Table of Contents
