6 Android Hacks To Easily Track User Acquisition On Mobile
Twitter Reddit LinkedIn Facebook
During Mobile World Congress 2014 in Barcelona I gave a talk about Growth Hacking for Mobile. It was not a PR and Marketing 101 list that you would run down to cross tasks off. On the contrary, it was a thorough dig into real product hacks that startups can use to acquire users, to tackle the initial content problem and even to “fake” user activity Before Product Market Fit (BPMF) in order to validate and verify hypothesis or After Product Market Fit (APMF) to optimize and therefore grow the business.
As famous commodity investor Jim Rogers once said: “Whenever I followed another person’s advice I made mistakes and lost money”. Alas, you have to do your own thinking. You cannot do things in a similar fashion as everyone else but expect meaningful different results. It is a beaten track especially in today’s world where things easily spread like wildfire to every little corner of the world.
Before we dig into the details we have to get something out of today’s growth hacking talks: Growth Hacking is not The New Marketing, Growth Hacking is the intersection between Product, Marketing and Data.
Growth Hackers use product tactics that go beyond SEO, Whitepapers or Adwords for distribution as Aaron Ginn correctly pointed out: “A growth hacker looks beyond adwords or SEO for distribution. In an age of social users, the right growth strategy with the right product-market fit will lead to massive scale through viral loops.” The stress here is on “product-market fit” and “viral loops” and as you can see those do not relate to marketing to any extent.
Unfortunately, many people talk about growth hacking but completely neglect the product part of the equation. Real growth, especially through viral loops comes through creativity on the product/technical front. The great thing here is that there is a myriad of ways to ignite and grow your business. A couple of quick example are Airbnb which offered hosts the ability to publish their properties on a well established player in the market, Craigslist.
The great thing here is that there is a myriad of ways to ignite and grow your business.
Another example is Twitter. When John Elman started to build a growth team at Twitter at the end of 2009 loads of users were signing up but also many were leaving shortly thereafter. The team dug in and discovered that if a new user would immediately follow 5-10 people she would very likely turn into a long-term user. So the Product and UX team implemented an onboarding scheme that would help a new user to discover people and interests to follow.
In fact, as Elman pointed out to me recently Twitter made major advancements to this onboarding experience in January 2010 as well as in August 2011. These unique technical solutions show that creativity leads to major breakthroughs when it comes to distribution and user retention.
Now, in the face of these two big-name Silicon Valley examples you need to ask yourself what growth means for your business at your current stage. Are you in need for more users to verify qualitative research in quantitative ways, in need to get to statistical significance or because you have pivoted recently (aka Before Product-Market Fit, BPMF) or do you want to optimize your product, sales and distribution in order to grow your business (APMF)? It makes a huge difference.
Simplify, Simplify, Simplify
Why? Simply because it will get way way easier to design, test, track and measure everything you do. For example: Take a screen that has 4 buttons, those 4 buttons lead to 4 other parts in your app in which 4 other screens await the user. If you would draw those interactions out it will get very complicated very quickly. Since growth hackers make products that are easily understood beyond a niche tech crowd simplicity is the most important ingredient.
Take the company Signatur.it and a simple email (slide 19). Well, sort of simple. The founder pitched us during StartupBootcamp Amsterdam Pitch Days in early December 2013. The company provides a service that allows every smartphone owner to sign documents in the mobile browser. Anyone can simply email a document to another person whereby Signatur.it then sends an email with the request for signature.
The initial email design had 9 different ways for the user to get off track through various links to Twitter, Facebook and whatnot. However, the primary action - to sign a document - was not even clearly marked as the primary action, it was just colored text. A quick review solved those issues. The new email layout contains just one button: “Sign Document”.
Mind you, we are only talking about a simple email here but it is apparent that even such a simple email can be quite hard to nail.
Tracking on Mobile
The biggest bottleneck on mobile (slides 23+24): The app stores cut the cord between the acquisition source of a particular user and the installation of the app on the user’s device. For Apple’s App Store this is the last word and this is where 3rd party tracking solutions jump in. Interestingly, Android or Google for that matter does not cut the cord entirely. Android only cut it if you do not care about it. Surprisingly, through recent discussions on that topic I noticed that some Android developers do not seem to know about the built-in tracking functionality of Android.
Most tracking needs center around campaign tracking. An ad is displayed within a mobile app that has an integration with an ad network (through an SDK). That ad network works hand in hand with a 3rd party tracking tool. When the user clicks the (banner) ad the networks sends device data (data set A) to the 3rd party tracking tool and then forwards to the local app store app. After the installation the SDK of the 3rd party tracking tool sends the device data (data set A) to their servers and tries to make the successful attribution.
Many product hacks and viral loops that I will describe below make heavy use of the Android’s tracking technique. But before we go into further detail let us review common tracking techniques.
Cookie tracking Cookie tracking has been used mainly on iOS between around 2011/2012. It works like this: A click on a banner opens Mobile Safari, the app creator then places a cookie within the sandbox of Mobile Safari. While opening the newly installed application the app will quickly jump back to Mobile Safari in order to read that cookie and then quickly jumps back to the app. I have not read anything about whether Apple has actually rejected apps that are doing this. On the other hand though I have not come across any apps that are still doing this either. (Please leave a comment if you know anything about it) Referrer URL (Android only) This is fairly straight forward and most tech and marketing people know about this from the web world.
Any URL that links to a web property can be feed with parameters for acquisition and campaign tracking. If the web property is integrated with Google Web Analytics, the tool would then pull in those parameters and it values. Since Google Analytics is now moving heavily into the app world the maintenance of URL parameters appended to app download links makes perfect sense. Interestingly though you do not need to specifically use Google’s app analytics product to make use of those URL parameters. Google Play “forwards” them no matter what.
Unique Identifier For Android this is mainly the android_id or MAC address, the unique identifier for iOS are the IFA for Advertisers and IFV for Vendors like app developers. Those are being used in 3rd party tracking solutions whenever possible in order to track devices and to make an attribution. If those are not available many solutions would then rely on Android’s Referrer URL (for Android only) or lastly on a technique call device fingerprinting.
Device Fingerprinting I have to confess this sounds pretty cool. The bummer is though that looks do not always count or that they can heavily deceive you at times. Same thing with device fingerprinting. This techniques is used for web to app tracking when, for example, a user clicks an invitation link sent through email. Device fingerprinting techniques try to grab as many data points as they can on that click (like device carrier, the IP address, device language or the user agent) in order to build a fingerprint for that device.
My personal experience is that in most cases the only data point used is in fact the IP address. Here is the problem: Imagine yourself getting an invitation email from a friend while you are on-the-go and decide to download the app through WIFI at home because it is too heavy for 3G. Your router at home will now assign a different IP address to your mobile device resulting in a broken link between acquisition and install no matter what. Unfortunately, this is not the only issue with IP addresses on-the-go. Carriers may actually change your IP address on-the-fly because, for example, you are taking the metro and won’t have coverage for some time. (Growth) Hacking Before Product-Market Fit
Product Hack A - Single-player utility (slide 30)
The starting point for all product endeavors should be single-player utility. At the very start the product shall provide decent value for the user itself, a product that does not require a “full party” to get value out of it. Simple examples are productivity apps like Asana or even the photo filters on Instagram. Asana can simply be used in single-player mode without the need to invite people.
In fact, Asana has crossed the chasm between single-player utility and social productivity with some clever viral loops. One example: A user can assign a task to every person on earth simply by entering their email address. The neat thing here is that the user is not inviting someone to finally use the product but to get their own stuff done. Extending the value already provided. The non-user has a clear incentive, namely, to get the task done so that she may try out the app. The likelihood for a positive viral loop is a multitude higher as it otherwise would be. Single-player utility might be tough for products that have the social aspect at their very core but it is worth exploring what combination of features provides enough value for a user to use the product on their own. Interestingly, adding viral loops at some point might just be a simple exercise.
Learnings
- Provide value without the need of being social
- Solves the chicken-egg problem • While users become hooked integrate smart viral loops
Product Hack B - How to tackle the content problem v0.1 (slide 34)
But what to do when your service falls into the latter category? How can you “fake” content first and a full party second? Let us take an example of a company I have helped last year to re-build and re-design their product and I am still advising: POSING LIFE. The app allows a user to create photo albums which can then be shared with friends for them to add photos themselves.
The two screens (slide 39) show how a user creates a simple photo album by selecting pictures (step 1). On the old version users needed to accomplish 9 single steps to create an album (aka add content). Users hated it. The UI was indeed simple to use but it was way too restrictive because it simply required the user to enter a ton of data. Through a re-design of the entire application we removed a world of restrictions so that the very same action (creating an album) now takes only 2 steps. This new UI was then tested with people and it was very well received. Even though some users only uploaded one or two photos it does solve the content problem. Overall album creation greatly increased.
Learnings
- Keep the core features as accessible as possible
- Avoid/mind restrictive features in an effort to differentiate
Product Hack C - How to “fake” or ignite activity? (slide 39)
How can we “fake” or ignite user activity? The biggest problem for many social services: Its an empty party. From the get-go it should feel like as if the party is in full swing, alive and kicking although it is quite the opposite. Luckily, it does not need much.
Staying with the example from Product Hack B, step 2 in the creation process is to invite friends. But what will happen next for a new user when the product just hit the market? The user will see an empty list that reads something like “Sorry buddy, no friends here”. Not good! In order to prevent an empty list the team at POSING LIFE implemented the following logic. User A would for example invite a handful of users and non-users whereby some people will certainly not know each other. As soon as people get invited the logic would create a friendship connection between each one of those people. Now, when a user who has been invited in the past now creates a new album she would automatically be friends with everyone that had been invited to albums alongside herself in the past. This will result in a long list of friends on this second step. It is certainly not the most trustful connection but it allows new users to try out the app without the need to bother every other friend.
Learnings
- Make it appear like the party is in full swing
- Non-trustful connections can get your product to the next milestone
Product Hack D - How to tackle the content problem v0.2 (slide 47)
The same team has recently integrated a Twitter-like follow feature that will give users more control over the content they see. Staying with the Product Hack C for a second the other benefit of a non-trustful connection is that a users’ Home screen will be populated with content instead of showing a blank screen. I agree on the point that this random content may not be of much interest to that particular user but it is better than showing a blank screen. But what will new users see when they open the app? Like many startups the team of POSING LIFE does not have the millions of dollars in funding and amount of resources that Twitter had to build a smooth onboarding flow. What can we do if a random connection between people is not he preferred way to go about content? The team actually implemented a very simple hack: Instead of building a heavy but smooth onboarding flow the app would simply pull a list of users from the server. This could be a global list containing a few active users or the server could host localized lists depending on the continent or country. Those lists can be changed manually at any time, it is a quick and easy hack.
Learnings
- Very quick and simple solution
- Things do not necessarily need to scale depending on the stage of your startup • Hacks of manual nature can simply overcome the content problem
Growth Hacking After Product-Market Fit
Product Hack E - Awesome invitations (slide 51)
Now, what will happen when a user invites you to an event album? You will get a link via email where the click on that link either opens your mobile or desktop browser, so far so good. The website will show one or a handful of images of that particular album as a teaser and after 2 seconds a little input field will appear at the bottom. By entering your email address in that field you can automatically join that album and upload pictures. But in order to upload pictures you would need to download the app, alas, the page forwards to the native app store app on your device. During registration you would normally need to re-enter your email, name etc. Not so good! A better solution is this: We are currently planning to implement that the email address you are entering in that input field will be handed over to the sign-up form within the application. The user will not need to type in her email address once again, her name could also be automatically picked up if the email syntax allows for it. As you can tell from your experience on the web the conversion rate will increase dramatically this way. However, you might wonder how the heck is that possible? Simple through the magic of Android’s Play Store. Bummer though you have to use a 3rd party tool to achieve the same trick on iOS.
Learnings
- Create an end-to-end invitation loop
- “Pre-fill” the sign-up fields for better conversion
Product Hack F - Test holistically across web & mobile (slide 55)
Why shall marketing experiments be the normal on the web but not on mobile? What your startups communicates throughout user acquisition on the web shall match the communication within the app. So a clever way to better align and holistically test user acquisition and onboarding (and potentially retention) is to build optimized responsive landing pages that act as your mobile walkthrough. You can do all the marketing magic that you are used to from the web world with those responsive landing pages made for mobile. You exchange images or change text any time on your server and the new content will immediately appear within the app. But how does the app know what to show? Once again Android will be at your service. You create different responsive landing pages A, B, X and by appending a version number to the download link the Android app can simply request the right landing page/walkthrough.
Learnings
Play the same marketing magic on mobile as you already do on the web • Make the onboarding experience consistent • Test holistically across web & mobile • Increase user retention
Product Hack G - Give to get (slide 60)
With the mobile app upptalk.com a user can make normal landline or mobile calls similar to Skype Out. However, she needs credits to do so which she can get through sending out invitations to friends via email, SMS or any other channel. Now, only successful invitations lead to credits paid out. Here lies a problem though: Users register an account with their phone number and not with their emails address. So whenever a user was invited through email and then signed up we either could not attribute the sign-up to the inviter and hence would not pay out the credit or it took a bit of time (we asked the user for her email address later on in the app).
This was reason number one why we implemented a 3rd party tracking tool. Furthermore, we wanted to find out what the most successful channel for invitations was. SMS invitations keep growing and growing, cost went up like crazy (we paid for the SMS) but we were not able to tell at the beginning whether it was worth the extra cost of offering that channel. At this stage we implemented mobileapptracking.com (MAT). As I noted above the main use case for mobile tracking is campaigns that run on other mobile apps.
So we had to set up MAT in a way that the app of the inviter would be declared as a publisher (a publisher is normally the app that runs the campaign) that then generates the tracking link (inviter and invitee IDs appended) and sends the invite. The invitee clicks - at this point the tracking tool makes a fingerprint of the device for the first time and the user then installs the app. On app start the MAT SDK would then send device data points to their servers in order to attempt a successful attribution. MAT then would make a callback to the servers.
Learnings
Viral loops may have many lose ends. Fix them first before integrating a tracking solution • Using tracking tools for different purposes may result in a lot of nitty-gritty hands-on work
In order to round up the article let me leave you with a few very important points to consider. With 3rd party tracking solutions you can basically track every sort of event, e.g. btn, revenue, but KISS. As pointed out earlier simple solutions are easier to build, to manage, to test, to measure. In fact, simplicity is the de facto ingredient for products that go mass-market. So, start with the most important metric first and remove whatever metric is more for vanity purposes than real value, the fewer the better.
In fact, simplicity is the de facto ingredient for products that go mass-market.
Start with Android because it is very simple to set up, test and iterate and then move across all platforms for a consistent approach. You will find open loops that cannot be easily closed. Better that you have started with one single platform that was the easiest to play around with. If you are heavy on iPhone users you actually cannot do anything wrong by testing things on Android. However, look at the most recent data of Android versus iOS activations, activations are leaning towards Android these days so you may not even need a 3rd party solution.
If you decide to go for a 3rd party solution be aware that every data point you shipping to the 3rd parties servers cannot be deleted. You would need to create another app ID in your account and start up fresh. In any event, keep production and testing versions separate in order to reduce the likelihood of false signals. It may not matter that much if you have 100 million users but for a small startup that employs a QA person who tests beta versions every single day you will get a skewed data mess on one single app ID for production and development/testing. Trigger tracking events where the data itself changed and do not track the same somewhere else.
This is sort of like maintaining files on your local drive while having the same copy or another version on Google Drive or Dropbox. I sometimes fall victim of the latter case myself but it only creates complexity. Tracking the same event on multiple fronts is especially dangerous on the UX side of things. Since there is never enough time available you may encounter a UI bug that allows a user to go back and forth between screens triggering the same event time and time again.
In fact, this does relate to the last point for today’s article: Trigger tracking events after they have happened. Tracking is just some random marketing stuff for some developers and it does not directly relate to functionality (what they care about). It will reduce complexity and increase data accuracy having a product manager or technically-minded designer to go through all events together with the developer after the functionality has been implemented (e.g. end of sprint).