Note that I am not asking how to set up Adwords, I'm interested in how its attribution works.
Consider this workflow: An ad for a mobile app is shown on your mobile phone via Google search. Clicking on the ad takes you to the Apple AppStore. You purchase the app and run it. AdWords records a conversion that you can use to track your campaigns.
In order for this to work, Google requires you to add a little chunk of code to your app that calls home with some info. What I can't quite grok is how they are able to relate the ad click to the AppStore purchase. There has to be some sort of data passed around. How does this work? On the web, you'd do it with a cookie or some sort of query parameter.
Another workflow: You send a newsletter to people. They click a link in the newsletter that takes them to the Play Store ( or AppStore ). The user buys the app. How would you attribute the purchase to the newsletter?
Does anyone have any knowledge into how this works behind the scenes across multiple platforms and companies?
Related
have the following scenario:
we have an app that users need to pay for. But we also want to sell the app bundled with a book meaning there is a code / voucher in the book that can be used to use the app for free. Unfortunately we haven't found any good way to address this scenario yet:
a) make the app a paid app and use Google / iOS Promo Codes for the books - not good, because the number of promo codes per app and quarter is limited
b) make the app itself free but require users to make an in-app purchase to access most of the content. Alternatively make it possible to enter a code to access that same content. The code comes with the book and is created and maintained by us.
negatives: a lot of effort to maintain the promo codes, handle the in-app purchases and Google / Android don't like it if content within the app is paid for outside - so we could end up being rejected.
I'm really wondering: are we the first one with this need? is there maybe already a solution to this problem we are not aware of? We do not want to rip Google / Apple of their 30% share of app sales. But there doesn't seem to be a supported solution for this.
any ideas? thanks
Thomas
Welcome to SO.
This could be done but i dont know if this is the optimal solution.
Make the app free and lock down at the sign-in, there give link to your play books.
In the app check if the user has purchased the book using
https://developers.google.com/books/docs/v1/using
So if user pays for the book and downloads it, On the next app launch give access to him to use the app.
You should be careful with Apple's in-app purchase guidelines, 3.1.1:
If you want to unlock features or functionality within your app, (by
way of example: subscriptions, in-game currencies, game levels, access
to premium content, or unlocking a full version), you must use in-app
purchase. Apps may not use their own mechanisms to unlock content or
functionality, such as license keys, augmented reality markers, QR
codes, etc. Apps and their metadata may not include buttons, external
links, or other calls to action that direct customers to purchasing
mechanisms other than in-app purchase.
I think for users that purchase the book, they would need to register outside of your app (e.g. on your website). If you had some authentication system you could store a flag on the users profile if they've unlocked the book or not and give them premium access to your app upon logging in.
You can make your app free and set non-consumeable book SKU in your app.
If you want to send the promo code, you can use Google Play Console.
https://android-developers.googleblog.com/2016/01/create-promo-codes-for-your-apps-and-in.html
Google only allow a small amount of promo codes per app, 500/quarter. This is because they don't want to encourage developers to sell this promo code offline. But this is still an official feature supported by Google Play. You will be totally fine as long as you're less than 500/quarter.
I would like to know how can I avoid having the user re-pay for an in-app subscription he already purchased.
Example: I purchase an App which offers in-app purchase on google play store for 5$ and now I shift from using an Android phone to an iPhone.
I came across this post which says it's not possible as they are two different competitors and would have to re-purchase the same app on the iOS once again, but is there a way to avoid it so that the end-user does not repay the sum of 5$ again?
I was thinking if it would be a good idea to have the receipt stored on a server and then when the user enters his email just do a lookup if there's a receipt associated with that email along with some validation logic.
In theory, I could avoid the user having to pay the 5$ with this approach but at the same time, I am not sure if doing this could get my app rejected or If this could lead to some different issues OR this is not doable at all and the user will have to end up paying 5$ anyways if he shifts from android to ios and vice versa.
The approach you suggested is correct. You would store the receipt on your server, along with the user identifier. Your server is responsible for refreshing the receipt with Apple/Google to keep the status up-to-date. You can then have an endpoint to your backend to check if a user is subscribed - regardless of the platform.
This is well within the App Store Guidelines, and is how large subscription businesses like Netflix and Spotify operate.
I'd like to be able to link users in one game to users in another game such that users that unlock certain achievements in game 1 are able to receive special items in game 2. This is very similar to how Blizzard does it where buying like X in Hearthstone gives you a special mount in WoW.
I know we could manage our own account system but we're hoping there's an easy way around that.
I've been researching Google Play Games and it seems like that could be the ticket but I can't seem to figure out a good way to identify that this new user linked in Google Play Games is the same user as in Game 1. Is this something I can accomplish with the SDK? Basically wondering if playerId is unique to the game or to the player themselves and across different devices.
(another option would be using the Google Play Advertising ID, but that isn't great for users that want to enabled limited ad tracking).
developer.android.com has a whole article on user identifiers. What you've got is a hard problem. I can give you a few tips:
playerId is the same for the same user across different devices, but is different between different games. This is deliberate to prevent Ad tracking that the user didn't intend. So playerId would probably be the wrong choice.
The Advertising id is "for user profiling or ads use-cases". So I definitely wouldn't use it for this use case.
In this case, my choice would be to use something like Firebase, especially Firebase Auth to manage a very simple account system. You won't need to create your own servers or write much sign-in code as Firebase handles this, and you get sign-in with Google or Facebook for free. And once you have it, it will give you a nice flexible way to do other things in future, eg experiments or configuration with Firebase Remote Config. And it is cross-platform if you ever write an iOS version, and from Google.
I have to create an application for iOS and Android, from which I can buy some "items".
I don't understand how the in-app purchase work; can I buy and download the content I already paid for? Or can I buy just the unlocking of internal content without downloading it? If its just for unlocking internal content, is there any way to buy and download the content?
Thanks
The only thing you can't do with in-app purchase is selling actual goods - that's also allowed in case you have a website doing the same thing (eg ebay app). And there are some more rules for iOS in-app purchase.
As for the step by step idea about in-app purchase, here is a gist:
iOS app requests for SKProducts from app store (already setup via itunes connect portal by developer)
The retrieved products are displayed in the app along with localised pricing
User selects a product to buy
Purchase goes through via various steps - in-progress / success / failure. Depending upon the status, the app UI should be updated to keep the user informed.
Upon successful purchase, you can download content inside the app using your own server, or the content that's uploaded on Apple servers. You can unlock the content from within the app as well.
In a nutshell, you have a long way to go. The best way to start theoretically is to refer to In-app purchase programming guide. In addition, this book by Apple is also helpful. And for your needs, here is a sample code from Apple to begin with.
If you rather want a step by step tutorial, here is one authored by me. A rather easier one is the video lecture series with SWIFT and Objective C - prepared by me - which also accompanies code sample for SWIFT and Objective C to save time.
I am building a website for a client that is promoting an App on Kickstarter. As one of the rewards this client wants to reward sponsors with in-app purchases. I have searched Apple and posted on other forums but I can't find out if this is possible and if it is possible, how it is done.
Thanks.
You need to implement a promo-code dialog inside your app to do that, then send promo-codes to your Kickstarter users.
I don't think It's possible.
Here's the only Google documentation I could find.
You could make the app free for a short period until all backers have their copy and then raise the price but non backers will be able to download it too.
It would be possible however to use the alpha/beta functionality in the Google Play store to release the app to backers who have joined specific circles setup by you. I don't know if Google would have a problem with you using it like this.
It might be possible to distribute the app outside of the Play Store but I suspect that will become a big support problem as users struggle to get the app installed and keep it up to date.
For iOS part we haven't this functionality with Store Kit. This framework was created to securely process payments from users. You don't need to work with payments. Just deliver some product or an extra functionality to user with promo code. Implement a dialogue in your app where user can enter his code, send this code to your server, check it and give an access for user, if code was right. That's all you need. After making the product available, your app needs to make a persistent record of the "purchase" like you do with normal in-app purchases.