Implement Event Delegate

[kimar]

Rationale

We’re developing an analytics backend which depends on the OpenRTB Request and Response data from the Prebid Mobile SDK.

To achieve this we’ve implemented a simple delegate which will be called with the request and response payloads once the HTTP request to the Prebid Server has finished.

Next steps

Once this PR has been approved we'd take it as a blueprint for the Prebid Mobile Android SDK and implement it in a similar manner.

[jsligh]

@kimar this seems like a very specific implementation and opens up the SDK's traffic to be sniffed. You are welcome to fork the SDK and implement it in your own fork. Why is this needed?

[steffenmllr]

Hey @jsligh 👋 @kimar is on vacation — I can follow up

this seems like a very specific implementation

We raised a PR here as we think it could be useful for anyone who uses your SDK to analyze or correlate device / app-specific data with bidding data.

We are developing a reach measurement study and provide a Prebid Server and JS Analytics Adapter to several publishers. We've received feedback that publishers are unable to activate the server-side analytics plugins or have systems that filter out most of the bid requests before they reach the Prebid server.

opens up the SDK's traffic to be sniffed

As far as we understand — the same information would be available in the server side analytics modules?

Currently, a publisher needs to hook into the completion handler for each ad unit to access the same request/response cycle on the mobile SDK as on the Prebid server — this involves a lot of code, which this non-breaking PR aims to simplify.

Hope this clarifies the contribution overall, interested to hear your thoughts on this

[kimar]

Hello @jsligh the intention of using this delegate is for consumers of the SDK to have a plug-and-play way of doing further analytics in terms of the study mentioned by @steffenmllr.

Without this delegate quite a bit more manual work would be required to extract the relevant data, risking also incorrect data by inconsistent implementations.

I'm afraid a fork would not be very appealing for integrators, would you see any chance (even if this would require an alternative implementation) to get this (or a similar solution) merged?