-
Notifications
You must be signed in to change notification settings - Fork 0
广告集成经验
最常见的广告源：MoPub, Facebook, AdMob(即google)。
其中Mopub, AdMob广告也可以作为Mediation(中介）来集成其他广告源（比如facebook, flurry, Fyber等等）。
横幅广告会占据应用布局中的一处位置，要么是设备屏幕的顶部，要么是底部。这类广告会在用户与应用互动时停留在屏幕上，并且可在一段时间后自动刷新。
插页式广告属于全屏广告，会覆盖宿主应用的整个界面，通常展示在应用流程的自然过渡点上，例如，页面之间的切换处或游戏关卡之间的暂停时段中。当应用展示插页式广告时，用户既可以选择点按该广告，进而访问其目标网址，也可以将其关闭，并返回应用。
在具有自然过渡点的应用中，插页式广告的效果最好。此类过渡点通常存在于应用内的任务结束时，例如分享完图片或完成一个游戏关卡时。因为用户希望借此机会在操作过程中休息一下，所以，此时展示插页式广告不会影响用户体验。请务必考虑在应用流程的哪些时间点展示插页式广告，以及用户可能会以什么方式响应。
插页式广告类型多样，包括文字广告、图片广告和视频广告等。确保应用在展示插页式广告时，也会暂停使用某些资源，以便供广告使用，这一点十分重要。例如，当您请求展示插页式广告时，请务必暂停应用产生的所有音频输出。您可以在广告关闭回调方法里恢复声音播放。此外，还应考虑在广告展示时暂停所有会占用大量资源的计算任务，例如游戏循环。这样可以确保用户不会遇到图像无响应、响应慢或视频卡顿的现象。
确保在恰当的时间展示插页式广告十分重要，同样，确保用户无需等待广告加载也十分重要。在广告需要显示前，不妨事先加载广告，这样可确保应用在广告展示时间到来时，已准备好加载完毕的插页式广告。
虽然提高插页式广告在应用中的展示频次似乎是实现增收的好方法，但这么做会影响用户体验，还会降低点击率。应确保用户不会频繁受到广告打扰，使他们可以充分享受到使用应用的乐趣。
原生广告是通过平台原本就有的界面组件向用户呈现的广告素材资源。这种广告使用您在构建布局时已经采用的同类视图进行展示，而且能以和周围视觉设计相称的形式呈现，让用户有浑然一体的使用体验。具体到代码编写层面，这意味着当原生广告加载成功时，您的应用会收到一个包含其素材资源的广告对象，然后就由此应用负责展示它们了。
激励广告是保持用户参与您的应用程序同时获得广告收入的好方法。通常以游戏中的货币（金币，硬币，道具等）的形式出现，并在成功观看广告后分配给用户。
-
不要在广告加载失败回调方法里加载新广告。如果实在是必须在广告加载失败的回调方法里加载广告，请限制广告加载的重试次数，以免在网络连接受限等情况下连续出现广告请求失败或者栈溢出导致应用crash的情况。
案例：之前在某个项目的一个全屏广告加载失败的回调方法里去加载新的广告，在后台crash log里出现大量关于堆栈溢出的log。
-
不要浪费请求（请求多，展示少）
针对客户端，如果代码上不严谨，很容易出现浪费请求的情况。比如很多应用有付费后去广告的功能，假如在请求广告的时候没有加上非付费用户的判断，就去直接load广告，而在展示广告的地方加了判断，那么就会导致有很多请求，展示少的情况。
-
如果在列表中展示native广告，一般的做法会将广告布局排版设计成和列表item一样，这样做的目的一方面是和周围视觉设计相称，让用户有浑然一体的使用体验，一方面也可以提高用户的点击率，但需要注意广告布局还是得和item区分开，不然会违规政策，被认为会误点击广告。可以给广告布局加个背景色，或者以卡片的形式呈现等。另外广告布局上需要有AD字样。
-
关于facebook native广告配置
facebook native广告分为Native（有大图）和Native Banner（无大图）两种样式。Native样式要求广告布局必须有大图(MediaView)，Native Banner样式要求广告布局必须有小图(小图的类型有点迷惑，facebook广告官网说的是也必须是MediaView, 但AdMob中介里提到的是ImageView, 而且从facebook广告sdk里看到的也有支持ImageView的)。所以如果项目里某个广告位设计的是有大图的话，那么后台配置必须配的是Native样式的，如果配的是Native Banner样式可能只是获取不到大图，也可能是没展示（待验证）；如果广告位设计的是没有大图的，那么后台配置必须配的是Native banner样式，如果配的是Native样式是不会有展示的，而且通过AdMob作为中介集成facebook native广告的话，客户端需要添加设置是否是Native Banner的代码(该部分代码在AdMob官网集成facebook广告的文档里有提到）。
-
广告请求时机
应用可以在实际展示广告之前先行请求这些广告。在许多情况下，推荐采取这种做法。目前在我们应用中最常用的做法就是加缓存。缓存的大概实现是从缓存里取出广告后再在内部请求下一个广告缓存起来（针对缓存一个的实现）。
应用中加缓存比较好的例子：Clean系列应用在清理后会先出现一个全屏广告，关掉全屏广告后再出现清理结果页（分有native广告和没native广告）。Clean清理过程有可能很短，等清理完了，很可能出现广告还没加载成功的情况，那么就不会显示对应的广告，也造成了浪费。如果有缓存的话，每次清理完就能立即出现广告，就不会造成广告请求的浪费。更能体现缓存价值的case是清理完后的两分钟内进入对应功能页面会立即出现结果页，如果没有缓存的话，根本来不及展示广告。
注意: 尽管预先提取广告是很好的做法，但发布商切勿过久保留旧广告而不展示它们。对任何广告对象来说，如果在保留一小时后仍没有获得展示，就应该予以舍弃，并替换为来自新请求的新广告。所以缓存需要做的好一些，需要有广告过期的处理。另外，为了减少请求浪费，缓存第一个广告的时机也很重要，一般是在第一次加载广告成功后去缓存一个，而不是特别提前去缓存一个。比如clean结果页的广告是在清理的时候判断缓存里有没有广告，没有的话去加载新的，新的加载成功后去缓存一个，如果在实际清理前去缓存第一个的话，很可能造成这个广告没有展示，因为用户有可能不去清理。
广告是否加缓存，还是需要根据实际情况决定，有的广告位加缓存的话效果也许没有不加缓存的好，变现人员提需求的时候也会根据后台数据来调整策略。