Line Item ID

[Brian Fallon]

Hi,

I notice that a successful HTTP request for an advert to DFP (SB) includes a HTTP header called X-Afma-Debug-Dialog.

Is it possible to access this value via the SDK on either Android or iOS? If not would it be possible to add it?

Here is the use case:

- We load interstitial ads and cache then and don't display the ad until the next time the user open the app so that the ad load is instantaneous and therefore doesn't overly impact user experience (particularly of mobile network connections).

- At present we are using a different ad server for this but want to transition to DFP. 

- The problem we have is that sometimes by the time the user open the app, the advert is no longer valid. This is a big problem for campaigns that are day part or week part targeted as the advertisers expect the ad to not be delivered outside these times.

- We want to use the lineItemId which is contained in the X-Afma-Debug-Dialog header to do a check via the DFP Api for the targeting information for the line item is served. This way we can check if the creative is still valid to show when the app is opened again. We have build an API endpoint on our servers that does the request to DFP so as to cache and speed up the response. This is working well for us on our other adserver but really want to move to DFP so that we can have all our desktop and mobile inventory in the same place.

Any help with this problem would be hugely appreciated.

Brian

[Eric Leichtenschlag]

Hi Brian,

This lineItemId is not exposed via an API, and that is intentional. If you really want this information, your best bet would be to send an app event from your creative with the line item ID, and listen for that event via an AppEventListener in the SDK.

Thanks,
Eric

[Brian Fallon]

Hi Eric,

I really appreciate you getting back so quickly.

The route you're suggesting is the one that I was exploring first as it seems simpler than lobbying for a feature to be revealed in the API :)

Unfortunately pulling the data from the creative as it's being displayed is too late... We're trying to find out, prior to showing a cached interstitial, if the ad is still valid to show according to the targeting set in DFP. For example, if the ad is only meant to show in the mornings or if it is meant to end by a certain date. A cached interstitial might no longer be valid by the time we want to show it. And my understanding is that you can only fire app events from the creative as it's displayed on screen rather than when it's loaded or loading into cache.

If we could access the lineItemId we could pull the information we require from the LineItemService in the DFP API

I'm hoping that our use case (showing splash interstitial ads cached from previous session on app startup) isn't so edge case that you wouldn't consider adding a solution to our problem. Which could be one of the following:

- exposing the X-Afma-Debug-Dialog header information in the google mobile ads sdk. And leave it up to us to get the info we need from the DFP API

- Sending the "maximum TTL" for an ad in the response for the ad request  in another http header such as "X-Afma-Interstitial-Max-TTL". The sdk could have a method isValid() (similar to the isReady()) call that uses the timeout sent in the initial call to see if it's safe to display the ad. [The main thing achieved here is avoiding any http requests after the initial ad request so that there's no user lag]. I noticed there there appears to be a reference to a X-Afma-Interstitial-Timeout" in the SDK, but I think this is something to do with loading timeouts. (Which is something we're trying to avoid entirely with the caching)

I understand that this may not be an issue for many people in which case we will need to look down the route of staying with our current ad server for serving our interstitials (or even writing our own library so that we can server via the DFP Http serving endpoint)

Do you think a solution for our problem might get added in future? Or else if there a work around that we have not considered.

Once again, your help is hugely appreciated.

All the best,

Brian

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "Google AdMob Ads Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-admob-ads-sdk/2lCnl0y_x1s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-admob-ads...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Eric Leichtenschlag]

Hey Brian,

The dispatchAppEvent method has a third parameter, an option to send the event before onReceiveAd is called. Perhaps setting this to true gets you the event just before the ad is received, and not when the ad is loaded into the WebView?

I'm not familiar with DFP Http Serving outside of the SDK. But at least from an AdMob product perspective, we don't want people trying to reverse-engineer and build their own SDK. It sounds like you already know more than you need to about headers that we aren't exposing!

I think the use case is valid. I'm not sure if/where it is on the roadmap, but if we are going to support it, we would do it in such a way that the SDK handles the bulk of the work, and you wouldn't have to query the API yourself to see that it's still valid.

Thanks,
Eric

To unsubscribe from this group and all its topics, send an email to google-admob-ads-sdk+unsub...@googlegroups.com.