这是indexloc提供的服务,不要输入任何密码
Skip to content
This repository was archived by the owner on Mar 16, 2023. It is now read-only.
This repository was archived by the owner on Mar 16, 2023. It is now read-only.

Proposal lacks clarity about stability of Cohort IDs #58

@AramZS

Description

@AramZS

Hi, reviewing the proposal for FLoC and there is some clarity issues about Cohort IDs that are assigned to users.

I am operating on the assumption that there are a limited set of cohort IDs possible across all users at any one time. For most users their cohort IDs will shift as their behavior shifts over time.

That is my interpretation now, hopefully correct. What is unclear is if the Cohort IDs themselves will shift over time in either their names or meaning based on user behavior across browsers or if they are relatively stable representatives of a user's interests.

Let's take an example:

I have a very boring individual user UserA who goes on to their computer and only visits GamingSiteA dot com, that is the only site on the web UserA ever visits. I am assigned a single FLoC [CohortID_A] that is shared by others who visit gaming sites. A consumer of FLoCs sees this Cohort ID with the value of [CohortID_A] and sees it's attachment to users on gaming sites, including GamingSiteA and others, and conversions to gaming purchases, say 'mygamingproduct.com/checkout'. As an exchange or SSP or publisher I assign "gaming" as an interest to that FLoC ID and make it available to be targeted by marketers who want to sell gaming-adjacent items.

For UserA, they keep visiting the same site forever, never going to any other site. Does [CohortID_A] remain stable on my browser and get re-applied as it expires? Or, as other people's browsers shift into different behaviors over time, does that redefine the field of play and cause [CohortID_A] to shift its value to [CohortID_B], which would mean that even if UserA's behavior is completely static, their Cohort ID will shift over time based on the behavior of all users who participate in FLoCs? Or does [CohortID_A] represent a cohortA which remain stable in what behavior it is attached to, but the name shifts over time so cohortA is represented by [CohortID_A] today and next month is represented by [CohortID_Z]?

This is very important to know because it means the allocation of computational resources may be continuous vs one-time. If the definition of FLoCs can be considered stable ([CohortID_A] is believed by my model to always represent "gaming-interested") then we can run ML to build those solutions and eventually end use of that resource once we understand the definitions of all FLoCs relevant to us. If [CohortID_A] is not a stable value we could bake a model that says 'behaviors x will always generate a cohort ID that means gaming-interested, so capture that ID and define it as gaming-interested'. Or if the meaning of [CohortID_A] shifts due to behavior across all browsers every week, then a machine learning system might have to operate very differently. In each case it might require a different level of resources dedicated to take advantage of FLoC.

I think this document needs to be clearer on this point, I propose we add a section to describe the lifecycle of a FLoC Cohort ID, it should be clear that the values for timing are not currently set in stone (we're still at an experimentation phase) and what might be defined as 'a week' may change. But if FLoC IDs themselves has a lifecycle outside of their assignment to users that should be noted and made clear for those of us interested in experimentation, as it will be useful for budgeting and assigning computational resources.

The section should make the following things clear:

  1. Does a FLoC Cohort ID names expire (is [CohortID_A] expected to be present somewhere in the FLoC system forever)
  2. Does a FLoC Cohort ID have a stable meaning
    a. If [CohortID_A] is persistent does it always represent the same in-browser historical behavior even if who it is assigned to changes over time.
    b. If [CohortID_A] is not persistent and will eventually be replaced by [CohortID_B] can we expect that if we have the same model assigned (all users on sites gamingX, gamingB, and gamingY who share a cohort ID can be understood to share a cohort ID that means 'gaming', even if today 'gaming' == [CohortID_A] and next week 'gaming' == [CohortID_B])
  3. If Cohort Name or Cohort Meaning or both are not stable over time (and therefore require regular recalculation), at what pace do shifts occur?
  4. If there are one-time shifts in meaning (Some issue in calculation of FLoCs forces the methodology to change via a browser update), how are systems notified of that shift? Is there a browser-level signal like "version", or a notification on the Chrome Developer Blog or... something else? How much time is given between the notification of intent to change and the actual change? Do they get signaled in developer tools with a warning in Canary? Is there an expected pace to such updates?

Hopefully this is an opportunity for clarity that will help with ongoing conversations and make it easier for people to make decisions around what to test, how and what the cost involved will be.

Thank you!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions