MoPubReyclerAdapter with EventListener and NetworkListener

[joeykrim]

What is the best way to track the number of native ad impressions and clicks through the MoPubRecyclerAdapter?

Methods Available in the SDK:
I’m not able to add the MoPubNativeEventListener and MoPubNativeNetworkListener to the MoPubRecyclerAdapter. The Event and Network Listeners appear to be part of MoPubNative, but MoPubRecyclerAdapter doesn’t appear to inherit MoPubNative, have access to MoPubNativeEventListener/NetworkListener, or have its own Event and Network listeners?

Impressions:
MoPubRecyclerAdapter does have onAdLoaded and onAdRemoved, but they only seem indirectly related, while the Event and Network Listeners seem directly related, to impressions and clicks. To be more specific about the onAdLoaded method, available via MoPubNativeAdLoadedListener, it does indicate when an ad is loaded and the position, but the loaded ad might not be visible to the user. If the ad is loaded but isn’t visible to the user, is that considered an impression? If not, how best to determine when the onAdLoaded is visible in order to count an impression?

Clicks:
There doesn’t seem to be an accessible ad click listener exposed, which is unusual for an Ad SDK. As a workaround, I’ve added this method: http://stackoverflow.com/a/26196831/1652110, which requires a bit more work than using a commonly exposed ad listener.

Thanks!

[shmeadyy]

Hi Joey!

The benefit of using AdPlacer is that the SDK handles all of the clicks and impressions for you, so you don’t have to worry about putting in those event listeners. We don’t expose these callbacks because we want AdPlacer to be lightweight for our publishers (though if you want more control with callbacks, you can utilize our legacy integration method for native ads).
While we don’t inform the publisher about impressions or clicks, I’ve included the bit of code from our Android SDK that indicates where we do track both of those so that way you can rest assured that we’ve taken care of it: https://github.com/mopub/mopub-android-sdk/blob/master/mopub-sdk/src/main/java/com/mopub/nativeads/NativeResponse.java#L110-L120

Hope this helps!

Laura
Solutions Engineer
MoPub for Twitter

[joeykrim]

We don’t expose these callbacks because we want AdPlacer to be lightweight for our publishers (though if you want more control with callbacks, you can utilize our legacy integration method for native ads).

It is helpful to know that not exposing the impression and click callbacks was intentional, but the reasoning provided seems unusual as exposing these simple callbacks shouldn’t conflict with the goal of keeping the AdPlacer lightweight.

The workaround suggestion has two issues: 1) using “legacy” code which could mean that it’ll be depreciated and 2) throwing away existing code built to interface with the MoPubRecylcerAdapter.

In general, it seems many ad networks, such as AdMob, expose these callbacks, which provide the publisher/developer with the flexibility to use them. I can only speak from personal experience and I rely on these callbacks for providing independent statistics in a separate system, outside of the Ad network’s system.

Thanks for your help!

Joey

[shmeadyy]

Hey Joey!

Quick clarification but we’re removing the words ‘legacy’ from our documentation soon because it is misleading. We are not going to deprecate this manual native ad integration process because we recognize that there are publishers like you where this particular solution is especially useful! So please feel free to use it!