Feature request: Topics api results on user.data

[patmmccann]

Type of issue

Feature request

Description

FPD enrichment module should populate results on topics api ( see https://github.com/jkarlin/topics/issues ) onto user.data.

Depends on a segtax being defined. see ( https://github.com/InteractiveAdvertisingBureau/openrtb/pull/81/files for an example and patcg-individual-drafts/topics#12 )

[patmmccann]

I attempted to reserve 600 for this InteractiveAdvertisingBureau/openrtb#86

[patmmccann]

Copying some notes from the last taxonomy meeting:

Publishers might not get all the topics; the browser might endeavor to hide many topics from the publisher but not from third parties. How would the browser do this hiding of topics? It seems they could isolate the frame that makes the call (but if they did this how would ssps correlate the topics to the bid request that is made from prebid?) or they could append headers to the bid request the publisher couldn't see (but then wouldnt the ssp just reflect the topics back at the publisher?)

Still though, it seems useful to have a place for the topics the publisher does happen to get. Relevant: patcg-individual-drafts/topics#30

[dmarti]

The Topics API proposal currently provides for up to five topics. But Topics API support in Prebid may need to handle more than five, since multiple parties might supply topics.

For example, a third-party caller could call Topics API, receive five topics for the current session, and reflect back to the publisher (as pointed out in @patmmccann 's comment ) and then the publisher might be able to supply additional topics for the same user, that had persisted in a first-party cookie or LocalStorage.

[fbastello]

@dmarti - Prebid FPD module could handle this like this:

 {
   ...,
   "user": {
     "data": [
       {
         "name": "publisher.example",
         "ext": {
           "segtax": 600
         },
         "segment": [
           { "id": "243" },
           { "id": "247" }
         ]
       },
       {
         "name": "large-third-party.example",
         "ext": {
           "segtax": 600
         },
         "segment": [
           { "id": "59" },
           { "id": "129" },
           { "id": "173" }          
         ]
       }
       ]
     }
   }
 }

rf: patcg-individual-drafts/topics#55 (comment)

[patmmccann]

Requirements: implement Fred's proposal above. Use the first party module and register a topics submodule in https://github.com/prebid/Prebid.js/blob/master/modules/.submodules.json. Call document.browsingTopics as per https://developer.chrome.com/docs/privacy-sandbox/topics/ but do not add the origin token; publishers can opt into the origin trial themselves. Append the topics to any topics already there with the same segtax and name from an rtd module or from a setConfig call (don't overwrite). Set user.data.name equal to 'chrome.com'. If there are topics already in the object on segtax 600 with a different user.data.name, do not edit those.

[patmmccann]

@jsnellbaker you had relayed a question from a colleague about our plans for the topics api. I think the status is now ready for dev on this one, unless additional feedback on requirements changes that.

[fbastello]

Just adding a couple of comments for the discussion @patmmccann

1. Where does the document.browsingTopics should live?
   Could we repurpose or extend the userSync config? I see Topics iframes being dropped in the same fashion as user sync, we then need a way to postmessage back the Topics to the parent frame.

2. Setting the Topics "provenance"
   Rather than aggregate the data under user.data.name='chrome.com', should we set user.data.name to whomever party contributed to segtax 600? I.e. There might be value for a buyer to see that the Topic "News" was contributed by user.data.name="news.example" and that Topics from user.data.name="dsp-1.com" showed additional Topics. I'm not sure if this creates a privacy concern though, so aggregating under "chrome.com" could help there!

[JoelPM]

Regarding provenance, would it be possible to use user.data.name for the entity that queried the Topics API and user.data.id as 'chrome.com' to identify source? (OpenRTB 2.6 allows both a name and an id.)

Given the way Topics works, it could be in the interest of Prebid itself to query the Topics API given the broad install base that it has, though aggregating across all the different SSPs may be just as effective.

[dmarti]

@JoelPM That makes sense. So a party could use name: party.example, id: chrome.com for freshly obtained topics, and name: party.example, id: otherparty.example for topics that had previously been shared to it?

[patmmccann]

user.data.id as chrome is not useful, that's already covered by specifying segtax. user.data.name as fred proposes is incremental info.

[patmmccann]

google/ads-privacy#61 for linkage

[JoelPM]

Segtax identifies the taxonomy in use. I would prefer not to overload segtax to also imply the source of data. Conceivably other providers could choose to use the Chrome taxonomy down the road if it becomes popular.

[dgirardi]

To start development I think two things are missing:

• how do I get document.browingTopics() to actually return something for testing? (it's always empty for me).

• related, how does the result map to user.data segments? all I see to go by is - from here:

  The returned array looks like: [{'configVersion': String, 'modelVersion': String, 'taxonomyVersion': String, 'topic': Number, 'version': String}]

  the only relevant item seems to be topic (going to segment[].id I'm guessing) - but what do we do with the rest, and where does name come from?

[lukwlodarczyk]

how do I get document.browingTopics() to actually return something for testing? (it's always empty for me).

@dgirardi do you see any output in chrome://topics-internals/ ?
some example expected outcome:

please find below some helpful links for troubleshooting

1. detect-feature-support
2. access-topics

[patmmccann]

how does the result map to user.data segments?

Detailed at
google/ads-privacy#61

[patmmccann]

One note, you can see google plans to adopt/confirm my suggestions into the readme with this comment google/ads-privacy#61 (comment)

[patmmccann]

document.browingTopics() to return something

{“configVersion”:“chrome.1",“modelVersion”:“2206021246",“taxonomyVersion”:“1",“topic”:133,“version”:“chrome.1:1:2206021246”} is a sample return (although i think the quotes are mangled with the copy paste)

To have the api return something, you may need to opt into the privacy sandbox on Chrome Beta 101+ or a more recent chrome version.

https://searchengineland.com/google-chrome-topics-api-test-public-july-1-385589 indicates on July 1 we will see more widespread api results.

[dgirardi]

I do see a similar page at chrome://topics-internal, but the api still always returns an empty array. No matter, it should be enough to use @patmmccann's example.

Am I understanding this right - the task is to build a separate fpd module* that populates one user.data object where name is always "prebid.org" (since prebid is the one calling)? If the API returned only the object above, that'd be:

user: {
   data: [
       {
         "name": "prebid.org",
         "ext": {
           "segtax": 600,
           "segclass": "v1" // why not just "1"?
         },
         "segment": [
           { "id": "133" },
         ]
       },
   ]
}

** FPD modules currently cannot work asynchronously so that's also needed, unless this would also make sense as an RTD module?