There is a specific and official analytics SDK for native Android apps (note that I'm not talking about webpages in apps on a phone). This library basically sends pages and events to Google Analytics and you can view your analytics in exactly the same dashboard as for websites. Since my background is apps rather than websites, and since a lot of the Google Analytics terminology seems particularly inapplicable to a native app, I need some pointers. Please discuss my remarks, provide some clarification where you think I'm off-track, and above all share good experiences!
1. Page Views
Pages mostly can match different Activities (and Dialogs) being displayed. Activities can be visible behind non-full-screen Activities however, though only the top-level Activity can be interacted. This sort-off clashes with a "(page) view". update -> Read http://android-developers.blogspot.com/2010/12/analytics-for-android-apps.html and accept it.
You'd also want at least one page view for each visit and therefore put one page view tracker in the Application class. However this does not constitute a window or sorts. Usually an Activity will open at the same time, so the time spent on that page will have been 0. This will influence your "time spent" statistics. How are these counted anyway?
Moreover, there is a loose coupling between the Activities, by means of Intents. A user can, much like on any website, step in at any Activity, although usually this then concerns resuming the application where he left off. This makes that the hierarchy of Activities usually is very flat. And since there are no url's involved. What meaning would using slashes in page titles have, such as "/Home"? All pages would appear on an equal level in the reports, so no content drilldown.
Non-unique page views seem to be counted as some kind of indicator of successfulness: how often does the visitor revisit the page. When the user rotates the screen however usually an Activity is recreated, thus making it a new page view. This happens a lot. Maybe a well-thought-through placement of the call might solve this, or placing several, I'm not sure.
How to deal with Page Views?
2. Events
I'd say there are two sorts:
A user event
Something that happened, usually as an indirect consequence of the above.
The latter particularly is giving me headaches. First of all, many events aren't written in code any more, but pieced logically together by means of Intents. This means that there is no place to put the analytics call. You'd either have to give up this advantage and start doing it the old-fashioned way in favor of good analytics, or, just be missing some events.
Secondly, as a developer you're not so much interested in when a user clicks a button, but if the action that should have been performed really was performed and what the result was. There seems to be no clear way to get resulting data into Google Analytics (what's up with the integers? I want to put in Strings!).
The same that applies to the flat pages hierarchy, also goes for the event categories. You could do "vertical" categories (topically, that is), but some code is shared "horizontally" and the tracking will be equally shared. Just as with the Intents mechanism, inheritance makes it hard for you to put the tracking in the right places at all times. And I can't really imagine "horizontal" categories. Unless you start making really small categories, such as all the items form the same menu in one category, I have a hard time grasping the concept.
Finally, how do you deal with cancelling? Usually you both have an explicit cancel mechanism by ways of a button, as well as the implicit cancel when the "back"-button is pressed to leave the activity and there were no changes. The latter also applies to "saves", when the back button is pressed and there ARE changes. How are you consequently going to catch all these if not by doing all the "back"-button work yourself?
How to deal with events?
3. Goals
For goal types I have choice of: URL Destination, Time on Site, and Pages/Visit. Most apps don't have a funnel that leads the user to some "registration done" or "order placed" page. Apps have either already been bought (in which case you want to stimulate the user to love your app, so that he might bring on new buyers) or are paid for by in-app ads. So URL Destination is not a very important goal.
Time on Site also seems troublesome. First, I have some doubt on how this would be measured. Second, I don't necessarily want my user to spend a lot of time in my already paid app, just be active and content. Equivalently, why not mention how frequent a user uses your app?
Regarding Pages/Visit I already mentioned how screen orientation changes blow up the page view numbers.
In an app I'd be most interested in events/visit to measure the user's involvement/activity. If he's intensively using the app then he must be loving it right?
Furthermore, I also have some small funnels (that do not lead to conversion though) that I want to see streamlined. In my mind those funnels would end in events rather than page views but that seems not to be possible.
I could also measure clickthroughs on in-app ads, but then I'd need to track those as Page Views rather than Events, in view of "URL Destination".
What are smart goals for apps and how can you fit them on top of Analytics?
4. Optimisation
Is there a smart way to manually do what "Website Optimiser" does for websites? Most importantly, how would I track different landing page designs? update -> Seems I could use the Custom Variables for that. More details are still welcome.
5. Traffic Sources
Referrals deal with installation time referrals, if you're smart enough to get them included. But perhaps I'd also want to get some data which third-party app sends users to my app to perform some actions (this app interoperability is possible via Intents).
Many of the terminologies related to "Traffic Sources" seem totally meaningless and there is no possibility of connecting in AdSense.
What are smart uses of this data?
6. Visitors
Of the "Browser capabilities", "Network Properties" and "Mobile" tabs, many things are pointless as they have no influence on / relation with my mostly offline app that won't use flash anyway. Only if you drill down far enough, can you get to OS versions, which do matter a lot. I even forgot where you could check what exact Android devices visited.
What are smart uses of this data? How can you make the relevant info more prominent?
7. Other
No in-page analytics. I have to register my app as a web-url (What!?)?
Google Analytics is pretty good for basic tracking of Android app usage. If you need more mobile-app-focused analytics you may also want to look at these:
http://www.flurry.com
http://www.capptain.com
A benefit of these over Google Analytics is that they are designed to track mobile app usage, rather than web site usage, so are more specific in what they do, but to be honest there's always going to be work for you to do to define what actions within your app matter to you enough to track - that's more about the needs of the business, than the technology.
I am not convinced with google analytics for tracking our application. Because as per my requirement i would like to get the error or crash report from my launching application in market. From this error report i could see the stack trace of the crash so that i can fix my bug. But from google analytics i am not sure how to get these details, I would suggest the best crash report trackr is Acra you will get more info here http://code.google.com/p/acra/
If someone know how to get these crash report using Google analytics please share.
I've no analytics experience but after searching a while i found this page Flurry-vs-Mixpanel-vs-Google-Mobile-Analytics-who-wins-Why and i think you can find useful information and I also decided to use Flurry
Related
I am planning to create a mobile app (android). It has several pages/frames for different cases. Now the number of frames/pages that I would like the app to have would grow over time, so new frames/pages would keep on adding.
Now, I have two options the way I see it. One being keep on adding new version of the app with new pages/frames once every few months. Other being I decide upfront all the possible templates for those frames. Once the templates are fixed, the response (from REST API containing data to display) would also contain the information of which template to use. I could embed the logic on how to interpret the template type available in response in the app code, so the app knows how to display a template of type "table" and what constitutes the table headers, etc.
The caveat for former approach (upgrade) is that once in while, app needs to be upgraded, something which not all users would like to do. A way around it is to enforce an upgrade, which renders app unusable. The problem with the latter approach (template) is that a lot more code needs to be written to make it work right.
I would like to know what approach is mostly used, and whether there are popular apps out there which use the latter (template) approach.
I definitely recommend using the first approach (that is, you submit updates when you actually provide new versions of the app...).
Here are a few reasons which seem to be enough to choose the regular option:
If you use the templates, you are "forcing" updates to the user. One day he has a UI, and the next he has another one (new element in the menu, or new display of a known activity/fragment). And that's worse, because he didn't receive a notification that there was a new version of the app. So he might actually get confused.
You are relying on a web connection to perform this check. So you don't even get the guarantee that this will work (depending on the permissions and business of your app, this argument may be invalid for your particular case. I wanted to answer to the general question though).
You will add a ton of complexity to your application's code (meaning no offense, I doubt you can think up-front about ALL the designs/renderings you will need in the coming months/years). And a higher complexity = more bugs, statistically.
Do you realize that the second approach you are talking about is more or less the principle of a website? Maybe what you are looking for is a simple app which has a webview to your mobile website?
We are building an app (iOS and Android). The core of the app will be a flash card interface where the user will see a question and then will need to give an appropriate answer. They have a timer and will be shown hints as time goes on.
We want to understand the following on a per question basis (there are potentially 100s of questions):
Which questions took longer to recall correctly (with and without hints)?
Which questions had the most errors (with and without hints)?
Which questions were skipped the most (with and without hints)?
What were the most common (wrong) answers for a question?
Of course, we are also going to be collecting number of installs, usage, churn, etc., but I figure that is pretty well covered by GA.
Also, we will be storing different information about the user themselves so they can track their progress. This is meant to help us understand how to tweak the flash card data later on so that it is better for the students.
It feels like we could potentially use goals within GA (end goal is to get the right answer), but I am not as familiar with them.
Would this be goals within Google Analytics? Or is Google Analytics not a good use for this type of thing? Is there something else we could use to collect/analyze this information or should we build it ourselves?
Google Analityc suppor custom variables. You can save custom data.
First I would just track every card event as unique pageView (card1234) with it's data.
You can also track events with data for every card.
Goal is more for tracking your app behaviour in general. Example:
Goal 1
for tracking wring answers - Make a goal with more that 100 wrong answer (for session or in general for day) - in this way you can track that your app has difficult question
Gola 2
Quick answer - Make goal with Event or pageView for card that has small duration (5 second for example). In this way you can check behaviour of whole app.
There are many other good analytics
Localitic
KiSSmetric payed one
Mixpanel - very good for tracking information about users and making segmentation reports
https://mixpanel.com/notifications/
County -Haven't try this one so can't say anything
Here you can find many others
Im currently using Flurry analytics it, more easy to integrate and simple to use.
http://www.flurry.com/flurry-analytics.html
http://www.google.com/analytics/ this is GA official web-page.
Edit: Documentation for developers: https://developers.google.com/analytics/
I'm constantly trying new apps and my phone is getting cluttered with old apps, I no longer use. So, I thought I'd develop a simple app to help me out. There are similar apps, but none does exactly what I want:
I would like to have a list of apps which I've installed in the last month, which I've used X number of times (for easy access: They may be keepers!) as well as those I've not used in Y weeks.
Is there any way to get app usage statistics with Android? I guess ActivityManager might help me to gather that statistics, but is there a way to read just when an app has been used last? Or how many times in a given period?
Any tips will be most welcome :)
You can try out my app for uninstallation of the apps you don't need : https://play.google.com/store/apps/details?id=com.lb.app_manager .
Also, if you wish to find exact usage statistics of your apps, you can use my app this way: find "settings" (the app itself) inside the list (you can perform a search query), choose to make a shortcut of it, and then choose on the dialog "Usage Statistics". This way you can perform both the operations you wanted.
I also plan on adding this feature somehow in the future, but that's what you can do for now.
Here's a screenshot (it's the first on what I show here) :
it's been some time now, since I started reading about android.
I've already made a few basic applications, but I still miss something: How is actually sharing application component being done?
This is what the Android Dev Guide says:
A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.
I think I came across some question like this, but I think I'm still confused.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Is information about the data that the application operates with private, too?
If it is described in the AndroidManifest.xml file is it available for the other applications, or it is available only to Android?
When I started satisfying my interest in Android - one of the things that grabbed me was the impression of immense interoperability...
:)
Have I been wrong or I still haven't found the way?
Thanks!
How is actually sharing application component being done?
That depends entirely on what you consider an "application component" to be, and what you consider "sharing" to be.
This is what the Android Dev Guide says
That is a fairly bad piece of the documentation. Here is how I would write it:
A central feature of Android is that one application can make use of components (e.g., activities, services) of other applications (provided those applications permit it). For example, if your application needs to display a list of contacts and another application has developed an activity that does just that and made it available to others, you can call upon that activity to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application. Rather, it simply starts up that piece of the other application when the need arises.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Either developers are intending for you to integrate with them, or they are not. If they are, they should be documenting how to do that (e.g., Intent formats to be used with startActivity() to trigger their code). If they do not document such integration points, you can certainly ask the developers to add some. However, randomly shooting Intents at them in hopes of getting a response, even if it temporarily works, is little better than script kiddie tactics -- those developers are not obligated to ensure you code works when they upgrade their app.
Is information about the data that the application operates with private, too?
I do not know what "information about the data that the application operates with" means. Data managed by an application is private by default. Again, application developers can offer integration points for data (e.g., content provider, remote service API) -- some do, some do not.
one of the things that grabbed me was the impression of immense interoperability
Android offers greater interoperability potential than some other mobile platforms. However, using that potential requires consent among the interoper-ees. You cannot unilaterally decide to hack into another app's database, or invoke private activities, just because you feel like it.
Should more Android developers offer more integration points? In the abstract, sure. However, bear in mind that this adds support costs (e.g., answering integration questions) and limits coding flexibility (e.g., need to maintain a stable API for those doing the integrating). Developers cannot be blamed if they do not wish to incur all that.
I'm about to implement Google Analytics support in an Android app, but after some googling, the documentation seems delightfully sparse. Are there any useful conventions or advice (i.e. when not to trigger pageviews/events, or something) that a newcomer to GA should know?
I also use events to report exceptions in case users are too lazy to hit the 'Report' button. Also useful for exceptions that you handle internally but want to understand and deal with user error.
An example of the later - I have a numeric EditText (that even has inputType:number) but users still find ways to trigger NumberFormatExceptions that I handle with a default value. When I saw how many times I handled this case, I realized that I needed to better explain how to use that field.
Personally I use page views only one per activity.
Then I map and record events on user interaction (button touch, item selection and so on).
Practically the same as a real website.
Related to Google Analytics in Android app - dealing with multiple activities