I have auto-renewable subscriptions in my app. These subscriptions come with 3-7 days trial (money charged only after this trial period). I didn't place any custom code for event tracking in source files, and facebook tracks all of these events just fine, except purchases. I thought that was because I've never had purchase events untill today, but today somebody subscribed, and "purchase" event still not tracked. Instead "Initiated checkout" event was tracked with value = subscription price.
Question is why it is not tracked? I am planning to create an advertising campaign with purchase events optimization in facebook, but if they are not recognized, then I can't do it.
Auto-renewable subscriptions can't be tracked by the Facebook SDK since the customer doesn't get charged in response to in-app events. Payment for your subscriptions occur after a trial conversion or on a renewal, and happen regardless of whether the user has your app open at the time.
In order to accurately track auto-renewable subscriptions in Facebook, you'll need to save the purchase receipt from Apple on your server, and periodically refresh it with the /verifyReceipt endpoint. From this response you can determine if your free trial converted or the subscription renewed, then, finally, you can track the conversion through the Facebook API from your server.
Related
We are trying now to add Facebook SDK to our android and ios applications and using received data to optimize facebook advertisment.
But now it's not clear for me how facebook analytics take account of trial, discount and renewal subscriptions.
I made some tests and it seems for me that all this subscription types just summarized like general subscriptions.
But this is not what out marketing team want see in facebook analytics.
Is it important for them see trial subscription as 0 on the profit chart at trial period and as full price after trial period.
And same situation for discount subscriptions.
Are my assumptions correct?
Or do I have to send subscriptions purchase events some other way to get necessary results?
I'm creating a Mac app that has a non-renewing subscription as an in-app purchase. I want to sync this data to the cloud for the following reasons:
I want the user to be able to use the app on all their Macs
The in-app purchase enables a widget, so that widget needs to access this data.
By Apple's documentation the restoration of non-renewing subscriptions has to be handled by the app by some kind of registration / cloud sync.
So I decided to implement a CloudKit sync to store the following data:
Which IAP product did the user purchase (currently only one value, but might change in the future)
When did the purchase occur.
Here's what I'm doing now when a user makes an in-app purchase:
I validate the receipt
If I find any IAP data, I sync that to CloudKit
I use a function to fetch the purchase data from CloudKit for the said widget
Question 1: As far as I can tell all the in-app purchases are contained in the receipt file, even after removing and restoring it. I could be using this, however the documentation clearly says I shouldn't. Even the forums are not certain about it... What do you think?
Question 2: While testing the app with multiple sandbox users I noticed that no matter which sandbox user I use to make the purchase, the currently logged in iCloud account (my personal account) gets the receipt data synced to CloudKit. Why isn't the purchaser (App Store) user getting the data to their private cloud database? How can I test that everything works fine? Do I have to log out of my iCloud account to make this work?
Thank you for your time :)
Question 1: Using the App Receipt to restore non-renewable subscriptions
From Apple's Documentation:
Apple's documentation on whether an in-app purchase of a non-renewing subscription remains in the receipt has contradictory answers:
Yes (retrieved 2016-05-11):
Table 1-2 Comparison of subscription types
Subscription type Auto-renewable Non-renewing Free
Users can buy Multiple times Multiple times Once
Appears in the receipt Always Always Always
Synced across devices By the system By your app By the system
Restored By the system By your app By the system
No (retrieved 2016-05-11):
The in-app purchase receipt for a consumable product or non-renewing subscription is added to the receipt when the purchase is made. It is kept in the receipt until your app finishes that transaction. After that point, it is removed from the receipt the next time the receipt is updated—for example, when the user makes another purchase or if your app explicitly refreshes the receipt.
From Apple's Developer Forums:
In a thread reporting the temporary (now fixed) loss of non-renewable subscriptions from the app receipt, an Apple Developer Technical Support engineer said:
I've queried the iTunes Production Support engineer who made the change - The "fix" to provide the history of non-renewing subscriptions in the application receipt is permanent. My interpretation is that permament means that if we make a change, we'll announce the change at a Developer Conference and announce the function to be deprecated for a period of time.
With regards to using iCloud as a means to restore non-renewing subscriptions, I've heard from my App Review contact - an application "can use iCloud to track the non-renewing subscriptions (NRS) but it can’t force the user to login prior to making the purchase. It has to be optional - that can can alert the user that iCloud is required to access the NRS content from their other iOS devices - and providing a way to register later, if users wish to have access to this content at a later time."
Source: https://forums.developer.apple.com/thread/22345#79067
You could attempt refreshing the app receipt to restore the non-renewable subscriptions, but it has broken before, the documentation isn't clear, and there have been past reports of App Review rejecting applications that try this method.
Question 2:
CloudKit always uses the current iCloud account under Settings > iCloud.
App Store purchases use the Apple ID configured in Settings > iTunes & App Store.
The user may be signed into the same Apple ID for both iCloud & iTunes, but there is no guarantee. These are two entirely separate settings.
In iTunes Connect it is possible to give a free trial period for autorenewable subscriptions.
App > Manage In App Purchases > Subscription Basic > 1 Month > Offer a free trial?
How can I get this information on the client? SKProduct does not have any information about this as I can see. Since we're having a marketing campaign it is very confusing for the end user to not see information about the product has a trial period.
Of course it is possible to fetch this kind of information from a server I maintain, but then we'll have the overhead with updating both our server and iTunes Connect. So I don't accept this kind of answer unless it is wired up to retrieving that trial period information from Apple's services.
TLDR; It is not possible. You need to manage this information yourself.
When you process an SKPayment you get back a receipt. You should verify those receipts regularly for subscriptions (e.g. before downloading new content) as the user might have cancelled the subscription. When the user does cancel the subscription or the subscription expires you get back a descriptive error when verifying the purchase's receipt.
Moreover the receipt gives you all the information you need: for a given product you know which trial period you grant. Therefore when a purchase is made you could store the purchase date given from the purchase receipt in your model object or in the NSUserDefaults or in the Keychain alongside the purchase data. At this point you know when the trial is expired and verify that the subscription is still valid. If you can't you might want to disable access to the content until you're able to do so.
For more informations about purchase receipts and subscriptions check out the In-App Purchase Guide by Apple.
On the client side you usually identify the different products and characteristics by their product identifier as the App Store does not deliver certain information such as subscription period and free trial period.
So if your product ID is for example:
com.domain.app.product_paid1month_free7days you split the ID on the client side and know that the paid subscription duration is 1 month and the product has a free trial period of 7 days.
Of course one approach would be to transmit the product ID to your own server to get its characteristics as response. This way you can maintain the product list continuously without updating the binary and across versions.
SKProduct > introductoryPrice
Available since iOS 11.2
https://developer.apple.com/documentation/storekit/skproduct/2936878-introductoryprice?language=objc
I have an iPhone/iPad application that offers a monthly subscription to a service. Although, this service is totally useless during 2 months in the whole year.
Is there any way to either suspend all my users subscription for 2 months, or give them a 2 months refund every year so they don't pay for a useless service ?
After a good talk with an Apple employee, it is not possible to suspend an auto-renewable product.
Also, 0$ subscriptions do not exist outside NewsStand apps for the moment.
In order to solve our problem, we will have to delete the in-app product in iTunes Connect. This will automatically cancel all active subscriptions we have so the users will not be charged for nothing.
A big downside to this solution is that we will lose all current subscribers, so next year we have to build up a new subscriber bank from scratch.
Maybe you can give two months for free to your users instead of refund them.
Have you found any better alternative, since posting your answer about canceling all subscribers every year?
In addition to 1-year subscriptions, apple lets you do other terms as well, including 1-month subscriptions, for both renewable and non-renewable subscriptions.
Maybe you could make your in-app UI look as if the user is signing up for a long-term subscription, but behind the scenes, your app only sends a 1-month non-renewable subscription request to apple. Then, each month, your app automatically requests another 1-month subscription, and another... just skip the months you want to skip.
The user fills out the subscription form in your UI 1 time. Your app logic remembers how many times to start a new 1-month subscription.
In the this Article Apple wrote how to enable an auto-renewing subscription from the users point of view. But my question is how to handle this auto-renewing subscription as the developer of an app?
In my app (currently in developing) the user can buy some subscriptions (30 days, 3 months and 1 year) via in-app-purchase. After a successful payment I send the bought item identifier to my server to save the new subscription time (also used for other platforms). This works perfectly in the sandbox-environment.
But if I correctly understand the article the auto-renewing subscriptions is performed from inside the AppStore and inside my app. How can I now track the subscription?
If a subscription is autorenewed, the transaction won't pass the paymentQueue:updateTransactions method. The renew just happens on the Store.
If you want to test for it you have to either:
Revalidate the receipt on your application server, if you store the receipt there.
Revalidate the receipt on your iOS client
See: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html#//apple_ref/doc/uid/TP40008267-CH104-SW1
In order to avoid testing for an autorenew each launch/activation you should store the endDate of the subscription period to test for a renew afterwards.
Also see: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html#//apple_ref/doc/uid/TP40008267-CH4-SW4
However, there seems to be a bug in the sandbox. Subscriptions sometimes get renewed, sometimes not. Hard to test....
based on the (rather scant) info found in apple's in-app-purchase documentation, my impression is that whenever you need to determine the state of a user's auto-renewal subscription, you would restore their transactions.
this would cause the app store to send all auto-renewal transactions to your app, at which point you would process the receipts and make the appropriate content available.
presumably, you would only need to do this when the user's current subscription (which you can track locally) is set to expire, or when they are first installing the app.