Enable userIds on mobile

[ian-lr]

Is your feature request related to a problem? Please describe.
It would be desirable to extend userId support to mobile environments, both iOS and Android.

Describe the solution you'd like
Enable publishers to pass userIds via the Prebid Mobile SDKs to Prebid Server for processing. This could occur in existing global settings (e.g. Prebid.shared.eids = base64(JSON);) or as a discrete interface.

A framework similar to what has been proposed for AMP RTC would keep things consistent: passing a base64-encoded JSON attribute that Prebid Server can unmarshall into a set of eids.

Describe alternatives you've considered
As there is more flexibility on the mobile side than in AMP, we could easily pass a different structure than base64 JSON, though I would find it preferable to have a single interface PBS to deal with across channels.

Additional context
It's worth thinking about the different interactions that this interface may have with AppTrackingTransparency -- e.g. publishers may configure AppTrackingTransparency enforcement, PBS and bidders should likely receive a AppTrackingTransparency status, etc.

Please let me know if it's helpful to open an issue in the Android repo as well, but thought it's easier to keep discussion centered here.

[bszekely1]

Hi @ian-lr,

What is the use case for passing cookie IDs in an in-app environment? is this for bid adapters to generate the cookie and IDs and pass it to their endpoints like AMP or for third party service to pass in ID to bid adapters?

In-App traffic makes use of a device ID that is static to the device for user tracking.

[ian-lr]

Hey @bszekely1 ! In my mind, this would primarily be used to pass IDs derived from non-cookie data, e.g. Britepool, IdentityLink, NetID, etc. These identifiers provide additional data enrichment relative to a device-based ID and can be used for e.g. cross-device frequency capping.

I could also see a publisher wanting to pass a "pubcommonId"-style identifier instead of e.g. the IDFV, although that would seem less common.

[bszekely1]

Are you envisioning publishers adding third party identity providers in theirs apps? that seems sub-optimal. Do these identity providers all have SDK that require device access?

I would imagine a better solution would be to integrate some tech into Prebid Server, read the signals there of the in-bound ad request, enriching the ad request either with additional identifiers or an IDFV or IDFA if not present.

[ian-lr]

@bszekely1 Some of those providers consume sensitive identifiers to do a lookup (think: hashed phone, hashed email), so I think we'd want to have that lookup occur before PBS comes into the picture, right?

Here's a quick illustration of what I'm thinking:

                             +------------+       |
                             |            +-------+    Bidders
+------------+      +---------> PB Server |
|   App      |      |        |            +--------->
|            |      |        +------------+
|            |      |
|      +------------+
|      |     |
|      |     |
| +----+---+ |                +-----------+        +----------+
| PB Mobile  +<---------------+           +<-------+          |
| +--------+ |                |  App      |        |  ID      |
|            |                |  Server   |        |  Server  |
|            +--------------->+           +------->+  (opt)   |
+------------+                +-----------+        +----------+

1. User logs in / interacts with app server.
2. App server fetches/retrieves cached userID info.
3. App server passes userID(s) into PBM SDK.
4. PBM SDK provides user IDs to PBS.
5. PBS unmarshalls userIds and passed to integrated bidders.

PB mobile becomes a simple pass-through for user IDs, which are obtained upstream by the publisher.

[bszekely1]

Another approach is publishers can pass a hashed key to Prebid SDK > Prebid Server where the Identity providers can expected an encrypted key on the PBS side or use a deterministic / predictive model if no key is present. This makes the integration for the publisher easy since there is simply a key required to be generated. The biggest hurdle in these exercises is the tech integration. Identity providers would be able to scale faster in this approach.

[ian-lr]

So if an identity provider requires, say, a hashed phone number as an input, is that the hash key that's being passed between SDK->Server? Otherwise, how is the association made between the hash key passed by the SDK and another identifier input for resolution?

[bszekely1]

So if an identity provider requires, say, a hashed phone number as an input, is that the hash key that's being passed between SDK->Server?

Correct. A publisher can pass any data they wish in the data object of Prebid SDK. Any adapter can read any such data assuming they have permissions to do so. There does not need to be a new field created in the SDK API or within Prebid Server. The format of this object can be any free form object, named how the publisher likes (or how you negotiate with the publisher).

Depending on what you want to do with this data, you can have a custom integration with PBS to modify user IDs, device ID or any form of the bid request sent to specific bid adapters you have agreements with or configured for this inventory. A word of caution I have is to respect any privacy regulation (i.e. GDPR or CCPA) to not track a user against their wishes.

[jdwieland8282]

@ian-lr & @bszekely1 late to the convo, but I think I can catch up if I understand the high level use case correctly. I "think" it's to use the app login information to resolve the users Liveramp IDL, and then pass that IDL through the prebid pipes? And the question is, how or can we embed that logic into the PrebidSDK?

[ian-lr]

@jdwieland8282 You've got it!

[gmcgrath11]

@ian-lr what about the fact that iOS prohibits email being used as an identifier?

[ian-lr]

@gmcgrath11 I can’t speak for all user ID systems, but IDL/ATS specifically only leverages publisher 1st party customer data (e.g. multi-channel, not just iOS), not app collected data. We still require notice/choice and consent where applicable.

[gmcgrath11]

@ian-lr huh? isn't "the app login information to resolve the users Liveramp IDL" an email address?

[ian-lr]

@gmcgrath11 It could be, but it's not necessarily the identifier the end-user provided in the app environment. The publisher would resolve the user's login to the profile (composed of multiple identifiers) they held in their 1P database, then call for us to transform one or more of those identifiers into the pseudonymous encrypted envelope. That envelope is pushed back into the app context by the publisher.

If this is an unusual workflow, we could gate userId functionality on iOS behind an override-able ATT attribute. However, I'd also like to consider this in the abstract for the Android case as well.

[bszekely1]

We implemented this with user ID support