Why are apps needed, how are they created, and how can you make your campaigns run better? Why do apps that look alike from different developers convert differently, and how do they differ apart from design? We dig into it in this article. You can read about affiliate marketing as a digital profession in the article.
Let’s start with the basics: how are apps used in affiliate marketing?
Apps — in iGaming or in any other vertical — are the simplest and fastest way to launch traffic.
For example, to launch on a link, you need certain technical skills. You have to buy a domain, make a white page, set up the connection between the white page and the offer page, connect pixels — and only then start with advertising. With an app, all of this comes down to one step: you share the app account and launch ads directly in Facebook.
This is the simplest launch option, but with nuances. Launching with an app differs noticeably from launching on a link, but it’s easier to handle if you know how to work with creatives properly. Most importantly, don’t run ads on Facebook on behalf of the app itself: otherwise the app may “fly off.” The launch should be done from a fan page.
In that case, all the risks fall on the fan page (FP). There is no direct trigger on the app itself, so you won’t see the Facebook tag on the app, for example, an hour or a day after its release in Google Play. For teams that develop apps, this is a common problem right now. The tag on Facebook is a very critical thing: the team has just got the app, and 3–4 hours later or the next day it no longer exists for Facebook. The problem is serious, but there are specialists who have found a way out and know how to work with it. You should always keep such people on the team.
There are many verticals, and each has its own nuances regarding apps. Why, for example, don’t apps have as much success in Nutra as in iGaming, and what should you know about other verticals?
Let’s look at the situation from the client’s side. A person downloads an app — say, a fitness trainer, a weight-loss program or one for beauty and health. What happens after installation? A maximum of 1–2 interactions: the user opens the app, sees the loaded landing page, leaves a request on the site — and at that point the app is no longer needed.
In iGaming, everything is different: the player opens the app, registers, looks at the offer, at how the product works, and goes through extra authorization via SMS or email if it’s required. Then they perform target actions: make deposits, confirm documents, and so on. So there are many such touchpoints in any case, and apps in iGaming “play the long game,” unlike apps in Nutra.
There is a way out, actually. We won’t spoil it, because it’s the inner kitchen, but we know how to “wrap” Nutra in apps. However, if we assess the current situation, Nutra is simply “leave a request and wait for the call center to call.”
So, in different verticals, everything depends on the level of engagement of the users who install the app. If engagement is low, there is no point in making an extra app. When a Nutra site has one product that you simply order, that’s one story. In iGaming, a lot can be done inside the app.
If in Nutra you built, for example, a site with 10, 20 or 30 offers, “closed” leads with push notifications for the offers and wrapped it all up nicely inside, apps would play with new colours.
App development: how hard is it, how long does it take, and what does it depend on? Where are apps placed — from creation until traffic starts running on them? How does development happen at all?
Let’s go through what development consists of and how everything happens. The first step is choosing a design. You analyze the market and different offers; for example, study which games are popular in offers. If you look at the top casino games, you’ll see Egypt, Zeus or fruits everywhere. That’s how the first layer appears: you decide, for example, to make the app’s design themed around slots with Zeus.
The second stage is developing the stub. Usually in teams, stubs and WebView apps are made by different people. In very large teams, there is a separate staff for white pages and white apps, as well as separate testers. The structure is simple: a white stub is created — not in a casino theme, but, for example, “Tic-Tac-Toe” or Flappy Bird. It is an ordinary app that Google can’t find fault with. By this point you already have a farmed Google developer account — with a console purchased through Google Pay, a linked card and documents. The white app is uploaded to this account, and meanwhile you prepare the WebView itself.
What does WebView consist of? It is a stub already in a casino style. You can take the white app you made for moderation and rework it into the design you liked — Zeus, Egypt and so on. Then the WebView itself is stitched into this stub with all the SDKs, pushes and extra “filling.” The filling is needed for traffic tracking: so it doesn’t get lost across the whole structure, so tags work, and also the cloak, which, at the stage of the active app on the market, will tell bots and moderators apart from target traffic.
When the white app has passed moderation, you upload the WebView with the stub. Then you wait for moderation to pass, then another day or two — and you can gradually start running traffic.
How much time roughly passes from the start of development to running traffic? After all, there are apps that drop out 2–3 days after launch.
The first stage — account farming — takes from 4–5 days to a week. There are also harder cases with long moderation and several approvals — then it can stretch to a week and a half. The second stage is, in fact, moderation of the white app. Officially, Google’s documentation states that it can take up to 7 days.
The guys have had cases where apps reached the market in 1–3 days. But if you go by the documentation, it’s 7 days for the white app, another 7 for the WebView app and 7 for farming — 3 weeks in total. If everything goes smoothly, it takes about 2.5 weeks for one app to come out.
Ready-made apps are rented out to anyone who wants to run traffic. Why is this done, and why not run traffic on your own apps? How does renting work at all?
There have been quite a few cases on the market where guys took apps directly from freelance developers who knew how to create them and could upload an app to the market. You text that you want to buy an app, transfer the money, they give you some access — and disappear. Such developers or sellers don’t explain to clients what the product is and how to work with it. That’s a bit incompetent, but there really are many such examples. I advise being very careful: don’t buy an app if you don’t know the person personally or your friends don’t know them. After all, it’s much simpler to rent an app.
All the difficulties that await you with a purchased app are taken on by the lessors. Why is renting better? For example, you may not know how push notifications work. In rented apps, they are already set up for different geos and different events — say, registration and repeat deposit go by default, if the developers set that up. Large companies that rent out apps usually do this in advance.
The second aspect is setting up the deep link and naming. They will tell and show you how to do it, set it up and connect it. If you don’t have a tracker, you can do this directly through the admin panel. For example, when you don’t have a third-party server tracker where you could set things up and track everything yourself.
In general, there is a system that reduces all this to a single company. Inside it, you simply set up a rotator that distributes your traffic the way you need.
To sum up: companies that rent out apps have already worked through all the wishes of webmasters. They have experience and focus on refining smaller details rather than on connecting elementary tracking, pushes and so on. They solve all current issues for you. All that’s left is to pay for installs, take the naming and deep link, and launch traffic. This works with One Apps too — with us, it is safe to rent apps for running traffic.
There are many traffic sources. What should you pay attention to when choosing an app if you run traffic from Google, for example?
Let’s first consider the criteria for Google, that is, for Google App Campaigns. How these campaigns generally work has already been described, so I won’t repeat myself. The app must be at least 16+, ideally 18+, and definitely in the “casino/iGaming” category. Why is that? In these campaigns you can’t set up any targeting at all: you can only specify the country and launch the ad campaign. If the app’s rating is 12+, then an audience of 12-year-olds will come from YouTube, meaning children and teenagers under 18 will end up in the pool of the audience that will download the app.
Is there any optimization from Google so that the app ranks in the right vertical?
Optimization in Google happens at the level of conversion setup — by install, target registration and deposit. All of this is set up when launching the ad campaign. The first step of launching Google App Campaigns is accepting the link, that is, the account share. The second is importing conversions. The third is adding these conversions and configuring them. The fourth is setting up the campaign itself: creatives, headlines, texts — and launching it.
What can be said about AppsFlyer?
AppsFlyer works as a layer between WebView and traffic. It is a service that lets you set up and connect a WebView app directly with the traffic sources on which ads are launched: Facebook, Google, TikTok and other integrated sources. It’s like Keitaro, but on the app side: the app is linked to AppsFlyer, and then you can integrate with traffic sources.
How and from whom is it better to get an app: from an intermediary or directly from a developer? How popular is that, and does it make sense at all?
If you just run traffic on Facebook, you don’t need to buy an app. Buying makes sense only in these cases: you work with a traffic source such as ASO; or you have traffic from Google App Campaigns and want all the organic traffic only on your side; or you simply have your own traffic sources to which you want to launch the app.
Tips for the buyer: by what criteria should you select an app in general?
If it’s Google App Campaigns — 18+, the “casino” category is required, and AppsFlyer that has already had traffic run through it.
The problem of an AppsFlyer without traffic run through it exists not with all app developers and services. When setting up a new app, the AppsFlyer conversions (events, install, registration and deposit) must be pulled through to the ad campaign in Google. For that, you need to run 50–100 test installs so that the events in AppsFlyer itself are recorded and pulled into Google. Usually all this is done on the developers’ side: they can pass a postback in their apps themselves and fire these target events.
How should you choose apps for Facebook? What should you pay special attention to?
First of all, look at the app’s design: what it represents and what the Android version looks like, as well as when the app was released. The date is needed purely for your internal analytics: if the app has been on the market for a week, you can try launching on it.
A few words about iGaming designs — those that clients on Facebook associate with games. A person taps “install the app,” sees a creative, for example, Egypt or Zeus, and recognizes the game, say Gates of Olympus.
When everything is set up harmoniously, the first interaction is the creative, the second is the app, the third is the offer, the fourth is the target actions that can deliver great numbers. At every step, it’s worth tracking these dependencies and the expectations of the person who downloads the app and reaches the end goal: the user shouldn’t feel a break between the first and last “touches.”
This is already a matter of a serious approach to launching traffic. Someone who carefully checks the app, design, Android version, release date, updates, reviews and ratings usually achieves their goals.
So, sometimes traffic is wasted if you don’t keep track of certain criteria and parameters of apps. The market is seeing mass bans of apps. What are they linked to?
This is a constant story. It’s rare for apps to go 2–3 months without being banned. It’s the usual Google “storm”: it starts mass-removing apps with identical designs and categories from the Play Market.
We are currently testing one theory about bans. Imagine: four teams release 3–4 similar apps each within a short time. Only the apps of one of the teams are removed immediately; a week later another’s; a week after that a third’s. We know Google starts looking at these apps and sees that on the first day they have no installs, and on the third day already 5–6 thousand, even though they have no ads. There is an instant boost of installs. Developers work faster than Google: they release apps sooner than it can track and immediately remove them for violations. But the day comes when it identifies all the team’s apps and starts taking them down from the Play Market. However, this is still just a theory that we are testing.
Different versions of apps exist on the market: there was a period when PWAs appeared quickly and disappeared just as quickly. And then they came back into fashion. And also — what is the difference between PWA and WebView?
In general, you can learn about how PWAs and WebView work here — their features, advantages, and potential limitations are compared in detail.
A PWA (progressive web app) works like this: a site is created — a copy of the Play Market — you make an app and wrap everything so that an APK is downloaded to the person’s phone; they open this APK — and the WebView opens. A PWA is launched on a link, while ordinary WebView apps are launched as apps.
It’s hard to say that PWAs have any problems on the market with conversion or anything else. There are teams that work only with PWAs, and everything is great for them; there are also those for whom PWAs didn’t work out at all, and they work only with apps. Everything needs an approach. Many think it’s enough to put a direct link to the landing page you run traffic from, forgetting about numerous nuances. Besides, when a user sees that it’s not a real app and something in it doesn’t work, they may simply leave.
Today there are PWA builders in which you can set how much the app weighs — for example, 10, 20 or 30 MB, set a rating and reviews, a translation of reviews and of the app itself if you run on multi-geo. That is, the PWA creation system is so well thought out that a person without technical knowledge can create an app in an hour and launch ads on it. Only one question remains: do you know how to work with PWAs? If you have always launched on a link and suddenly switch to PWA, there will be many nuances you’ll have to deal with.
What is the difference between Android and iOS apps? For example, there are fewer iOS apps on the market — what is the problem?
Making iOS apps is not difficult: you simply choose a programming language and make an ordinary stub in which the WebView is wrapped.
The problem is how to work with them next. First, there is the account, which can sit up to 30 days on farming. Second, after farming, you need to upload a white app to the account, and ordinary “Tic-Tac-Toe” doesn’t pass — it has to be “Tic-Tac-Toe” with animation and bonuses. It has to be a game that will live on the account for a long time, and therefore the app that ads run on will live for a long time too.
Third, when you make the WebView app after the white one passes moderation, its design must not be iGaming-themed. It should be dragons, candies, pirates — that is, nothing that could be an extra trigger for the app in the App Store.
Is it true that iOS development is more expensive?
Yes, and that’s logical. Both development and the account are more expensive, and if you count all the small elements — even the design. But in the end, there is little iOS on the market because there is no understanding of how to work with it so that it brings satisfaction. However, I know 3–4 teams that work with iOS apps.
The main problem is when you want to launch Facebook ads for an iOS app: the account share has a limit of 9 slots per account. It can’t be expanded — it’s 9 slots for the whole market per app. You can share one account, because the other 8 slots will be given by the developers to other teams that will run traffic. On Android, for example, an unlimited number of slots can be made on Facebook. And for iOS, you need to find 9 top teams that will squeeze the maximum out of the app during its short lifespan. iOS is a big market: Ukraine, as well as Europe. There are Tier-3 countries where Android still dominates, and you shouldn’t run iOS there.
