Swan (1plusX)

From Bitnami MediaWiki
Revision as of 14:51, 13 February 2021 by Jkoran (talk | contribs) (Created page with "The goal of 1plusX's Swan is to enable interest-based targeting across multiple publishers, while relying only on browser storage for these audience.<ref>https://...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The goal of 1plusX's Swan is to enable interest-based targeting across multiple publishers, while relying only on browser storage for these audience.[1]

1plusX's Swan proposal is to be commended for providing far richer audiences than Google's single cohort cluster per web client. 1plusX's Swan also attempts to partially overcome the disproportionate impact removing access to interoperable data has on smaller marketers and publishers by allowing limited audience information to be shared across domains according to First Party Sets.

The "first party" (which can operate multiple domains) can registers scripts that execute in the web client to generate the audience attributes. The "first party" also can declare which third-parties it grants read-only permission to these attributes. Thus designated third-parties can generate audiences, based on information collected within and across first party sets of domains. The web client applies the audience script to the generate a binary membership within a given audience. The proposed method of declaration is by relying on a well known location, such as specified path associated with the data controller's domain.

To avoid naming conflicts, the audience attributes are stored in per-first-party-set local storage.

The proposal allows for reading, setting, and removing audience attributes, although only when that web client interacts directly with the "first-party" domain that originally created that attribute.

The proposal suggests that the browser block the creation of audience segments that have too few user. Google's minimum threshold for audiences outside of their own properties is likely in the thousands.[2] This proposal does not describe how each web client knows the distinct count of other web clients already are members of this audience, so as to conditionally apply the audience membership rule.

The proposal suggests Turtledove ought to conduct the publishers' auction, hence has the same drawbacks associated with that proposal on impacting publisher yield, due to impaired marketer effectiveness.


1plusX is to be commended for recognizing the importance of supply chains for nearly all marketers and publishers, and proposing a method for to enable them to continue to work with one another. Another positive aspect of this proposal is the recognition of the need for marketer-defined audiences to rely on partial information gathered over time.

While this proposal addresses limited retargeting use cases, due to the first-party domain dependency it does not address cross-publisher frequency capping.

The impact on storage, processing (and battery life) and latency due to this edge processing is not addressed.

Another potential impact of removing this information is a degraded end user experience.

The reliance on the well-known path for managing supply chains shares the same limitations as ads.txt. The key issues it is has a negative impact on competition, by introducing a barrier to entry for new organizations to enter the ecosystem. This method also suffers from the related impacts to yield management cause by this friction.[3]

Open Questions

  • Why limit attribute update and delete requests based on revisiting the domain that first created them?
  • What is the value impairment associated with delaying the ability to update marketer-defined audiences?