According to this
https://support.google.com/firebase/answer/6317485?hl=en
in_app_purchase event will be automatically tracked when a user completes an in-app purchase.
The problem occurs with test users.
They are not charged (since they are entered in "Test Accounts" list in google developer console) but in_app_purchase events are tracked for them too.
So, there are discrepancies between analytics and real payments.
Is there a way to separate somehow real and 'test' purchases?
Either, maybe a way to disable automatically tracking for certain events and send them manually? And how to recognize 'test' purchases in this case at runtime (in order to don't send in_app_purchase event)
I know it's a bit late, but putting down my 2-cents here:
I think you might already know that test purchases for Android in Firebase Analytics are accounted for, as mentioned here(see in_app_purchases), "Note: paid app-purchase revenue, subscription revenue (Android only), and refunds are not automatically tracked. Your reported revenue may differ from the values you see in the Google Play Developer Console. Events that are flagged as being invalid or as sandbox (test) are ignored. Only iOS events are flagged as sandbox".
That said, there isn't a way to recognize such purchases at runtime and avoid them from being reported for Android and populating your prod app data. However, there are only a couple of ways to deal with it currently(in my opinion):
Separate your prod data from test data: Look into this document on how to set up a separate app in Firebase to record your test data.
Disable collection of analytics for your test app: As shown here, you can temporarily or permanently disable collection of Firebase Analytics data. It includes the option to be able to disable and enable it at runtime.
Although, I would consider option #2 a little counter-intuitive given your case and go with #1 instead.
Disabling reporting of test purchase data to Analytics at runtime would require 2 things:
Knowledge of how the Google Play system recognizes a test purchase, what event is sent from the user device for such an event, and the ability to recognize/intercept that event.
The option of preventing an event from being reported to Firebase Analytics at runtime.
In this case, #2 definitely does not seem like an option currently. Hence, all we can do here is reach out to Firebase Support and request that feature. But until then, I don't see another way. But I'm curious and open to suggestions if somebody else has. :)
Related
I have an Android app that has several features available as in-app purchases. We have published the app on both Google Play and the Amazon App Store. We need to stop offering one of the features as of a certain date. However, customers who have already purchased the feature should be able to use it past that date, even if they install the app on a new device. They should also still be able to purchase other features.
I was thinking that we could simply update our app so that the UI offered no option for purchasing the feature in question. However, that would not prevent a user with an older version of the app from purchasing the feature. So it seems like in addition to removing the feature purchase logic from the app (but not the feature itself), we need to do something to turn off the purchase at the store end. But whatever that something is, it must still allow the app to check whether the user had previously purchased the feature.
I've been unable to figure out from the Google Play or Amazon App Store documentation how to set this up. My understanding, from what I've read, is that removing the item (from either store) will cause checks for previous purchases to fail. Is it possible to do what I've described? We need solutions for both stores.
P.S. I did find one related question on SO: Are Google Play in-app purchases still valid if the app or the product is removed? However, it has no answer and also is a little too narrowly framed. (I'm not assuming that the product has to be removed and I also need to know about the Amazon store.)
I was thinking that we could simply update our app so that the UI
offered no option for purchasing the feature in question. However,
that would not prevent a user with an older version of the app from
purchasing the feature. So it seems like in addition to removing the
feature purchase logic from the app (but not the feature itself), we
need to do something to turn off the purchase at the store end.
For Amazon Appstore, you would need to contact their support team to get the in-app item in question suppressed (it's not a self-service as of today). Once suppressed, that in-app item would no longer be purchasable. It would not affect existing users who purchased that item in the past.
When it comes to in-app purchase I always opt for implementing everything in my own server. when a user buys something, I instantly consume it and notify my server. Then instead of querying Google or Amazon, I query my own server which gives me a lot of flexibility. If I face something like your problem I just add few lines of code!
Since you already published your app this may not work for you unless you willing to force users to update the app to the newer version. (Hoping you can do that!)
You mentioned that you don't know what happens if you deactivate the product and there is no documentation, well you can try it on a test project and see what happens! It shouldn't be that hard. If that doesn't work as you expect there is nothing you can do, your logic is in your app and it's already published so...
I am developing an Android App.
I fire a Google Analytics event when a purchase has been made successfully.
If I compare the Google Play Developer console data with the Google Analytics data, I see a huge difference between them. I mean there are like 40 or 50 events related to successful purchases (for a lot of different type of items), and in the Google play console I don't see them (only 2 or 3 items).
Do you know if the same Google Analytics event can be fired multiple times ?
Is there any possibility my Java code calls the callback function
OnSuccess function of a purchase multiple times (i am using SDKBOX
plugin for cocos2d-x), when a purchase is made?
Notice that I see GA events for items that I have never sold.
Many thanks
My last doubt is the apps that hacks for in-app purchases are sufficiently popular that they could be the reason...
I am not sure and its just a guess. May be your users are using some illegal means to buy in-apps like root or jailbreak.
We're using Firebase Analytics to track our Android app.
We've connected it to our Google Play account in hopes to receive the automatic in_app_purchase events. What we later realized is that does not support in-app subscriptions: https://support.google.com/firebase/answer/6317485?hl=en
How do we track subscription revenue events?
We thought about using the ecommerce_purchase event (https://support.google.com/firebase/answer/6317499?hl=en) so we could track the ARPU, ARPPU and LTV of our users.
The problem we are facing is dealing with subscription recurrence. Should we manually send this event each month/year and stop sending once the subscription is cancelled? It seems like a error-prone hack ...
Any other ideas?
Thanks!
If you want to pursue the technique you described, from your server, you can track whether a google subscription event is active or cancelled via the subscriptions API.
If you poll this API, you should be able to determine when to send the ecommerce_purchase event to firebase.
Here is a ruby example of polling the API for Google Play. You can poll the iTunes API with a similar technique.
supscriptions are a complex thing to measure and track in app, because the app might not get the cancel/change event and therefore continue tracking on something, that does not exist anymore. This leads to corrupt and untrustworthy data.
For that reason, we implemented it as follows:
client side:
We track all creation, changes and cancelations as custom events.
server side:
whenever we charge a subscription, we track this as a "purchase" event. Therefore, the calculated life-time-value of the user is correct and we still have a workflow of all the actions, changes, ... the user made.
I can really recommend this solution, because - even though it is slightly more complex - allows you to follow the full user journey, while having correct firebase stats at the same time.
Background
My app has some in-app billing (like this one), and I wish to test it out before publishing it.
I've watched some google IO lectures and read some articles, and prepared everything.
According to what i've learnt (talked about here), all I need to do is just add my email to the test accounts, and it won't be charged.
The problem
It seems that in the developer console, the in app items cannot be activated.
I think it's because the app isn't published yet, but that's the whole point of testing - I want to test the app before publishing it...
As I've also found out, in order to test in-app billing, I have to do a lot of things to take care of for making it work, also having many restrictions and annoyances:
sign the app and upload it to the play store . if you don't use a signed app, you get this message ("This version of the application is not configured for Market Billing...") .
make credit cards be used to the devices, even if they won't cost anything.
let others do the testing instead of myself, as my account cannot be used for that. not only that, but instead of adding exactly which you wish to add, you have to create a google group and there put the people who will be able to use the app, and all will have to have a google+ account... You will also need to wait some time till the testers will be able to use in-app-billing of your app and till then they will get an error "User is not eligible for this purchase" .
because of #1, I need to have some kind of mechanism to reset the purchases, within the app itself, but i also shouldn't forget to remove/hide this features for the end users, so that they won't reset it by mistake
because of #1, if I wish to be able to debug the app, I need to change it on the manifest, and choose to debug the app within Eclipse, and also remember to uncheck this flag before actually releasing the app.
since the app is on the play store, you cannot modify in-app purchases items (their Id for example), as opposed to many thing you can modify before publishing the app. It's no longer a development as flexible as it can be using simple development. It's like your app should be sealed with what you choose even though you haven't published it yet.
The question
Why is it this way?
How come there isn't a simple way to allow to test the in-app-billing ?
How would you deal with the problems I've written about?
Is it possible to test the in-app purchases before the app is published?
How come I can't use my own google account ?
Also, suppose I do make a (fake) purchase, how do I reset it (all/specific purchases) in order to check it out again? Is it true I can't do it anywhere besides the app itself?
Am I missing anything?
you dont have to publish the app inorder to test it all you have to do is upload the apk to your developer console, just dont publish it. If your account is linked to your developer console you cannot use that account and have to create a test account to test the IAP's
You will have to public the app but publish in beta mode so that you can test the in app purchases. Beta mode will enable to test the functionality with limited user set.
Yes, you can test your app without publish (and without publish in beta mode too). There are instruction http://developer.android.com/google/play/billing/billing_testing.html#billing-testing-test. Please remember that after 1 point it's maybe need to wait about hour or two.
It seems that in the developer console, the in app items cannot be activated.
it's ok, just check that you mark it as active. It look like not active before you publish the app, but you can test it.
I can use my own google account, right?
I strongly recommended have additional account only for test purchases.
Also, suppose I do make a (fake) purchase, how do I reset it (all/specific purchases) in order to check it out again?
You'll must to fill billing information for your test account. But when you make test purchase, there are no any real money transaction. Every in-app can be tested once again after the app consume it.
I'm also working on how to test In-App-Billing for Android in best way since days.
With real transactions to me it seems to be really too complicated and a lot too much effort. So i'm currently thinking of 'only' testing this stuff with static responses (http://developer.android.com/google/play/billing/billing_testing.html#billing-testing-static).
In theory i guess once this works, it should also be fine in production as in the source code only the SKU id gets changed for live release..
I have added in-app billing to my app, and everything seems to work fine on the Android side. But the orders in Google Checkout cannot be charged, even though the status is chargeable, because the Charge Order button is disabled. Apart from this, everything about the order appears to be correct.
The same thing happens with the Dungeons sample app, so I am a bit stuck at this point.
You give very little informations about your problem.
What is the purchase type you're using ? If they are "managed per user account", then they can only be purchased once for a given user. Maybe the charge has been successful once, and is now blocked (in which case you should use "unmanaged" purchases)
Or maybe I'm totally wrong, and you should give us some additional infos.
Yes, Google will block you from charging unless your app is published or you register your self as a test user.
Test users can parches when the app is not published.
You don't use the Charge button when selling Android apps. Charging occurs automatically.
Maybe the Charge button is there for other kind of goods sold on Google Play, but for software sales it's useless, thus it's grayed.
Worth a general read: In-app Billing.
On the Google checkout side of things, one potential cause for this issue is that there is a delay period with purchases for fraud detection, etc. (source "Charge Order" button greyed out). More reading on this here: In-app billing and Google Checkout setup. It is typical for the "charge order" button to be greyed out during this period.
I'm guessing that this isn't your issue however, because it would have been resolved already. In can't press charge order button but order is chargeable one of the most relevant points is given as
#sounddoctorin: If you click the order details, you will see why - its likely the order is in some pending state "Reviewing", etc.
The point is that if you can't click the "Charge" button, it means the order is still pending for one reason or another.
For more information on charge states visit "Understanding Order States".
If this still doesn't help resolve your issue I would look into figuring out why it is misbehaving. What other data can you gather?