The Privacy Sandbox Timeline for the Web – The Privacy Sandbox
Google updated the Privacy Sandbox timeline and gave more insights on what exactly will antecede 3rd-party cookies deprecation, at which time, and for how long. “Pre-launch testing” is supposed to last until the end of Q2 2023, then “General Availability” (previously known as “Transition Period #1”), which entails launching Privacy Sandbox for 100% of Chrome traffic, and is intended to stand for a year. These are going to be followed by gradual 3rd-party cookies withdrawal within a 2-month time frame in Q3 2024 (previously known as “Transition Period #2”). [Note: In April 2024, it was further postponed until early 2025]
As to where the Privacy Sandbox Origin Trials currently stand, Google stated on 11th August that the Chrome 104 Stable update expanded the Privacy Sandbox Origin Trials to 1% of the total stable Chrome user base, on top of the previously included 50% of the beta Chrome users.
Bidding and auction service proposal – Developer Chrome Blog
Google published the “Overview of FLEDGE services for Chrome and Android” article which aimed to provide information on how to leverage cloud resources in order to optimize FLEDGE’s performance. On top of that, it included referrals to relevant technical pages for developers interested in FLEDGE’s technicalities and setup.
The authors introduce a new “Bidding and auction service” proposal which is open for community feedback. Its main goal is to offload the compute-intensive execution of ad bidding and auction services from the user’s device to the so-called “Trusted Execution Environments in the cloud”, also known as TEEs.
Trusted Execution Environment is not a new concept, because ever since FLEDGE was announced, it was under the term of a “Trusted Server”, which was supposed to provide additional real-time data during the bidding process. Such data could include e.g. the remaining campaign budget. What is new is that the entire auction and bidding activities are proposed to be executed in TEEs.
The authors, similarly to other described aspects, refer to GitHub for a more technical explanation of the concept.
Apple is building a demand-side platform – Digiday
The author of this article believes that Apple is planning to develop its own DSP based on a job listing from Apple. The position is supposedly “a senior manager for a DSP in its ads platform business”. It is for now, according to the author, the only evidence on hand, as Apple refused to confirm its potential intentions.
The article lays out a hypothesis that Apple prepared the groundwork for opening its own DSP by the fact that it had been consistently devastating the digital ads business by constricting access to information essential for campaign execution in its environments (iOS and Safari).
It is unclear to what extent Apple intends to operate its DSP-to-be. It can be, according to the author, confined to its own properties (Apple Store), all iOS apps, or also 3rd-party properties (the mobile web).
For further context, an article from October 2021 in the Financial Times revealed that within 6 months after ATT (App Tracking Transparency) had been introduced, Apple more than tripled its advertising business market share. As one of the sources of the article claimed, Apple can easily benefit from limiting tracking abilities from 3rd-parties because it is “not subject to the same policy that every other ad network is” since it interprets itself as a 1st-party in that matter.
If you have any questions, comments or issues, or you’re interested in meeting with us, please get in touch.
