Are there non-tracking uses of redirect bounces not enumerated in the explainer?

[wanderview]

If so, are there new signals that can be used to exclude these uses from impact?

[bc-pi]

Delegated authorization (i.e. OAuth) is also a legit use of redirect bounces. From the browser perspective, it looks like the Federated Authentication so I don't think it needs any different/specific treatment. But might be worth mentioning explicitly as a supported use case not to break.

SAML is still widely in use. Particularly in "workforce to SaaS" type use cases where the so called IDP initiated flow is often used to SSO from a portal like page into various apps. From the browser perspective, this will look a lot like Redirect Bounce on an Outgoing Navigation. I don't think this needs any different/specific treatment either but thought it was worth mentioning.

These authn/authz protocols sometimes use an auto-submitting form post for cross-site navigation (OAuth 2.0 Form Post Response Mode and the SAML POST Binding being examples of such). I kinda assume that kind of thing is covered in this work as general top-level navigation. But, again, thought it was worth mentioning just in case.

Lastly, there are also non-standard authn/authz flows out there that are nonetheless legitimate. AFAIK though they mostly look the same at this level from the browser perspective so are probably okay.

[t-zuehlsdorff]

Aloha,

Please let me add that there is a whole market segment using non-tracking redirect bounces. It started in 2016 in Germany, and (disclaimer) my own company Bounce Commerce is the biggest example of it, with around 400 clients in the Affiliate / Performance Marketing market.

We use redirects after bounces, but only if the user previously consented to this, using the mandatory Cookie Banner.

In the last years, some other companies have joined the market, and the service is used actively in companies in ~ 15 countries, from Europe to the US. While the market is relatively small, we alone brought our clients around 50 Mio € in additional sales.

Suppressing the redirects in the first 10 seconds would basically kill most of the market. Since we have a very high standard of data protection and all our clients require consent from their users for our services, i would like to add this as valid case which should not be impacted. :D

[wanderview]

@t-zuehlsdorff FWIW the affiliate link bounce would likely currently be impacted by bounce tracking mitigations. We view this use as similar to 3P cookies in its semantic behavior.

There are currently two options you could investigate:

1. Navigate to your domain during the bounce to show a page that explains that the domain is facilitating a potential purchase. When the user clicks on the acknowledgement on your domain, then the domain would be protected from BTM enforcement for 45 days.

2. Investigate possibly using ARA instead of a bounce flow: https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting

[t-zuehlsdorff]

@wanderview Thank you for your explanation. However this did not cover the technique, only the Affiliate Links which are optional and way later in the process. While affiliate links are most commonly used, these are used on the sides after a redirect. So a typical process flow is:

• Visitor goes from Google to Example.com
• Visitor hits Back Button
• Visitor is redirected to another page instead of Google
  (* If visitor hits Back Button again, Google will show up)

"redirected to another page" can have 3 different aims:

• A third party URL (different Domain same Owner, different Domain with Content provided by Third party, etc.)
• A Subdomain of the initial domain, like subdomain.example.com
• Another page like example.com/redirect-page

As far as I understand the current draft, every type of aim is prohibited. I also can't see how the 45 days should work in real life, especially in this flow.

ARA does not apply to this bounce flow at all. These services do not attribute anything - they just provide content to re-engage bouncing visitors.

Since we are in Europe half of the services do not track/log anything about the user. The other half tracks some of the user flow, but has explicit consent for it, like required by EU laws (GDPR in General, TDDDSG in Germany especially). Does the Cookie Consent Banner provide this consent enough to fulfill the acknowledgment? Please excuse my lengthy questions. I read the draft multiple times and can't find the answers. Not sure if its because English is not my mother tongue or if it's not specified yet.

Thank you!

[wanderview]

@t-zuehlsdorff Can you open a separate issue for your use case? I'm not sure I fully understand all the flows and I'd like to avoid having too much forking on conversations in this issue as there are other use cases that may be discussed here. Having a discussion in a separate issue seems like it would help. Thanks.

[t-zuehlsdorff]

Sure @wanderview, will do :)