Clarification on subsets, specifically "associated" subsets

[Jack-Pritchard]

In reading the use cases as well as the definition of subsets I have a use case that does not seem to be addressed that also presents a need for a clarifying question on the first bullet of abuse mitigation - "Mutual exclusivity to ensure a domain isn't part of multiple First-Party Sets" .

Does FPS cover the use case of websites that utilize a 3P vendor for booking/purchasing? The easiest example is a small hotel that utilizes one of the large booking engine companies to handle date availability and booking confirmation.

User first goes to hotelpropertsite.com and navigates to search for their dates of stay. Once the User submits the dates of stay, they are taken to the bookingengine.com url to select the available room types and continue their purchase. In this case the hotelpropertsite.com is the "set Primary" and bookingengine.com is the "set member". Because bookingengine.com has the same branding and structure but not common ownership, it would appear to meet the definition of the "associated" sub-type. This is where the Mutual exclusivity clarification is needed. Is ONLY the Primary in the set subject to this abuse mitigation measure or does it apply to the Member as well? In the case of bookingengine.com, this domain could be an associated set member to thousands of hotels that utilize the booking engine for availability and booking.

This same use case could be a personal website that links to etsy.com to sell goods or a high school bookstore website that links to shopify.com for their apparel. In these cases, the association is obvious and the ownership is clearly different. But if the mutual exclusivity applies to any domain in a set, then these larger 3P vendors would appear to go against this abuse mitigation measure.

[johannhof]

Hi @Jack-Pritchard, 3P vendor / SaaS flows is not a use case that is currently considered in scope for First-Party-Sets, but this is good feedback (and we've received similar feedback in the past), and I generally agree that this kind of user flow should be possible when blocking cross-site cookies. It's not clear to me whether this can be done through FPS, though.

I'd also like to better understand the technical challenges that arise when cross-site cookies are blocked here. Can you tell me a bit more about what cross-site cookies would be used for in these kinds of scenarios, based on your experience?

[Jack-Pritchard]

Hi @johannhof ,

Thank you for the response back and clarification that our use-case is currently not in scope for FPS. Let me provide a little more background on our use case to see if this would be something that could be solved via FPS.

Hotel properties often use 3P vendors for their booking process. Cross-site cookies are used to follow a consumer as they go through the booking flow/process:

1. Consumer initially visits the hotel property homepage or photo page (hotelproperty.com)
2. Consumer then initiates a check-in/checkout date search for availability
3. Consumer clicks for search results ends up on a 3rd party partner booking engine website (bookingengine.com/hotelproperty) designed to look and feel like the property site
4. Consumer then completes booking on booking engine website

The way that I have understood the FPS documentation is that because hotelproperty.com and bookingengine.com are separate domains, the cross-site cookies would be blocked moving from hotelproperty.com to bookingengine.com. For Performance reporting on a campaign or website shopping behavior, cookies would need to be persistent from when a user lands on the home page (hotelproperty.com) and then eventually books (bookingengine.com/hotelproperty). Without being able to report on booking metrics to a hotel property, there would be no way to understand in detail the impact that their advertising dollars are having on their business.

Allowing this cross domain behavior will also support a consistent and personalized customer experience across this domain boundary as the consumer experience as any preferences can be passed from the hotel site to the hotel’s booking engine. It’s worth noting that from the consumer experience, it really is the same site experience and it’s for technical reasons that the domain is changing.

This is an example of the moving from the hotel property website to the 3rd party partner booking engine website. The user experience as it relates to look and feel are contiguous, and it is just the URL difference that would indicate that these are different websites to the user.

[johannhof]

Hi @Jack-Pritchard, sorry for the delay as I was on vacation. Thank you very much for outlining your scenario in more detail, that is super helpful! I agree that from a user's perspective this should be perceived as the same site or "party" they're interacting with, but it's important to consider that this perception doesn't reflect the real capabilities of bookingengine.com to recognize the user across interactions with many other sites. From a privacy perspective, we want to ensure that the perceived user boundaries match the real technological constraints.

This being considered, there are currently two possible approaches I can see here, one of which involves FPS:

1. Do something about the top-level URL of bookingengine.com/hotelproperty so that it can be included in the same FPS as hotelpropertsite.com, either by adding bookingengine.com to the PSL or CNAMEing hotelproperty.bookingengine.com to hotelpropertsite.com. To be clear, this has other (security-related) consequences that I'm not going into in detail here, but which you should consider beforehand. In both cases, a subdomain-based approach on bookingengine.com seems required.

2. Use the measurement APIs that are provided as part of the Privacy Sandbox for true cross-site measurement, e.g. Shared Storage with Private Aggregation as an output gate. This of course has other caveats as it only produces aggregate reporting and largely prevents the customization you were mentioning.

With that said, I think we should look into whether there are more ergonomic ways of enabling 1) without opening doors to abuse as described above (cc @cfredric @krgovind)