Inform ExtBidResponse's usersync field with the user sync status about prebid-server-java HOT 6 CLOSED

So should I update the PR in order to make this field not serializable ? (not visible to the outside world)

yes please

from prebid-server-java.

@jordillachmrf - please help me understand the interface impact. I see in one of your test files that there's a $.ext.usersync section of the response:

"usersync" : {
      "rubicon": { "status": "expired" },
      "audienceNetwork": { "status": "expired" },
      "pulsepoint": { "status": "expired" },
      "indexExchange": { "status": "expired" },
      "lifestreet": { "status": "expired" },
      "pubmatic": { "status": "expired" },
      "appnexus": { "status": "expired" },
      "appnexusAlias": { "status": "expired" },
      "conversant": { "status": "expired" },
      "conversantAlias": { "status": "expired" },
      "sovrn": { "status": "expired" },
      "adtelligent": { "status": "expired" },
      "adform": { "status": "expired" },
      "openx": { "status": "none" },
      "eplanning": { "status": "expired" }
    }

What is the change relating to auction result?

from prebid-server-java.

As we are filling BidResponses.ext.usersync with data then by default it'll serialized along with the rest of the object.
That's why in the PR I suggested making this field transient(or JsonIgnore), to avoid changing the serialized output in case you have any concern

from prebid-server-java.

Key decision that should be made and that directly affects implementation is about including usersync status in /openrtb2/auction response. Although there is POJO and place defined in bid response extension for them (bidresponse.ext.usersync.{bidder}.*) filling them in auction response was never implemented for /openrtb2/auction (in contrast with legacy /auction endpoint) even in Go counterpart. That makes sense to me as there is /cookie_sync endpoint for achieving similar result (and making it easier to handle GDPR with regard to initiating usersync - see #63) so I wonder if there is benefit in providing this information in /openrtb2/auction response.

from prebid-server-java.

What's the use case for exposing this information in the externally available auction response object?

What I'm hearing so far is that the data is really only needed internally later in the auction pipeline, not by the client? I don't think we want to expose data that's not needed by a client app/browser -- that could be inefficient, confusing, and/or GDPR-sensitive if cookie-related.

from prebid-server-java.

The PR's comment (#75) already mentions that maybe we should make this field transient, in order to not expose this information to the outside world.

Marfeel does not need to expose this information to the outside world, I agree with you that is useless from the client point of view, we only need it internally, for tracking metrics.

In my opinion the only "natural" way of storing and retrieving this data in both /openrtb2/amp and /openrtb2/auction endpoint is using this POJO field

So should I update the PR in order to make this field not serializable ? (not visible to the outside world)

from prebid-server-java.