I need to know how many users used my app. Now what is the correct definition of how many users used my app ?. What's the difference between active users, installed users and users who have used the app.
For example look at this graph i have attached. There are three numbers i am looking New installs (6554), Lifetime installed users(5431) and monthly active users(Highest at 17k+). What's the difference ? And what should be the answer when my question is how many users used my app ?
Here's an explanation of the different figures:
New installs - How many users have installed your app in a certain time period.
Lifetime Installed Users - How many users have ever installed your app (up to a certain point in time which is indicated when you hover on the ? beside the label).
Monthly/Daily/Weekly Active Users - How many users have actively used your app in a certain time period
It's your choice which of those figures you want to use to say how many 'use' your app, but DAU/WAU/MAU are probably the most honest in terms of real, actual users.
Related
I have a cool flutter app which is used to track staff attendance. A user can check-in and check out when they start/stop working and the app record that event, calculate the number of hours worked and send a weekly summary to the manager of the staff expected wages. The current problem is that some staff members forget to check out (everyone is ok with check-in) so we don’t have good numbers and we need to manually change the attendance. I would like to add something to remember them to check out, and I am looking for creative ideas to do so. My objective is to make something very affordable.
So far I thought about two options:
to use geolocation and track when staff get in/out of a certain location and log it as check-in and check out
to set a timer when they start the shift and send a local notification if after xx hours they have not done the checkout
Geolocation seems to be the best because I can even automate the checkin/check out and do it in the backend but it will consme lots of resources in the client because I would need to check their location every while even when their at at home or on holiday...
The timer has some limits and still, I would need to manage background tasks that are complex as well as imprecise checkout depengin on when the notification goes out.
Do you have any suggestions on anything simple to implement?
I would suggest the second option.
A simple scheduler which would look for all the employees who are checked in for more than x number of hours and then throw a clickable notification to checkout. It would be an easy and clean solution. However, it has several limitations as an employee might leave early but checkout later.
In my opinion, Your most clean solution would be to have an RFID/NFC check which automatically registers as a user checks out from the building.
Another thing that can be done if your employees are working mostly on their computers. There can be a browser extension or a web app which will clock in the time they are working on their laptops. Once they close it they will be automatically checked out.
I am currently developing an app for a company that is in a very competitive field. I have finished all of the features of the app that they requested except for one, making it somehow protected from their competing companies to download and use. I thought that I could set up a UIViewController with a password field that would check against some kind of database, but I'm not sure how to do the checking against a database part nor the practicality of it, and was hoping I could get some ideas on how to do this so that other companies couldn't steal and use this app without a password or something that changes like every 30 days or something and is kind of like an activation code.
Review the WWDC 2012 video "Building and Distributing Custom B2B Apps for iOS". I'm unsure if your app is in this B2B classification, it seems that it might be from your description.
What I ended up doing (if everyone needs a reference) was setting up a server with an SQL table that has pass codes in it. Since apple does not allow for any sort of system that requires you to "buy the app from outside the app store" I made a dumby username field (shame on me) that takes any value you like and then requires to have a pass code that fits. Once the pass code gets authenticated with the web server in a json sql request (there are plenty of api's to do this with) it comes back and sends the user to the first screen and sets a value in a plist with how many days of use the user has left. Whenever the user opens up the app it checks to see if the date is different from the last date logged in (saved in the same plist file) and if it is different then it calculates the difference and deducts that many. When the count reaches 0 it sends the user to the pass code authentication screen again. A bit complicated but an effective method of getting around Apple's restriction on not having a sort of pass code system like this. Thanks for the answers, unfortunately enterprise did not work for this company since they needed to be able to distribute the app to as many 3rd party members as they wanted to without having to worry about them leaving the company for other suppliers and remote management of the app (I.e ability to remote uninstall) was also not an option. Hope this helps someone someday!
So as to avoid overwhelming the infrastructure in a web application instance, what would be the methods of implementing a feature roll out to a controlled group of your user-base?
It depends on the situation. You can't really redirect them to another site using another database if the users are expecting to work with real data and the real site.
I would introduce a flag on your users in your user-table, let's say isBetaUser (bool). Then you can just show these new features for users that got this flag set to True. You could also let them check this flag off using a checkbox through some settings page, if they don't like the idea of trying out new features that is.
Partition your users into groups. Randomly. Demographically. Somehow.
Pick one or more groups for a pilot.
Fix your web site to have both versions of your app running. Maybe use virtual hosting or a different path or something.
One database. Two applications. Data doesn't move. Only the presentation changes.
At first, all users are in the old version. Workload has not changed.
Move a group of users so that their default URL's or links or menus or whatever are references to the new application.
Same workload. Same database. Same number of users. Two applications.
Move another group of users to the new application.
Same workload. Same database. Same number of users. Two applications.
Eventually, after all users are moved, you can delete the old application.
I have current a developed app which I am going to submit in just few days .
Currently The Application shows data by calling a web service and fetches data from a server .
Now client requirement is to build two different databases.
So the question is should I make two different builds for two different countries or should I make alternative call to the web services based on the format region selected in the iPhone .
e.g, if ( country == uk ) then
call uk_Service;
else if( country == us ) then
call us_Service;
Please tell me which approach is better. And also if should I make two different builds then can I submit both of them at a time in the AppStore .
Thanks
I don't think it is a good idea to have two different builds for the App Store. This would mean that you have to do all the organisatorial overhead in iTunes Connect twice. For example an update with all the screen shots and textual descriptions have to be submitted twice. Also you do not have a chance to ensure the release of both submissions will be synchronous.
Why don't you provide a setting to the user where he can choose the country he wants to use your app for?
I would go with the if/else option purely because maintaining 2 apps instead of one will be more work - eg when you want to fix a bug you'll have to do it twice over. Another advantage of using the localised version is that a user can change their localisation and start using the correct database - eg they buy the app in the US and then move to the UK, change their settings and can start using the UK database without a problem
Let's say that I have an application that helps people "manage" a certain number of "items". Normally they'd have to manage information about these items on paper, but my application will let them do it on the phone.
I want to sell my application by the number of items it supports. For example, I might charge $10 for the version that has a limit of 20 items, and $15 for the version that lets you manage 40 items.
What's the best way to do this? Ideally I'd like to let users download the application for free as a sort of trial that only supports a very small number of items like 2 or 3, then they'd have to use in-app purchases or something to buy additional capacity.
I also need them to be able to "re-download" their license from the app store if they wipe their phone or it gets destroyed.
I also want people to be able to buy upgrades as they go along. So once they find they need to manage more than 20 items or whatever, I want them to be able to buy an upgrade for 40 without having to reinstall the app or something.
Installing extra application bundles for each license or license upgrade seems like a bad way to do things, though I'm sure I could have them all use the same bundle seed ID and have them insert license info into the keychain or something.
Anyway, ideas?
You could use in-app purchase to add extra “items” to the user’s list. That will survive a phone restore and you could support adding as many “items” as possible.
I think the best way is to manage this via some sort of subscription where the 'items' are stored on your server rather than the phone. Then you can control the number of them and use the app to access each item.
So, you run the app, it manages these 'items' and each item is stored on your backend database. Depending on their subscription, you can allow/deny attempts to add items.
Alternatively, I guess you could do a similar thing on the iPhone using the built in database but you'll still need a backend somewhere to keep control of the number of items they can manage, whether that's via some sort of certificate or whatever.