Does anyone know why are users with older app version which doesn't have new experiment in config counted as part of experiment? This is scenario:
I have app version 1 with experiment A with activation event for new users new_install
Then I create app version 2 and new experiment B with same activation event for new users new_install . I start experiment on firebase console.
Now I am waiting for app to be approved by apple appstore or starting rollout on android. Even before any user gets app version 2 I already see many users showing in experiment B on firebase console.
I would expect that users with app version 1 will be not part of experiment because remote config doesn't have default value for experiment B in app version 1 but it seems that because users are still installing app version 1 and new_install event is fired, they are counted as part of experiment B event when it's not in app version 1.
Is it feature? Bug? I am supposed to create custom activation event for every experiment?
That's actually easy to prevent - and good practice for A/B testing in general - just target users with at least given app version. Usually it will be version since you have remote config properly set up.
I would not rely on Firebase including or excluding users if they don't have remote config parameter. Today it might work differently than how it's going to work in a month. If there is no guarantee, just make sure you are targeting users who are properly set up.
Related
I'm running Facebook Ads campaigns for my iOS app and quite naturally I have Facebook Analytics SDK integrated inside my app to track App Installs and Start Trial events to measure the "quality" of the traffic my campaigns bring.
At the Analytics settings page inside Facebook developer dashboard.
https://developers.facebook.com/apps/XXX_APP_ID_XXX/analytics/settings/?business_id=XXX_BUSINESS_ID_XXX
I have the option Log In-App Events Automatically (Recommended) set to "Yes", which I presume enables the tracking of App Install and Start Trial events. There's also a Shared App Secret field filled in with the value from iTunesConnect.
Indeed, the App Install and Start Trial events have started to appear inside Analytics dashboard
https://www.facebook.com/analytics/XXX_APP_ID_XXX/AppEvents?__aref_src=landing_page&__aref_id=entity_name&force_desktop=1&user_id=XXX_USER_ID_XXX
However I noticed when viewing the stats for just App Installs there's a quite considerable value in USD attributed to these events. I decided to take a closer look into these events using Event Debugging
https://www.facebook.com/analytics/XXX_APP_ID_XXX/most_recent?since=1577923200000&until=1580256000000&__aref_src=landing_page&__aref_id=entity_name&force_desktop=1&user_id=XXX_USER_ID_XXX
and selecting "App Install" in the events filter.
There I saw that some (only some and as if randomly) App Installs have a value associated with them. To me this is an unexpected behavior since I can't imagine revenue being made by just receiving an install.
Same goes for Start Trial event, which always has the value associated to it (equal to the sale price of a subscription period) and once again this makes no sense to me because started trials themselves bring no value to me. They may be canceled or may end up in Billing Retry when the user has no money on the bank card attached to their iTunes account, etc. I track the conversions from Start Trial to Purchase on my backend separately with great precision and only these conversions as well as subsequent renewals would bring real value to my business.
I can and will track these Purchases manually and post them to Facebook (server-to-server style) and I will supply the corresponding value to these events myself, which will help to understand the overall performance and ROI but I need to clean my stats from these "false" automatically and erroneously attributed values to App Install and Start Trial events first.
I've already reported this issue to Facebook few days ago, however they seem to be slow in handling such requests so I've decided to ask here if anybody ran into similar issue.
Add this to your plist file to disable Auto Event Logging
<key>FacebookAutoLogAppEventsEnabled</key>
<false/>
Thanks to Lena Bru for giving enough food to find a solution.
The Facebook documentation is scarce on the raised questions and the support answer literally headed me towards the documentation. To recap things, there were 2 main issues (the second one I've mentioned in the comments to Lena's reply):
Facebook was tracking value for the events, which brought no value to my business
Some of the events I've sent from backend didn't appear in the campaign reports
To solve both of these problems, I:
Turned off the value tracking option in the Facebook app settings
On the client side I've started setting up User ID (which the client receives from backend) according to Facebook documentation
I've started to send all of the events, which I wanted to view inside Facebook business cabinet, under custom names from backend. I've supplemented them with app_user_id parameter (see Advanced Matching for App Events in Facebook documentation) so that they could match the App Installs reported from client.
There's still a smaller issue left (it feels like Facebook reports include 20% less installs than actually happening) but the current setup is already something to begin with.
I am creating a weather app and want to give local warnings to people through an app. I want to be able to give up to date warnings, but I am wondering: does updating information in Xcode get automatically pushed to the devices or will it need an update every time I put new information in?
If I understand your question correctly - you have an app, which warns people about some unexpected weather conditions?
You basically have two options:
Do a code push to your app every time you do a change. This is not supported by default in Swift and Xcode, and can only be done via some third-party integration or framework (e.g. React Native), and is generally a hard thing to implement.
Setup a back-end server and link it with your app, so the new information is downloaded from this back-end server dynamically.
The only suitable and easy thing to do for your use case seems to be option 2.
i have an ionic android mobile app which connects to a ruby on rails api server
and this app uses postgresql as database server.
whenever i create a new feature i deploy both, the api and the new app to the app store and bump the respective versions of api and the app, which have their own version numbering sequence.
The api is deployed to the server but app's on users devices are not frequently updated so below 2 cases arise for me
Case 1 : New columns additions
Issue happens for a release when for e.g i have few new columns added to certain tables in db to capture additional info for which respective text fields have also been added to the app's UI.
Here users of the newer version of app will work as expected (send those 2 info to columns) but the older versions will not be sending those 2 field values
Case 2: Columns deleted
for instance i am re-architecting the app in a major way and have to normalized the database as it was inefficient earlier which even leads to breaking of tables etc or deletion of a couple of columns.
Here the older versions of app would simply crash or fail to work.
i feel every business app i build will have this same scenario to manage and it should be common issue to all
I am in the process of writing some custom logic where the app would check when connected to api server for a "update flag" and if the app's version is set to
be force updated to make it work with api version then the app would be redirected to play/ app store.
i would like to know how everyone handle this problem and am i doing the right way.
Is there any rails plugin or library which already takes care of this particular problem
or helps in doing so.
i know there are lot of versioning gems available but they dont take care of this issue [force updating app]
Please guide
I've worked on a project where an API for configuration was called on the Android App Startup. This API would provide 2 fields: major_version and minor_version. If the major_version from the configuration API did not match the one on the App, there would be a popup asking you to force update the App. This would be on the Start-up Screen, so you won't be able to access the actual contents of the App unless you force update your app. If you do not want a force update between 2 app versions or 2 API versions, you have the option of tweaking the minor_version.
this is my first ios app. am working on a version 1 that i'm planning on giving to few of my customers. customers will get it from app store. in future, if i have new version that i'd like to notify current users, is there anything that I have to put in version 1?
thanks.
Yes, you will need to put something in version 1 in order to do this if you want some kind of notification in the app itself. You can go about it a few different routes depending on how complex you want it to be:
You could add push notifications to your app, so that you can send a push notification to your users letting them know an upgrade is available. You would probably only want to do this if you used the push notifications for other purposes as well, as users probably wouldn't want to allow push notifications for an app to only inform them of app updates.
You could have your app check with your server upon app launch to see if there's an update available. You could simply have a file on your server that the app checks which can contain the version number of the most up to date app you have available. If the server reports a newer version than the version reported by the app, it can display a message, which could also be contained on your server to be configurable. This would be pretty simple to implement, and could possibly contain other configuration information for your app. You could also choose when to show the prompt, in case you don't want to bug users for some updates but do for others. This would be good to do if you might release an update that requires users upgrade in order to continue to have it work with a backend server.
You can also get your app to check directly with Apple to see if a newer version of the app is available on the app store. You should be able to find a resource that will instruct you how to do this. Going this route, as soon as an update is available it will start bugging users to upgrade, so you may not want to do this if you only want to push some updates on your users but not others.
You can do nothing. On iOS 7 by default app updates get automatically installed, and even if they have that disabled, the user can see what app updates are available in their app store app. This is what most apps do, aka they don't bug the user every time an update is available. And if somebody isn't updating their apps anyway, your prompt won't necessarily encourage them to do it either.
It's similar to the message appearing in Chrome when a new version is available - something like "Chrome has just got better".
Presuming that you have a server side counterpart, my approach would be the following:
store the latest version number of your app somewhere on the server (database, configuration file, etc)
implement an API at server side that, upon an app version provided as parameter, returns true if an update is available
in your app, read the current app version (see this SO answer)
call the remote API mentioned in (2), and act accordingly if the return value is true
Note however that appstore notifies the user when an update is available - but that doesn't happen in-app
Incrementing the app version is enough for App Store notification as explained in
iPhone app Update Vs new version
I'm considering using the CFUUIDCreate API to build a database in my server to measure what percentage of users of each of my apps are running which version of iOS (to help me make a decision on iOS minimum supported version for future development).
My question is: Should I ask the user for permission to send the (anonymous) UUID / iOS version data pair to my server, or is it OK to do it automatically?
I ask because I could bet on the safe side and ask anyway, but most users would feel intimidated by the technical details and most likely decline. Also, the longer the text in an UIAlertView, the more likely the user won't read it.
Will Apple reject my app if I don't ask? Even if they don't, do you think I should always ask the user for permission to send this anonymous data?
What's everyone's experience implementing this kind of functionality?
OK, this is what I'm going to do, based on Nikolai Ruhe's answer but improving on a pitfall I just discovered.
Suppose user John Doe installed my app on his iPhone running iOS 5.0.
On the first launch, the app sends an anonymous request to my server that effectively increases by one the counter for 'Devices running iOS 5.0'. The app records this event and the iOS version (in User Defaults or Keychain) and does not send any further requests as long as the locally stored OS version string and the current one (returned by the system) are equal.
The next week, John upgrades to iOS 5.1 and launches my app. The app detects the OS version discrepancy and sends a new request to my server.
But if this only adds one device to the 'iOS 5.1' population, John's iPhone is now being counted twice: once as "Devices running 5.0" and once as "Devices running 5.1".
So to fix this, my HTTP request should look like this:
http://myserver.com/my_stats_scripts/index.php?app_id=com.myCompany.myApp&new_os_ver=5.1&old_os_ver=5.0
So my database can increase the number of 5.1 devices and decrease the number of 5.0 devices by one.
Of course, on the first request, the HTTP parameter old_os_ver is set to empty, and the server treats it like a new device.
If I pull this right, I no longer need UUIDs. But I am still sending system info covertly to my server. I think I'll also disclose this on the Terms of Use.
You should definitely ask for permission. The crucial bit here is that your data collecting might be anonymous, yet it can be used it to track individual users.
Web browsers send a user-agent string with every request. The difference is that they do not send a universally trackable id that would never change.
So the problematic piece in your proposal is the UUID. Why not just leaving it out? Your app would send an anonymous request once and locally store the transmitted iOS version. When the user upgrades the OS, you send another request with the new iOS version and an update count.
Using this scheme you would not transmit trackable data and still get a proper usage-by-os statistic.