On http://support.google.com/admob/bin/answer.py?hl=en&answer=1307237 it states the following:
Ads should not be placed very close to or underneath buttons or any
other object which users may accidentally click while interacting with
your application.
but it doesn't recommend a distance to put between click-able objects and I've heard stories about how Google shut down accounts without warning, so I don't want to risk anything.
Does anybody know what distance you should be using to be on the safe side?
As you found out yourself, there is no real strict guideline for this.
Basically all they want to prevent is that you place small buttons on top of the banner or you pop up banners on top of buttons in the hope people hit them per accident.
If you want to be sure and follow the guidelines, you could take an 8dp margin, as this is the rule of thumb Google uses as space between all UI elements;
http://developer.android.com/design/style/metrics-grids.html
Accidentally click are not real clicks, Google following some rules for Avoiding this kind of clicks.
Google not specify a fixed distance from clickable button.
Use our own logic for avoiding accidental click.
Problems Caused By Accidental Click.
If Google found accidental click from an Ad_ID, They Give a Warning mail fist. and we can rectify the problem.
If same violation came from same Ad_ID multiple time(most case 3 times) in a short time, The disable that Ad_Id.
If Multiple Ad_Id(normally more than 3 disable) Disabled in A Short time Your account will be terminate by Google.
Once Account termination happen you can't do nothing (it's gone)
Which click comes under Accident Click.
Some developers set ad_view very closer to buttons and other clickable points of app for increase ad revenue.
Click from Same device or same region is most probably not come under Accidental click , It come under invalid click. So your opponent developer can't disable Ad_Id Normally.
Related
I was looking for some auto event capture for every screen and button clicks without manually putting them on every single button or Activity/Fragment and I could find few. But I am really curious to know what to going under the hood and how are they getting these info about screen views and button clicks.
Looking for some tips to create my custom auto capture events in Android App.
You just have your tracking logic in global screen renderer, or button click listener, using whatever available there (screen ids, button ids, class names) to put in your events.
However, this only works if you don't hack around and always use the same methods for rendering and navigations.
Soon enough, the product owner will ask you to make a transparent screen, or to have a screen that flows from right to left, or a screen that opens only to a 1/3 of the screen, or a pop-up, or an overlay, or a weird iframe. You'll have to have defined tracking for those separately.
And then, on top of that, the Analytics team will donate their bit of discord where they don't want to see transparent screens as new screenviews, but also track red buttons differently from green ones. And Toggles should be tracked differently too. By the way, the screen class names aren't useful for analytics, please name them manually. And also, buttons that look like links should be tracked this special way. And don't track the buttons that are just tooltips. Oh, the iframes. The iframes issue messages on activity in them, so listen to those and translate them to events please.
Now, this is an example of what it's going to be like. In real life, it's even more than that. If you have to add an exception for your universal tracking every time Analytics doesn't like it, you will end up with a mess of nested logic that is impossible to maintain. Also, every change to it will cause more bugs in unexpected places than fixes.
Still, universal tracking makes sense when you don't have dedicated analysts or a large marketing team and so you don't want to be able to answer complex business questions frequently.
In all other cases, it's better to hardcode analytics in a structured manner, maybe mapping screen ids to screen names in one neat place, then have analytics sdk wrappers to store the core logic and make use of the name mapping,
I have an Android app and I'm doing some A/B test experiments to see how the store listing text performs.
In one of my test I changed the logo image. The problem is that I have the same logo image inside my app, as a resource file. It is shown on the splash screen during loading.
Both A and B test are serving the same APK of course so it may be confusing for users on B to see a given logo on the store listing and then a different one on the actual app.
How can I solve this? I suspect the only option available is to remove the logo image from the APK.
This is an interesting problem without a definitely correct answer. There are at least two points of view.
The first point of view says "it doesn't matter". A/B store listing experiments are about seeing which store listing works best to convert a user from "someone who is looking at your listing" to "someone who installs your app". By the time you have got to the splash screen the experiment has done it's job. Yes it is a slightly strange experience for some users, but that's ok. Run the experiment for long enough to get a result about which works best, then change both the store listing and the app to use that icon.
The second point of view says the inconsistency matters. Having an inconsistent icon will make the user confused, lead to higher tech support costs, and more uninstalls. It would be nice to make the icon match, but the trouble is, for any given user you don't know which experiment branch they were in, and Google don't give you any way to find this out. So while it would be nice to have it match you can't. This leaves you with two options:
take the logo out of the splash screen
switch to a third logo on the splash screen that is different to both experiment conditions
Personally I think I take the first point of view. But if you take the second, there are at least two things you can do.
Right now it takes too long to select the bar, and its frustrating. I also have a bar graph, so you can only select a bar, which is unintuitive.
Thanks!
I think this query has two parts, so I'll cover each in turn. (Disclaimer - I work for ShinobiControls.)
1 - 'Right now it takes too long to select the bar, and its frustrating.' -
I am going to assume here that you are referring to the showing of the tool tip and crosshair on the ShinobiChart for Android. We have aligned our product's long press behaviour on that of Android. As such, our api currently does not expose any means of customising the long press duration (needed to show the crosshair). Whilst currently we have no plans to introduce this functionality, we are always interested to learn more about how our customers use our products, and what new features people want. As such, I'll register your interest in this feature and we will certainly give it consideration for the future.
2 - 'I also have a bar graph, so you can only select a bar, which is unintuitive.' -
I am making the assumption here that you are referring to the fact that for bar (and column) series one must long press inside a bar (or column) in order to show the crosshair and tooltip. This is unlike the behaviour of a line series on which a long press does not need to be directly on the series, for the crosshair and tooltip to be shown.
This behaviour was an explicit design decision which was made in order to achieve parity with our iOS charting product. This seems to be suitable for most of our clients but that said, having the option to customise this behaviour would be a nice feature. Again, whilst we have no immediate plans to implement such a feature, as with your previous point I will register your interest in this and we will certainly consider it for future development.
Thanks and kind regards,
Kai.
Thanks for the feedback and thanks for the upvote :-)
Rest assured I have added your feedback to our 'requested features' tracking system and it will be discussed in due course. Like I said before I cannot promise anything at this stage except that it certainly will be considered. Thanks again. Only with customer feedback like this can we continue to improve our products. Kind Regards, Kai.
Navigation with Up and Back buttons is quite complicated (at least for me)
As the android documentation states,
You have the ability to make the Up behavior even smarter based on your knowledge of detail view. Extending the Play Store example from above, imagine the user has navigated from the last Book viewed to the details for the Movie adaptation. In that case, Up can return to a container (Movies) which the user hasn't previously navigated through.
http://developer.android.com/design/media/navigation_between_siblings_market2.png
I am exploring Google IO 2013 application for best practices and as far as I can see the mentioned above navigation rules are not taken into consideration.
Here is the picture:
https://dl.dropboxusercontent.com/u/6129677/do_not_delete/iosched2013.png
I launch the app and the main screen opens (#1). I tap on 'Browse sessions' -> second screen opens. Then I tap on a session - its detailed view is opened (#3). UP button says that this is 'Google+' category, and I expect to navigate to list of 'Google+' sessions after clicking on this button. Instead, the first screen is opened again (see picture).
Is this a correct behaviour and I am missing something?
Android design says that the up button goes up to the container regardless of what the icon is. It also says that the icon in the top left should be of the app. So in this case you could say that it violates the design by having a g+ icon.
That being said it is okay to violate android design if you have a specific reason to, in this case Google decided that it would like to show the icon of the category to give the user an indication of what category is without having to show 2 icons. In this case, they didn't want to alter the design all the way so as to go back to g+, but to assume the user understands that they are replacing the app icon with the category icon. So while they could show your 4th screen, they aren't necessarily required to and it depends on what you think will be best for user flows. Android design is meant to guide your individual design and doesn't need to be followed strictly (though it should be most of the time).
Hope that helps, I'm happy to answer any follow up questions.
So, I just integrated AdMob into my application. Now, I'm wondering whether to place the Ads on the top of the screen or the bottom.
Aesthetically, I think the App looks better with the ads on the bottom of the screen.
However, the little devil in me is thinking that there's more likelihood of people clicking on the ads by mistake (thereby increasing my click count), if I place them at the top since that's where I have the action bar.
Of course people who genuinely want to click on ads will click them no matter where I place them.
Can anyone share their experience in this regard?
The AdMob Publisher Guidelines cover this:
Ads should not be placed very close to or underneath buttons or any other object which users may accidentally click while interacting with your application.
and also:
Ads should not be placed in areas where users will randomly click or place their fingers on the screen. For applications that involve this type of interaction, we recommend implementing our ads on a title or ending page.
As others have mentioned, place ads where they will not be accidentally hit.
Of course people will be more likely to click your ad (accidentally or on purpose), but your customer's satisfaction will also be likely to drop (especially when someone accidentally hits your ad). When an ad affects the usability of an app the chance that a user will delete your app is quite likely, which results in nil income.
If you really need to incorporate ads in your app, I would place them at a place where the user is the least likely to accidentally tap them. As the iPhone's screen is not that large, in terms of visibility this will not have any serious effect. (I personally dislike any app that uses ads and especially AdMob ads, but that is a personal note).
With the soft buttons found on many of the latest phones I don't think positioning your ads at the top of the screen will increase your CTR, as users are likely just as likely to accidentally touch ads at the bottom of the screen.
Go with where you think the ad looks better (most likely the bottom).