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

Merge Pubcommon and SharedId user id sub adapters. #6640

Closed
jdwieland8282 opened this issue Apr 21, 2021 · 14 comments
Closed

Merge Pubcommon and SharedId user id sub adapters. #6640

jdwieland8282 opened this issue Apr 21, 2021 · 14 comments

Comments

@jdwieland8282
Copy link
Member

jdwieland8282 commented Apr 21, 2021

Type of issue

Feature Request

Description

We have two functionally similar user id sub adapters (PubCommon and SharedID). We would like to merge the two w/o impacting the DSPs who read "source=pubcid.org" in pb.js 5.0

  • We will deprecate the SharedID sub adapter.
  • We will rename the PubCommon sub adapter to "SharedId"
  • The PubCommon Source value will remain "pubcid.org"

Expected results

  • We expect publishers who have deployed Pubcommon to not be impacted in any way.
  • We expect publishers who have deployed SharedId to not be impacted but encouraged to remove sharedid from their pb.js build & migrate to the newly renamed Pubcommon sub adapter.

remove the following sharedid files

  • modules/sharedIdSystem.js
  • test/spec/modules/sharedIdSystem_spec.js
  • modules/sharedIdSystem.md

remove pubcommon references in

  • test/spec/modules/userId_spec.js
  • modules/userId/userId.md
  • modules/userId/eids.js
  • modules/userId/eids.md

remove sharedid references in:

  • modules/pubCommonIdSystem.js
  • test/spec/modules/eids_spec.js

rename references to sharedid.org to pubcid.org in:

  • test/spec/modules/logicadBidAdapter_spec.js
  • test/spec/modules/betweenBidAdapter_spec.js
  • integrationExamples/gpt/userId_example.html
  • modules/betweenBidAdapter.js
  • integrationExamples/gpt/idImportLibrary_example.html
  • modules/districtmDMXBidAdapter.js
  • test/spec/modules/sharethroughBidAdapter_spec.js
  • test/spec/modules/sonobiBidAdapter_spec.js
  • modules/openxBidAdapter.js
  • test/spec/modules/rubiconBidAdapter_spec.js
  • modules/sharethroughBidAdapter.js
  • test/spec/modules/livewrappedBidAdapter_spec.js
  • modules/ucfunnelBidAdapter.js
  • test/spec/modules/ucfunnelBidAdapter_spec.js
  • test/spec/modules/apacdexBidAdapter_spec.js
  • test/spec/modules/districtmDmxBidAdapter_spec.js
  • modules/rubiconBidAdapter.js
  • test/spec/modules/adagioBidAdapter_spec.js
  • test/spec/modules/openxBidAdapter_spec.js
  • modules/ixBidAdapter.js
  • modules/ozoneBidAdapter.js

rename

  • modules/pubCommonIdSystem.js to modules/sharedIdSystem.js
  • test/spec/modules/PubcommonIdSystem_spec.js

rename

update references to pubcid, pubcommon to sharedid in

Actual results

Platform details

Other information

@bretg
Copy link
Collaborator

bretg commented Apr 22, 2021

From an external perspective this change is really more like getting rid of pubcommon and making everyone move to sharedid.

Under the covers though it's still pubcommon in two ways:

  • the eids.source entry is "pubcid.org". This is because this source has a much higher DSP adoption.
  • the module config can still look for the pubcommon cookie name the pub wants

We expect publishers who have deployed Pubcommon to not be impacted in any way.

actually publishers would have two major impacts in order to upgrade to PBJS 5.0

  1. when building their PBJS package, there's no more pubcommon, so they would instead choose sharedid as the module. This module happens to behave exactly like pubcommon but with a new name.
  2. when configuring the user ID modules, build a new "alias" feature into the userID module to allow references to the name 'pubcommon' instead load the 'sharedId' module.
pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "sharedId", 
            storage: {
                type: "cookie",
                name: "_pubcid",         // can keep this as the cookie name if desired
                expires: 365
            }
        }]
    }
});

Yes, we recognize that this complicates adoption of 5.0. However, it doesn't make sense for Prebid.org to have two first-party user ID modules that do essentially the same thing after 3rd party cookies go away. So we're biting the bullet to get to a place where we have the best revenue adoption with a name that's considered more catchy.

@patmmccann
Copy link
Collaborator

patmmccann commented Apr 22, 2021

I do not like the idea of "We will rename the PubCommon sub adapter to "SharedId" "

Absent combining pubcid 1st party cookie into sharedid 3rd party cookie, this proposal seems without merit to me. Pubcommonid has no branding problem that changing the name solves I am aware of. We discussed this in the publisher committee today and it was suggested pubcid shares an association with its creator company. I am not sure why that is a problem, anymore than Prebid shares an asssociation with Xandr, but it was suggested that the name change would make the new ownership by prebid of this code apparent.

It was proposed the Epsilon association could be solved by changing the name to prebid common id or some other third name, and we would lose the negative association some folks have with sharedid as the unsuccessful 3rd party attachment to pubcommonid. This seems better than rebranding to sharedid, but I still don't see the usefulness of rebranding at all.

As @bretg points out, this makes publishers' lives difficult for no clear reason. I propose we scrap the rebranding.

@slayser8
Copy link

slayser8 commented Apr 22, 2021

PubCommon was a project that came out of Conversant and was donated to Prebid.org. Without a rebranding, there is no indication that this is now owned by the community. There was absolutely a Rebranding that occurred from Prebid.js to Prebid.org when we established the standards organization. The intent was to always merge SharedIDs 3rd party namespace for A/B testing purposes to PubcommonID and combine them into one SharedID platform, and I am not sure what negative association with SharedID you're referring to - honestly there is not much talk about it in market up until this moment. Merging did not happen for a myriad of reasons, and as we move forward we realize that SharedIDs 3rd party value is not necessary for A/B testing as most SSPs can use their own seeded 3rd Party identity space.

I would prefer a rebranding to SharedID but it's up to the wider group and I am happy to bring this to the Prebid Identity group next week for more feedback.

@smenzer
Copy link
Collaborator

smenzer commented Apr 23, 2021

Isn't SharedId tied to Magnite as much as PubCommon is to Conversant/Epsilon or as much as UnifiedID and UID2 are tied to The Trade Desk?

I'm not arguing for or against a rebranding...I'm just saying that if the reason to do it is that PubCommon is attached to the original company who donated it to Prebid, I would argue SharedId is no different, since it was originally a Rubicon/Magnite initiative before it was donated

@slayser8
Copy link

PubCommon was Conversant's for years (long enough for it to be donated after they were bought by Epsilon) where as UID 2.0 and SharedId were created with the intent to donate to Prebid

@patmmccann
Copy link
Collaborator

I'm not sure that's true about uid2, but I remain opposed to making hundreds of publishers change their config because a few people prefer "a name that's considered more catchy."

@jdwieland8282
Copy link
Member Author

Our expectation is that hundreds of pubs will not have to change their config. The rebranding from PubCommon to Sharedid is a docs change, we intend to leave the source value for the PC module the same source=pubcid.org. The intention here was to make pub changes as minimal as possible and DPS (that are reading PC) changes non existent since they are helping pubs monetize inventory. Any DSP looking for an id where source=pubcid.org will be unaffected.

wrt sharedid being tied to Magnite I think that notion obscures the nature of Magnite's intention when we developed the module and donated it to Prebid.org. We (Magnite) were reacting to the path identity was taking, primarily that it was becoming a profit generator for a new class of ad tech companies. We believe the concept of identity is as a shared resource among participants in the RTB ecosystem, and publishers specifically have a 1st party relationship with their site viewers and as such have a special relationship with them making them the logical owner of a user id.

I hope that clarifies Magnite's position, we're not seeking credit or notoriety for/with Sharedid. We've put development, product, and marketing resources behind it at no small cost. Combining those efforts with Conversants install base gives a publisher 1st party id the best chance at success.

@patmmccann
Copy link
Collaborator

patmmccann commented Apr 23, 2021

I agree with @bretg above that @jdwieland8282 is mistaken, if that turns out not to be the case, I have no objection. One way to achieve this might be via a config alias?

@jdwieland8282
Copy link
Member Author

Wouldn’t be the first or the last I suspect. I think I see what you mean @patmmccann the config has a ‘name’ change, I missed that, I was expecting the ‘name’ and ‘source’ to remain unchanged. Keeping them as is or config change via alias I don’t have a strong preference, is one more palatable to you/others?

@patmmccann
Copy link
Collaborator

I have no preference; if we can achieve the rebranding without requiring the installed base to reconfigure in either way, my concerns would disappear.

@patmmccann
Copy link
Collaborator

Confirmed with @idettman that the alias option is feasible, solving my concern

@slayser8
Copy link

Does that mean you're happy @patmmccann? :)

@patmmccann
Copy link
Collaborator

My concerns about breaking things seem to be addressed, but there is an enormous amount of doc to rewite prebid/prebid.github.io#2525 that is easier said than done. I am not sure someone has been identifed to do all this work the rebranding would create.

@jdwieland8282
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants