Alphabet’s DMA Compliance Workshop – The Power of No: A Gargantuan Task Ahead and a Dual Role in Balancing Interests
The Digital Markets Act (DMA) became entirely applicable on 7 March 2024. By then, the gatekeepers issued their compliance reports documenting their technical solutions and implementation of the DMA’s provisions under Article 11 DMA as well as their reports on consumer profiling techniques as required under Article 15 DMA (see here).
I will be covering the workshops organised by the European Commission per each of the gatekeepers under The Power of No series, where the representatives of the undertakings meet with stakeholders to grind their compliance strategies and solutions. This blog post covers the fourth workshop organised by the EC for assessing Alphabet’s compliance plans. A full review of the rest of the workshops can be found here on Apple’s, Meta’s and Amazon’s participation.
First wish granted: Alphabet conforms with the template-form
Alphabet, which is the parent company of Google’s designated services under the DMA, published its compliance report under Article 11 and the consumer profiling report under Article 15 DMA according to plan. At least, according to the European Commission’s (EC) plans.
In previous posts, I have discussed that the DMA is not a standalone piece of regulation that applies without a procedural backbone to it. Instead, the DMA is becoming more of a corpus of regulation not only comprising the provisions under the regulation in an explicit manner but also the regulatory templates that the EC released since October 2023 to accommodate the formal channels that the gatekeepers must accommodate their sending of documentation to the EC to. For the particular case, for example, of Article 11 DMA, the European Commission published the last version of its regulatory template substantially expanding on the items that the provision and its corresponding recitals highlight within the regulatory instrument. Some of those items compel the gatekeeper, for instance, to disclose whether it has performed any testing on the solutions that it proposed and how those sets of solutions align with the broader objectives of contestability and fairness embroidered into the regulatory framework.
On this count, Alphabet has delivered well above the expectations. As opposed to the previous gatekeepers that have already participated in previous workshops (namely, Apple, Amazon and Meta), Alphabet did substantively engage with the format of the regulatory template presented by the EC. A completely different discussion is, however, whether the same spirit of effective compliance has transpired in all of the gatekeeper’s compliance solutions on all of the core platform services (CPSs) that the EC designated last September. To briefly recall the reader’s mind, Alphabet stands as the top gatekeeper in terms of the number of CPSs that the EC designated for it: up to eight of its services fall within the DMA’s scope, including Google Search and Google Shopping as separate services.
Thus, the EC’s workshop was multi-faceted and brought a kaleidoscopic view of the different shades that compliance can take in different contexts. This blog post will analyse those contexts in turn, by first exploring Alphabet’s dedicated plan to expand user choice relating to the browser and search engine defaults engrained into its Android devices. Later on, the piece analyses the policy changes that Google has introduced as a result of the DMA’s application with respect to Google Play. The third part of the post considers one of the main tenets (and justifications) for the DMA’s final approval: the spin-off discussion stemming from the lagging dissatisfaction of Google’s competitors within the Google Shopping case. Finally, the post examines the high-level provisions that apply to all of the CPSs designated by the EC with respect to Google’s data-related obligations.
The rule of thumb of open-source
Unlike other gatekeepers, Alphabet does not run a tight enterprise of ecosystem management and handling in the sense that one can clearly observe with respect to Apple’s strict control over the intervening agents within its iOS ecosystems. Due to this reason, Alphabet’s obligations under Article 6(3) – which compels the gatekeeper to allow and technically enable the end user to easily change their default settings on the gatekeeper’s settings – were said to be limited, to the extent that it cannot control every decision that other operators make along the different levels of the value chain.
As it already presented in its compliance report, Alphabet presented the new choice screens that it will display to users so that they can change, if they wish to do so, both their browser apps or their search engine. Both choice screens, which are separate one from another, are being rolled out as we speak to end users in forcing them to make this choice. The gatekeeper, however, highlighted that it would not show the choice screen to those users who have another browser app installed on their devices as a default. For example, if a user on a Pixel device chooses to make Mozilla Firefox its default browser, then Alphabet has no intention to steer users away from that show.
Similarly to the choice screen that Apple presented at the compliance workshop, Alphabet’s choice screen will mandatorily require the user to scroll down across all of the options shown to it before making its decisions and the order of those browsers will be fully randomised (although full randomisation will only be completed by May). Around that same date, Alphabet also strives to include descriptions and details on the search engines and browsers to the customers directly on those choice screens so that they can make an informed choice. Notwithstanding, as opposed to Apple’s technical implementation, the end user’s choice will have a real and immediate impact on the setting of the default. As soon as the choice is made, then the app will be directly downloaded on the device via Alphabet’s proprietary app store Google Play, albeit this last part of the process could bring problems of its own.
Although Google’s approach towards compliance is satisfactory from a substantial perspective, an additional hurdle stands in the way of implementation. Given that the gatekeeper does not directly manufacture its own devices (as Apple does), it cannot mandate the application of these updates upon Original Equipment Manufacturers (OEMs) such as Samsung or LG. Due to this reason, Alphabet directly recognised that it could decide on its dedicated Pixel devices, but that rolling out those choice screens may take some time on Android devices manufactured by OEMs. As of last week, Alphabet started to progressively roll out the prompt to 1% of its Pixel devices and it aims to reach all of its Pixel devices by Monday night (25th of March).
On the side of OEM-manufactured Android devices, however, adoption may be slower. Alphabet has made it mandatory for OEMs to include the choice screen on future devices after the DMA compliance deadline on March 7, but those devices may take time to be produced and then distributed in the market. For those devices that were released into the market prior to the deadline, Alphabet has basically no power to impose the release of the choice screens but ensured both the EC and stakeholders that it would engage with OEMs so as to bundle the choice screen with other updates to their functionality. In a similar vein, to the question of a participant asking about the placement of apps on the phone, Alphabet recognised that it also had no power to decide where apps lay within its device’s home screen.
In parallel, however, Alphabet struck the weird balance that default settings and pre-loading apps on a device powered by Android is not quite the same thing. The former is covered by the DMA, whereas the latter is, according to the gatekeeper’s responses to stakeholders, mainly competition on the merits that takes place when it distributes Android via its agreements with OEMs. The theory may make more sense than the practical aspect of that statement, as one will previously recall from discussions arising from the discussions that the undertaking had to engage with in the Google Android case, now pending before the Court of Justice.
Regarding the release of the search engine choice screen on Google’s Chrome, the rolling out of the functionality is easier to perform insofar as Chrome updates on the background of most desktops (notably Windows PC OS), so that when users operating on desktops access the service, they will be forced to make the choice. The release date of the choice screen, according to Alphabet, was mid-May 2024 with the release of Chrome’s latest M125 update, which will aim to reach 150 to 200 million end users by early summer.
Staying on the topic of search engines, but now on the side of business users, Article 6(11) imposes the obligation upon search engine providers that have been designated to provide any third-party undertaking providing an online search engine, at its request, with ranking, query, click and view data in relation to free and paid search generated by end users on its online search engines. To comply with the provision, Alphabet plans to quarterly datasets including more than 1 billion distinct queries produced by end users from the 30 EEA countries, amounting to more than 1.5 TB of data. Some of the data fields included within the datasets will be those related to the country, device type, result, result type or the average rank for the query. In addition to the release of data, Alphabet has also designed strong privacy measures to ensure that the data remains anonymised, just as the DMA provides.
To cater to this data, Google will sell this data in different packages with different levels of granularity. Online search engine providers, however, must meet several conditions for eligibility, such as the fact that they must have a track record of safeguarding security to a high standard or that they have no connection to non-EEA countries. The fee structure of the European Search Dataset Licensing Program starts at EUR 3 per every 1,000 unique queries per country that are delivered for those licensees that produced less than EUR 0,5 billion in revenue in the preceding year (whilst it will charge EUR 6 and EUR 9 per every 1,000 unique countries for those licensees with revenue between EUR 0,5 billion and 1 billion and for those with more than 1 billion, correspondingly). In that sense, Alphabet presented that the indicative full quarterly EEA dataset would roughly amount to EUR 3,3 million for its lowest tier pricing. It is true, however, that third-party online search engines may also request smaller segments of the dataset, for instance, per Member State. Alphabet comprehensively presented the indicative starting prices for each of the Member States for the full quarterly dataset per country. For example, stemming from its lowest tier of pricing, access to the dataset corresponding to the Netherlands would amount to EUR 180.000, whereas access to Spain’s would tentatively reach EUR 351.000.
Once again, Alphabet recognised that it had not made it to comply in time and that will start offering these datasets for Q3 in 2023 on April 1 and will cater to the Q1 2024 in the first weeks of July 2024.
Anti-steering, billing and alternative app distribution on Android
Building on the open-source nature of its operating system, Android first sought to put forward that it substantially complies with Article 6(4) – which was designed by the EU legislator, in truth, to make Apple open up its system of distribution on its iOS ecosystem.
To that end, Alphabet presented up to three additional channels that end users may dispose of so as to download apps on their Android devices. First, Alphabet did not have any restrictions in place hindering the ability of third-party app stores to be installed on its devices. Second, end users may sideload apps directly from the web, without any charge being imposed by Alphabet. On this same point, since Android 12 was released in 2021, Alphabet has allowed automatic updates of sideloaded apps and app stores. Third, Alphabet also allows progressive web apps on its devices. To that end, Alphabet also argued that more than four quarters of apps installed on its devices come from different sources as opposed to Google Play whereas more than half of Android devices have a third-party app store pre-installed.
Alphabet’s billing system is somewhat similar to Apple’s: it charges developers a commission for the digital transactions that they complete on their ecosystem. During these last few years and due to regulatory pressure in different jurisdictions, such as South Korea, it reduced its 30% fee on digital goods and services to 15% for smaller developers. However, up until this point, Alphabet continued to force some developers (those corresponding to gaming apps) to complete their transactions through Google Play’s billing system. This will no longer be the case so all developers (of gaming or non-gaming apps) will be able to offer alternative payment processing systems.
As opposed to Apple’s compliance plan that frames its solution as an all-or-nothing choice on the side of the developer, Alphabet presents its User Choice Billing Program where developers may be able to present end users with the choice of processing their payments both on their selected payment processing provider or through Google Play’s billing system. The fee charged by Alphabet is adjusted, in this instance, by 4%. Alternatively, as a consequence of the DMA, Alphabet has launched its EEA Program so that developers have the capacity to present the payment processing provider of their choice directly to the user, which entails that the end user will not receive the prompt to transact with Google Play. In this case, the fee charged by Alphabet is adjusted by 3%. Due to their distinct nature and functionality, the adoption of these programs for the developers is, again, not framed in an all-or-nothing fashion. Alphabet has made it possible for developers to present one type of choice screen for payment processing at the game or app level, so that each type of app may benefit from different types of payment processing, depending on their content and the distinct types of user engagement.
Despite that Alphabet has not introduced any new fees with regard to alternative payment processing, the anti-steering provision under Article 5(4) has some role to play in the new fee structure that Apple will apply in those instances where end users make the choice to complete transactions outside of the developer’s app via a link-out, following the External Offers Program that it has put in place to apply the DMA’s provisions. By doing this, Alphabet will charge developers for the initial acquisition of users, and not an upfront fee over all transactions completed. The rationale underlying Alphabet’s technical implementation is to only charge developers (even if transactions are completed via a link-out) for those transactions that it has played a major role in and to avoid any double charging with those transactions where it has not intervened as a major player. One must remark on the fact that Recital 40 DMA explicitly provides that the anti-steering obligation may be complied with by the gatekeeper either for free or on a paid basis. The limitation that the DMA imposes is that only initial acquisitions may be charged.
Therefore, Alphabet has managed to architecture a complex subset of fees that will apply depending on the scenario presented before the developer. On the side of the initial acquisition fee, the developer will be charged 5% of the transaction within two years after the first external transaction is completed, and it will charge an ongoing services fee of 7%, which the developer can opt-out of after the second year. The two-year lapse of the initial acquisition fee will apply automatically and does not require an opt-out on the side of the developer to stop applying. On the side of the ongoing services fee that Alphabet applies to all its providers, the developer may choose whether to opt-out of the additional and ongoing services that Play provides to it such as its security services or its infrastructure to distribute, update and reinstall apps. In case the developer opts out, then nothing will be charged on this second front, although the developer will have to significantly invest in these services in isolation. Alternatively, will be charged 17% if it does not opt out from being catered to Play’s ongoing services.
Dangerous liaisons: the prohibition on self-preferencing or how to explain one’s way through the obligation of self-preferencing
Article 6(5) explicitly provides that the gatekeeper shall not treat more favourably, in ranking and related indexing and crawling, its own services as opposed to similar services or products catered by a third party. The prohibition, one must recall, is a direct transplant, in origin, from the long-lasting drama (which still prevails!) surrounding the EC’s case on Google Android. One could go as far as saying that the case opened Pandora’s box for the introduction of the DMA. Expectations, on this front – and particularly on the side of comparison-shopping services (CSSs) – were high.
Ironically, none of the solutions that Alphabet presented within the compliance workshop aimed to (finally!) close the gap between CSS and its Shopping unit, nor to settle the matter entirely. Alphabet’s compliance plan in applying Article 6(5) revolved around the displaying of search results with respect to vertical search services (VSSs) and direct suppliers.
The solutions were two-faced: they subtracted some features from the search results, but they also embedded functionality into them. On one side, Alphabet has, for instance, eliminated all those instances where it linked VSSs with its own services via a direct link, such as Google Hotels or Google Flights. On the other side, it has enabled both VSSs and direct suppliers to show additional information directly on the search results page by showcasing imagery, pricing and reviews via dedicated carousels aimed at making the end user’s experience more seamless. On the side of direct suppliers, for instance, Alphabet has also added website links directly to their webpages and it has also introduced ‘chips’ (that is, the labels at the top of Google Search) dedicated to the catering of their services, such as Product or Flights.
Even in these particular cases where VSSs and direct suppliers such as hotels, airlines or restaurants have been directly impacted, the reaction from the vast majority of the stakeholders was wholly negative. Some stakeholders argued that despite their constant participation in previous non-public workshops organised both by the EC and Alphabet where they proactively shared feedback with the gatekeeper, they felt overall frustrated that it had been unheard. It is true, in this respect, that Alphabet recognised within its compliance report that it could not reconcile or integrate most of the feedback of stakeholders due to its particularly contradictory nature. Therefore, by listening to none, it obliviated both of their interests in the balancing act that Alphabet’s representatives sought to defend throughout the day that they had performed. For instance, direct suppliers such as hotels complained about the fact that the new display of direct suppliers hinders their capacity to be competitive in the online environment insofar as Alphabet establishes an additional layer of intermediation to them directly by providing a list of comparison sites (Booking.com being the most prominent player in that market) that directly compete with them on price.
From the extensive (and perhaps not perfectly constructive, despite the EC’s efforts) exchanges between stakeholders and Alphabet, two main tenets of the discussion permeated the underlying debate. First, Alphabet’s indicators for compliance with the particular provision are somewhat unclear. When asked directly on this same point, Alphabet’s legal representative stressed that Article 6(5) does not require the gatekeeper to deliver on outcomes. In other words, the provision is not designed to compel the gatekeeper to send traffic to its competitors, but it is only aimed at providing parity treatment to its competitors on its gateway. Thus, outcomes are clearly not the goal of effective compliance. On the contrary, when Alphabet was accused of not going far enough for some stakeholders and not going too far by others, Alphabet slightly changed its argument and rephrased the underlying rationale that it has applied to designing its solution to comply with Article 6(5) DMA. According to the gatekeeper, it first must determine what nature of services it provides to the market within its Google Search CPS and, from there, it must concretise what opportunities it needs to make sure that it provides to others with whom it directly competes. Once it does both of those mental exercises, then the gatekeeper must assess the countervailing impact of the decisions resulting from them, bearing in mind the number of links, positioning, display, format and ranking that it has administered to its competitors to try to mitigate huge impacts on its competitors. Second, as one of the stakeholders made perfectly clear to end the round of questions, the problem with the gatekeeper’s solutions is not that they are more or less aligned with the letter of the law. Instead, Alphabet is compelled to determine at what level it competes with other operators and how it should integrate its solutions so as to level the playing field between its own position and that of its competitors, but not by opposing the interests of the different types of stakeholders against each other.
Honouring data choices and the Portability API
On the last panel of the staggeringly long workshop organised by the European Commission, Alphabet set out the means of its compliance with its data-related obligations relating to Articles 5(2) and 6(9) DMA.
Article 5(2) prohibits data combination unless the gatekeeper seeks consent from the end user to perform processing, cross-using, or combining of personal data across its CPSs. To that end, Alphabet presented the changes it introduced in the front-end experience of end users and the safeguards that it has introduced to honour those same decisions across the processing of its data at the back end of its data infrastructure.
In terms of the former, Alphabet introduced (yet another!) prompt so that users could select whether they wished to link their services’ data with each other or not. The prompt is nothing particularly new or different to the similar choice screens presented by other gatekeepers, aside from the fact that Alphabet was clear in establishing that it did not charge its end users if they chose not to consent to data processing (as opposed to Meta) and that the choice of the end user would not only impact the use of that same for the means of personalising online advertising but also of personalising its products and the content shown directly on its different interfaces. To a question of one of the participants in the workshop, Alphabet further explained that its choice screen worked on top of its already existing consent frameworks for personalised advertising. Therefore, data flows of personalised advertising to other services (and CPSs) could only happen in the case that end users consented twice to the processing in these two distinct ways.
From the technical perspective, Alphabet has pre-emptively separated (through consent gates) the data flows of personal data across its CPSs with non-CPSs. Therefore, only if the end user affirmatively consents to the data flow, then the gate will be unlocked and, thus, cross-using and combinations of data will be possible. To this particular end, Alphabet labels its data according to each one of the CPSs it belongs with so that one piece of information is clearly identifiable from another one from the perspective of the low levels of its technical infrastructure.
On the side of the portability obligation that Article 6(9) opens up for end users and for them to authorise third parties to gain continuous and real-time access to their data to increase contestability, Alphabet presented that its already existing Takeout functionality caters to that purpose for end users whereas it has built up its Portability API to operate that task for third parties authorised by end users. On this last tenet, however, Alphabet failed to refer to the fact that the Portability API will not authorise third parties to perform recurring calls for access despite if they have been fully authorised by end users to do just that.
Key takeaways
Alphabet’s compliance workshop was the most exhausting and exhaustive. It is true that the ask ahead of Alphabet’s representatives was not small, given that it had to explain and detail how it complied with some of the DMA’s provisions with respect to eight different CPSs. As some stakeholders already highlighted throughout, there are ‘blatant’ spots of non-compliance that one can quickly point to if one reads the compliance report or if one listened in on the workshop for a couple of hours. Alphabet’s clear omission of any reference to any type of solution for Google Shopping and/or directed at CSSs is the most evident of all of them. It might not be wise to finish off with the EC’s case in this alternative DMA-driven way, from an institutional perspective, at least in light of the ECJ’s imminent ruling on the case. However, clear repercussions will stem throughout.
As one stakeholder put it: is Alphabet up to assume the consequences of non-compliance in the interim?
