Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardizing First Party Data #4269

Closed

Conversation

msm0504
Copy link
Contributor

@msm0504 msm0504 commented Oct 7, 2019

Type of change

  • Bugfix
  • Feature
  • New bidder adapter
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Does this change affect user-facing APIs or examples documented on http://prebid.org?
  • Other

Description of change

  • setConfig will now accept a 2nd parameter when object in 1st parameter is protected data. The new parameter will have the format of { allowedBidders: [ <list of bidders> ] } and will be used to determine which adapters this data will be passed into
  • Any protected data that an adapter has access to will be contained within bidderRequest.protected
  • Any object can be made protected, but for now, the Prebid server adapter will only send the context and user objects to Open RTB

Be sure to test the integration with your adserver using the Hello World sample page.

  • contact email of the adapter’s maintainer
  • official adapter submission

For any changes that affect user-facing APIs or example code documented on http://prebid.org, please provide:

Other information

  • Solution Proposal
  • NOTE The instructions for reviewing bid adapters should be updated to include the following:
    "No bid adapter should ever call config.getProtectedData. All of an adapter's protected data will be included in bidderRequest.protected"

nakamoto and others added 30 commits February 16, 2019 21:30
# Conflicts:
#	modules/advangelistsBidAdapter.js
#	test/spec/modules/advangelistsBidAdapter_spec.js
@bretg bretg added the on hold label Oct 9, 2019
@bretg
Copy link
Collaborator

bretg commented Oct 9, 2019

we're reviewing a change in the approach here in light of the requirements for schain

@bretg bretg removed the on hold label Oct 28, 2019
@bretg
Copy link
Collaborator

bretg commented Oct 28, 2019

The details of how this should be implemented has changed in issue #3687:

@stale
Copy link

stale bot commented Nov 11, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 11, 2019
@msm0504 msm0504 closed this Nov 14, 2019
@msm0504 msm0504 deleted the standard-first-party-data branch November 14, 2019 21:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants