Reputation: 1315
In our app, we have a feed of images loaded in an ListView. These images are returned from our server. When an user scrolls down to the bottom of the page, a load-more logic would be triggered, where we will send another request to our server to ask for more content (images) to display. This is also the time when we request for one FAN ads using the Facebook SDK. If an ad is indeed returned by Facebook, we will insert it into the list of content just returned by our server. Finally, when this cell (containing the FAN ad) is in view, we would start loading the content (images and texts) of this cell.
Given we don't pre-cache FAN ad, we expect the # of Impression to # of Filled ratio to be close to 100%. However, we've been observing a ratio of around 67%.
FYI - all FAN ads referenced here are NativeAd.
Question: what happened to the 33% of the Filled requests? Somehow they are rendered, but are not counted as Impressions?
Upvotes: 5
Views: 3096
Reputation: 16281
Consider that if you want to track the actual impression you can implement the ImpressionListener
that fires the onLoggingImpression(Ad)
, called immediately before an impression is logged.See docs here.
There is a full implementation of facebook native ads in the MoPub nativeads custom native event here:
that clearly shows you how to implement it in the right way.
Upvotes: 0
Reputation: 611
I am an engineer working on Audience Network. Impression for a NativeAd is logged only when the view registered for that NativeAd is viewable on screen. If the view is in the part of the list view that is not yet visible on screen, it will not be counted as an impression. (It will be counted when it becomes visible.) This should explain the difference between filled requests and impressions.
Upvotes: 4
Reputation: 12121
Disclaimer I've worked on a Ad SDK.
The Ad View is a WebView and there are a few ways to know that an ad has been loaded.
1) Wait for a Javascript call back from the Ad to the SDK who will then fire a tracking pixel/request to make sure that ad is really VISIBLE (vs HIDDEN/INVISIBLE) before counting
and/or
2) Fire a tracking pixel/request from the WebView.
Either way as it is a WebView, even though the image has loaded, it doesn't necessarily mean that the load completed state has been communicated - especially if the Ad is within in a fast scrolling ListView where the image for the ad might be visible, but the rest of the Javascript code hasn't quite reached the 'Ad done loading' state. Basically an Ad is a small HTML5/CSS/Javascript bundle and subject to the delays therein - which could be on the order of seconds.
One way to check is to monitor the traffic via HTTP Proxy and take a best guess as to when it fires and adjust expectations.
Alternatively is to move the Ad to a footer/header where it isn't subject to the visible/loading problem if it within the scroll part of a ListView.
Upvotes: 0