Federal Court of Australia
Epic Games, Inc v Google LLC [2025] FCA 901
File number: | NSD 190 of 2021 |
Judgment of: | BEACH J |
Date of judgment: | 12 August 2025 |
Catchwords: | COMPETITION LAW — digital technology — Android mobile devices — operating system software — original equipment manufacturers — Google mobile services — anti-fragmentation agreement — Android compatibility commitment —smart phones — tablets — personal computers — native apps — web apps — web browsers — Google’s Play Store — downloading apps — installing apps — app developers — access to platforms — two-sided platforms — platform operators — market definition — market power — mobile OS licensing market — distribution services market — market for payment services — restrictive conduct in distribution market and payments market — security and technology considerations and constraints — misuse of market power — imposition of restrictive contractual conditions — substantial lessening of competition — purpose questions — effects questions — contraventions of s 46 of the Competition and Consumer Act 2010 (Cth) — alleged contraventions of ss 45 and 47 — unconscionable conduct — alleged contravention of s 21 of the Australian Consumer Law |
Legislation: | Competition and Consumer Act 2010 (Cth) ss 4, 4E, 4F, 4G, 5, 45, 46, 47, 51, sch 2 ss 21, 22 |
Cases cited: | Australian Competition and Consumer Commission v Air New Zealand Ltd (2014) 319 ALR 388 Australian Competition and Consumer Commission v Metcash Trading Ltd (2011) 198 FCR 297 Australian Competition and Consumer Commission v Pacific National Pty Ltd (2020) 277 FCR 49 Australian Competition and Consumer Commission v Pacific National Pty Ltd (No 2) [2019] FCA 669; (2019) ATPR ¶42-633 Australian Competition and Consumer Commission v P T Garuda Indonesia Ltd (2016) 244 FCR 190 Epic Games Inc v. Apple Inc 67 F.4th 946 (2023) (9th Circuit, Court of Appeals) Federal Trade Commission v. Advocate Health Care Network 841 F.3d 460 (2016) (7th Circuit, Court of Appeals) Federal Trade Commission v. Penn State Hershey Medical Centre 838 F.3d 327 (2016) (3rd Circuit, Court of Appeals) Federal Trade Commission v Tenet Health Care 186 F.3d 1045 (1999) (8th Circuit, Court of Appeals) Re Duke Eastern Gas Pipeline Pty Ltd (2001) 162 FLR 1 Re Fortescue Metals Group Ltd (2010) 271 ALR 256 Re Qantas Airways Limited (2004) ATPR 42–027 Re Southeastern Milk Antitrust Litigation 739 F.3d 262 (2014) (6th Circuit, Court of Appeals) United States v. American Express Company 838 F.3d 179 (2016) (2nd Circuit, Court of Appeals) Athey S, Chetty R, Imbens G and Kang H, “The Surrogate Index: Combining Short-Term Proxies to Estimate Long-Term Treatment Effects More Rapidly and Precisely” (2019, Working Paper, National Bureau of Economic Research) Cameron A and Trivedi P, Microeconometrics: Methods and Applications (Cambridge University Press, 2005) Chandar B et al, “The Drivers of Social Preferences: Evidence from a Nationwide Tipping Field Experiment” (2019, Working Paper, National Bureau of Economic Research) Davis P and Garcés E, Quantitative Techniques for Competition and Antitrust Analysis (2009, Princeton University Press) Decarolis F, Li M and Paternollo F, “Competition and Defaults in Online Search” (2023, Discussion Paper, Centre for Economic Policy Research) Evans D and Salinger M, “The Role of Cost in Determining When Firms Offer Bundles” (2008) 56(1) The Journal of Industrial Economics 143 Felt A et al, “Improving SSL Warnings: Comprehension and Adherence” (2015, Conference Paper, CHI 2015 Crossings, Korea) Filistrucchi L, “A SSNIP Test for Two-sided Markets: The Case of Media” (2008, NET Institute Working Paper) Filistrucchi L et al, “Market Definition in Two-Sided Markets: Theory and Practice” (2014) 10(2) Journal of Competition Law & Economics 293 Gneezy U and List J, The Why Axis: Hidden Motives and the Undiscovered Economics of Everyday Life (2013, Public Affairs) Haggag K and Paci G, “Default Tips” (2014) 6(3) American Economic Journal 1 Hovenkamp H, The Antitrust Enterprise: Principle and Execution (Harvard University Press, 2005) Katz M and Shapiro C, “Critical Loss: Let’s Tell the Whole Story” (2003) 17(2) Antitrust 49 Kotzias P et al, “How Did That Get In My Phone? Unwanted App Distribution on Android Devices” (2021) (Published at the 42nd IEEE Symposium on Security and Privacy, California) Lindenberg E and Ross S, “Tobin’s q Ratio and Industrial Organization” (1981) 54(1) Journal of Business 1 Mayrhofer R et al, “The Android Platform Security Model” (2021) 24(3) ACM Transactions on Privacy and Security Salinger M, “A Graphical Analysis of Bundling” (1995) 68(1) Journal of Business 85 Smitizsky G, Liu W and Gneezy U, “The endowment effect: Loss aversion or a buy-sell discrepancy?” (2021) 150(9) Journal of Experimental Psychology: General 1890 |
Division: | General Division |
Registry: | New South Wales |
National Practice Area: | Commercial and Corporations |
Sub-area: | Economic Regulator, Competition and Access |
Number of paragraphs: | 6370 |
Dates of hearing: | 15, 18 to 21, 25 to 28 March, 2 to 4, 8 to 11, 15 to 18, 22 to 24, 29, 30 April, 1, 2, 6 to 9, 13 to 16, 20 to 23, 27 to 30 May, 3 to 7, 11 to 14, 17 to 20, 24 to 28 June, 1 to 5 July 2024 |
Counsel for the Applicants: | Mr N J Young KC, Mr G K J Rich SC, Dr R C A Higgins SC, Mr T O Prince, Mr A d’Arville, Mr A Barraclough, Mr O Ciolek, Ms K Lindeman, Mr B Hancock, Mr J T Waller, Ms J Apel and Mr R R Marsh |
Solicitor for the Applicants: | Allens |
Counsel for the Respondents: | Mr C A Moore SC, Mr R A Yezerski SC, Mr P J Strickland, Ms C Trahanas and Ms W Liu |
Counsel for the Respondents (confidentiality issues only): | Ms E N Madalin and Mr A Hanna |
Solicitor for the Respondents: | Corrs Chambers Westgarth |
Counsel for the Respondents (Apple parties) in NSD 1236 of 2020 and VID 341 of 2022: | Mr M J Darke SC, Mr S Free SC, Mr C Bannan, Ms Z Hillman, Ms L Thomas, Ms X Teo and Mr B Lim |
Solicitor for the Respondents (Apple parties) in NSD 1236 of 2020 and VID 341 of 2022: | Clayton Utz |
Counsel for the Applicants in VID 341 of 2022 and VID 342 of 2022 (class actions): | Mr A J L Bannon SC, Mr N De Young KC, Ms K Burke, Mr D Preston, Mr B Ryde and Dr S Chordia |
Solicitors for the Applicants in VID 341 of 2022 and VID 342 of 2022 (class actions): | Phi Finney McDonald and Maurice Blackburn |
ORDERS
NSD 190 of 2021 | ||
| ||
BETWEEN: | EPIC GAMES, INC First Applicant EPIC GAMES INTERNATIONAL S.A R.L Second Applicant EPIC GAMES ENTERTAINMENT INTERNATIONAL GMBH Third Applicant | |
AND: | GOOGLE LLC First Respondent GOOGLE ASIA PACIFIC PTE LTD Second Respondent GOOGLE PAYMENT AUSTRALIA PTY LTD Third Respondent |
order made by: | BEACH J |
DATE OF ORDER: | 12 august 2025 |
THE COURT ORDERS THAT:
1. The further hearing of the proceeding be stood over to a date to be fixed.
2. Save for the oral summary of these reasons given by Beach J at the time of delivery of this judgment and any republication in any form of that summary, pursuant to s 37AF(1) of the Federal Court of Australia Act 1976 (Cth) and on the ground set out in s 37AG(1)(a), subject to further order, disclosure and publication of these written reasons and the content thereof shall only be made to the parties’ external legal advisors in this proceeding and in proceedings NSD 1236 of 2020, VID 341 of 2022 and VID 342 of 2022, and to no other person.
3. Liberty to apply.
4. Costs reserved.
Note: Entry of orders is dealt with in Rule 39.32 of the Federal Court Rules 2011.
REASONS FOR JUDGMENT
BEACH J:
1 There are four proceedings before me, the joint trial of which took place over a period of four months on questions of liability.
2 In the first proceeding, the Epic parties have made claims against the Apple parties principally concerning alleged contraventions of s 46 and other provisions of the Competition and Consumer Act 2010 (Cth) (CCA). I have set out the relief that they seek elsewhere.
3 The Epic parties are involved in developing entertainment software for personal computers, smart mobile devices and gaming consoles, with their most popular game being Fortnite. They allege that the Apple parties’ contravening conduct has forced app developers including Epic to only use Apple’s App Store to distribute their software applications (apps) to the broad base of iOS device users, and to only use Apple’s payment system for processing the purchases of their in-app digital content by iOS device users. Apple removed Fortnite from the App Store on 13 August 2020. That step has provoked the present litigation against the Apple parties.
4 I have delivered a separate set of reasons dealing with the first proceeding (Epic Games, Inc v Apple Inc [2025] FCA 900).
5 In the second proceeding, which these present reasons deal with, the Epic parties have made claims against the Google parties principally also concerning analogous alleged contraventions of s 46 and other provisions of the CCA. The relief that they seek is directed at gaining more access to Google’s digital ecosystem which does allow some access but is akin to a nature reserve protected by a large barbed-wire fence.
6 They allege that the Google parties’ contravening conduct has hindered the ability of app developers including Epic to distribute apps to Android devices in a realistic and practical way other than through Google’s Play Store. It is said that Google has achieved this by imposing various contractual and technical restrictions, which stifle or block Android device users’ ability to download app stores and apps directly from developers’ websites and prevent or hinder competition in the distribution of apps to Android devices. It is also said that Google has inappropriately imposed on app developers Google’s payment system for processing the purchases of in-app digital content by Android device users. I will explain the detail of this in a moment. Google removed Fortnite from the Play Store on 13 August 2020. That step has also provoked the present litigation against the Google parties.
7 The third and fourth proceedings are representative proceedings commenced by the representative applicants under Part IVA of the Federal Court of Australia Act 1976 (Cth) where similar allegations have been made by them on behalf of group members against the Apple parties and the Google parties concerning the same contraventions of s 46 of the CCA as alleged in the first proceeding and the second proceeding. One of the class actions is against the Apple parties concerning inter-alia the overcharging of commissions on the App Store. The other class action is against the Google parties concerning inter-alia the overcharging of commissions on the Play Store. In each case it is said that the contraventions caused app developers to pay materially higher commissions on paid app downloads and in-app purchases of digital content than they would otherwise have had to pay had the contravening conduct not occurred.
8 I have delivered a separate set of reasons dealing with both the third and fourth proceedings (Anthony v Apple Inc; McDonald v Google LLC ([2025] FCA 902).
9 I will say something more about the joint trial and how these reasons should be read a little later. But for the moment let me introduce the case against the Google parties in some more detail.
10 Epic’s case is that Google has used its control of the Android ecosystem to stifle competition in app distribution and in payment solutions for Android apps. It is said that as a result of Google’s conduct, Google’s Play Store is the default and predominant distributor of Android apps, and is not meaningfully subject to the forces of competition. And it is said that in exchange for access to the Play Store, app developers are compelled to use Google’s payment solution, Google Play Billing, as their sole supplier of services for facilitating, including accepting, processing, collecting, and remitting, payments for in-app purchases of digital content.
11 Further, it is said that in order to secure, and to prevent any challenger from threatening, Google’s control of app distribution and in-app payment solutions within the Android ecosystem, Google imposes and enforces a set of contractual and related arrangements on app developers and on the original equipment manufacturers (OEMs) of smartphones and tablets.
12 Epic’s case is that every OEM that wishes to sell smart mobile devices needs to pre-install an operating system (OS) for those devices. Now the Android OS, which is owned by Google, is an operating system for mobile devices being smartphones and tablets, based on the open source Linux OS.
13 Google makes Android OS available for free under an open source licence being the Apache 2.0 licence via the Android Open Source Project (AOSP). So, Google makes the source code for that software publicly available for use and modification. At the time of trial there had been 14 iterations of the Android OS, with Android 15 in beta phase. But apparently Android 15 was released in late 2024. The Android OS is available to be modified by OEMs.
14 The Android OS is the foundation of what has been described as the Android ecosystem, which comprises the Android OS, the products and services that support the Android OS, as well as the participants in that ecosystem, being users, OEMs, developers, carriers and Google.
15 Now the development and success of Android as an OS depends upon its ability to attract OEMs to develop Android-compatible devices, its ability to attract developers to develop apps for Android and its ability to attract users to acquire Android devices and apps, each of which is related to the others.
16 The notion that Android is an ecosystem reflects the fact that there is interdependence between these participants. This dynamic of interdependence is relevant to understanding the commercial realities of any competition or any competitive constraints faced by Google, Android and the Play Store.
17 Android connects OEMs who make Android devices, telecommunications carriers who supply mobile services on Android devices, app developers who develop apps for Android devices, and consumers who use Android devices and Android apps. As I have said in my reasons in the Apple proceeding, multi-sided platforms involve indirect network effects which can create feedback loops across the platform. These indirect network effects manifest strongly with respect to Android. The more consumers that want to acquire Android devices, the greater the incentive for OEMs to make Android devices and for developers to develop apps for the Android OS. The better the range and quality of Android devices and Android apps, the more attractive Android devices become for consumers.
18 These network effects create economic challenges. In particular, the continued success of Android depends upon it overcoming coordination problems and agency problems. Now a coordination problem arises when the value that one participant derives from a platform is linked to the participation of other users on the platform. Further, an agency problem arises in situations where participants are incentivised to act in ways that may harm other participants or the platform overall, such as some OEMs or developers engaging in malicious privacy or security practices that reduce consumers’ willingness to purchase Android devices.
19 Coordination and agency problems manifest in multi-sided platforms due to indirect network effects.
20 In the case of Android, the interests of users, OEMs, developers and carriers must be balanced so that each group is sufficiently incentivised to participate. In the absence of such balance, the Android ecosystem may be unable to attract and sustain sufficient engagement and investment from participants on all sides of the platform, being OEMs, developers, users and carriers. Were that to occur, Android may cease to remain competitive.
21 In the case of Android, risks are mitigated, in part, by the contracts Google enters into with OEMs. These contracts overcome coordination problems, and enhance the attractiveness of Android to both users and developers. By comparison, Apple manages risks through vertical integration.
22 Now as I have said, Google owns the Android OS and makes its source code available to third parties free of charge under an open source licence. I will refer to this version of Android as open source Android. Open source Android does not include a suite of software apps, software development kits (SDKs) and application programming interfaces (APIs) that are owned by Google and known as Google Mobile Services (GMS).
23 A smart mobile device which does not have GMS installed is functionally limited, because most non-iOS apps are built using GMS APIs or SDKs supplied by Google and those apps will only run as intended on devices that have GMS installed. Further, GMS includes six core applications developed by Google that are among the most used apps in the world, being the Play Store, Google Search, Chrome, Google Maps, Gmail and YouTube.
24 In theory, an OEM can do without GMS. It can license an Android fork, which is a modified version of open source Android which does not comply with compatibility standards set by Google. It can also create its own mobile OS. But few OEMs do either of these things and those that do end up with market shares that are miniscule. Instead, the vast majority of non-iOS smart mobile devices distributed outside of China with a licensable mobile OS are pre-installed with a combination of open source Android and GMS. For convenience, I will refer to that combination as GMS Android or Google Android, although I accept Google’s point that this is not supplied by it as a unitary product.
25 Now to obtain the right to distribute devices with GMS Android pre-installed, OEMs must enter into a mobile application distribution agreement (MADA) with Google.
26 The MADA grants OEMs a license to distribute their devices with GMS pre-installed, but on conditions that, first, certain apps nominated by Google, including the Play Store, must be pre-installed on those devices, second, those Google apps must be placed in specified prominent locations on the OEM’s device, third, the OEM must comply, and their devices must be tested for compliance, with numerous technical requirements set by Google, including restrictions on which apps are allowed to install other apps and, fourth, the OEM must ensure ongoing compliance with the Android Compatibility Commitment (ACC) as part of the Android compatibility program.
27 An ACC is a nominally separate contract between the OEM and Google. In general terms, it precludes OEMs from distributing devices that run on an Android fork. It operates together with a MADA so that, for so long as an OEM wants to distribute devices with GMS Android pre-installed, it cannot distribute any devices that run on an Android fork. This explains the dearth of non-Apple smart mobile devices distributed outside China that run on something other than GMS Android.
28 The effect of the anti-fragmentation agreements (AFAs) and the ACCs is that some OEMs have committed to certain core functionality and baseline standards, which ensures that developers and users have a consistent experience in developing for and using Android devices. That is because departures from or modifications to the Android OS source code may result in so-called “forked” devices, being devices on which apps developed for Android either do not function, or do not function correctly.
29 This is the problem of device fragmentation, which arises when there is incompatibility between devices notwithstanding that they notionally operate on the same operating system.
30 As their names suggest, the AFAs and ACCs address the risk of device fragmentation by promoting compatibility between Android devices. Devices that comply with the compatibility standards agreed in the AFAs and ACCs are often referred to as compatible Android devices and are so approved under what has been described as the Android compatibility program. Google did not, and does not, charge OEMs any fee under the AFAs or ACCs.
31 Further, some OEMs have entered into MADAs with Google under which, as discussed above, Google licenses the OEMs to use GMS. That package of software includes familiar Google apps such as Google Maps, Chrome and YouTube. These are high quality apps which certain OEMs want to have on their devices. Google also licenses OEMs to use the “Android” and “Google” trademarks under the MADAs in relation to compatible Android devices. Outside of Europe and Turkey, Google does not charge OEMs a licensing or other fee under the MADAs.
32 Of course, many OEMs do want to develop, manufacture and sell Android devices that satisfy the AOSP compatibility standards, which use GMS and which can be marketed and sold using the Android trademark. Such devices may be referred to as Android devices although they might more accurately be described as GMS devices.
33 That OEMs who wish to develop, manufacture and sell Android devices must enter into a MADA with Google is unremarkable in circumstances where that is the means by which Google licenses OEMs to use Google’s proprietary software, being GMS, and intellectual property.
34 According to Epic, to ensure this situation never changes, Google has entered into incentive agreements with most OEMs, whereby they receive a portion of Google’s advertising revenues earned from the OEM’s devices. Such incentives are conditional upon OEMs complying with their MADAs and ACCs. Further, certain OEMs have entered into incentive arrangements which entitle them to a portion of Google’s Play Store revenues, provided the OEMs do not pre-install or promote a competing app store. I will address what have been described as the Premier-tier revenue sharing agreements (RSA3s) and mobile incentive agreements (MIAs) later.
35 Let me now say something about the distribution of Android apps.
36 It is possible to distribute Android apps to Android device users via pre-installation on the device prior to its sale, or else via download to the device after sale, from the Play Store, a third-party app store that may come pre-installed on the device such as the Samsung Galaxy Store, or be directly downloaded onto the device, or via a website. Acquiring an app from a website is referred to as direct downloading or, in some cases, sideloading.
37 Google does not permit third-party app stores or any app that facilitates the distribution of another app to be distributed through the Play Store.
38 Pre-installation requires the agreement of the device’s OEM. Often the agreement of mobile telecommunications carriers is also necessary. Carriers supply devices to users subject to mobile plans, being so-called locked devices, and have a say in what apps are pre-installed on locked devices. Different carriers operate in different territories such that securing pre-installation is a complex endeavour.
39 Although direct downloading of apps and app stores is possible on Android devices, less than 3% of new apps downloaded to Android devices in Australia during 2020 were directly downloaded or downloaded from an app store that was itself directly downloaded. Globally, the relevant proportion was under 12%. Three major challenges attend this distribution method.
40 The first challenge is one of discoverability, that is, of being found or noticed by users. If the app or app store is made available in the vast cyberspace of the internet, rather than within a dedicated and searchable app store that is already installed on users’ devices, it is far less likely to be found by users.
41 The second challenge is that several additional steps and warnings are injected into the sideloading process. These frictions stem from restrictions with which Google requires OEMs to comply as a condition of distributing devices with GMS installed. I will refer to these collectively as the technical restrictions.
42 The third challenge is that directly downloaded apps are functionally deficient, in that they generally do not update automatically. Instead, they must be updated manually, which requires the user to reinstall the app from the original source to obtain the updated version. Until Android 12 was released in October 2021, the same was generally true for apps sourced from a directly downloaded app store. It is only since October 2021 that Google has permitted directly downloaded app stores to update apps automatically.
43 Now it is said by Epic that within this realm, developers like Epic, who wish to distribute apps to the users of smart mobile devices with GMS installed, which for convenience I will refer to as Android devices or GMS devices, have been forced to operate. And it is a realm in which the Play Store is pre-installed in a prominent location on almost every Android device, and in which about 97% in Australia and about 91% globally, excluding China, of new app downloads through Android app stores are undertaken via the Play Store. Its closest rival in Australia, being Samsung’s Galaxy Store, has a share of only about 1.5% of app downloads and its closest rival globally, being Oppo Store, has a share of only about 2.5%.
44 Now it is possible for developers to distribute their apps to Android device users by methods other than app stores. But Epic says that none of those methods are a substitute for distribution through an Android app store. And the only Android app store with a more than negligible market share is the Play Store.
45 Now developers do not need Google’s consent or permission to develop or distribute apps for Android. Developers have a range of alternatives for distributing apps on Android. These include reaching pre-installation or pre-loading agreements with OEMs or carriers, installing via a pre-installed third-party app store, downloading or sideloading apps or app stores from a website, via streaming or in the form of a web app. A web app is an application accessed through a web browser. And developers can distribute through any of these means without entering into any agreement with Google.
46 But developers cannot distribute their apps through the Play Store unless they enter into a developer distribution agreement (DDA) with Google, the terms of which are essentially non-negotiable.
47 Under the DDA, developers are prohibited from distributing an app store or any app that distributes another app through the Play Store. Google claims this prohibition is necessary for security reasons. The result is that rival Android app stores, and indeed any Android app that distributes another app, are denied access to the Play Store. They cannot be distributed via the most effective means of Android app distribution.
48 The DDA also provides that app developers that monetise their Play Store apps through in-app purchases of digital content must use Google’s own payment solution, Google Play Billing, to facilitate such payments. The parties have described this as the payments tie. When a user makes an in-app purchase of digital content using Google Play Billing, Google charges the developer a service fee, which is ordinarily 30% or 15% of the in-app purchase price.
49 Google requires that app developers use Google Play Billing as their payment solution for in-app purchases of digital content within apps downloaded from the Play Store. There are some limited exceptions to this. Google does not require the use of Google Play Billing for in-app purchases of physical goods and services. Other payment solutions including those provided by third-parties such as PayPal, Stripe, Adyen and Braintree are used to purchase physical goods or services within apps distributed through the Play Store.
50 Additionally, the DDA includes an anti-steering rule, which prohibits Play Store apps from leading users to a payment method besides Google Play Billing. So, developers cannot include within their apps a link to a website where payment can be made.
51 The final set of agreements which are of present concern are known as the Games Velocity Program (GVP) agreements and Apps Velocity Program (AVP) agreements, whose genesis was Project Hug which I will describe in detail later. These were made with certain large developers, which were described by Google as “beacons of the ecosystem” and many of whom Google considered to be at risk of distributing their Android apps outside the Play Store.
52 Now it is Google’s conduct in entering into and enforcing these various arrangements which is the subject of these proceedings.
53 Epic says that this conduct occurred in three relevant markets being, first, a market for the supply of mobile OS licenses to OEMs, second, a market for the supply of services for the distribution of Android apps and, third, a market for the supply of services for facilitating payments for the purchase of digital content within Android apps.
54 Now the posited mobile OS licensing market is a market for the supply of licenses for mobile operating systems, where the geographic dimension of the market is a global market excluding China, of which Australia forms part.
55 The posited Android mobile app distribution market is a market for the supply of services for the distribution of Android apps to Android smart mobile device users, with the following elements or dimensions. It is said that the services consist of the provision of services to app developers enabling or facilitating app developers to reach, offer and provide Android smart mobile devices users with Android apps and associated updates and/or the provision of services to Android smart mobile devices users enabling or facilitating Android smart mobile devices users to be presented with or to find, obtain and utilise Android apps and associated updates. And it is said that the geographic dimension of the market is Australia or a global market excluding China, of which Australia forms part.
56 The posited Android in-app payment solutions market is a market for the supply of services to app developers for accepting and processing payments for the purchase of digital content, including by way of subscriptions, within an Android app, with the following elements or dimensions. It is said that the services consist of the provision of services to app developers enabling and/or facilitating app developers to accept and process payments for the purchase of digital content, including by way of subscriptions, within an Android app. And it is said that the geographic dimension of the market is Australia or a global market, excluding China, of which Australia forms part.
57 Now there is an alternative posited to the Android mobile app distribution market. This is the mobile app distribution market, which is said to be a market for the supply of services for the distribution of Android apps and native apps written for iOS to smart mobile device users, with the following elements or dimensions. It is said that the services consist of the provision of services to app developers enabling or facilitating app developers to reach, offer and provide smart mobile device users with native apps and associated updates and/or the provision of services to smart mobile device users enabling or facilitating smart mobile device users to be presented with or to find, obtain and utilise native apps and associated updates. And it is said that the geographic dimension of the market is Australia or a global market excluding China, of which Australia forms part. I will put this alternative to one side for the moment.
58 Now it is said that Google has a substantial degree of power in each of these markets.
59 It is said that the purpose and effect of Google’s conduct in both the mobile OS licensing market and the Android mobile app distribution market has been to ensure that the Play Store remains the predominant supplier of Android app distribution services and to prevent or hinder the emergence and expansion of rival Android app stores. It is said that its conduct has substantially lessened competition in the Android mobile app distribution market. It is said that in the absence of Google’s conduct, rival app stores would enter that market and compete with the Play Store, including by offering developers lower fees. And it is said that existing Android app stores such as the Amazon App Store and the Galaxy Store could compete more effectively.
60 Similarly, it is said that the purpose and effect of Google’s conduct in the Android in-app payment solutions market has been to ensure that Google remains the sole supplier of services for the facilitation of payments for the purchase of digital content within Play Store apps. It is said that its conduct has substantially lessened competition in that market. It is said that in the absence of Google’s conduct, rival payment solutions providers would enter the Android in-app payment solutions market and compete with Google Play Billing.
61 In summary, Epic says that Google has contravened ss 46 and 47, alternatively, s 45 of the CCA on and from 6 November 2017 (the relevant period).
62 It is said that Google has contravened s 46 because it has a substantial degree of power in all three relevant markets and its conduct had the purpose, effect, or likely effect of substantially lessening competition in two of those markets.
63 It is said that Google has contravened s 47 by supplying Android app distribution services to developers via the Play Store on the condition that they not obtain services for the facilitation of in-app purchases of digital content in Play Store apps from anyone besides Google. Alternatively, it is said that Google has contravened s 45 because it has made and given effect to contractual provisions that have the purpose, effect, or likely effect of substantially lessening competition.
64 Further, it is said that in all the circumstances, Google has engaged in unconscionable conduct contrary to s 21 of the Australian Consumer Law.
Summary of findings
65 In summary, I have made the following key findings.
66 First, I have found in favour of Epic concerning its three posited markets being, first, the mobile OS licensing market, second, the Android mobile app distribution market and, third, the Android in app payment solutions market.
67 And relevant to the question of substitution concerning the second posited market, in my view other Android app stores do provide a competitive constraint on the Play Store such as to be a substitute. Further, there is some substitutability between sideloading of apps and Android app distribution services, but it is not a close constraint, and users and developers do not consider it to be a close substitute. Further, the pre-installation of apps is not a close substitute for Android app distribution services. Further, there is some competition with PC and console operators and mobile app stores, but there is not close substitution. Further, out of app payments say little about the question of substitution for distribution services and in any event would not constrain the hypothetical monopolist of Android app distribution services.
68 Now I should note that the fact that I have found that various other products and services are not close constraints and therefore are not part of the relevant product dimension of market definition does not entail that the availability of such products and services do not provide some form of competitive constraint. In my view they do provide a competitive constraint to some extent although not such as to deny the market definition that I have found or Google’s substantial market power in such a market.
69 Second, I have found in favour of Epic to the effect that at all relevant times Google has and had a substantial degree of power in each market.
70 Third, I have found that contrary to s 46 of the CCA, Google engaged in conduct in the latter two of the three posited markets that has had or is likely to have the effect of substantially lessening competition in such markets being conduct that prevents or prohibits developers and users from using alternative payment methods to Google Play Billing for purchasing digital in app content.
71 In terms of the Google Play Billing restrictions being the payments tie provision and the anti-steering provision, I have found that they were imposed or have been maintained at the start of the relevant period with the effect or likely effect of substantially lessening competition in the payment solutions market.
72 Fourth, I am satisfied that Google engaged in conduct concerning Project Hug, the GVP agreements, the AVP agreements and the RSA3s that had the purpose of substantially lessening competition in the Android mobile app distribution market and so contravened s 46. Further, in relation to the conduct constituted by Project Hug and the GVP agreements, I am satisfied that such conduct had a likely effect of substantially lessening competition in that market; I am using “likely” here in terms of a real chance.
73 In all other respects I have not accepted Epic’s case against Google concerning the other alleged contraventions of Part IV of the CCA or its unconscionable conduct case. And to be clear, I have not accepted Epic’s case concerning the technical restrictions or its case concerning clause 4.5 of the DDA. Let me briefly make some observations on these last two matters.
74 As to the first matter in terms of the technical restrictions relating to install flows and frictions, I have concluded the following. First, such technical restrictions caused or imposed by Google are disproportionate to the security risks that Google has sought to protect against. Second and notwithstanding the first point, in my view such technical restrictions were not imposed by Google or sought to be maintained by Google for the purpose of substantially lessening competition. Third, such restrictions do not separately have any actual or likely effect of substantially lessening competition. And fourth, I have also considered these restrictions in combination with other restrictive conduct that Epic has alleged, but in my view no anti-competitive purpose or effect has been shown by the combination.
75 Now as to the second matter in terms of clause 4.5 of the DDA and the ban on, in effect, an app store within an app store, I am not prepared to find that Google imposed this with the purpose or effect or likely effect of substantially lessening competition in the Android app distribution services market.
76 Now, it must be recalled that Google has permitted direct downloading or sideloading of other competing Android app stores. So such competition was not substantially hindered by Google.
77 Further, the clause 4.5 ban is targeted if at all against competitors rather than competition.
78 Further, Google seems to have had various purposes for the clause 4.5 ban. One purpose was to address security risk as Google perceived it. Another purpose was to prevent free riders. And an associated purpose was to protect the asset that it had invested in and built up. Clearly there was no anti-competitive purpose. Moreover, given the other avenues for the direct downloading or sideloading of alternative Android app stores, in my view no actual or likely anti-competitive effect has been shown in the relevant markets.
79 Now I should say here that the position is a little more complicated concerning Apple as it precluded direct downloading or sideloading of alternative iOS app stores.
The joint trial and these reasons – structural aspects
80 Now as I have said, the joint trial before me concerned the concurrent hearing of four proceedings being Epic’s proceeding against Google, Epic’s proceeding against Apple and two class actions, the detail of which I have set out elsewhere.
81 Epic’s two proceedings had been issued out of the NSW Registry of this Court. The two class actions had been subsequently issued out of the Victoria Registry of this Court. The two class actions in terms of competition law liability questions were derivative of or sought to leverage off Epic’s cases and evidence on liability against Apple and Google, save for the question of the overcharging of commissions relating to paid app downloads or in-app digital purchases on the Play Store or Apple’s App Store.
82 Now in terms of the concurrent hearing of all four matters, I made orders that the evidence in one case should be treated as evidence in all other cases unless I indicated to the contrary, say, in respect of an admission made by one party that was not cross-admissible against other parties.
83 As I have said earlier, I have produced three sets of reasons being the present reasons, another set of reasons in the Epic v Apple proceeding and a third set of reasons dealing with and combining my analysis and findings in the two class actions. Now a number of points.
84 First, the sequence in which the reasons should be read for ease of comprehension are my reasons in the Epic v Apple proceeding, the present reasons and then the reasons in the class actions.
85 Second and relatedly, it should also be understood that findings of fact or law in my reasons in the Epic v Apple proceeding form part of the foundation for my present reasons and then my reasons in the class actions, unless I indicate to the contrary. Indeed, all sets of reasons should be read as a composite whole. So, although I have indicated the sequence in which the reasons should be read, which in one sense can be seen as an incremental vertical structure, I also intend for my findings in this proceeding to be treated as findings in the Epic v Apple proceeding as well as findings in the class actions, and for the findings in the class actions to the extent relevant to be findings in this proceeding and the Epic v Apple proceeding.
86 Third, occasionally, my reasons in Epic v Apple and Epic v Google may overlap in relation to a particular topic. This is partly a function of how the cases have been presented. Nevertheless, my conclusions on such a topic in each proceeding have considered and been based upon all the evidence in all proceedings.
87 Fourth, some aspects of my discussion in the reasons in the class actions concerning the relevant counterfactual analysis should be taken as being incorporated by reference in these reasons. But I do accept that to some extent the dimensions to such an analysis are different.
88 In terms of assessing whether the relevant contraventions occurred, one is looking at and comparing the future from the time of the contravention with the relevant impugned conduct against the future from the time of the contravention without such conduct. But of course in looking at the future with and without the relevant conduct you do not just simplistically hold all else equal. But in terms of the class actions where one is considering causation questions involving what would have occurred if the relevant impugned conduct had not been engaged in, a different calculus and standard of proof is required as I have explained in my reasons in the class actions. A different retrospective hypothetical scenario is involved. Nevertheless the two types of analysis overlap and accordingly my reasons here also include aspects of my reasons in the class actions.
89 Fifth, I have dealt with the survey evidence in my reasons in Epic v Apple.
90 Sixth, I have set out all relevant legal principles concerning market definition, s 46 and other provisions of Part IV of the CCA and aspects of the ACL in my reasons in Epic v Apple.
91 Seventh, I have also set out some applicable economic principles in my reasons in Epic v Apple, including on the question of tied products.
92 Eighth, annexed to my reasons in this proceeding and the Epic v Apple proceeding is both a schedule of abbreviations and acronyms and also a dramatis personae which also includes the detail of lay and expert witnesses in terms of their positions at the start of the trial.
93 Now in terms of the venue for and mode of the joint trial, I have made various observations in my reasons in the Epic v Apple proceeding which I will not repeat save as to two matters.
94 As I have said in my reasons in the Epic v Apple proceeding, the trial required the use under my control of the largest electronically fitted out trial court room of its type in Australia with the necessary technical and other assistance from numerous court staff, all of whom were directly answerable to my requirements. What was also necessary was to provide the parties with work spaces, conference rooms and storage facilities on the same level as the court room. All of this was arranged and provided months in advance of the trial starting. If I may say so I am most grateful to the administrative and court staff for making this all possible. I should also express my appreciation to the in court electronic operator for her first class work.
95 Further, let me express my appreciation for the considerable effort put in by Mr Neil Young KC and his team for Epic, Mr Cameron Moore SC and his team for Google, Mr Matthew Darke SC and his team for Apple and the cameo performance of Mr Anthony Bannon SC and his team for the class applicants. The timeliness and quality of the work of counsel and their instructing solicitors was excellent, and the skill of counsel in their notably efficient presentations including the handling of witnesses resulted in this complex and lengthy trial finishing precisely on time.
96 Let me now proceed to the heart of the matter. For convenience I have divided my reasons into the following sections:
(a) The Google entities and background matters – [97] to [148].
(b) Epic, Google and the Play Store – [149] to [191].
(c) The OEM restrictive conduct and the OEM agreements – [192] to [367].
(d) App developer restrictive conduct and the developer distribution agreements – [368] to [545].
(e) Mobile OS licensing and Android mobile app distribution markets – s 46 – [546] to [594].
(f) In app payment solutions restrictive conduct – [595] to [642].
(g) The Android in app payment solutions market – s 46 – [643] to [687].
(h) Google’s lay evidence – [688] to [766].
(i) Market definition concerning Android mobile app distribution – the parties’ cases – [767] to [861].
(j) Some relevant concepts debated by the economic experts – [862] to [1095].
(k) Epic’s posited Android mobile app distribution market – what is the correct focal product? – [1096] to [1280].
(l) The experts’ approaches to HMT quantitative and qualitative analysis – [1281] to [1444].
(m) Fortnite removal event and diversion ratios – [1445] to [1816].
(n) Logit demand model, transition probability analysis and counting of diversion estimates – [1817] to [2017].
(o) Critical loss analysis including the Lerner index – [2018] to [2402].
(p) What are the close substitutes, if any? – [2403] to [2650].
(q) Is there any competitive tension between Google and Apple? – [2651] to [2789].
(r) Market power – Android mobile app distribution – [2790] to [3162].
(s) Market definition and market power concerning the mobile OS licensing market – [3163] to [3376].
(t) The MADAs including questions of anti-competitive purpose and anti-competitive effect – [3377] to [3584].
(u) The revenue share agreements including the RSA3s and MIAs – anti-competitive purpose and anti-competitive effect of the RSA3s – [3585] to [3918].
(v) Project Banyan and Project Hug – purpose and effect of Project Hug and the GVPs – [3919] to [4280].
(w) Clause 4.5 of the DDA – prohibiting the distribution of rival app stores – [4281] to [4406].
(x) Android ecosystem security including Google Play Protect – [4407] to [4596].
(y) Behavioural economics evidence – [4597] to [4716].
(z) The technical restrictions – [4717] to [4815].
(aa) Real world impact of installation frictions – [4816] to [5178].
(ab) The technical restrictions – purpose and effect of SLC – [5179] to [5346].
(ac) Epic’s s 46 case – Android in app payment solutions, contracts and mechanisms – [5347] to [5567].
(ad) In-app payments – some technical evidence – [5568] to [5687].
(ae) Android in-app payment solutions – market definition, market power, purpose and effect of SLC – [5688] to [6057].
(af) Overall purpose and effect of Google’s conduct – Android mobile app distribution – [6058] to [6128].
(ag) The effect of Google’s conduct on Epic and Fortnite – [6129] to [6221].
(ah) Epic’s claims for breach of ss 45, 46 and 47 and for unconscionable conduct – [6222] to [6345].
(ai) Relief and conclusion – [6346] to [6370].
(aj) Schedule of abbreviations and acronyms, dramatis personae of witnesses and other individuals, and other annexures.
The Google entities and background matters
97 The following matters in this section are largely uncontentious, unless I indicate otherwise.
98 Google LLC is incorporated in Delaware, USA and its ultimate holding company is Alphabet Inc., which is also incorporated in Delaware. Google LLC is headquartered in California, USA.
99 Google LLC is the largest of the entities owned by Alphabet. For public financial reporting purposes, Google LLC is divided into two segments, being Google Services and Google Cloud. The core products and platforms which comprise Google Services include what are known as or what have been described as Android, Chrome, Hardware, Gmail, Google Drive, Google Maps, Google Photos, the Play Store, Search and YouTube.
100 Google LLC owns and continues to develop the Android OS. Google LLC also owns and develops GMS and licenses GMS to OEMs. But as Google points out, it does not supply or license a unitary product of both the Android OS and GMS. They are separately supplied, although of course GMS has some relevant OS aspects.
101 Let me at this point say something about GMS Android, which I have used as a convenient composite label, given that both in Australia and globally excluding China, over 99.9% of smart mobile devices which utilise a licensed OS are GMS Android devices, that is, they have the Android OS and GMS. From 2018 to 2021, approximately 4 million smartphones were sold in Australia each year with GMS Android pre-installed. Globally excluding China, approximately 800 million smartphones were sold each year with GMS Android pre-installed.
102 As I have said earlier, GMS is Google’s proprietary software that runs on top of open source Android and is necessary for a number of key OS features not available in open source Android alone.
103 GMS includes key modules being APIs and SDKs collectively known as Google Play Services, which enable core functionality for the device and for many apps and services. Android devices which do not also have GMS installed cannot access Google Play Services and are significantly functionally limited as a result. One limitation is that if app developers build apps using Google Play Services APIs or SDKs, those apps become dependent on GMS and will only run as intended on devices that have GMS installed.
104 So, by using Google Play Services, app developers can design their app to make use of Google Maps functionality, such as features that respond contextually to a user’s location, via specific Google Play Services APIs. But if such an app is installed on a device that lacks GMS, the app will not have that functionality. Many popular apps, such as Facebook, YouTube, WhatsApp, Gmail, Twitter, Netflix, Uber, Pokemon Go, Slack, and CommBank cannot be run on an Android device that does not have GMS installed.
105 GMS also includes apps developed by Google. Among them are the core applications, being the Play Store, Search, Chrome, Google Maps, Gmail and YouTube. The remaining five core applications were among the top six apps by usage in the Play Store as of April 2023. GMS also includes what are described as flexible applications. These differ between territories and, in Australia, consist of Drive, YouTube Music, Play Movies, Duo and Photos.
106 Now as I have indicated, in Australia and globally excluding China, the vast majority of smart mobile devices which utilise a licensed OS are pre-installed with a combination of open source Android and GMS, which on occasion I will refer to as GMS Android or Google Android.
107 As I have said, Google’s GMS apps are pre-installed under the terms of the MADAs on virtually all Android devices sold outside of China.
108 As I have said, Google licenses OEMs to distribute GMS on their Android devices in accordance with the terms of a MADA. In doing so, more users are introduced to the GMS apps, which include Google Search and the Play Store, and therefore more advertising revenues are derived by Google. This has led Google to make most of its money selling advertising on Google Search and a considerable amount from the Play Store.
109 Such a licence includes the following software and apps. First, a bundle of closed-source, proprietary Google apps including the Play Store, Google Search, Google Chrome, Google Maps, Gmail and YouTube. Second, a Google proprietary software layer that provides background services, SDKs and APIs for the integration of apps with Google Play Services.
110 Google Play Services is an important component of the Android ecosystem and is relied on by many app developers. Its main components are the Google Play Services Android Application Package (APK) and the Google Play Services client library. And without Google Play Services, many Android apps could not function properly.
111 The elements of GMS perform functions that were previously performed by open-source Android OS source code.
112 The GMS apps and Google Play Services are listed in the Google Product Geo Availability Chart, as modified or updated by Google from time to time.
113 Let me at this point say something about the Play Store and Google Play Billing.
114 The Play Store is an app store and is itself a native app. It is owned and was developed by Google. It was originally known as Android Market, which launched in 2008 in the United States and in 2009 in Australia, before being rebadged as the Play Store in 2012.
115 The Play Store distributes Android native apps to Android devices. It is the principal distribution point for Android native apps. Through the Play Store, users can search or browse for apps developed by Google or third-parties, and then download and install such apps onto their devices. There are approximately 3 million apps available to users in Australia for download on the Play Store. Users can discover apps within the Play Store using the search function, and recommended apps are presented to users based on their search and download history. The Play Store also facilitates app updates.
116 From December 2017 to September 2022, the Play Store was pre-installed on between 97.7 and 99.6% of active Android devices in Australia, and between 97.2 and 99.2% of active Android devices worldwide excluding China. Further, in 2020, some 97.9% of new app downloads to Android devices in Australia that occurred through an app store were undertaken via the Play Store, while globally excluding China some 91.4% of new app downloads from an app store occurred via the Play Store.
117 If an app developer wishes to distribute its app via the Play Store, the developer must enter into a DDA with Google.
118 With limited exceptions, app developers who wish to distribute their apps via the Play Store are required to use Google Play Billing to facilitate in-app purchases of digital goods. Google Play Billing enables the facilitation of payments from users in many countries, via a range of payment methods. Google charges developers a fee of up to 30% of the price of in-app purchases made through Google Play Billing.
119 Google Play Billing can only be used on native Android apps that are downloaded from the Play Store and installed on Android devices. Hundreds of thousands of developers monetise their apps through the use of Google Play Billing.
120 Google Play Billing has a function which facilitates the transfer of money from the user to the app developer. Google Play Billing can be considered to be either a payment solution or it can be considered to have a function which includes a payment solution.
121 Let me at this point say something about Google Asia Pacific Pte Ltd and Google Payment Australia Pty Ltd.
122 Google Asia Pacific Pte Ltd is incorporated in Singapore. Its ultimate holding company is Alphabet Inc. Google Asia Pacific Pte Ltd is a party to a payment processing service agreement with Google Payment Australia Pty Ltd.
123 Google Asia Pacific Pte Ltd is also the contracting Google entity and marketplace service provider under the DDA with app developers who select to distribute apps through the Play Store to Android users in Australia.
124 The DDA provides that it is a contract between the app developer and “the applicable Google entity based on where [the developer has] selected to distribute” its apps. The “applicable Google entity” is Google Asia Pacific Pte Ltd in relation to apps distributed through the Play Store in Australia. And the applicable entity is Google LLC in respect of US distribution. Consequently, a developer that distributes apps through the Play Store in Australia and in the USA enters into the DDA with both Google Asia Pacific Pte Ltd and Google LLC.
125 Google Payment Australia Pty Ltd is an Australian corporation and subsidiary of Google LLC. Google Payment Australia Pty Ltd holds an Australian financial services licence which authorises it to offer the Google Payments Service as that term is used in the Google Payment Australia Pty Ltd product disclosure statement. Google Payment Australia Pty Ltd enters into agreements with users of the Google Payments Service who register for that service online. The terms of those agreements are set out in the PDS issued by Google Payment Australia Pty Ltd.
126 By a payment processing services agreement with Google Asia Pacific Pte Ltd, Google Payment Australia Pty Ltd has undertaken to perform payment processing functions and services as directed by Google Asia Pacific Pte Ltd.
127 Now both Google LLC and Google Asia Pacific Pte Ltd carry on business within Australia for the purposes of s 5(1)(g) of the CCA. They do so directly and through Google Payment Australia Pty Ltd. As such, the relevant provisions of the CCA apply to their conduct outside Australia. Now by the end of the trial these matters ceased to be contentious. But for completeness it is worth stating the following.
128 The fact that Google LLC carries on business within Australia is evident from the following facts.
129 First, Google LLC supplies services in Australia, including but not limited to the service known as Google Play to Australian users of the Play Store. The Play Store terms of service expressly reflect such a position. Further, the Google terms of service stipulate that “Google services are provided by, and you’re contracting with, Google LLC”. Those “Google services” referred to within the Google terms of service are not confined to the Play Store. They also include Android OS, Chrome, Gmail, Google Maps and Google Search. That such Google services are supplied in Australia is evident from the fact that Australian users of Android OS, Chrome, Gmail, Google Maps and Google Search all use those products on devices physically located in Australia.
130 Second, in addition to the supply of the Google services in Australia, Google LLC also enters into the contracts under which those services are supplied in Australia. In each instance where the Google terms of service and the Play Store terms of service are accepted by users within Australia when they first use the Google services and the Play Store on their Android device, Google LLC can be taken to have entered into that contractual relationship in Australia.
131 As at 30 September 2022, there were more than 1.9 million Android device users in Australia, which is indicative of the number of Android device users who had agreed to the relevant terms of service in Australia.
132 Google LLC’s supply of services and entry into contracts in Australia amounts to business activities carried on by Google LLC in the jurisdiction on a continuous and repetitive basis.
133 Third, and in addition to the services that Google LLC supplies to Australian consumers, Google LLC also supplies, in Australia, various services to Google Payment Australia Pty Ltd. Appendix IV of Google Payment Australia Pty Ltd’s Compliance Manual records that those services include “[s]oftware maintenance and development”, “[o]perations and support” and “hosting” for the “[Google] Wallet account management platform”, “IT support and services for the office environment”, among other services relating to risk management, human resources, auditing and legal services.
134 Google Asia Pacific Pte Ltd likewise carries on business within Australia.
135 First, like Google LLC, Google Asia Pacific Pte Ltd also supplies services and enters into contracts in Australia.
136 For a developer to distribute apps via the Play Store, the developer must enter into a DDA. Where the developer wishes to have its apps distributed in Australia, the relevant Google counterparty to the DDA is Google Asia Pacific Pte Ltd. So, developers located in Australia who wish to distribute apps in Australia via the Play Store must enter into the DDA with Google Asia Pacific Pte Ltd. Those developers’ entry into the DDA occurs by the developer accepting the terms of that agreement by accessing a website from their device located in Australia, such that Google Asia Pacific Pte Ltd will be taken to have entered into those contractual relationships within Australia.
137 Further, under the DDA, Google Asia Pacific Pte Ltd is the relevant entity authorised to make apps available in Australia via the Play Store, such that Google Asia Pacific Pte Ltd supplies app distribution services in Australia.
138 Accordingly, Google Asia Pacific Pte Ltd’s supply of services and entry into contracts in Australia amounts to business activities carried on by it in the jurisdiction on a continuous and repetitive basis.
139 Second, Google Asia Pacific Pte Ltd has contracted with Google Payment Australia Pty Ltd for the provision of payment processing services in Australia in exchange for a service fee, which Google Asia Pacific Pte Ltd pays to Google Payment Australia Pty Ltd under that agreement. This ongoing commercial relationship with an Australian entity, the subject matter of which is services supplied by that entity in Australia in consideration for a fee, similarly amounts to the carrying on of business in Australia by Google Asia Pacific Pte Ltd.
140 Further, both Google LLC and Google Asia Pacific Pte Ltd carry on business within Australia by and through Google Payment Australia Pty Ltd.
141 Google Payment Australia Pty Ltd conducts a confined business as one of several Google payment entities used to process payments made on the Play Store. It performs that role pursuant to the terms of the payment processing services agreement between it and Google Asia Pacific Pte Ltd.
142 The payment processing services agreement provides that Google Payment Australia Pty Ltd shall provide the defined “Services” in consideration for a set fee from Google Asia Pacific Pte Ltd. Those “Services” are defined to include “all services, consulting, advice and assistance required by [Google Asia Pacific Pte Ltd] in connection with performing payment processing functions and services”. The agreement stipulates that those services shall be provided “as directed by” Google Asia Pacific Pte Ltd. The agreement further stipulates that Google Payment Australia Pty Ltd “shall provide other services in relation to the Services as directed by Company”.
143 The fee for which Google Payment Australia Pty Ltd performs these services at the direction of Google Asia Pacific Pte Ltd is tied to the amount of operating expenses incurred by Google Payment Australia Pty Ltd in the performance of those services, plus an additional 8% of those expenses.
144 Google Payment Australia Pty Ltd adopts the organisational systems and compliance measures, processes and procedures and the employment and personnel policies of Google LLC, and it considers that its employees are bound by the code of conduct published by Google LLC.
145 Indeed, many of the functions required to deliver its services are provided either in whole or in part by Google affiliate companies. And Google Payment Australia Pty Ltd’s compliance manual lists a multitude of functions that are outsourced to Google LLC and Google Asia Pacific Pte Ltd.
146 Further, Google LLC has given Google Payment Australia Pty Ltd a financial undertaking so as to enable it to satisfy the requirements of its Australian financial services licence. Similarly, Google Asia Pacific Pte Ltd has indemnified Google Payment Australia Pty Ltd in respect of any financial risk, expenses, civil and criminal liability, or any kind of financial liability whatsoever that may be incurred as a result of any third-party litigation in which both entities are named as co-defendants.
147 In summary, both Google LLC and Google Asia Pacific Pte Ltd carry on business within Australia. And because they carry on business within Australia, Part IV of the CCA and the ACL (other than Part 5-3) apply to conduct engaged in by Google LLC and Google Asia Pacific Pte Ltd outside Australia.
148 It is convenient in dealing with Epic’s main competition case to refer to Google LLC and Google Asia Pacific Pte Ltd together as Google unless I indicate otherwise; I will not generally put Google Payment Australia Pty Ltd under that label given its more limited function.
Epic, Google and the Play Store
149 I have summarised the nature and evolution of Epic’s business up to the launch of Fortnite on iOS in my reasons in the Apple proceeding. It is unnecessary to repeat that detail here. Let me at this point set out a narrative of some of the relevant dealings between Epic and Google and Epic and various OEMs, the primary facts of which were not contentious unless I state otherwise.
150 Let me begin by saying something about the launch of the Fortnite installer on Android.
151 In August 2018, Epic launched the Fortnite installer on Android. The Fortnite installer was an app from which users could download, and which would thereafter be used to update, another native app, that is, Fortnite.
152 Although initially Fortnite was the only mobile app available for download through the Fortnite installer, Epic’s intention was that the Fortnite installer would be expanded in the future to become the Epic Games App, through which users could download other mobile apps developed by Epic, and ultimately mobile apps developed by third parties.
153 Since the primary function of the Fortnite installer was to distribute and update another app, the DDA prohibited Epic from distributing the Fortnite installer through the Play Store.
154 But it is possible for developers to distribute native apps to Android device users outside the Play Store by reaching arrangements with OEMs to pre-install the app on devices manufactured by that OEM, via third-party Android app stores, or via direct downloads from a website. And given these possibilities, Mr Sweeney proposed launching the Fortnite installer on Android outside the Play Store via a combination of direct downloading from Epic’s website and pre-installation deals negotiated with Android OEMs.
155 Epic ultimately chose not to distribute Fortnite on the Play Store because it believed that Google’s contractual terms would require Epic to use Google’s payment solution, Google Play Billing, for in-app purchases, require Epic to pay Google a 30% commission on those purchases, and prevent Epic from distributing the Fortnite installer as distinct from Fortnite, because the former facilitated the distribution of another app contrary to Google’s contractual terms.
156 Epic saw the Fortnite installer as an initial step towards having its own mobile app store. This was important to Epic, including because Epic was intent on developing its own ecosystem, being a set of developers and users with whom Epic had an ongoing relationship.
157 Let me at this point say something about Epic’s collaboration with Samsung. The following chronology is not contentious in terms of the base facts.
158 From about April to August 2018, Epic negotiated with Samsung and sought its agreement to pre-install the Fortnite installer on Samsung devices. Epic’s original proposal disclosed its intention to later grow the Fortnite installer into a mobile game distribution service for third-party gaming apps. Samsung liked Epic’s intention to disrupt the Play Store but advised that it had to get approvals from Google and various carriers which may not be forthcoming.
159 Whilst these negotiations were occurring, Epic informed Google of its intention to make Fortnite available on Android outside the Play Store. Soon afterwards, Google, which was concerned with a potential revenue loss of up to USD 3.6 billion if other developers followed Epic in not launching on the Play Store, offered Epic various incentives worth over USD 200 million to reverse that decision.
160 When Epic declined this offer, Mr Lockheimer, the senior vice president, platforms and ecosystems at Google, said to Mr Sweeney that Google viewed any launch of software outside the Play Store as a threat to Google and that Google would have to make changes to Android to protect users.
161 In July 2018, an internal Google presentation titled Project Elektra was prepared. It noted Epic’s plan to launch Fortnite directly to the public, thereby bypassing the Play Store, and observed that a large strategic investment into Epic could help advance broader discussions about using the Play Store for Fortnite.
162 On 19 July 2018, an off-cycle meeting of the Google business council was convened to discuss the proposed investment in Epic. The business council is an internal Google committee which is responsible for reviewing significant deals or transactions being proposed by Google’s various business divisions.
163 In a presentation titled EPIC/Fortnite BC Deal Review of the same date, the objectives of the deal were said to include that “[n]ot having Fortnite on Play creates significant risks for Android ecosystem & Play business, and threatens our business in the long term”. Among the risks identified in the presentation were the “Contagion effect” of other top developers following Epic, “increased rev[enue] share pressure” and “Fortnite may legitimize “Samsung” store & 3rd party stores; fragmenting distribution on Android”.
164 On 21 July 2018, the business council approved the proposal. The proposed investment in Epic did not eventuate.
165 In August 2018, the negotiations with Samsung culminated in Epic entering into the Samsung collaboration agreement. The Samsung collaboration agreement provided that Samsung would distribute the Fortnite installer or the Epic Games App through the Galaxy Store. It also licensed Samsung to pre-install the stub version of the Fortnite installer and, if Epic transitioned to the Epic Games App, the stub version of the Epic Games App on Samsung Galaxy Note 9 and Galaxy Tab S4 devices.
166 These stubs were icons which when clicked took the user to the Galaxy Store, where the user could then initiate a download of the Fortnite installer in the same way that any other app could be downloaded from within a pre-installed Galaxy Store, which had a privileged install permission and so did not confront the technical restrictions.
167 But the Samsung collaboration agreement was limited and did not overcome the discoverability challenges faced by Android apps distributed outside the Play Store.
168 Samsung only agreed to use reasonable efforts to pre-install the stub on two new device models, and to make reasonable efforts to perform an update which would install the app on existing Samsung devices. So, Epic could not compel pre-installation on locked devices, even of the two new models, without the consent of carriers. Further, the Fortnite installer stub was located within Samsung’s Game Launcher, which was located in the app tray and not on the home screen of the relevant Samsung devices. Further, if a user searched for an app via the search bar of their Samsung device, they were redirected to Google Search, the results of which prioritised apps available on the Play Store.
169 Now pursuant to the Samsung collaboration agreement, Fortnite apps and any apps downloaded through the Epic Games App were required to use Samsung’s in-app payment solution. Use of Samsung IAP was not mandatory where Epic’s apps were directly downloaded onto a Samsung device.
170 The agreed revenue shares were as follows. In the scenario of in-app purchases within Fortnite apps, the revenue share was 85% to Epic and a commission of 15% to Samsung for the first 18 months, and an 88/12 percentage split thereafter. And in the scenario of in-app purchases within other apps downloaded through the Epic Games app, the revenue share was REDACTED] to Epic and a commission of [REDACTED] to Samsung for the first REDACTED] months, and a REDACTED] percentage split thereafter.
171 On 10 August 2018, Epic announced the launch of Fortnite on Samsung devices at Samsung’s Galaxy Unpacked event. The Fortnite installer was also made available for Samsung users to download via the Galaxy Store and Epic made an Android version of the Fortnite installer available for direct download from its website.
172 Further, in the period from 2018 to 2020, Epic negotiated with various OEMs besides Samsung, with a view to having the Fortnite installer, and later the Epic Games App, pre-installed on as many Android devices as possible. Epic also negotiated with carriers to pre-install its apps on “locked” Android devices. Epic’s goal in these negotiations was to improve both the discoverability and the install flow of Epic’s apps on old and new, locked and unlocked Android devices.
173 At about the time of these negotiations, Epic launched the Epic Games Store on PC in December 2018 and, in October 2019, Epic began replacing the Fortnite installer with the Epic Games App for Android devices. At that time, the Epic Games App enabled users to download, install, and update another Epic app besides Fortnite.
174 Let me now turn to the question of the launch and subsequent removal of Fortnite on the Play Store.
175 In December 2019, Mr Sweeney contacted Google and advised that Epic would submit a version of Fortnite to the Play Store that used Epic’s own payment solution being Epic Direct Payment (EDP) to facilitate in-app purchases instead of Google Play Billing. The app was duly submitted with EDP installed but Google refused to allow it onto the Play Store and suspended Epic’s publishing status.
176 Following further unsuccessful negotiations, Mr Sweeney concluded that all avenues for negotiating terms with Google to distribute Fortnite on the Play Store using EDP were exhausted. He concluded that Epic’s attempt to connect with a large proportion of Android users outside the Play Store, via direct download, pre-installation, and the Galaxy Store, had been unsuccessful.
177 Mr Sweeney decided that Epic should adopt the same approach toward both Apple and Google, namely, to distribute Fortnite on the Play Store and on the App Store, and then publicly challenge both Apple and Google to alter their policies.
178 On 21 April 2020, Epic launched Fortnite on the Play Store, using Google Play Billing. It continued to make the Epic Games App available on Android through other means, including the Galaxy Store and Epic’s website. The contractual terms which applied to Epic’s distribution of Fortnite through the Play Store were set out in a DDA with Google that was entered into in November 2016.
179 After Fortnite launched on the Play Store, Epic experienced a large increase in new Fortnite users on Android. In the first month after that launch, 3.14 million Fortnite users downloaded the app from the Play Store, and 1.7 million of them were new to Fortnite. Fortnite’s gross revenue from the Play Store in that month was approximately $1.3 million, or about $50,000 per day.
180 In June and July 2020, Mr Sweeney sought Google’s agreement to allow Epic to offer its own payment solution within Fortnite and other Epic apps distributed via the Play Store, and to allow Epic to launch a mobile Epic Games Store app on Android, either via the Play Store or by a direct download process which did not have to confront the technical restrictions. Google declined those requests.
181 On 3 August 2020, Epic submitted Fortnite version 13.40 to Google. This version contained code that would allow Epic to offer EDP as an alternative payment option within Fortnite on Android devices when what has been described as a hotfix was activated. Epic did not disclose the hotfix to Google, because it believed that Google would then not approve the update.
182 On 5 August 2020, Mr Sweeney requested from Mr Lockheimer and Mr Samat that Google support Epic using competing payment options in time for a planned Fortnite price reduction. Lockheimer’s response on 11 August 2020 indicated that Google was not willing to do so.
183 On 13 August 2020, Epic activated the hotfix and thereby made EDP available within Fortnite apps downloaded from the Play Store and the App Store. As a result, Play Store users were presented with a choice when purchasing V-Bucks within the Fortnite app: they could make their purchase using Google Play Billing or using EDP. At the same time, Epic introduced the “Fortnite mega drop”.
184 Within a few minutes of Epic activating the hotfix and implementing the mega drop, Mr Sweeney emailed Mr Lockheimer and other senior executives at Google, informing them that Epic had introduced EDP in the version of Fortnite distributed through the Play Store.
185 Later on 13 August 2020, Google removed Fortnite from the Play Store. Epic later commenced proceedings against Google in the US District Court for the Northern District of California, alleging, among other things, violations of the Sherman Act and California’s Unfair Competition Law.
186 Fortnite is still excluded from the Play Store and users have been unable to download Fortnite from the Play Store since the removal. Further, users who previously downloaded Fortnite from the Play Store have been unable to update that version of the app since 13 August 2020. The Epic Games App from which users can download Fortnite is available to Android users in Australia on the Galaxy Store and by direct download from Epic’s website.
187 Shortly after the removal, the average monthly active users of Fortnite on Android devices declined to below 3 million, from 5.9 million immediately prior to the removal in July 2020.
188 Now I should note here that Google says that it removed Fortnite from the Play Store because Epic had breached the DDA and the payments policy by introducing EDP via a hotfix. Google says that Epic’s move was part of a pre-planned scheme intended to provoke a response from Google. It says that Google’s conduct only amounted to enforcing the provisions of the DDA and the payments policy.
189 I will say something more about the relationship between Epic and Google much later in my reasons and addressed to the question of whether Google’s conduct or policies impeded Epic or Fortnite.
190 Further, as to the relevant Apple entities and background matters relevant to such entities, I refer to what I said in my reasons in the Apple proceeding.
191 Let me now turn to Epic’s case and begin by more precisely identifying what Epic says to be the OEM restrictive conduct. Before dealing with the question of markets, it is important to be clear about what precisely is said to be the impugned conduct.
The OEM restrictive conduct and the OEM agreements
192 Generally speaking, Epic says that Google has engaged in conduct by which it prevents or hinders competition for the supply of services for the distribution of Android apps and for facilitating in-app payments made within Android apps. Specifically, it is said that Google has spun a web of contractual terms and policies that traps OEMs and app developers, so as to preclude robust competition for the Play Store and Google Play Billing.
193 Now for convenience and in this context, Epic’s case concerning Google’s anti-competitive conduct can be divided into three categories.
194 First, there are the alleged contractual restrictions which Google imposes on and enforces against OEMs that license GMS. I will refer to this as the OEM restrictive conduct.
195 Second, there are the alleged contractual restrictions which Google imposes on and enforces against app developers that distribute Android apps via the Play Store and additional arrangements with large developers by which Google has sought to prevent or neutralise competition in app distribution. I will refer to this as the app developer restrictive conduct.
196 Third, there are the alleged contractual restrictions which Google imposes on and enforces against app developers with respect to in-app payment solutions and related matters. I will refer to this as the in-app payment solutions restrictive conduct.
197 Let me in this section address the OEM restrictive conduct only. Now the alleged OEM restrictive conduct includes the following aspects.
198 The first aspect is that it is said that Google’s conduct required OEMs that wish to distribute devices with GMS to enter into a MADA.
199 Epic has given the following description, the terms of which are largely accurate subject to any qualification that I have made.
200 The terms of the MADA require OEMs, who wish to distribute an Android smart mobile device with GMS, to pre-install the Play Store and to place the icon giving access to the Play Store on the device’s default home screen (DHS) or, in the case of certain Samsung devices, in the device hotseat. OEMs must place the icons giving access to Google Search, the Play Store and a folder providing access to a collection of icons for the other GMS apps on the DHS of their Android smart mobile device or, in the case of certain Samsung devices, in the device hotseat.
201 And OEMs may only distribute devices with GMS if their devices comply with the following GMS requirements. Devices must pre-install all core applications on the device, including the Play Store. The Google Search widget, the Play Store app icon and a folder labelled “Google” containing the core applications must feature on the DHS. Devices must pre-install the GooglePackageInstaller app, as a privileged app, in place of the default package installer available with the Android OS. The Play Store must be placed in the apps menu and should be in the top level of the apps menu and may not reside within any folder of the apps menu. Devices running Android must replace the global “Unknown Sources” setting with the “Allow apps installs” setting, which grants the “REQUEST_INSTALL_PACKAGES” permission on a per app basis, allowing the granted app to provide other apps for installation. Devices must not implicitly grant this permission to any pre-installed or downloaded third-party apps that do not have a privileged installation permission (unknown sources). And devices must comply with the CDD and pass applicable testing suites, including the CTS and GMS testing suite.
202 OEMs are required to comply with terms of the MADA or documents incorporated into the MADA which have the effect that if an Android smart mobile device user seeks to download an Android app from an unknown source, including an internet browser or an alternative app store that does not have a privileged install permission, the user is confronted with various warnings including that their device is more vulnerable to attack by “unknown apps” and must alter their device’s settings to allow the download to occur. Further, those warnings and the requirement for an Android smart mobile device user to alter their device settings will not apply to downloads from the Play Store.
203 OEMs are also subject to the following requirements under the MADA.
204 OEMs may only distribute GMS on an Android compatible device, being a device that complies with the Android Compatibility Definition Document (CDD), being part of the Android compatibility program. I will return to the detail of the CDD later.
205 Further, OEMs may not distribute an Android compatible device unless the GMS apps, including the Play Store, and Google Play Services, have been preinstalled on that device, except as otherwise approved by Google in writing.
206 Further, OEMs may only distribute a device with one or more GMS apps if they make all of the Google mobile services apps, including the Play Store, available on that device.
207 Further, in the case of MADAs entered into before 2017, OEMs must not take any actions that may cause or result in the fragmentation of the Android OS.
208 Further, OEMs may not distribute an Android compatible device in any territory without Google’s written approval prior to the launch of each device model, and OEMs must send the final software build of their devices, as well as test reports confirming the device passes the Android Compatibility Test Suite (CTS), to Google for final approval.
209 The second aspect is that it is said that Google’s conduct required OEMs that wish to distribute devices with GMS to enter into an AFA containing the terms referred to below. So, OEMs that wanted to distribute devices with GMS had to enter into an AFA and ACC, being part of the Android compatibility program.
210 OEMs are prevented from distributing, in the case of OEMs subject to an AFA, or from manufacturing, distributing or marketing, in the case of OEMs subject to an ACC, devices based on the Android OS that are not Android compatible devices. A device is an Android compatible device if it complies with the CDD. I will say something more about the CDD shortly.
211 Further, OEMs are prevented from distributing, in the case of OEMs subject to an AFA, or from developing, distributing or marketing, in the case of OEMs subject to an ACC, any software based on the Android OS that is not designed to run on Android compatible devices.
212 Further, OEMs subject to an AFA are prevented from taking any actions that may cause or result in the fragmentation of the Android OS.
213 Further, OEMs are prevented from, in the case of OEMs subject to an AFA, distributing an SDK derived from the Android OS or derived from Android compatible devices and participating in the creation of, or promotion in any way of, any third-party SDK derived from Android, or derived from Android compatible devices, or in the case of OEMs subject to an ACC, distributing or marketing an SDK based on the Android OS to third parties, or participating in the development of such an SDK, save for their own internal use.
214 Further, OEMs that wanted to distribute devices with GMS had to comply with various requirements of the CDD, which I will detail more specifically in a moment.
215 The third aspect concerns Google’s conduct in entering into what have been described as the Premier revenue sharing agreements, which I have previously referred to as RSA3s, or mobile incentive agreements, which I have previously referred to as MIAs, with certain OEMs.
216 Those terms promise financial incentives to OEMs in exchange for the OEMs configuring devices so that the Play Store is set as the default app store, no alternative app store or other app substantially similar to the Play Store is pre-installed on the device, only apps that are available on the Play Store are pre-installed on the device, and the Play Store icon is placed on the device’s DHS.
217 The RSA3s or MIAs with certain OEMs contained various terms.
218 The incentives offered to OEMs in the RSA3s, conditional on the OEM entering into a MADA and AFA, are only payable in respect of revenue generated from devices configured by the OEMs as follows. Devices configured in the appropriate way are referred to as “Premier” devices.
219 A Premier device must not include any pre-installed app that is substantially similar to the Play Store, nor any launcher, over the air prompt or functionality that has the primary purpose of providing access to any service substantially similar to the Play Store.
220 Further, a Premier device must set the Play Store as the “default” app store or marketplace for apps and all other digital content including subscriptions.
221 Further, a Premier device must only pre-install an app that is available on the Play Store, and does not contain privileged install permissions, which facilitate the downloading of other apps, although in some instances, there is an exception for an app store owned by the OEM or certain carriers.
222 Further, a Premier device must not be configured so as to allow an OEM or any third-party to promote, introduce or suggest alternative app stores to an Android smart mobile device user.
223 Further, a Premier device must have the Play Store icon placed on the DHS.
224 The incentives offered to OEMs in the MIAs, conditional on the OEM entering into a MADA and AFA, are only payable in respect of revenue generated from devices configured by the OEMs with, generally speaking, the same requirements as set out.
225 The fourth aspect is said to be Google’s conduct in giving effect to and/or enforcing the terms referred to above including in relation to Epic by engaging in the relevant conduct.
226 I will refer to the MADAs, AFAs and ACCs, and RSAs and MIAs collectively as the OEM agreements. Let me delve deeper into some of these agreements and arrangements.
Anti-fragmentation agreements and Android compatibility commitments
227 Now as I have mentioned earlier, if an OEM wishes to distribute Android devices with relevant APIs known as GMS pre-installed, Google requires the OEM to enter into either an AFA or an ACC as part of the Android compatibility program, in addition to a MADA. Of course an AFA or an ACC can be entered into without entering into a MADA. Now the AFAs and ACCs are relevant to Epic’s case in two ways, as Epic has explained in the following terms.
228 First, they mandate compliance with compatibility standards that include the technical restrictions.
229 Second, they buttress Google’s power in the mobile OS licensing market and constitute a barrier to entry and expansion in that market.
230 Now Epic does not say that all of the compatibility standards imposed on OEMs via the AFAs and ACCs are anti-competitive and unlawful. It was not Epic’s case that Google cannot set common compatibility standards for Android devices or that Android OS must be allowed to fragment. Instead, Epic impugns a single aspect of the compatibility standards, namely, that aspect which forms part of the technical restrictions.
231 Epic otherwise relies on the AFAs and ACCs as elements of Google’s power in the mobile OS licensing market.
232 Now as I have indicated, Google made an AFA and/or an ACC with every OEM that distributed Android devices with GMS pre-installed during the relevant period. After all, the GMS distribution licence granted under the MADA is expressly subject to the OEM being in compliance with a valid and effective AFA or ACC.
233 In any event, the evidence includes copies of agreements covering the relevant period which Google made with ten OEMs, being Samsung, Huawei, OPPO, Xiaomi, Sony, Motorola, Nokia, Vivo, OnePlus, and LG; I will refer to these as the selected OEMs.
234 The selected OEMs accounted for between about 74 and 85% of all Android devices and Android fork devices shipped in Australia from 2018 to 2022, and over 70% of all Android devices and Android fork devices shipped globally excluding China during the same period.
235 And as I have indicated, both AFAs and ACCs use a defined term that is also used in the MADA, namely, Android compatible device(s), which term is defined to mean an Android device that complies with the CDD and successfully passes the CTS. The CDD contains numerous baseline requirements for the configuration, behaviour, and security of Android devices. The CTS is an automated software suite developed by Google that scans an OEM’s installed software and tests for compliance with the CDD. Devices that run on an Android fork do not comply with the CDD and will not pass the CTS, whereas all Android compatible devices do comply with the CDD and have passed the CTS.
236 The AFAs relevantly provide that OEMs may only distribute devices developed to run on the Android OS if those devices are Android compatible devices. The AFAs further provide that OEMs may only distribute software developed for use on devices that run on the Android OS if those devices are Android compatible devices.
237 Finally, the AFAs prohibit OEMs from taking any actions that may cause or result in the fragmentation of Android. They also prohibit OEMs from distributing, creating or promoting an SDK that is derived from Android or from Android compatible devices.
238 In 2017, Google replaced most AFAs with ACCs. The terms of the ACCs are similar to those of the AFAs. The ACCs provide that all devices based on Android that the OEM manufactures, distributes or markets will be Android compatible devices. They further provide that all Android based software that the OEM develops will be designed to run on Android compatible devices. Further, the ACCs prohibit the OEM from distributing or marketing an SDK based on Android to third parties.
239 The ACCs contain exceptions whereby OEMs are permitted to manufacture devices and components for devices that are not Android compatible devices, if they do so for a third-party brand and do not market such devices. OEMs are also permitted to develop, distribute, or promote apps for any platform.
240 ACCs entered into from 2020 onward also contain an exception for devices supplied into the European Economic Area (EEA). For those devices only, the OEM may develop, manufacture, distribute or market, first, Android devices that are not Android compatible devices, second, software derived from the Android OS that is not designed for Android compatible devices and, third, SDKs associated with those devices, provided that such devices, software and/or SDKs comply with the Android and Google brand guidelines. This exception largely abrogates the ACC within the EEA.
241 Google nonetheless insists that ACCs must be entered into and enforced throughout the rest of the world.
242 The AFAs and ACCs have the effect of committing OEMs to only distribute Android compatible devices and to refrain from manufacturing, distributing, or marketing, except as a contractor for third-party brands, any smart mobile devices that operate on an Android fork or are otherwise non-compliant with the CDD.
243 ACCs but not AFAs may be terminated by the OEM on 60 days’ notice. But termination of an ACC would cause the OEM to lose its distribution licence under the MADA.
244 Now the ACC is an agreement entered into voluntarily by device manufacturers to promote compatibility and ensure compliance with the CDD. But if an OEM wants to comply with the CDD, it can do so without signing an ACC. And it follows that a voluntary desire to promote compatibility and ensure compliance with the CDD cannot explain why OEMs sign binding ACCs with Google, although Google did not accept this.
245 If an OEM wants the right to pre-install GMS on its devices, it has no choice but to enter into, and comply with, an ACC. And I agree with Epic that the primary reason why an OEM would sign an ACC is because it wants the right to distribute GMS under a MADA.
246 Google’s own documents state that almost all OEMs which sign an ACC also sign a MADA. Further, Google has not led evidence of any OEM that has not signed both.
247 The primary reason why OEM’s sign an ACC is that they want the right to distribute GMS under a MADA. If they want that right, OEMs have no choice but to enter into, and comply with, an ACC, or previously an AFA.
248 So, although formally separate documents, the ACCs and AFAs are in substance part of the bargain embodied in the MADAs.
249 In this way, one of the choices supposedly available to OEMs in the Android ecosystem is foreclosed. If an OEM wants to distribute any Android devices, it must sign an ACC. And for so long as it is a party to an ACC, the OEM cannot distribute any devices that run on an Android fork.
250 Google executives who prepared a 12 October 2010 presentation titled Android OC Quarterly Review – Q4 2010 said of the similarly framed AFA that it “[s]tops our partners and competitors from forking Android and going alone”. That was evidently an important objective which Google sought to achieve via the AFAs and ACCs. It was far more advantageous for Google to make sure that there was just one operating system, which it controlled, rather than multiple forked operating systems, which it did not.
251 Now it has been said that an OEM can always choose to distribute devices that run on an Android fork, or develop their own operating system, instead of distributing Android devices. But the evidence demonstrates that this is not really an option for OEMs if they wish to make a profit.
252 Apps developed for use on Android compatible devices are not likely to function correctly on forked devices, let alone on a newly developed operating system. Google’s proprietary apps, including the Play Store, are unlikely to function properly on forked devices. That is because those apps, along with hundreds of thousands of third-party apps, use one or more of the Google APIs that are collectively known as Google Play Services.
253 In 2016, some 826 of the top 1,000 Android apps used one or more Google Play Services APIs. If a device does not have Google Play Services installed, none of those apps will work as intended, if at all, on that device.
254 Google Play Services are necessary for several key operating system features not available in the AOSP alone and a number of very popular apps, including Facebook, YouTube, WhatsApp, Netflix and Uber, cannot be run on non-GMS-certified versions of Android.
255 It is also not possible to utilise the Google Play Services APIs without installing the Play Store. Those APIs require and use Play’s infrastructure.
256 As far back as 2010, Google’s executives were planning to train developers on Google’s APIs. They recognised that if developers used Google’s APIs, their apps would not function properly outside of the Android ecosystem which Google controlled.
257 The end result is that throughout the relevant period, an OEM which chose to distribute devices that ran on an Android fork would have to persuade users to buy devices on which most Android apps would not function properly, if at all.
258 The OEM would also have to persuade developers to develop apps or versions of apps that did function properly on its Android fork.
259 The only way for an OEM to ensure that most Android apps do function properly on its devices is to pre-install GMS which includes Google Play Services. And to do that, the OEM must sign both an ACC and a MADA.
260 So, it is unsurprising that few OEMs develop their own operating systems or choose to pre-install Android forks.
261 From 2017 to 2022, less than 0.2% of the smart mobile devices shipped in Australia and globally excluding China each year were smartphones with an operating system other than GMS Android or iOS pre-installed.
262 If one focuses on operating systems that are available for license by OEMs, then from 2017 to 2022 less than 0.1% of smart mobile devices shipped in Australia and globally excluding China each year pre-installed a licensable operating system other than GMS Android. The remaining 99.9% were Android devices.
263 So, excepting China where GMS is not available, and Apple whose proprietary operating system is not licensed to any other OEM, almost no OEMs believe that it is in their commercial interests to distribute smart mobile devices that use an operating system other than GMS Android.
264 The commercial reality is that, besides Apple, OEMs operating outside China have no practical choice but to sign an ACC and a MADA.
The mobile application distribution agreements
265 Let me now delve more deeply into the MADAs.
266 As I have already said, if an OEM wishes to include GMS on its smart mobile devices or to use the Android trademark, it must enter into a MADA with Google which contains the relevant licence terms for GMS. Each of the selected OEMs was party to a MADA throughout the relevant period, and the same is no doubt true of all OEMs who distributed Android devices.
267 The Android trademark signals to users that the device is an Android-compatible device which participates in the Android app ecosystem. The MADA relevantly grants, “subject to Google’s prior written approval for each use”, a licence to display Google owned trademarks, which include the Android trademark, “solely for the purposes of this Agreement”.
268 The “purposes of this Agreement” are to grant the OEM a licence to distribute devices with GMS installed and to prescribe the conditions of that grant. So, the licence to use the Android trademark which Google confers upon OEMs under the MADA permits use of that trademark in connection with the distribution of Android devices with GMS. It does not permit use of the Android trademark in connection with the distribution of devices that do not have GMS installed.
269 So, OEMs only have a choice to distribute non-GMS Android devices insofar as it is commercially sensible for them to sell smart mobile devices without being able to use the Android trademark when doing so.
270 Apart from the trademark licence, under the MADAs, Google grants OEMs a non-exclusive licence to distribute GMS on, and only on, Android compatible devices and to reproduce GMS to the extent necessary to exercise that licence.
271 GMS principally consists of specific Google owned apps, as well as the collection of SDKs and APIs that make up Google Play Services.
272 The GMS apps include the core applications, being, the Play Store, Search, Chrome, Google Maps, Gmail and YouTube, and flexible applications.
273 Google Play Services include SDKs and APIs that enable core functionality for many apps and services such as Google Sign-In and Google Maps. Since many Android apps are developed using Google Play Services SDKs and APIs, those apps will not function properly on a device that does not have Google Play Services installed.
274 The OEMs’ licence to distribute devices pursuant to the MADA is subject to them complying with a valid and effective ACC.
275 Further, and importantly, under the MADAs OEMs are only permitted to distribute a device containing GMS if all core applications including the Play Store and flexible applications have been pre-installed on that device, save as approved by Google in writing. It is not permissible for OEMs to choose which of those GMS apps they wish to pre-install and which they do not.
276 The MADAs also prescribe placement requirements pertaining to the GMS apps.
277 Specifically, OEMs must place on the device’s DHS the icons which give access to the Google Search app, the Play Store and a folder providing direct access to icons for the core and flexible applications.
278 The phrase “default home screen”, which I have referred to as DHS, is defined at clause 1.14 of the MADA as the default display of a device, including the lock screen and/or the notification tray, prior to any changes made by end users that appears without scrolling after initial boot-up, without scrolling after each subsequent power-up or without scrolling after an end user selects the “home” icon.
279 OEMs must also ensure that any GMS app that is not a core or a flexible application is placed no more than one level below the DHS.
280 Samsung’s MADA imposes placement requirements to the same effect, save that, since 8 January 2018, those requirements have been varied in respect of three categories of device only being Galaxy S9, Galaxy Note9 and Galaxy Fold. On those devices, Samsung may remove all app icons from the DHS. But where Samsung does so, the Play Store must be placed in the device hotseat, which is the dock along the bottom row of every screen, including the DHS. Further, a folder of pre-installed GMS apps must be placed in the first row of the application tray, which is accessed by swiping up from the bottom of the DHS.
281 These three categories of Samsung devices accounted for 13.9% of all Android device shipments in Australia in 2018, and that number rapidly diminished, such that it was only 1.2% in 2019 and zero by 2020. Globally excluding China, these devices only represented 2.1% of all Android device shipments in 2018, 0.5% in 2019, and zero in 2020.
282 The MADAs also provide that OEMs may not distribute an Android compatible device without Google’s written approval prior to the launch of each device model, and OEMs must send the final software build of their Android compatible devices, as well as test reports confirming they pass the CTS, to Google for final approval. Google may provide approval in its sole discretion.
283 Let me deal with one other matter at this point.
284 To comply with decisions of the European Commission and the Turkish Competition Authority, different versions of the MADA apply in the EEA and Turkey. Under these MADAs, Google Search and the Chrome app are not included in the GMS licence granted to OEMs for devices that are distributed in the EEA and Turkey. Instead, Google Search and Chrome are separately licensed to OEMs at no cost. Further, OEMs must pay a licensing fee to Google to license the remaining GMS, including the Play Store. Otherwise, these MADAs are in substantially similar form to the other MADAs.
The Google Mobile Services requirements
285 The GMS distribution licence granted under a MADA is expressed to be “subject to” the “GMS requirements”. These requirements are published by Google, which may change them at any time in its sole discretion. The GMS requirements include the following which I have mentioned above.
286 First, the requirement to pre-install all core applications, including the Play Store.
287 Second, the requirement to feature on the DHS the Google Search widget, the Play Store icon, and a folder labelled “Google” containing the core applications, although this does not apply to certain Samsung devices as explained above
288 Third, the requirement that every device preloads a particular Google-signed package installer in place of the default package installer available with open source Android.
289 Fourth, the requirement that the Play Store be placed in the top level of the apps menu and not in any folder.
290 Fifth, the requirement that devices must replace the global “Unknown Sources” setting with the “Allow app installs” setting, which grants the “REQUEST_INSTALL_PACKAGES” permission on a per app basis, allowing the granted app to provide other apps for installation. Devices must not implicitly grant install permission to any pre-installed or downloaded third-party apps that do not have a privileged installation permission.
291 Sixth, the requirement that devices comply with the CDD and pass applicable testing suites, including the CTS and the GMS testing suite, being a suite of tests to ensure compliance with the GMS requirements. Relevantly, a device will not comply with the GMS requirements or pass the GMS testing suite if a pre-installed app has been granted a privileged installation permission but has not been approved by Google for inclusion on an “allowlist”, that is, for the grant of a privileged installation permission.
The Android CDD and technical restrictions
292 The MADA incorporates the requirements of the CDD. It does so in two ways. First, it makes the GMS distribution licence subject to compliance with a valid and effective ACC. Second, it confines the GMS distribution licence to Android compatible devices.
293 The CDD contains requirements for the configuration, behaviour, and security of Android devices. Throughout the relevant period, among other things, the CDD included requirements as to when, and how, a device may install apps from “unknown sources”.
294 By requiring OEMs to assume and perform the contractual obligations referred to above and/or by reason of decisions made by Google in the course of determining whether the OEM’s devices have complied with the Android CDD and the GMS requirements, and have passed the CTS and the GTS to its satisfaction, Google has imposed on all OEMs who wish to distribute Android smart mobile devices with GMS a requirement that the OEM must configure their Android smart mobile device so that, if an Android smart mobile device user attempts to download an app from an unknown source including via their internet browser, the user is confronted with all or at least some of the following aspects or consequences.
295 First, a warning with words to the effect that the APK can harm their device and words that ask whether the user wishes to keep the APK anyway.
296 Second, if the user indicates that they do wish to keep the app, the download commences and, after the APK is downloaded, a statement that for their own security their device is not allowed to install unknown apps on their Android smart mobile device.
297 Third, an option to cancel the installation or to alter their device settings.
298 Fourth, if the user wants to proceed with the installation, a statement and/or functionality that they must go to the settings for their Android smart mobile device and alter their settings to allow the installation of “unknown apps”.
299 Fifth, on navigating to the settings menu, another warning that their Android smart mobile device is more vulnerable to attack by “unknown apps” and that by installing apps from this source the user agrees they are responsible for any damage to their device or loss of data that may result from the app.
300 Sixth, a step such that to proceed with the installation of the app, the user must then toggle the setting to indicate that they wish to make the change to the default setting.
301 Seventh, a step being that the user is then presented with an installation confirmation prompt that asks the user whether they want to install the app, and once the user acknowledges the prompt and presses “install” the installation proceeds.
302 The precise text the user is confronted with as a result of each of the matters referred to above can vary between OEMs, versions of the Android OS and, in instances of direct downloading, the browser through which the app is downloaded.
303 Further, any device had to be configured such that prior to the release of the Android 12 version of Android OS on 4 October 2021, it was not possible to automatically update apps downloaded from unknown sources; and to update an app downloaded from an unknown source the user had to repeat all or at least some of the steps outlined above.
304 Further, any device had to be configured such that since the release of the Android 12 version of Android OS on 4 October 2021, apps downloaded from an unknown source can be automatically updated, but subject to conditions which are not imposed on Android apps distributed via the Play Store.
305 As a result of all of these matters, OEMs are prevented from performing or permitting the following actions.
306 They are prevented from distributing Android smart mobile devices without configuring those devices as referred to above, such that all attempts to directly download an Android app, or to download an app from an alternative app store that is not pre-installed with a privileged install permission, will confront the restrictions referred to, but the restrictions referred to will not apply to downloads from the Play Store.
307 Further, they are prevented from allowing direct downloading of apps or downloading of apps from an alternative app store that has not been approved by Google for pre-installation with a privileged install permission on Android smart mobile devices without displaying warnings to users and requiring users to take steps to allow such downloading of apps outside the Play Store.
308 I have referred to the above matters collectively as the technical restrictions.
309 Now Epic says that by reason of the technical restrictions, OEMs that want to distribute devices with GMS installed must configure those devices so that, if a user attempts to download an app from a source that does not have a privileged install permission, the user cannot download and install that app without manually navigating through a series of warnings and additional steps or clicks.
310 The technical restrictions ensure that only Android apps and app stores which have a privileged install permission can install other apps via a one click process.
311 Where GMS Android is installed on a device, the Play Store is granted a privileged install permission and Google has ultimate control over which other apps or app stores (if any) are granted a privileged install permission. Google exercises this control to disallow the grant of privileged install permissions to apps and app stores of which it does not approve.
312 If a user wants to download and install an app from a source, be it a web browser or an app store, that has not been granted a privileged install permission, being sources Google refers to as “unknown sources”, the user must explicitly grant permission to install apps from that source by changing a setting on their Android device.
313 Epic says that the technical restrictions are designed to apply frictions based on the source of the app being installed, that is, the web browser or the app store, not based on the app being installed or the developer of the app being installed. Epic says that this leads to absurd results.
314 So, if an Android device user seeks to install the Google Wallet app using the Google Chrome web browser, the technical restrictions apply and frictions are applied on the basis that Google Chrome is an “unknown source”.
315 But once the user changes their settings to allow Google Chrome to install the Google Wallet app, the technical restrictions will not apply for any app, however malicious, which the user subsequently finds on the web using the Google Chrome browser and seeks to install on their device.
316 There is nothing secure about this system, and evidently the technical restrictions are not aimed at protecting Android device users from potentially harmful apps. They are aimed at potential sources of app distribution, not at potentially harmful apps or at potentially nefarious app developers.
317 Until Android 8 was released in 2017, this required users to adjust their device’s settings once, following which the device would allow all so-called “unknown sources” to install apps without causing warnings to appear. With the launch of Android 8, this was changed to a “per source” permission, such that users have been required to adjust their device’s settings each time they wish to allow a new “unknown source” to install apps.
318 In practical terms, this means that although it is possible to download and install apps otherwise than from a privileged app store, users who attempt to do so encounter frictions in the form of explicit warnings and additional steps or clicks. The number, form and sequence of these install frictions is described later.
319 So, to directly download the Amazon App Store to various Android devices, the user encounters three separate warnings.
320 In addition, on devices that post-date Android 8, the first time a user tries to download an app from the Amazon App Store which has been directly downloaded onto the device, they must undertake another three or four steps and encounter a fourth warning.
321 Further, because directly downloaded apps do not update automatically, and updated versions must be reinstalled from the original source, users have to undertake three of the same steps and re-encounter one of the same warnings each time they directly download an updated version of the app. Until October 2021, the same experience confronted users when seeking to update an app which they had obtained from a directly downloaded app store.
322 The number, form and sequence of the install frictions that result from the technical restrictions is described in the evidence. Taken together, they not only create a disincentive for users to directly download apps, by making the process more difficult and time consuming than downloading apps through the Play Store, but they are apt to cause users to think that directly downloading apps is harmful and to dissuade them from completing the process.
323 Epic says that the technical restrictions are also designed in such a way that apps being directly downloaded from well-known and safe sources are treated in the same way as truly “unknown sources”. In contrast, on Windows PCs, the degree of install friction varies depending upon the extent to which the developer of the app being installed has been verified as trustworthy by means of a certification process.
GMS non-technical requirements
324 Some of the GMS requirements form part of the technical restrictions which I have identified elsewhere and will not repeat here. As Epic has identified, the remaining relevant GMS requirements do not form part of the technical restrictions and are as follows.
325 Section 2.2 provides that new product launches must pre-install “all Core services and apps in the latest GMS bundle no later than 60 days after the latest bundle is released by Google.”
326 Section 3.1 provides that the DHS must feature the Google Search widget, the Play Store icon and a folder labelled “Google” containing the core applications.
327 Section 3.3 provides that all GMS apps must be placed in the apps menu and that the Play Store should be placed in the top level of the apps menu and not in any folder.
328 In summary, OEMs may only distribute devices with GMS, including GMS apps and Google Play Services, if their devices comply with the GMS requirements, which include the following requirements.
329 First, to pre-install all core applications on the device, including the Play Store.
330 Second, to feature on the DHS of the device the Google Search widget, the Play Store app icon and a folder labelled “Google” containing the core applications.
331 Third, to pre-install the GooglePackageInstaller app, as a privileged app, in place of the default package installer available with the Android OS. A package installer is a system application that is responsible for handling the installation and uninstallation of apps on the device; the package installer confirms that an app that is attempting to install other apps has permission to do so, or has otherwise sought the consent of the user to install apps.
332 Fourth, to place the Play Store in the apps menu and, specifically, within the top level of the apps menu and not any folder on the apps menu.
333 Fifth, to replace the global “Unknown Sources” setting with the “Allow app installs” setting on Android devices, which grants the REQUEST_INSTALL_PACKAGES permission on a per app basis, allowing the granted app to provide other apps for installation. A device must not implicitly grant this permission to any pre-installed or downloaded third-party apps that do not have a privileged installation permission, that is, unknown sources.
Revenue sharing agreements and mobile incentive agreements
334 Let me at this point say something further concerning the RSAs and the MIAs.
335 Under the RSAs Google promises to pay OEMs a share of certain Google revenues, which are essentially advertising revenues generated from Google Search results displayed on the OEMs’ devices, in exchange for those OEMs configuring their devices in particular ways.
336 Prior to mid-2019, each of the selected OEMs had entered into RSAs.
337 RSAs also require OEMs to comply with their MADAs. Where an OEM breaches this obligation, Google is not required to make payments to the OEM under its RSA.
338 In this way, the RSAs serve to ensure that OEMs will prefer distributing Android devices over possible alternatives, and will comply with the restrictive terms imposed under the MADA, including the requirement to pre-install the Play Store on the DHS and the technical restrictions, and the ACCs.
339 Unlike ACCs and MADAs, it is not mandatory for an OEM to enter into an RSA. But most OEMs are incentivised to enter into a RSA in order to receive the lucrative revenue shares.
340 In November 2021, about 97% of Android devices that were active worldwide excluding China were manufactured by an OEM that had an RSA with Google.
341 Let me say something more about the RSA3s and Premier devices, which excited some attention during the running of the trial.
342 Until mid-2019, RSAs do not appear to have contained specific requirements relating to the Play Store or to provide for any sharing of revenue generated through the Play Store.
343 But between January and June 2019 Google developed its Google Distribution on Android Framework, which was approved by Google’s business council in June 2019 and which I have described elsewhere as simply GDAF.
344 RSAs were modified in accordance with this approved framework and the modified versions are referred to within Google as RSA3s. At least six of the selected OEMs have entered into an RSA3.
345 Pursuant to the approved framework, there are three tiers of device configurations which the OEM may choose to adopt, with each tier being more prescriptive than the last, and with OEMs entitled to receive a greater share of Google revenues in respect of devices configured as Tier 3 or Premier devices, than for Tier 2 or Tier 1 devices.
346 Unsurprisingly, OEMs that have an RSA3 tend to configure most of their devices as Tier 3 or Premier devices. As at October 2020, some 65% of RSA3 activations were Premier tier.
347 Significantly, under the RSA3s, Google promised OEMs who configured their devices as Premier devices a share of the revenue generated from the Play Store on those devices. In exchange, OEMs were required not to pre-install any alternative app store on their devices.
348 For a device to be classified as a Premier device and for OEMs to be entitled to a share of Play Store revenues generated from that device, OEMs must configure that device as follows.
349 First, the device must not include any pre-installed app that is substantially similar to the Play Store, as determined in the sole discretion of Google, nor any launcher, over the air prompt or functionality that has the primary purpose of providing access to any service substantially similar to the Play Store.
350 Second, the device must set the Play Store as the “default” app store or marketplace for apps and all other digital content including subscriptions.
351 Third, the icon for the Play Store must be placed on the DHS.
352 Fourth, the device must not be configured so as to allow the OEM or any third-party to promote, introduce or suggest alternative app stores to users.
353 Fifth, the OEM must comply with the Premier device program requirements document, which may be updated by Google. Effective 31 July 2020, the Premier device program requirements document provided that a Premier device must only pre-install an app that is available on the Play Store, that is offered via Play auto-install unless separately agreed to in writing by Google, that does not interfere with the Premier device program requirements, that does not overlap with the functionality or features of the Play Store and other specified GMS apps, and that does not contain privileged install permissions which facilitate the downloading of other apps.
354 Let me say something about payments under RSA3s. RSA3s entitle an OEM to a proportion of one or two types of revenue.
355 The first type of revenue is net ad revenue, which is the revenue recognised by Google from ads displayed on a device’s results page and clicked by the user, minus REDACTED] of those revenues. These ads are displayed in response to a valid Search query from a series of agreed-upon Search access points such as Google.com or Google Assistant.
356 The second type of revenue is net play transaction revenue, which is the gross amount spent by device users on Play Store transactions, minus applicable taxes, adjustments, refunds, chargebacks and reversals, the portion paid to app developers, and 20% of the remainder. Play Store transactions are purchases of third-party apps and in-app purchases by a user within the Play Store on a Premier device.
357 The portion of these revenues payable to the OEM varies depending on whether a given device is configured in accordance with the requirements that apply to a Tier 1, Tier 2 or Tier 3 (Premier) device.
358 Now a share of Play Store revenues and the highest portion of advertising revenues are only payable under the relevant RSA3s in respect of Premier devices, that is, devices which do not include any pre-installed app that is substantially similar to the Play Store and do not promote or suggest any alternative app store.
359 Let me say something more about the MIAs and the Samsung incentive arrangements.
360 The MIAs are another form of incentive agreement, which have very similar features to the RSAs. Three selected OEMs have entered into MIAs rather than RSA3s, being Motorola, LG, and Samsung.
361 Under the Motorola and LG MIAs, very similar requirements to those specified in the RSA3s must be met for a device to qualify as a Premier device.
362 Relevantly, Motorola’s and LG’s MIAs entitle those OEMs to a monthly incentive payment if a minimum percentage of their devices activated that month are Premier devices. Further, the amount of that payment increases if the percentage exceeds higher thresholds. Further, the greater the proportion of activated devices that are Premier devices, the greater the amount payable by Google.
363 Motorola’s and LG’s entitlement to these incentives is conditional upon ongoing compliance with their MADAs.
364 As for Samsung, it has been party to an RSA but not an RSA3 with Google throughout the relevant period. The first was entered into in September 2017, and entitled Samsung to receive REDACTED] of net ad revenue earned from its devices, provided, among other things, that Samsung complied with the MADA and the AFA. An internal Google presentation indicates that, in 2019, Google was paying Samsung around USD 1.7 billion per annum under this RSA.
365 On the same day in November 2020, Google entered into both a replacement RSA and an MIA with Samsung. The second RSA was on relevantly similar terms to the first although with varying revenue shares. The MIA entitled Samsung to additional incentive payments, of between [REDACTED] of certain kinds of [REDACTED][REDACTED] earned from Samsung devices. The MIA also entitled Samsung to a bonus payment of USD 150 million.
366 Samsung’s MIA is in a different form to that of Motorola and LG. It does not provide for different tiers of devices and nor does it impose restrictions on Samsung relating to the Play Store besides those prescribed in the MADA. But it does make Samsung’s revenue share entitlement conditional upon Samsung complying with its MADA.
367 Let me turn to what Epic has alleged to be the app developer restrictive conduct.
App developer restrictive conduct and the developer distribution agreements
368 The app developer restrictive conduct alleged by Epic includes the following aspects.
369 The first alleged aspect is Google’s conduct in requiring app developers that wish to distribute apps through the Play Store to enter into a DDA, and comply with the associated developer program policies, containing the terms referred to below.
370 Those terms preclude app developers from distributing an alternative app store via the Play Store. Further, they preclude app developers from using user information obtained via the Play Store to distribute apps outside the Play Store. Further, they require app developers offering Play Store app in-app purchases to use Google Play Billing for those transactions except in limited circumstances. Further, they require app developers to pay a fee of 30% on Play Store app in-app purchases subject to limited exceptions. Further, they preclude apps distributed via the Play Store from leading users to a payment method other than Google Play Billing subject to limited exceptions. And further, they empower Google to terminate the DDA on 30 days’ notice (or less) if the above terms are breached.
371 So, Google required app developers that wished to distribute Android apps to Android smart mobile device users via the Play Store to agree to the following terms of the DDA and developer program policies.
372 Google Asia Pacific Pte Ltd is appointed as the app developer’s marketplace service provider in respect of apps distributed through the Play Store in Australia, and Google LLC is appointed as the app developer’s agent in respect of apps distributed through the Play Store in the US and various other countries. This is for the purpose of making the developer’s apps available to Android smart mobile device users.
373 Further, app developers must not use the Play Store to distribute or make available any product that has a purpose that facilitates the distribution of software applications for use on Android smart mobile devices outside of the Play Store.
374 Further, app developers are prohibited from using user information obtained via the Play Store to sell or distribute products outside the Play Store.
375 Further, Google may, in its discretion, determine that an app or a portion of an app violates the DDA or an applicable policy, or may have an adverse impact on Google including economic impact, in which case Google may reject, remove, suspend, or limit the visibility of the relevant app on the Play Store, and/or suspend and/or bar the app or app developer from the Play Store or Android smart mobile devices.
376 Further, Google may terminate the DDA for any reason on 30 days’ written notice, or immediately upon written notice, or with 30 days’ prior written notice if required by law, where the app developer breached the DDA or other agreement relating to the Play Store or the Android platform and/or the app developer or its app posed a potential risk of economic, reputational or security-related harm to Google.
377 Further, Google is authorised to give users refunds in accordance with the Play Store refund policies and may deduct the amount of those refunds from payments to the app developer.
378 Further, app developers wishing to offer Play Store app in-app purchases must have a valid payments profile under a separate agreement with a payment processor and be approved by a payment processor for a payments profile, with payment profile being a financial service account or profile provided by a payment processor to an app developer that enables the payment processor to collect and remit payments on the app developer’s behalf for “Products” distributed by the Play Store, payment processor being a Google-affiliated entity providing services that enable the app developer to be paid for “Products” distributed via the Play Store, and “Products” being software, content, digital materials, and other items and services as made available by app developers via the Google Play Console.
379 Further, app developers must pay Google a fee of 30% on Play Store app in-app purchases with certain limited exceptions.
380 Further, all claims arising out of or relating to the DDA or the app developer’s relationship with Google under the DDA are expressed to be governed by the laws of the State of California, excluding California’s conflict of laws provisions. App developers agree to submit to the exclusive jurisdiction of the federal or state courts of the county of Santa Clara, California to resolve any legal matter arising from or relating to the DDA or the app developer’s relationship with Google under the DDA.
381 Further, app developers offering Play Store app in-app purchases must use Google Play Billing for those transactions.
382 Further, in the period from at least January 2021 in respect of new apps, and 30 September 2021 in respect of pre-existing apps, which could be extended to 31 March 2022 on request, an app distributed via the Play Store must not lead users to a payment method other than Google Play Billing subject to certain exceptions.
383 Further, an app distributed via the Play Store must not modify, replace or update itself using any method other than the Play Store’s update mechanism, download executable code from a source other than the Play Store or allow users to install another app.
384 Further and as I have already indicated, where Google considers that an app developer or app has not complied with the terms of the DDA, including the developer program policies, Google may reject, remove, suspend, or limit the visibility of the app from the Play Store, suspend and/or bar the app and/or the app developer from the Play Store or Android smart mobile devices, and/or terminate the DDA.
385 Further, app developers who wish to offer Play Store app in-app purchases are required to enter into an agreement with Google Payment Australia Pty Ltd in respect of the use of Google Play Billing as the method of payment in Australia.
386 The second alleged aspect is Google’s conduct in entering into the GVP agreements and the AVP agreements with certain app developers.
387 Google entered into agreements with approximately 20 games app developers which required those app developers to do the following.
388 They had to release, or in the case of some app developers, use reasonable endeavours to release, Android apps on the Play Store at the same time as, or before, the release of the same app, that is, an app of the same title, on any other mobile distribution channel.
389 Further, for certain of those app developers, they had to ensure that the Play Store was not disadvantaged in terms of the quality and promotion of the developer’s apps.
390 Further, they had to ensure that the core content, features and functionality, or, in the case of some app developers, that the core game content and quality, of their Android apps released on the Play Store were the same on other mobile app stores or, in the case of some app developers, other comparable platforms.
391 Further, for certain of those app developers, they had to not remove any of their Android apps from the Play Store unless required by law or in other limited circumstances specified in the agreements.
392 Further, for certain of those app developers, they had to make good faith efforts or, in the case of one app developer, reasonable efforts, to include their apps in pre-registrations, open betas, and other early access programs on the Play Store.
393 Further, Google entered into AVP agreements with at least 4 app developers which required those app developers to act or refrain from acting in the following fashion.
394 First, they were not to remove specified Android apps from distribution on the Play Store unless required by Google or by law.
395 Second, they had to ensure that the specified Android apps had the same core content and features as are made available in the same app or service on platforms other than the Play Store.
396 Third, they had to promote its apps on the Play Store in the same or equivalent manner as it promotes the same app or service on platforms other than the Play Store.
397 Fourth, they could not make exclusive content available on the same app or service as those specified Android apps on platforms other than the Play Store, unless it is not technically feasible to make such content available on the Android OS.
398 Fifth, they were to make available to Play Store users the same SKUs or service tiers in each specified Android app as are made available to users on other platforms.
399 Sixth, with the exception of one developer, they had to ensure that the subscription and/or purchase price applicable to each specified Android app on the Play Store is at least as favourable as the subscription and/or purchase price of the same app or service on other platforms.
400 Seventh, they had to use Google Play Billing as the sole payment solution in the specified Android apps across all devices in all markets in which those apps are available on the Play Store.
401 The third alleged aspect is Google’s conduct in giving effect to and/or enforcing the terms referred to above including in relation to Epic, for example by suspending Epic’s publishing status on the Play Store, removing Fortnite from the Play Store, refusing to allow Epic to offer EDP for any Play Store app in-app purchases and failing to agree to Epic’s request for in-principle approval to make the Epic Games Store available on the Play Store.
402 Let me now turn to saying something more about the relevant agreements concerning app developers.
The developer distribution agreements
403 In addition to its agreements with OEMs, Google has imposed various contractual restrictions on app developers, primarily through the DDA. I have mentioned some of this earlier, but let me set out the detail.
404 Any app developer that wishes to distribute Android apps through the Play Store must enter into a DDA. Its terms are non-negotiable, and clause 15.1 empowers Google to vary them at any time.
405 Now the relevant terms of the DDA may be divided into three categories.
406 First, one has terms governing the relationship between Google and the developer, as well as the service supplied under the DDA.
407 Second, one has a term prohibiting the distribution of rival app stores such as clause 4.5.
408 Third, one has terms relating to Google’s service fee and payments policy.
409 The DDA is a contract between three separate Google entities and the developer. Those entities are Google LLC, Google Commerce Limited, and Google Asia Pacific Pte Limited.
410 Pursuant to clauses 2.1 and 3.1 of the DDA, the developer makes the following appointments.
411 First, the developer appoints Google LLC as its “agent” to make its products available in the Play Store to users in various countries and territories predominantly located in North and South America; there is a definition of “Products” that I will identify in a moment.
412 Second, the developer appoints Google Commerce Ltd as its “agent” to make its products available in the Play Store to users in various countries and territories predominantly located in Europe, the Middle East and Africa.
413 Third, the developer appoints Google Asia Pacific Pte Ltd as its “marketplace service provider” to make its products available in the Play Store to users in various countries and territories predominantly located in Asia and the Pacific, including Australia.
414 Each of those appointments expressly states that “the purchase and sale of [the developer’s] Product(s) is governed by a contract of sale directly between [the developer] and users”, save where Google Commerce Ltd is the merchant of record for sales in specified countries in Europe, the Middle East and Africa. So, neither Google LLC nor Google Asia Pacific Pte Ltd effects any contracts of sale on behalf of the developer under the DDA.
415 Let me then turn to some of the specific provisions.
416 “Products” are defined by clause 1 as “Software, content, digital materials, and other items and services made available by Developers via the Play [Store]”. They include apps and digital content purchased within the app.
417 Clause 2.1 refers to the developer’s “use of Google Play to distribute Products” and provides that Google will “display and make [the developer’s] Products available for viewing, download, and purchase by users”.
418 Clause 3.1 similarly provides that the developer appoints Google as its agent or marketplace service provider (as the case may be) “to make [the developer’s] Products available in Google Play”.
419 “Google Play” is defined as the “software and services, including the Play Console, which allow Developers to distribute Products to users of Devices”. Various other provisions refer to products being “distributed” or “made available” via the Play Store.
420 Clause 3.2 stipulates that the DDA “covers both Products that users can access for free and Products that users pay a fee to access”. It then provides that “[i]n order for [the developer] to charge a fee for [the developer’s] Products and to be paid for Products distributed via Google Play, [the developer] must have a valid Payments Profile under a separate agreement with a Payment Processor”.
421 A “Payments Profile” is defined as a “financial service account or profile provided by a Payment Processor to a Developer that enables a Payment Processor to collect and remit payments to the Developer on the Developer’s behalf for Products sold via Google Play”.
422 As for a “Payment Processor”, it is defined as a “Google affiliated entity providing services that enable Developers to receive payments for Products sold via Google Play.”
423 So, the terms of the DDA make it clear that the “services that enable Developers to receive payments for Products sold via Google Play” are provided by payment processors “under a separate agreement”. Those services are not provided by Google LLC, Google Commerce Ltd or Google Asia Pacific Pte Ltd. Nor are they provided under the DDA.
424 But what is provided under the DDA is the distribution service constituted by the Play Store. Google itself defines the Play Store as the “services … which allow Developers to distribute Products to users of Devices”.
425 Pursuant to clauses 2.1 and 3.1 of the DDA, the developer appoints Google as its agent or “marketplace service provider” to make the developer’s products available for viewing, download and purchase by users in the Play Store. “Products” are defined by clause 1 as “Software, content, digital materials, and other items and services made available by Developers via the Play [Store]”. They include apps and digital content purchased within the app.
426 Where Google determines in its sole discretion that an app developer’s product violates the DDA or the developer program policies, or may have an adverse impact on Google, Google is entitled under clause 8.3 of the DDA to “reject, remove, suspend, limit the visibility of a Product” on the Play Store and/or suspend and/or bar any product and/or app developer from the Play Store or from Android smart mobile devices.
427 Clause 4.1 of the DDA requires app developers and their products to adhere to the developer program policies. Two of those policies are presently relevant, being the device and network abuse policy and the payments policy. The latter compels developers to use Google Play Billing for in-app purchases of digital content.
428 A breach of either policy entitles Google to, among other things, remove the developer’s app from the Play Store and terminate the DDA immediately or on 30 days’ notice.
429 Clause 4.5 of the DDA prohibits app developers from using the Play Store to distribute or make available any product that has a purpose that facilitates the distribution of other Android apps for use on Android devices outside of the Play Store.
430 In other words, clause 4.5 prohibits an app store or any app that facilitates the distribution of another app from being distributed through the Play Store.
431 This prohibition has existed in this form since 25 September 2014. Prior to that date, clause 4.5 only prohibited products whose primary purpose was to facilitate the distribution of Android apps. Prior to this change there were apps on the Play Store that distributed other apps. Google altered the terms of clause 4.5 which had the effect of stifling emerging competition for the Play Store in app distribution.
432 Clause 4.9 of the DDA prohibits app developers from using user information obtained via the Play Store to sell or distribute products outside the Play Store. This prohibition has been present in all versions of the DDA since at least June 2014. It precludes app developers from using information about their own customers. It is problematic given that Google purports to be the app developer’s agent or marketplace service provider.
433 Clause 3.8 of the DDA authorises Google to give users refunds in accordance with the Play Store’s refund policies, and to deduct the amount of any refunds from payments due to the developer. Google’s refund policies generally provide that Google will administer refunds within the first 48 hours and thereafter users should contact the developer.
434 By the combination of clauses 2.1, 3.1, 3.8 and 4.9 of the DDA, Google interposes itself between the developer and its customers, with the result that the control of important interactions is assumed by Google. The outcome of refund applications, for example, will often depend on Google’s refund policy and its application thereof, not the developer’s.
435 More broadly, these terms limit the developer’s ability to form a direct commercial relationship with its customers, and to expand that relationship beyond the Play Store.
436 For app developers, this direct relationship with users of their apps is important. Differing levels of control over the customer relationship is one of the ways in which alternative providers of app distribution services and in-app payment solutions for Android apps would be likely to compete with the Play Store and Google Play Billing, if Google’s conduct did not foreclose or impede such competition.
437 Clause 3.4 of the DDA requires app developers to pay Google a service fee, being a percentage of the price of Android apps purchased through the Play Store and of in-app purchases of digital content. The service fees payable by app developers under the DDA have varied over time, as set out in the following table:
Time Period | Service Fee for subscriptions | Service Fee for developer’s first US$1 million | Service Fee for developers under special programs | Service Fee for all other Play Store revenue |
Mar 2011 – 23 May 2012 | - | 30% | - | 30% |
24 May 2012 – 31 Dec 2017 | 30% | |||
1 Jan 2018 – 22 June 2021 | 30%, then 15% for automatically renewing subscriptions | |||
23 June 2021 – 30 June 2021 | 15% or lower | |||
1 July 2021 – 31 Dec 2021 | 15% or 30%, then 15% for automatically renewing subscriptions | 15% | ||
1 Jan 2022 – present | 15% for all subscriptions |
438 As the table shows, the service fee varies depending on the app developer’s revenue and the type of digital content offered for sale. Generally, app developers now pay a service fee of 15% on the first USD 1 million of revenue earned by the developer each year, 30% of revenue in excess of USD 1 million of revenue each year, and 15% of revenue for automatically renewing subscriptions.
439 Developers that are eligible for special programs pay a 15% or lower service fee. These programs generally target media companies, or developers offering video, audio or music subscriptions, or digital books.
440 Further, Google charges different service fees that are 4 percentage points lower where app developers use an alternative payment solution in South Korea or India, 3 percentage points lower where app developers of non-gaming apps use an alternative payment solution in the EEA, and 4 percentage points lower where app developers of non-gaming apps use an alternative payment solution as part of Google’s pilot program for user choice billing.
441 Now the service fee is only payable on apps and in-app products sold through the Play Store’s billing system or through an alternative billing system, the latter being a system permitted under Google’s user choice billing (UCB) or developer only billing (DOB) programs.
442 The service fee payable by app developers under the DDA has varied over time to time, as summarised in the table that I have set out earlier.
443 Generally, developers now pay a service fee of 15% on the first USD 1 million of revenue earned by the developer each year; a service fee of 30% of revenue in excess of USD 1 million of revenue each year; and a service fee of 15% of revenue for automatically renewing subscriptions regardless of the revenue earned by the developer.
444 Developers eligible for special programs pay a 15% or lower service fee. These programs generally target media companies, or developers offering video, audio or music subscriptions, or digital books.
445 In addition, Google charges a varied service fee in circumstances where UCB or DOB apply.
446 Outside of special programs for eligible developers, UCB, and DOB, Google has made only limited changes to the service fee that it charges for in-app purchases of digital content over time. When in-app purchases were first introduced to the Android Market in 2011, the service fee for such purchases was 30%. Some 13 years later, the service fee is still 30%, save for the first USD 1 million in earnings each year and subscriptions, both of which are charged at 15%.
447 Google’s service fees are similar to those generally charged by Apple, although there are two differences.
448 First, Apple charges a 15% fee to developers whose earnings were under USD 1 million in the prior year, as opposed to charging all developers 15% on their first USD 1 million.
449 Second, Apple’s fee for subscriptions is 30% in the first year and 15% thereafter.
450 Let me set out a little history concerning the changes.
The subscription pricing change in 2018
451 The first change to Google’s subscription pricing occurred with effect from 1 January 2018, when Google reduced its service fee for subscriptions that had been active for more than one year from 30 to 15%.
452 Google witnesses said that this change was driven by a need to remain price competitive with Apple, which had reduced its fee on subscriptions active for more than one year from 30 to 15% some 18 months earlier, with effect from 13 June 2016.
453 But the document in which this change was proposed, a document that Mr Feng co-presented, gave five reasons for the change, only one of which related to Apple. The other four reasons for the change listed in the document included encouraging subscription developers to adopt Google Play Billing and easing the path to a potential Play Store payment policy change, being the removal of the external consumption exemption. As to Apple, the document merely said, “Bring Play’s pricing for subscription SKUs in line with market – Apple offers 30% for 12 months, 15% thereafter”.
454 Google’s behaviour did not amount to competing with Apple on price, or on any other metric. That is a fortiori when the price adjustment was made some 18 months after that of Apple. And it is especially true in this case, given the other reasons for the change. Moreover, bringing one’s pricing into line with the market is not competing on price.
The service fee reduction for small developers and a further subscription pricing change in 2021
455 On 18 November 2020, Apple announced a small business program, whereby its service fee was reduced to 15% for those developers who earned less than USD 1 million in the prior year.
456 With effect from 1 July 2021, Google reduced its service fee to 15% for the first USD 1 million earned each year by all developers. In October 2021, Google reduced the service fee for subscriptions to 15% in the first year.
457 Although the reasons for the change are contentious and a topic to which I will return later, it is convenient to note here that in my view one of the motivations for making the first of those changes was the pressure Google was facing from regulators.
458 In an internal document dated 16 November 2020 titled Project Runway: Proposal for changes to Play business model, Google set out its hypotheses, including that “[w]e have an a la carte menu of additional levers to pull in a set of forecasted PR/regulatory scenarios for further discussion”, and “[w]e should proactively make moderate changes in 2021 to forestall more drastic required changes”.
459 Under the heading “Scenario Planning”, the following scenarios were contemplated.
460 The first stated:
* Should we be REQUIRED to adjust our service fee, we would need to re-imagine the store promotional strategy and GPB strategy.
* If government mandated requirement to make play billing optional, we respond with aggressive store changes and perhaps lower service fee …
461 The second stated “[i]f government mandated price for play billing (say 20% or cost + 5%) (WIP, needs more thinking)…”.
462 The third stated:
* We c/should VOLUNTARILY adjust our service fee now to improve optics, align value delivered with fees charged, and reduce agitation --
…
* We recommend the first magical bridge option (30% for the first year after user purchase, 15% thereafter) …
…
* Match Apple’s discount for small developers and perhaps be more aggressive by tiering it lower in emerging markets.
…
463 Further, the document makes no reference to a supposed competitive dynamic with Apple as somehow necessitating or justifying its proposals. Rather, the focus is on “forestall[ing] more drastic required changes” by way of regulation and “optics”.
464 On 21 November 2020, the day of Apple’s small business announcement, Mr Samat prepared a document which commenced with a summary of Apple’s small business program announcement, including reactions from the press and developers. The document then provides an overview of the reaction from regulators, which includes that Apple’s announcement had been “informally described … as too little too late and will not help Apple’s position in the Digital Markets Act debate in Europe” and that Google was “expecting to receive” a request from South Korean legislators to “follow Apple’s lead”.
465 The document then set out Google’s “take”, as follows:
Waiting for Apple to make the first move has been our plan. Our strategy has been to wait to make any public revenue share changes until Apple moved first. We did not want to move downward on rev share while Apple stayed at 30%, nor did we want to give them the opportunity to “one-up” any announcement we made and cause us to need to react again.
We have a very similar program scoped out…
We will take the next several weeks to gain more feedback on how Apple’s changes landed. The benefit of going second here is we have the opportunity to be more thoughtful and take into account the reaction. …
466 So, Google wanted Apple to lower its prices and was not at all concerned that this would cause Google to lose customers.
467 Google’s motives are also confirmed by a 2 December 2020 document titled Runway January 2021 Announcement Proposal and Status, which records that Google had “decided to announce in January 2021 an adjustment to our fee schedule, focused on providing relief to small developers and defusing some of the regulatory pressure experienced in several countries”. Defusing regulatory pressure was the real reason for this change.
468 The following “goals” are set out in the document:
Defuse immediate regulatory pressure
Be seen as helping people build their business…
Reduce the new perceived gap between Apple and Play’s billing policies
Continue to allow Apple to make first moves on service fee structure changes
469 The penultimate “goal” was not about price competition but about the regulatory pressure that had arisen due to the “gap between Apple and Play’s billing policies”. That it was not about price competition is confirmed by the last goal.
470 The document then outlines the “Desired PR and Regulatory Landings” and says “our message will be evaluated based on how many devs pay less. Press will line us up vs Apple”. Again, it was all about “PR and regulatory landings”, not winning customers from Apple.
471 Further, a drafting comment records:
… we need a headline PR/reg message – esp given that the message is the primary goal in this effort … Arguably the most believable, as well as most helpful reason is competitive pressure/response…Helpful to our case – if we’re trying to create the meme intense competitive pressure.
472 In other words, competition was a “message” or “meme” Google was “trying to create”. If competition were the reality, this would not have been necessary.
473 I will return to the evidence of some of the Google witnesses on these questions much later in my reasons.
Google Play Billing — the DDA and the payments policy
474 Google Play Billing is the payment solution that Google requires app developers and consumers to use, and is the only payment solution that Google permits app developers and consumers to use, for accepting and processing payments for Play Store in-app purchases.
475 Google Play Billing, as a payment solution, provides for and facilitates the acceptance and processing of payments from Android smart mobile device users for apps or in-app purchases.
476 It does this by, among other things, providing for the acceptance and collection of payments from Android smart mobile device users, all necessary engagements with credit providers, payment processors and financial institutions, the deduction and payment of any relevant fees or commissions, and the payment of the remaining balance to the app developer.
477 Google Play Billing is charged by Google Payment Australia Pty Ltd, or alternatively by Google LLC, Google Asia Pacific Pte Ltd and/or Google Payment Australia Pty Ltd, at a 30% commission to app developers for Play Store in-app purchases or, in some limited circumstances, 15%.
478 Clause 4.1 of the DDA provides that the developer must adhere to the developer program policies, which include Google’s payments policy.
479 The payments policy provides that developers charging for app downloads from the Play Store must use Google Play Billing.
480 The payments policy provides that Play Store-distributed apps requiring or accepting payment for access to in-app features or services, including any app functionality, digital content or goods, must use Google Play Billing unless section 3 or section 8 of the payments policy applies.
481 Section 3 stipulates that Google Play Billing must not be used where the payment deals with any of the following items or matters.
482 First, it must not be used where the payment is primarily for the purchase or rental of physical goods, for the purchase of physical services or a remittance in respect of a credit card bill or utility bill.
483 Second, it must not be used where the payment includes peer-to-peer payments, online auctions or tax exempt donations.
484 Third, it must not be used where the payment is for content or services that facilitate online gambling.
485 Fourth, it must not be used where the payment is in respect of any product category deemed unacceptable under Google’s payments centre content policies.
486 Section 8 was first added to the payments policy in late 2021. The provision was initially limited to in-app purchases effected by users in South Korea, but its scope was enlarged with the subsequent introduction of inter-alia the UCB pilot and the DOB program.
487 These programs permit developers to offer users an alternative billing system in countries where UCB or DOB are available, but only if they comply with requirements prescribed by Google.
488 In summary then, except where developers are participating in UCB or DOB, the payments policy relevantly requires developers to exclusively use Google Play Billing for in-app purchases of digital content within apps distributed via the Play Store. The parties before me referred to this as the payments tie.
489 And as I have said, the payments policy does not require the use of Google Play Billing for in-app purchases of physical goods or services. In fact it prohibits such use.
490 And since the service fee is only payable on apps and in-app products sold through Google Play Billing or an alternative billing system, no service fee is payable on in-app purchases of physical goods or services. And nor is a service fee payable in respect of apps which are distributed without charge and without charging for in-app purchases, even if the developer monetises the app in a different way, for example, with paid advertising.
491 There is also an exemption from the requirement to use Google Play Billing in around 15 countries where Google Play Billing is not offered. Developers can use their own billing systems for purchases made in those countries.
492 Now it is convenient at this point to say something about the external consumption exception.
493 Between August 2013 and 20 January 2021, the payments policy contained another exception, whereby developers offering additional content, services or functionality within a non-gaming app downloaded from the Play Store were not required to use Google Play Billing where the payment was for digital content or goods that may be consumed outside of the application itself. The parties have referred to this as the external consumption exception.
494 With effect from 20 January 2021, Google removed the external consumption exception from the payments policy. Google described this as a “clarification”, but this was an unsatisfactory description. The change was a unilateral change to the contractual obligations of developers which required them to use Google Play Billing and to pay a service fee on in-app purchases of digital content that, until then, had been exempt from these requirements. Existing apps that used an alternative payment solution were given until 30 September 2021 to comply with the amended payments policy. I have discussed this so-called Orwellian-like “clarification” later.
495 Google announced that from 1 June 2022, any app developer that was non-compliant with the amended payments policy would be removed from the Play Store.
496 Before Google removed the external consumption exemption from its payments policy in January 2021, around 5,000 developers had chosen to use a payment solution other than Google Play Billing to facilitate in-app purchases of digital content within Play Store apps. Google expected more to follow.
497 Google expected contagion or a domino effect, with an increasing number of developers having recourse to alternative payment solutions.
498 I will return to the topic of the external consumption exemption much later in my reasons.
499 But I would say here that in my view the major reason Google removed the external consumption exemption was to raise more revenue by requiring more developers to use Google Play Billing rather than an alternative payment solution.
500 Now the requirement to use Google Play Billing is not imposed for security reasons. If it were, that would surely have been foremost among the considerations in favour of removing the external consumption exception and it would not have taken several years for Google to alter its policy.
501 Moreover, Google positively requires alternative payment solutions to be used for in-app purchases of physical goods and services, and permits them where UCB and DOB apply. That conduct is not consistent with a genuine concern that such alternative solutions are inadequate from a security perspective.
502 Now many developers affected by the removal of the external consumption exception preferred to use an alternative payment solution and did not want to use Google Play Billing.
503 Google has suggested that this is explained by a desire to avoid paying the service fee. But many developers considered Google Play Billing to be a deficient product that was harmful to their business.
504 The evidence shows that many developers wanted to use an alternative payment solution because the relevant alternative better suited their business and payment solution needs.
505 Developers wanted better forms of payment (FOP) coverage, better involuntary churn rates, and the ability to maintain a direct relationship with their customers, including the ability to respond to questions and complaints. Developers wanted to use the same payment solution for in-app purchases of both digital and physical products and to use the same payment solution across more than one distribution channel. Developers wanted better access to data about their users and the ability to bill customers at the time they chose and for a price they chose. And developers wanted the ability to adjust the payment solution features that they acquired from one country to the next, based on local market conditions.
506 The desire amongst some large developers to use an alternative payment solution was so great that they were willing to use an alternative payment solution even if there was no reduction in Google’s service fee.
The anti-steering prohibition
507 On 20 January 2021, Google amended the payments policy to prohibit apps that were required to use Google Play Billing from leading users to a payment method other than the Play Store’s billing system.
508 This prohibition expressly extends to leading users to other payment methods via an app’s listing in the Play Store, in-app promotions related to purchasable content, in-app webviews, buttons, links, messaging, advertisements or other calls to action, and in-app user interface flows, including account creation or sign-up flows.
509 The parties before me referred to this prohibition as the “anti-steering rule”.
510 Google has enforced the anti-steering rule.
Device and network abuse policy
511 Clause 4.1 of the DDA requires app developers and their products to comply with the developer program policies. One such policy is the device and network abuse policy, which stipulates that an app distributed via the Play Store must not “modify, replace, or update itself using any method other than Google Play’s update mechanism”, and must not “download executable code … from a source other than Google Play”, or allow users to install another app.
512 This restriction plays a similar role to that of clause 4.5 of the DDA, insofar as it precludes the distribution of apps that distribute other apps. But the device and network abuse policy does more than this.
513 Developers tend to update their apps regularly such as to effect improvements, to make new features available to users, and to resolve software glitches. Yet the device and network abuse policy precludes developers from updating their own apps, except through the Play Store, even after a user has selected and downloaded the app from the Play Store onto their own device. The result is that an app distributed through the Play Store is tied to the Play Store.
514 Google, a so-called agent of app developers, has inserted itself, permanently, between those developers and users of their apps, and the developers remain subject to Google’s control. A decision by Google to remove their app from the Play Store or to terminate the DDA will make it impossible for the developer to update apps previously downloaded from the Play Store, and will preclude the developer from continuing to serve its users.
515 Further, clause 4.9 of the DDA prohibits app developers from using information obtained via the Play Store to contact those users and suggest that they might want to reacquire the app outside the Play Store.
516 I have kept these realities in mind when evaluating Google’s arguments as to the alternative choices available to app developers. How many of them can truly afford to do other than bend the knee and pay whatever fee, or accept whatever condition, Google is minded to impose, when the alternative is to abandon every user the developer has ever acquired via the Play Store and hope to reacquire them somewhere else within the Android ecosystem that Google controls?
Other provisions of the DDAs
517 Let me address some other provisions of the DDA.
518 First, clause 15.1 empowers Google to vary the terms of the DDA at any time. This is a power which Google has exercised in the past, including to make material changes.
519 One example is Google’s alteration of its payments policy, which Google changed to require developers, for the first time, to pay a service fee on purchases of digital content that could be consumed outside the app.
520 Another example is Google's amendment to clause 4.5, by which Google expanded the class of apps with distribution capabilities that were prohibited from being distributed through the Play Store.
521 Second, clause 15.3 provides that if developers do not agree with Google’s changes to the DDA, their “sole and exclusive remedy” is to terminate their use of the Play Store. In other words, developers must take it or leave it. And if they leave it, developers will lose the ability to distribute or update their apps previously distributed through the Play Store. Current users of their apps will not be able to make any in-app purchases within those apps.
522 Third, clause 10.3 permits Google to terminate the DDA “for any reason” on 30 days’ notice where “allowed under applicable law”. The same clause permits Google to terminate the DDA “immediately upon written notice or with thirty (30) days prior written notice if required under applicable law” if the developer has “breached any provision” of the DDA or the developer or its product “pose a potential risk for economic, reputational, or security-related harm to Google, users, or other third-party partners.”
523 Termination of the DDA will cause the developer to lose the ability to distribute or update their apps previously distributed through the Play Store, and current users of their apps will not be able to make any in-app purchases within those apps.
524 Any user that downloaded the app from the Play Store will no longer have an app that updates, or that facilitates in-app purchases. Before they can obtain an up-to-date version of the app, or make an in-app purchase, users will have to find the app elsewhere and download it again.
525 Fourth, clause 8.3 provides that Google may “suspend and/or bar any Product and/or Developer from Google Play” if inter-alia Google “determines in its sole discretion that a Product … violates this Agreement, applicable policies, or other terms of service, as may be updated by Google from time to time”. A suspension results in the developer’s app being removed from the Play Store, such that it is no longer available for download by users, it cannot be updated, and current users are unable to make any in-app purchases within the app.
526 Fifth, clause 4.9 prohibits app developers from using user information obtained via the Play Store to sell or distribute products outside the Play Store. This precludes developers from using information about their own customers. It is incongruous, given that Google purports to be the developer’s agent or marketplace service provider.
527 Sixth, clause 3.8 authorises Google to give users refunds in accordance with the Play Store’s refund policies, and to deduct the amount of any refunds from payments due to the developer. Google’s refund policies generally provide that Google will administer refunds within the first 48 hours and thereafter users should contact the developer.
528 An exercise of Google’s power to terminate the DDA or to suspend apps from the Play Store is likely to have a material adverse impact on most developers that have been distributing their apps through the Play Store for any length of time. Affected developers would lose their Play Store customers and their in-app purchase revenues from those users.
529 Those powers, which include a right to terminate for any reason on 30 days’ notice, confer considerable leverage or bargaining power on Google vis-à-vis developers.
530 Likewise, Google’s right to alter the terms of the DDA confers considerable leverage or bargaining power on Google vis-à-vis developers, whose only “remedy” is to terminate the DDA and lose all their Play Store users and associated revenues.
The Games Velocity Program agreements
531 The origins of the GVP agreements are sourced to Project Hug which I will describe later.
532 The GVP agreements were structured as addenda to existing DDAs between Google and the relevant app developers. Under the GVP agreements, in exchange for benefits provided by Google, which included marketing support, advertising credits, and a share of Google’s Play Store revenue from the developer’s apps, to be provided in the form of Google Cloud credits, the developers undertook to do various things.
533 First, they undertook to simultaneously launch new titles on the Play Store and other mobile distribution channels. This has been described by the parties and I will describe it as sim-ship. Google described this as the key criteria of the GVP.
534 Second, they undertook to ensure that Play Store users were not materially disadvantaged compared to users on other mobile distribution channels, with regard to core game content, features and functionality. In other words, there had to be content parity.
535 Third, they undertook to ensure that titles were not removed from the Play Store unless the developer was required to do so by applicable law, was required to do so by Google, or there was agreement between Google and the app developer to do so.
536 Fourth, they undertook to maintain game quality, with a prescribed minimum user rating.
537 Fifth, they undertook to make best efforts to include titles in pre-registrations, open betas and other early access programs in the Play Store, and to participate in strategic programs.
538 In addition, the Tencent GVP agreement required Tencent to ensure that prices for its Android apps on the Play Store, including the purchase price, any subscription prices and the price for any in-app purchases, were at least as favourable as the prices on any other platform.
539 Further, Tencent was required to make available all product and service offerings applicable to its Android apps within the Play Store that are available on any other platform, unless a product or service offering is not compatible with the Play Store, or it is not technically feasible to make a product or service available within the Play Store.
The Apps Velocity Program agreements
540 Let me say something more about the AVP agreements although I have already touched on them.
541 In early 2020, Google decided to extend Project Hug, which I will detail later, to 20 top non-game app developers. The extended Project Hug proposal, which became the AVP, was presented to the business council in February 2020. It was approved on 6 March 2020. Google thereafter entered into AVP agreements with four developers.
542 The AVP agreements were structured as addenda to the existing DDAs between Google and the relevant developers. Under the AVP agreements, Google agreed to provide certain benefits to app developers such as marketing support and credit for purchasing advertisements through Google, in exchange for the app developers agreeing to various restrictions.
543 First, the app developers’ designated apps were required to use Google Play Billing as the sole payment solution across devices in all markets in which the designated apps were available on the Play Store.
544 Second, the app developers’ designated apps were required to have the same core content and features as any comparable product, being an application or service that is the same as the applicable title or any in-app purchase product or subscription product that can be used in titles, except that it is made available by the app developer on platforms other than the Play Store, and to promote apps in the same or equivalent manner.
545 Third, the app developers’ designated apps were required to make available the same “SKUs or service tiers” on the Play Store as other platforms. Further, some of the developers were required to ensure that the subscription or purchase price applicable to each designated app on the Play Store was at least as favourable as the subscription or purchase price of comparable products.
The mobile OS licensing and Android mobile app distribution markets — section 46
546 I have laid out what is said to be the impugned conduct and the relevant contractual matrix. Let me now turn more generally to Epic’s s 46 claim against Google and begin by again identifying Epic’s posited markets.
547 Epic says that there is a mobile OS licensing market, which is a market for the supply of licenses for mobile operating systems, where the geographic dimension of the market is a global market excluding China, of which Australia forms part.
548 Further, Epic says that there is an Android mobile app distribution market, which is a market for the supply of services for the distribution of Android apps to Android smart mobile device users, with the following elements or dimensions.
549 First, the services consist of the provision of services to app developers enabling or facilitating app developers to reach, offer and provide Android smart mobile devices users with Android apps and associated updates and/or the provision of services to Android smart mobile devices users enabling or facilitating Android smart mobile devices users to be presented with or to find, obtain and utilise Android apps and associated updates.
550 Second, the geographic dimension of the market is Australia or a global market excluding China, of which Australia forms part.
551 Further, Epic says that there is an Android in-app payment solutions market, which is a market for the supply of services to app developers for accepting and processing payments for the purchase of digital content, including by way of subscriptions, within an Android app, with the following elements or dimensions.
552 First, the services consist of the provision of services to app developers enabling and/or facilitating app developers to accept and process payments for the purchase of digital content, including by way of subscriptions, within an Android app.
553 Second, the geographic dimension of the market is Australia or a global market, excluding China, of which Australia forms part.
554 Further, Epic says that in the alternative to an Android mobile app distribution market, there is a mobile app distribution market, which is a market for the supply of services for the distribution of Android apps and native apps written for iOS to smart mobile device users, with the following elements or dimensions.
555 First, the services consist of the provision of services to app developers enabling or facilitating app developers to reach, offer and provide smart mobile device users with native apps and associated updates and/or the provision of services to smart mobile device users enabling or facilitating smart mobile device users to be presented with or to find, obtain and utilise native apps and associated updates.
556 Second, the geographic dimension of the market is Australia or a global market excluding China, of which Australia forms part.
557 Now Epic’s case is that Google has contravened s 46(1) of the CCA by engaging in conduct that had the purpose, and the effect or likely effect, of substantially lessening competition in the Android mobile app distribution market.
558 Now there are two markets which are relevant to this allegation.
559 First, there is the mobile OS licensing market, which is a market for the supply of mobile OS licenses to OEMs.
560 Second, there is the Android mobile app distribution market, which is a market for the supply of services for the distribution of Android apps.
561 Epic’s case is that Google has a substantial degree of power in each of these markets and has engaged in conduct for the purpose, and which had the effect or likely effect, of substantially lessening competition in the Android mobile app distribution market.
The purpose of Google’s conduct in the Android mobile app distribution market
562 Epic says that a substantial purpose of Google in engaging in the OEM restrictive conduct and the app developer restrictive conduct, which in this context includes the payments tie and the anti-steering rule, was to substantially lessen competition in the Android mobile app distribution market.
563 It is said that Google’s anti-competitive purpose ought to be inferred from the OEM restrictive conduct and the app developer restrictive conduct themselves.
564 Further, it is said that internal business records of Google demonstrate that a substantial purpose of the impugned conduct was to prevent or hinder competition for the Play Store.
The effect of Google’s conduct on the Android mobile app distribution market
565 Epic says that Google’s OEM restrictive conduct including the terms and enforcement of the ACCs, the MADAs and the RSA3s, and Google’s app developer restrictive conduct including the terms and enforcement of the DDAs, the GVP agreements and the AVP agreements have created and sustained many of the barriers to entry in the Android mobile app distribution market and operate, individually and cumulatively, to prevent or hinder competition in that market.
566 Epic says that the effect of the OEM restrictive conduct and the app developer restrictive conduct has been and is to prevent or hinder alternative sources of supply in the Android mobile app distribution market, to create a virtual monopoly, and to increase barriers to entry such that there is almost no independent rivalry or substitution in the market. There is almost no market pressure on Google to reduce its costs of production and prices or improve the quality of its Android app distribution services.
567 Epic says that Google has closed off every effective path by which an alternative Android app store might achieve a significant market share, and it has severely hindered app developers’ capacity to distribute Android apps outside the Play Store.
568 Epic says that the ways in which the OEM and app developer restrictive conduct have prevented or hindered competition in the Android mobile app distribution market include the following seven points or matters.
569 First, the OEM restrictive conduct ensures that the Play Store is pre-installed in the most prominent locations on virtually every Android device in the world. This guarantees the Play Store can distribute apps to virtually every Android device user, makes it virtually essential for app developers wishing to reach those users to distribute their apps via the Play Store, enhances network effects that benefit the Play Store, and increases market concentration at the expense of its rivals.
570 In a world without the OEM restrictive conduct, rival Android app stores could and would negotiate with different OEMs for pre-installation on all or some of that OEM’s devices, including exclusively, or else in a more prominent location than the Play Store, to improve the discoverability and reach of the rival app store relative to that of the Play Store.
571 Second, the OEM restrictive conduct embodied in the RSA3s and the Motorola and LG MIAs hinders competition because it creates a disincentive for the relevant OEMs to pre-install or promote any rival Android app store. These terms, together with the technical restrictions requiring Google’s approval for privileged install permissions, hindered and ultimately prevented Epic’s attempt to pre-install the Epic Games App on Sony, LG, and OnePlus devices.
572 In a world without these terms, the relevant disincentives would not exist.
573 Third, the OEM restrictive conduct comprising the technical restrictions hinders competition from rival app stores in several ways.
574 Since Google has a discretion to approve (or not) the inclusion of a rival app store on the “allowlist” before Android devices may be distributed under a MADA, Google ultimately controls whether, and if so which, alternative app stores may be granted a privileged install permission on Android devices.
575 Further, those restrictions hinder the installation of rival app stores on Android devices by way of direct downloading, including by deterring users from installing those rival stores.
576 Further, the restrictions also hinder the installation of the first app a user seeks to download from a directly downloaded app store.
577 Further, the restrictions disadvantage a rival app store that lacks a privileged install permission when seeking to compete with an app store that has such permission.
578 Overall, the technical restrictions mean that any rival app store which is wholly or partly reliant upon direct downloading to be installed on Android devices must overcome a poor initial user experience that is apt to dissuade a large proportion of users from completing the installation process or ever using the rival app store.
579 In a world without these restrictions, OEMs could choose which app stores ought to be granted a privileged install permission on their devices without needing to obtain Google’s approval, and rival app stores could be distributed more successfully by way of direct downloading. Both eventualities would enable rival app stores to find their way onto more Android devices and to compete more effectively against the Play Store.
580 Fourth, by the app developer restrictive conduct, being specifically clause 4.5 of the DDA, as well as clause 4.1 and the device and network abuse policy, Google denies rival Android app stores access to the most effective means of distribution to Android device users, that is, via the Play Store.
581 The effect of these terms is that there is no truly effective means by which rival Android app stores can be distributed to the vast majority of Android devices. Pre-installation and direct downloading each involve the obstacles outlined already. And no other Android app store besides the Play Store has a share of app store downloads above about 2.5%. There is next to no prospect of a rival emerging or expanding to impose material competitive constraints on the Play Store with these terms on foot.
582 Conversely, in a world without these terms, rival app stores could be distributed to almost every Android device in the world, through the most popular Android app distribution channel, without users having to confront any of the technical restrictions.
583 Fifth, by clause 4.1 of the DDA and the device and network abuse policy, Google precludes developers from updating their own apps, except through the Play Store. This means developers cannot switch from distributing their apps through the Play Store to doing so only through a rival app store, without losing the ability to update apps previously downloaded from the Play Store. As a result, developers are unlikely to cease distributing apps through the Play Store and rival app stores will be unable to secure those apps as exclusive content.
584 Sixth, by the app developer restrictive conduct comprised in the GVP and AVP agreements, Google has prevented or hindered potential competitors of the Play Store from establishing themselves and offering differentiated content from some of the world’s most popular app developers, including “beacons” of the mobile gaming industry.
585 Without this conduct there is a real chance that rival app stores would be established, including by Riot Games and Tencent, and would offer exclusive or differentiated content likely to attract large numbers of Android device users.
586 Seventh, reference was made at one stage in the material to Google preventing app developers who did not list their apps on the Play Store from accessing the App Campaigns program. The parties hardly addressed this and I do not propose to say anything further about this in these reasons; if the parties want more reasons from me, they can request it.
587 The effect is to prevent or impede potential competitors of the Play Store from differentiating themselves from the Play Store through exclusive content.
588 Epic says that there is at least a real chance that the OEM and app developer restrictive conduct have the effect of substantially lessening competition in the market for the supply of Android app distribution services.
589 Epic says that absent that conduct, a number of entities, including Epic, are likely to establish rival Android app stores and compete with the Play Store. Further, existing Android app stores would be able to compete on a more equal footing. If that occurred, there would be increased competition for the supply of Android app distribution services. That competition is likely to manifest through alternative app stores offering different terms and conditions, including lower prices.
Cross-effect of conduct in the mobile OS licensing and Android mobile app distribution markets
590 Further, Epic says that there is an important nexus between Google’s OEM restrictive conduct and its app developer restrictive conduct, and competition in the Android in-app payment solutions market. It has made the following points.
591 In short, quite apart from the in-app payment solutions restrictive conduct, Google’s conduct with respect to OEMs and app developers ensures that app developers who wish to reach most Android device users have no real choice but to distribute their apps through the Play Store and accept the DDA terms.
592 That conduct facilitates and supports the anti-competitive conduct in which Google engages in the Android in-app payment solutions market, because it ensures that developers are, in practical terms, required to accept the payments tie and the anti-steering rule.
593 Indeed, both the payments tie and the anti-steering rule form part of the DDA terms, and as such, are an integral part of Google’s conduct vis-à-vis app developers.
594 So, Epic says that the effect and likely effect of the conduct referred to is not limited to the Android mobile app distribution market. It also substantially lessens competition in the Android in-app payment solutions market.
In-app payment solutions restrictive conduct
595 The payment solutions restrictive conduct alleged by Epic includes the following aspects.
596 The first alleged aspect is Google’s conduct in requiring app developers that wish to distribute apps through the Play Store to enter into a DDA, and comply with associated developer program policies, containing the terms referred to below.
597 Those terms require app developers offering Play Store app in-app purchases to use Google Play Billing for those transactions save in limited circumstances. They require app developers to pay a fee of 30% on Play Store app in-app purchases subject to limited exceptions. And they preclude apps distributed via the Play Store from leading users to a payment method other than Google Play Billing subject to limited exceptions.
598 So, Google required app developers who wished to offer Play Store app in-app purchases to agree to the terms of the DDA and developer program policies relating to Google Play Billing.
599 The second alleged aspect is Google’s conduct in entering into the AVP Agreements with certain app developers, and requiring those app developers to use Google Play Billing as the sole payment solution in all markets in which the relevant apps are available on the Play Store.
600 The third alleged aspect is Google’s conduct in giving effect to and/or enforcing the terms referred to above relating to Google Play Billing, including against Epic, by removing Fortnite from the Play Store, refusing to allow Epic to offer EDP for any Play Store app in-app purchases and failing to agree to Epic’s request for in-principle approval to make the Epic Games Store available on the Play Store.
601 Let me say something about the payments tie conduct.
602 As alleged by Epic, the payments tie conduct describes the conduct of Google, by the terms of the DDA and developer program policies relating to Google Play Billing, in making its supply, or offers to supply, app developers of services for the distribution of Android apps to Android smart mobile device users via the Play Store conditional upon app developers not acquiring payment solutions for accepting and processing payments for Play Store app in-app purchases from any person other than Google.
603 The second developer program policy which is relevant and made binding on developers by clause 4.1 of the DDA is the payments policy.
604 Between at least 31 July 2012 and 20 January 2021, the payments policy required app developers distributing apps through the Play Store to use Google Play Billing for in-app purchases, except where the payment was primarily for physical goods or services or for digital content or goods that might be consumed outside of the app itself.
605 In August 2013, the payments policy was amended to require all gaming apps selling digital in-game currencies or other digital goods to use Google Play Billing, even if the in-game currency or digital good could be used outside of the app. As a result, the second exemption referred to above no longer applied to gaming apps.
606 On 20 January 2021, what remained of the exemption for non-gaming digital content or goods that could be consumed outside of the app was removed entirely.
607 Google described this as a “clarification”, rather than what it actually was, being a unilateral amendment to a longstanding policy with contractual effect.
608 Existing apps that used an alternative payment solution were given until 30 September 2021 to comply with the amended payments policy. Google subsequently announced that, from 1 June 2022, any app developer that was non-compliant with the amended payments policy would be removed from the Play Store.
609 So, since January 2021, clause 2 of the payments policy has provided that “Play distributed apps requiring or accepting payment for access to in-app features or services, including any app functionality, digital content or goods … must use Google Play’s billing system for those transactions …”. This obligation is subject to certain exceptions, currently set out in clauses 3 and 8 of the payments policy.
610 Section 3 stipulates that Google Play Billing must not be used where the payment is of one of the following types. First, it is primarily for the purchase or rental of physical goods, for the purchase of physical services, or is a remittance in respect of a credit card bill or utility bill. Second, it concerns peer-to-peer payments, online auctions, and tax exempt donations. Third, it is for content or services that facilitate online gambling. Fourth, it is in respect of any product category deemed unacceptable under Google’s payments centre content policies.
611 Section 8 was added to the payments policy in response to legislative or regulatory changes in South Korea and India. It permits developers that require or accept payment from users in India and South Korea to offer users an alternative billing system alongside the Play Store’s billing system if they agree to certain prescribed requirements.
612 So, subject to limited exceptions, throughout the relevant period the payments policy has required app developers to exclusively use Google Play Billing for in-app purchases of digital content within apps distributed via the Play Store. The parties before me referred to this as the payments tie.
613 Now many developers besides Epic expressed dissatisfaction with the payments tie throughout the relevant period, particularly following the “clarification” of the payments policy in January 2021.
614 From at least 2016 until April 2022, YouTube, which is a subsidiary of Google, used a Google-owned payments solution that was not Google Play Billing for in-app purchases of digital products on Android devices. YouTube resisted replacing its own payment solution with Google Play Billing.
615 YouTube was concerned about the features and functionality of Google Play Billing, that the integration of Google Play Billing would involve significant migration costs, including time and engineering effort, and that switching to Google Play Billing would result in the loss of YouTube’s autonomy and ability to innovate and compete with their main competitors, Spotify and Netflix.
616 Ultimately, following the September 2020 update to the payments policy, and an extended period of negotiation between YouTube and Google, YouTube reluctantly complied with the payments tie in April 2022.
617 Other developers have also expressed dissatisfaction with the payments tie during the relevant period such as Spotify, Netflix, Match, Calm, Bumble and Parship Group. It would seem that these developers considered Google Play Billing to be inferior to other payment solutions. Google nonetheless enforced the payments policy over the developers’ objections.
618 I have also mentioned above the anti-steering rule which is relevant in this regard.
619 Let me turn to three other related topics.
User choice billing in South Korea and India
620 Since 18 December 2021 in South Korea, and since 26 April 2023 in India, Google has permitted app developers to offer users an alternative in-app payment solution in addition to Google Play Billing under Google’s user choice billing (UCB) program.
621 If an app developer wishes to offer UCB, it must comply with several requirements imposed by Google.
622 First, it must follow Google’s interim user experience requirements, including displaying an information screen and a separate billing screen which presents Google Play Billing and the alternative payment solution to the user in an equal manner.
623 Second, it must manually report to Google the amount of all paid transactions from users in South Korea / India each month.
624 Google has stated that when a user selects an alternative payment solution under UCB, Google charges a service fee that is 4 percentage points below the fee it would charge the developer for that transaction had the user selected Google Play Billing.
625 In other words, where UCB is deployed and the user selects an alternative payment solution, the service fee is said to be typically 26% or 11%, rather than 30% or 15%.
626 So, unless a developer can find an alternative payment solution that charges a service fee of less 4%, the developer is financially worse off under UCB.
Developer only billing in the EEA
627 Since 19 July 2022, in the EEA only, Google has allowed non-gaming app developers only to use an alternative in-app payment solution without also having to integrate Google Play Billing alongside it. This program is the developer only billing (DOB) program. It was introduced by reason of the passage of the Digital Markets Act.
628 Under DOB, if a non-gaming app developer wishes to integrate an alternative in-app payment solution, it must comply with requirements imposed by Google, including following Google’s user experience guidelines, and accounting for and reporting to Google the amount of all paid transactions from the alternative payment solution for invoicing.
629 Google has stated that, under DOB, when an in-app purchase of digital content is made using an alternative payment solution, it charges a service fee that is 3 percentage points lower than the fee that Google would charge had the user selected Google Play Billing.
630 So, unless a developer can source a payment solution that charges a service fee of less than 3%, the developer will be worse off financially under DOB.
631 Google’s own assessment is that payment processing costs vary between about 3.5 and 6%.
User choice billing pilot in other countries
632 Since 1 September 2022, Google has also allowed eligible non-gaming app developers only to join its UCB pilot program in certain geographies outside India and South Korea, including Australia, India, EEA countries, Indonesia and Japan.
633 On 10 November 2022, the program was extended to the United States, Brazil and South Africa.
634 If a non-gaming app developer wishes to use an alternative in-app payment solution alongside Google Play Billing pursuant to the UCB pilot program, it must comply with the same requirements imposed by Google in South Korea and India outlined above.
635 Google has stated that, pursuant to this arrangement, when a user selects an alternative payment solution, it charges a service fee that is below what it would otherwise charge for that transaction had the user selected Google Play Billing by 4 percentage points.
636 So, unless a developer can source a payment solution that charges less than 4%, the developer will be worse off financially under UCB. Again, Google’s assessment is that the payment processing costs vary between about 3.5 and 6%.
637 App developers entitled to access the UCB program remain subject to the payments tie, albeit in a varied form. They must still integrate Google Play Billing as a payment solution for in-app purchases of digital content. They have the option of offering an alternative payment solution in addition to Google Play Billing but are not permitted to only offer that alternative payment solution.
638 Further, Google precludes price competition under UCB. Everywhere other than South Korea, app developers using UCB must offer users the same price, irrespective of the payment solution selected by the user. App developers therefore cannot incentivise users financially to choose a third-party payment solution in lieu of Google Play Billing.
639 There are also limitations on the alternative payment solutions that app developers can offer under UCB and DOB.
640 The terms of the UCB pilot prevent app developers from using a payment solution provider that operates as a “merchant of record”.
641 Now the evidence establishes that acting as a merchant of record is a way to take administrative and operational burdens such as handling taxes, currencies and financial compliance away from the app developer, whereby the payment solution provider operates as a reseller of the app developer’s software for each action. So, payment solution providers that act as a merchant of record, such as Paddle, cannot offer payment solutions under UCB.
642 Again, the choice being presented to developers by Google is not commercially real. App developers remain constrained by the payments tie, even when they have access to UCB.
The Android in-app payment solutions market — section 46
643 Epic’s case is that there is an Android in-app payment solutions market, which is a market for the supply of services to app developers for the facilitation of payments for the purchase of digital content within Android apps.
644 Alternatively, it is a narrower market, for the supply of services to app developers for the facilitation of payments for the purchase of digital content within Play Store apps only.
645 But nothing turns on the distinction between the two alternative markets relied on by Epic. The Android in-app payment solutions market is only marginally wider than the alternative market, and this difference does not alter the analysis of market power or the likely competitive effects of Google’s conduct.
646 The points below refer only to the Android in-app payment solutions market, although they should also be taken to also include the narrower alternative market.
647 Epic has made the following points.
648 Through clause 4.1 of the DDA and the payments policy, Google imposes the payments tie, namely, it requires app developers that sell digital content in apps downloaded from the Play Store to use Google Play Billing as their payment solution for all in-app purchases of digital content within those apps.
649 But Google’s payments tie does not dictate that a service for facilitating in-app payments is not a separate product from app distribution services. From an economic perspective, two products are distinct if it is technically feasible for them to be supplied separately, and in the absence of tying, there would be distinct demands for each of them, as customers are prepared to acquire each product without the other attached.
650 Google Play Billing can be, and is, provided separately from Android app distribution services. The following may be noted.
651 Google Play Billing is not available in 15 countries where the Play Store operates. In those countries, app developers can and do distribute apps through the Play Store but use a payment solution other than Google Play Billing.
652 Until about 2021, when Google amended its payments policy to prevent it, at least 90 different developers distributed apps through the Play Store using a payment solution other than Google Play Billing for in-app purchases of digital content.
653 Under the UCB and DOB programs, developers are permitted to use a payment solution for in-app purchases other than Google Play Billing, and various developers have sought to do so.
654 Between November 2021 and October 2022, approximately 103 app developers in South Korea sought to integrate an alternative payment solution into their apps.
655 Between September 2022 and October 2022, approximately 19 developers of non-gaming apps sought to integrate an alternative payment solution into their apps, pursuant to the UCB pilot program.
656 And between 19 July 2022 and October 2022, 29 app developers applied to Google to use a payment solution other than Google Play Billing, pursuant to the DOB program.
657 Various other developers of Android apps have sought to use, or expressed interest in using, a payment solution for in-app purchases of digital content other than Google Play Billing, including Epic, Parship Group and customers of Paddle.
658 App developers who sell non-digital content within Play Store apps do not use Google Play Billing. Instead, they acquire payment solutions from third parties separately from the distribution services supplied by Google.
659 For these reasons, Epic says that it is appropriate to treat services for the facilitation of in-app payments as a distinct product.
660 The next question that arises is whether there are close substitutes to Google Play Billing for the supply of services to app developers for facilitating in-app payments for digital content within Android apps.
661 Out-of-app payment solutions connote at least two requirements, namely, a requirement for the developer to build or acquire a solution that facilitates out-of-app payments, and a further requirement for the user to leave the app to effect a purchase elsewhere, for example, on a website using an out-of-app solution which the developer has built or acquired.
662 Epic says that out-of-app payment solutions are not a viable substitute for Google Play Billing.
663 First, as I have said above, Google’s anti-steering rule prohibits apps from “leading users to other payment methods”. The result is that developers cannot create links to out-of-app payment solutions within their Play Store apps or even tell their users about the out-of-app solution via in-app promotions or user-interface flows. Rather, out-of-app payment solutions can only be implemented separately from the app. Very few developers have taken this option.
664 Second, developers would not substitute in-app payment solutions with out-of-app solutions because the latter are a worse experience for users, who are more likely to complete the transaction within the app than if they must exit the app. Leaving the app can be disruptive to users, takes more time, and is often frustrating. App developers will prefer the payment solution that leads to more, not fewer, completed purchases.
665 Further, Epic’s case is that the geographic dimension of the Android in-app payment solutions market includes at least Australia and is likely global, excluding China and possibly other territories where competitive conditions began to differ towards the end of the relevant period.
Google’s power in the Android in-app payment solutions market
666 Epic says that Google has a substantial degree of power in the Android in-app payment solutions market. It has made the following points.
667 If the market is confined to payment solutions for in-app purchases within Play Store apps, then Google is a virtual monopolist.
668 The in-app payment solutions restrictive conduct means that Google Play Billing is the only payment solution permitted for facilitating payments for in-app purchases of digital content within Play Store apps, save for apps distributed in the 15 countries where Google Play Billing is not offered, and apps that take advantage of the UCB or DOB programs. The take up of those programs has been relatively low.
669 The in-app payment solutions restrictive conduct also prevents new entry by competing payment solution providers. The barriers to entry with the conduct are insurmountable outside of the limited exceptions and app developers have no effective countervailing power.
670 Even within the exceptions, the scope for competitive constraint is very limited.
671 Under the UCB program, developers must still offer Google Play Billing alongside an alternative, and, save in South Korea, developers are not allowed to quote a lower price for using the alternative solution.
672 Further, the DOB and the UCB pilot programs are only available to “non-gaming” app developers, and the UCB pilot program precludes app developers from using a payment solution provider that operates as a “merchant of record”.
673 Alternative providers are thereby precluded from competing with Google Play Billing on equal terms, given that Google does act as merchant of record.
674 If the market also includes payment solutions for in-app purchases of digital content within Android apps more generally, the conclusion is the same.
675 The Play Store accounts for 98% of new app downloads from Android app stores in Australia and 91% of such downloads globally, and Google Play Billing is the payment solution for almost all in-app purchases of digital content that occur in those apps.
The purpose of Google’s conduct in the Australian Android in-app payment solutions market
676 Epic says that a substantial purpose of the in-app payment solutions restrictive conduct has been to substantially lessen competition in that market.
677 It is said that Google’s anti-competitive purpose ought to be inferred from the in-app payment solutions restrictive conduct itself.
678 Epic says that, notably, even when Google has been forced to allow developers to offer alternatives to Google Play Billing, it has done so in ways that force developers to continue offering Google Play Billing whether they want to or not, that disincentivise the use of any alternative solution, or that prohibit developers charging their customers a lower price for the alternative.
679 Epic says that none of this is aimed at protecting user security or privacy. It is aimed at hindering competition and maximising Google’s profits.
680 Further, it says that Google’s internal business records demonstrate that a substantial purpose of the in-app payment solutions restrictive conduct was to prevent or hinder competition.
The effect of Google’s conduct in the Android in-app payment solutions market
681 As to the state of competition in this market with Google’s conduct, Epic says that there is next to no competition at all. Epic makes the following points.
682 Epic says that in the counterfactual, without the in-app payment solutions restrictive conduct, Google Play Billing would be likely to face significant competition.
683 There would be demand from app developers for Android payment solutions other than Google Play Billing, just as there was in the past and is currently.
684 There would also be suppliers with the incentive and ability to meet that demand. Several providers already supply payment solutions for in-app purchases of physical goods within Android apps. It would not be difficult for these providers to supply an in-app payment solution for purchases of digital content within Play Store apps. As a result, one would expect entry by those suppliers into the market if Google’s in-app payment solutions restrictive conduct ceased.
685 At least one payment solution provider, namely, Paddle, has already expressed a desire to enter the market and compete with Google Play Billing.
686 For these reasons, Epic says that the in-app payment solutions restrictive conduct has the effect, or likely effect, of substantially lessening competition in the Android in-app payment solutions market.
687 Now that I have set out the claims that Epic has made, let me say something about the witnesses.
Google’s lay evidence
688 I have addressed Epic’s lay witnesses in my reasons in the Apple proceeding. Essentially, Epic called the same lay witnesses in both the Apple and Google proceedings. I adopt that commentary here.
689 It is convenient at this point to say something about Google’s lay witnesses.
690 Mr Lee Rawles, the managing director of Global Games, Play Partnerships at Google, gave written evidence in chief. He was cross-examined by Mr Young KC for Epic.
691 Generally speaking he gave reliable evidence, although at times he was a little evasive and occasionally was prone to overly elaborate responses. As to his evidence which was relevant to the question of market definition and competition, I have addressed that subject matter elsewhere.
692 I should also note that Mr Rawles reported to another witness in the case, Ms Purnima Kochikar.
693 Ms Kochikar, the vice president of Play Partnerships at Google, gave written evidence in chief. She was cross-examined by Mr Rich SC for Epic and Mr De Young KC for the class applicants.
694 Clearly, Ms Kochikar is commercially highly skilled particularly in her role in dealing with many facets of Google’s dealings with developers including their demands, needs and preferences, and also questions dealing with billing and Google’s monetisation of its dealings with developers.
695 Ms Kochikar generally speaking gave reliable evidence, but I would note three cautionary aspects.
696 First, I thought that she over pushed and overly injected the corporate theme of Google vigorously competing with iOS/Apple, and on occasion in a non-responsive way to Mr Rich SC’s precise and pithy questions. The competition for app developers and users was more directly within the Android ecosystem between the Play Store and non-Play Store platforms or other mechanisms, although of course the broader context included competition with iOS/Apple. Further, I accept that the broader competition concerning Android mobile devices and iOS mobile devices is not irrelevant to the case. But such competition has little to do with market definition in my view. But it is relevant to any broader context considering competitive constraints.
697 Second, her evidence concerning Project Hug had some problematic aspects to it, which I have specifically addressed elsewhere.
698 Third, like some other witnesses, Ms Kochikar also sought to push the line of a “clarification” to policy in an Orwellian fashion.
699 Mr Richard Byers, a principal software developer at Google, gave written evidence in chief. He was cross-examined by Mr Young KC for Epic. Generally he gave reliable evidence, although in my view he overstated the virtues of web apps. I have dealt with this topic in more detail elsewhere.
700 Mr Paul Gennai, a product management vice president at Google, gave written evidence in chief. He was cross-examined by Mr Garry Rich SC for Epic and Mr Bannon SC for the class applicants.
701 I found his evidence at times to be evasive. Moreover on occasion he made what I consider to be problematic distinctions in some of his answers. Moreover, some of his evidence concerning Project Hug and the RSA3s was not reliable. I have discussed specific matters concerning his evidence elsewhere.
702 Mr Paul Feng, the vice president of product management at Google, gave written evidence in chief. He was cross-examined by Mr Young KC for Epic and Mr Bannon SC for the class applicants. His principal topics of evidence concerned questions of monetisation, service fees, the Play Store’s billing system and the like.
703 Generally he gave reliable evidence on most topics. But there were aspects which were problematic such as his attempt to explain a policy change which eliminated an exception as a mere “clarification”. Several of Google’s witnesses persisted with such an Orwellian expression, which did them no credit. Further, at times his evidence was evasive or incomplete, such as what he said and sought to justify at [152] of his first affidavit. I have dealt with specific topics of his evidence in more detail elsewhere.
704 Finally, there were two other lay witnesses called by Google on security and technology questions, namely, Mr Porst and Mr Cunningham. I will say something more about them later.
Jones v Dunkel inferences
705 Now a key question in this case is Google’s subjective purpose in imposing and enforcing relevant terms in the AFAs, ACCs, MADAs, RSAs, DDAs and payments policy and undertaking Project Banyan and Project Hug.
706 Epic says that Google’s contemporaneous business records support an inference that a substantial purpose of Google’s conduct was to substantially lessen competition in the pleaded markets.
707 But Google has both denied that it held such an anti-competitive purpose, and positively asserted that its subjective purposes were either procompetitive or otherwise justified.
708 But Google has neither called the senior executives who bear executive responsibility for the impugned conduct and contractual terms nor explained why those senior executives were not called to give evidence.
709 Now the rule in Jones v Dunkel (1959) 101 CLR 298 is that an unexplained failure by a party to call a witness may in appropriate circumstances support an inference that the uncalled evidence would not have assisted the party’s case. The failure to call a witness may also permit a court to draw, with greater confidence, any inference unfavourable to the party that failed to call the witness, if that uncalled witness appears to be in a position to cast light on whether the inference should be drawn.
710 The inference permitted to be drawn is not that evidence not called by a party would have been adverse to the party, but that it would not have assisted the party. In other words, the rule does not enable me to infer that the evidence of the absent witness would have been positively adverse to that party.
711 It follows that the rule does not preclude me from drawing inferences in favour of a party that has not called a witness if such a favourable inference is otherwise open on the documents.
712 The rule in Jones v Dunkel operates in circumstances in which a party is required to explain or contradict something. A Jones v Dunkel inference will not always be drawn and whether it is drawn depends on weighing all of the evidence. The basis on which an inference may be appropriate depends on all of the circumstances of the specific case.
713 Now there are limitations to drawing an inference under the principle in Jones v Dunkel. The inference cannot be used to rectify any deficiencies or gaps in the evidence of the party seeking to rely on the adverse inference. Similarly, conjecture or speculation cannot be converted into an inference. The inference must be available from direct and proven evidence. In this regard, disputed questions of fact must be decided according to the evidence that the parties adduce, not according to some speculation about what other evidence might possibly have been led.
714 Epic has made the following points.
715 Mr Sundar Pichai was the CEO of Alphabet Inc, which was Google’s parent company, during the relevant period. Mr Pichai previously held positions as chief business officer at Google, and “Head of Android”.
716 As Google’s most senior executive during the relevant period, Mr Pichai was a person who could speak with authority to Google’s subjective purpose. Mr Pichai was directly involved in driving decisions regarding the Play Store placement requirements under the MADA. Mr Pichai was also involved in the amendment to clause 4.5 of the DDA. Further, as the CEO, Mr Pichai had ultimate executive responsibility for Google’s proposed “special deal” with Epic, Project Banyan, Project Hug and Google’s longstanding approach to imposing and enforcing the impugned contractual provisions and policies.
717 Mr Pichai was not called to give evidence in this proceeding and Google provided no explanation for the failure to call him. He is still employed in the role of CEO.
718 Sitting directly under, and reporting to Mr Pichai during the relevant period, was Mr Lockheimer. Mr Lockheimer was the most senior executive, other than Mr Pichai, with responsibility for the Play Store.
719 Mr Gennai, whose own boss Mr Rosenberg reported to Mr Lockheimer, gave evidence that either Mr Lockheimer or Mr Rosenberg would have been responsible for approving the changes to clause 4.5 of the DDA.
720 It is also apparent from the documentary record that Mr Lockheimer was extensively involved in the issues and decisions the subject of this proceeding, including Google’s strategy for Android since 2010.
721 Mr Gennai, by contrast, described his role in the 2010 process as being a scribe. Mr Lockheimer was involved in decision-making for Project Banyan, and Project Hug.
722 Further, Mr Lockheimer, along with Mr Rosenberg and others, was listed as a deal representative for the Google business council approval of the framework that included the RSA3s; I have discussed this later. Mr Gennai was not a representative, nor was he present at the relevant meeting.
723 Mr Gennai’s suggestion that he was travelling only serves to emphasise the oddity of calling him rather than Mr Lockheimer or Mr Rosenberg to shed actual light on the decision. Indeed, the travelling suggestion was offered by Mr Gennai on various occasions to explain his failure to have attended important meetings.
724 Mr Lockheimer was not called to give evidence in this proceeding and Google did not explain its failure to call Mr Lockheimer, a very senior executive whom Google still employs.
725 During the relevant period, Mr Rosenberg and Mr Samat sat below Mr Lockheimer and held various senior responsibilities relating to the Play Store and Android. The evidence demonstrates that they were key decision-makers concerning the attempted deal with Epic in 2018, Project Hug, Project Banyan and the RSA3s.
726 Both Mr Rosenberg and Mr Samat remain employed by Google. Neither was called to give evidence. Despite the documentary record indicating their close involvement in the relevant conduct, Google provided no explanation for its failure to call these senior executives. Instead, it called Mr Gennai, who reported to Mr Rosenberg.
727 Not only did Google not call Mr Lockheimer, but it did not even call his direct reports, Mr Rosenberg and Mr Samat. Instead, it called executives another rung down the ladder: Mr Gennai, Ms Kochikar and Mr Feng. Mr Gennai reported to Mr Rosenberg from 2010 until about August 2020. Ms Kochikar had also previously reported to Mr Rosenberg and Mr Samat. Mr Feng had previously reported to Mr Samat.
728 That forensic choice might have made sense if Mr Gennai, Mr Feng, or Ms Kochikar had been decision-makers within Google. But the evidence indicates that they were not. Instead, Mr Gennai’s involvement in decisions was in the nature of him being an advisor rather than as part of the decision-making team, Ms Kochikar was downstream of the decisions, and Mr Feng was not responsible for any final sign-off on policies concerning the Play Store or Google Play Billing.
729 In these circumstances, Epic says that it is appropriate to infer that Google did not call Mr Pichai, Mr Lockheimer, Mr Rosenberg, or Mr Samat because it was afraid that their evidence would expose facts unfavourable to Google.
730 Epic says that I should infer that the evidence of each of those senior executives would not have assisted Google’s case and more readily draw inferences adverse to Google which are available on the evidence.
731 But in my view and largely for the reasons that Google has advanced, no Jones v Dunkel inference should be drawn against Google.
732 Google called evidence from very senior executives being Mr Gennai, Ms Kochikar and Mr Feng. Those witnesses were intimately involved in Google’s decision-making in connection with the conduct at issue, and in a position to give evidence of Google’s purposes in connection with that conduct.
733 Mr Gennai is a product management vice president at Google LLC. Between 2010 and 2020, he was involved in the launch of the Play Store, managed the Play Store’s weekly product council, managed the strategy and analytics function for Android and managed and grew the Play Store analytics team, which is responsible for collecting, processing and analysing data for the Play Store business.
734 Mr Gennai was closely involved in developing Google’s strategy for the Play Store and Android since the Play Store’s launch in March 2012 until he changed roles in August 2020. He was in a position to speak to that strategy and to why Google made and implemented the decisions it made during the period of critical relevance to Epic’s claim.
735 Ms Kochikar is the vice president of Play Partnerships at Google and has been in that role since November 2020. Ms Kochikar was closely involved in the development of Project Hug and the GVP. She was involved in the internal process of proposing and progressing Project Hug for approval by the Play Store’s business council, and attended the business council meetings where that project was discussed. Ms Kochikar was in a position to give evidence as to Google’s subjective purpose in connection with Project Hug and the GVP.
736 Mr Feng is the vice president of product management at Google LLC. Between 2016 and 2022, he led the Play Store’s monetisation initiatives. He led the team that was responsible for the management and functions of the Google Play billing system, including the Play Store’s payments policies. As the leader of the team, he was responsible for product strategy, and for defining and implementing products to assist developers to build and monetise their digital content businesses on Android and the Play Store. Mr Feng was involved in Google’s consideration of its monetisation strategy and payments policy. He was in a position to give evidence as to Google’s rationale for that policy and its subjective purpose.
737 Each of Mr Gennai, Ms Kochikar and Mr Feng appears on numerous internal Google documents that are at the core of Epic’s case against Google. That demonstrates their central involvement in, and knowledge of, Google’s decision-making in connection with the conduct that Epic impugns. They were appropriate witnesses to address those matters.
738 Now Google is a large organisation and it is customary for senior executives to attend meetings and be copied on documents and emails. And Google is not required to call each and every witness who can speak to a matter.
739 Further, I agree with Google that Epic has made no attempt to identify, with the requisite precision, what inference ought to be drawn in each case. Even if I was inclined to draw any generalised adverse inference, that would not take any particular forensic issue far in any event.
Chat deletions
740 Epic says that an aspect of the evidentiary landscape which should affect my assessment of Google’s purpose is Google’s destruction of its internal Google Chat records. Google Chat is an instant messaging service which is used regularly by Google employees to communicate with other Google employees, including about business matters. Records of those chats, if they still existed, would constitute a repository of contemporaneous business communications.
741 Epic says that those records to a significant extent were deliberately destroyed and consequently have not been discovered in this proceeding. Moreover, it is said that that occurred in circumstances where there is evidence that Google employees, knowing that Google’s Chats would be destroyed, channelled sensitive business communications into Google Chat.
742 Now in September 2008, Google issued an internal company-wide announcement of a new company policy in the light of Google continuing to be in the midst of several significant legal and regulatory matters and its recognition that Google was going to keep facing these kinds of challenges. The policy announcement was sent by Mr Bill Coughran then the senior vice president of engineering, and Mr Kent Walker a senior lawyer within Google and apparently now the chief legal officer and president of global affairs for Alphabet.
743 The new policy, which was said to help avoid the “inadvertent retention” of instant messages, was a decision to make “off the record” the Google corporate default setting for “Google Talk”. In this context, “off the record”, which is also known as “history off”, was a setting whereby chats were permanently deleted within 24 hours.
744 So, Google instituted a default setting that resulted in the systematic destruction of Google Chat records every 24 hours, for the purpose of ensuring that none of those records would have to be produced to third-parties in the several significant legal and regulatory matters that were ongoing at the time, or in the context of future legal and regulatory challenges that Google was going to keep facing. Google maintained this policy from September 2008 until February 2023, when the default setting was changed.
745 Both Ms Kochikar and Mr Gennai confirmed that during that period they used Google Chat regularly to communicate with other Google employees, including concerning Google business matters.
746 Now Google’s policy was not influenced by any technical constraints regarding its document retention capabilities. Google possessed the technical ability to preserve its Google Chat records by setting the chat history to “on”.
747 Google’s efforts to avoid the so-called “inadvertent retention” of documents also extended to the training it provided to its employees.
748 In a training program titled You Said What?! 10 Things To Ensure You Are Communicating With Care, employees were advised that “[a]t Google, [w]e are constantly in the public eye … and the courthouse. We often have to produce employee communications as evidence … Our communications can hurt or embarrass us as a company …”. With respect to the advisability of communicating by “Chat ‘off the record’ via Hangouts” instead of by email, employees were instructed that this option is “[b]etter than sending the email, but not without risk” because “[w]hile “off the record” Hangout chats … are not retained by Google as emails are, any chat participant may save the conversation by simply copying and pasting it into a doc or email …”.
749 Google’s policy also set out instructions to those employees subject to a “litigation hold”, directing them that if “you must chat regarding matters covered by that hold, please make sure that those chats are ‘on the record’”.
750 Relevantly, both Mr Gennai and Ms Kochikar were subject to legal hold notices since around September 2020 in relation to the lawsuit brought by Epic against Google in the United States. But despite being subject to litigation holds, until the policy change in February 2023, the default setting for their Google Chats remained history-off. Google left it to the discretion of employees to determine whether their communications were “covered by” the hold.
751 Now Epic says that determining whether a communication such as a Google Chat record is relevant to the issues in dispute in legal proceedings and necessary to retain is a question which cannot reasonably be delegated to the lay participants in those communications, particularly in a case which involves the many and complex issues which arise in this proceeding.
752 Epic says that Google’s conduct gives rise to the real likelihood that a significant quantity of otherwise relevant material was not discovered. And it says that as to such chats being relevant, that likelihood is increased given that Ms Kochikar directed her co-workers to communicate with her via Google Chat, rather than by email, in respect of sensitive business matters.
753 So, Epic says that in an email chain concerning Google’s assessment of a policy violation by Epic, Ms Kochikar advised the participants that “[t]his developer is not acting in good faith. Please be very careful about anything you say and do not put anything in writing. Please call or ping me if you have any questions”. By “ping”, Ms Kochikar meant communicate using Google Chat.
754 Further, it says that another instance occurred in an email chain regarding a meeting with Mr Don Harrison of Google about a proposed amendment to Google’s payment policy, in respect of which Google was attempting to obtain Spotify’s agreement. Ms Kochikar responded that she:
… caught up with Don briefly after the Spotify call - his concerns are less about the commercial terms and more about implications of the product path we are picking. Let me ping you in a bit ... It’s best to discuss this live.
755 In another email dealing with Google’s response to the Fortnite hotfix and removal situation, Ms Kochikar directed her staff not to discuss the topic using a form of Google Chat whose records are retained.
756 In the present case, Epic says that I should take an approach analogous to the rule in Jones v Dunkel. So, if the evidence as a whole is consistent with a particular adverse inference relating to Google’s conduct or purpose, Epic says that that inference may be drawn more readily by reason of the absence of contemporaneous Google Chat records that might have shed light on the true position.
757 Epic says that here, the evidence establishes that the conduct which resulted in the destruction of Google Chat records was not accidental but a deliberate company policy that was conceived and implemented with a view to preventing the retention of records that might have to be produced in legal and regulatory proceedings.
758 It is said that the effect of Google’s conduct in destroying its Chat records is that I do not have the benefit of knowing what was contained in those Chat records and the way in which they may have borne upon the issues in dispute.
759 But in my view no adverse inference should be drawn against Google concerning the Chats.
760 Chats are not core business documents. They are ephemeral communications and the digital equivalent of idle chatter or vacuous prattle around a water cooler.
761 Epic has not demonstrated that Chats were commonly used by Google’s executives to discuss any of the matters at issue in these proceedings. Nor is there a basis to infer that any significant documents have been lost by reason of the fact that Chats were not historically retained.
762 Further, Epic has been able to identify documents which it asserts record or constitute Google’s decision-making and actions in connection with the conduct at issue. Further, this is not a case where I have any basis to infer that Epic has been deprived of the opportunity to cross-examine witnesses by reference to contemporaneous emails. And of course, Chats are nothing like emails.
763 On the evidence that I have seen, Google makes decisions collaboratively, over time and in an elaborate documented fashion.
764 Indeed, when one has regard to the over 3 million documents that Google has discovered in this proceeding, the idea that any meaningful business communication occurred in Chats, without reflection in some email, presentation or other document, is quite unlikely, as Google points out.
765 For these reasons, I will not draw the inference that Epic seeks.
766 Let me now turn to the question of market definition and begin by saying something about the parties’ cases.
Market definition concerning Android mobile app distribution – the parties’ cases
767 Let me begin by setting out again Epic’s posited markets.
768 Epic says that there is a mobile OS licensing market, which is a market for the supply of licenses for mobile operating systems, where the geographic dimension of the market is a global market excluding China, of which Australia forms part. I will put that to one side for the moment.
769 Further, Epic says that there is an Android mobile app distribution market, which is a market for the supply of services for the distribution of Android apps to Android smart mobile device users, with the following elements or dimensions.
770 First, the services consist of the provision of services to app developers enabling or facilitating app developers to reach, offer and provide Android smart mobile devices users with Android apps and associated updates and/or the provision of services to Android smart mobile devices users enabling or facilitating Android smart mobile devices users to be presented with or to find, obtain and utilise Android apps and associated updates.
771 Second, the geographic dimension of the market is Australia or a global market excluding China, of which Australia forms part.
772 In this section of my reasons I will concentrate on this market.
773 Further, Epic says that in the alternative to an Android mobile app distribution market, there is a mobile app distribution market, which is a market for the supply of services for the distribution of Android apps and native apps written for iOS to smart mobile device users, with the following elements or dimensions.
774 First, the services consist of the provision of services to app developers enabling or facilitating app developers to reach, offer and provide smart mobile device users with native apps and associated updates and/or the provision of services to smart mobile device users enabling or facilitating smart mobile device users to be presented with or to find, obtain and utilise native apps and associated updates.
775 Second, the geographic dimension of the market is Australia or a global market excluding China, of which Australia forms part.
776 Further, Epic says that there is an Android in-app payment solutions market, which is a market for the supply of services to app developers for accepting and processing payments for the purchase of digital content, including by way of subscriptions, within an Android app, with the following elements or dimensions. I will put that to one side for the moment.
777 In this part of my reasons I will just address the posited Android mobile app distribution market and the alternative market as outlined.
Android mobile app distribution market
778 Before proceeding further I should say a little more about Epic’s articulation of this market.
779 In summary, Epic says that the Android mobile app distribution market is a market for the supply of services for the distribution of Android apps to Android device users.
780 It is said that those services are supplied to app developers and enable them to reach, offer, and provide their Android apps to users, as well as to update those apps. In addition, those services are supplied to Android device users and enable them to find and obtain Android apps, as well as updates to those apps.
781 Now as Epic correctly contends, it is appropriate to start the market definition process by identifying the product which Google supplies and asking whether there are any close substitutes.
782 Google supplies services for the distribution of Android apps through the Play Store. The services which Google supplies to developers via the Play Store are described in the DDA.
783 In particular, clause 2.1 recognises that the developer is making use of the Play Store “to distribute Products”, that is, apps, and provides that “Google will … display and make [the developer’s] Products available for viewing, download, and purchase by users”.
784 Clause 3.1 further provides that developers appoint Google as their agent or “marketplace service provider” in order “to make [the developer’s] Products available in Google Play”.
785 Other pertinent aspects of the DDA include the express recognition in clause 3.2 that the developer’s products are “distributed via Google Play” and the statement in clause 3.3 that “Products are displayed to users” on the Play Store.
786 Further, in clause 3.4 there is reference to products being sold or made available to users “via Google Play”. Further, there is authorisation granted to Google under clause 5.1 to market products on the Play Store and to provide “hosting services … to allow for the storage of and user access to the Products”.
787 Further evidence that Google supplies app distribution services to developers and users via the Play Store can be found in the text of the developer program policies, which are incorporated into the DDA by clause 4.1. Those policies include statements such as “[t]hese Developer Program Policies, along with the [DDA], ensure that together we continue to deliver the world’s most innovative and trusted apps to over a billion people via Google Play” and “[p]eople from all over the world use Google Play to access apps and games every day”.
788 Further, Google describes the Play Store as an app distribution system and a distribution platform. And as Epic points out, Ms Kochikar accepted that the services that the Play Store provides directly to developers include facilitating discovery of apps by users and app distribution. Further, Mr Gennai explained that using the Play Store, users can search for or browse for apps developed by third-party developers and download and install such apps onto their devices. He also said that distribution on the Play Store is valuable to developers in that it provides them with the ability to reach billions of Android device users around the world via a single platform, through which they can distribute their apps.
789 Further, Epic’s case is that only other Android app stores are sufficiently close substitutes to warrant inclusion in the same market as the distribution services which Google supplies to developers and users through the Play Store.
790 Epic also makes the following ten points.
791 First, a small but significant change in the price or quality of those distribution services would not provoke sufficient switching by developers and/or users to other possible substitutes as to justify their inclusion in the same market.
792 Second, the possibility of developers entering into pre-installation arrangements with OEMs to distribute their Android apps is not a close substitute to distribution via an Android app store for various reasons.
793 Third, the distribution of Android apps by means of direct downloads from a website on an Android device is also not a close substitute to distribution through an Android app store.
794 Fourth, accessing web apps, which run through the device’s web browser rather than natively on the device itself, is not a close substitute to the distribution of Android apps through an app store.
795 Fifth, the absence of close substitutability between services for the distribution of apps through Android app stores and web apps is demonstrated by users’ clear preference for native apps over web apps.
796 Sixth, the methods of distributing apps on non-Android smart mobile devices are not substitutes for distribution through an Android app store.
797 Seventh, the vast majority of users do not own both an Android and a non-Android mobile device, and do not readily switch between Android and non-Android devices. The intent to use another OS is low, potentially driven by high switching costs and/or loyalty to their existing OS. Switching costs include both direct financial costs and loss of the features of a particular eco-system, such as Google Drive, headsets, smart watches, paid apps or app related data.
798 Eighth, services that enable the distribution of apps on PCs are not a close substitute for distribution through an Android app store, including because there are functional differences between smart mobile devices and PCs which mean that they tend to be used in different situations, rather than as substitutes for one another.
799 Ninth, most of the top 50 revenue-generating apps on the Play Store are not available in PC app stores, reinforcing the conclusion that users are unlikely to switch to PC app stores in response to changes in the price or quality of Android app stores.
800 Tenth, distribution of apps on consoles is not a substitute for the distribution through Android app stores. The smart mobile device user base is about 3.7 billion, more than twelve times larger than the console user base of about 300 million. Given that the large majority of smart mobile devices distributed outside China consists of Android devices, it is clear that most Android device users do not own a console, and could not switch to using apps distributed to consoles without incurring the additional cost of acquiring one. In addition, gaming consoles are functionally different from smart mobile devices and the most widely used such as Xbox and PlayStation are designed for use at a fixed location.
801 In summary, Epic says that the market in which Google supplies app distribution services through the Play Store is one for the supply of services for the distribution of Android apps to Android device users, and the participants in the market are the Play Store and other Android app stores. I have referred to this as the Android mobile app distribution market.
802 The geographic dimension of the Android mobile app distribution market is at least Australia-wide, and likely global excluding China. The market excludes China because the Play Store, being the primary supplier of services, is not available in China. The primary supplier of services in the market is Google. Further, there is no price or other differentiation across geographic areas indicative of a national or regional market.
The mobile app distribution market
803 Now contrary to the above, if services for the distribution of Android apps to Android devices are supplied in the same market as services for the distribution of non-Android apps on non-Android smart mobile devices, then Epic maintains an alternative case based on the existence of a mobile app distribution market.
804 That market is relevantly the same as the Android mobile app distribution market, except that it also incorporates services for the distribution of non-Android apps to non-Android devices, including iOS devices.
805 In other words, this market would include distribution services relating to both Android app stores including the Play Store and Apple’s App Store.
806 Epic says that including the App Store in the market effectively makes the mobile app distribution market a duopoly market.
807 In 2020, the Play Store was responsible for about 38% of new app downloads from all app stores in Australia and 67% globally. The Apple App Store was responsible for about 61% of new app downloads in Australia and 26% globally.
808 Consequently, Apple and Google are responsible for about 99% of downloads in Australia and 94% of downloads globally. The market thus remains a highly concentrated one.
809 Epic says that Google and Apple do not compete closely so as to impose a real competitive constraint on one another in the field of app distribution. Their market shares are relatively stable, and neither has a history of altering prices or other terms to undercut the other.
810 But even if the appropriate market for analysis was the mobile app distribution market, Epic says that Google would still have a substantial degree of market power. And Epic’s case concerning the purpose and effect of Google’s conduct would continue to be as I have set out elsewhere.
Google’s criticisms – markets
811 Now Google says that I cannot be satisfied that any of these markets is an appropriate market for assessing whether Google has substantial market power, or whether its alleged conduct has the proscribed purpose or effect.
812 Google has referred to various legal and economic principles of relevance to market definition. I have discussed the relevant principles in my reasons in the Apple proceeding and, of course, have applied such principles to the Google proceeding.
813 Google has asserted various general deficiencies in Epic’s case on market definition. It is convenient to identify some of these asserted deficiencies at this point.
814 Google’s first main criticism concerns the asserted failure by Epic to capture relevant incentives and rivalry affecting the Play Store.
815 Google says that Epic’s approach to market definition, and its expert economic evidence in support of that approach, focuses on the use that can be made of Android OS and app stores by ecosystem participants, that is, OEMs, carriers, app developers and device users, rather than the transactions that involve spending and the facilitation of those transactions.
816 Google says that a deficiency arises because Google’s services are unique in that, at several points, there is a decoupling of revenue-generating transactions from use of the service features.
817 It is said that the central problem with Epic’s approach is that it eschews consideration of the very revenue generating transactions that create the relevant incentives to compete and in respect of which the rivalry between market participants principally occurs.
818 This is notwithstanding that Ms Edwards-Warren conceded that monetisation is relevant to the market definition inquiry, that monetisation of the product is what matters to the supplier, that if rivals can divert monetisation of the product, this could constrain the supplier, and that the focus of the analysis is on what constrains the Play Store, which impacts Google’s profits.
819 So, by excluding the relevant transactions or facilitation of transactions that generate revenue for Google, Google says that the pleaded markets cannot provide the necessary lens for assessing the purpose and effect of the alleged conduct on the competitive process.
820 This is because competitive constraints derive from incentives, which in turn are driven by profits that ultimately must be sourced from monetary transactions.
821 Take Epic’s pleaded Australian Android mobile app distribution market, which comprises a focal product of app distribution services but not facilitation of sales of digital content, which it says is inconsistent with the contractual position.
822 Google says that by its very definition, this market excludes virtually all the transactions from which Android app stores earn revenue and over which they compete, because it focuses exclusively on distribution of apps and app updates rather than facilitation of transactions for app-based digital content.
823 This can be seen from the Play Store’s revenue composition, being REDACTED] from paid ads on the Play Store, which is not in any of Epic’s markets, and REDACTED] from service fees on transactions between developers and users for digital content.
824 In 2022, the service fee revenue was REDACTED] from in-app purchases and REDACTED] from subscriptions, which are both not in Epic’s market, while less than 1% came from paid app downloads, which are in Epic’s market. In other words, Epic’s market includes only 1% of the transactions which earn revenue for the Play Store.
825 Google says that the difficulty with a market for app distribution services that excludes facilitation of in-app transactions for digital content is that it cannot assist in assessing whether the relevant conduct is likely to have a meaningful impact on the way in which the Play Store and other Android app stores compete for developers and device users.
826 The relevant incentives to compete on the part of the Play Store and other app stores are driven by the choices which app developers and device users make with respect to paid transactions, because it is those choices which directly affect app store profits.
827 Google says that by excluding consideration of how the Play Store and other app stores monetise their services, the proposed market fails to capture the incentives of relevant firms to compete and the competitive constraints that they face. In short, it does not focus upon what emerges as the clearest picture of the relevant competitive process in the light of commercial reality.
828 Now Google says that Epic attempts to answer this problem by pointing to indirect network effects and the fact that usage could be a proxy for spend. The suggestion is that, because services for distributing apps and app updates, including free apps and apps which provide for transactions for physical goods, improve the attractiveness of the Play Store, this ultimately leads to paid transactions for digital content.
829 It is also suggested that there is a connection between usage and spend because it contributes to app revenue generation by developers and Google, whether via paid app downloads, in-app purchases or apps that display ads.
830 In that way, usage is said to be a proxy for spend, and therefore sufficient to analyse the relevant competitive incentives.
831 But Google says that it is neither necessary nor appropriate in this case to focus on usage as a proxy for spend. This is for several reasons as Google puts its case.
832 Spending data is the most informative data point concerning competitive incentives, so it would be erroneous to focus the market definition exercise on usage to the exclusion of the transactions which result in actual spend. This is particularly problematic in a case such as this where detailed spending data is available.
833 Further, the HMT focuses on how a hypothetical monopolist’s profits would change in response to a price increase or quality reduction. This necessarily requires a focus on how spending translates into revenue for the hypothetical monopolist if one is to apply the test quantitatively.
834 In addition, it is not clear in any event that usage and app spending on digital content are closely correlated.
835 Professor Asker’s analysis demonstrated a lack of correlation between app downloads and service fee revenue, as well as a lack of correlation between Android Fortnite usage and spending. And no expert has analysed the extent to which app store or app usage is correlated with other categories of app store revenue such as spending on advertising.
836 Google says that this further points against the utility of a market definition exercise focused on usage to the exclusion of spend, when there can be no confidence that usage data would accurately capture the relevant competitive incentives or rivalry with respect to the Play Store’s services.
837 The second main criticism by Google is that it says that Epic’s markets are said to be inconsistent with the evidence of choices and constraints.
838 Google says that a deficiency with Epic’s pleaded markets is that they are inconsistent with the commercial realities that Google faces with respect to threats to its revenue, in particular, the evidence concerning the choices available to app developers and device users, and the fact that the Play Store’s revenue is fragile given it is concentrated amongst a small number of high value users and large app developers.
839 Google says that when these choices are understood in this broader context, it becomes clear that the sources of alternatives available to users and developers impose a substantial competitive constraint on the Play Store and Android OS and should be included within the relevant markets.
840 Google says that there are choices available to Android device users with respect to how they use their apps and how they purchase app-based digital content. It has advanced the following points.
841 A user first makes a choice when purchasing their mobile device, that is, choosing whether to purchase an Android or an iOS device. Next, a user must select which device to use from among those they already own, that is, multi-homing. Finally, a user can access and spend on an app from a multitude of locations, including through the Play Store, or an alternative app store, a sideloaded app, a pre-installed app, a web app, a streaming service or an out-of-app purchase on a developer’s website.
842 Out of all of these choices, the Play Store is only able to generate revenue if the user decides to transact via the Play Store.
843 Likewise, there are a range of choices available to app developers with respect to how and where they monetise their apps, and as to the extent to which they invest in one platform versus another.
844 These choices include the platforms for which they develop an app, that is, Android, iOS, PC, console, or web based. There is the choice of the extent to which they invest in apps for certain platforms, that is, a developer could invest more in apps for certain platforms relative to other platforms. There is the choice of how the app is distributed, that is, the Play Store versus an alternative app store, sideloading, pre-installation, web app or streaming service. There is the choice of the monetisation strategy, that is, in-app purchases, paid app download, subscription, in-app advertising decisions or a combination. And there is the choice of the transaction venues used for monetisation, that is, within the app, cross-wallet functionality, or out of app purchase on a website.
845 Further, the sources of these various user and developer choices in fact impose close competitive constraints on Android OS and the Play Store, and they are close constraints both individually and in aggregate.
846 The principal sources of this constraint are Apple’s iOS, the option of Android app stores or sideloaded or pre-installed apps in the Android ecosystem, gaming consoles and PC app stores, and web apps, websites and streaming services.
847 Google says that the evidence regarding these choices and competitive constraints is both qualitative and quantitative.
848 The qualitative evidence includes numerous Google business records that consistently describe its perception of serious competitive threats from iOS, rival Android app stores, and other platforms, and its response or proposed response to these threats.
849 Similar perceptions of competitive threats with respect to monetisation of in-app transactions are contained in Apple’s internal documents, communications between Epic and gaming console makers in the context of negotiations over cross-play and cross-wallet functionality in Epic’s games, and a communication between Epic and Valve.
850 Google also says that the quantitative evidence is provided by Professor Asker and is corroborated in material respects by the quantitative analysis contained in Professor Goldfarb’s second report.
851 It says that this econometric evidence based on Fortnite spend data shows not only that non-Android transaction venues including iOS are closer substitutes for user spend on the Play Store than alternative Android app stores, but that Epic’s pleaded Android app store market fails the hypothetical monopolist test.
852 Further, Google says that Professor Asker’s critical loss analysis demonstrates that even when adopting the inputs advanced by Professor Goldfarb and Professor Davila, Epic’s Android mobile app distribution market does not have robust empirical support for a 10% SSNIP. It fails under a range of reasonable assumptions and specifications.
853 Google says that the effect of the quantitative evidence is that the relevant market in which the Play Store competes must include, at a minimum, game consoles and Apple’s App Store.
854 Google’s third main criticism concerns the position of the OEMs.
855 Google says that Epic has adduced little evidence to understand the true position of OEMs or their commercial incentives to participate in the Android ecosystem.
856 It has adduced no evidence from any OEM to suggest that they consider the OEM restrictive terms to be restrictive or contrary to their interests. Nor has it adduced evidence as to how OEMs might operate if the OEM restrictive terms were removed.
857 And it has adduced no evidence that would permit an understanding of the financial position of OEMs, the nature and extent of their commercial incentives to participate in the Android ecosystem or how those incentives may be affected by the relief which Epic seeks.
858 Google says that these omissions have consequences for the analysis of the conduct at issue.
859 First, they impact the market definition inquiry and the evaluation of Epic’s proposed mobile OS licensing market. One cannot select what emerges as the clearest picture of the relevant competitive process without first obtaining a detailed understanding and proper characterisation of the commerce in question.
860 Second, they impact the question of market power. One cannot understand whether Google has market power in the putative mobile OS licensing market without understanding the countervailing power of OEMs.
861 Third, they impact the competitive effects inquiry. Any question of commercially realistic likelihoods requires a consideration of whether, and how, OEMs would act differently in a future without the impugned conduct.
Some relevant concepts debated by the economic experts
862 It is convenient at this point to refer to some economic concepts that were the subject of discussion and debate before me in the Google proceeding.
863 The first topic discusses some general themes concerning the HMT. The second topic concerns elasticities, diversion ratios, multi-homing and switching. The third topic concerns whether one should look at user spending or actual usage. The fourth topic concerns the distinction between a profit-maximising step and a profitable step. The fifth topic concerns the application of quantitative testing to two-sided markets. And the sixth topic concerns bundled products.
864 Now many of these topics were the subject of greater debate between the experts in the Google proceeding than in the Apple proceeding. This is a reflection of the fact that greater quantitative analysis was carried out by the experts in the Google proceeding.
865 But it should be noted that my discussion in this proceeding takes as its foundation the detailed legal and economic discussion concerning general principles relating to market definition contained in my reasons in Epic v Apple.
866 Now before proceeding further I should say something about the economic experts.
The experts
867 Professor John Asker, an expert economist, was called as a witness by Google. He is a professor in the department of economics at the University of California, Los Angeles. His research interests are industrial organisation, competition policy and anti-trust economics.
868 He gave one report in Epic’s proceeding against Google and another report in the class action against Google.
869 He also participated in a joint expert report with Ms Edwards-Warren and Professor Goldfarb and in a separate joint expert report with Mr Holt.
870 He gave evidence in various concurrent evidence sessions. He was principally cross-examined for Epic by Mr Young KC, although Mr Prince was given a cameo role on some technical quantitative questions. Professor Asker was also cross-examined by Mr Bannon SC for the class applicants.
871 There is no doubting Professor Asker’s expertise, but I did think at times that he over-played his position on some of the quantitative analysis. Clearly he had a predilection to mathematise anything that he could. But the relevant formulae and other mathematical analysis that he used could only be one tool. Further, some relevant data inputs were lacking. Moreover, simplifying assumptions had to be made. But nevertheless, his detailed treatment was impressive and I have seen fit to set out some of his mathematical derivations for formulae that have been derived for the specific purpose of this proceeding.
872 But when his quantitative treatment came up against Professor Goldfarb, who seemed to have more specialist econometric expertise, I thought that Professor Goldfarb’s views were preferable. And there was no occasion where Professor Goldfarb over-played his hand.
873 Further, in terms of the inter-play between Professor Asker, who was more quantitative, and Epic’s expert Ms Kirsten Edwards-Warren, who was more qualitative, the latter’s views sat more easily and commercially with me, as did Professor Wright’s views in the Apple proceeding as I have said elsewhere.
874 Further, I thought that Mr Holt and Professor Asker were equally matched in the areas of subject-matter overlap.
875 Now rather than comment further at this point, it is better that I address the specific aspects of Professor Asker’s evidence under the particular topics later.
876 Now Ms Edwards-Warren is an expert economist. She is an executive vice president at Compass Lexecon, a global economic consulting firm, and the deputy head of its European practice. She had been the director of economics at both the UK Office of Fair Trading and the UK Competition Commission before they were combined.
877 Her first report dealt with an economic analysis of the relevant markets, market power and effects and was qualitative in its emphasis. Her second report provided a response to Professor Asker’s report, and indeed was longer than her first report given that she responded to Professor Asker’s detailed quantitative analysis.
878 Ms Edwards-Warren participated in a joint expert report with Professor Asker and Professor Goldfarb and also gave evidence in concurrent evidence session. She was cross-examined by Mr Moore SC for Google.
879 Now it is fair to say that I engaged more with Professor Asker than I did with Ms Edwards-Warren during the concurrent evidence session, but I needed to understand more of the quantitative analysis in Professor Asker’s evidence, and indeed query some aspects to improve my understanding. Contrastingly, her style of anti-trust analysis was more familiar to me and sat better with me commercially, as too did the approach of Professor Wright in the Apple proceeding.
880 There is no doubting Ms Edwards-Warren’s considerable expertise and reliability. It is appropriate that I leave further commentary to the more detailed discussion of particular topics.
881 I should also note that Professor Goldfarb and Mr Holt also gave relevant evidence on some of the economic topics. I repeat what I said in my reasons in the Apple proceeding concerning their background and expertise.
882 Let me then turn to some of the themes debated between the experts.
Hypothetical monopolist test — general themes
883 In what follows I will assume that the reader has read what I have said in my reasons in Epic v Apple concerning the HMT.
884 Ms Edwards-Warren usefully identified the conceptual steps in applying the HMT. It is convenient to adopt her framework with which for the most part I substantially agree. Some of this is a repetition of what I have said in my reasons in Epic v Apple.
885 The test begins by identifying a narrow candidate market that incorporates the product of interest.
886 The next step is to consider demand-side (and potentially supply-side) responses to a SSNIP. As I have said elsewhere, SSNIP is short for small but significant non-transitory increase in price. Small but significant is typically interpreted as a 5 to 10% price increase, holding prices of other products constant.
887 Now a SSNIP test is inter-alia an organising framework for assessing markets. It raises the question, if customers were faced with a small increase in price or, alternatively, a small worsening in contractual terms or quality, how would they likely respond? Answering this question involves identifying the potential substitute products and/or geographies and assessing based on available evidence whether customers would switch to these potential substitutes.
888 As part of the consideration of demand-side responses, it is important to consider who the customers are, and how they impact each other’s behaviour.
889 A market is two-sided if firms in the market are platforms which intermediate between two sets of customers, and the size of one side of the market has an impact on the size of the other side of the market.
890 In a two-sided market, reactions on one side of the platform, for example, by Android smart mobile device users, can influence reactions on the other side, for example, by app developers.
891 It may also be relevant to consider supply-side responses to a small hypothetical price increase, say, where a supplier of a closely related product may start to supply the product in question within a relatively short time frame and without incurring significant sunk costs.
892 Supply-side substitution could, in theory, render a hypothetical monopolist’s price increase (SSNIP) unprofitable. But in practice the most immediate constraint typically comes from the demand-side.
893 Further, the time period within which switching has to take place to constrain the hypothetical monopolist might vary depending on the context. If switching is unlikely to happen sufficiently quickly, a SSNIP can be considered profitable.
894 The next step is to assess whether a SSNIP would likely be profitable.
895 If demand-side or, if relevant, supply-side responses are insufficient to prevent a small price increase by the hypothetical monopolist, that is, the small price increase is profitable, then the candidate market being assessed is a viable antitrust market and the test is complete.
896 If the hypothetical price increase is unprofitable because of switching to a substitute product, then the market should be widened to include that product. One then repeats the thought experiment starting with a wider set of products or geographies. The closest substitutes should be considered before more distant substitutes, to the extent this is known.
897 Now products that are not within the relevant market based on the SSNIP test may still exert some competitive constraint on products within the market. It is appropriate to consider such competitive constraints from potential rivals as part of the market power assessment.
898 Now as I have indicated, in practice it is frequently the case that one cannot perform an empirical or quantitative SSNIP test due to limitations on data availability. Instead, it is appropriate to evaluate other types of evidence such as functional substitutability, evidence on customer purchase drivers and evidence on past switching or threatened switching to inform a qualitative application of the HMT.
899 Let me say something about multi-sided platforms and network effects. Now I have discussed this topic in detail in my reasons in Epic v Apple, but let me make a few points here.
900 Digital platforms connect different groups of customers and may generate a network effect. A network effect arises when one group of customers on the platform benefit when there are more participants on the other side of the platform and/or vice versa. The platform can be described as multi-sided.
901 The Play Store is an example of a digital platform which supplies services to two distinct customer groups. It intermediates between app developers and Android smart mobile device users, enabling the distribution of apps. App developers benefit when there are more users accessing apps on the Play Store, and Android smart mobile device users benefit when there are more app developers distributing via the Play Store.
902 The prices charged by a multi-sided platform to each user group will depend on several different factors, including which user group benefits most from there being more participants on the other side of the platform, whether charges are levied per transaction or on a lump sum basis, and whether users use only one platform or multiple different platforms, that is, multi-homing.
903 If the HMT is applied without taking into account network effects, then the results could be misleading and markets could be defined incorrectly, typically too narrowly.
904 For example, if the test is applied only considering the behaviour of app developers, it could overlook how a reduction in the number of app developers would reduce the number of Android smart mobile device users, and thus reduce the profitability of a price increase.
905 Where relevant, in analysing different candidate market definitions, one should take into account the potential two-sidedness or multi-sidedness of the putative market and the resulting likely feedback and network effects between different groups of customers in, for example, the effects that the choices of users and app developers have on each other.
906 I will say something more about two-sided markets and applying a SSNIP test later.
907 Now before proceeding further, let me say something about the application of the HMT.
908 When assessing whether it would be profitable for a hypothetical monopolist to raise prices by a small amount, or reduce quality or worsen contractual terms more generally, it is not necessary that all customers switch away or that customers switch away all of their purchases for the small price increase to be unprofitable.
909 If the sales generated by marginal customers, that is, by customers who are most likely to switch away, whether fully or by reducing their purchases, are sufficiently large, a SSNIP may be unprofitable, even if a large number of infra-marginal customers remain with the hypothetical monopolist.
910 The following types of evidence are relevant to assessing how much switching would be expected in response to a SSNIP.
911 The first type of evidence relates to the comparability of potential substitutes from a functional perspective. So, Android smart mobile device users or app developers would be less likely to substitute towards products that are functionally very different in response to small changes in relative prices.
912 The second type of evidence relates to the cost of switching between different alternatives for OEMs, for app developers and for Android smart mobile device users or suppliers of similar products. The cost of switching may be financial or non-financial such as time or inconvenience. All else being equal, higher switching costs make it less likely that switching would occur in response to relatively small changes in prices.
913 The third type of evidence relates to actual switching, involving understanding the products to which customers or suppliers switch and their motivation for switching where known and the context for such switching.
914 The fourth type of evidence relates to what is revealed by Google’s internal documents to the extent that they reveal any competitive pressure or lack of pressure on Google Android, the Play Store or Google Play Billing.
915 Now if there is insufficient data to quantitatively assess actual losses from a SSNIP, one has to make qualitative judgements to decide whether a price increase by a hypothetical monopolist would likely be profitable.
Elasticities, diversion ratios, multi-homing and switching
916 A competitor constrains a firm when customers of the firm view a competitor’s product as a substitute. As Professor Asker explained, economists define substitutes in terms of elasticities. An elasticity measures the percentage change of a variable in response to the percentage change of another variable.
917 As Professor Asker explained, when thinking about competition there are two types of elasticities to focus on.
918 First, own-price elasticity measures the percentage change in a firm’s quantity sold in response to a percentage change in its price. Own-price elasticities answer the question “if a firm raises prices by, for example, 1 percent, by what percentage is the quantity sold reduced?”
919 Second, cross-price elasticity measures the percentage change in a firm’s quantity sold in response to a percentage change in a competitor’s price. Cross-price elasticities answer the question “if a firm raises prices by, for example, 1 percent, by what percent does its rival’s quantity sold increase or decrease?”
920 Two firms’ products are substitutes when the cross-price elasticity is positive, that is, when the quantity sold by one of the firms increases when its rival’s price increases or, equivalently, when its rival’s quality decreases.
921 Contrastingly, two firms’ products are complements when the cross-price elasticity is negative, that is, when the quantity sold by one of the firms decreases when its rival’s price increases.
922 Analogous definitions for substitutes and complements can be defined with respect to changes in quality instead of changes in price.
923 Now as Professor Asker explained, a useful reformulation of price elasticities is that of diversion. Diversion refers to lost sales due to a price increase or product removal that are captured by a supplier of a substitute.
924 The diversion ratio between two products A and B is the proportion of sales that are captured by product B when product A increases its price by some amount. The diversion ratio tells you about substitutability between products and it is sometimes approximated by examining the effect of removing product A from the market entirely and seeing if the customers move across to buy product B. Diversion is typically measured by a diversion ratio, which refers to the proportion of total sales lost that is captured by a rival.
925 Diversion answers the question “if a firm increases its product’s price, of the lost quantity sold, what percent goes to a given rival?” Positive diversion implies that cross-price elasticities of demand are positive and that the two firms’ products are substitutes.
926 As Professor Asker explained, arithmetically the diversion ratio from good i to good j is equal to the ratio of market shares of good j to good i multiplied by the ratio of the cross-price elasticity of good j with respect to the price of good i to the absolute value of the own-price elasticity of good i.
927 Now the greater the degree of substitutability between two firms’ products, the closer they are as competitors and the higher the diversion ratio.
928 Now diversion ratios are invariant to measurement in terms of quantities or revenue units, as they are measured with reference to the firm that increases its product’s price. Revenue is price times quantity. Because diversion is expressed as a ratio, measuring diversion using revenue units is the same as measuring diversion using quantity because the price term is common to the numerator and denominator. So, price cancels out.
929 Now the key aspect for accurate measurement of diversion is that quantities (equivalently revenues) correspond to the product or service being purchased by consumers. Depending on the context, it can be easier from a data perspective to use revenues instead of quantities.
930 Further, as Professor Asker explained, two other related concepts to substitution are those of multi-homing and switching.
931 Multi-homing occurs when customers of a given product purchase that product from multiple firms, for example, a developer publishing to multiple app stores. The term multi-homing is more commonly applied with respect to multi-sided platforms.
932 Switching occurs when customers of a given product completely stop using one firm’s offering and start using another’s, for example, a consumer replacing an Android smartphone with an iOS smartphone.
933 Multi-homing and switching are distinct from, but informative about, substitution. They are distinct because neither concept measures changes in behaviour that can be solely attributed as responses to changes in price (or quality). Nonetheless as Professor Asker explained, they can be indicative about price-based and quality-based substitution when combined with other information.
934 So, high levels of multi-homing may indicate that it would be relatively easy for customers to substitute in response to any one firm raising prices because they already transact with rivals. For example, when the price of a game on a given hardware gaming platform such as Xbox or PlayStation 2 increases, customers who own multiple hardware gaming platforms may substitute to a platform on which the game is cheaper for purchase compared to customers who only own one platform. An important reason is that multi-homing customers have already purchased and transacted on other hardware platforms, and therefore do not need to incur additional adoption costs that are unavoidable for single-homing customers. This means that the costs to the customer of finding an alternate supplier, and any uncertainty associated with the quality of that supplier, are lower than if customers were not multi-homing.
935 And high levels of switching may indicate that it would be easy for some customers to substitute in response to a price increase to a rival’s product. When consumers change their choice of product, say, because consumers switch their preferences for characteristics that vary across differentiated products, absent a price change, then price changes will incentivise more consumers to switch products. This is because marginal customers already switch between the products in response to their experience with the product, indicating that it is feasible and likely relatively easy to do so.
User spending or actual usage? What is the relevant metric?
936 Professor Asker’s analysis focused on user spending to understand the relevant constraints facing the Play Store.
937 Epic’s experts instead focused on usage, relying on metrics such as the number of downloads and the amount of time spent on an app. They said that usage is informative because it is a proxy for spending.
938 But according to Professor Asker, actual spending is the best proxy for spending and the correct metric to use. It is unnecessary to interpose a different proxy in circumstances where there is no economic, statistical or practical reason not to base an analysis on the rich data available concerning the primary and most informative metric, spending.
939 First, the HMT is about understanding what constrains a hypothetical monopolist’s profits. This means that substitution that affects revenue, that is, where consumers substitute their spending, is central to the HMT because it requires the economist to consider things in terms of dollars.
940 Second, Professor Asker said that Professor Goldfarb’s focus on Fortnite usage was divorced from the commercial reality within which the Play Store operates. The Play Store primarily earns revenues from the service fee it charges on consumer spending on digital content, not the use of apps downloaded via the Play Store. This means that the relevant substitution to understand the market within which the Play Store operates is substitution in spending on paid digital content transactions. While there can be contexts where usage is relevant for market definition, for example, if the firm does not monetise with a price, they do not apply here.
941 Third, economists do not use usage as a proxy for spending when spending data is available. Usage may be a good proxy for spending in some contexts, but spending is always the best proxy for spending.
942 According to Professor Asker, in this matter rich data exists to measure spending, including data on Fortnite users’ spending, spending via the Play Store, spending via the iOS App Store and spending on digital game content. In any event, usage is not a good proxy for spending in the relevant circumstances. Usage of app content and spending on app content by consumers are separate and divergent inquiries. Further, he said that the fact that usage and spending can be and often is decoupled increases the importance of focusing on the relevant metric, namely, spending.
943 Fourth, he said that spending is a sufficient statistic to evaluate competitive constraints facing the Play Store. Now Epic’s experts pointed to indirect network effects in which greater usage leads to greater spending, although they did not quantify the magnitude of these effects and instead relied on hypothetical examples. But Professor Asker said that the fact that such network effects exist does not mean that usage should be given primacy over spending. A decrease in usage may affect spending, whereas a decrease in spending will decrease spending. In this sense, focusing on spending is conservative. Further, if the network effects are significant, the analysis of spending captures them anyway.
944 But Professor Goldfarb gave evidence which I found persuasive that usage data and analysis is appropriate for several reasons.
945 First, usage is directly tied to the benefit that users receive from an app. Most users derive value without ever spending.
946 Second, the value of usage is evident regardless of the specific app monetisation strategy employed by an app developer.
947 Third, use by one consumer increases value for other consumers through direct network effects.
948 Let me develop these points further based upon Professor Goldfarb’s evidence which in my view was conceptually coherent and commercially sound.
949 First, I agree with Professor Goldfarb that usage is important for understanding consumer substitution behaviour as it quantifies the benefit a consumer derives from an app. The focus on actual consumer use of apps therefore measures how apps generate value to the consumer. As consumption is directly tied to how a consumer values an app, more use is a sign of more value to the consumer.
950 Nevertheless, Professor Asker said that use is distinct from spending. He supported this claim through several examples of goods like computer screens or grocery stores where usage appears to be unrelated to spending.
951 But these examples do not correspond to the issue at hand as apps are durable digital goods. For durable goods, the benefit of the product depends on usage itself. All else being equal, those who use a durable product derive more benefit from it through continued use.
952 For computer screens, the amount a consumer uses a screen provides a greater indication of the value they derive, net of the purchase price, than the purchase price alone. This aspect is heightened for digital goods, as much of the consumer surplus from a product is derived from consumption itself, that is, scrolling on an app, often regardless of payment. Consumption and thus the consumer benefit is directly related to time use on an app.
953 Second, I also agree with Professor Goldfarb that usage creates economic value for developers across all app monetisation strategies.
954 Consumer usage is also relevant to understanding business decisions that developers make. Usage contributes to app revenue generation across multiple app monetisation strategies, that is, the developer’s choice of how to generate app revenue. So, usage is a key metric to understanding consumer behaviour and firm revenues. Professor Asker himself said that usage as a metric can be helpful in situations where firms monetise based on usage-based ads. In an ad-based app monetisation strategy, usage serves as a proxy for consumer behaviour that drives a firm’s revenues. But this app business model is not the only monetisation strategy where usage is a key metric to understand consumer behaviour and firm revenues.
955 The nature of the connection between usage and spending depends upon the app monetisation strategy. Available monetisation strategies through the Play Store include pay-to-download apps, free-to-download apps with in-app purchases including recurring subscriptions, or free-to-download apps that may rely on ad-supported models. For each of these monetisation strategies, there is a link between use and revenues.
956 For pay-to-download apps, use is linked to spending because users download the app for the purpose of using the app. On the developer side, while a user must first pay before they engage with the app, developers seek to maximise user engagement with the app to attract other users to make paid downloads.
957 For apps utilising in-app purchases, use and spending are directly linked. A user engages in in-app purchases to enhance their engagement with the app, for example through a game or through purchasing specialised material in an education app. For recurring subscription models, developers similarly value user engagement so that users are incentivised to continue making a recurring purchase and so that other users are motivated to initiate a subscription. So, use is closely related to continued subscription transactions.
958 For ad-supported apps, it is use that matters and not spending because developers seek to maximise individual user engagement and number of users overall to command higher advertising revenues. Professor Asker highlighted that because customers do not spend money on ad-supported apps, customer spending is not the appropriate metric to understand constraints on the relevant firm. He said that in these situations examining substitution in usage in response to increased ads or worsening quality can be informative.
959 App developers may also have one or multiple monetisation strategies, for instance, the “freemium model” where developers may offer a free tier and a paid tier of an app. Free tiers often increase the number of sales of paid versions of apps available on Android, along with apps available on iOS.
960 Third, I also agree with Professor Goldfarb that direct network effects create value for apps from use alone.
961 Now Professor Asker further dismissed usage as uninformative because the Play Store does not earn revenues based on the time users spend within an app and users can scale this time up or down or shift this time to a competitor of the Play Store and the Play Store’s revenue is unchanged. These statements ignore network effects.
962 Usage is linked to revenues because of the importance of network effects for many app types. By network effects, what is meant is that the value of an app increases with the number of users engaged.
963 For most gaming apps in particular, the number of users and the time they spend on an app directly impacts the experience of other users, particularly for multiplayer games, regardless of whether these players engage in in-app purchases or not.
964 Ad-supported social media apps also increase in value with more (non-transacting) users engaging across the platform. More users streaming content on a given app helps developers decide what content to invest in to meet demand, an indirect network effect, which in turn affects the decisions of users to pay for subscriptions.
965 For apps that facilitate the exchange of physical goods or services, for example, ride hailing or home rental, more drivers or property owners increase consumer surplus through more choice and improved quality for consumers. More users impact driver or property owner willingness to participate on the platform. Use therefore increases revenues.
966 Professor Asker further said that network effects in usage on apps do not translate to network effects in spending, particularly in the context of Fortnite. But if network effects in usage do not translate into network effects in spending, then developers or platforms would not be motivated to develop or include free apps or freemium apps. In reality, freemium models are acknowledged to be popular in the video game industry and in other industries. Free versions of apps lead to more purchases of paid app versions on Android. This contradicts Professor Asker’s statements.
967 Professor Asker provided a measure of the correlation between total weekly spending through the Play Store in Australia and worldwide weekly usage across all channels as evidence that usage and spending are not related.
968 This approach is uninformative. The correlation figure presented by Professor Asker (-0.42) is a statistically insignificant figure that compares weekly spend on one channel in one country, being weekly spend on the Play Store in Australia, with the global weekly number of users across all channels. There are many factors that would explain this non-statistically significant negative correlation. For example, factors such as different holiday schedules or seasons across the Northern and Southern Hemispheres may cause differences between expenditure and usage patterns for Australia as compared to the rest of the world.
969 Professor Goldfarb considered the more appropriate comparison to be between the total weekly spending across all channels in Australia and the total weekly users across all channels in Australia. In estimating this figure, he found a statistically significant correlation of 0.52. The large figure and the statistical significance together indicate that these two variables move strongly together.
970 Fourth, I also agree with Professor Goldfarb that by focusing on only users that spend, Professor Asker excluded the majority of users and apps. This is because most apps do not offer paid transactions to users and the majority of users do not make paid app transactions.
971 The majority of users of Fortnite do not spend. Indeed Professor Asker estimated that approximately 55 to 70% of Fortnite users did not spend on Fortnite at all over the three and a half year period for which he had data.
972 On the developer side, few developers offer paid apps or in-app purchases.
973 So, considering only paid transactions omits the majority of users and the majority of apps from an analysis. This is despite the fact that usage contributes directly and indirectly to revenues, consumers gain consumer surplus through their usage, and developers gain value through network effects.
974 So, across each of his analyses, Professor Asker in effect excluded most users and a major source of consumer surplus. Let me turn to some general matters.
975 Now Professor Asker said that Epic’s economic experts ignored evidence of substitution in spending by focusing on substitution in usage. But as Professor Goldfarb pointed out, this criticism is problematic given several relevant points about app products that Professor Asker disregarded, along with the relationship between spending and usage.
976 Usage is appropriate for understanding whether Android smart mobile device users treat web apps, iOS native apps, and native apps on other devices as interchangeable with apps on Android smart mobile devices. Usage quantifies the benefits that consumers derive from an app. As apps are digital durable goods, the benefit of the product depends on usage itself, often regardless of a direct purchase on the app.
977 Consumer usage is also relevant to understanding the business decisions that developers make, including which monetisation strategy to pursue.
978 Usage is related to revenue generation and this is true across app monetisation strategies. A monetisation strategy is how the developer chooses to earn revenue, whether via subscription, in-app purchases, advertising or other means.
979 Professor Goldfarb explained the links between usage and revenue for pay-to-download apps, apps with in-app purchases, including recurring subscriptions, ad-supported apps, and mixed monetisation strategies like “freemium” models.
980 Further, usage itself generates value for users and developers. This includes network effects in usage translating to network effects in consumer spending. This runs counter to Professor Asker’s claim that usage and spending are not closely related.
981 Professor Asker presented a problematic, negative and statistically insignificant correlation between weekly spending on Fortnite through Play Store in Australia and global weekly usage across all channels as evidence for his claim.
982 Professor Goldfarb corrected this, and applied a more appropriate correlation metric between weekly spending and usage in Australia across all channels. Professor Goldfarb’s correlation metric is more appropriate because it is regionally specific and representative of the correlation between spending and usage regardless of channel.
983 He found a robust correlation of 0.52, which shows that usage and spending are highly correlated.
984 A further issue with Professor Asker’s spending analysis is that the majority of users do not spend, and so considering only spending to understand consumer substitution omits the majority of app consumers.
985 The same issue applies to the developer side. Most developers do not pursue monetisation strategies where users pay directly in or for the app. Alternatives include ad-supported apps, for example. So, considering only spending also fails to account for the majority of app developers.
986 Given the relevance of usage for understanding whether consumers treat different app types as substitutes, Professor Goldfarb did not consider spending to be the most useful metric through which to understand consumer substitution behaviour. Nevertheless, he explained that use is a strong proxy for spending for the users who make paid app transactions, for several reasons. Whenever he referred to spending, he referred to paid app downloads and in-app purchases of digital content including subscriptions.
987 First, Professor Goldfarb demonstrated that use and spending are highly correlated for users who spend. This means that changes in revenue are associated with similar changes in usage, and vice versa. Professor Asker also presented correlation coefficients for use and spending, oftentimes nearing 0.50. A correlation coefficient runs on a scale of -1 to 1, with numbers closer to 1 indicating that two variables move closely together in the same direction, that is, when there is an increase in one coefficient there is also an increase in the other coefficient. He interpreted these coefficients to show minimal correlation.
988 This interpretation is incorrect given common practice is to consider both the magnitude and statistical significance from zero to interpret the strength of a correlation coefficient. It also ignores the established literature defining the assumptions required for one variable to be considered a good proxy variable for another.
989 Second, Professor Goldfarb found that usage is a good proxy for spending because users almost never play and spend across different channels. Across all users prior to the removal of Fortnite from the Play Store, he found that a minority of users spent across more than one spending channel overall within a given day. He also assessed multi-homing across spending and play channels within a day and found that less than 2% of users unambiguously spend and play across different play channels within a day.
990 This is in direct contradiction to Professor Asker’s presented data on user substitution across spending channels. Professor Asker did not show evidence of substitution between spending channels, either on the same device or across devices. His evidence showed only that a consumer had ever used a given spending channel. This is not evidence of whether consumers would consider that spending channel as reasonably interchangeable with another.
991 Professor Goldfarb’s view is that usage is a critical outcome to assess when trying to understand consumer substitution behaviour.
992 Further, even if spending was the most appropriate metric for understanding consumer substitution, usage remains a strong proxy variable for spending.
993 Now Professor Asker said that usage is not a proxy variable for spending because usage and transactions are not correlated. He presented evidence first on the correlation between downloads and service fees revenues across apps in the Play Store. He also presented evidence on the correlation between usage and revenues for Android or Play Store Fortnite users.
994 Professor Asker used a rank correlation as his main analysis for both measures but also presented correlations based on actual downloads, use, and spending as robustness checks. For measuring the correlation between downloads and revenues from service fees, Professor Asker found correlations of 0.27 to 0.31, depending on the exact methodology used.
995 Professor Goldfarb did not find these correlations to be informative in determining the extent to which usage is a proxy of spending because downloads do not measure usage.
996 For revenue versus use, he found a correlation of 0.39 to 0.46, depending on methodology. Again, each of these correlation coefficients are statistically significant.
997 This methodology likely understates the correlation between use and spending.
998 Usage and spending do not need to be perfectly correlated to be considered proxy variables.
999 In S Athey, R Chetty, G Imbens and H Kang, “The Surrogate Index: Combining Short-Term Proxies to Estimate Long-Term Treatment Effects More Rapidly and Precisely” (2019) National Bureau of Economic Research (working paper), the authors discuss surrogates, that is, proxies, as outcome variables that can be used to measure another outcome variable that may often be harder to measure or based on a longer time horizon, for example, school test scores as surrogates for long-run earnings.
1000 The authors note that the key assumption for one variable being a good surrogate, for example, usage, for a given outcome, for example, spending, is that the outcome must be independent of treatment conditional on the surrogate.
1001 Here, usage is a valid surrogate variable for spending if, after conditioning for usage, spending is independent of removal. This is to say that usage is a valid surrogate variable for spending if changes to spending due to removal can be explained by changes to usage alone. Based on this commonly used assumption, usage is a good proxy for spending.
1002 Professor Goldfarb performed his own analysis to understand the correlation between Fortnite usage and spending. He linked Fortnite game play and purchases data to study the relationship between match play time, being usage, and paid app transactions, being spending to obtain digital content, across all spending channels and usage channels and across a longer time frame.
1003 He found that only 26.1% of users ever spent on Fortnite through any spending channel during the time window from 26 February 2018 until 9 August 2020 (pre-removal).
The themes of “device first” and “clicks are costly”
1004 Professor Goldfarb explained that user behaviour in choosing devices such as a smartphone or PC is influenced by external factors such as use context, such as a free afternoon or a spare five minutes before class, and environment at home, work or, say, on the bus. He said that the choice of device itself influences choice of activity, since difference devices are conducive to difference usage experiences.
1005 This concept is referred to as “device first”. These concepts are important in understanding consumer behaviour, particularly in relation to substitution patterns. Further, “device first” is a useful framework to understand why products that may appear to be functionally similar are not substitutes in reality for consumers.
1006 Further, the concept of “clicks are costly” refers to the phenomenon of users finding the requirement to execute additional steps to perform activities on electronic devices, that is, information gathering or transactions, to be burdensome enough to deter the user from completing the activity. “Clicks are costly” provides a framework to discuss the relative costs and benefits that consumers implicitly weigh in their decisions. This includes whether to move out-of-app to make a paid transaction or complete the transaction in-app.
1007 Professor Goldfarb disagreed with the claims of Professor Uri Gneezy and Professor Asker that the “clicks are costly” concept is uninformative for the matter at hand.
1008 Professor Asker mischaracterised the “clicks are costly” concept and provided unfounded critiques of Professor Goldfarb’s supporting empirical analysis. Professor Asker also criticised his empirical study of the impact of switching to biometric-enabled devices on the number of transactions undertaken by the consumer.
1009 The criticisms of Professor Asker of Professor Goldfarb’s analysis of how switching to a biometric device impacts the number of transactions a consumer undertakes are incorrect. Furthermore, when one corrects for the errors in Professor Asker’s methodology to assess the effect of switching to a biometric-enabled device using a different event study design, the results confirm the conclusion that reducing the frictions associated with completing transactions increases the number of transactions consumers undertake.
1010 Further, Professor Gneezy refused to engage with Professor Goldfarb’s “clicks are costly” analysis.
1011 Professor Gneezy stated, in respect of Professor Goldfarb’s “clicks are costly” analysis, that the application of that concept to the analysis of Android smart mobile device users’ behaviour on electronic devices absent proper empirical evidence is inappropriate.
1012 Professor Goldfarb provided empirical analysis by way of his consideration of the introduction of biometric features on iOS devices. That analysis was contained within the “clicks are costly” section of Professor Goldfarb’s report to which Professor Gneezy was instructed to respond.
1013 The analysis was also referred to in Professor Goldfarb’s response to the same question in the joint report to which Professor Gneezy was responding.
1014 Despite those matters, it became clear from the cross-examination that Professor Gneezy had not considered Professor Goldfarb’s biometric analysis in preparing his written report.
1015 Professor Gneezy was willing to describe Professor Goldfarb’s analysis as inappropriate without paying any real attention to the material upon which it was based.
1016 In my view, his criticisms of Professor Goldfarb on this aspect lacked substance.
1017 I accept Professor Goldfarb’s themes of “device first” and “clicks are costly” which I have also discussed elsewhere.
1018 Let me turn to another topic that excited the interest of the parties and their experts.
Profit-maximising or just profitable?
1019 Professor Asker considered that the HMT asks whether the hypothetical profit-maximising monopolist would raise prices by a small, significant, non-transitory amount (say 5%). This is important, because if one does not require profit-maximisation, the test would be hypothesising a scenario that would be economically irrational for the hypothetical monopolist. The reason for conducting the critical loss analysis with a 10% price increase, which merely asks whether that price increase would be profitable, as opposed to profit-maximising, is because of a result in the economics literature that if a 10% price increase is profitable, the profit-maximising price increase is generally at least 5%, whereas if it is profitable at 5% but not 10%, the profit-maximising price increase is generally below 5%.
1020 Contrastingly, Ms Edwards-Warren considered that the HMT merely asked whether the hypothetical monopolist would find it profit increasing, in contrast to profit-maximising, to increase price by a small, significant, non-transitory amount (say 5%). But she conceded that on her version of the test it could mean that while a 5% price increase may be profitable, it may not be the level to which a hypothetical monopolist rationally would increase their price. She acknowledged that her version of the test really means “5 to 10 per cent being profit increasing, which one can also interpret as – broadly as two and a half per cent to 5 per cent profit maximising”.
1021 Google says that Ms Edwards-Warren’s version of the test should be rejected, because it is inconsistent with economic theory and competition regulatory practice for the following reasons.
1022 First, no regulatory guideline or authority has been put forward by Epic to corroborate Ms Edwards-Warren’s suggestion that a 2.5% to 5% profit-maximising price increase is the appropriate way to implement a SSNIP.
1023 Second, the evidence shows that the HMT is normally employed as a profit-maximising test.
1024 Third, the ACCC merger guidelines are consistent with a profit-maximising test and Professor Asker’s approach. I will return to this in a moment.
1025 Fourth, P Davis and E Garcés, Quantitative Techniques for Competition and Antitrust Analysis (2009, Princeton University Press) cited by Professor Asker supports the profit-maximising application of the HMT, not Ms Edwards-Warren’s profit-increasing version.
1026 Now I note that under cross-examination, Professor Asker observed that “this is a frustrating text in this regard because economists are loose with words and precise with math”. But Professor Asker said that when one focuses on the mathematical explanation of the HMT, it is clear that the authors posit an inequality where profits are always increasing, and require it to hold for all price increases between 0% and 5%. In other words, the test requires that the point of profit-maximisation is not reached before 5%. So, what was required was a profit-maximising price increase of at least 5%.
1027 Fifth, the fact that many Australian judgments have described the HMT as whether the hypothetical monopolist could profitably engage a SSNIP does not gainsay that the correct approach requires profit-maximisation, which is a nuance that arises only explicitly when conducting the HMT quantitatively.
1028 This is because in almost all competition law cases where market definition is in issue, the HMT has been applied as a qualitative thought experiment. There is no need for precision if the data does not permit a quantitative test. By contrast, mathematical precision is important if one is conducting the test quantitatively. So far as the quantitative analysis is concerned, the more precise formulation should be followed being the requirement for profit-maximisation.
1029 So, it follows that the HMT requires a profit-maximising price increase of at least 5%. This means that the critical loss analysis should be implemented with a profitable 10% price increase, to ensure that at least a 5% price increase would be profit-maximising.
1030 If so, Professor Asker’s approach of applying a 10% price increase is correct, and his analysis demonstrates that Epic’s Australian Android mobile app distribution market fails the HMT, whether using his preferred diversion estimates or Professor Goldfarb’s.
1031 So, it is too narrow and must be expanded to include non-Android platforms, particularly app stores on gaming consoles.
1032 Now Professor Asker’s HMT asked whether a hypothetical monopolist would find it profit-maximising to increase prices by at least 5% rather than asking if the price increase would be profitable.
1033 So, a given increase in price might be profitable, that is, profit-increasing, but not profit-maximising. But a profit-maximising formulation is more likely to lead to a broader market than a profitable formulation. Indeed, Professor Asker considered that asking whether a price increase is profit-maximising is equivalent, under certain assumptions, to asking whether double that price increase is profitable. That is, a profit-maximisation formulation is equivalent to doubling the magnitude of the price increase that must be profitable.
1034 I reject Professor Asker’s profit-maximising formulation of the HMT. It is not consistent with the preponderance of Australian and US case law or the literature. Let me first set out some Australian law on the profitable versus profit-maximising formulation of the SSNIP.
1035 In Australian Competition and Consumer Commission v Pacific National Pty Ltd (No 2) [2019] FCA 669; (2019) ATPR ¶42-633 I said (at [91] and [500]):
The “hypothetical monopolist” test or what is sometimes known as the “SSNIP” test can be used to assess substitution possibilities on the demand side. The question posed is whether a hypothetical monopolist supplier could profitably impose a small but significant non-transitory increase in price (so the SSNIP acronym) say between 5-10%, for the supply of the relevant product or service, but holding constant the terms of sale of all other products and services. The SSNIP being considered is relative to the prices that would prevail but for the merger. The thought experiment, whether built upon detailed data of the relevant variables or assessed more qualitatively, starts with the hypothetical monopolist supplier and the product or service in issue to define the product and geographic market; the test does not assist concerning defining the functional dimension. The question is then posed as to whether a SSNIP could be profitably imposed. If not, the next best substitute on the demand side is added to the market definition. The new market is then tested with the SSNIP test. If a SSNIP could be profitably imposed, then you have your market definition. If not, you again add the next best substitute to your market definition and test again, and so on. The idea is to find the smallest area (product and geographic) over which the hypothetical monopoly supplier can impose the SSNIP which then provides the boundaries of the market as Yates J discusses in Australian Competition and Consumer Commission v Metcash Trading Ltd (2011) 198 FCR 297 at [247] to [251].
…
Second, as the ACCC correctly points out, the first of PN’s proposed preconditions, that the hypothetical monopolist is able to identify the customers to whom price can be increased, is not to be confused with the hypothetical monopolist test. As I have said, that test can be used in the analysis of demand-side substitution that is undertaken for the purpose of product market definition. Contrastingly, PN’s first proposed precondition is a simple question as to the feasibility of identification of the relevant users. But the hypothetical monopolist test asks whether a hypothetical monopolist who supplied the particular service at issue would find it profitable to impose a SSNIP in the order of 5 to 10% in relation to that service. If, in response to the price rise, customers would switch to acquiring other services in sufficient numbers so as to render the price increase unprofitable, those other services ought to be included in the relevant market. But this test assumes that the hypothetical monopolist could apply a SSNIP to the relevant users in relation to the relevant services, and asks whether that SSNIP would be profitable. Moreover, satisfaction of the hypothetical monopolist test does not require me to be satisfied that PN could have in the past, or could at present, implement a SSNIP to the relevant users. PN has not been in the past, and is not at present, a monopolist supplier of Rail Services in any of the relevant markets. As such, its past and present experiences have no bearing on the hypothetical monopolist test, notwithstanding that they are relevant to the analysis of whether the relevant conduct would substantially lessen competition.
1036 On appeal, in Australian Competition and Consumer Commission v Pacific National Pty Ltd (2020) 277 FCR 49, Middleton and O'Bryan JJ, and Perram J writing separately did not take issue with that description.
1037 I note that I cited Australian Competition and Consumer Commission v Metcash Trading Ltd (2011) 198 FCR 297 at [247] per Yates J who did not use the profit-maximising phraseology for the relevant SSNIP.
1038 In Re Qantas Airways Limited (2004) ATPR 42–027 at [241] the Australian Competition Tribunal said:
…Where the available competitive alternatives vary systematically as between customer types, the area over which a hypothetical monopolist may profitably impose a small but significant and non-transitory increase in price (referred to as the "SSNIP test") will be determined by reference to customer type, provided that the hypothetical monopolist is able to engage in price discrimination between the various customer groups.
1039 In Re Duke Eastern Gas Pipeline Pty Ltd (2001) 162 FLR 1 at [106] the Australian Competition Tribunal said:
…The small but significant, non-transitory increase in price analysis tests substitutability by asking whether a firm would gain or lose by attempting to impose a small but significant, nontransitory increase in price on its own product or service.
1040 In Australian Competition and Consumer Commission v Air New Zealand Ltd (2014) 319 ALR 388 Perram J referred to the profit-maximising formulation (at [220]):
… Through the lens of the HMT the relevant product market was generally the smallest collection of products or services such that a hypothetical monopolist over those products would find it profit maximising to impose a small but significant and non-transitory increase in price (a SSNIP) on at least one of the products or services.
1041 In Australian Competition and Consumer Commission v P T Garuda Indonesia Ltd (2016) 244 FCR 190, Dowsett and Edelman JJ stated at [24]:
His Honour explained the SSNIP at [220]. His explanation of the concept was not in dispute. In 1977, Professor (now Justice) Breyer summarised an early version of what is now the SSNIP test as “the notion of drawing a circle around a set of sales. Within the circle one should find sales with the following characteristic: were all those sales in the hands of a single seller, that seller would have the power to raise price significantly above the competitive level [and maximise profits]”: Breyer S, “Five Questions About Australian Antitrust Law” (1977) 51 Australian Law Journal 28 at 34. The SSNIP approach has been traced to the United States Justice Department 1892 Merger Guidelines, based on the work of Mr Werden. It has not been without controversy: Stigler GJ and Sherwin RA, “The Extent of the Market” (1985) 28(3) Journal of Law and Economics 555; Harris RG and Jorde TM, “Market Definition in the Merger Guidelines: Implications for Antitrust Enforcement” (1983) 71(2) California Law Review 464 cited in Re Fortescue Metals Group Ltd (2010) 242 FLR 136; 271 ALR 256 at [1033] (Full Tribunal).
1042 Now as is clear from the first passage, the statement of the SSNIP was not in issue in the Full Court. Further, Dowsett and Edelman JJ referred to Re Fortescue Metals Group Ltd (2010) 271 ALR 256 at [24], which adopted the profitable formulation of the SSNIP. Dowsett and Edelman JJ did not indicate that they were departing from this decision or endorsing the profit-maximising approach. Yates J, who dissented on the outcome in the appeal, framed the test as the profitable formulation, although there is nothing to suggest that Yates J was seeking to disagree with the majority judgment or the primary judgment.
1043 Let me next set out some US intermediate appellate case law examples from various circuits on the profitable versus profit-maximising formulation of the SSNIP.
1044 In United States v. American Express Company 838 F.3d 179 (2016) it was said at 198 to 199:
To define the relevant market, this Court often applies a "hypothetical monopolist test" ("HMT") asking whether a hypothetical monopolist acting within the proposed market "would be 'substantially constrain[ed]' from increasing prices by the ability of customers to switch to other producers." Todd, 275 F.3d at 202 (alteration in original) (quoting AD/SAT, Div. of Skylight, Inc. v. Associated Press, 181 F.3d 216, 228 (2d Cir. 1999)). Under the HMT, "'[a] market is any grouping of sales whose sellers, if unified by a hypothetical cartel or merger, could profitably raise prices significantly above the competitive level. If the sales of other producers substantially constrain the price-increasing ability of the hypothetical cartel, these others are part of the market.'" AD/SAT, 181 F.3d at 228 ...
The Court implements the HMT by imagining that a hypothetical monopolist has imposed a small but significant nontransitory increase in price ("SSNIP") within the proposed market. If the hypothetical monopolist can impose this SSNIP without losing so many sales to other products as to render the SSNIP unprofitable, then the proposed market is the relevant market. By contrast, if consumers are able and inclined to switch away from the products in the proposed market in sufficiently high numbers to render the SSNIP unprofitable, then the proposed market definition is likely too narrow and should be expanded.
1045 In Federal Trade Commission v. Penn State Hershey Medical Centre 838 F.3d 327 (2016) it was said at 338 and 344:
A common method employed by courts and the FTC to determine the relevant geographic market is the hypothetical monopolist test. Under the Horizontal Merger Guidelines issued by the U.S. Department of Justice's Antitrust Division and the FTC, if a hypothetical monopolist could impose a small but significant non-transitory increase in price ("SSNIP") in the proposed market, the market is properly defined. Merger Guidelines, § 4, at 7–8. If, however, consumers would respond to a SSNIP by purchasing the product from outside the proposed market, thereby making the SSNIP unprofitable, the proposed market definition is too narrow. … Important for our purposes, both the Government and the Hospitals agree that this test should govern the instant appeal. See Gov't Br. 25; Hosps. Br. 17–20.
…
… In determining the relevant market, we "look[ ] not to the contractual restraints assumed by a particular plaintiff," id. but instead, we answer whether a hypothetical monopolist could profitably impose a SSNIP.
1046 In Federal Trade Commission v. Advocate Health Care Network 841 F.3d 460 (2016) it was said at 465:
The court also heard testimony from several economic experts, including Dr. Tenn. He used the "hypothetical monopolist test" to identify the geographic market relevant to the case. That test asks whether a single firm controlling all output of a product within a given region would be able to raise prices profitably a bit above competitive levels. Economists and antitrust cognoscenti refer to such a price increase as a "SSNIP," a "small but significant [usually five percent] and non-transitory increase in price." U.S. Dep't of Justice & Federal Trade Comm'n, Horizontal Merger Guidelines 9 (2010). …
1047 In Epic Games Inc v. Apple Inc 67 F.4th 946 (2023) it was said at 975 to 976:
A market comprises "any grouping of sales whose sellers, if unified by a monopolist or a hypothetical cartel" could profitably raise prices above a competitive level. Rebel Oil Co., Inc. v. Atl. Richfield Co., 51 F.3d 1421, 1434 (9th Cir. 1995). If the "sales of other producers [could] substantially constrain the price-increasing ability of the monopolist or hypothetical cartel, these other producers must be included in the market." …
Often, this inquiry involves empirical evidence in the form of a "SSNIP" analysis. That analysis echoes Rebel Oil and uses past consumer-demand data and/or consumer-survey responses to determine whether a hypothetical monopolist could profitably impose a Small, Significant, Non-transitory Increase in Price above a competitive level.
…
In Kodak, the Supreme Court considered the question of whether a lack of market power in the foremarket (photocopier machines, generally) categorically precludes a finding of market power in the aftermarket (replacement parts for and servicing of Kodak-brand photocopiers), which Kodak had allegedly achieved by contractually limiting customers to Kodak-provided parts and services. 504 U.S. at 455, 466, 112 S.Ct. 2072. ... The Supreme Court thus folded aftermarkets into the framework for assessing markets generally, evaluating cross-elasticity of demand to determine whether a hypothetical monopolist could profitably charge a supracompetitive price. See id. at 469, 112 S.Ct. 2072. …
1048 It was said in Re Southeastern Milk Antitrust Litigation 739 F.3d 262 (2014) at 277 to 278:
… Using the hypothetical monopolist as an entity that controls all the suppliers in a proposed market, a question is posed: could a monopolist profit if it imposed a "small but significant non-transitory increase in price" ("SSNIP")? Id. Typically, the increase that is posited is five percent. Ky. Speedway, 588 F.3d at 918. If buyers in a defined area would respond to a small, lasting increase in price—a SSNIP—by purchasing from another supplier, rendering the SSNIP unprofitable, the market has been too narrowly defined. See FTC v. Tenet Health Care Corp., 186 F.3d 1045, 1053, n. 11 (8th Cir.1999) (citing Merger Guidelines § 1.21). …
1049 In Federal Trade Commission v Tenet Health Care 186 F.3d 1045 (1999) it was said at 1053:
Tenet argues that the evidence relating to "marginal consumers" shows that the merged entity would be unable to raise prices without causing the "critical loss" of enough patients to make the increase unprofitable. This "critical loss" approach is in fact employed by the FTC in its own Horizontal Merger Guidelines which are used by the FTC to ascertain a relevant geographic market in exercising its prosecutorial discretion to challenge a merger. See Department of Justice, Federal Trade Commission, Antitrust Division, 1992 Horizontal Merger Guidelines, 57 Fed.Reg. 41552 § 1.21.
1050 Now as to the literature, Professor Asker relied on P Davis and E Garcés (2009) as a standard reference. But it consistently employs the profitable formulation. Pages 201, 202 to 204, 206 to 208 and 227 are replete with such references or their analogues rather than using terminology such as profit-maximising.
1051 For example, on pp 202 and 203 it was said:
… To do this, the HMT assumes that all products within the proposed market definition are owned by one single producer which sets each of their prices in an attempt to maximize the total profits derived from them. If the hypothetical monopolist finds it profitable to increase prices, we will have found that constraints from goods outside the proposed market definition are not a sufficient constraint on producers within the market to render a price rise unprofitable. In other words, prices were kept down by the competition within the market. In practice, to operationalize this idea we must, among other things, be a little more precise about exactly what we mean by a "price rise." To that end most jurisdictions apply the "SSNIP" lest, which looks at whether a "small but significant nontransitory increase in prices" would be profitable for the hypothetical monopolist. Usually, "small but significant nontransitory" is assumed to mean 5-10% for a year.
…
… We then need to evaluate whether a monopolist of this product could profitably raise prices by 5-10% for a year. If so, that single product will then constitute our antitrust market. If not, we must include the "closest" substitute, that product which provides the best alternative to consumers facing the price increase. We then assume again a hypothetical monopolist, this time of each of the products in our newly expanded set of products in our candidate market and we repeat our question, will a 5-10% price increase for a year be profitable?" …
1052 Now Professor Asker said that the formulae below support the profit-maximising formulation. But this is not clear, as the formulae are not in and of themselves saying profit-maximising.
1053 The statement from the above extract that “[a] monopolist of product 1 will increase price as long as it raises their profits” and the immediately following formula is consistent with a profitable formulation.
1054 Now in fairness to Professor Asker, the part of the statement that he relied on is the later statement "[w]e will want to evaluate whether this inequality holds for all prices between p1Comp and p15% = 1.05p1Comp ". Now admittedly the reference in that sentence to all prices is consistent with a maximising criterion. But the formulae on the immediately preceding and following pages clearly support a profit-increasing approach as the formulae focus on the difference between the profits of a hypothetical monopolist imposing a SSNIP and the profits of a hypothetical monopolist pricing at the competitive level and whether that difference is greater than zero.
1055 So on the immediately preceding page it was said (p 204):
1056 And on the following page it was said (p 206):
1057 It was then said (p 211):
1058 And it was then said (pp 217 and 218):
1059 Further, Ms Edwards-Warren considered that in Australia the hypothetical monopolist test is normally applied asking whether a hypothetical monopolist would find it profitable or profit-increasing to raise prices by 5 to 10%. Moreover, Professor Wright, Professor Hitt and Mr Houston all agreed on the profitable formulation of the SSNIP test in the Apple proceeding.
1060 Further, the test as set out in the ACCC merger guidelines ([4.19] and [4.20]) also asks whether a price increase would be profitable and is expressed in the following terms:
The HMT determines the smallest area in product and geographic space within which a hypothetical current and future profit-maximising monopolist could effectively exercise market power. In general, the exercise of market power by the hypothetical monopolist is characterised by the imposition of a small but significant and nontransitory increase in price (SSNIP) above the price level that would prevail without the merger, assuming the terms of sale of all other products are held constant.
The process of applying the HMT starts with one of the products and geographic areas supplied by one or both of the merger parties. If a hypothetical monopolist supplier of this product cannot profitably institute a SSNIP because of customers switching to alternative products, the next closest demand substitute is added. If a hypothetical monopolist supplier of this extended group of products cannot profitably institute such a price increase because of customers switching to alternative products, the next best substitute is added. The collection of products is expanded until a hypothetical monopoly supplier of all those products could profitably institute a SSNIP.
1061 Now [4.19] merely states that the hypothetical monopolist is profit-maximising. But [4.20] states that under the HMT, one tests whether that profit-maximising hypothetical monopolist could profitably implement a SSNIP. The paragraph does not require the price increase to be profit-maximising. The perfect Platonic form of a monopolist might only profit-maximise, but I am only concerned with the imperfect and base monopolist who in the worldly realm is hypothesised to be taking (or not) a profitable step.
1062 Further, the formulation of the Continental test is to ask if a 5% or 10% increase in price is profitable.
1063 Moreover, Professor Asker’s reasoning for why he preferred the profit-maximisation formulation was problematic in any event.
1064 Professor Asker said that it is economically irrational for a hypothetical monopolist to give up profits by choosing a profitable price if an intermediate price is in fact profit-maximising. But that is not an argument for a profit-maximising formulation of the HMT as Epic points out. The HMT is a conceptual framework used to define the market. The idea is to seek to identify whether there is a significant price constraint on a given set of products, which constraint comes not from the intra-candidate market but from the availability of other products that are outside the proposed market definition and that offer viable substitutes. It is not necessary to ask what price rise a hypothetical monopolist would in fact implement when assessing whether it is price constrained.
1065 Now why am I discussing any of this? Why does it matter?
1066 Well Professor Asker’s profit-maximising approach based on a SSNIP of 5 to 10% would likely lead to a requirement that a 10 to 20% price increase is profitable. But a 20% price increase is not a small increase, and such an approach would likely lead to unrealistically defined markets.
1067 Indeed, Professor Asker accepted that asking whether a 5% price increase is profit-maximising is, under certain assumptions, the equivalent of asking whether a 10% price increase is profitable.
1068 But even a 10% price increase may be problematic in a case such as that before me being a misuse of market power case. A 5% SSNIP may be more appropriate where there is a risk of the cellophane fallacy which I have discussed elsewhere. It would seem that a small SSNIP should be preferred out of an abundance of caution when the cellophane fallacy might be in play, such as in a misuse of market power case, as Dr Rhonda Smith, University of Melbourne, has pellucidly observed.
Two-sided markets – applying a SSNIP test
1069 As was explained in L Filistrucchi et al, “Market Definition in Two-Sided Markets: Theory and Practice” (2014) 10(2) Journal of Competition Law & Economics 293, interesting issues arise when attempting to extend the SSNIP test to a two-sided market. First, given that in a two-sided market firms set two prices, one on each side of the market, the question is which price the hypothetical monopolist should be raising. Second, given that in a two-sided market there are indirect network effects between demands, and therefore profits, on the two sides, the issue is whether one should consider profits on one or both sides of the market.
1070 Now I discussed that article in detail in my reasons in Epic v Apple and I will not repeat that discussion.
1071 But in addition, in L Filistrucchi, “A SSNIP Test for Two-sided Markets: The Case of Media” (NET Institute working paper 08-34, 2008), the author highlights that the logic behind the traditional SSNIP test is to define a market as the smallest set of substitute products on which a monopolist would find it profitable in the EU (or profit-maximising in the United States) to increase prices by a small-but-significant amount. So, it is designed to ensure that the market is defined in a way that a monopolist has market power, which is a basic requirement of economic theory.
1072 To maintain the same rationale when dealing with two-sided markets, one should allow the monopolist to optimally adjust the price structure. The author also proposed some critical loss analysis formulas to perform the SSNIP test in a two-sided non-transaction market under the usual assumptions of linear or isoelastic demand and constant marginal costs.
1073 The author then argues that, while using the standard single-sided critical loss analysis formulas would lead to the definition of a relevant market that is too narrow, adopting the formulas proposed by others would lead to the definition of a market which is too large. Indeed, not allowing the price structure to be adjusted optimally would overestimate the loss in profits due to the increase in prices, because by definition the optimal adjustment by the hypothetical monopolist will tend to reduce such a loss.
Bundled products
1074 Let me say something here on the question of bundling.
1075 When products are sold only in a bundle, there can be a question as to whether they are separate products from the viewpoint of customers or whether they should be treated as components of a single product.
1076 Now as Ms Edwards-Warren pointed out, if customers are prepared to acquire each product without the other attached, and if this is technically possible, then from an economic perspective they should be treated as separate products with separate demand. If customers would only buy one of the products with the other attached, then one product is a component of the other and they should not be considered separately.
1077 Now this is a relevant consideration in this case in relation to the Play Store and Google Play Billing, given that they are effectively supplied as a bundle in Australia to app developers that monetise via Play Store in-app purchases. Google Play Billing is not available as a standalone payment solution and is not available outside the Play Store.
1078 So, when assessing the relevant markets for each of these two products, one therefore needs to consider both whether there is demand for the Play Store as a stand-alone product, that is, for app distribution services separate from payment solutions services, and whether there is demand for Google Play Billing as a stand-alone product, that is, for payment solutions services separate from app distribution services.
1079 Now Ms Edwards-Warren and Professor Asker disagreed as to whether the Play Store and Google Play Billing are correctly understood as a single product or distinct products.
1080 According to Professor Asker, the framework Ms Edwards-Warren used to make the determination that they are distinct products, namely, if customers are prepared to acquire each product without the other attached and if this is technically possible, is incomplete.
1081 He expressed the view that as a conceptual exercise, almost all products can be viewed as a bundle of their components. This is true even in cases where customers typically or always buy an integrated product (a pure bundle) rather than combine the components themselves. So, a pair of shoes is a bundle of a left shoe and a right shoe. A newspaper is a bundle of the different sections in the paper. And a car is a bundle of a chassis, an engine, safety equipment, and many other components.
1082 Now to devise relevant criteria for determining when a bundle constitutes one or multiple products, Professor Asker explored these examples in more depth in the following fashion.
1083 A newspaper may be both a single product or multiple products depending on whether it is distributed physically or electronically or both. A newspaper’s readers can have separate demand for different sections of the newspaper. Some consumers only want to read the fashion section, whilst others only want to read the business section. But there are production and transaction cost efficiencies to offering all sections of a newspaper as a bundle, depending on how the newspaper is distributed.
1084 For physical distribution, there are transaction costs to selling each section of a newspaper separately as that increases the number of products a vendor needs to price, the time to complete selling an entire newspaper, and the complexity of delivery on a paper route.
1085 This is not true for electronic distribution where readers can simply click to transact for the sections they want. This difference is reflected in the fact that physical newspapers are largely sold as a bundle, that is, all sections together, whereas newspapers online can and in some instances do offer separate subscription products for specific sections.
1086 It is natural to think of a car as a single product, and that the components of a car are not distinct products. This is because for almost all consumers purchasing a car, the components of a car are sufficiently strong complements such that no firm in a perfectly competitive equilibrium would offer an “unbundled” car, that is, a pile of parts that consumers assemble on their own, or any subset of parts.
1087 Put differently, the value to the consumer of any component of the car requires that the consumer have the other components properly assembled to have a functional car. This is also because suppliers of cars have production efficiencies, that is, an integrated assembly line, to supply an entire car rather than subsets of a car.
1088 A pair of shoes is a single product. Left shoes and right shoes are not distinct products. This is because for nearly all consumers purchasing shoes, left and right shoes are sufficiently strong complements such that no firm in a perfectly competitive equilibrium would offer an “unbundled” pair of shoes that consumers mix-and-match. This is also because a firm supplying left shoes would have strong production efficiencies to also supplying right shoes, rather than another firm incurring the fixed costs of establishing a separate manufacturing facility for right shoes.
1089 So, Professor Asker developed and deployed the following economic criteria when making this determination.
1090 His first bundled products criterion posed the question: does separate demand exist for different components of the bundle? This question asks whether the components are close complements for consumers.
1091 His second bundled products criterion posed the question: is it more efficient, that is, output expanding, to supply the components of the bundle as a pure bundle absent the challenged conduct at but-for prices? This question asks whether production efficiencies exist because of, for example, reductions in transaction costs or production costs via bundling regardless of the price charged.
1092 He expressed the view that the economic content behind these criteria is to determine whether, starting from the position that the components of the bundle are distinct products, they would be sufficiently close complements for customers or would give rise to sufficient production and distribution efficiencies for suppliers, such that in market equilibrium the components would always or nearly always be supplied as a bundle. This is because when bundling increases the value that is created by engaging in trade, firms in a competitive market will nearly always supply the components as a bundle. If the components are both close complements and give rise to supply-side efficiencies, then a bundle is all the more likely to arise as the competitive market offering.
1093 Now Ms Edwards-Warren used only the first of the two criteria Professor Asker deployed to determine whether components of a bundle are single or multiple products, that is, whether customers have separate demand for different components of the bundle.
1094 But according to Professor Asker, this is economically incomplete. A physical newspaper would plausibly have separable customer demand for different sections of the newspaper but is nonetheless always sold as a single product given the production efficiencies of doing so.
1095 But for the moment let me say that I agree with Ms Edwards-Warren that this additional criterion is not an accepted economic principle for conducting a competition assessment.
Epic’s posited Android mobile app distribution market — what is the correct focal product?
1096 As I have indicated, Epic’s case is that there is and has been at all relevant times a market in Australia for the supply of services to developers and users for the distribution of Android apps to Android device users. I will refer to this as the Android mobile app distribution market.
1097 Epic says that this is the market in which Google engages in the app developer restrictive conduct and in which that conduct has effects upon competition. And it says that it is also a market in which the OEM restrictive conduct has effects upon competition.
1098 Moreover, Epic says that it is a market in which Google has a substantial degree of power, which it leverages, not only in engaging in the app developer restrictive conduct but also in imposing the payments tie and the anti-steering rule in the Android in-app payment solutions market.
1099 Now Google disputes the existence of the Android mobile app distribution market and contends instead for markets for facilitating sales of different types of digital content, but I agree with Epic that these markets do not meet the purposive character of the market definition exercise and the need to be consistent with commercial reality.
1100 As Epic says, they are artificial, including because they are driven by the manner in which Google happens to monetise its services from time to time. Further, they do not take into account various aspects of the services in fact supplied by Google. Further, they do not accord with commercial reality.
1101 Moreover, they are not an appropriate framework within which to assess Google’s impugned conduct.
1102 Let me begin by addressing the principal issue that divides the expert economists being the product by reference to which they commenced their competition analysis, referred to as the focal product including services. And it is convenient at this point to summarise my principal views.
1103 Now the Android mobile app distribution market is the appropriate lens through which to analyse the app developer restrictive conduct and the effects of the OEM restrictive conduct.
1104 Now Professor Asker has criticised such a market based in part upon two fundamental areas of dispute between Professor Asker and Ms Edwards-Warren. The first relates to the selection of an appropriate focal product as the starting point for the market definition exercise. The second relates to Professor Asker’s econometric analysis. At the moment I will only address in detail the first matter. I will leave the econometrics until later.
1105 Now as to the first area of dispute, it must be said that I have not seriously entertained Professor Asker’s selection of the facilitation of sales of digital content as the focal product. Such a focal product is inconsistent with the commercial reality of the services Google offers developers and users via the Play Store.
1106 First, it does not capture all of the services affected by the impugned conduct, and it is inconsistent with the contractual position.
1107 Second, it does not account for all of Google’s incentives to compete, even assuming those incentives have any relevance to the selection of the focal product.
1108 Third, it is insufficiently flexible to account for Google’s ability to change its monetisation strategy at any time.
1109 These difficulties are really a manifestation of the fact that Professor Asker’s inquiry into the focal product did not properly commence with the challenged conduct, but instead with how Google monetises the Play Store.
1110 I agree with Epic that Professor Asker’s starting point is unorthodox, and results in an artificial focal product that obscures rather than elucidates the competition inquiry.
1111 Contrastingly, Ms Edwards-Warren’s identification of app distribution services as the focal product reflects the commercial reality of the core services offered by Google via the Play Store. And it is supported by the descriptions of Google’s services in the DDA and the developer program policies, as well as Google’s documents and the evidence of its witnesses. It is a sound starting point for the market definition inquiry.
1112 Now as to the second central area of dispute, Professor Asker’s primary criticism of Ms Edwards-Warren’s conclusions as to the boundaries of the Android mobile app distribution market was premised on an analysis involving the application of three quantitative methods to Fortnite revenue data to estimate diversion ratios from the Play Store in response to a change in price or quality. But I should say upfront that in my view those quantitative analyses are flawed and do not support Professor Asker’s contention that there is strong substitution away from the Play Store to console stores and PC stores. I will address these analyses in much greater detail later.
1113 Now after such analyses one is then left to consider the respective experts’ analysis of potential substitutes for the app distribution services Google provides via the Play Store. I will also address such matters in greater detail later. But it is worth noting here that I have reached the view that the only close constraint on Google’s app distribution services are other Android app stores.
1114 Now as I have said, my key conclusion is that the relevant market for analysing the effects of the OEM restrictive conduct, the app developer restrictive conduct, and Google’s market power, is the Android mobile app distribution market. The participants in that market are the Play Store and other Android app stores.
1115 But I should say that even if app distribution services provided by Apple via the App Store are a sufficiently strong constraint on Google’s app distribution services provided via the Play Store so as to warrant inclusion in the market, the relevant market would then be one that encompasses distribution of both iOS and Android apps.
1116 But even the adoption of that market would not save Google. Such adoption would not affect the conclusion that Google has substantial market power and that its conduct has substantially lessened competition.
1117 Let me now turn in detail to the identification of the focal product.
Google’s arguments
1118 There are three principal matters that Google has put against Epic’s identification of the focal product. Let me summarise its position on each aspect.
1119 Now the first matter that Google has raised is that it says that the relevant commercial agreements and the commercial structure of its operations do not support Epic’s focal product.
1120 Epic says that the fact that the focal product is app distribution services should not be controversial, because it follows from Google’s contracts with developers. But Google says that the central problem with Epic’s approach to the product which the Play Store supplies is that it is an incomplete concept of the product.
1121 The pleading refers to the product as services that enable app developers to reach, offer and provide Android device users with Android apps and updates, and that enable Android device users to be presented with and/or find, obtain and utilise Android apps and updates.
1122 But Google says that this focus only looks at part of what the Play Store supplies and ignores Google Play Billing and the fact that the Play Store does in fact facilitate transactions for purchasing digital content between users and developers.
1123 Google says that it supplies an integrated product that comprises a range of service features that include both providing a way for developers to make apps and app updates available and for users to download, install and update apps, and Google Play Billing for the benefit of users and developers.
1124 Further, the underlying DDA with developers does not support Epic’s conceptualisation of the product supplied by the Play Store. Google says that the suggestion that the Play Store merely supplies distribution services under the DDA that exclude Google Play Billing should be rejected for the following reasons.
1125 First, clause 1 defines “Google Play” as “[t]he software and services, including the Play Console, which allow Developers to distribute Products to users of Devices”. Further, the evidence shows that “Play Console” includes Google Play Billing and that it is therefore part of the Play Store service supplied under the DDA.
1126 Second, clause 3.3 of the DDA makes it clear that Google Play Billing is part of the services supplied under the DDA. It states that:
Products are displayed to users at prices You establish in Your sole discretion. If You utilize Google Play's billing system or the Play Console to control settings related to any taxes (including taxes, fees, or surcharges that are outside the scope of this Agreement) on the sale of Products, or if Google believes that Taxes may be owed by You or Google on the sale of Products, You grant Google permission to charge, collect, and discharge any such taxes as required in accordance with applicable law. …
1127 Third, clause 3.4 of the DDA provides for the payment of a service fee by the developer on products for which the developer charges a fee:
… A “Service Fee”, as set forth here and as may be revised by Google from time to time with notice to You as described in Section 15, will be calculated and charged on the sales price. …
1128 The “here” in this clause is a hyperlink to a document which describes the service fee. That document states that apps and in-app products sold through the Play Store’s billing system or an alternative billing system are subject to a service fee.
1129 At the bottom of the service fee document is another hyperlink to a 2023 document titled “Understanding Google Play’s Service Fee”. This document states that the service fee covers the cost of Google Play Billing and a range of other services supplied by the Play Store. This is clear from the following statement under the question “[w]hat does the service fee pay for?”:
The service fee supports our investments across Android and Google Play, reflects the value provided by Android and Google Play, enables us to deliver an affordable and innovative user experience, helps developers reach users and build sustainable businesses, and keeps the platform safe and secure.
1130 One of the stated investment areas under this statement is the billing system. So, the service fee is charged not only for processing payments for apps and in-app digital content sold by developers, but for the whole integrated package of features and services that the Play Store provides to developers.
1131 The fact that one service fee is charged with respect to the whole package of features supplied by the Play Store is consistent with the proposition that the Play Store supplies an integrated service that includes app discovery, app distribution and Google Play Billing, amongst many other features.
1132 So, Google says that as a matter of commercial reality and economic substance, what the Play Store supplies to developers under the DDA is an integrated product that includes features such as discovery and distribution of apps, and Google Play Billing.
1133 It says that the fact that some developers do not use all the features of the service the Play Store provides, such as Google Play Billing when developers offer free apps, does not detract from the fact that the Play Store supplies an integrated product that comprises multiple features.
1134 Fourth, Google says that whilst it is true that clause 3.2 of the DDA states that developers who wish to be paid for products distributed via the Play Store must have a valid “Payments Profile” under an agreement with a “Payment Processor”, this does not deny that the Play Store provides an integrated product that includes Google Play Billing under the DDA.
1135 Clause 1 of the DDA defines the payment processor as a “Google-affiliated entity providing services that enable Developers to receive payments for Products sold via Google Play”. In Australia, the payment processor is Google Payment Australia Pty Ltd.
1136 The agreement which users and developers must enter into with Google Payment Australia Pty Ltd is the product disclosure statement (PDS). Under the PDS, the service which Google Payment Australia Pty Ltd supplies is the “Google Payments Service”, which is an online payment processing service designed to facilitate processing of payments between purchasers, that is, users, and merchants, that is, developers. But payment processing is only part of what Google Play Billing provides.
1137 So, the fact that a separate Google entity provides the payment processing part does not mean that Google Play Billing is not part of the services supplied under the DDA.
1138 Fifth, Google says that there is some distinction between the product that the Play Store supplies as a matter of commerce, and the legal contracts which Google enters into with developers and users that govern and facilitate the supply of that product.
1139 Now it was put to Mr Feng that the legal contracts are inconsistent with the view that the Play Store supplies an integrated product that includes Google Play Billing. But Mr Feng’s view was that it is an integrated product, and that there is a distinction between the legal and the commercial dimensions. And Mr Feng considered it artificial to separate out part of the Play Store product based on the different contractual entities.
1140 Further, it is said that Mr Feng’s evidence is also corroborated by an August 2019 presentation titled “Project Magical Bridge” that he gave to Mr Samat, which conceptualises the Play Store as comprising multiple features including user acquisition, monetisation, distribution and developer tools and services. Google views the Play Store including Google Play Billing as an integrated product.
1141 Sixth, Google says that after being taken to the DDA and associated the Play Store console help pages, Ms Edwards-Warren agreed that Google charges the service fee for a range of services including Google Play Billing.
1142 It is said that she also agreed that Google supplies an integrated product for which it charges a single service fee providing both billing services and a range of other services, and does so pursuant to a contract between Google and the developer.
1143 Seventh, for the purposes of market definition, it is not in doubt that I should focus on the nature of the product supplied in a commercial sense, not some artificially constructed product based on legal form that does not accord with commercial reality or the economic substance of what is supplied.
1144 Google says that it is artificial and contrived in this case to characterise certain distribution features of what the Play Store provides to users and developers as separate and distinct from everything which Google Play Billing provides, when in a commercial sense it is one integrated product that has several features, not all of which will be used by every user or developer. And nor do they have to be for the Play Store to be characterised as a single integrated product.
1145 The second matter that Google has raised is that Google’s internal documents do not support Epic’s focal product.
1146 Google says that its documents do not describe the core service of the Play Store as making apps and app updates available to users on behalf of developers to the exclusion of Google Play Billing and every other feature that the Play Store provides.
1147 Now Epic has drawn attention to the fact that a slide deck which Mr Gennai prepared in August 2019 titled “Let’s talk about our business model” mentions that “Play makes $ (primarily IAP) through strength in its distribution”. But Google says that all that sentence says is that a high number of users will lead to a high number of in-app purchases. It says nothing about what services or features are included in the core product supplied by the Play Store.
1148 The third matter that Google has raised concerns Professor Asker’s analysis.
1149 Now Epic made three criticisms of Professor Asker’s approach. First, it said that his approach excluded all services that do not involve the transfer of money to purchase digital content, and so frustrated the analysis of competitive effects. Second, it said that his approach erroneously focused on how the Play Store monetises at the moment, which means the product dimension of the market will change if Google alters its monetisation strategy. Third, it said that Professor Asker was unable during the concurrent evidence session to justify his approach in a comprehensible way.
1150 But Google says that these points have no substance.
1151 As to the suggestion that Professor Asker excluded services for which there is no payment of money and therefore frustrated the competitive effects analysis, Google says that that is wrong for several reasons.
1152 First, the focal product of facilitation of transactions for digital content does not exclude the Play Store features such as distribution or search. The transactions facilitation service that the Play Store supplies to consumers and developers involves several features including search and discovery of content, distribution of content, intermediation of all transactions by assuming counterparty risk, and a secure billing system.
1153 Second, Professor Asker’s facilitating transactions for digital content products also does not exclude all the services with respect to free apps or apps with transactions for physical goods because of indirect network effects.
1154 In other words, because there are indirect network effects at work, the services supplied to free apps or apps with transactions for physical goods make the Play Store more attractive and support the facilitation of paid digital content transactions, and are therefore captured within the notion of facilitating transactions for digital content.
1155 Third, Professor Asker did take incentives into account, unlike Ms Edwards-Warren’s approach which excluded the incentives associated with all the Play Store revenue apart from paid app downloads, which corresponds to less than 1% of the Play Store revenue.
1156 Fourth, in any event, Google says that Professor Asker’s approach does not frustrate the approach with respect to market definition, because it ensures that there is a focus on the source of app stores’ incentives to compete, and how the conduct affects those incentives.
1157 Professor Asker explained this in his report in terms that the relevant question for evaluating market definition is to understand how a hypothetical firm’s profits would change in response to a price increase or quality reduction. He said that what disciplines the firm from doing so is the possibility that the firm would lose revenue because its customers substitute in response to the firm raising prices or lowering quality. He said that in most cases, firms charge a price or fee for the goods or services they sell, and so the relevant metric for understanding this substitution is customer spending.
1158 As to the suggestion that Professor Asker’s approach was erroneous because it focused on how the Play Store monetises at the moment, and the product dimension could change if Google were to alter its monetisation strategy, Google says that that is misconceived for various reasons.
1159 First, it says that Professor Asker gave evidence that it is normal economic practice to focus solely on the current monetisation model employed by the firm of interest.
1160 Second, it says that conducting the economic analysis based on how Google and most of its competitors makes money is a reasonable place to start because it reflects what is actually happening in the marketplace and is therefore informative of what would happen today and in realistic futures. It is a market-informed way to understand the sources of competitive pressure that exist, grounded in objective fact.
1161 Third, it says that it would be erroneous not to approach the economic analysis informed by how firms operate in the marketplace today, because as Professor Asker said, the hypothetical monopolist is still subject to the realities of the market. The fact that one firm has chosen a way to monetise is informative as to what all the real world commercial constraints are. To conclude otherwise would be to depart from commercial reality.
1162 Fourth, it says that there is nothing problematic about the fact that Professor Asker acknowledged that if the Play Store’s monetisation strategy were different, it is possible that the focal product could be different. His position seemed to be that it was not illogical that the product market could change with a change in monetisation strategy.
1163 This view reflects the fact that the question of market, especially the product market, does not necessarily admit of a unique answer. It involves value judgments and is purposive. The product market in one situation could differ from the product market in another situation, depending on the nature of the relevant competitive process and the conduct at the time.
1164 Finally, as to the suggestion that Professor Asker did not explain how he had taken into account developers who do not make sales of digital content, and was therefore evasive, Google says that Professor Asker explained how services supplied for free apps were taken into account through indirect network effects. Further, Google says that he explained that anything which supports paid digital content transactions was captured within his product market.
Analysis
1165 Now the first step in the market definition process is to identify the focal product which is supplied by Google. And as Epic points out, that requires considering the conduct being analysed, and the commercial context in which it occurs.
1166 The app developer restrictive conduct that Epic has alleged against Google in summary consists of the following.
1167 First, it consists of Google’s conduct in imposing the DDA terms on all developers who wish to distribute apps via the Play Store, including clauses 4.5 and 4.1 of the DDA.
1168 Second, it consists of Google’s conduct in imposing the developer program policies on all developers who wish to distribute apps via the Play Store, including the device and network abuse policy and the payments policy.
1169 Third, it consists of Google’s conduct in entering into the GVP agreements and the AVP agreements with certain developers, which agreements formed an addendum to each developer’s DDA and placed obligations on those developers in connection with the launch time, content, and removal of apps distributed via the Play Store.
1170 Such conduct is concerned with the terms on which Google supplies app distribution services to developers and users via the Play Store. Each of the impugned agreements is concerned with Android app distribution.
1171 The OEM restrictive conduct which Epic says has anti-competitive effects in this market is also centrally concerned with Android app distribution.
1172 The relevant MADA terms that I have been required to focus on concern the pre-installation of and default home screen placement for the Play Store which it is said ensure that the Play Store is the default choice of users for Android app distribution services and hinder the ability of rival Android app stores to compete for the provision of those services.
1173 It is said that the RSA3s incentivised the exclusive pre-installation of the Play Store and hindered the ability of rival Android app stores to compete with the Play Store for the provision of distribution services by disincentivising their pre-installation.
1174 Additionally, it is said that the technical restrictions imposed on OEMs hinder the ability of rival Android app stores to reach and supply distribution services to Android device users in competition with the Play Store.
1175 So, I agree with Epic that a consideration of the impugned conduct directs attention to the app distribution services which Google supplies via the Play Store.
1176 Let me at this point say something more about the DDA. The DDA contains several provisions which identify the nature of the services supplied by Google under the DDA.
1177 Clause 2.1 describes the DDA as an agreement in relation to the developer’s “use of Google Play to distribute Products”, that is, apps, and provides that “Google will … display and make [the developer’s] Products available for viewing, download, and purchase by users”.
1178 So, the DDA relates to the developer’s use of the Play Store’s distribution service, and obliges Google to provide distribution services, that is, it obliges Google to make apps available for viewing, download and purchase by users.
1179 Clause 3.1 of the DDA further provides that the developer appoints Google as its agent or “marketplace service provider” in order “to make [the developer’s] Products available in Google Play”.
1180 So, the relevant Google entity’s role under the DDA is to make apps available in the Play Store, that is, to distribute the developer’s apps on behalf of the developer.
1181 Further, clause 3.2 provides that the developer’s products are “distributed via Google Play”. Further, there is the statement in clause 3.3 that “Products are displayed to users” on the Play Store. Further, there is the reference in clause 3.4 to products being sold or made available to users “via Google Play”.
1182 Further, there is the authorisation granted to Google under clause 5.1 to market products on the Play Store and to provide “hosting services … to allow for the storage of and user access to the Products”.
1183 Accordingly, the terms of the DDA support the conclusion that Android app distribution is the core service provided by Google to developers and users through the Play Store.
1184 The developer program policies lead to the same conclusion.
1185 Those policies include the statement that “[t]hese Developer Program Policies, along with the [DDA], ensure that together we continue to deliver the world’s most innovative and trusted apps to over a billion people via Google Play”. There is also the statement that “[p]eople from all over the world use Google Play to access apps and games every day”.
1186 Let me turn then to some broader evidence and propositions advanced by Epic that in my view were either not contentious or could hardly be disputed.
1187 The Play Store provides a single and accessible mechanism by which developers can distribute their apps to a global audience using a click through distribution agreement. It facilitates the distribution of apps to mobile devices.
1188 The central purpose of the Play Store, from the perspective of both users and developers, is the process of getting apps from developers to users’ devices.
1189 The Play Store provides a method for app developers to make their apps available to users and enables users to download, install and update Android apps on their device.
1190 Those distribution services are provided to developers on the terms of the same DDA and subject to the developer program policies, regardless of whether the developer’s app is a free app, a paid app, or an app with in-app purchases, whether of physical or digital content.
1191 Moreover, the Play Store supplies app distribution services to users, regardless of whether they pay for the app or make in-app purchases of digital or physical goods within the app.
1192 Google has described the Play Store as an “app distribution system” and a “distribution platform”. Google has also described the services provided by the Play Store as “discovery and distribution services”.
1193 A slide deck which Mr Gennai prepared in August 2019 titled “Let’s talk about our business model” includes the following pertinent descriptions of what the Play Store does: “Android reaches lots of people + Google distributes its apps”; “Play is the preeminent app store within Android”; “[g]ame and app developers BUILD for Android and choose PLAY to reach these users”; “Play makes $ (primarily IAP) through strength in its distribution”.
1194 In cross-examination, Mr Gennai denied that “through strength in its distribution” referred to the Play Store’s ability to distribute other people’s apps, but I agree with Epic that it plainly does refer to the strength of the Play Store’s distribution service.
1195 A 2015 document co-authored by Mr Gennai titled “Google Play | The Rise of New Storefront Platforms” described the “different levels of service that a mobile app store platform (Google, Apple, Amazon) provides for its developers”, namely, discovery, distribution, business services and development services. Mr Gennai agreed that the Play Store has provided each of those services to developers throughout the relevant period. Each is an aspect of the core service, being Android app distribution.
1196 Ms Kochikar described the services that the Play Store provides directly to developers as including facilitating discovery of apps by users and app distribution. Moreover, she described the value provided by Google to developers through the Play Store, and the broader Android ecosystem, as including the maintenance of a secure distribution platform.
1197 Mr Gennai explained that, using the Play Store, users can search for or browse for apps developed by third-party developers to download and install onto their devices. He also said that distribution on the Play Store is valuable to developers in that it provides them with the ability to reach billions of Android device users around the world via a single platform, through which they can distribute apps.
1198 Mr Feng described the Play Store and Apple’s App Store as two well-known app stores for the distribution of digital content on mobile devices, and the Play Store as an app store that facilitates the distribution of apps, games, movies, TV shows and books to users of Android devices.
1199 Clearly, as Epic correctly points out, Google’s witnesses conceptualise the Play Store as supplying app distribution services.
1200 On the commercial evidence, it seems clear to me that the focal product by reference to which the competition analysis should proceed is Android app distribution services.
1201 But let me turn to the views of an economist and address Professor Asker’s approach to the focal product.
1202 Now Professor Asker accepted that the Play Store provides a way for app developers to make their apps available to users, and a way for users to download, install and update such apps. That is, he accepted that the Play Store provides app distribution services.
1203 But Professor Asker then took an additional step, being to ask whether that service is a source of competitive pressure on the Play Store. He concluded that it was not.
1204 Rather, he found that the source of such pressure was the facilitation of sales of digital content. This led Professor Asker to identify the facilitation of sales of digital content as the focal product.
1205 Professor Asker defined “facilitating sales” to mean connecting a developer and a consumer and ensuring the transfer of funds and content in the transaction.
1206 So, Professor Asker’s focal product excluded all services that did not involve the transfer of funds to purchase digital content, including the distribution of free apps without in-app purchases as well as the distribution of apps which offer in-app purchases of physical goods and services.
1207 Professor Asker said that an inquiry into the source of competitive pressure on the Play Store was necessary because identifying the focal product for the market definition exercise requires an assessment of a firm’s incentives to compete. Because firms compete to earn profit, that directs attention to how the firm monetises.
1208 His conclusions about the focal product were therefore driven by his conclusion that the Play Store primarily monetises by facilitating sales of digital in-app content, subscription or otherwise, and not from downloads.
1209 But I reject Professor Asker’s analysis for the reasons advanced by Epic.
1210 First, his analysis excludes many services that the Play Store provides and which are affected by the impugned conduct. Second, it is inconsistent with the contractual position. Third, it does not account for all of Google’s incentives to compete. And fourth, his analysis identifies a focal product based on how Google chooses to monetise from time to time, such that the focal product would change if Google altered its monetisation strategy, despite no change in the underlying services being supplied.
1211 Professor Asker’s approach also combines the separate services of distribution and the facilitation of in-app purchases into a single product.
1212 Moreover, Professor Asker’s focal product does not capture all of the services which Google provides.
1213 I have rejected Professor Asker’s focal product. It is divorced from the impugned conduct, and does not grapple with the contractual or commercial evidence as to the services in reality supplied by Google to developers and users who interact with the Play Store.
1214 Now given that the exercise of market definition is purposive, the boundaries of the market should be drawn with a view to analysing the specific conduct in question, in its commercial context, to determine whether that conduct has the substantial anti-competitive effect(s) alleged.
1215 Google’s impugned conduct affects all apps distributed by all developers to users via the Play Store, irrespective of whether developers sell digital or physical content within their apps, whether developers pay the service fee, and whether users pay for their apps or make in-app purchases.
1216 Clause 4.5 of the DDA, for example, does not apply only to developers who sell digital content. It applies equally to developers who distribute their apps for free.
1217 In contrast, Professor Asker’s market definition excluded some 96% of apps distributed through the Play Store.
1218 In my view a market definition that excludes key elements of the services supplied by Google under the DDA, being a key contract whose provisions are impugned, frustrates an analysis of the competitive effects of that conduct.
1219 Instead, the product dimension of the market must capture the services which Google provides to app developers and users under the DDA, to which its impugned conduct extends.
1220 Now whilst Professor Asker seemed to accept that market definition is a purposive concept, and that the goal of market definition in the present case is to understand the competitive effects of the challenged conduct, his analysis did not commence with the impugned conduct but, rather, with how Google monetises the Play Store.
1221 His focus on monetisation seemed to arise out of the fact that when applying the HMT, one must consider flows of profit. That is apparent from the fact that his report commenced with a consideration of the HMT and then later turned to the question of the services provided by Google.
1222 But by focusing on monetisation at the initial step, Professor Asker moved away from the orthodox approach of identifying the focal product prior to considering substitution alternatives.
1223 Instead, Professor Asker’s approach used the HMT logic to define the focal product itself.
1224 A firm’s incentives to compete are relevant to the question of substitution, that is, the application of the HMT, not to the identification of the focal product by reference to which the substitution analysis is to occur. It is an approach that is inconsistent with his own concession that implementing the HMT presupposes that an economist has a candidate product in mind.
1225 Professor Asker was not able to justify that approach during the concurrent evidence. The following exchange with me identified the difficulty:
HIS HONOUR: I’m just trying to work out – there are two ways to look at it. You look at the conduct and then work out what market definition best conceptually explains the conduct and its competitive nature, and if you start from the other end of trying to work out the competitive nature and retrofit that back to the conduct and try and fit the conduct back into that.
PROFESSOR ASKER: So I think - - -
Q: Are you saying the latter or the former?
A: I’m saying somewhere between the two, in the sense that if I might suggest, if we were doing a merger between Ford and Toyota, we wouldn’t spend an enormous amount of time on exactly how, potentially, car dealers work. But if we were doing a case relating to the vertical arrangements between Ford and car dealers, that would be entirely sensible.
1226 The first methodology that I identified is the plain vanilla Australian approach.
1227 The second, retrofitted methodology is the approach which Professor Asker took. His inability to accept that, and his reliance upon an irrelevant example about car manufacturers, was indicative of his overall difficulty in justifying the approach that he took.
1228 The result of Professor Asker’s retrofitting approach is the identification of a focal product that does not extend to all of the subject conduct, which includes services provided by Google to developers who distribute apps via the Play Store, and users who download apps from the Play Store, where there is no sale of digital content at all.
1229 The fact that the impugned conduct extends to apps being provided for free was put to Professor Asker during the concurrent evidence session. But as Epic rightly says, Professor Asker did not offer any coherent explanation as to how that aspect of Google’s conduct fits within his analysis.
1230 Now I also agree with Epic that Professor Asker’s approach is inconsistent with the contractual position.
1231 The exercise of defining a market miscarries when that exercise is used to construct, or deconstruct and reconstruct, the supply of a service in a manner divorced from the commercial context of the putative contravention which precipitates the analysis. The analysis of market definition and market power must reflect the reality of the contractual arrangements under which services are provided.
1232 The “service” provided by Google under the DDA is expressly said under clause 3.1 to be “mak[ing] [a developer’s] Products available in Google Play”. As clause 3.2 states, that service is provided in respect of “Products that users can access for free and Products that users pay a fee to access”.
1233 It is inconsistent with the contractual regime to separate the services provided by Google under the DDA into separate and distinct segments, insofar as those same services facilitate the distribution of free apps, or in-app sales of physical goods and services, or sales of digital content versus monetised apps. The DDA contemplates the same services being provided in respect of all “Products”.
1234 Further, Professor Asker’s focus on the facilitation of sales of digital content is in tension with the fact that under the contractual arrangements none of the Google entities responsible for distributing apps through the Play Store supplies the services which facilitate the payments made by users to developers, or is a party to the contract between the developer and user by which a developer’s digital content is sold.
1235 Professor Asker accepted that these are transactions between a developer and a user.
1236 Defining the focal product by reference to a transaction to which no Google entity is a party, and which is not part of the service supplied under the DDA, involves a further departure from the impugned contractual arrangements.
1237 Further, to describe the Play Store as supplying a single service of facilitating (or intermediating) sales of digital content between consumers and developers is also inconsistent with Google’s own descriptions of the service it provides via the Play Store in its internal documents, which focus upon app distribution.
1238 I agree with Epic that those documents are a better guide to the commercial reality of the service which Google provides than any theoretical analysis by Professor Asker.
1239 Let me now turn to the question of monetisation and Professor Asker’s obsessive focus on how Google monetises the Play Store.
1240 Now I agree with Epic that it is because Professor Asker’s analysis started with the HMT rather than with the product or service being supplied that Professor Asker came to identify the facilitation of sales of digital content as the focal product.
1241 The essential problem with that emerged in the concurrent evidence session, where it became clear that Professor Asker’s approach meant that the product dimension of the market would alter if Google changed its monetisation strategy, even though the underlying service supplied by the Play Store did not change and the impugned conduct did not change.
1242 Consider a scenario where Google reduced its commission rate from 30% to 20%, but increased the price it charged for search ads by 50%. That scenario is consistent with changes Google considered making to its monetisation targets in 2019.
1243 In this scenario, applying Professor Asker’s “monetisation” criterion, the focal product with which Professor Asker’s analysis started would change.
1244 The focal product would be expanded to include the services in respect of search ads which Google provides to any app, whether including in-app purchases or not.
1245 And the focal product would continue not to capture any services provided by Google in respect of free apps if those developers do not purchase search ads.
1246 Consider now a scenario where Google reduced the commission charged to 10%, but required all developers to pay a flat fee of a specified amount when their app is made available for distribution. That hypothetical is also consistent with changes Google previously considered.
1247 In that scenario, the focal product with which Professor Asker’s analysis started would expand to include services which Google provides in respect of all apps, because the flat fee applies to all developers, and so Google monetises the services provided to all app developers.
1248 Professor Asker conceded that it is an empirical reality that Google could change its monetisation targets. Indeed, that possibility was central to his effects analysis. Yet that possibility is unaccounted for in his identification of the focal product.
1249 On Professor Asker’s logic, if Google were to adopt any of those alternative monetisation strategies, the focal product would change. Yet in circumstances where the services that Google supplies are unchanged, and the impugned conduct is unchanged, in each of the hypotheticals set out above the starting point for market definition analysis should not change.
1250 Professor Asker’s initial tentative acceptance of that proposition, followed by a later rejection of it demonstrated his fixed and mistaken approach.
1251 I also agree with Epic that another feature of Professor Asker’s analysis is that, following his logic, Professor Asker is led to identify multiple different markets comprising Google’s distribution services insofar as they facilitate sales of digital gaming content, Google’s distribution services insofar as they facilitate sales of physical goods and services, Google’s distribution services insofar as they facilitate other free apps, Google’s services insofar as they generate revenues through search ads, and additional markets for Google’s services insofar as they facilitate sales of different types of non-gaming digital content.
1252 This is so despite the fact that precisely the same conduct is the subject of analysis across each of Professor Asker’s markets, and Google provides the same services across each market. The artificiality of such a conclusion is immediately apparent.
1253 Further, Professor Asker’s focus on Google’s competitive incentives in identifying the focal product was misguided.
1254 But even if such an approach were justified, Professor Asker’s version was incomplete. His analysis was premised on an unduly narrow characterisation of the incentives driving Google’s behaviour, for two reasons.
1255 First, Professor Asker’s focus on the sales of digital content ignored the material value non-paying developers and users present to Google by reason of network effects.
1256 Non-paying developers provide app diversity and innovation, in turn attracting more users. More users mean more views for advertising, and also more opportunities for in-app purchases to be made, both of which earn revenue for Google.
1257 More users in turn mean more developers will distribute via the Play Store as those developers want access to users, many of whom will pay the service fee and thereby contribute to Google’s revenue.
1258 Further, every time network effects are increased in this way, this builds on Google’s market power because it heightens the barriers to entry for a new app store.
1259 So, Google gains significant benefits via network effects from attracting and retaining non-paying developers and users. That is demonstrated by Google’s investment in non-paying developers and users by distributing those developers’ apps to users without charge, and by offering features of the Play Store relating to search, review and security.
1260 Now the provision of those services involves costs. But Google would not incur those costs unless it considered attracting and retaining non-paying developers and users to be of commercial benefit.
1261 Further, Google itself recognises the importance of network effects in its internal documents.
1262 In an internal Google presentation titled “Amazon Competitor deep dive – Apr. 2017”, the speaking notes record that:
Play benefits from network effects.
Users come to Play because we have by far the most compelling catalogue of apps / games
Developers come to Play because that’s where the users are.
1263 An undated internal Google document titled “Strategic developments” states that:
2. App and game developers
The app and game ecosystem is a virtuous circle: better apps and games make Android more attractive to users, while more users increases the attractiveness to developers for investing in Android. To keep the virtuous circle, we need to continue supporting developers, with the goal of making Android the most profitable platform for their apps / games.
1264 Now Professor Asker accepted that the Play Store is a multi-sided platform that is characterised by network effects. He also recognised that attracting non-paying developers and users improves the competitiveness of the Play Store.
1265 He noted that the service fee supports the Play Store providing free services for many developers and apps that likely confer substantial value to consumers, and supports the competitiveness of the Play Store.
1266 And he noted that a platform that attracted no one would have no competition within the platform. Sellers on a platform need to have consumers to compete over.
1267 Moreover, Google competes with other Android app stores across the full range of services provided through the Play Store.
1268 Clearly, Google seeks to attract all developers and users, not just paying ones, and all such customers drive Google’s competitive incentives and constraints.
1269 But such incentives are ignored in Professor Asker’s identification of the relevant focal product for his analysis.
1270 Second, Professor Asker’s focus on the sales of digital content ignored the material proportion of revenue Google derives from the Play Store through routes other than in-app purchases of digital content.
1271 Some [REDACTED] of the revenue Google earns via the Play Store is through advertising on the Play Store itself. Advertising is therefore a significant means through which Google monetises the app distribution service it provides through the Play Store. Through such advertising, developers obtain greater discoverability and, therefore, greater prospect of their apps, whether free or paid, being downloaded.
1272 Considering the focal product through the paradigm of Google’s profit-incentives would require the focal product to extend to advertising. Professor Asker’s only justification for his exclusion of advertising was that Epic’s allegations in this case “focus on service fees and not on ad-revenues from search placement”.
1273 This demonstrates the difficulty with Professor Asker’s approach. Had he started with the conduct that is the subject of the proceeding, the drawing of such fine distinctions about which money-making opportunities he does and does not consider would be unnecessary.
1274 Further, I agree with Epic that Professor Asker was evasive when pressed on how he had grappled with the fact that Google’s impugned conduct extended beyond developers offering in-app purchases and therefore extended to services not encompassed within the focal product.
1275 Further, at no point did Professor Asker explain how he had considered developers who were subject to the DDA but who do not make sales of digital content within their apps and therefore do not fall into Professor Asker’s market definition.
1276 Further, Professor Asker sought to make reference to consumption-only apps when dealing with his focal product.
Conclusion
1277 For the above reasons, the facilitation of sales of digital content, be that gaming content or non-gaming content, cannot be adopted as the focal product for the purposes of defining a market to analyse the effects of the OEM restrictive conduct and the app developer restrictive conduct.
1278 Such a focal product is detached from commercial reality, fails to account for Google’s incentives to compete, and results in an unstable market definition.
1279 In my view the focal product is the supply of app distribution services to developers and Android device users.
1280 Let me now turn to the next topic concerning the HMT.
The experts’ approaches to HMT quantitative and qualitative analysis
1281 Detailed qualitative and quantitative evidence was led by the parties concerning the use and application of the HMT and related topics. Part of the quantitative evidence analysed data relevant to the Fortnite hotfix and removal event and diversion ratios. Detailed analysis was also addressed to logit demand modelling, transition probability analysis and ultimately critical loss analysis including the Lerner index.
1282 Now a formal HMT requires estimating cross-price elasticities or a complete set of diversion ratios in response to a hypothetical price increase for each product in the relevant candidate market(s) as well as considering the economic margins for these products.
1283 But in the context before me, this required more data than was available. Specifically, there was a lack of systematic information about how developers responded to changes in app store pricing and quality.
1284 But economists can still use the framework of the HMT to weigh candidate market(s) even when the necessary information to implement a formal HMT is absent.
1285 With information on alternatives available to, and used by, customers of the hypothetical monopolist, one can use the best available evidence to evaluate whether, in response to a price increase, customers would have an incentive to switch to rivals and one can determine whether evidence indicates that doing so is relatively easy. And this evaluation of incentives and ease of switching can be used to draw inferences as to whether the hypothetical monopolist’s price increase would likely be defeated.
1286 Now the key evidence needed under the framework of the HMT is the degree of customer substitution. And this can be measured empirically if one has the appropriate and available data. Now in the context before me some data was available to assess customer substitution along certain dimensions, but such data was limited in other respects. And to overcome these limitations Professor Asker performed other quantitative analyses.
1287 But before proceeding further, let me introduce some concepts that I will develop in much greater detail later.
Critical loss analysis
1288 In the absence of complete data on cross-price elasticities and margins required for a complete quantitative HMT, an empirical tool that economists can use to determine whether a candidate market is a well-defined market, but underpinned by the principles of HMT, is a critical loss analysis.
1289 A critical loss analysis first establishes a critical loss threshold that would make a price increase by the hypothetical monopolist unprofitable, and then determines whether actual losses from that price increase would be higher or lower than the critical loss threshold.
1290 In essence, critical loss answers the question: if the hypothetical monopolist raises the price of one product in the candidate market by X%, what percentage of the sales of that product would need to be lost, that is, not recaptured by the hypothetical monopolist’s other products, for the price increase to be unprofitable?
1291 In its standard formulation, critical loss is expressed as a threshold that is a function of the percent increase in price, X, and the firm’s margins, M. The standard formulation of the critical loss threshold is expressed as a fraction where the numerator is X and the denominator is X plus M. This means that the critical loss threshold increases with a higher price increase and decreases with a higher margin. Actual loss answers the question: if the hypothetical monopolist raises the price of one product by X%, what percentage of sales of that product would be lost due to the price increase?
1292 Let me also couch this concept in profit maximising terms as Professor Asker has done.
1293 Critical loss analysis starts by asking the following question: would a hypothetical monopolist of the candidate market find it profit-maximising to increase the price of one of its products, say Product A, by at least X %? The profit-maximising price increase is at least X % if an increase of twice the size (2X %) is profitable. This occurs when the actual loss in sales, for a 2X % price increase, is less than what is called the critical loss threshold.
1294 To determine the actual loss in sales, one must balance two competing effects. On the one hand, by increasing the price, the firm will lose customers from Product A. On the other hand, the firm, as the hypothetical monopolist, can recapture some of those lost consumers through the other products it owns, that is, everything else in the candidate market except Product A. The amount of lost Product A sales can be calculated using consumer elasticity, where the elasticity can be imputed using the Lerner index. The amount of recapture can be calculated using an aggregate diversion ratio, that is, how much is diverted to all other products in the candidate market.
1295 Critical loss analysis is typically evaluated by estimating an aggregate diversion ratio.
1296 An aggregate diversion ratio answers the question: if the hypothetical monopolist raises the price of one product, what fraction of lost sales of that product does the hypothetical monopolist recapture by other products it owns?
1297 Calculating an aggregate diversion ratio for a hypothetical monopolist of Android app stores would answer the question: what fraction of sales that divert from the Play Store in response to an increase in the Play Store’s prices are recaptured by other Android app stores?
1298 Now the advantage of such an analysis is that it requires a parsimonious set of parameters to understand when a candidate market is a well-defined market being the aggregate diversion ratio from the product of interest to other products in the candidate market, the margin for the product of interest, and the hypothetical percent increase in the price of the product of interest.
1299 A critical loss analysis usually evaluates a 10% price increase by the hypothetical monopolist, as that corresponds to the hypothetical monopolist finding it profit-maximising to increase prices by at least 5%.
1300 Now a standard critical loss analysis that compares aggregate diversion ratios to the critical loss threshold is predicated on the Lerner index. The Lerner index relates a firm’s margins to the elasticity of customer demand it faces. Obviously the more price-sensitive consumers are, the smaller margins a firm can sustain.
1301 Now to perform a critical loss analysis Professor Asker used the diversion ratios calculated based on the hotfix regression specifications, which is a method of conducting the HMT quantitatively. But it only considers the hypothetical monopolist raising prices on one product, rather than all products in the market, as would be required under the HMT.
Diversion ratios
1302 Let me say something about diversion ratios, which were calculated and/or analysed by the experts based upon the Fortnite removal event as a result of the Fortnite hotfix.
1303 Professor Asker’s analysis involved three quantitative methods applied to Fortnite revenue data to estimate diversion ratios from the Play Store in response to a change in price or quality.
1304 First, he used a difference in differences analysis which purported to measure the extent to which Fortnite revenue was diverted from the Play Store to other channels following the removal of Fortnite from the Play Store.
1305 Second, he used a logit demand model which estimated diversion ratios based on data about consumer spending prior to the removal.
1306 Third, he used a transition probability analysis which estimated diversion ratios based on data about consumer spending prior to the removal.
1307 Fourth, Professor Asker also counted up the various estimates of diversion, in particular diversion from the Play Store to the Samsung Galaxy Store, and used the results in his critical loss analysis to support his conclusion that the Android mobile app distribution market proposed by Ms Edwards-Warren was too narrow.
1308 Now Google’s thesis is that the spending patterns in the Fortnite spend data before and after the hotfix illustrate that non-mobile platforms are substitutes for the Play Store when it comes to users executing transactions for app-based digital content.
1309 Professor Asker considered that this pattern of spending indicates that Android and the Play Store Fortnite users are able to substitute their spending to non-mobile transaction venues such as consoles and PCs, because the data shows that in practice this is what they in fact do.
1310 Google said that a significant percentage of the reduction in the Play Store spending was diverted to other platforms including non-mobile platforms. It is said that this shows that non-mobile platforms are substitutes for the Play Store as digital content transaction venues.
Logit demand modelling
1311 Now the purpose of the logit demand model is to generate diversion ratios, and the purpose of diversion ratios is to inform substitution, which is the basis for defining relevant markets.
1312 The logit demand model translates observed consumer choices among a viable choice set into estimates of diversion and substitution. The architecture of the logit demand model means that diversion is proportional to spending shares. If consumers choose one transaction venue more than another out of the available choice set, the logit model says that there will be more diversion to that transaction venue.
1313 Now Professor Asker used the logit demand model in the present context to derive a measurement of diversion to the iOS App Store which was not possible from available natural experiments like the hotfix. Diversion estimates from Professor Asker’s logit model exercise were said by Google to corroborate diversion estimates from the analysis of the hotfix.
1314 The logistic model, typically referred to as the logit model, is a popular model in modern industrial organisation economics. It belongs to a group of economic models called discrete choice models which economists use to explain how agents choose one option from a set of alternatives, often referred to as the choice set. So, an economist can use the logit model to analyse purchase data from the cereal aisle of a grocery store, including the prices, number of boxes bought, and characteristics about each cereal available, to estimate how price sensitive consumers are and the substitution patterns between cereals.
1315 Choice sets must exhibit several properties for a discrete choice model to be appropriate for a given setting. First, the alternatives must be mutually exclusive, choosing one option means that none of the other alternatives are being chosen. Second, the choice set must include all relevant alternatives to the decision maker. Last, there must be a finite number of alternatives. In practice, economists include an alternative referred to as the “outside option” in the choice set. The outside option typically represents the option not to purchase any available alternative. So, it can represent a consumer choosing to not to spend their money or purchase another option not in the choice set.
1316 With that general introduction to the concepts out of the way, let me return to Professor Asker’s quantitative framework and how he dealt with data limitations.
Professor Asker’s quantitative analysis
1317 Professor Asker accepted that in practice one cannot perform a full empirical or quantitative SSNIP test due to limitations on data availability. Instead, one has to evaluate other types of evidence such as functional substitutability, evidence on customer purchase drivers and evidence on past switching or threats to switch to inform a hybrid qualitative and quantitative application of the HMT.
1318 Now whilst Professor Asker agreed with Ms Edwards-Warren that there were limitations on data availability that prevented performing a full quantitative SSNIP test, he disagreed with her that the available data was sufficiently lacking so as to require the use only of a wholly qualitative application of the HMT. He said that detailed data did exist that allowed one to do the following.
1319 First, one could estimate switching rates, including net switching rates and gross churn rates, between iOS and Android smartphones so as to contextualise those rates in comparison to other products Australian consumers commonly interact with.
1320 Second, one could calculate diversion from Android smartphone models to iOS smartphones based on elasticity estimates from academic literature in combination with available data to understand the closest competitive constraints facing Android smartphones.
1321 Third, one could estimate diversion from the Play Store to determine which rivals were the Play Store’s closest competitors.
1322 Fourth, one could quantify the prevalence of multi-homing by developers and consumers across transaction venues that facilitated their ability to substitute across these venues.
1323 Fifth, one could conduct a variety of other quantitative analyses that informed whether and to what extent customers of a hypothetical monopolist would substitute in ways that would discipline the hypothetical monopolist.
1324 Now Professor Asker relied on three related quantitative analyses to support his findings of a market for the facilitation of digital sales of games apps.
1325 First, he relied on a critical loss analysis which he claimed disproved that there is a narrower market that only includes Android app stores.
1326 Second, he relied on an event study which analysed customer purchasing behaviour before and after the Fortnite hotfix on 13 August 2020, on which he concluded that console stores are closer competitors to the Play Store than rival Android app stores.
1327 Third, he relied on a logit demand model through which he claimed to estimate consumer diversion, which also showed that Play Store Fortnite users are substantially more likely to divert Play Store spending to console stores, PC stores and the Apple App Store than to rival Android app stores.
1328 Now Ms Edwards-Warren did not conduct these analyses but focused primarily on how comparable potential substitutes are from a functional perspective. She also focused on conceptual discussions of switching costs.
1329 Now although Professor Asker agreed with Ms Edwards-Warren that qualitative evidence including functional substitutability can in some circumstances be informative, he was of the view that placing too much weight on such evidence could lead to problematic conclusions of overly narrow markets.
1330 Professor Asker’s view was that in the present case, detailed quantitative data existed that was informative as to market definition.
1331 Let me say something about Professor Asker’s specific approach concerning multi-homing/switching and demand system modelling. As he explained, economists typically use two quantitative approaches to empirically evaluate whether two products are substitutes. The first approach involves the estimation of multi-homing, switching or substitution, and the second approach involves demand system modelling. Professor Asker used both approaches in the present context.
1332 Let me say something about estimates of multi-homing, switching, and substitution.
1333 Estimates of multi-homing and switching typically take the form of summary statistics. These estimates do not require a triggering event, that is, a change in price or quality, to properly estimate. One can contrast this with substitution where there is switching in response to a price or quality adjustment.
1334 Multi-homing and switching statistics are calculated from data on consumer spending on the products over time. So, with data on how consumers spend on Fortnite across transaction venues over time, it is possible to construct estimates of Fortnite user multi-homing and switching across these venues.
1335 Now estimates of substitution rely on variation and natural experiments. This is because estimates of substitution require a triggering event such as a change in price or availability. This triggering event is provided by the natural experiment.
1336 A natural experiment is when an exogenous event changes the environment in which individuals, families, firms, or cities operate. This change occurs due to external factors, for example, institutional rule changes, policy changes and natural phenomena. This change occurs in such a way that some people are exposed to the change being the treatment group, and some people are not exposed to the change being the control group. These features of natural experiments permit one to identify causal relationships as opposed to correlations.
1337 Typically, when evaluating whether a candidate natural experiment would permit causal inference, economists evaluate whether the event is exogenous. By this, economists mean that the event itself is uncorrelated with any unobserved determinants of the outcome of interest.
1338 So, as an exogenous example, app stores may raise prices when they think customers would not meaningfully respond, for example, because a rival app store has already raised its price, and so analysing customer responses to such a price increase would underestimate the magnitude of substitution. A natural experiment would avoid this flaw and allow researchers to estimate the causal effect of the change on a given outcome of interest, here, consumer substitution.
1339 A standard natural experiment analysed by economists to understand substitutability concerns the entry or exit of a firm’s or a rival’s products.
1340 Under certain circumstances, the entry or exit of a firm’s or a rival’s products can safely be treated as exogenous. So, for example, unexpected plant closures due to extreme weather conditions can be used as a natural experiment to analyse substitutability between the affected and unaffected products. Likewise, competition agencies have utilised the entry and exit of stores when defining relevant markets in the context of grocery retail level mergers.
1341 Now whilst such analyses examine the effect of removing or adding a product rather than a change in price, the diversion ratios estimated from these analyses are regarded as reasonable approximations to those estimated with price changes.
1342 Let me say something about demand system modelling. Under certain modelling assumptions, observable market outcomes like shares of sales associated with each product in a candidate market can be informative as to the underlying consumer demand.
1343 A workhorse demand model used by economists is the multinomial logit, which is more simply known as the logit model. As I have already indicated, a logit model captures consumer decision-making over discrete choice options. Each consumer is assumed to make a single choice over distinct products. The model structures consumer utility over these options as a function of the product’s price and other observable and unobservable characteristics, with consumers choosing the product that yields the most utility to them.
1344 By placing certain assumptions on the unobservable characteristics, the model derives expressions for elasticity ratios and diversion ratios that are ratios of market outcomes like shares of sales.
1345 Professor Asker used the logit model to contextualise consumer spending when determining relevant markets.
1346 Let me draw out some other themes of Professor Asker’s evidence.
Professor Asker’s qualitative analysis
1347 Now Professor Asker said that to supplement quantitative approaches in a context where available data is limited, economists also rely on qualitative evidence to determine the nature and degree of competition between rivals. And economists use qualitative evidence to draw conclusions about relevant markets in several ways.
1348 First, qualitative evidence on technical or functional substitutes to the products offered by the firm engaging in the challenged conduct can inform reasonable substitutability, and so narrow the set of potential products to evaluate in a candidate market. Technical or functional substitutes refer to products that offer similar uses to customers. The products which are substitutes in use are sometimes known as the set of functional substitutes.
1349 Second, qualitative evidence like internal company strategy documents or public financial reports can be useful to determine which products and rivals a firm views as a competitive threat, and how they respond to this competition. So, internal strategy documents can describe the competitive responses that the firm engaging in the impugned conduct took in response to competition from rivals.
1350 Third, competitive responses to rivals in terms of pricing and innovations are evidence of competition with those rivals.
1351 Fourth, one can also use survey evidence to draw inferences about market definition.
1352 Now usually the use of surveys for market definition is confined to retrospective buyer surveys that question a firm’s customers as to what products the buyers currently use or used in the past. Such retrospective surveys can be informative as to switching rates and multi-homing. When there have been past changes in price or quality, and those changes are plausibly exogenous, then retrospective surveys could also reveal changes in customer behaviour that is indicative of substitution.
1353 Contrastingly, surveys that focus on why customers made certain purchasing decisions, or what features of products customers found salient when they made a purchase, may be less informative as to how such customers would respond to price increases or reduced quality.
1354 Now Professor Dhar used such survey evidence to draw conclusions as to whether Android smartphone purchasers valued the quality of app stores and the availability and pricing of apps when purchasing their device. Ms Edwards-Warren relied upon Professor Dhar’s survey evidence to support her conclusion that the iOS App Store and Play Store are not in the same relevant market.
1355 Further, hypothetical questions in surveys are generally viewed as less reliable for understanding substitution when detailed evidence on actual purchasing behaviour exists. Economists instead typically analyse revealed preference, that is, choices revealed in real-world data. Contrastingly, asking survey respondents how they would respond given a hypothetical price increase or quality reduction without real-world consequences or incentives may not elicit accurate responses.
1356 More generally, Professor Asker expressed the view that when appropriate data exists for quantitative empirical estimation of substitution, economists usually weigh such quantitative evidence more heavily than qualitative evidence. Moreover, the importance of quantitative evidence is higher when addressing questions about the degree to which effects were substantial, which are more appropriately addressed through quantification. In such situations, qualitative evidence is usually used to supplement these data-driven approaches.
Ms Edwards-Warren’s approach
1357 Now Ms Edwards-Warren’s starting point for her market definition inquiry was the product, the customers who use the product and the conduct in question. This is because market definition exercises are purposive. The aim is to assess the effect of particular conduct in a market.
1358 The correct starting point for assessing market definition is the good or service supplied or acquired by the relevant firm and its close substitutes and to consider the functional dimension of the market. I have already identified the focal product.
1359 Now Ms Edwards-Warren assessed six potential substitutes to Android mobile app stores that she identified being the pre-installation of individual apps on Android devices, the direct downloading of individual apps on Android devices, web apps including streamed web apps, app distribution services on non-Android devices, app distribution services on PCs and app distribution services on consoles.
1360 The first three are potential substitutes, for which users do not have to switch devices, whilst the next three are potential substitutes for which users would have to switch devices. I have discussed elsewhere the six potential substitutes, and the extent and closeness of substitution (if any).
1361 With respect to each potential substitute, Ms Edwards-Warren assessed evidence on functional substitution, switching costs, both financial and non-financial, switching rates and quantification of the prevalence of multi-homing by developers and consumers. She considered multi-homing by app developers and consumers across the Play Store and the Apple App Store, developer multi-homing with PCs and consoles, and user access to PCs by smart mobile device users, and access to consoles. I have discussed some of Ms Edwards-Warren’s evidence on switching in my reasons in Epic v Apple.
1362 On the basis of her evaluation, Ms Edwards-Warren concluded that the relevant market was for Android app stores, that is, Android mobile app distribution. She considered each substitute separately and concluded that developer and/or user switching to each substitute in response to a SSNIP would be very limited. On this basis she also considered that total switching to all six substitutes would be insufficient to enlarge the market.
1363 In summary, Ms Edwards-Warren evaluated qualitative and quantitative evidence to inform a qualitative application of the HMT. Further, she also analysed Professor Asker’s analyses and gave her view as to where she saw the difficulties.
1364 Ms Edwards-Warren considered that there were a number of difficulties with Professor Asker’s quantitative analysis.
1365 First, she considered that the critical loss analysis suffered from methodological flaws and relied upon the flawed diversion ratios calculated by the hotfix analysis. But even if one accepted the methodology and inputs, the results were mixed and suggested that either there is an Android mobile app distribution market or that this market should be extended to include direct downloads but no wider. In her view the analysis did not support the market definitions put forward by Professor Asker under any scenario.
1366 Second, the Fortnite hotfix on 13 August 2020 was not a clean event that would have caused consumers to switch their purchases to another distribution channel. Any user that had downloaded Fortnite via the Play Store prior to 13 August 2020 could still both play and purchase V-Bucks in that version of Fortnite, at the same price as on other platforms. The only change was that they paid via EDP rather than via Google Play Billing. It was not until 27 August 2020 when a new season of Fortnite was available that users needed to switch to other platforms.
1367 Third, in her view the switching that was identified in Professor Asker’s analysis was generated by a flaw in the way the analysis was designed. She found that if one re-ran the same codes on other randomly selected dates, one would find substantively the same results.
1368 Fourth, in her view the results of the Fortnite hotfix analysis could not be generalised to all games apps. Professor Asker claimed that the fact that most of the top 25 games apps on the Play Store have cross-wallet and cross-progression functionalities meant that users have the same substitution options as Fortnite users. But of those top 25 games apps, only two are actually available on consoles.
1369 Fifth, as for Professor Asker’s logit demand model, it essentially estimated diversion ratios based on revenue market shares, in which the market had already been assumed to include the Apple App Store, PC stores and console stores. So, in her view the results of the logit model were driven by the starting assumptions.
1370 So, the fact that the highest switching is to consoles is by the design used by Professor Asker. Consoles account for the highest share of revenues in this pre-assumed widely defined market and therefore switching to consoles is the highest.
1371 Now Professor Asker said that the hotfix event is what economists call a natural experiment and from the perspective of Fortnite users, the removal of Fortnite from these two app stores corresponds to the exit of a transaction venue.
1372 And it was on the basis of these three analyses that Professor Asker concluded that the relevant markets in which the Play Store compete is the markets for facilitating sales of digital gaming content. Indeed, these three analyses were fundamental to his overall findings and for broadening the market for facilitating sales of digital gaming content to include PC, consoles and the Apple App Store.
1373 But in Ms Edwards-Warren’s opinion, these analyses were not determinative for market definition and/or the results were misinterpreted.
1374 First, and as I have said, she was of the view that the critical loss analysis of Professor Asker was flawed in relation to its design, implementation and interpretation. But even if one accepted the methodology and inputs, the results were mixed and suggest that either there is an Android mobile app distribution market or that this market should be extended to include direct downloads, but no wider. In her view, the analysis does not support the market definitions put forward by Professor Asker under any scenario.
1375 Second, in her view and as I have said, the Fortnite hotfix was not a clean natural experiment and should not be described as the exit of a transaction venue, as from the user perspective very little changed. Smart mobile device Fortnite users were able to continue to play, and to make in-app purchases at the same price as via other transaction venues after 13 August 2020. And in her view there were various other conceptual and analytical flaws with the analysis. She gave evidence that if one re-runs Professor Asker’s analysis on three placebo dates prior to the hotfix, the analysis produces substantively the same results, thus demonstrating that it is not the hotfix event driving them.
1376 Third, in her view and as I have said, the logit model that was described by Professor Asker essentially assumed the answer to the question that it purported to answer. In her view this analysis said nothing significant about market definition that has not been pre-assumed.
1377 Let me also identify some other differences between the experts.
Functional substitutability
1378 Professor Asker said that Ms Edwards-Warren’s approach to defining markets was incomplete given the primacy she gave to analysis of functional substitutability. But this does not accurately reflect what she did. She identified a candidate market, and then assessed each of the potential substitutes that she identified from the Google witness statements.
1379 Her starting point for each assessment was functional substitutability. She then considered evidence of switching and other relevant evidence available to her, both quantitative and qualitative. She then reached her conclusions based on her assessment of all of this evidence.
1380 Now qualitative evaluation is usually the starting point of any market definition exercise. And it is appropriate to start with the product characteristics and the intended use(s) of the product. Doing so allows one to define a broad and plausible set of possible demand substitutes. The products which are substitutes in use are the set of functional substitutes.
1381 So, Ms Edwards-Warren did not give primacy to analysis of functional substitutability, over and above other types of evidence. But she did consider it a necessary step of the market definition exercise to understand which other products fulfil the same functional purpose as the focal product, in line with the best practice described above.
1382 Now Professor Asker said that Ms Edwards-Warren ignored relevant empirical evidence on substitution. Professor Asker listed five categories of “rich data” in this case relevant for the application of the HMT and said that she did not conduct these analyses and that she ignored this available data. But Ms Edwards-Warren disagreed with the accuracy of that assessment.
1383 As to switching rates, Ms Edwards-Warren analysed switching rates. But she did not analyse net switching rates and gross churn rates or benchmark them against other industries because she considered them to be uninformative for market definition.
1384 Further, as to diversion ratios from Android to iOS smartphones based on academic literature, she did not analyse this, but she explained why the calculations based on those datasets by Professor Asker were inaccurate, biased and did not support the conclusions drawn from them.
1385 Further, as to the diversion from the Play Store to other platforms using Fortnite hotfix data, she did not consider this informative for market definition.
1386 Further, as to the quantification of the prevalence of multi-homing by developers and consumers, she analysed multi-homing by app developers and consumers across the Play Store and the Apple App Store. She also analysed developer multi-homing with PCs and consoles, and user access to PCs by smart mobile device users and access to consoles.
1387 Now a variety of other quantitative analyses can inform whether and to what extent customers would substitute in ways that would discipline the hypothetical monopolist.
1388 In addition to quantification of switching rates and multi-homing, Ms Edwards-Warren relied on other quantitative evidence where there was data available.
1389 So, she analysed Google Android and iOS smart mobile device prices when evaluating substitution between licensable and non-licensable OSs, and the number and share of new app downloads by source when assessing the constraint direct downloading imposes on distribution via Android app stores.
The interpretation of rates of switching
1390 Another evidentiary issue on which Ms Edwards-Warren disagreed with Professor Asker was the interpretation of rates of switching that occur in the ordinary course of business, that is, customer churn.
1391 This is relevant in the assessment which they both conducted of switching by users between Android smartphones and iOS smartphones. The question of interest is the extent to which users would switch away from Android to iOS in response to a small increase in the price, or small decrease in quality, of the operating system, or in response to a small increase in the Play Store service fee, should it result in an increase in app prices.
1392 Since they could not directly observe this happening, they both analysed studies of user switching between phones with the Google Android OS and iPhones.
1393 She agreed that switching rates are distinct from, but informative about, substitution, because switching rates do not measure changes in behaviour that can be causally attributed as responses to changes in price or quality.
1394 But Ms Edwards-Warren disagreed with two aspects of the reasoning of Professor Asker.
1395 The first aspect was that she did not agree that the incremental switching in response to a price increase would be higher than the base level of switching. When conducting a HMT, one is interested only in the incremental switching driven by the price increase, not the base level of switching and the increment. The base switching rate is informative about whether consumers find switching easy in which case, all else being equal, customer churn will be high, or not. That is, the base switching rate is informative about the ability of consumers to switch. But if say 10% of customers switch from one product to another on an annual basis, this does not mean that the same proportion or a greater proportion of customers would switch in response to a small price increase.
1396 The base level switching is driven by many factors including changes in the product price or quality, consumer income, and dissatisfaction with service. So, Ms Edwards-Warren disagreed with Professor Asker’s conclusions.
1397 The second aspect was that she disagreed with the interpretation of switching levels in other industries as set out by Professor Asker. There is no benchmark level of churn above which products are in the same market and below which they are not.
Usage and spending data
1398 Let me at this point say something about usage and spending data.
1399 Now Professor Asker said that the relevant question for evaluating market definition is to understand how a hypothetical firm’s profits would change in response to a price increase or quality reduction. In most cases firms charge a price for the goods or services they sell, and so the relevant metric for understanding customer substitution is customer spending.
1400 Professor Asker said that economists consider usage in addition to or in lieu of spending when evaluating markets if there is lack of data on spending and usage is a proxy for spending, and when a firm does not monetise by charging a price.
1401 Ms Edwards-Warren agreed that when implementing a HMT quantitatively one is primarily interested in where customers switch their expenditures in response to a price increase. But a hypothetical monopolist will take into account where customers switch their volumes if it affects where the same customers or other customers switch their expenditures.
1402 If spend data is not available, then volumes or usage can be a proxy to assessing substitutability. This is the case if customers switch their volumes or usage, for example, play time of a game, to the same alternatives as they switch their expenditures in response to a price increase.
1403 Where revenue or spend data was available and robust, Ms Edwards-Warren used it.
1404 So, she used it when assessing spend on the Play Store by app and purchase types, supply shares of operating systems, the cross-availability of apps across the Play Store and the Apple App Store, and the impact of the Fortnite removal event on payment solutions.
1405 To the extent that she relied upon volume or usage data it was because she judged that the analysis could not be carried out robustly with value data, for example through lack of availability, or because it was otherwise relevant.
1406 The two analyses that Professor Asker criticised her for having relied upon usage data are the following.
1407 Professor Asker criticised her focus on how consumers and developers use the Play Store when discussing functional substitutability. Her analysis of whether a potential substitute performs similar functions to the focal product was informative about whether a developer or user is likely to switch both their usage and their expenditure to that potential substitute.
1408 Further, Professor Asker criticised her reliance on the analysis of Professor Goldfarb. Professor Goldfarb conducted analysis using usage data, which is relevant for understanding consumer behaviour and substitution patterns. Ms Edwards-Warren recognised that implementing a HMT quantitatively, which is something Professor Goldfarb was not instructed to do, requires assessing spend.
1409 With respect to market definition involving the Play Store, it is important to note that approximately 96% of developers do not pay a service fee for app distribution services.
1410 The choices of the non-fee paying developers will have an impact on the choices of the fee-paying developers, because they generate positive externalities from being on the same platform. I have referred to these elsewhere when discussing network effects.
1411 So, Professor Asker was incorrect when he said that spending is a sufficient statistic to evaluate competitive constraints facing the Play Store. He was also incorrect when he said that when data on spending is available, there is no reason to evaluate usage.
1412 Let me now turn to a more general matter concerning some aspects of principle.
Professor Asker’s five HMT principles
1413 Now Professor Asker said that Ms Edwards-Warren made several implementation errors when deploying the HMT that resulted in her defining improperly narrow markets. Professor Asker defined five implementation principles for the HMT which he said that he subscribed to, but Ms Edwards-Warren had not conformed to.
1414 Let me identify these principles and Professor Asker’s criticisms. I might say that Ms Edwards-Warren agreed with most of these principles putting to one side for the moment an issue that arose between the experts concerning the difference between taking a profitable step as distinct from a profit maximising step.
1415 There is a difference between profit-maximising and profit-increasing, and I have addressed this in more detail elsewhere.
1416 Ms Edwards-Warren considered that a HMT involves assessing whether a small, typically 5% or 10%, price increase would be profitable, with care needed to ensure that one does not define over-wide markets due to the cellophane fallacy. This is how a quantitative SSNIP test is conducted, but that was not possible in this case.
1417 Absent a quantitative SSNIP analysis, one assesses the evidence on each substitute and considers whether there appears to be sufficient switching to them either individually or collectively.
1418 The first HMT principle was to the effect that the hypothetical monopolist of the candidate market is to be taken as not controlling any products outside that market. Now a failure to adhere to this principle may mean that substitution to products outside the candidate market that the hypothetical monopolist is “incorrectly” assumed to own may not discipline the hypothetical monopolist. This may result in an improperly defined market.
1419 Now Professor Asker said that for the purposes of analysing a price increase by a hypothetical monopolist, the terms of sale of products outside the candidate market are held constant. But Professor Asker said that Ms Edwards-Warren made an error by assuming that a hypothetical monopolist over an Android app distribution market controls the payment solution which Ms Edwards-Warren viewed as a distinct product.
1420 But this is not a correct interpretation of what Ms Edwards-Warren did.
1421 Professor Asker claimed that by assuming a Play Store service fee of 30% Ms Edwards-Warren was including Google Play Billing. But Ms Edwards-Warren was hypothesising an increase in the app store service fee, and that the app store service fee is at most 30% of the value of in-app purchases. This is because she did not know what the prices of the Play Store and Google Play Billing would be if they were unbundled, but she could assume that neither would exceed 30%. Her analysis was explicitly taking an upper bound for the app store service fee for illustrative purposes.
1422 But in any event, Professor Asker’s criticism is inconsequential. If Ms Edwards-Warren had assumed that the app store service fee was 26% or 27%, as advanced by Professor Asker, her conclusion that a small increase in Android app store service fees would have a small impact on the average user expenditure relative to the cost of switching smart mobile devices would be unchanged. This is because a 5% or 10% increase in Android app store service fees would be even smaller when applied to a lower service fee figure, for example, 26% or 27%, than to a 30% fee.
1423 The second HMT principle was to the effect that a proposed market fails the test if the hypothetical monopolist would not find it profit-maximising to raise prices (or worsen quality) by at least 5% given sufficient substitution to all possible rivals. So, this principle states that even if no potential substitute sufficiently constrains the prices of the hypothetical monopolist on its own, one should consider whether collectively all possible substitutes in aggregate provide a constraint, and then consider which of those should be included in the market.
1424 This second principle enshrines the idea that iteratively applying the HMT to each individual rival or different groups of rivals and determining that they would not discipline the hypothetical monopolist on their own is not informative as to whether all the rivals together could discipline the hypothetical monopolist.
1425 Now a failure to adhere to this principle means that the HMT sought to be applied does not consider total substitution away from the hypothetical monopolist and so leads to inappropriately defined markets.
1426 Professor Asker said that Ms Edwards-Warren made this implementation error when defining all three of her proposed markets. But Ms Edwards-Warren concluded that developer and/or user switching to each of six potential substitutes in response to a SSNIP would be very limited. On that basis she also considered that the total switching to all six of them would also be insufficient to enlarge the market.
1427 The third HMT principle was to the effect that sufficient substitution from the hypothetical monopolist that would lead it to not find it profit-maximising to raise prices or worsen quality can arise from partial substitution by a subset of customers. Now a failure to adhere to this principle means that the HMT ignores substitution that could discipline the hypothetical monopolist, that is, every dollar that could substitute away. This leads to inappropriately defined markets.
1428 Professor Asker said that Ms Edwards-Warren made this implementation error when defining all three of her proposed markets. He said that she focused on complete substitution that requires customers to switch away all their purchases from the hypothetical monopolist but did not consider partial substitution by customers. He said that Ms Edwards-Warren made this error despite accepting that when assessing whether it would be profitable for a hypothetical monopolist to raise prices by a small amount, or reduce quality or worsen contractual terms more generally, it is not necessary that all customers switch away or that customers switch away all of their purchases for the small price increase to be unprofitable.
1429 Now Ms Edwards-Warren agreed that partial substitution by a subset of customers can in principle constrain a hypothetical monopolist if the substitution is sufficient and if the hypothetical monopolist cannot price discriminate towards that subset of customers.
1430 But she did not take account of partial substitution in her assessment of market definition involving GMS Android because, as she saw it, OEMs could not substitute some of their devices away from GMS Android to Android forks. But she did take into account partial substitution in her assessment of market definition involving the Play Store.
1431 The fourth HMT principle was to the effect that the relevant time frame for evaluating substitution from the hypothetical monopolist will vary based on the lifecycle of the products considered and can be several years in duration for durable goods. But for products with short lifecycles and high user churn, examining substitution over short time periods is appropriate. For products with longer lifecycles where users replace products every few years, examining substitution over longer time periods is appropriate.
1432 A failure to adhere to this principle means that the HMT would evaluate substitution over inappropriate time windows and lead to inappropriately defined markets.
1433 Professor Asker said that Ms Edwards-Warren made this implementation error when defining the proposed mobile OS licensing market. She considered narrow time frames when evaluating whether consumers would substitute to iOS devices and the iOS App Store. He said that despite conceding that the average lifecycle for mobile devices is typically more than three years, she did not evaluate substitution over a period of at least that length. This understated substitution.
1434 Now Ms Edwards-Warren agreed that the relevant time frame depends on the type of product and on how quickly consumers can switch. And in applying the HMT, she accepted that the time frame considered affects two elements.
1435 First, it affects the expected cost of switching to customers. She agreed that customers would likely take into account the expected lifetime cost of a product when switching. They would most likely value spending today more highly than spending in two years’ time, therefore applying some discount rate.
1436 Second, it affects the time frame over which customers are likely to switch away.
1437 Now as she said, it is not the case that one has to assume a time frame over which every single customer could switch away. This is not appropriate, because a hypothetical monopolist, when considering whether to increase prices, would take into account whether some customers may or may not switch for a long period of time. In any event, she considered this criticism to be inconsequential, as using a longer or shorter time frame did not affect her overall conclusion.
1438 Now more specifically Professor Asker criticised Ms Edwards-Warren for overstating switching costs faced by consumers when switching from Android to iOS smartphones and misinterpreting evidence on switching because she had not assessed switching over an appropriate time frame of three to four years. But Ms Edwards-Warren disagreed with this and said that a hypothetical monopolist when deciding whether to increase prices would take into account the fact that some customers will switch immediately and some would not switch immediately.
1439 Finally, the fifth HMT principle was to the effect that it is more appropriate to evaluate candidate markets that contain closer substitutes to the firm’s product than weaker ones. Professor Asker said that a well-known challenge with the framework of the HMT is that the relevant markets defined using the framework can be sensitive to the order in which rivals’ products are evaluated.
1440 He said that consistently with the goal of market definition being to better evaluate the effects of the challenged conduct by narrowing the focus to the most relevant competitors and substitute products, one should ensure that the products of the closest competitors to the challenged firm are included in the candidate markets to evaluate using the HMT.
1441 Now Professor Asker said that Ms Edwards-Warren made this implementation error when defining the proposed mobile OS licensing market and Android mobile app distribution market. Professor Asker said that this was evident in the fact that she included the licensable OS Sailfish in her proposed OS market whilst she excluded iOS, and in the fact that she included Android app stores like Aptoide in her proposed Android mobile app distribution market whilst she excluded webstores, console stores, PC stores, and the iOS App Store.
1442 Now Ms Edwards-Warren agreed with this fifth HMT principle, but she disagreed with the conclusions of Professor Asker about which were the closest substitutes to the Play Store and the Android OS.
1443 Now in my view Professor Asker’s criticisms of Ms Edwards-Warren are misplaced. There are of course differences between them which I will come to in discussing the detail of some of the quantitative analyses. But Professor Asker’s so-called implementation or methodological errors as such which he has attributed to Ms Edwards-Warren are not made out.
1444 Let me now turn to the detail and begin with the topic of the Fortnite removal event and diversion ratios.
Fortnite removal event and diversion ratios
1445 Let me begin by saying something about diversion ratios, which were calculated and/or analysed by the experts based upon the Fortnite removal event as a result of Mr Sweeney’s hotfix strategy.
1446 Professor Asker used three quantitative methods applied to Fortnite revenue data to estimate diversion ratios from the Play Store in response to a change in price or quality.
1447 First, he used a difference in differences analysis which purported to measure the extent to which Fortnite revenue was diverted from the Play Store to other channels following the removal of Fortnite from the Play Store. I will discuss the legitimacy or otherwise of this approach in this part of my reasons.
1448 Second, he used a logit demand model which estimated diversion ratios based on data about consumer spending prior to the Fortnite removal event. I will discuss such a model in a separate section of my reasons.
1449 Third, he used a transition probability analysis which estimated diversion ratios based on data about consumer spending prior to the Fortnite removal event. Again I will discuss such an analysis in a separate section of my reasons.
1450 Fourth, Professor Asker also counted up the various estimates of diversion, in particular diversion from the Play Store to the Samsung Galaxy Store, and used the results in his critical loss analysis to support his conclusion that the definition of the Android mobile app distribution market was too narrow. I will also discuss this critical loss analysis in a separate section of my reasons. As I have already indicated, a critical loss analysis is underpinned by the principles of HMT and is the essence or central theme of Professor Asker’s analysis, with the diversion ratios used as a necessary input.
1451 Now Google’s thesis is that the spending patterns in the Fortnite spend data before and after the hotfix illustrate that non-mobile platforms are substitutes for the Play Store when it comes to users executing transactions for app-based digital content. This is said to be the case by Google for various reasons that were said to be justified by Professor Asker’s quantitative analysis.
1452 Professor Asker considered that the relevant pattern of spending indicated that Android and the Play Store Fortnite users were able to substitute their spending to non-mobile transaction venues such as consoles and PCs. It was said that the data shows that in practice this is what they in fact do.
1453 Google said that a significant percentage of the reduction in the Play Store spending after the removal event was diverted to other platforms including non-mobile platforms. It is said that this shows that non-mobile platforms are substitutes for the Play Store as digital content transaction venues.
1454 Now as Epic correctly identified, there are two interrelated questions that arise in relation to Professor Asker’s quantitative analyses. First, is quantitative analysis in relation to a single app, Fortnite, informative for market definition more generally? Second, assuming quantitative analysis concerning Fortnite is informative, what does that analysis show?
1455 Now Epic says that Professor Asker’s difference in differences regression analysis of diversion of Fortnite spending following the hotfix suffers from various flaws. As a consequence it over-estimates total diversion. It says that Professor Asker inappropriately used a levels difference in differences analysis rather than the percent approach deployed by Professor Goldfarb.
1456 Further, as to the relevant time frame(s) used by Professor Asker, Epic says that retaining the week of the hotfix (10 August 2020) and the two subsequent weeks (17 and 24 August 2020) in Professor Asker’s analysis was inappropriate. Further, it says that adopting a 5-week post-period rather than the 13-, 26- and 52- week post-periods was not the preferable approach.
1457 Before proceeding further, I should say something more about the Fortnite hotfix and removal event.
1458 As I have discussed elsewhere, on 13 August 2020 Epic activated a hotfix on the Fortnite app available through both the Play Store and the App Store which presented users with a choice for purchasing V-Bucks either through Google’s or Apple's own payment solution or through EDP.
1459 At the same time, Epic introduced the “Fortnite Mega Drop”, being a permanent 20% discount for Fortnite in-app purchases on mobile, PC and console platforms. But users were not eligible for such discounts if they chose to use Google's or Apple's payment solution.
1460 On the same day, Fortnite was removed from the Play Store and the App Store, and since 13 August 2020, Fortnite has not been available for download from, or updating via, the Play Store or the App Store.
1461 At or about the same time, users of Fortnite downloaded from the Play Store and the App Store were informed that they would not be able to play a new season of Fortnite when it was released on 27 August 2020.
1462 Now smart mobile device users who had already downloaded Fortnite through those app stores were able to continue playing the version of Fortnite they had downloaded, and to make in-app purchases at the same discounted price via EDP on their smart mobile device as on other platforms. The main change was that smart mobile device Fortnite users could not re-download or update Fortnite through those app stores. Moreover, as I have indicated, users would not be able to update the Fortnite app downloaded from the Play Store and the App Store when a new season was released on 27 August 2020.
1463 Now the Fortnite removal event could be described as, or giving rise to, a natural experiment. Professor Asker said that from the perspective of Fortnite users, the removal of Fortnite from the relevant two app stores corresponded to the exit of a transaction venue(s), although Ms Edwards-Warren took issue with this characterisation.
1464 Now Professor Asker focused on Fortnite users who spent on the Play Store during the four weeks before the hotfix. Professor Asker excluded Fortnite users who had spent on the App Store during the same time period from both the treatment and control groups.
1465 Professor Asker analysed where those users made in-app purchases during the five weeks after the hotfix. He defined this five-week period after the hotfix as the period between 10 August 2020 and 13 September 2020. But this “after hotfix” period included three days prior to the hotfix, which occurred on 13 August 2020.
1466 Professor Asker considered that the diversion ratios estimated from switching that occurred in the five weeks after 13 August 2020 would be the same as those estimated from a small change in price or quality.
1467 Now to put the hotfix diversion analysis in context, I should note the following matters.
1468 First, Professor Asker and Ms Edwards-Warren agreed that analysis of substitution and diversion, including natural experiments and critical loss analysis, can be informative about market definition.
1469 Second, Professor Asker and Professor Goldfarb agreed that the removal of Fortnite from the Play Store is a natural experiment, they agreed that estimates of diversion in response to that event are informative and can be used to draw general conclusions as to substitution by consumers across devices and transaction venues, and they agreed that a difference in differences regression estimation strategy is a well accepted method, but that in some instances the suitability of a levels or percent approach may differ although in other instances it may not matter which approach is utilised.
1470 Third, Professor Asker and Professor Goldfarb agreed that diversion is central to market definition because it is closely related to substitution. Substitution is defined as the percentage change in quantity purchased from a firm in response to the firm raising prices or worsening quality by a small amount. Diversion measures the fraction of the sales a firm loses due to a small increase in price or decrease in quality that are recaptured by another firm’s product. Of course the two concepts are related such that higher diversion to another firm’s product means that that product is a closer substitute.
1471 Fourth, Professor Asker and Professor Goldfarb agreed that to estimate diversion empirically usually requires a triggering event, being a change in price or quality.
1472 Now I should note here that both Professor Asker and Professor Goldfarb used similar study designs to measure diversion. They used a specification where the treatment group consisted of users that played or spent on Fortnite via the Play Store (the treatment group), and the control group included users that did not do so and played or spent via alternate transaction venues (the control group).
1473 Now in order to appreciate the materiality of the methodological debates between the experts and to identify the diversion estimates that are significant for market definition, it is necessary to note the way in which the diversion estimates are sought to be used.
1474 First, the diversion from the Play Store to other Android app stores, most notably the Galaxy Store, is an input into Professor Asker’s critical loss analysis, which as I have already indicated is a form of quantitative HMT that Professor Asker has used to evaluate Epic’s candidate Android mobile app distribution market. As I say, I will discuss this critical loss analysis later.
1475 Second, the diversion from the Play Store to console stores relative to diversion to sideloading or other Android app stores is said to be informative as to whether console stores or other Android transaction venues impose closer competitive constraints on the Play Store, which indicates the next closest substitutes to be included in the market if the candidate market fails the HMT.
1476 Third, the diversion from the Play Store to all other Android transaction venues relative to all non-Android transaction venues is also said to be informative as to whether Android or non-Android transaction venues impose the greater competitive constraint on the Play Store, and indicates whether those venues provide meaningful competitive constraints for the Play Store.
1477 But I should note, more generally, that what matters is not the total amount of diversion from the Play Store, but the relative diversion to available choices.
1478 Now I should also note that Professor Asker and Professor Goldfarb presented numerous different sensitivities for estimating diversion from the hotfix. I will return to these diversion estimates later.
1479 Let me now turn to some of the evidence of Ms Edwards-Warren and Professor Goldfarb. In doing so and conveniently, I will pick up the salient aspects of Professor Asker’s evidence.
Ms Edwards-Warren’s evidence
1480 Ms Edwards-Warren disagreed with Professor Asker’s perspective on the Fortnite hotfix event. In her view, the hotfix should not be described as the exit of a transaction venue, as from the user perspective very little changed. Smart mobile device Fortnite users were able to continue to play, and to make in-app purchases at the same price as via other transaction venues.
1481 Ms Edwards-Warren considered that because from the perspective of smart mobile device Fortnite users little changed on 13 August 2020, the hotfix did not give these users an incentive to switch to other “transaction venues”.
1482 So, Ms Edwards-Warren considered Professor Asker to be erroneous in attempting to estimate substitution of user spend following the hotfix event and subsequent removal of Fortnite from the Play Store on 13 August 2020, in order to estimate how Fortnite users would substitute in response to a small change in relative prices.
1483 Now Professor Asker concluded that the Fortnite hotfix analysis demonstrated that there was more switching by Play Store users to consoles than to other Android app stores. But Ms Edwards-Warren said that this result was due to an error in the analysis, being a poorly defined control group.
1484 To demonstrate this, she re-ran the same analysis around three different “placebo” dates, being 4 June, 18 June, and 9 July 2020, and she found substantively the same results, being that diversion to consoles was significantly higher than switching to Android app stores. This demonstrates that the result was not driven by the Fortnite hotfix on 13 August 2020, but was due to errors in the analysis. I should say that Professor Asker sought to explain this away, but I was not completely convinced.
1485 She said that another error in the model is that the “after period”, selected to be 10 August 2020 to 13 September 2020, contained an actual event that did give users an incentive to switch, and this event contaminated the results of the Fortnite hotfix analysis of Professor Asker.
1486 On 27 August 2020, a new season of Fortnite was launched. From this date onwards, users were affected by the removal of Fortnite from the Play Store, because they could not update their apps to get the new season. At this point in time switching might have occurred in response to essentially a large degradation in quality. This happened in the middle of the “after” period of Professor Asker, but was not controlled for in the analysis.
1487 Further, in her view the Fortnite hotfix analysis was conceptually incorrect given that the event on 13 August 2020 did not result in an option being removed, or indeed a price change, for users. In her view the hotfix on 13 August 2020 did not reflect a forced diversion of users from the Play Store and the App Store to other “transaction venues” due to a “complete removal” as characterised by Professor Asker.
1488 Generally, Ms Edwards-Warren was of the view that Professor Asker was erroneous in attempting to estimate substitution of user spend following the hotfix event and subsequent removal of Fortnite from the Play Store in order to estimate how Fortnite users would substitute in response to a small change in relative prices.
1489 Let me elaborate further on some of her evidence.
1490 Now Ms Edwards-Warren identified what she said to be analytical errors in Professor Asker’s approach.
1491 Professor Asker’s analysis found that there was switching by users of their expenditure to other platforms after 13 August 2020. Ms Edwards-Warren considered that it is unclear why the hotfix itself should have driven user switching, so she investigated why Professor Asker’s analysis found that users switched. She considered it possible, for example, that Epic publicly challenging Google’s policies around the time of the hotfix might have affected user behaviour and therefore could have driven the findings of Professor Asker, although ultimately she concluded that the findings were driven by errors in his analysis.
1492 If the public challenge had led to user switching, this would not be a good approximation for developer and user response to a price increase, because she would not expect other developers to publicly challenge Google in the same way.
1493 In her opinion the most likely reason is that Professor Asker’s analysis relied on a poorly defined control group.
1494 Professor Asker conducted difference-in-differences regressions across a four-week period before and a five-week period after the hotfix event.
1495 This is a standard data analysis methodology, and the aim of such analysis is to compare how behaviour of a control group compares with a treatment group and to eliminate the effect of potentially confounding variables, for example, common trends that affect both groups.
1496 But Ms Edwards-Warren did not agree that Professor Asker’s analysis achieved this for the following reasons.
1497 Professor Asker defined the treatment and control groups as follows. He excluded Fortnite users who had spent on the App Store during the same time period from both the treatment and control groups.
1498 The treatment group was Fortnite users who spent on the Play Store during the four weeks before the hotfix. The treatment group included users who spent on the Play Store only, as well as users who spent on the Play Store and other transaction venues. It excluded Fortnite users that spent on Fortnite downloaded from the App Store in this period.
1499 The control group was defined as Fortnite users who only spent on Fortnite from non-Play Store and non-iOS sources during the same time period, being four weeks before the hotfix.
1500 For the analysis to be meaningful, the behaviour of the control group has to be a good approximation of the behaviour of the treatment group. This is known as the parallel trend assumption.
1501 Professor Asker presented no evidence that his chosen control and treatment groups experienced similar trends in user spend. And he presented no evidence that changes in spending by both user groups are similar.
1502 A common method of demonstrating if the parallel trend assumption holds, and therefore whether the chosen treatment group is appropriate for accounting for confounding effects, is to compare the differences between the chosen control and treatment groups before the event occurs that affects the treatment group. If such differences are stable over time, the chosen control group can be said to follow a similar trend to the treatment group.
1503 So, Ms Edwards-Warren compared the evolution of weekly average spend of users in the chosen control and treatment groups of Professor Asker. Her figure 11 below presents this comparison in Australia for user spend on the PlayStation, during the same time period chosen for the hotfix analysis by Professor Asker.
1504 The figure above shows that average weekly user spend of the treatment and control group of Professor Asker’s analysis evolved differently over time. During the “before” period (non-shaded area), average user spend in Australia on the PlayStation for the treatment group ranged between USD 1.16 and USD 1.80, but between USD 3.41 and USD 5.98 for the control group.
1505 To better assess if user spend of the treatment and control group users in Professor Asker’s analysis follow similar trends, Ms Edwards-Warren examined the difference between average weekly spend of both groups, that is, the difference between the light and dark blue lines in figure 11 above.
1506 If both sets of users’ expenditures follow similar trends over time, she would expect these differences to remain relatively similar each week before the hotfix.
1507 Ms Edwards-Warren’s figure 12 below presents the evolution of these differences in Australia for user spend on the PlayStation, during the same time period chosen for the hotfix analysis by Professor Asker.
1508 The figure above shows that the difference between average weekly spend, on the PlayStation, of treatment and control group users in Professor Asker’s analysis in Australia does not remain stable over time. During the “before” period (non-shaded area), the difference in average spend between both sets of users differed by as much as 86%, which is calculated as the difference between the minimum difference, being USD 2.25, and maximum difference, being USD 4.18, divided by the minimum difference.
1509 These comparisons suggest that the control group chosen by Professor Asker does not satisfy the parallel trends assumption required for a differences-in-differences analysis and cannot account for any confounding effect on user spend over time. Now Professor Asker said that his analysis was robust as to this assumption, but again I was not convinced as to this.
1510 Ms Edwards-Warren’s view, which I accept, was that such analytical errors in the analysis will lead to unreliable and uninformative results.
1511 Ms Edwards-Warren had other criticisms.
1512 Putting aside the above errors of Professor Asker’s analysis, to further illustrate the point that Professor Asker’s hotfix analysis was not in fact estimating diversion, Ms Edwards-Warren re-ran the exact same analysis but centred around three different dates, being 4 June, 18 June, and 9 July 2020. These dates were randomly selected amongst possible dates where a similar analysis spanning nine weeks would still fit within the time period where Fortnite was available on the Play Store.
1513 Running Professor Asker’s analysis on these “placebo” dates, when there is no reason to expect Fortnite user diversion in spend, generates similar results to the hotfix analysis. That is, the results on these dates also show much higher switching to consoles than the Galaxy Store. Ms Edwards-Warren’s table 13 below presents the diversion ratios estimated based on the regression analyses around the three placebo dates globally excluding China.
1514 The table above shows that in the three placebo analyses, diversion ratios indicate a substantial pattern of user spending diverting from the Play Store to console stores. In particular, diversion ratios from all three placebo analyses indicate higher switching to consoles than to the Galaxy Store.
1515 Because Ms Edwards-Warren generated substantively similar results to Professor Asker using placebo dates, which had no competitive significance, that is, where no change in user behaviour was expected on Fortnite downloaded from the Play Store, this provided further support for her conclusion that Professor Asker’s analysis was flawed and not capable of providing information about diversion of spend in response to a small or large change in prices or quality. So, it is uninformative for market definition.
1516 Now Professor Asker sought to explain away the placebo date conclusions, but I was not convinced.
1517 Further, even taking the results of Professor Asker’s analysis as given, Ms Edwards-Warren found a number of errors and inconsistencies in the interpretation of the results.
1518 First, diversion in response to an extreme event will not necessarily be informative in this case about diversion in response to a smaller event.
1519 Second, Professor Asker assumed that switching, as a proportion of the total lost user spend on the Play Store, following the removal of an option is equivalent to switching following a small change in price or quality. He said that while the hotfix event resulted in the complete removal of Fortnite from the Play Store and the App Store, and so does not correspond to a 5% change in the price or quality of the Play Store or the App Store for Fortnite users, it is nonetheless informative for analysing substitution for the purposes of market definition.
1520 But Professor Asker then contradicted this assumption when criticising Ms Edwards-Warren’s own analysis of the Fortnite data, which was limited to analysing whether users switched from Google Play Billing to EDP after the hotfix which led to Play Store in-app purchases made through EDP being 20% cheaper than when made through Google Play Billing. Professor Asker said that a major issue with Ms Edwards-Warren’s analysis was that consumer behaviour when faced with a 20% price reduction is uninformative about behaviour in response to a smaller price change.
1521 Ms Edwards-Warren disagreed that one can assume that diversion in response to an extreme event such as the Fortnite removal equates to diversion in response to a more limited change, being a small change in price or quality. And she did not make that assumption.
1522 This assumption requires that all users spending on Fortnite behave in the same way. But there is evidence that Fortnite spenders are heterogenous, which implies that this assumption may be incorrect.
1523 Third, the fact that Epic reduced prices across all platforms simultaneously does not, contrary to the claim made by Professor Asker, suggest that Epic views them as substitutable transaction venues. On the contrary, if the other platforms were substitutable transaction venues, then there would have been limited value to Epic in either distributing via the Play Store in the first place, or in implementing the hotfix.
1524 Fourth, Professor Asker did not consider whether the limited switching to the Galaxy Store or direct downloading might itself be a function of the relevant Google conduct.
Other matters
1525 In Ms Edwards-Warren’s view, another error in Professor Asker’s model was that the “after period”, selected to be 10 August to 13 September 2020, contained an actual event that gave users an incentive to switch, and this event contaminated the results of Professor Asker’s Fortnite hotfix analysis.
1526 Now as I have said, on 27 August 2020, a new season of Fortnite was launched. Users that had previously downloaded Fortnite from the Play Store or the App Store had to either continue playing the previous season or switch to an alternative platform in order to download the new season of Fortnite.
1527 So, the new season launch on 27 August 2020 represented a decrease in the quality of Fortnite for players playing the old version downloaded from the Play Store relative to players who had downloaded the app from other sources. At this point in time it was feasible that those users, being the ones analysed by Professor Asker, switched both playtime/usage and in-app purchasing spend to another platform on which they could access the new season of Fortnite.
1528 So, the launch of the new season was an exogenous event or natural experiment that may have caused diversion of spend.
1529 But because this event occurred part way through the “after period” in Professor Asker’s analysis, being the five-week period after the hotfix between 10 August 2020 and 13 September 2020, it contaminated the “before” and “after” analysis being carried out.
1530 Professor Asker’s analysis defined the “after” period as the five-week period between 10 August 2020, being the start of the week containing 13 August 2020, and 13 September 2020. But only two of those weeks were after 27 August 2020.
1531 By focusing on the 13 August 2020 date, when it is likely that little changed for users who had already downloaded the Fortnite app from the Play Store, and considering only a narrow two-week period after 27 August 2020, Professor Asker was erroneous in attempting to estimate substitution of user spend following the hotfix in order to estimate how Fortnite users would substitute in response to a small change in relative prices. I have touched on this above.
1532 From 27 August 2020 onwards, users were affected by the removal of Fortnite from the Play Store, because they could not update their apps to get the new season. At this point in time Ms Edwards-Warren would have expected switching to have occurred in response to essentially a large degradation in quality. This happened in the middle of the “after” period of Professor Asker, but was not controlled for in his analysis.
1533 So, in Ms Edwards-Warren’s view, the Fortnite hotfix analysis was conceptually incorrect given that the event on 13 August 2020 did not result in an option being removed, or indeed a price change, for users.
1534 In summary, Ms Edwards-Warren considered that Professor Asker’s analysis should not be attributed any weight for the purposes of defining markets.
1535 Let me deal with one final aspect of her evidence concerning the generalisation of the Fortnite hotfix analysis to other games apps.
1536 Even if one concluded that the Fortnite hotfix analysis was conceptually and analytically sound, Ms Edwards-Warren disagreed with the conclusion of Professor Asker that the results of this analysis can be generalised to all games.
1537 Now Professor Asker concluded that, on the basis that the top 25 games apps have cross-wallet and cross-progression functionalities, users of those apps have the same substitution options as users of Fortnite. But Ms Edwards-Warren analysed those top 25 five games apps and found the following matters.
1538 First, Fortnite is and was at the time of the hotfix playable on consoles as well as PCs and mobile, whilst only two of the top 25 games apps on the Play Store are playable on consoles.
1539 Second, Fortnite is and was at the time of the hotfix available on six platforms. 23 out of the top 25 games apps on Android are available on only two or three platforms.
1540 Third, five of the top 25 games apps are available on mobile only. These five games account for 20% of the top 25 games apps and [REDACTED] of Australian consumer spend on Play Store in-app purchases across the 25 game apps in 2021.
1541 Fourth, Fortnite offers and offered at the time of the hotfix cross-wallet functionalities on consoles, except the Nintendo Switch, and on PC and mobile, while only two of the top 25 games apps offer cross-wallet functionality on consoles, and not all offer cross-wallet on PC.
1542 Fifth, Fortnite offers and offered at the time of the hotfix cross-progression functionalities on consoles, PC and mobile, while only two of the top 25 games apps offer cross-progression functionality on consoles, and not all offer cross-functionalities on PC.
1543 On the basis of this analysis, she concluded that the Fortnite hotfix analysis cannot be generalised to other games apps on Android.
Professor Goldfarb’s evidence
1544 Like Professor Asker, Professor Goldfarb also used the removal of Fortnite from the App Store and the Play Store as a natural experiment to estimate diversion to Play Store alternatives following what could be considered to be an infinite price increase on the Play Store.
1545 Now Professor Asker examined diversion of player spending, and so his analysis was restricted to only players that spend. But Professor Goldfarb’s analysis assessed diversion in usage across all users.
1546 Now they both began with standard regression models to estimate the change in their respective outcome variables, being spending or usage, for Fortnite Play Store users based on a difference-in-differences estimation approach. But Professor Goldfarb considered that Professor Asker’s primary diversion methodology led to problematic results.
1547 Professor Asker’s results differed from Professor Goldfarb’s primarily because he used a levels difference-in-differences approach. But according to Professor Goldfarb this is an inappropriate approach because the average spending amounts for Professor Asker’s treatment and control groups differ substantially prior to removal. This leads to inaccurate estimates of what spending would have been in the absence of the removal for the treatment group.
1548 Specifically, according to Professor Goldfarb, this drives the illogical result of negative average spending values for several channels, implying that Epic would pay users to spend through such channels but for the removal. When a more appropriate percentage-based approach to calculate diversion was used, Professor Goldfarb found diversion estimates that aligned with the results he found for usage.
1549 Professor Goldfarb also disagreed with Professor Asker’s choices regarding several regression approaches. These disagreements centred around his use of a short time period for assessment of the removal.
1550 Now beyond methodological differences, Professor Asker also emphasised that his disagreement with Professor Goldfarb’s removal analysis was that Fortnite player usage is the incorrect metric for understanding substitution.
1551 But I agree with Professor Goldfarb that usage is a direct measure of the consumer benefit from playing Fortnite. Focusing only on spending ignored that the majority of Fortnite users do not spend. Professor Asker’s analysis ignored that Fortnite still derives value from these non-spending users. A focus exclusively on spending therefore underestimates the true impact of removal. I have discussed this debate as to the use of the appropriate metric elsewhere in my reasons.
1552 Now as I have touched on, Professor Asker calculated diversion to a given channel as the additional spending on that channel attributable to the removal, divided by the loss in spending on Play Store attributable to the removal. Professor Asker estimated any additional spending on Play Store alternatives using a levels differences-in-differences regression approach.
1553 Professor Asker said that he used a standard difference-in-differences methodology, which infers the treatment group’s counterfactual outcome by leveraging the level change observed in the control group. This means that he assumed, had the hotfix not occurred, the change in spending relative to the pre-period for the treatment group would have been by the same amount as the change observed for the control group. He said that this is a standard approach in the economic literature for estimating a difference-in-differences regression. He referred to this standard approach as a levels difference-in-differences.
1554 Professor Goldfarb explained that a key assumption in applying a levels-change methodology is that the treatment group, that is, Fortnite Play Store spenders, and control group, that is, Fortnite non-Play Store spenders, must be largely similar. When they are not, economists often take the log of the outcome variable so that proportional changes can instead be assessed. This is because the methodology uses the control group’s trajectory to construct a counterfactual trajectory for the treatment group. It infers that the observed level-change in spending for the control group from pre-removal to post-removal would have also occurred, at the same level, for the treatment group but for removal.
1555 Professor Goldfarb said that for some channels, during the pre-removal period the average spend for the control group was upwards of three times greater than the average spend for the treatment group. This points to a substantial lack of comparability between the treatment and control groups in levels that must be addressed in the analysis design. But according to Professor Goldfarb, this approach is inappropriate and leads to illogical conclusions about what would have happened but for the removal.
1556 According to Professor Goldfarb, Professor Asker’s inappropriate levels differences-in-differences approach yields illogical results, for example, Fortnite spending absent the removal is estimated to be negative for PlayStation and Switch. In other words, but for the removal, Epic would have paid users of those channels to transact on Fortnite. Professor Asker estimated a negative counterfactual spending amount for some channels, which was unrealistic. Such results arose due to the substantial differences pre-removal between Professor Asker’s treatment and control groups for some channels.
1557 Professor Goldfarb said that one well-recognised solution is to assess the relative change rather than the absolute change in the treatment by the use of a logarithmic transformation of a given outcome variable. When a variable is so transformed, the estimated effect in a regression is then interpreted as a percentage increase in response to treatment.
1558 Professor Goldfarb updated Professor Asker’s analysis with this approach. He replicated Professor Asker’s results and corrected the approach by using a more appropriate proportional change in spending. He found substantially lower diversion rates to non-Android channels.
1559 Professor Goldfarb found that Professor Asker’s diversion results were skewed towards a diversion to PlayStation, Switch, and Xbox, which was on precisely these channels where the control group average spending is more than double that of the treatment group pre-removal. I will elaborate on this in a moment.
1560 Further, Professor Goldfarb said that a separate and important weakness in Professor Asker’s empirical analysis of the removal was his use of a narrow analysis period for assessing diversion. Professor Asker’s window of assessment was 4-weeks pre-removal and 5-weeks post-removal, including the week of removal.
1561 Professor Goldfarb used wider analysis periods, for example, 13-weeks pre-removal and 13- weeks, 26- weeks, 52-weeks post-removal, excluding the week of removal. And in his view, the use of a narrower analysis period reduces the reliability of Professor Asker’s results in several ways.
1562 First, consumers could still use the Play Store Fortnite app with full functionality during the week of removal and up to two weeks post-removal. Removal from the App Store and Play Store meant that users could no longer download the Fortnite app through these stores. Users who had already downloaded the app through these stores could continue to access the app, but would not be able to re-download, for example, if they factory reset their device. And they would not be able to update their Fortnite app.
1563 Now Professor Asker’s analysis was designed to compare a period where Fortnite was available on the Play Store to a period where Fortnite was not available on the Play Store. But consumers could still play with full functionality on the Fortnite Play Store app for over half of the period in which Professor Asker counted it as unavailable.
1564 Second, Epic introduced a new Fortnite season two weeks post-removal, which likely changed patterns of Fortnite demand and spend. The new season created an asymmetry in an important factor before and after the removal, making Professor Asker’s estimated impact of removal less reliable. For these reasons, Professor Goldfarb assessed diversion over longer time periods that would be less impacted by these two factors.
1565 Third, according to Professor Goldfarb, Professor Asker incorrectly included the week of removal in his regression. As removal occurred on a Friday, users spent as normal for the majority of the week. Including this week as a post-removal week mis-attributed pre-removal spending to the post-removal period. So, it understated the loss in Play Store spending directly following removal and similarly renders Professor Asker’s results unreliable.
1566 In Professor Goldfarb’s opinion, Professor Asker’s reliance on a shorter 4-week analysis period post-removal and inclusion of the removal week and the two weeks following the removal week may have impacted the measured rate of diversion.
1567 Professor Goldfarb tested the impact of including these weeks on Professor Asker’s analysis. The overall diversion rate to non-Android channels remained largely consistent when Professor Goldfarb updated Professor Asker’s analysis. I will address his updated analysis in a moment.
1568 Professor Goldfarb also considered the analysis presented by Professor Asker to justify the 4-week post-removal analysis period. Professor Asker sought to justify the 4-week analysis period in part to avoid introducing survivorship bias into his analysis.
1569 Professor Goldfarb explained that survivorship bias, also known as attrition bias, occurs when a study using data that tracks individuals over time only focuses on individuals who passed some selection process and are observed in the data through the end of the sample. When the probability of attrition is correlated with the exogenous variable or other unobserved variables that affect the outcome, this would lead to biased results.
1570 But according to Professor Goldfarb, survivorship bias is not a risk owing to the design of Professor Asker’s analysis and using survivorship bias as a justification for a 4-week analysis period is illogical. Professor Asker selected users that pay prior to removal and followed these users over time. Users who do not have another observation remained in the dataset and were included in the analysis. This removed the possibility of biasing the sample to consider only those users that had an observation in the post-removal period. In Professor Goldfarb’s analysis, he also avoided survivorship bias by following all users in his selected sample post-removal in the same manner as Professor Asker.
1571 Professor Asker offered a second justification for using a 4-week window. He presented an additional analysis where he claimed to show that 70% of Android and Play Store users who spend on Fortnite spend again within 4-weeks. Professor Goldfarb examined this and I will return to this topic in a moment.
1572 The upshot of this according to Professor Goldfarb was that the use of a 4-week window provides less accurate results than those provided by a longer window post-removal. Professor Goldfarb considered a time window of assessment that is at least 13-weeks long to be more appropriate.
1573 Professor Goldfarb found that extending Professor Asker’s window of analysis to 13-weeks pre-removal and 13-weeks, 26-weeks or 52-weeks post-removal, there were consistently lower overall diversion rates to non-Android spending channels than those reported by Professor Asker.
1574 Further, Professor Goldfarb said that extending the time window out past 4 weeks also required the relaxation of an overly restrictive assumption that users must spend within the analysis window and spend or play before the analysis window. When using a pre-removal analysis window of 13-weeks, this entails that users most likely must have had played or spent prior to Fortnite becoming available on the Play Store. This leads to a selection bias towards multi-homing users.
1575 I will set out some of Professor Goldfarb’s tabulated results in a moment.
1576 Professor Goldfarb concluded that, similar to usage, users do not treat the ability to spend through native apps on Play Store as substitutable with the ability to spend on other apps on desktop computers, laptop computers, or gaming consoles, except to a limited extent.
1577 Let me descend into more detail concerning Professor Goldfarb’s analysis and some aspects that I have just touched on above.
1578 First, let me explain why Professor Goldfarb said that Professor Asker’s primary diversion methodology reveals illogical diversion of Fortnite spending from Play Store to other channels.
1579 In the current context, a diversion estimate is the ratio of the additional usage or spending on a given channel, for example, PlayStation, following removal, relative to the loss in usage or spending on Play Store resulting from removal.
1580 To calculate the denominator, it is necessary to estimate the usage or spending but for removal. Professor Asker did not explicitly calculate this counterfactual spending. But one can observe his implicit counterfactual spending using his regression coefficient estimates of the removal effect.
1581 The average counterfactual spending levels indicated by Professor Asker’s analysis were negative for the PlayStation and Switch channels. These negative estimated spending amounts mean that Epic would pay users to transact for such channels but for the removal. This is an unrealistic result.
1582 According to Professor Goldfarb, to understand why Professor Asker’s primary diversion methodology is illogical, one can break down the two conceptual components of a diversion ratio in more detail.
1583 The first measure, the denominator, in a diversion ratio is an estimate of the usage or spending that was lost overall from Fortnite on the Play Store because of the removal.
1584 The second measure, the numerator, in a diversion ratio is the portion of the usage or spending following removal that was gained or lost because of the removal for each Play Store alternative channel, for example, PlayStation, PC, Xbox or Switch.
1585 Both measures are based on the estimation of a counterfactual usage or spending amount for each channel. This counterfactual is the amount of usage or spending that would have occurred in the absence of the removal. It is the usage or spending that would have occurred in the counterfactual world.
1586 In Professor Goldfarb’s own diversion analysis, he explicitly calculated this counterfactual amount while Professor Asker did so implicitly with his selected methods.
1587 Second, Professor Goldfarb said that Professor Asker estimated a negative counterfactual spending amount for some channels.
1588 Professor Asker and Professor Goldfarb differed in their approach to calculating this counterfactual for non-Play Store channels. Professor Asker’s primary methodology used a levels difference-in-differences approach to estimate counterfactual channel spending for non-Play Store channels. He assumed that had the hotfix not occurred, the change in spending relative to the pre-period for the treatment group would have been by the same amount as the change observed for the control group.
1589 In contrast, Professor Goldfarb estimated counterfactual treatment group spending based on the percentage change in spending from pre-removal to post-removal realised in the control group. His analysis was more appropriate given the difference in spend levels between the treatment and control groups evidenced in his table 5.
1590 Professor Goldfarb replicated and added to Professor Asker’s primary regression results in table 5 to demonstrate the main issue with his underlying counterfactual spending estimates. He presented average spending rates for the treatment and control group pre- and post-removal, and the difference between pre- and post-removal for each group in columns (A) to (F). Pre-removal, the overall average spending for the control group at $8.89 (column A) is lower than that of the treatment group at $13.30 (column D) on average per user per week. He also showed that the treatment group played more hours per week on average. The control group had noticeably higher spending on PlayStation, Xbox, and Switch pre-removal, while the treatment group had noticeably higher spending on Android channels. These differences limit the applicability of using a levels-change difference-in-differences approach to understand the impact of the removal.
1591 In column (G), Professor Goldfarb replicated Professor Asker’s reported regression estimates from exhibit 61. This coefficient is the absolute increase in spending due to removal for the treatment group, estimated through his regression. In column (I), he calculated the counterfactual average spending amount implied by Professor Asker’s levels difference-in-differences regression approach for each channel. This is estimated as the observed post-removal average spending amount for each channel (column E) less the estimated increase due to removal (level-change regression coefficient from column G). Column (I) revealed that Professor Asker’s underlying counterfactual spending estimate on non-Play Store channels yields illogical, negative spending for Switch and PlayStation. Clearly Epic would not pay users to transact for such channels.
1592 According to Professor Goldfarb, the error lies in Professor Asker’s reliance on a levels-change (absolute value) difference-in-differences applied to highly divergent spending amounts for treatment and control groups for certain channels.
1593 A difference-in-difference estimation takes the difference in average spending for the treatment group before and after removal less the difference in spending for the control group before and after removal.
1594 For PlayStation, the control group average pre-removal spending was $4.53. This is more than three times greater than the pre-removal treatment group spending average, at $1.37. Average spending on PlayStation dropped an average of $1.51 for the control group post-removal, to $3.02. The same drop for the treatment group leads to a negative spend amount, as $1.51 is more than the average pre-removal spending amount of $1.37.
1595 Professor Asker’s approach implied negative spending for Switch for the same reasons. Professor Asker’s regression model controls for additional individual and time specific effects and estimates that removal caused a $1.75 increase in spending for the treatment group on average per user for a PlayStation user. Column E shows that actual spending in the treatment group on PlayStation was $1.49 on average per user. This implies that spending on PlayStation for the treatment group would have been approximately -0.25 on average per user in the absence of removal.
1596 In Professor Goldfarb’s view, the difference in pre-removal spending for Professor Asker’s treatment and control groups meant that a proportional change approach was more appropriate.
1597 A proportional change approach may take the form of a regression specification using the log of spending as an outcome variable. This is a common technique used in economics. A proportional approach may also take the form of estimating a counterfactual based on the percentage change in the control group based on raw numbers. Professor Asker performed this percent difference-in-differences analysis in exhibit 158 as a robustness test against his primary results and found noticeably lower diversion rates. To show why this approach renders more logical results, in column (H) Professor Goldfarb replicated the same methods that he used to calculate a counterfactual average spending amount. He based this on Professor Asker’s main regression modelling assumptions. When using a proportional change approach, as in column (H), Professor Goldfarb found counterfactual estimates that are always above zero.
1598 Third, Professor Goldfarb said that Professor Asker’s regression methodology biased his diversion estimates towards channels with high spending pre-removal in the control group.
1599 Professor Asker used the estimated regression coefficients from his levels difference-in-differences regression approach, with underlying illogical counterfactual spending estimates, to calculate diversion. This led to biased results for several reasons. One such reason is the bias in his numerator described above. Another reason is that the denominator and numerator in his diversion calculation are internally inconsistent. The numerator Professor Asker used was a level change in spending that overstated gains in spending on Play Store alternatives. His denominator was the impact on Play Store spending scaled by the percentage change observed for the control group. These two numbers were estimated through different assumptions and have minimal relation to one another.
1600 Professor Asker’s methodology overstated the overall estimated rate of diversion.
1601 Professor Asker’s use of a levels difference-in-differences regression specification, which causes negative counterfactual estimates for some channels, will overstate the increase in spending for channels with much higher pre-removal spending in the control group versus the treatment group. Larger differences in pre-removal spending averages for the treatment and control groups will generate more disproportionate estimates of the change in spending in the treatment group attributable to removal. This effect in particular skewed Professor Asker’s diversion estimates towards PlayStation, Switch, and Xbox, since in these channels the control group average spending is more than double that of the treatment group.
1602 To demonstrate the impact of using a percentage change approach, Professor Goldfarb left Professor Asker’s modelling assumptions unchanged, except he applied a percentage change approach to estimate diversion in table 6. Using this approach, the loss of Play Store spending to non-Android channels was 26.4% (or 29.7%) using the assumption that 100% (or 50%) of EDP spending is through direct download.
1603 The results in Professor Goldfarb’s table 6, together with Professor Asker’s exhibit 158, indicate large differences in estimated diversion using a levels difference-in-differences compared to a percent difference-in-differences approach. But Professor Asker surmised that the results in exhibit 158 reveal that his methodology and Professor Goldfarb’s methodology generate very similar estimates for diversion to non-Play Android stores and PC stores. Professor Goldfarb did not agree with this statement.
1604 The estimated diversion to non-Android alternatives using the appropriate percentage change diversion methodology is half that of Professor Asker’s diversion calculation based on illogical counterfactual post-removal spending estimates. The largest differences are for those based on negative estimates of spending in Professor Asker’s counterfactual, such as PlayStation and Switch. Using the percentage change diversion methodology, non-Android alternatives represent a significantly lower proportion of diverted spending.
1605 Fourth, Professor Goldfarb said that Professor Asker’s use of a short period to assess consumer switching behaviour biased his results.
1606 In addition to Professor Asker’s incorrect diversion estimates, Professor Goldfarb considered the period adopted by Professor Asker to study diversion of spending to be unreliably short and impacted by several sources of bias.
1607 In his analysis, Professor Asker obtained results using a 4-week window before removal and a 5-week period after removal, which included the week of the removal and the 4-weeks after that week. The post-removal window was influenced by several factors that rendered these results unreliable.
1608 As I have already said, in Professor Goldfarb’s own removal analysis studying usage, he presented results assessing diversion from 13-weeks prior to removal to 13-weeks, 26-weeks, and 52-weeks post-removal, representing short, medium, and long-term windows of analysis.
1609 Professor Asker stated that longer time intervals, for example, greater than 4 weeks, are inappropriately long as they may be impacted by factors other than the removal.
1610 The influence of other factors is important and something that Professor Goldfarb considered when performing his removal analysis. He found that a longer time window corrects for factors that render a four-week window uninformative and does not introduce additional significant bias.
1611 Fifth, Professor Goldfarb said that Professor Asker’s short analysis period led to biased channel diversion ratios.
1612 Professor Asker estimated diversion of spend, following the removal event, from the Play Store to other channels. He employed a 5-week post-removal window in this analysis, being the week of removal and an additional four weeks after. There are several factors that cause results based on a 5-week post-removal window to be unreliable. When Professor Goldfarb adjusted Professor Asker’s analysis to correct for these factors, he found noticeable differences in individual channel diversion rates.
1613 The first factor causing Professor Asker’s results to be less reliable is that users could still use the Play Store Fortnite app with full functionality until 27 August 2020, two weeks following the removal event. Any spending from those users during that time period would be included in Professor Asker’s estimate of the treatment group’s post-removal spending through the Play Store. It is likely that consumer use and spending behaviour may have been impacted directly following the removal. But Professor Asker’s estimate of the loss in spending owing to removal included a period where users could continue to use the Play Store Fortnite app with full functionality, leading him to underestimate the loss in spending once users could no longer spend via the Play Store.
1614 Further, Professor Asker’s 5-week post-removal window included the release of a new Fortnite season on 27 August 2020. This meant that Professor Asker’s analysis compared spending during the release of a new season in the five weeks post-removal to spending during the tail end of a season in the four weeks pre-removal.
1615 The direction of bias of this event on the results is not clear. If users belonging to the treatment group engaged more in the first weeks of a season compared to users belonging to the control group, this would bias Professor Asker’s diversion ratio estimate upwards and overstate diversion from Play Store to other channels. If users belonging to the treatment group instead engaged less in the first weeks of a new season compared to users belonging to the control group, then the estimated diversion rate would be understated.
1616 Finally, Professor Asker included the week of removal in his regression. To estimate the effect of removal on spending diversion using a difference-in-differences approach, Professor Asker must compare the difference in pre-removal average spending and post-removal average spending between the treatment group and control group.
1617 The removal occurred on a Friday, meaning that during the week of the removal, users spent as normal from Sunday to Thursday but were affected by the removal from end of day Thursday to Saturday. Professor Asker included the removal week in his post-removal period.
1618 Including the Play Store spending prior to removal on 13 August 2020 in the post-removal period adds noise to the estimation. This artificially inflated the average post-removal spending on Play Store amount for the treatment group.
1619 In table 7, Professor Goldfarb demonstrated the effect of correcting for these factors that affect Professor Asker’s analyses. In table 7, he presented percentage difference-in-differences diversion calculations, plus two iterations in which he made updates to his calculations. Columns A and B of table 7 replicate Professor Asker’s exhibit 158. These are based on his comparison of the four weeks pre-removal to the removal week and the following four weeks.
1620 Iteration 1, presented in columns C and D, provides results following Professor Asker’s sampling methodology but excluding the removal week from the calculation. In other words, iteration 1 compares the four-weeks pre-removal to the four-weeks post-removal, excluding the removal week.
1621 Iteration 2, presented in columns E and F, provides the results following Professor Asker’s sampling methodology but excluding the two weeks following the removal week as well as the removal week. Iteration 2 compares four-weeks pre-removal with the four-week period beginning 31 August 2020.
1622 Table 7 shows that the diversion to non-Android channels remains largely consistent across these iterations using a 4-week window of analysis.
1623 The diversion rates to the Galaxy Store and the diversion rates to direct download vary between exhibit 158, iteration 1, and iteration 2. One source of variation is the difference in share of EDP through direct download. Professor Goldfarb first considered this source of variation and then discussed the remaining variation arising from adjusting the time windows for Professor Asker’s analysis.
1624 Each iteration in table 7 provides two results, being one for 100% direct download and one for 50% direct download. This is to account for insufficient visibility into the relevant channel for EDP data subsequent to the removal. The results for each spending channel within each iteration in table 7 are largely consistent regardless of whether 100% or 50% direct download share is used, apart from direct downloads itself.
1625 To assess whether the 100% direct download or the 50% direct download result provides the better estimate in iteration 1 and in iteration 2, Professor Goldfarb considered the availability of EDP in the Play Store and direct download channels.
1626 Professor Asker provided an estimate that found that between 10 August and 13 September 2020, 43.9% of EDP transactions occurred via the Play Store app. This indicates that for exhibit 158, the estimate using the 50% direct download share is likely more accurate than the estimate using the 100% direct download share. For iteration 1, the estimate using the 50% direct download share, or an estimate between the 50% and 100% direct download share estimates, is likely more accurate than the estimate based on 100% direct download share.
1627 The Fortnite app on the Play Store lost significant functionality for users following the season release on 27 August 2020. Following this date, it is likely that most transactions through EDP were related to spending through the direct download version of Fortnite.
1628 The share of EDP through direct download also likely increases over time. This means for iteration 2, where the post-removal period begins on 31 August 2020, the estimated diversion ratio using a 100% share of direct download is likely more accurate than the estimate using a 50% direct download share. It would also be more accurate to assume a 100% share for longer periods of analysis, including for an analysis that extends to 13-weeks post-removal or longer.
1629 Professor Goldfarb highlighted the more accurate results for exhibit 158, iteration 1 and iteration 2 in his table 7. I will not set out the highlighted table, but would note that what he highlighted were all of columns B, D and E in the table set out above.
1630 The direct download diversion ratio varies more than the diversion ratio for other spending channels in part because changing the share of direct download payments affects both the numerator and denominator of the direct download diversion ratio. For other channels, the share of direct download payments affects only the denominator. Accounting for the more accurate rate of direct download reduces the variability in estimates for diversion to direct download.
1631 Table 7 shows that the diversion rates to the Galaxy Store changes between exhibit 158 and iterations 1 and 2, from 10.6% to 11.1% and 18.6%. This reflects the effect of adjusting the window for analysis to remove the removal week, being iteration 1, and the removal week plus the following two weeks, being iteration 2, and accordingly comparing the pre-removal spend to a more appropriate post-removal time period when considering a 4-week window.
1632 Fortnite users who downloaded via the Play Store on or prior to 13 August 2020 could still play with full functionality in Fortnite between the removal and 27 August 2020. Once the Fortnite app via the Play Store functionality diminished on 27 August 2020, users may have been more likely to switch Fortnite usage and spending to another channel with full functionality. Users who switched to another channel selecting the Galaxy Store rather than non-Android channels is consistent with users being motivated by the “device first” and “clicks are costly” concepts. Indeed, the Galaxy Store has the highest diversion ratio in iteration 2 amongst the six spending channels displayed in table 7.
1633 Sixth, Professor Goldfarb said that Professor Asker’s reasons for choosing a four-week time window did not support his conclusion and in fact indicated that a longer time period was more appropriate.
1634 Professor Asker asserted that a time frame of four weeks was appropriate to assess diversion due to the potential for survivorship bias. He supported this assertion with two analyses of Fortnite churn.
1635 In one analysis, Professor Asker looked at the number of weeks in which Fortnite Android or Play Store users who engaged in paid transactions did so during the 16-week period in which Fortnite on the Play Store was available. He found that 36% of spending users spent in only one week out of the 16-weeks. Professor Asker said that this means that using a shorter time period for analysis corrects for the possibility of error due to survivorship bias.
1636 As I have already touched on, survivorship bias occurs when a study using data that tracks individuals over time only focuses on individuals who passed some selection process and are observed in the data through the end of the sample. Professor Asker asserted that short time frames are appropriate for studying substitution as longer time frames would narrow the analysis to a selected set of Fortnite users and be impacted by survivorship bias.
1637 But this concern is misplaced given how both Professor Asker and Professor Goldfarb carried out the removal analysis in practice. The analysis that both Professor Asker and Professor Goldfarb performed did not narrow focus on a selected set of users that continued to play or spend on Fortnite. They both instead required that a user play or spend prior to removal and track all users in the post-removal period. If a user does not spend in a week, they are recorded as having zero spend in that week, not dropped from the sample. If a user does not spend following the removal, the remainder of their recorded weeks are recorded with zero dollars of spending. They are not dropped from the sample.
1638 Given that the analysis design does not introduce survivorship bias, Professor Asker’s finding that one week is the most common number of weeks in which to have a paid transaction does not affect the choice of appropriate analysis window.
1639 In the second analysis, Professor Asker looked at the distribution of time elapsed between paid transactions, which he referred to as spending events, on Fortnite, for Australian Android and Play Store users who made more than one purchase across the full data period.
1640 Professor Asker found that the median time between spending events for spenders with two or more transactions is only two weeks for both Australian Android and Play Store users and that 70% of Android and Play Store users who spend on Fortnite would choose where to transact again within four weeks of a triggering event.
1641 Professor Goldfarb reviewed Professor Asker’s calculation methodology and found a more accurate way to calculate the statistic provided by Professor Asker.
1642 Professor Asker purported to show the amount of time that elapses between purchases for Australian Android and Play Store users. This is relevant given that both were interested in observing, for a user who purchased in the Play Store before the removal, where that user purchased following the removal. The typical interval between purchases helps one know how long after removal to look to see the user’s post-removal purchase, if any.
1643 But upon examining Professor Asker’s methodology to calculate the typical interval per user, it was apparent to Professor Goldfarb that Professor Asker had calculated that 70% of consecutive purchases are less than four weeks apart, not that 70% of users make transactions less than 4 weeks apart. Professor Asker’s calculation looked at the distribution of time between two consecutive purchases across users, not at the user-level. Professor Asker then calculated the average and other statistics of these transaction-distance observations. This introduced error in assessing the typical frequency of user purchases because users that purchase more frequently occur more often in the transaction-distance observations. If there is a group of Fortnite users who make frequent and numerous purchases during the data period, these players will skew the distribution towards the shorter intervals.
1644 In other words, Professor Asker calculated these statistics across transactions, which weights frequently transacting users more heavily. The more informative calculation is to take an average per user and then the average across users. This calculation indicated the typical gap between purchases for a user and consequently the time period should be examined post-removal.
1645 Professor Goldfarb replicated Professor Asker’s exhibit 53 but considered instead a distribution based on user-level average number of weeks between spending events. Professor Goldfarb’s table 8, which I will not reproduce, shows that the average user who spends on Android has 10.6 weeks between spending events. The average user that spends on Play Store has 10.8 weeks between spending events. Even in the 30th percentile of Android and Play Store users, the number of weeks between spending events is 4.3. His table 8 demonstrated that a window of analysis of only 4-weeks is too restrictive because more than 70% of users average more than 4 weeks between spending events.
1646 Based on these two results, Professor Asker argued that user attrition will bias estimates relying on a longer analysis window and that a shorter analysis window is reasonable given his calculation of purchase frequency.
1647 For the reasons stated above, Professor Goldfarb did not agree with Professor Asker’s conclusion. As most users who make paid transactions do so across more than one week and the time between transactions is long, a longer time period of analysis should be used. Professor Goldfarb assessed the effect of switching to a longer time period in Professor Asker’s analysis.
1648 Professor Goldfarb considered it appropriate to update Professor Asker’s analysis to consider diversion over a longer time period than four weeks, in order to obtain more accurate estimates of diversion rates that are not as prone to the biases detailed above. To do so, he had to first update his sample selection criteria. He then updated Professor Asker’s analysis to reflect a longer window.
1649 Seventh, Professor Goldfarb said that updating Professor Asker’s sample selection criteria was appropriate when extending the time window for analysis.
1650 Professor Asker imposed two conditions on his sample selection.
1651 The first condition required that a user must spend in Fortnite on any channel within the pre-removal period in order to be included in his sample. In Professor Asker’s analysis, this required that a user spends in the four weeks prior to removal, between 16 July 2020 and 13 August 2020.
1652 The second condition required that a user either plays or makes a purchase in Fortnite on any channel or spending channel prior to the pre-removal period, that is, between the start of the dataset on 26 February 2018 and 16 July 2020, being four weeks before removal, in Professor Asker’s analysis. Professor Asker imposed the second condition to include in his sample only users who are familiar with Fortnite.
1653 Professor Goldfarb considered that Professor Asker’s analysis would produce a more accurate result if the pre-period was extended. For that reason, he extended his pre-removal period from four weeks to thirteen weeks. This extension required the exclusion of the second condition imposed by Professor Asker for the following reasons.
1654 Fortnite was released on Play Store on 20 April 2020. Increasing the pre-period to thirteen weeks, covering a time period from May 2020 to August 2020, reduced the amount of time between the availability of Fortnite on Play Store and the beginning of the pre-period of the analysis to just three weeks, which was relevant to the second condition. This provided therefore only a short time period to observe users who did not play or purchase in Fortnite through other channels but were attracted to adopt Fortnite on Play Store following its release. Given that such users did not already play or purchase in Fortnite through other channels, Professor Goldfarb’s expectation was that most users would single-home on Fortnite through the Play Store. So, extending the time period, which he considered to be more reliable, required removing the second condition. Otherwise, the inclusion of that condition would likely artificially bias the treatment group, being users who had ever paid in Fortnite on the Play Store, to Fortnite users who multi-home across Play Store and other channels.
1655 Professor Goldfarb assessed the possibility that imposing the second condition with a 13-week pre-period biases the treatment group towards multi-homing users. In table 9, he displayed summary statistics for two samples. The first sample was selected according to Professor Asker’s two conditions and a 13-weeks pre-removal period, whilst the selection of the second sample removed Professor Asker’s second condition, requiring that users have paid or played on Fortnite before the pre-period.
1656 Table 9 shows that imposing the second condition increases the share of multi-homing users in the treatment group and excludes many single homing Play Store users from the sample. The share of treatment group users multi-homing in the 13 weeks before removal drops from 42% to 30% when removing the second condition. The change is even larger when considering multi-homing over the full time period between 2018 and removal. This is because users in the treatment group necessarily have purchased in Fortnite on the Play Store and the second condition allows a much longer window to include users who have also paid or played on Fortnite in other channels (July 2018 to May 2020) compared to users for whom Fortnite on the Play Store is their sole channel between 20 April 2020 and May 2020.
1657 Professor Goldfarb assessed the effect that imposing the second condition and increasing the share of multi-homing users in the treatment group had on the analysis results. In table 10, he provided diversion estimates for both samples considered above, applying a 13-week pre- and post-removal analysis. In this analysis, he also applied the proportion change diversion estimate method, along with an exclusion of the removal week.
1658 Comparing the results with and without the second condition, he found lower diversion to each channel excluding the Galaxy Store. This lower rate of diversion for channels other than the Galaxy Store is likely because the sample without the second condition aptly included more single-homing users who were more likely to stop spending altogether after the removal.
1659 The Galaxy Store sees an increase likely because it is the most straightforward alternative for the single-homing Fortnite Play Store players. When applying a longer time window for analysis, Professor Goldfarb considered the analysis without the second condition to be more reflective of what occurred for consumers post-removal and less prone to a sample selection bias.
1660 Eighth, Professor Goldfarb said that extending Professor Asker’s analysis out to medium and long-term windows showed generally consistent rates of diversion to non-Android channels.
1661 Professor Goldfarb extended Professor Asker’s analysis by considering three longer windows of analysis, being 13 weeks before and 13 weeks after removal, 13 weeks before and 26 weeks after removal, and 13 weeks before and 52 weeks after removal. In his extensions he also employed a proportional diversion estimate and removed sampling the second condition. He further presented results excluding the week of removal, being iteration 1, and removing both the week of removal and the following two weeks, being iteration 2, given that Fortnite was still available with full functionality up to 27 August 2020. He considered excluding the removal week to be the correct approach. Understanding the impact of the additional two weeks following removal on diversion results is also important, though in practice the effect of these weeks is likely to be attenuated when using a longer analysis window.
1662 In table 11.A, he found generally consistent results across the analyses when using longer time periods and excluding the removal week. He found a total diversion to non-Android channels of 28.1% to 29.7% when measuring diversion in the 13 weeks post-removal. He found a total diversion to non-Android channels of 27.8% to 28.7% when measuring diversion in the 26 weeks post-removal. When measuring diversion in the 52-weeks post-removal, the total diversion to non-Android channels was slightly higher at 33.3% to 34.3%.
1663 So, consumers do not treat usage or spending on Android smart mobile devices as substitutable with laptop computers, and desktop computers, or gaming consoles, except to a limited extent.
1664 Since users were able to play Fortnite with full functionality on their Play Store Fortnite app until the new season was released on 27 August 2020, the full extent of switching to other channels may not have occurred immediately after the removal.
1665 Professor Goldfarb conducted a robustness analysis where he removed not only the week of removal, but also the following two weeks from the post-removal period. So, the post-removal period started at the third week after the removal, that is, from 31 August 2020, and is for 13-, 26- and 52-weeks thereafter. The pre-removal period started 11 May 2020 and ended the week before removal.
1666 Table 11.B presents results for this robustness extension with time windows of 13-weeks, 26-weeks, and 52-weeks post-removal. The results for the 13-week, 26-week, and 52-week periods are generally consistent with table 11.A.
Analysis
1667 In my view Professor Asker’s difference in differences analysis is unreliable and should not be used. Moreover, Professor Asker’s analysis inappropriately includes the weeks of 10, 17 and 24 August 2020 which leads to unreliably low estimates of diversion to the Galaxy Store. I prefer Professor Goldfarb’s approach.
1668 A reasonable range of diversion estimates is provided by the highlighted estimates for 13-, 26- and 52-weeks in Professor Goldfarb’s table 11.A and the highlighted estimates in table 11.B, with a range of between 10.1 and 18.7% for diversion to the Galaxy Store.
1669 The best single estimate of diversion to the Galaxy Store is the highlighted estimate for 13 weeks in table 11.B, being 15.8%.
1670 On Professor Goldfarb’s figures, approximately half of all spending was lost as a result of the removal.
1671 Let me now address some specific topics.
What is preferable? A levels analysis or a percent approach?
1672 Now as I have said, Professor Asker used a levels difference in differences analysis to analyse the hotfix, which assumed that the expenditure of the treatment group would have changed by the same amount as the expenditure of the control group. Contrastingly, Professor Goldfarb used a percent approach, which assumed that the treatment group’s expenditure would have changed by the same proportion as that of the control group.
1673 Google says that Professor Asker’s use of the well-accepted and utilised levels difference in differences approach is orthodox. Let me set out some of its arguments.
1674 First, Google says that there are trade-offs associated with either approach. A trade-off of using a levels approach is that it can result in a negative counterfactual for some sources of diversion. But this is not a problem that ultimately matters for the following reasons.
1675 It does not impact estimates of diversion to the Galaxy Store, as the relevant counterfactual estimates are positive.
1676 One can bound the counterfactual to never be less than zero as Professor Asker did, and it does not change the economic substance of the results. Professor Asker explained that negative counterfactuals are a consequence of lower average spending by the treatment group than the control group and spending on Fortnite generally declining over time.
1677 Further, Google says that there are trade-offs in using the percent approach and it makes the following points.
1678 It says that when the treatment group has much lower spending than the control group, while a levels difference in differences approach could overstate the relevant change and so produce a negative counterfactual, a percent difference in differences approach could understate the relevant change.
1679 Further, it says that as a result of the proliferation of zero spending events in the relevant dataset, the percent approach cannot be implemented in a manner that allows for individual controls or any analysis where the individual is the unit of analysis.
1680 It says that Professor Asker explained how the inability to control for differences in spending patterns between recent adopters and long-time users renders the regression machinery inoperable in this environment under the percent approach.
1681 Google says that Professor Goldfarb appeared to accept that it was sensible if controlling for variables such as the duration of phone ownership. Professor Goldfarb did not control for those variables, because he did not consider them to make a meaningful difference to his conclusions about overall diversion. So, he preferred a simpler analysis lacking appropriate controls.
1682 Google says that it is these trade-offs that explain why Professor Asker correctly viewed the two approaches as complementary for estimating the relevant parameters of interest.
1683 Second, Google says that despite not having conducted any diversion analyses of her own, Ms Edwards-Warren sought to proffer some views on this issue. She said that the parallel trend assumption, which is that the control group must be a reasonable approximation for the treatment group, does not hold for Professor Asker’s model, with the effect that his analysis cannot account for any confounding effect on users spend over time. But Google says that this contention is both wrong and irrelevant. It is said that her concerns about parallel trends did not extend to estimates of diversion to the Galaxy Store. Further, Google says that Professor Asker’s results were robust to using the levels and the percent approach, particularly with respect to the Galaxy Store, which indicated that his results were not being driven by issues with parallel trends. This is because the percent approach does not have a parallel trend assumption.
1684 Third, Google says that Epic misunderstands the parallel trend assumption. It says that there is no connection between Ms Edwards-Warren’s placebo analysis and the parallel trend assumption. Testing the parallel trend assumption requires analysing the treatment group’s and control group’s outcomes in the pre-period. Ms Edwards-Warren’s placebo test instead studied the outcomes of a different treatment group and control group in a different pre-periods.
1685 Fourth, Google says that the difference between the results of Professor Asker’s levels approach and Professor Goldfarb’s percent approach is primarily the degree of total diversion.
1686 But it says that total diversion was not used by Professor Asker in his critical loss analysis. Whilst for the purposes of that analysis Professor Asker was concerned with diversion to the Galaxy Store, which is quantitatively robust, his levels analysis highlighted the relevant importance of relative diversion to alternative distribution channels, for which there is a similar pattern under the percent approach in any event.
1687 Google says that having regard to these matters, Professor Asker’s levels approach is reliable, and indeed in some respects preferable to Professor Goldfarb’s percent approach.
1688 But in my view, Professor Asker’s difference in differences analysis of the diversion of Fortnite spending suffered from various flaws. And I agree with Epic that this caused him to overestimate the total amount of expenditure which was diverted following the Fortnite removal event and particularly diversion to consoles, and to underestimate the expenditure diverted to the Galaxy Store and Samsung. I have accepted Epic’s position based upon the evidence of Professor Goldfarb and Ms Edwards-Warren, aspects of which I have set out.
1689 Professor Asker, in using a difference in differences analysis to estimate the rate at which Fortnite expenditure was diverted from the Play Store to other channels following the removal event, relied upon an assumption that, but for the removal, the expenditure of the treatment group, being Play Store users, would have changed by the same amount as the expenditure of the control group, being users who he considered were not affected by the removal.
1690 Contrastingly, Professor Goldfarb used a percent difference in differences approach, which assumed that the treatment group’s expenditure would have changed by the same proportion as that of the control group.
1691 Professor Asker’s approach was problematic because the average expenditure of Play Store users was substantially lower than the control group pre-removal. This meant that the decrease in control group spending from pre-removal to post-removal had an exaggerated effect on his estimate of the counterfactual expenditure of Play Store users.
1692 Professor Goldfarb illustrated this flaw by demonstrating that Professor Asker implicitly estimated that Play Store users would have had negative spending on certain channels if the removal had not occurred.
1693 Professor Asker accepted that these negative counterfactual estimates were a consequence of the treatment group’s lower average spend compared to the control group. He further acknowledged that the fact that his methodology led to negative counterfactual spending estimates was problematic, and conceded that it led to exaggerated estimates of the rate at which Play Store users’ Fortnite revenue was diverted to consoles, and to all other channels in aggregate.
1694 But he defended the use of a levels methodology to estimate diversion to the Galaxy Store on the basis that the Galaxy Store was not one of the channels for which his methodology estimated negative counterfactual spending, and that the differences between the Galaxy Store diversion estimates based on levels and percent were so small that it would give an undue sense of precision to treat them as being meaningfully different.
1695 But the fact that the Galaxy Store counterfactual spending happens to be non-negative does not mean that Professor Asker’s otherwise inappropriate methodology is reliable when applied to this channel. As Professor Goldfarb explained, the negative counterfactuals are a symptom of the problem rather than the problem itself.
1696 Further, Professor Asker’s dismissal of the significance of the differences in the Galaxy Store diversion produced by the two methodologies is unfounded, given that the results of his critical loss analysis are sensitive to small variations in input assumptions.
1697 Now Professor Asker said that a percent approach foreclosed the use of a linear regression, because this would involve dividing by zero, which would produce an undefined result. But Professor Goldfarb addressed this issue by implementing his difference in differences based on averages rather than a regression. He concluded that this difference in methodology did not impact his results.
1698 Further, in seeking to explain his reliance on the levels approach despite its calculation of negative counterfactual spending, Professor Asker argued that a percent approach could similarly produce strange results if applied in a situation where the expenditure of the treatment group was much larger than the control. Now depending upon the context, it is sometimes appropriate to measure the changes in levels and sometimes in percent. But in the present context, a percentage approach is more appropriate because expenditure by the control group is substantially greater than expenditure by the treatment group.
1699 A further matter supporting Professor Goldfarb’s percent approach relates to the parallel trend assumption, which for difference in differences analysis to be meaningful requires the control group to be a good approximation for the behaviour of the treatment group as I have previously touched on. A difference in differences analysis is used to compare outcomes for the treatment group to a control group to eliminate any potential confounding variables that affect the outcome of interest and occur at the same time.
1700 Further, Ms Edwards-Warren demonstrated that the parallel trend assumption does not hold for Professor Asker’s treatment and control groups, and as such, his analysis could not account for any confounding effect on user spend over time.
1701 Ms Edwards-Warren re-ran Professor Asker’s analysis using three randomly selected placebo dates on which there was no reason to expect Fortnite user diversion in spend. These placebo dates generated similar results to Professor Asker’s removal analysis, that is, they show high rates of diversion to consoles and lower diversion to the Galaxy Store.
1702 Professor Asker explained that the reason his regression method resulted in diversion to consoles on the placebo dates was due to underlying drift from mobile to console that underpins at least part of Epic’s business strategy. But his analysis should have controlled for this underlying drift, given that the aim of difference in differences analysis is to eliminate the effect of potentially confounding variables.
1703 But this defective choice of control group likely led to his finding of diversion from the Play Store to consoles prior to the new season release on 27 August 2020 which Professor Asker mistakenly relied upon to assert that these weeks contain information about diversion in response to the removal.
1704 Contrastingly, Ms Edwards-Warren gave evidence that the parallel trend assumption does hold for Professor Goldfarb’s analysis, on the basis that the percentage differences observed for the expenditure of the control and treatment groups track one another more closely.
1705 In my view, Professor Asker’s method is not appropriate in this case. And I have given little weight to the estimates of diversion based on this methodology in favour of the percent difference in differences approach.
1706 Let me turn to another topic.
What is the relevant period for a proper analysis?
1707 Now Epic says that Professor Asker’s analysis is flawed because it includes the week of the hotfix, in which the hotfix occurred partway through the week, and the two weeks after the hotfix, which were before the new Fortnite season release on 27 August 2020. And Epic says that users were unaffected by the hotfix until the new season was released two weeks later, and therefore any analysis should only begin after the new Fortnite season was released.
1708 But Google says that these criticisms are misconceived for the following reasons.
1709 First, it says that the data on user behaviour within the period immediately following the event being studied is valuable and informative as to diversion and ought not be ignored. So, it is appropriate and relevant to include the period immediately following the hotfix.
1710 Second, Google says that Epic’s claim that users were unaffected by the hotfix is incorrect. It says that when Fortnite was removed from the Play Store, the Play Store users immediately lost the ability to download or update Fortnite via the Play Store and lost the ability to transact with Epic via Google Play Billing. This meant that they lost access to a transaction venue because the Play Store no longer facilitated sales of Fortnite in-app content, that is, it did not guarantee delivery of content, push updates, and facilitate discovery. The only way in which they could make purchases on Fortnite in the version of the app they had downloaded from the Play Store was via EDP. Professor Asker characterised this initial change due to the hotfix as a degradation in quality.
1711 Third, Google says that the raw data shows that the hotfix had an immediate effect on the Play Store user spending.
1712 Professor Asker analysed the spending of treatment group users, that is, those who spent via the Play Store version of Fortnite, before and after the hotfix. He found that spending via Google Play Billing went immediately to zero after the hotfix, which was consistent with these users losing access to Google Play Billing on their app, from an average of $9 per week in the week prior to the hotfix, but that there was not a commensurate increase in spending via EDP after the hotfix.
1713 Google says that what this means is that users experienced an immediate quality degradation in Fortnite that was borne out in their spending. So, the appropriate start date to analyse diversion from the hotfix is the date of the hotfix.
1714 Google says that this reasoning is no different from evaluating the effects of a medical trial starting on the date that users receive medication. If users had adverse effects for the first two weeks after the start of the trial, and then positive effects thereafter, no scientifically valid study design would remove the first two weeks of trial as that would involve cherry-picking the data.
1715 Google says that Epic’s assertion that the two weeks after the hotfix should be removed from the analysis is similarly unsupportable.
1716 Fourth, Google says that as to Epic’s claim that Professor Asker’s inclusion of the week of the hotfix creates results that are biased in favour of his ultimate conclusions, Epic misrepresents the direction of this alleged bias.
1717 Google says that Professor Goldfarb’s analysis shows why excluding the week of the hotfix increases the diversion for some venues and decreases the diversion for other venues. But, overall, it has a minimal impact on the estimates, as Professor Asker stated.
1718 Similarly, Google says that Professor Asker described how diversion to the Galaxy Store increased after the new season was released, but that this effect was short-lived and dissipated over time.
1719 Consistently with this, Google says that Professor Goldfarb’s results revealed similar diversion to the Galaxy Store when using a 4-week period, including the two weeks after the hotfix, and when using a 26- or 52-week period, regardless of whether the two weeks after the hotfix were included.
1720 This means that, according to Google, Professor Asker’s results did not represent diversion during some outlier period, but rather captured typical diversion patterns for Fortnite users.
1721 Instead, Professor Goldfarb’s choice to eliminate the first two weeks after the hotfix, and focus on a time window when diversion to the Galaxy Store was artificially inflated, meant that his estimates captured atypical diversion patterns.
1722 Further and as I have said above, when analysing the hotfix, Professor Asker used a shorter period, being 4 weeks before the hotfix and 5 weeks after, while Professor Goldfarb analysed it using a longer period, being 13 weeks before the hotfix, and 13, 26, or 52 weeks after.
1723 Google says that Professor Asker’s approach was informed by his analysis of spending patterns of Fortnite, which indicated that a shorter period was more appropriate given the high churn in the Fortnite user base.
1724 Further, Google says that Professor Asker’s shorter period should be preferred for the following reasons.
1725 First, it says that Professor Goldfarb ultimately accepted in cross-examination that his preferred specifications were the longer ones, being 26- and 52-weeks. So it says that the 13-week specification should not be preferred over the other specifications.
1726 Second, it says that Professor Goldfarb sought to support his asserted preference for a post-hotfix period of at least 13 weeks by saying that it was the longest analysis period that had a symmetric pre- and post-period length.
1727 But it says that that symmetry alone does not justify a longer time horizon relative to a shorter one. Moreover, there is no econometric reason to prefer a specification with symmetric pre- and post-periods, consistent with Professor Goldfarb’s statements in the joint expert report and during his evidence in the Apple proceeding that he prefers a 26- and 52-week post-period.
1728 Third, Google says that there are challenges in drawing a causal inference from a single event, being the hotfix, over longer time periods because of confounding factors. There can be other differential shocks to the treatment group and control group in the post-period.
1729 Google says that this means that the Play Store users’ substitution many weeks after the hotfix may reflect a variety of other factors, whereas the Play Store users’ substitution immediately after the hotfix can likely be attributable to the effect of the hotfix itself, after controlling for pre-existing trends, as the difference in differences method does.
1730 Additionally, Google says that whilst as a general matter a shorter time period such as 4 weeks is more appropriate for analysing the hotfix, Professor Asker also explained that he was less bothered by the longer time periods. Rather, the more significant area of difference between him and Professor Goldfarb pertained to omitting the weeks immediately after the hotfix.
1731 But again, I have accepted the position of Epic and its experts.
1732 In my view, Professor Asker’s estimates of diversion are also based on an inappropriate time period which caused him to underestimate the rate of diversion to the Galaxy Store.
1733 Professor Asker primarily relied upon the diversion of spending by Fortnite users following the removal to draw conclusions about the extent to which users would divert their revenue to the Galaxy Store in response to a SSNIP on the prices of apps and in-app content on the Play Store. With this purpose in mind, the five-week post-period Professor Asker relied upon for his analysis is inappropriate for two reasons.
1734 First, Professor Asker’s post-period started on 10 August 2020, three days prior to the Fortnite hotfix.
1735 Second, Professor Asker’s post-period included two weeks between the Fortnite hotfix on 13 August and the Fortnite new season launch on 27 August 2020.
1736 All of Professor Asker’s difference in differences estimates of diversion included the week of 10 August 2020 in the post-period. Professor Asker’s inclusion of the week of 10 August 2020 in his post-period was inappropriate because it included several days which were unambiguously prior to the removal.
1737 Professor Asker indicated that he did not have a strong view as to whether this week should be removed from his analysis but claimed that its inclusion would have resulted in the calculation of lower diversion ratios and so was conservative for his purposes.
1738 But as Professor Goldfarb pointed out, Professor Asker primarily relied on his analysis to show that diversion to the Galaxy Store was below his critical loss threshold. As such, any dampening of his diversion estimate would have been biased in favour of broadening the market.
1739 Additionally, Professor Goldfarb found that including the week of 10 August 2020 from the post-period produced higher estimates of total diversion and lower estimates of diversion to the Galaxy Store.
1740 So, Professor Asker’s inclusion of this week produced results that were biased in favour of his ultimate conclusions. There was no sound basis for including the week of 10 August 2020.
1741 Further, given that Professor Asker primarily relied upon this analysis for estimating diversion to the Galaxy Store, the inclusion of the following two weeks of 17 and 24 August 2020 prior to the season release was also inappropriate.
1742 Following removal, users of Fortnite on the Play Store experienced the following changes to their experience.
1743 From 13 August 2020, they were given the choice between buying V-bucks through Google Play Billing for the usual price or using EDP for a 20% discount. This discount was also available to users who bought V-bucks in Fortnite on other platforms.
1744 By 18 August 2020 at the latest, the option to pay with Google Play Billing was removed. Users could continue to spend through Play Store Fortnite using EDP.
1745 On 27 August 2020, Fortnite was updated to a new season. This update could not be downloaded on the version of Fortnite downloaded from the Play Store, meaning that users could not access the new season’s content, or play with users on other platforms.
1746 So, it is apparent that an assessment of the diversion of revenue from the Play Store to the Galaxy Store should focus on the change in expenditure following the season release, as until this point, the experience of playing and spending in Fortnite downloaded from the Play Store was largely unchanged. To the extent that there were changes to the Play Store version of Fortnite on 13 August 2020, Professor Asker acknowledged that these changes were smaller than those caused by the season release.
1747 In particular, prior to the season release on 27 August 2020, Play Store users would have had no incentive to divert any spending to the Galaxy Store. Professor Asker’s analysis shows that prior to the hotfix, only in the order of 1% of Play Store Fortnite users’ expenditure was through the Galaxy Store. After the hotfix on 13 August 2020 but before the season release on 27 August 2020, Play Store users could still play their existing Play Store version of Fortnite on their Android device and could make purchases through EDP through their existing Play Store version of the app.
1748 The idea that Play Store users would have diverted spending to the Galaxy Store prior to 27 August 2020 is premised on the notion that between 13 August and 27 August 2020, rather than using EDP to make purchases within their existing Play Store version of Fortnite, the Play Store users would have chosen instead to undertake the additional steps of downloading the same version of the Fortnite app via the Galaxy Store onto their Android device, setting up Samsung Pay and making a Fortnite purchase through Samsung Pay.
1749 But the frictions involved in re-downloading the same app on the same device and the lack of any corresponding benefit in doing so point against any appreciable diversion to the Galaxy Store prior to 27 August 2020. This logic is borne out by two findings.
1750 First, Professor Asker’s finding that Fortnite user expenditure on the Galaxy Store in Australia was largely consistent for three weeks before increasing significantly on the day of the season release.
1751 Second, Professor Goldfarb’s finding that the rate of diversion to the Galaxy Store increases when the two weeks following removal are excluded from the analysis.
1752 Professor Asker’s argument that there was some observed diversion in the period after Google Play Billing ceased and 27 August 2020 misses the point. What is observed in that period is diversion to channels other than the Galaxy Store.
1753 Relevantly for Professor Asker’s analysis, during the period after Google Play Billing ceased and prior to the season release, users may have had an incentive to divert their spending to channels they already multi-homed on, because of the reduced frictions in using their existing payment channel on another device rather than setting up EDP. But as the data bears out, there was limited multi-homing prior to the hotfix between the Play Store and the Galaxy Store.
1754 The consequence is that in any analysis focused on diversion to the Galaxy Store, the inclusion of the weeks of 17 and 24 August 2020 is inappropriate because it will result in unreliably low estimates of diversion.
1755 It is particularly unreliable if one uses, as Professor Asker did, a 5-week post-treatment period in which three of the five weeks are purporting to measure an effect which has not yet occurred.
1756 Professor Goldfarb explained that removing these two weeks from the post-period is critical when relying on a 4-week analysis window. For 13, 26 and 52-week analysis windows, the effect of the inclusion of these two weeks is attenuated.
1757 Now Professor Asker criticised Professor Goldfarb’s preference for longer periods of analysis on the basis that Fortnite users generally exhibit a high level of churn, meaning that assessing substitution over a longer period is inappropriate, and an analysis based on longer periods is likely to be affected by factors other than the removal.
1758 Professor Asker’s preference for a 4-week period was based on a churn analysis by him suggesting that 70% of consecutive purchases on Fortnite on the Play Store and Android were less than 4 weeks apart.
1759 On the other hand, as I have already said, Professor Goldfarb assessed diversion by reference to a 4-week post-period compared to a 4-week pre-period, as well as 13, 26, and 52-week post-periods compared to a 13-week pre-period. He indicated that extending the analysis to longer, that is, 13, 26 or 52-week time periods was preferable because, for analyses which rely upon data before the season release, that is, the weeks of 17 and 24 August 2020, using a longer period of time attenuates the effect of the ambiguity associated with this period. He also explained that considering a longer window allows for more balance across Fortnite seasons. As to this point, because Fortnite was only made available in April 2020, 13 weeks was the longest period assessed which allowed for balanced pre- and post- periods.
1760 Consistently with these considerations, Professor Goldfarb considered his estimate of diversion based on a 13-week pre- and post-period excluding the weeks prior to the season release to be the most reliable.
1761 Further support for the 13-week period is provided by Professor Goldfarb’s reasoning and his correction to Professor Asker’s churn analysis.
1762 Professor Goldfarb accepted that the typical interval between purchases helps identify an appropriate window of analysis. But Professor Goldfarb identified that Professor Asker’s churn analysis was not considering the average time between purchases on a user level, and that Professor Asker’s result that 70% of consecutive purchases were less than 4 weeks apart could be biased by a small number of users making a large number of repeated purchases.
1763 Professor Goldfarb identified that when purchases are considered on a user level basis, in fact 70% of users had an average period of around 10 weeks between consecutive purchases, rather than 4 weeks.
1764 Accordingly, applying Professor Asker’s criterion would lead to the conclusion that a time window in the order of 10 weeks is an appropriate window of analysis to consider diversion. That gives further support to the symmetric 13-week periods selected by Professor Goldfarb.
1765 Further, Google did not attempt to engage with why, when measuring diversion to the Galaxy Store and Samsung, the weeks of 17 and 24 August 2020 should not be included.
1766 Further, there is nothing inconsistent with the proposition that nothing very much happened in the two weeks following the hotfix, but that effective removal after 27 August 2020 was an extreme event.
1767 Let me turn to another topic.
Professor Goldfarb’s diversion estimates
1768 Now Google says that Professor Goldfarb said in his opening statement that he preferred the yellow shaded columns of his table 11.A, save for the 4 week specification, and all specifications in table 11.B.
1769 And according to Google, in cross-examination, Professor Goldfarb’s position became further refined.
1770 It is said that he conceded that he was not putting forward any 4 week specification as preferred, even in table 11.B. Further, it is said that he accepted that the 13 week specification was not preferred to the 26 or 52 week specification if the first two weeks after the hotfix are included, that is, the 13 week specification in table 11.A was not preferred.
1771 As to the 13 week specification in table 11.B, which excludes the first two weeks after the hotfix, Google say that Professor Goldfarb said he was more comfortable with this when those two weeks are removed. But Google says that Professor Goldfarb also accepted that he viewed 13 weeks as a short period, had said in the joint report that he preferred longer periods than 13 weeks, and had described 52 weeks as the preferred time period in his Apple reply report.
1772 So, in context, Google says that when Professor Goldfarb said he was comfortable with the 13 week specification in table 11.B, he was not saying this was preferred.
1773 Google says that the effect of Professor Goldfarb’s evidence was that his preferred specifications were the 26 and 52 week specifications in tables 11.A and 11.B. And so Google says that the result is that Professor Asker and Professor Goldfarb were in agreement that I should at least rely on the 26 and 52 week specifications in tables 11.A and 11.B.
1774 Google says that this has implications for the market definition analysis.
1775 It shows that the diversion ratio in spending to the Galaxy Store ranged between 10.1% and 12.1%, much lower than the 27.8% to 34.9% diversion ratio to non-Android sources, and lower than the diversion to Xbox or PlayStation on the 52 week specification.
1776 In other words, the regression analysis indicates that non-Android platforms, that is, app stores on gaming consoles and PCs, are closer substitutes than other Android app stores.
1777 But I do not accept Google’s position on this aspect. Again, I have accepted the position of Epic and Professor Goldfarb.
1778 Initially, Professor Goldfarb said that in the context of estimating diversion to the Galaxy Store and Samsung, he was comfortable with all of the estimates in table 11.B at 4, 13, 26 and 52 weeks, giving a range of approximately 10 to 18% and that his most preferred estimate was the 13-week estimate of 15.8%. He explained that the 13-week estimate was best because it had an equal number of weeks on either side with one new Fortnite season on either side.
1779 In cross-examination, Professor Goldfarb also said that each of the 4-, 13-, 26- and 52-week estimates in table 11.B provided a reasonable range of estimates. Professor Goldfarb again said that the 13-week estimate was the best estimate.
1780 Now it was put to Professor Goldfarb that he had stated a preference in the joint expert report for 26- or 52-week estimates. But as Epic says, Professor Goldfarb indicated that that was in a particular context, being in circumstances where the two weeks commencing 17 and 24 August 2020 were included, and in the context where Professor Goldfarb was focusing his attention on overall diversion rates.
1781 As Epic says, his evidence was that when you did not have those “ambiguous” two weeks, he was more comfortable with a 13-week analysis. This is consistent with his earlier evidence that the 13-week specification was the most preferred.
1782 I agree with Epic that in circumstances where Professor Goldfarb’s evidence was never challenged directly on that aspect, Google’s assertion that Professor Goldfarb’s preferred specification was for 26 or 52 weeks is not open.
1783 In any event, a symmetric period is preferable given that it avoids confounding events by having the release of one new Fortnite season on either side of the event. And as Professor Goldfarb explained, in the Apple proceeding Professor Goldfarb had additional data so that symmetric 26 and 52-week pre and post periods could be constructed.
1784 Further, a 13-week estimate is an appropriate time period having regard to gross churn rates.
1785 Finally, it is not correct that Epic has sought to just fasten on the highest of Professor Goldfarb’s Galaxy Store diversion estimates. The highest estimate in table 11.B was 18.7%. The 13-week estimate was 15.8%.
Conclusions
1786 Professor Asker said that he considered the best estimates to be those recorded in exhibit 158 of his first report, table 11.A in Professor Goldfarb’s reply report, and the 26- and 52-week specifications in table 11.B in Professor Goldfarb’s reply report.
1787 Professor Goldfarb said that he considered that the best estimates were the 13-, 26-, and 52-week specifications in table 11.A and all specifications in table 11.B of his reply report.
1788 Now Google made the following points concerning its preferred diversion estimates based on different regression specifications.
1789 First, it says that diversion to the Galaxy Store ranges from 9.4% to 13.2% across all specifications, which means that Epic’s candidate market fails the HMT on the 14.5% critical loss threshold calculated by Professor Asker. It says that this conclusion remains true when much lower pass-through rates are used.
1790 Second, it says that diversion to a console transaction venue, particularly PlayStation and Xbox, is equal to or larger than diversion to the Galaxy Store in 5 out of the 8 specifications.
1791 Third, it says that diversion to a console transaction venue, particularly PlayStation and Xbox, is larger than diversion to sideloading in every specification.
1792 Fourth, it says that diversion to non-Android venues is larger than diversion to Android venues in every specification.
1793 But in my view and having regard to the evidence, the estimates of diversion which are based on a percent difference in differences are more reliable than those using levels. Further, I am satisfied that the inclusion of the three weeks of 10, 17 and 24 August 2020 is inappropriate for an analysis which attempts to calculate diversion to the Galaxy Store, particularly when relying on a more time limited window.
1794 Finally, I have given the most weight to the Professor Goldfarb’s estimate of diversion based on an analysis window of 13 weeks, as this window provides for the most balance across Fortnite seasons and seasonal effects.
1795 So, I accept Professor Goldfarb’s evidence of the following matters.
1796 First, the most reliable estimates of diversion are the highlighted estimates for 13 weeks in table 11.B of Professor Goldfarb’s reply report, which calculate that 15.8% of revenue was diverted to the Galaxy Store. I have already set out tables 11.A and 11.B.
1797 Second, beyond this, a range of reliable diversion estimates is provided by the highlighted estimates for 13, 26 and 52 weeks in table 11.A, and all the highlighted estimates in table 11.B, indicating that between 10.1 to 18.7% of revenue was diverted to the Galaxy Store.
1798 The results in table 11.B also show that approximately 50% of all revenue was lost following removal, that is, they range from 45.8 to 54.7%.
1799 Further, they show that there was substantially less diversion to consoles than is indicated by Professor Asker’s estimates.
1800 In summary then, Professor Asker’s conclusion that consoles are closer competitors to the Play Store than other Android app stores is not supported by the data.
Other matters
1801 Professor Asker said that the key insight from his Fortnite analysis was not just that consoles were a constraint, but that developer substitution possibilities to non-Android venues were meaningful and to some extent constrained the Play Store.
1802 But as Epic points out, there is an inherent asymmetry in the extent to which quantitative analysis of Fortnite and the Fortnite removal event can inform market definition. That asymmetry has two aspects as Epic correctly described.
1803 As Epic explained, the first aspect of the asymmetry relates to relative rates of substitution between Android apps and apps on non-mobile devices. Because Fortnite is an app that has an unusually high degree of cross-platform functionality, a conclusion that Fortnite users might substitute from Fortnite on Android to Fortnite on other devices says very little about substitution in relation to other apps where cross-platform functionality is limited. Contrastingly, if the analysis shows that even users of Fortnite are unlikely to substitute to other devices, then a fortiori the same result will hold for apps with more limited cross-platform functionality.
1804 In relation to this first aspect, Fortnite’s cross-platform functionality is unusually broad, even among games apps. In order for users to be able to substitute across platforms, in particular from Android to games consoles, games must be available on both platforms.
1805 Professor Asker’s exhibit 55 shows the top 25 games apps by 2021 Australian Play Store consumer spending. The exhibit focused on cross-wallet and cross-progression functionality across platforms. Having cross-wallet and cross-progression functionality across platforms permits spending and play across different platforms, but only across those platforms on which the game is available.
1806 As Epic pointed out, figure 13 of Ms Edwards-Warren’s reply report compared the availability of Fortnite with the 25 apps from Professor Asker exhibit 55. It showed that at the time of the removal, being 13 August 2020, Fortnite was available on Android, iOS, PlayStation, Xbox, Switch and PC. As of 29 February 2024, Fortnite was no longer available on iOS but was available on streaming services in addition to Android, PlayStation, Xbox and Switch.
1807 Of the top 25 gaming apps on the Play Store, only two out of 25 are available on console: PlayStation and/or Xbox. None are available on Switch.
1808 Five of the top 25 gaming apps on the Play Store are available on mobile platforms only: Android and iOS. Their users have no substitution options to console, and no substitution options to PC. These five games account for 20% of the top 25 games apps and [REDACTED] of Australian consumer spend on in-app purchases of digital content across the 25 game apps in 2021.
1809 The remaining 18 out of the top 25 are available on at least one PC platform as well as mobile platforms, being Android and iOS.
1810 So, as Epic said, Fortnite results with respect to substitution from mobile to console generalises to potentially only two out of the 25 top games apps on the Play Store. I agree with Epic that with such limited cross-platform functionality for the highest revenue games, conclusions with respect to diversion to consoles cannot be extended to apply to games apps more broadly or to non-games apps, except insofar as the Fortnite results show limited diversion.
1811 Further, as Epic pointed out, the second aspect of the asymmetry relates to absolute levels of substitution in light of the Fortnite removal event. Given that the Fortnite removal event is not a SSNIP, and is analogous to an infinite price increase, this entails that absolute diversion levels can only be informative in one direction.
1812 Low levels of substitution in response to complete removal logically suggests even lower levels of substitution in the case of a SSNIP. Contrastingly, even if there were high levels of substitution in response to complete removal, this would say nothing about the absolute level of substitution in the case of a SSNIP.
1813 In other words, Fortnite data and the Fortnite removal event can really only provide evidence in one direction. For Epic, quantitative analysis of Fortnite can provide useful positive evidence in support of Epic’s proposed markets. But for Google the evidence is neutral.
1814 Now as I have already indicated, Professor Asker relied upon his calculation that following the removal event Australian Play Store users divert approximately 80% of their spending to other platforms, to conclude that other transaction venues are substitutes for the Play Store.
1815 But as I have already discussed, this was based on Professor Asker’s inappropriate levels difference in differences methodology, which produced much higher levels of diversion to consoles and other platforms overall. The correct figure on Professor Goldfarb’s analysis, which I have accepted, was that approximately half of spending (45.8 to 54.7%) was lost following removal.
1816 But I agree with Epic that even if Professor Asker’s figure was right, it could not support any conclusion that non-mobile platforms were substitutes for Android apps in response to a SSNIP.
Logit demand model, transition probability analysis and counting of diversion estimates
1817 Now the purpose of the logit demand model is to generate diversion ratios, and the purpose of diversion ratios is to inform substitution, which is the basis for defining relevant markets.
1818 As Google explained, the logit demand model translates observed consumer choices among a viable choice set into estimates of diversion and substitution. Indeed Google went so far as to say that it is an economically rigorous way to perform that translation where the assumptions needed to draw inferences are made explicit.
1819 Now the architecture of the logit demand model means that diversion is proportional to spending shares. If consumers choose one transaction venue more than another out of the available choice set, the logit model says that there will be more diversion to that transaction venue.
1820 And as Mr Moore SC explained, the logit demand model formalises an underlying economic intuition, being that the realised choices consumers make among a set of possible alternatives is informative as to properties of consumer demand like substitution. Indeed, usually such revealed preference analysis is preferable to an analysis of hypothetical choices such as may be the subject of a survey.
1821 Now Professor Asker used the logit demand model in the present context to derive a measurement of diversion to the iOS App Store which was not possible from available natural experiments like the hotfix. Diversion estimates from Professor Asker’s logit model exercise were said by Google to corroborate diversion estimates from the analysis of the hotfix.
1822 In Professor Asker’s view diversion to non-Android transaction venues was greater than diversion to other Android transaction venues. In his view this also indicated that diversion to the iOS App Store was quantitatively meaningful.
1823 Professor Asker examined how Fortnite users that downloaded Fortnite from the Play Store spend on Fortnite. These are users for whom the Play Store is a demonstrably viable transaction venue. As is obvious, if they choose not to spend via the Play Store that means that they may instead be allocating their spending via a different transaction venue, such that the Play Store is losing out on potential business to that alternate transaction venue.
1824 Now Professor Asker presented the data on how Fortnite Play Store users spend on Fortnite. In his view, what the data reveals is that Fortnite Play Store users overwhelmingly spend outside the Play Store, and indeed primarily spend via non-Android venues like console stores.
1825 But, in summary, I agree with Epic that the logit model put forward by Professor Asker has some problematic features.
1826 First, it does not provide new evidence additional to spending data.
1827 Second, it is relied upon by Professor Asker to support his conclusions about market definition but it is itself driven by assumptions regarding the boundaries of the market.
1828 Third, the independence of irrelevant alternative (IIA) assumption, an essential technical condition for relying upon a logit model, does not hold.
1829 Now the logit model allocates diversion shares proportionately to market share. Moreover, it was not in doubt that most user spending on Fortnite occurs on consoles and PCs.
1830 Professor Asker showed that the majority of the spending of Fortnite users who downloaded Fortnite on Android smart mobile devices occurs via consoles, with consoles accounting for 75.6% of the user spending of all Fortnite users on Android smart mobile devices in Australia between 20 April 2020 to 9 August 2020. The equivalent figure for Fortnite users downloading Fortnite via the Play Store is 71.5%.
1831 But given that the logit model represents spending shares, as Epic rightly said it is unsurprising that when consoles are assumed to be in the market, one finds diversion to consoles.
1832 Accordingly, in my view the logit model as applied by Professor Asker is not informative about market definition in this case. It does not independently provide information about market definition. As Epic pithily put it, it simply represents market shares in a claimed market, the boundaries of which have been assumed. By assumption, it generates more diversion to devices with higher shares of spending such as PlayStation.
Professor Asker’s evidence
1833 Let me begin by setting out some evidence of Professor Asker.
1834 The logistic model, typically referred to as the logit model, is a popular model in modern industrial organisation economics. It belongs to a group of economic models called discrete choice models which economists use to explain how agents choose one option from a set of alternatives, often referred to as the choice set. So, an economist can use the logit model to analyse purchase data from the cereal aisle of a grocery store, including the prices, number of boxes bought, and characteristics about each cereal available, to estimate how price sensitive consumers are and the substitution patterns between cereals.
1835 Choice sets must exhibit several properties for a discrete choice model to be appropriate for a given setting. First, the alternatives must be mutually exclusive, choosing one option means that none of the other alternatives are being chosen. Second, the choice set must include all relevant alternatives to the decision maker. Last, there must be a finite number of alternatives. In practice, economists include an alternative referred to as the “outside option” in the choice set. The outside option typically represents the option not to purchase any available alternative. So, it can represent a consumer choosing to not to spend their money or purchase another option not in the choice set.
1836 Now the logit model assumes that the utility provided to consumer m, from buying product i, takes the form:
1837 The index i =1..., J indexes items in the choice set. J is the total number of products in the choice set. xj typically represents qualities of the product that provide utility to the consumers. pj represents the price the consumer pays for product j.εim represents any taste consumer m has for good i that is not explained by good ’s characteristics and price.
1838 The coefficients α and β represent the taste for each characteristic and price sensitivity, respectively. It is implicitly assumed, through this utility function, that consumers only differ from each other through the εim term. The logit model explicitly assumes that all εim terms are independent of each other. In other words, any additional taste beyond what is explained by xi and pi that consumer m has about good i is unrelated to their additional taste for good j and consumer m’s additional taste for any good is unrelated to all other consumers additional taste for that good.
1839 Because economists do not typically have information about εim, they must make assumptions about its distribution amongst individuals in the market. This distributional assumption has allowed economists to derive straightforward mathematical equations from the model, which is a large reason for the logit model’s popularity.
1840 Now the formulae for diversion ratios and price elasticity of demand, which are commonly used concepts in a quantitative application of the HMT, are as follows.
1841 The diversion ratio from product i to product j under the logit model is:
1842 The cross-price elasticity from product i to product j under the logit model is:
where sj represents the choice share of good j and α is the same parameter from the utility function defined above.
1843 In the above formulations, the share of good j (sj) represents how often good j is chosen, which can be measured using metrics such as the share of consumers that choose good j, when estimating the model on the aggregate level, or the probability that a given consumer chooses good j, when estimating the model on an individual level.
1844 Now the logit model can be written down in terms of market shares, which of course reflect the proportion of individuals that choose a particular product. This can be aligned with the likelihood that an individual chooses a particular product. Such a likelihood multiplied by the total number of consumers can provide a measure of the demand. So, demand and market shares are related.
1845 Now another implication of the logit assumptions is the IIA property.
1846 The IIA assumption means that if a new alternative is introduced or removed from a choice set, the relative probability of choosing good j compared to good k, that is, the ratio of those probabilities, does not change. In other words, under the IIA assumption in a logit model, if consumers lose or gain access to one alternative, then the ratio of shares for all other products remains the same.
1847 Although this property implies substitution patterns that may not be realistic in some scenarios, it also gives economists a way to test if the logit model is appropriate in any given setting. In the economics literature, the substitution pattern that the IIA assumption leads to is known as the red bus – blue bus problem. I will return to this later.
1848 If the data shows that the ratios of choice shares of the existing or remaining alternatives after entry or exit of an alternative are relatively similar, then the logit model is consistent with observed patterns of substitution. Professor Asker tested the IIA assumption in the context of Fortnite spending.
1849 Now the logit model relates diversion ratios to choice shares, but calculating a diversion ratio requires knowing the choice share on the outside option.
1850 But when applying the logit model to the Fortnite data, Professor Asker could not observe spending by Fortnite users on any outside option. He only observed their spending on Fortnite. So, he did not observe the full choice shares of Fortnite users because in the logit model any choice set includes the outside option. Instead, he could only observe the choice shares within Fortnite spending.
1851 Now Professor Asker estimated diversion ratios based on his difference-in-differences regression, which were based on the change in spending amounts and could therefore be estimated as standard diversion ratios. Put differently, he only observed a normalised choice share that is the relative share excluding the outside option:
1852 In the above formula, si refers to the share of product i, s0 refers to the actual share for the outside option, and ŝi refers the normalised share of product i.
1853 Professor Asker purported to show that under a logit model, the ratios of normalised shares that he did observe corresponded to a normalisation of diversion ratios. He put forward the following analysis.
1854 The diversion ratio from product i to j implied by the logit model is:
1855 For convenience he denoted:
1856 Because this formula depends on the share spent on the outside option, he could not estimate it from the data he analysed. Instead, one can estimate a normalisation of diversion ratios, which eliminates the denominator.
1857 So, he let J represent the set of transaction venues, that is, all options excluding the outside option. And he let J ⁄ i represent the set of transaction venues excluding i. Total diversion from i to all the inside options is then:
1858 With this, one can estimate, , the normalised diversion ratio from i to j as:
1859 He said that the normalised diversion ratios from product i to another product j are like the standard logit model diversion formula but using their normalised shares, which he observed in the data.
1860 He said that the interpretation of the normalised diversion ratio addresses the following question: if a firm increases the price of i, of the customers that leave but do not choose the outside option, what percentage will go to product j? He said that this was informative about diversion within the inside options but could not be used to infer the extent of diversion to the outside option.
1861 So Professor Asker’s position was that if he examined spending by Fortnite Play Store users across transaction channels, he could infer normalised diversion ratios by using the distribution of their spending across transaction channels.
Ms Edwards-Warren’s evidence
1862 Let me at this point set out some evidence given by Ms Edwards-Warren.
1863 Ms Edwards-Warren considered that the logit diversion ratios calculated by Professor Asker were not informative about how Fortnite users of the Play Store substitute to other platforms, and hence about which platforms are in the same anti-trust market as the Play Store.
1864 She explained the following matters.
1865 First, she explained how the normalised diversion ratios implied by the logit demand model presented by Professor Asker have been calculated using only data on the expenditure shares of all platforms.
1866 Second, she explained that the logit diversion ratios calculated using these shares of expenditure can only be interpreted as actual diversion ratios, that is, diversion ratios that reflect the actual substitute patterns of Fortnite users, due to Professor Asker assuming that all platforms are substitutes and that Fortnite users substitute to all of these platforms in the restrictive manner assumed by the logit demand model.
1867 Third, she explained why the test of the IIA assumption of Professor Asker is not a reliable test of the IIA assumption made by the logit demand model, and why the IIA assumption does not hold.
1868 Further, her position was that although Professor Asker calculated the normalised diversion ratios implied by the logit demand model, these logit diversion ratios merely reflect the restrictive assumptions about Fortnite users’ behaviour made by the logit demand model used by Professor Asker, and so as a consequence, these normalised logit diversion ratios provide no evidence as to which platforms Fortnite users consider as substitutes for the Play Store as a platform, and so no evidence on which of these other platforms are in the same market as the Play Store.
1869 Let me say something more about Ms Edwards-Warren’s evidence as to how the logit diversion ratios have been calculated.
1870 In her view, Professor Asker’s logit diversion ratios are simply the result of assuming that Fortnite users substitute to platforms that Professor Asker assumed are substitutes for the Play Store, in the way assumed by the logit model.
1871 The logit demand modelling is essentially a transformation of the Fortnite spend data discussed by Professor Asker. The logit model of Professor Asker estimated diversion ratios from Fortnite spend on the Play Store to other transaction venues by assuming that users switch to other platforms in proportion to each platform’s market share of the assumed market.
1872 Now she articulated the steps in this analysis to illustrate what was occurring.
1873 The logit analysis of Professor Asker started with the assumption that the Play Store competes in a market that includes console stores, the Apple App Store, the Samsung Galaxy Store, and PC stores. And it assumed a high proportion of Fortnite spend occurred on consoles (71.5%) during the period of analysis. The analysis found that most switching from the Play Store goes to console stores. This is because the analysis assumed that switching to alternatives occurs in proportion to market shares.
1874 Further, it assumed that a higher proportion of Fortnite spending occurred on the Apple App Store than on the Samsung Galaxy Store during the period of analysis. And on this basis, the analysis found that users are more likely to switch from the Play Store to the Apple App Store than to the Samsung Galaxy Store.
1875 Further, it assumed that a higher proportion of Fortnite spending occurred on PC stores than on the Samsung Galaxy Store during the period of analysis. On this basis, the analysis found that users are more likely to switch from the Play Store to PC stores than to the Samsung Galaxy Store.
1876 But according to Ms Edwards-Warren, this assumption driven analysis is circular. The analysis conveys no information about market definition that has not been pre-assumed. I have no doubt that she would agree that it is about as useful for real world analysis as an analytic statement is in philosophy where the predicate is necessarily and wholly included within the definition of the subject.
1877 As a consequence, she said that these logit diversion ratios provide no evidence as to which platforms Fortnite users who use the Play Store actually consider to be the largest and closest substitutes for the Play Store as a platform.
1878 She said that they can therefore provide no independent evidence as to which platforms are in the same relevant market as the Play Store because the answers are driven by the starting assumptions.
1879 Let me say something further about her views on the normalised diversion ratios of Professor Asker.
1880 As I have said above, Professor Asker presented normalised logit diversion ratios, which rely on the assumption that the logit demand model accurately captures how Fortnite users would substitute to other platforms when purchasing in-app content, particularly those Fortnite users who used the Play Store to purchase in-app content.
1881 As Ms Edwards-Warren said, the logit diversion ratios of Professor Asker were normalised diversion ratios because they did not take account of the possibility that some Fortnite users might substitute to an outside product in response to an increase in the costs of purchasing in-app content via a platform.
1882 Professor Asker explained that due to the restrictive assumptions about consumers’ preferences for substitute products made by the logit demand model, it is possible to calculate diversion ratios using only data on market shares. Professor Asker used each platform’s share of total expenditure of Fortnite users’ expenditure on in-app content to calculate the diversion ratios from the Play Store to each of the other platforms.
1883 Now the implied logit diversion ratios were calculated using the expenditure shares as follows:
where (𝐸𝑆PS) is the expenditure share of the Play Store (𝑃𝑆) and (𝐸𝑆i) is the expenditure share of platform 𝑖.
1884 But as she said, Professor Asker did not estimate these normalised logit diversion ratios econometrically, and did not econometrically test the restrictive assumptions made by the logit demand model.
1885 Now using data for the period during which Fortnite was available on the Play Store, Mr Edwards-Warren’s table 30 presented the expenditure shares for each of the platforms and the implied logit diversion ratios calculated using them, being the implied logit diversion ratios shown in Professor Asker’s exhibit 64.
1886 Ms Edwards-Warren’s table 31 presented equivalent figures but used the expenditure shares for the four-week period before the Fortnite removal event. These are shown with the logit diversion ratios shown in Professor Asker’s exhibit 159.
1887 As the logit diversion ratios of Professor Asker are calculated using each platform’s share of Fortnite users’ total expenditure on in-app content, these diversion ratios merely reflect the relative importance of each platform in terms of this expenditure.
1888 Given this, Ms Edwards-Warren said that it is not surprising that PlayStation and Xbox have the largest diversion ratios since these platforms have the largest shares of total expenditure.
1889 Let me set out some further points made by Ms Edwards-Warren.
1890 Professor Asker interpreted these normalised logit diversion ratios as actual diversion ratios, because he assumed that Fortnite users who purchase in-app content, particularly those Fortnite users who used the Play Store to purchase in-app content, divert to assumed substitution platforms in the restrictive manner assumed by the logit demand model.
1891 Now Ms Edwards-Warren said that the logit demand model makes two key assumptions about consumers’ preferences in order for diversion ratios to be estimated using only data on market shares.
1892 First, it assumed that consumers consider all the products used to calculate the market shares as substitutes for each other.
1893 Second, it assumed that consumers’ preferences for these substitute products are such that consumers substitute to these products in proportion to these products’ shares of expenditure. This is the IIA assumption.
1894 Ms Edwards-Warren said that in the context of app distribution this means that not only did Professor Asker assume that the response of Fortnite users to an increase in the cost of purchasing in-app content via the Play Store is representative of the response of games app users in general to an increase in the costs of in-app purchases made via the Play Store, but in addition, he assumed the following.
1895 First, he assumed that as well as the Samsung Galaxy Store and the directly downloaded app, PCs, PlayStation, Xbox, Nintendo Switch and iOS are all considered by Fortnite users to be substitute platforms for the Play Store.
1896 Second, he assumed that in response to an increase in the costs of purchasing in-app content via the Play Store, marginal Fortnite users who use the Play Store would substitute to all of these assumed substitute platforms in proportion to these platforms’ relative shares of expenditure.
1897 Ms Edwards-Warren said that if Fortnite users do not behave in accordance with either of these two assumptions, then the diversion ratios implied by the logit demand model are not accurate or reliable estimates of the actual diversion ratios of Fortnite users.
1898 She said that if Fortnite users do not consider PCs, PlayStation, Xbox, Nintendo Switch and iOS to be substitute platforms for the Play Store, for example, because Fortnite users consider these to be complementary platforms, then the logit diversion ratios of Professor Asker will underestimate the actual diversion ratios to the Samsung Galaxy Store and direct download, because by design the logit demand model assumes some diversion to PCs, PlayStation, Xbox, Nintendo Switch and iOS, even though Fortnite users do not consider these platforms to be substitutes for the Play Store.
1899 She said that if Fortnite users consider only the Samsung Galaxy Store and direct download to be substitutes for the Play Store, and substitute between these platforms in proportion to their relative expenditure shares, then the diversion ratios implied by this logit demand model would be 78% and 21% respectively.
1900 Similarly, she said that if Fortnite users consider some of these platforms to be closer substitutes for the Play Store than other platforms, that is, the IIA assumption of the logit demand model does not hold, then the logit diversion ratios of Professor Asker will underestimate the actual diversion ratios to the platforms that are closer substitutes and overestimate the diversion ratios to the platforms that are more distant substitutes.
1901 Ms Edwards-Warren considered that the analysis of critical loss and the Fortnite hotfix event of Professor Asker are flawed and cannot be relied upon for purposes of market definition.
1902 She said that Professor Asker provided no robust evidence to justify the assumption made in the logit demand modelling that Fortnite users who purchase in-app content, particularly those Fortnite users who used the Play Store to purchase in-app content, consider PCs, PlayStation, Xbox, Nintendo Switch and iOS to be substitute platforms for the Play Store.
1903 Further, she said that Professor Asker’s test for the IIA assumption is not a reliable test of the IIA assumption made by the logit demand model.
1904 Now Professor Asker claimed to test the IIA assumption made by the logit demand model, and concluded that the results of this test are consistent with the IIA assumption holding for Fortnite users who purchase in-app content.
1905 If Fortnite users consider all of the platforms to be substitutes, then the IIA assumption means that in response to a change in prices Fortnite users will substitute to rival platforms in proportion to the expenditure shares of each of these substitute platforms.
1906 Now to test whether the IIA assumption holds, Professor Asker compared the ratio of each platform’s share of expenditure to the expenditure share of PCs, before and after the launch of Fortnite on the Play Store in April 2020. If these before and after ratios are similar for each platform, then Professor Asker interpreted this as evidence that the IIA assumption holds for Fortnite users.
1907 But Ms Edwards-Warren said that there were several problems with this test such that it was not reliable. As a consequence Ms Edwards-Warren did not consider that the test of the IIA assumption of Professor Asker provided reliable evidence that Fortnite users behave in a manner consistent with the IIA assumption.
1908 She said that the test is unable to distinguish between all the platforms being substitutes for the Play Store and the IIA assumption holding, and none of the platforms being substitutes for the Play Store. In both cases the launch of the Play Store will result in a pro-rata reduction of the existing platforms’ expenditure shares and hence leave the ratios of these shares to one of them unchanged.
1909 She said that more importantly, the results of the test are sensitive to which platform it uses as the base to calculate the ratios of the expenditure shares before and after the launch of Fortnite on the Play Store.
1910 Now Professor Asker used the expenditure share of PCs to calculate the ratios. But she said that using the expenditure share of iOS results in there being much larger differences between the ratios of expenditure for both PlayStation and Xbox before and after the launch of Fortnite on the Play Store.
1911 Ms Edwards-Warren’s table 32 and table 33 below contain the ratios of the expenditure shares of Australian Fortnite Play Store users, in the top half of the table, and Australian Fortnite Android users, in the bottom half of the table, for the non-Play Store platforms before and after launch of Fortnite on the Play Store using the expenditure share of PC to calculate the ratio, and the expenditure share of iOS to calculate the ratio for each group of users. Ms Edwards-Warren’s table 34 and table 35 contain the equivalent figures for global (excluding China) Play Store users and global (excluding China) Android users, respectively.
1912 Now using the expenditure share of PC to calculate the ratios, Professor Asker said that the differences in the ratios before and after the launch of Fortnite on the Play Store are minor for both groups of Australian Fortnite users, and interpreted this as evidence that the IIA assumption holds for Fortnite users. Professor Asker also found that the differences are minor for global (excluding China) Play Store and Android users.
1913 But using the expenditure share of iOS to calculate the ratios, Ms Edwards-Warren found that there are much larger differences between the ratios for both the PlayStation and the Xbox before and after the launch of Fortnite on the Play Store for both groups of Australian Fortnite users. For both the PlayStation and the Xbox the differences between the before and after ratios are at least four times larger using the iOS expenditure share to calculate the ratios compared with using the PC expenditure share. She found similar large differences for global (excluding China) Play Store and Android users.
1914 Ms Edwards-Warren said that as using a different expenditure share to calculate the ratios has a material effect on the difference between the before and after ratios, and Professor Asker used the size of this difference to test whether the IIA assumption holds, she did not consider the results of Professor Asker’s exhibit 160 to be informative about whether the IIA assumption holds for Fortnite users; I should note that Professor Asker’s exhibit 160 is presented a little later in one of Professor Goldfarb’s tables that I have reproduced.
1915 So, in summary she said that the logit diversion ratios reported by Professor Asker merely reflect the unsubstantiated assumption made by him that Fortnite users who purchase in-app content, particularly those Fortnite users who used the Play Store to purchase in-app content, behave in the manner described by the logit demand model, that is, Fortnite users consider all of the platforms to be substitutes for each other and would substitute to them in proportion to each platform’s expenditure share.
1916 Now I should at this point say something about Professor Goldfarb’s evidence, although I have covered some aspects in my discussion of Professor Asker’s and Ms Edwards-Warren’s views.
Professor Goldfarb’s evidence
1917 Professor Goldfarb explained that in a logit demand model, the estimated rate of substitution to each alternative is simply proportionate to the share of each alternative, so that the ratio of shares remains constant across alternatives.
1918 As he postulated, consider a set of four alternatives, each with a 25% share of current user spending. Under a logit model, if one of these alternatives is removed, users of the removed alternative will substitute to the other three remaining alternatives at equal rates. This is because the remaining three alternatives had equal shares prior to the exit of the other alternative. Prior to the loss of the fourth alternative, the share of each of the remaining three alternatives was 25%, and following the loss of the fourth alternative, the share of each of the remaining three alternatives is one-third. The relative share of the three options does not change. The shares occur in a 1-1-1 ratio before and after.
1919 Professor Goldfarb said that because of the way that the logit demand models consumer choice, it is important that proportionate substitution to alternatives holds in the particular context in which the model is applied. As I have already said, this is the IIA assumption. Under the IIA assumption in a logit model, if consumers lose or gain access to one alternative, then the ratio of shares for all other products remains the same.
1920 Now Professor Goldfarb said that the red bus - blue bus problem is instructive in understanding why IIA is a strong assumption that does not always hold. I have mentioned this problem above, but let me explain it here.
1921 Suppose a commuter has a choice between commuting via a car or via a red bus. The IIA assumption implies that the introduction of a blue bus, being a blue bus that is the same as the red bus apart from colour, would reduce the usage of the car and the red bus in proportion to their respective shares, with the result that their relative share remains unchanged. But in reality, the introduction of a blue bus would reduce the usage of the red bus much more than usage of the car, as the blue and red buses are much closer substitutes than the blue bus and the car.
1922 In A Cameron and P Trivedi, Microeconometrics: Methods and Applications (Cambridge University Press, 2005) it is said (at p 503):
As an extreme example, the conditional probability of commute by car given commute by car or red bus is assumed [under IIA] to be independent of whether commuting by blue bus is an option. However, in practice we would expect introduction of a blue bus, which is the same as a red bus in every aspect except color, to have little impact on car use and to halve use of the red bus, leading to an increase in the conditional probability of car use given commute by car or red bus.
This weakness … is known in the literature as the red bus-blue bus problem, or more formally as the assumption of independence of irrelevant alternatives. It can be tested by a Hausman test (see Hausman and McFadden, 1984). …
1923 Now the IIA assumption may not be realistic in some scenarios. So Professor Asker aimed to test whether the IIA assumption held in relation to Fortnite user behaviour by comparing the relative shares of the channels for Fortnite before it was available on Play Store and while Fortnite was available on the Play Store. He provided his results in exhibit 160 in his report, which are replicated in Professor Goldfarb’s table 12.A.
1924 Upon reviewing Professor Asker’s results, Professor Goldfarb noted that there were large decreases to the relative shares of mobile channels, being a decrease in normalised share of 50% or more for the Samsung Galaxy Store.
1925 Professor Goldfarb noted that there were much smaller decreases to the relative share of consoles. The normalised share of PlayStation decreased by less than 5% for Australian Play Store users and increased by about 5% for Australian Android smart mobile device users.
1926 On the basis of these results, Professor Asker concluded that there were generally similar ratios of normalised shares before Fortnite launched on the Play Store and while Fortnite was available on the Play Store.
1927 But Professor Goldfarb said that on the contrary, he observed disproportionate changes in normalised shares following the launch of Fortnite on the Play Store, indicating a disproportionate pattern of substitution and indicating that the IIA assumption does not hold.
1928 To further test the changes in relative shares, Professor Goldfarb provided in his table 12.B below a reconstruction of exhibit 160 of Professor Asker’s report. In this reconstruction he provided shares normalised relative to the Samsung Galaxy Store, rather than PC, to highlight the decrease in the relative share of Samsung Galaxy Store as compared to PlayStation, Xbox, PC, and Switch. The Samsung Galaxy Store has a lower overall share than PC and using a channel with a lower share can make any relative share changes easier to observe. Professor Asker said that the IIA assumption is valid if the normalised are generally similar before the launch of Fortnite on Play Store and while Fortnite was available on Play Store.
1929 Table 12.B illustrates that the shares of PlayStation and Xbox, relative to other channels, considerably increased following the launch of Fortnite on the Play Store. This holds for both Australian Play Store users and Australian Android users. The normalised shares of PlayStation among Australian Play Store users more than doubled, increasing from 19.8 to 54.1, whilst the PlayStation shares among Australian Android smart mobile device users changed by over 30%, increasing from 19.3 to 26.4.
1930 According to Professor Goldfarb, these results further confirm that the IIA assumption does not hold. So Professor Asker’s application of the logit demand model is inappropriate.
1931 Finally, Professor Goldfarb noted that although there are known extensions of the logit model which allow it to be used in situations where the IIA assumption does not hold, Professor Asker indicated that he did not have sufficiently detailed data to apply these extensions of the logit demand model.
1932 In summary, Professor Goldfarb found that Professor Asker’s logit analysis was flawed and concluded that his associated results were not informative.
Google’s arguments
1933 It is convenient at this point to address Google's arguments.
1934 Now Epic says that the logit model analysis should not be attributed any weight, because it is driven by assumptions regarding the boundaries of the relevant market, but Google says that this suggestion is wrong for the following reasons.
1935 First, Google says that contrary to Ms Edwards-Warren’s claim that Professor Asker assumed the set of products over which to estimate the diversion ratios, Professor Asker’s logit model analysis was informed by the empirical evidence.
1936 Professor Asker’s analysis focused on Play Store Fortnite users and Android Fortnite users and evaluated what transaction venues those users used when spending on Fortnite.
1937 So, his approach was to focus on Fortnite users who could spend via the Play Store and evaluate where they choose to spend. The set of transaction venues included in the analysis are those where users of interest who could spend via the Play Store chose to spend instead. So these are venues to which the Play Store lost potential revenue, and so represent the issue considered in the market definition exercise.
1938 Second, Google says that were Fortnite Play Store users to have only spent via Android app stores or the Play Store, then those would have been the only transaction venues included in the logit analysis.
1939 According to Google, Ms Edwards-Warren’s critique amounts to dismissing the fact that Fortnite users who could have spent via the Play Store chose not to.
1940 Third, Google says that Play Store Fortnite users also spend on Fortnite via non-Android transaction venues. There is no evidence that these realised choices by consumers who could otherwise spend on the Play Store are uninformative of their choice preferences.
1941 Further, Google says that Professor Asker’s logit model satisfies the IIA assumption.
1942 Now as Google pointed out, the assumption needed for the logit model to translate spending patterns into diversion estimates is the IIA assumption. As I have already said, essentially, the assumption states that the likelihood of choosing between options A and B is unaffected by the ability to choose option C.
1943 The IIA assumption can be tested by asking whether observed spending patterns across options in the choice set change when a new option is added.
1944 Now Epic says that the IIA assumption does not hold, and that as a consequence, no weight should be attributed to the logit modelling. But Google says that Epic is wrong for the following reasons.
1945 First, Google says that Professor Asker tested whether the IIA assumption holds by asking whether relative spending shares across existing transaction venues meaningfully changed when Fortnite was first published to the Play Store. They did not.
1946 Professor Goldfarb said that the relative spending shares did change if one was to calculate them relative to the Samsung Galaxy Store. But as Professor Asker explained, that approach simply captures noise due to dividing by small numbers. The issue stems from few people wishing to use the Samsung Galaxy Store to spend on Fortnite even prior to the launch of Fortnite on the Play Store. Professor Goldfarb’s criticism in this respect is misplaced.
1947 Second, Google says that Professor Goldfarb suggested that the removal of Fortnite from the Play Store due to the hotfix can also be used to test IIA, and that what that removal shows is that there is a large change in the share of spending on the Samsung Galaxy Store relative to pre-removal shares. Google says that this point should be rejected, because it is not relevant to IIA.
1948 It says that by removing the Play Store as an option, the share of spending on almost every venue increased. The standard test for IIA accounts for this by comparing the ratio of shares. Professor Goldfarb did not examine the ratios of shares. In contrast, Professor Asker found that these ratios held approximately constant before and after the launch of Fortnite on the Play Store. Professor Asker’s assessment focused on the launch of Fortnite on the Play Store rather than on the hotfix.
1949 Contrastingly, because the hotfix affected both the Play Store and the iOS App Store, it cannot be used to test the IIA assumption without further assumptions being made as to how to treat the removal of two, instead of just one, potential choices. Professor Goldfarb conceded this by observing that “[t]he problem with doing that is that we’re not going to be able to deal with Apple”. But he then provided no explanation of how he would account for this problem. So, Epic’s position in this regard is not maintainable.
1950 Google says that as Professor Asker explained, the basic pattern of how Fortnite Play Store users spend is so stark that even extensions of the logit model that relax the IIA assumption in specific ways are unlikely to yield qualitatively different conclusions as to the importance of different transaction venues as competitive constraints on the Play Store.
Analysis
1951 Let me deal with some central questions.
1952 As I have said earlier, in order for the logit model to hold, the IIA assumption also needs to hold.
1953 As Professor Asker stated, if the IIA assumption is not satisfied, the diversion ratios coming out of the standard logit model are going to be incorrect. Whilst there are extensions to the standard logit model which can be implemented, Professor Asker indicated these would have been impossible to implement because doing so requires a richness of data and variation which he did not have.
1954 In this case, the IIA assumption does not hold. This is reflected in the fact as I have said above that even on Professor Asker’s estimates, diversion from the Play Store to the Galaxy Store following the removal far exceeded what was predicted by Professor Asker’s model.
1955 As Professor Goldfarb explained, it is also evident from a comparison between the graphs in Professor Asker’s exhibits showing Fortnite platform shares. Prior to the Fortnite removal event the share of Play Store user spending for “other Android” is in the order of 1% and is the smallest share. Following the removal the “other Android” share is 31% and is the largest share.
1956 That is a violation of the IIA assumption. The failure of this assumption means that Professor Asker’s logit modelling will not generate correct results and is uninformative about substitution or removal.
1957 Despite these limitations, Professor Asker said that he would not expect his conclusions to change were he to have access to sufficient data to instead use those richer versions of the logit framework. Professor Asker’s assertion is just that.
1958 I reject this claim, particularly considering Professor Goldfarb’s evidence that based on the data he had, he had no information about how those alternatives would play out.
1959 For these reasons, I do not attribute Professor Asker’s logit modelling analysis any weight with respect to substitution or market definition.
1960 Now Google says that Professor Goldfarb’s results disproving the IIA assumption simply result from noise due to dividing by small numbers. But Professor Asker never established that it was due to noise, rather than a disproportionate diversion in violation of the IIA assumption.
1961 Further, if the IIA assumption were true, then upon removal of Play Store, diversion from the Play Store should occur in proportion to the market shares of the other channels assumed to be in the market. But Professor Asker’s relevant exhibit shows that not to be the case.
1962 As I have already said, prior to removal, “other Android” had 0.8% of total “market” share, and was the smallest of all channels. If, following removal of the Play Store, diversion to “other Android” was in proportion to market share, then it should have remained the smallest of all channels. In fact, after removal of Fortnite from the Play Store, “other Android” became the largest channel.
1963 In my view the logit diversion ratios presented by Professor Asker add no new evidence as to which platforms Fortnite users who use the Play Store actually consider as the largest and closest substitutes for the Play Store as a platform.
1964 So, these logit diversion ratios are not informative about market definition in this case. This is because the results of the logit model are driven by the assumptions made on the set of products over which to estimate the diversion ratios.
1965 So, the high diversion to consoles is solely driven by the fact that the majority of user spend on Fortnite is on consoles.
1966 And the assumption that the market includes consoles is based on the results of the hotfix analysis which was not properly conceived.
Transition probability analysis
1967 Let me turn to another topic concerning estimates of diversion using transition probabilities.
1968 Now Professor Asker supplemented his diversion estimates from the hotfix and logit analyses with diversion estimates based on transition probabilities.
1969 According to Google, diversion estimates based on transition probabilities are another way of interpreting baseline switching rates in the raw data. It is said that the value of this exercise is to complement existing diversion estimates by interpreting them through a fresh lens, especially given that the one relevant natural experiment available does not allow for measuring diversion to the iOS App Store.
1970 Google says that the transition probabilities analysis confirms Professor Asker’s findings from other analyses that console transaction venues are the closest competitors to the Play Store for the facilitation of gaming content. Professor Asker considered that the diversion estimates based on transition probabilities are informative when it comes to evaluating the totality of the evidence.
1971 Professor Asker calculated the diversion ratios based on transition probabilities using the observed spending patterns of Fortnite users.
1972 Professor Asker analysed pairs of successive spending events on Fortnite to calculate transition probabilities. According to his evidence, these probabilities answered the question: after a user spends on a transaction venue A, what share of their next spending occurs via transaction venue B?
1973 Professor Asker used these transition probabilities to calculate the implied normalised diversion ratios. These were calculated by assuming that Play Store Fortnite users can no longer spend next via the Play Store, and then using the magnitudes of their transition probabilities to estimate where their spending would most likely divert.
1974 According to his evidence, the identifying assumption behind this analysis is that users divert spending from the Play Store proportionally to where they transition spending in the observed data, which means that users switch in response to a triggering event proportionally to where they were already switching.
1975 Now Professor Asker purported to calculate diversion ratios based on the proportion of transactions which were performed on each non-Play Store channel by users whose previous transaction was on the Play Store.
1976 But I agree with Epic that this analysis does little more than provide an indirect measure of multi-homing amongst Fortnite users prior to the removal. It does not provide any insight into the likely diversion rates which would occur in response to a price or quality change on the Play Store.
1977 In particular, it significantly underestimated the likely diversion to the Galaxy Store in response to such a change, given that one would not expect users who had downloaded the game from the Play Store to also have access to the Galaxy Store version, consistent with Professor Asker’s finding that Play Store users spent the least through “other Android channels”.
1978 Further, transition probabilities do not measure any observed behaviour in response to a price or quality change.
1979 Further, the probabilities calculated in Professor Asker’s exhibit 146 would not be expected to be observed in response to such a change in this case.
1980 As Epic says, the transition probabilities in question are based on an average of immediately consecutive transactions over a period of time. They do not show how spending changes over time.
1981 Further, the fact that the transition probabilities are asymmetric merely shows that console users are more likely to make their next purchase on a console than mobile users.
Counting of diversion estimates
1982 Finally, let me turn to the topic of Professor Asker’s counting of diversion estimates.
1983 Now Professor Asker also provided a meta-analysis in the joint expert report, which summarised the diversion estimates advanced by him and Professor Goldfarb.
1984 Whilst Professor Asker acknowledged in cross-examination that his “80 out of 86” and “70 out of 75” summaries would give equal weight to every estimate and would be problematic if interpreted in the manner put forth by Epic, Google says that properly understood, his main compilation of diversion estimates in the joint expert report, rather than these introductory statistics, is informative.
1985 First, Google says that Professor Asker explained in the concurrent evidence session that the purpose of compiling diversion estimates in the table in the joint expert report was to understand where the experts agree and differ, or where the body of the estimates lie, with respect to the key qualitative takeaways that matter for market definition.
1986 Google says that because there were more than 80 different diversion estimates advanced in Professor Asker’s first report and in Professor Goldfarb’s second report, such a summary, being the figure at page 87 of the joint expert report, helped to clarify the key points of disagreement between them and helped to interrogate the borderline results to understand what drives them.
1987 Google says that what the summary reveals is that the key point of disagreement that matters for market definition pertains to whether to include the two weeks after the hotfix in the post-period or not. This is because almost all other specifications yield similar qualitative results.
1988 Second, Google says that compiling areas of agreement and difference across a range of econometric specifications is important because of the econometric concept of robustness. It says that conclusions that are robust to multiple, correct specifications that vary samples, time periods, and controls are more likely to yield correct inferences than those that are sensitive to these dimensions.
1989 Google says that what Professor Asker’s compilation of diversion estimates revealed is that his key findings are robust. So, it is said that they support his position that diversion to at least one console store is typically as large if not larger than diversion to the Samsung Galaxy Store, with consoles taken together accounting for much larger diversion. Further, it is said that they support his position that diversion to non-Android transaction venues is usually as large if not larger than diversion to Android transaction venues.
1990 Third, Google says that although the compilation included duplicate and intermediate results, as well as including specifications that Professor Goldfarb did not analyse, this is inconsequential for the following reasons.
1991 It is said that Professor Asker’s diversion estimates based on the logit analysis and the transition probability analysis are informative about substitution, and should be considered as part of the totality of evidence. Further, it is said that Professor Asker’s analysis using the levels method are valid estimates of diversion, and preferable to the percent method. Further, it is said that Professor Asker’s analysis, which relied on an assumption of 0% of spending via EDP on Android occurring through sideloading, is valid, especially in the context of the 5-week post-period that Professor Asker analysed.
1992 Google also says that Epic incorrectly said that Professor Asker regarded these estimates as inaccurate. Professor Asker stated that he considers the 0% assumption informative, but that the 50% assumption is likely more accurate than the estimates assuming 0% or 100%. This is different from framing it as inaccurate.
1993 Google says that Epic overlooks that the 0% assumption is Professor Asker’s conservative specification since assuming lower spending via sideloading means that the diversion to the Samsung Galaxy Store is higher. That is evidenced in the results.
1994 Further, it is said that Professor Asker did not include any duplicate or intermediate results in his presentation of diversion estimates in the said figure of the joint expert report, only in the preceding summary of the total number of estimates to which he had regard. The duplicate and intermediate results arose from Professor Goldfarb’s method of presenting the same analyses in multiple tables, or presenting analyses that he viewed as uninformative as to the correct diversion estimate. So it is said that this means that the 46 estimates that Professor Asker provided from his first report are not affected by this criticism and the fact of them being recorded in a spreadsheet is irrelevant.
1995 Further, Google says that removing duplicate and intermediate entries has no effect on the qualitative takeaways of the exercise. Removing the relevant entries does not change the proposition that under most specifications presented, diversion to the Samsung Galaxy Store is too low for Ms Edwards-Warren’s market to be well-defined, diversion to at least one console store is higher than diversion to other Android transaction venues, and diversion to non-Android transaction venues is higher than diversion to Android transaction venues.
1996 Further, Google says that whether or not Professor Goldfarb analysed a particular specification is irrelevant. Professor Asker analysed diversion in spending in his first report without reference to any prior estimates of diversion in spending put forward by Epic’s economic experts, of which there were none.
1997 Further, Google says that Professor Asker’s synthesis of the totality of the evidence through the relevant figure in the joint expert report reflects an effort to assist me by distilling the areas of agreement and disagreement between the experts.
1998 But clearly he had to acknowledge that the vast majority of the summary figures were not robust and could be disregarded.
1999 I agree with Epic, largely for the reasons it advanced, that Professor Asker’s counting exercise was unreliable and did not provide any useful information.
2000 First, this analysis combined and afforded equal weight to estimates of diversion based on methodologies of differing reliability and relevance to the case at hand.
2001 So, Professor Asker included 10 estimates of diversion which are based on the logit and transition probability analysis, which he acknowledged are less useful for measuring diversion than directly analysing user behaviour following the removal.
2002 Further, he included 30 estimates of diversion based on his levels difference in difference methodology which produces nonsensical estimates of negative counterfactual expenditure, 10 of which assumed that 0% of spending through EDP after the removal went through the sideloaded app, something he regards as inaccurate.
2003 Further, he included six duplicate estimates which were individually counted as separate estimates of diversion.
2004 Additionally, as well as being unrealistic or irrelevant, many of the specifications underlying the 46 diversion rates Professor Asker relied upon from his own report were not considered at all by Professor Goldfarb.
2005 So, out of the first 30 estimates Professor Asker included from his own report, 20 related to parameters or assumptions which Professor Goldfarb did not consider, including those directed to diversion globally (excluding China) or based on an assumption of 0% EDP spend through the sideloaded app.
2006 The inclusion of these estimates biased the outcome of Professor Asker’s counting exercise towards alignment with his own results.
2007 The consequence of what I have said is that Professor Asker’s characterisation of the weight of the available evidence in the joint expert report was influenced by the inclusion of diversion estimates which are irrelevant, duplicative, and unreasonable.
2008 Generally, the more appropriate approach was to consider the estimates of diversion which were calculated based on the most appropriate methodologies. Professor Asker’s exercise of taking every diversion estimate and including it provided little assistance.
2009 Further, in the joint expert report Professor Asker purported to use his counting exercise to form direct quantitative conclusions concerning market definition based on his critical loss analysis, rather than attempting to show areas of agreement and difference and what the quality estimates were.
2010 He wrote:
Hence, at this conservative set of inputs, 70% of available estimates indicates that Ms Edwards-Warren’s Android mobile app distributions market fails the HMT.
What this tells me is regardless of the inputs chosen … the weight of evidence on diversion from the Play Store indicates that the Android mobile app distribution market is too narrow. …
Hence, the weight of evidence in this case points to the Android mobile app distribution market failing the HMT.
2011 Professor Asker’s reference to the “weight of evidence” was to the 70% of his useless compilation of estimates, including duplicates and estimates using unreliable methodologies.
2012 In cross-examination, Professor Asker conceded that the counting exercise was not useful in terms of the precise numbers. Once that is accepted, the counting exercise ceases to be relevant. An imprecise counting exercise is worthless.
2013 Further, in relation to the 0% sideloading assumption, Professor Asker was counting analyses which he did not think were accurate and which Professor Goldfarb did not perform. There was nothing conservative about including them, because ultimately the 0% estimates did not lead to a higher number of estimates exceeding Professor Asker’s relevant threshold.
2014 On the other hand, if Professor Goldfarb had calculated estimates based on a 0% sideloading assumption, a greater number of Professor Goldfarb’s estimates would have exceeded Professor Asker’s threshold.
2015 So, the inclusion of the 0% estimates merely biased the counting exercise in Professor Asker’s favour. This highlights the inherent bias in Professor Asker’s method by including estimates in his counting exercise that had nothing comparable in Professor Goldfarb’s analyses.
2016 Further, the results in figure 1 of the joint economic report are based on Professor Asker’s list of estimates which included duplicate and intermediate results.
2017 Further, once one only includes estimates based on the most reliable methodology for estimating diversion to Samsung Galaxy, one is left with Professor Goldfarb’s estimates in table 11.B, which I have reproduced in the previous section of my reasons dealing with the Fortnite removal event and diversion ratios.
Critical loss analysis including the Lerner index
2018 As Professor Asker explained, in the absence of complete data on cross-price elasticities and margins required for a complete quantitative HMT, an empirical tool that economists use to determine whether a candidate market is a well-defined market, but underpinned by the principles of HMT, is a critical loss analysis.
2019 A critical loss analysis first establishes a critical loss threshold that would make a price increase by the hypothetical monopolist unprofitable, and then determines whether actual losses from that price increase would be higher or lower than the critical loss threshold.
2020 In essence, critical loss answers the question: if the hypothetical monopolist raises the price of one product in the candidate market by X% , what percentage of the sales of that product would need to be lost, that is, not recaptured by the hypothetical monopolist’s other products, for the price increase to be unprofitable?
2021 In its standard formulation, critical loss is expressed as a threshold that is a function of the percentage increase in price, X, and the firm’s margins, M. The standard formulation of the critical loss threshold is expressed as a fraction where the numerator is X and the denominator is X plus M. This means that the critical loss threshold increases with a higher price increase and decreases with a higher margin. Actual loss answers the question: if the hypothetical monopolist raises the price of one product by X%, what percentage of sales of that product would be lost due to the price increase?
2022 Let me also couch this concept in profit maximising terms as Professor Asker has done.
2023 Critical loss analysis starts by asking the following question: would a hypothetical monopolist of the candidate market find it profit-maximising to increase the price of one of its products, say Product A, by at least X %? The profit-maximising price increase is at least X % if an increase of twice the size (2X %) is profitable. This occurs when the actual loss in sales, for a 2X % price increase, is less than what is called the critical loss threshold.
2024 To determine the actual loss in sales, one must balance two competing effects. On the one hand, by increasing the price, the firm will lose customers from Product A. On the other hand, the firm, as the hypothetical monopolist, can recapture some of those lost consumers through the other products it owns, that is, everything else in the candidate market except Product A. The amount of lost Product A sales can be calculated using consumer elasticity, where the elasticity can be imputed using the Lerner index. The amount of recapture can be calculated using an aggregate diversion ratio, that is, how much is diverted to all other products in the candidate market.
2025 Critical loss analysis is typically evaluated by estimating an aggregate diversion ratio.
2026 An aggregate diversion ratio answers the question: if the hypothetical monopolist raises the price of one product, what fraction of lost sales of that product does the hypothetical monopolist recapture by other products it owns?
2027 In the present context then, calculating an aggregate diversion ratio for a hypothetical monopolist of Android app stores would answer the question: what fraction of sales that divert from the Play Store in response to an increase in the Play Store’s prices are recaptured by other Android app stores?
2028 Now Professor Asker said that the advantage of a critical loss analysis is that it requires a parsimonious set of parameters to understand when a candidate market is a well-defined market being the aggregate diversion ratio from the product of interest to other products in the candidate market, the margin for the product of interest, and the hypothetical percent increase in the price of the product of interest.
2029 According to Professor Asker, a critical loss analysis usually evaluates a 10% price increase by the hypothetical monopolist, as that corresponds to the hypothetical monopolist finding it profit-maximising to increase prices by at least 5%. I will put to one side for the moment the debate as to the difference between the profitable step approach and the profit maximising step approach when one is dealing with the application of the HMT.
2030 Now a standard critical loss analysis that compares aggregate diversion ratios to the critical loss threshold is predicated on the Lerner index. The Lerner index relates a firm’s margins to the elasticity of customer demand it faces. Obviously the more price-sensitive consumers are, the smaller margins a firm can sustain.
2031 Now the standard Lerner index usually assumes a single set of customers. But this does not apply to the Play Store as the Play Store connects two sets of customers, being developers and consumers, with developers setting the price consumers pay and the Play Store monetising by a fraction of the transaction value.
2032 So, to conduct a critical loss analysis for the Play Store, Professor Asker needed to first derive the relevant Lerner index for the Play Store, and then derive the relevant critical loss formulae.
2033 Now whilst both consumers and developers might substitute away from the Play Store in the event of a price increase, Professor Asker’s resulting platform critical loss analysis focused on substitution by consumers.
2034 The use of critical loss analysis to evaluate markets in which the Play Store competes only allowed for consumer substitution, not developer substitution. So, this means that such analysis is inherently conservative because it does not account for how developers can respond to worsening terms from the Play Store. It assumes that the only way developers can respond is to adjust the price of the content they set for consumers on the Play Store whilst continuing to use the Play Store at the same level of intensity. Now because of this reason, when Professor Asker deployed critical loss analysis, he supplemented it with a discussion of developer substitution possibilities that could further discipline any hypothetical monopolist.
2035 Now compared to a standard critical loss analysis, Professor Asker’s platform critical loss included an additional parameter reflecting the different way that the Play Store monetises. That parameter is the elasticity of developer price with respect to the platform’s service fee, which is also known as the pass-through elasticity.
2036 Now developer pass-through depends on the price elasticity of consumers. The more price elastic consumers are, the more likely developers are to absorb service fee increases instead of passing them through.
2037 Now without directly estimating developer pass-through, an alternative according to Professor Asker is to perform the platform critical loss analysis under different assumptions of developer pass-through. The most conservative approach for purposes of market definition analysis is to consider the value of developer pass-through that corresponds to the lowest consumer price elasticity being full developer pass-through. The platform critical loss analysis therefore seeks to understand whether consumer substitution alone is sufficient to discipline a hypothetical monopolist from raising prices.
2038 Now to perform a critical loss analysis Professor Asker used the diversion ratios calculated based on the hotfix regression specifications, which is a method of conducting the HMT quantitatively. But it only considers the hypothetical monopolist raising prices on one product, rather than all products in the market, as would be required under the HMT.
2039 Both Ms Edwards-Warren and Professor Asker agreed that one way of conducting a critical loss analysis is to follow the approach described in M Katz and C Shapiro, “Critical Loss: Let’s Tell the Whole Story” (2003) 17(2) Antitrust 49.
2040 This approach compares the aggregate diversion ratio, which is the share of sales lost by Google Play that would be recaptured by other products in the candidate market in response to a price increase, to a critical loss threshold. When the diversion ratio is below the threshold, the candidate market fails the HMT.
2041 It was also agreed that in a platform context, the critical loss analysis requires four key inputs being, first, Google Play’s economic margin, second, the hypothetical price increase, third, the developer’s pass-through elasticity and, fourth, the aggregate diversion ratio.
2042 For the first input, Professor Asker used Professor Davila’s estimates of Google Play’s gross margin, which ranged between 74.9% and 80.7% during the relevant period, as the profit input. This usage did not appear to be contentious between the economic experts as best as I could tell in this context.
2043 As to the fourth input, the Samsung Galaxy Store diversion ratio from the hotfix regression analysis was used as the aggregate diversion ratio, because Samsung Galaxy Store was the only Android app store on which Fortnite was available after the hotfix. This did not seem contentious in this context, although it was said by Google that this made the analysis “conservative” so far as it was concerned; this resonated with the line that it continued to push that the Galaxy Store was a weaker substitute than other modes that it said were stronger substitutes.
2044 Now as to the second and third inputs, there was disagreement between Professor Asker and Ms Edwards-Warren.
2045 As to the second input being the hypothetical price increase, Professor Asker’s view was that the relevant price increase to consider for the purposes of conducting a quantitative HMT is 10%, rather than 5% or something between.
2046 He said that this was because a 10% price increase being profitable means that a hypothetical monopolist would find it economically rational (profit-maximising) to increase prices by at least 5%. Professor Asker also used a developer pass-through assumption of 100%.
2047 If those assumptions are made, according to Professor Asker the relevant platform critical loss threshold ranges between 14.5% and 15.4% for the relevant period.
2048 Further, according to Professor Asker and on these assumptions, diversion ratios to the Samsung Galaxy Store based on the 26 week and 52 week specifications in Professor Goldfarb’s table 11.A and table 11.B were well below the critical loss threshold. This meant according to Professor Asker that a 10% price increase by a hypothetical Android app store monopolist would not be profitable.
2049 In other words, on Professor Asker’s analysis Epic’s pleaded Australian Android mobile app distribution market failed the HMT on a 10% price increase. And that being so, the next closest substitutes needed to be included in the market, which according to Professor Asker were gaming consoles or non-Android platforms based on the diversion ratios calculated from the hotfix regression analysis.
2050 Further, according to Professor Asker, he disagreed with Ms Edwards-Warren that the next closest substitute was direct downloads. According to Professor Asker this was because the diversion ratio to direct downloading was far smaller than Xbox and PlayStation and the total for non-Android platforms.
2051 Let me at this point say something about Ms Edwards-Warren’s position.
2052 Ms Edwards-Warren’s main point concerning the second input was that the critical loss analysis should not be done only with a 10% price increase, and other price increases between 5% and 10% should be considered.
2053 Now it was common ground that if a 5% price increase were used, the critical loss threshold would be exceeded, and the candidate market would pass the HMT. Ms Edwards-Warren said that this result, that is, passing at 5% but failing at 10%, indicates that the candidate market definition is “borderline”.
2054 I should note that the basis for the disagreement over which notional price increase should be used principally arose from a difference of opinion concerning the proper application of the HMT when conducting it quantitatively.
2055 As to the third input, as I say, Professor Asker used a developer pass-through assumption of 100%.
2056 Contrastingly, Ms Edwards-Warren’s view was that a 100% developer pass-through is unrealistically high, but she offered no estimate of her own. Instead, she re-ran the critical loss analysis using pass-through rates ranging between 5% and 100%, and Google Play gross margins ranging between 70% and 95%, which were beyond Professor Davila’s estimates.
2057 Ms Edwards-Warren listed the critical loss thresholds for a 10% price increase at every pass-through rate in 5% increments for gross margins between 70% and 95%.
2058 But according to Google, even if the lowest pass-through rate of 5% is assumed, the diversion ratios to the Samsung Galaxy Store based on the 26 week and 52 week specifications in Professor Goldfarb’s table 11.A and table 11.B all remain below the threshold when using a realistic gross margin of 80%.
2059 Further, if one were to use the lowest pass-through rate that Professor Asker considered might be within the reasonable range, that is, 20%, the Samsung Galaxy Store diversion ratios based on the 26 week and 52 week specifications in Professor Goldfarb’s table 11.A and table 11.B are below the threshold on whichever gross profit margin is assumed. In other words, so Google said, Ms Edwards-Warren’s criticism based on pass-through does not materially change the result.
2060 Let me turn to some literature which sets out some useful themes.
Critical loss theory — some literature
2061 It is convenient at this point to set out some extracts from M Katz and C Shapiro (2003) although I have touched on some of the themes above; there has been some paraphrasing by me.
2062 Let me begin with the authors discussion of the SSNIP test and the concept of a critical loss calculation.
2063 Consider a proposed merger between two companies manufacturing prescription sleeping pills. If a single firm controlling all brands of prescription sleeping pills would find it profitable to impose a SSNIP for at least one of the brands sold by the merging parties, then prescription sleeping pills constitute a relevant product market. If not, the next-best substitute, for example, non-prescription sleeping pills, is added to the candidate relevant market and the test is repeated.
2064 As a matter of arithmetic, the effect of a SSNIP on the hypothetical monopolist’s profits depends upon the prevailing profit margin earned on each unit sold and on the percentage of unit sales that would be lost as a result of the price increase. This can be called the actual loss. The maximal percentage of unit sales that can be lost for the price increase to be profitable is known as the critical loss. If the actual loss from a price increase would be greater than the critical loss, the price increase would be unprofitable.
2065 A critical loss calculation can usefully frame the empirical estimation of demand responsiveness for the purpose of delineating relevant product markets. Critical loss analysis is commonly used, both by economists for private parties and by economists in the US Department of Justice and Federal Trade Commission. But critical loss analysis can also be misused.
2066 A common but incomplete and potentially misleading argument based on critical loss analysis has been used to justify broad relevant markets, and it runs as follows. Because the suppliers’ profit margins are high, any lost sales have a large adverse impact on profits, and so even a hypothetical monopolist controlling a group of products could not profitably raise price.
2067 This story is incomplete because high margins also tend to imply that the actual loss is small, and so a price increase might be profitable even when the critical loss is small.
2068 The authors explain a simple approach that uses the aggregate diversion ratio, being the percentage of the total sales lost by a product when its price rises that are captured by all of the other products in the candidate market, to make greater use of the available market evidence.
2069 Their central result is that an aggregate diversion ratio greater than the critical loss creates a presumption that the candidate product market is in fact a relevant antitrust market. This implies that, all other things being equal, higher pre-merger margins, which lead to a low critical loss, tend to support a finding of narrower markets.
2070 Now the HMT examines the profitability of a SSNIP for at least one product, including at least one product of one of the merging firms. One begins by asking the traditional question posed by critical loss analysis: would a given SSNIP yield higher profits for the hypothetical monopolist than do the pre-merger prices?
2071 Consider the effects of raising the price of just one product, Product Z, which is produced by one of the merging parties. A hypothetical monopolist would consider the effect of that price increase on the profits earned on all of the products in the candidate market, not just Product Z. When the price of Product Z rises, some of the sales lost by Product Z will shift to other products in the candidate relevant market. These sales are not lost to the hypothetical monopolist. Indeed, if the difference between price and incremental cost is larger for these products than for Product Z, such diversion of sales actually boosts the monopolist’s profits, thereby making the price increase more attractive on a relative basis. To keep the analysis as simple as possible, one can focus on the case in which all of the products in the candidate market have the same difference between price and incremental cost, P – C.
2072 With this simplification, one can focus attention on the sales actually lost by the hypothetical monopolist when raising the price of Product Z, namely the sales that are lost by Product Z and not gained by any of the other products in the candidate relevant market. For this purpose, it is useful to define the aggregate diversion ratio for a given Product Z. For a given price increase for Product Z, the aggregate diversion ratio is the fraction of overall sales lost by Product Z that are captured by, or diverted to, any of the other products in the candidate relevant market. Suppose, for example, that a 5% increase in the price of Product Z causes the sales of Product Z to fall by 200 units, but the sales of other products in the candidate market to rise by 90 units. The aggregate diversion ratio is then 45%, being 90 divided by 200 and then multiplied by 100.
2073 The aggregate diversion ratio must lie between zero and 100%.
2074 With this definition, the hypothetical monopolist considering whether to raise the price of Product Z will capture a fraction D of any lost sales through increased demand for its other products. So, the hypothetical monopolist effectively loses only a fraction (1 – D) of the sales that are lost by Product Z. The greater the aggregate diversion ratio, the fewer the sales lost by the monopolist, and the more profitable is a price increase. Making use of some algebra, this fact leads to a powerful and surprisingly simple finding when gross margins are large. If and only if the aggregate diversion ratio is larger than the critical loss, then the actual loss is less than the critical loss and so a hypothetical monopolist would find a SSNIP profitable.
2075 Although the comparison of the actual loss with the critical loss tells one whether a given price increase would be profitable, the HMT asks whether the hypothetical monopolist’s profit-maximising [or profitable] SSNIP would be at least as large as the chosen threshold, say 5%. As a rule, increasing the price of Product Z above its pre-merger level will cause the profits of the hypothetical monopolist to rise, reach a maximal level, and then decline. The price that maximises profits is not as large as the price at which profits fall all the way back down to their pre-merger level. As a good working approximation, the profit-maximising price increase is half as large as the maximal price increase that yields profits above their pre-merger level. So, if a 10% price increase would cause the hypothetical monopolist’s profits to be higher than their pre-merger level, then the profit maximising price increase is at least 5%.
2076 This approximation supports the following presumption when gross margins are large:
Given the pre-merger gross margin M, calculate the critical loss associated with a 10 percent price increase. If and only if the aggregate diversion ratio associated with a group of products is at least as large as the critical loss, then this group of products forms a relevant market using a 5 percent price increase threshold.
2077 This is a cautionary result.
2078 For example, with the 90% gross margin used in that SunGard case, the critical loss associated with a 10% price increase would be 10%. Based on this analysis, and assuming the firms were not engaged in coordinated pricing prior to the merger, there would have been a presumption that a hypothetical monopolist controlling all products in the relevant market alleged by the government would find it profitable to impose a 5% price increase for at least one product if and only if the aggregate diversion ratio were at least 10%.
2079 In other words, there would have been a presumption that the candidate market was in fact a relevant market if a total of at least 10% of any sales lost by one product whose price was increased would have been captured collectively by the other products in the candidate market.
2080 But the presumption can be rebutted. For instance, the sample calculations are only an approximation based on the firm’s perceived elasticity of demand at the pre-merger price, in conjunction with the standing assumption that the firms are pricing independently.
2081 Further, all of this analysis concerns a horizontal merger. I should also note that I have discussed the debate concerning profit maximising as compared with profitable elsewhere.
2082 Let me also set out an extract from P Davis and E Garcés, Quantitative Techniques for Competition and Antitrust Analysis (2009, Princeton University Press) at pp 210 to 212, with a little paraphrasing by me.
2083 Critical loss analysis is conceptually closely related to the HMT. It also uses information about demand and in particular the own-price elasticity of demand to make inferences about the price constraint exerted by substitute products.
2084 As I have indicated earlier, the question asked in critical loss analysis is the following: how much do sales need to drop in order to render an X% price increase unprofitable?
2085 In the context of a benchmark homogeneous product model, this question is answered by the following formula:
2086 If the quantity demanded falls by more than 7.7% following the 5% price increase, the price increase is not profitable and the candidate market must be expanded.
2087 At least three issues commonly emerge in applying a critical loss test.
2088 First, the fact that a 5% price increase is not profitable does not mean that a 50% price increase is not profitable. Yet one is interested in market power and would clearly wish to draw narrow market boundaries if one found that a hypothetical monopolist could raise prices by 50%.
2089 Second, it may be argued that the critical loss is likely to be far smaller than the drop in sales that would be experienced by a 5% price increase and therefore a 5% price increase would be unprofitable. When accepting evidence of actual sales declines following price increases, one needs to be careful about the potential endogeneity of price and sales changes.
2090 Third, when considering critical loss calculations, it is very important to bear in mind that if pre-merger margins are high, each unit less of sales is associated with a large fall in profits and so will produce a critical loss in sales that is small. To illustrate, in the case of a 5% price increase the authors obtained the values for the critical loss shown in their table 4.8.
2091 This issue is related to the cellophane fallacy because if the margin is high, it means market power is probably already being exercised and so one must be careful to rely on the effect of price changes on an already supra-competitive price level when drawing conclusions about substitutability and market definition. If the firm has market power, it will increase price up to the point where margins are high and therefore the critical loss appears small.
2092 The fallacy in this analysis is to treat the elasticity and the margin as if they were independent from each other. In fact, according to the benchmark model, margins tells one about the own-price elasticity before the price increase. If margins are high, it implies a low price elasticity and that in turn suggests, perhaps even strongly, there will be low actual losses due to a price increase.
2093 Firms sometimes argue that because their critical loss is small, their actual loss is probably larger and the market should be large. Such arguments should not be accepted uncritically, but rather the firm must explain why they would have a low elasticity of demand evidenced by the high margins and relatively large actual losses of demand following a price increase.
2094 More generally, this is one example of a tension between the pieces of data, being the margin and the likely actual loss resulting from a price rise, and the model which states that the Lerner index is inversely related to the own-price elasticity of demand.
2095 Whenever a model and pieces of data are difficult to reconcile, one must question each. The apparent tensions may be reconciled by the finding that one or more pieces of data are “wrong”, or alternatively that the data is right but the benchmark model is not the correct one for the relevant industry.
2096 It is important to note that the exact form of the critical loss formula depends explicitly on the monopoly model being used to characterise the industry. So, table 4.8 captures the results only of one particular type of critical loss exercise.
2097 Let me now delve into more detail concerning Professor Asker’s approach.
Critical loss analysis for a platform – Professor Asker’s approach
2098 Now Professor Asker first presented the derivations necessary for a standard critical loss analysis as derived by M Katz and C Shapiro (2003) as I have referred to above. He then proceeded to re-derive them to aid with intuition when deriving the modified equations needed for a platform like the Play Store. He then presented the derivations for the critical loss formulae for a platform like the Play Store.
2099 Let me say something about these derivations, re-derivations and the standard critical loss threshold by reference to Professor Asker’s evidence.
2100 As I have indicated earlier, the critical loss in sales is the amount of sales that would have to be lost to make a price increase by the hypothetical monopolist of a candidate market unprofitable. Suppose there is a hypothetical price increase from p0 to p1, where the quantity sold also changes from q0 to q1. Further suppose that the firm’s marginal cost stays fixed at c. Under this setup, the price increase is profitable if:
2101 Professor Asker defined the following terms:
(a) the increase in price (in percent terms) is defined as:
(a) the decrease in quantity (in percent terms and in absolute value) is defined as:
(b) the initial gross margin for the product is:
2102 The above inequality can be rearranged to express the critical loss threshold, which is the maximum possible value of L for the price increase to be profitable:
2103 Suppose the hypothetical monopolist of products in a candidate market increases the price of one product i. This results in a loss of sales from i, but part of this is recaptured by the hypothetical monopolist with other products in the candidate market. One can denote the share of recaptured sales as D∈[0,1], which is the aggregate diversion ratio. The higher the aggregate diversion ratio, the fewer sales lost by the hypothetical monopolist, which makes the price increase more profitable.
2104 Using this setup, one can then express the hypothetical monopolist’s actual loss in terms of the other parameters. Professor Asker derived the expression for the actual loss as follows.
2105 Under the standard Lerner index, the elasticity of product i (ϵ) and the margin for product i (M) have the following relationship:
2106 For an X percent increase in price, the (absolute) percent change in quantity sold is shown by the following formula, but note that the percentage change in quantity sold is approximated by Xϵ for small values of X. This is because represents the percentage change in quantity in response to a 1 % change in price, while represents the percentage change in price, so their product is the percentage change in quantity in response to a X percent change in price:
2107 Because of the recapture, the actual loss for the hypothetical monopolist is:
2108 Using the critical loss formula, this means that the price increase is profitable if A, that is, the actual loss is less than the critical loss, which happens if and only if D>L, that is, the aggregate diversion ratio is greater than the critical loss. This can be seen as follows:
2109 Let me turn to the platform critical loss threshold.
2110 As Professor Asked explained, the difference between the standard critical loss analysis and that for a platform amounts to correctly accounting for developer pass-through, but the overall intuition remains the same.
2111 A platform charges a service fee τ onto the price charged by developers p. For simplicity, assume there is one good on the platform with a representative developer that charges a price of p. These assumptions are reasonable as accounting for developer heterogeneity would not change Professor Asker’s conclusions.
2112 The platform raises its service fee from τ0 to τ1. This results in a change in the price set by developers from p0 to p1 and the quantity sold changes from q0 to q1. In a market that passes the HMT, the service fee increase would be profitable:
2113 Professor Asker defined the following terms:
(d) the increase in the service fee in percent terms is defined as:
(e) the increase in the platform’s marginal revenue (in percent terms) is defined as:
(f) the decrease in quantity, in percent terms and in absolute value, is defined as:
(g) the initial gross margin for the product is defined as:
2114 First, he derived the platform critical loss threshold.
2115 To start, he subtracted τ0p0q1 from both sides of the inequality above and rearrange terms.
2116 He divided each side by τ0p0 and substituted the terms above:
2117 Then he added and subtracted Xpq0 to the right-hand side and re-arranged further:
2118 Professor Asker noted that the net price increase can be expressed in terms of elasticities:
2119 Next, Professor Asker derived the actual loss formula for the platform.
2120 Under the platform Lerner index, the consumer price elasticity (ϵpq), the developer pass-through elasticity (ϵτp), and the margin for product i (M) have the following relationship:
2121 For an X percent increase in the service fee, the (absolute) percent change in quantity sold is:
2122 Because of the recapture, the actual loss for the hypothetical monopolist is:
2123 Using the critical loss formula, this means that the price increase is profitable if A, which occurs when:
2124 In the formula, μ is an adjustment term that is small, positive, and a function of the developer pass-through elasticity.
2125 This means that actual loss is less than the critical loss if the aggregate diversion ratio is greater than a term that is slightly larger than the critical loss threshold.
2126 In M Katz and C Shapiro (2003), the authors recommend using a 10% increase for the critical loss analysis. The logic for this thought experiment is as follows.
2127 The HMT asks if the profit-maximising price increase is at least above the usual threshold of 5%. But a given price increase can be profit-increasing without being profit-maximising.
2128 Under some assumptions, for example, linear demand or close approximations, the profit-maximising price increase is half as large as a price increase that would leave the hypothetical monopolist’s profits unchanged. This is because beyond the profit-maximising price increase, the hypothetical monopolist’s profits will decline up until a point that it reaches the initial profits.
2129 This means that if a 10% price increase is profit-increasing, then the profit-maximising price is at least 5%.
2130 This can be illustrated through an example.
2131 Consider a hypothetical monopolist of two products, which has the following profit function:
2132 Suppose one had a linear demand of the form:
2133 Call the current prices observed as p1* and p2*. Next, consider that the hypothetical monopolist of both products wishes to raise the price of p1 only. The firm would choose the profit-maximising value of p1, while holding constant at p2*, by maximising the following:
where the coefficients A,B,C are a combination of the other constant terms.
2134 This formulation makes it clear that the profit function to be maximised is quadratic in p1. Call the solution to this p1**.
2135 Given that one knows the hypothetical monopolist’s profit-maximising price is larger than the current prices, that is, p1**>p1*, one knows that the firm’s profit function looks as shown in Professor Asker’s exhibit 112 below:
2136 This is because a firm that owns the two rival products would have an incentive to set prices higher than a firm that only owns one of the products. In particular, due to the concavity of the profit function, one knows that there is a price p1M>p1**>p1* such that:
2137 Moreover, due to the symmetry of the parabola, one also knows that p1** is halfway between p1* and p1M.
2138 Now, consider a 10% price increase. If this price increase is profitable, this means that the new price must be between p1* and pM*. This means that there are two cases, both of which imply that the profit-maximising price is greater than 5%.
2139 If the 10% price increase falls between p1*and p1**, we know that p1** is greater than a 5% increase.
2140 If the 10% price increase falls between p1** and p1M, we know that a 5% increase falls between p1* and p1**. This means that p1** is greater than a 5% increase.
2141 A similar logic also applies to the platform case, according to Professor Asker. This means that when analysing the platform critical loss analysis, it is also appropriate to use a 10% price increase.
2142 Consider a hypothetical monopolist of two platforms, which has the following profit function:
2143 Suppose one had a linear demand of the form:
2144 In addition, suppose that the developer price function is linear: pi= fi+gi τi. The service fee τi only enters the consumer demand function through . Call the current service fees observed as τ1* and τ2*.
2145 Next, consider a hypothetical monopolist of both products who wishes to raise the price of τ1 only. The firm would choose the profit-maximising value of τ1, while holding τ2 constant at τ2*, by maximising the following:
2146 In the formula, the coefficients A,B,C,D are a combination of the other constant terms.
2147 This formulation makes it clear that the profit function to be maximised is cubic in τ1. Call this solution τ1**. Due to diminishing returns, economists typically assume that profit functions are concave, which guarantees a solution to the firm’s profit-maximisation problem, that is, firms do not earn infinitely higher profits by setting higher prices. This property ensures that the cubic function set out has a local maximum.
2148 Whilst a cubic function is not symmetric around its local maximum as a quadratic function is, as M Katz and C Shapiro (2003) recommend, one can use a quadratic approximation of the function around τ1**. A common approach for approximating any function is called a Taylor series, which more accurately approximates a function the higher the order of the Taylor series. This means that a quadratic approximation, that is, a second-order Taylor series approximation, will closely approximate a cubic function, that is, a third-order polynomial. This allows one to use a similar logic and apply the 10% threshold as the basis for the critical loss test.
2149 Now putting to one side questions of inputs, the underlying assumptions and other issues between the parties such as the distinction between a profitable step and a profit maximising step, there did not seem to be an issue between the parties concerning Professor Asker’s derivations including his algebra. On a lighter note I should add that although Professor Asker professed to be an Aristotelian in his methods, I suspect that he is a closet Platonist given his predilection for such mathematization and his attraction to pure forms of economic theory such as prioritising the significance of profit maximising steps over profitable steps. Let me turn to the Lerner index.
The Lerner index — general
2150 Professor Asker gave the following evidence concerning the Lerner index.
2151 Determining what constitutes a “high” margin requires an understanding of the institutional features of the market. And what is high in one context may be unremarkable in another.
2152 Now economists may study whether a margin is “high” by examining what the margin implies about customer elasticities using a relationship called the Lerner index.
2153 The Lerner equation states that if a product is priced to maximise the profits from that product, then the proportional gross margin, m, will be the inverse of the elasticity of demand facing the product ε: that is, ε = 1/m.
2154 As I have indicated earlier, the Lerner index reflects the relationship between a firm’s margins and the elasticity of customer demand the firm faces. So, when consumers are less price-sensitive, firms can charge a higher price and enjoy higher margins. What this means is that when a firm’s customers have many alternatives that they can easily substitute to, that is, when customers are very price sensitive so the firm faces very elastic customer demand, then the firm cannot earn high margins.
2155 When economists view high margins as indicative of market power, it is because these high margins are understood to imply low customer price elasticity, indicating that the firm has pricing power.
2156 Professor Asker said that the traditional Lerner index does not apply in this setting because Google in respect of the Play Store does not set prices for customers that choose where to allocate the quantity of transactions from which Google through the Play Store monetises. Instead, the relevant profits depend upon two prices, being the service fee Google sets for the Play Store and the price developers set in response to that service fee. This means that Google sets its prices by considering both how developers respond to its service fee changes as well as the knock-on effect of how consumers then respond to the developer’s price change.
2157 Now according to Professor Asker, the Lerner index traditionally, and the version that he re-derived, cannot account for all possible substitution possibilities by consumers and developers. Instead it accounts for all substitution possibilities by consumers, who choose where to spend their money, but restricts developer responses to adjusting their price for Play Store content.
2158 In this way, even the re-derived Lerner index understates the competitive constraints facing the Play Store.
2159 To take into account these features of the Play Store, Professor Asker re-derived the Lerner index for a platform. The key property of this platform Lerner index is that it relates the Play Store’s margins to two elasticities being the developer pass-through elasticity and the elasticity of consumer demand with respect to prices.
2160 So, Professor Asker needed information on developer pass-through elasticities to draw inferences about consumer elasticities from the Play Store’s margins. Absent this information, he made a conservative assumption of a high developer pass-through elasticity. This is because for a given value of the Play Store’s profit margins, he derived the lowest estimate of consumer elasticity consistent with that margin and therefore, the strongest indicator that the Play Store has market power, were he to assume the highest value of developer pass-through elasticity.
2161 Professor Asker gave the following derivation of the Lerner index for a platform.
Derivation of the Lerner index for a platform
2162 The Lerner index embodies or reflects the relationship between a firm’s margins and the elasticity of customer demand (ϵpq) it faces.
2163 The standard Lerner index for a firm setting a price p for a good it produces with marginal cost c is:
2164 is the total revenue earned by the firm. This is equal to pQ, where is the per-unit price of the good and Q is the quantity sold. TVC is the total variable cost incurred by the firm. This is equal to cQ, where is the per-unit cost of the good and Q is the quantity sold. ϵpq is the consumer price elasticity for the good.
2165 The equation relates the per-unit margin the firm charges to the inverse of the price elasticity of customer demand facing the individual firm. The less price elastic a firm’s consumers, that is, the larger ϵpq is, the higher the per-unit margin the firm can charge. This means that when consumers are less price sensitive, firms can charge a higher price and earn higher margins. So, if the firm operated in a perfectly competitive environment, it would face a perfectly elastic demand curve, that is, consumer price elasticity would be infinite, and so would set a markup of zero.
2166 Now as I have already indicated, Professor Asker explained that the traditional Lerner index does not apply in this setting because the Play Store does not set prices for consumers. Instead, the Play Store sets the service fee faced by developers (τ); the developers then set the price faced by consumers (p).
2167 So, Professor Asker re-derived the appropriate Lerner index for this setting so that the Play Store’s margins relate to two elasticities being the elasticity of consumer demand in response to developer pricing (ϵpq), and the elasticity of developer pricing in response to the service fee (ϵτp). The latter is also known as the elasticity of pass-through which poses the question: by what percent does developer pricing change in response to a given percent change in service fees? He called his formula the platform Lerner index being the following:
2168 Now this formula is more complex than the traditional Lerner index, and no longer relates high margins to necessarily low elasticities of consumer demand. As the platform Lerner index shows, high Play Store margins are consistent with high elasticities of consumer demand whenever pass-through elasticities are low. And for a fixed level of platform margins, the lower the value of the pass-through elasticity, the higher the value of the implied consumer elasticity. This is a direct implication of the platform Lerner index that Professor Asker derived. It is appropriate to set out his derivation, which if I might say so was an impressive piece of work in theory although it had its limitations in the present context which I will discuss later.
2169 Consider the profit function (Π) of a platform such as the Play Store:
2170 is the set of digital content that is distributed via the platform, which are indexed by k. τ is the platform’s service fee. is the platform’s marginal cost for distributing digital content. pk is the price set by the developer for content k. qk is the quantity sold of content k.
2171 Under this profit function, the platform chooses the service fee (τ) to maximise its profits according to the following first-order condition:
2172 Unlike the standard Lerner index, this formulation takes into account that the price set by developers (pk) and the quantity of digital content sold (qk) can be affected by the platform’s service fee.
2173 Now for ease of notation, Professor Asker assumed that there is one good and suppressed the k subscript. This is consistent with assuming that all digital content is distributed by a representative developer, which implies that the developer’s pricing power for their content with respect to consumers is uniform across all content on the platform. He largely made this assumption for mathematical clarity. Allowing for heterogeneity in developer pricing power would make it necessary to keep track of more elasticities, but the intuition of the end result would remain the same. Further in this context, when only a small number of developers make up the majority of the Play Store’s spending, this would be equivalent to focusing only on the content distributed by these competitively meaningful developers. This simplifies the first-order condition to:
2174 Next, he rearranged terms to express this equation as follows:
2175 To simplify this further, he assumed that the quantity of content sold q is only affected by the service fee through the price of the content p. In other words, this assumption means that consumers are only affected by the service fee via the price they pay for the digital content. This assumes, for example, that developers do not change the quality of their product or remove their product from the platform in response to a change in the service fee. Professor Asker said that this assumption was conservative for his purposes. It allowed him to provide intuition that high platform margins are consistent with elastic consumer demand but does not capture the full range of substitution possibilities available to developers. This allowed him to express the above equation as follows:
2176 To express this in similar terms to the standard Lerner index, he noted the following definitions:
(c) TR = τpq is the total revenue of the platform.
(f) TVC = cq is the total variable cost of the platform.
2177 The consumer price elasticity of demand with respect to the price of the content is:
2178 The developer’s price elasticity with respect to the platform’s service fee, that is, the pass-through elasticity is:
2179 Using these definitions, Professor Asker expressed the above equation as the platform Lerner index:
2180 Now according to Professor Asker, this platform Lerner index reveals a key difference from the standard Lerner index. The per-unit mark-up charged by a platform depends on both the consumer price elasticity of demand and the developer’s pass-through elasticity. This means that a platform having high margins can be consistent with consumers having high price elasticities and developers having sufficiently low pass-through elasticities.
2181 And according to Professor Asker, in the case of the Play Store, high consumer price elasticities are consistent with the various estimates of the Play Store’s margins even under an assumption of 100% developer pass-through.
2182 Let me now set out some evidence of Ms Edwards-Warren.
Ms Edwards-Warren’s evidence
2183 Now as should be apparent from what I have set out earlier, Professor Asker used two critical loss equations, being the standard critical loss equation and a platform critical loss equation. The latter accounts for the fact that the Play Store charges a service fee, being a percentage commission, rather than a unit price.
2184 But according to Ms Edwards-Warren, neither is well suited for a market like app distribution which is characterised by high fixed costs, close to zero marginal costs and large economies of scale.
2185 Further, for such markets, Ms Edwards-Warren said that the Lerner index on which the critical loss is based is an inadequate tool for approximating price elasticity.
2186 Further, Professor Asker assumed a 100% pass-through rate from developers to users which was said to be conservative, but according to Ms Edwards-Warren this is incorrect and the test is more likely to be passed with a lower pass-through rate. Ms Edwards-Warren considered it unlikely that the pass-through rate is very high or close to 100%.
2187 Further, she said that Professor Asker used a diversion ratio from the Play Store to the Samsung Galaxy Store calculated from the Fortnite hotfix analysis, which is flawed.
2188 Further, she said that Professor Asker did not consider whether diversion ratios from the Play Store to other Android app stores are suppressed because of the relevant Google conduct.
2189 Let me deal with another point.
2190 The results of the analysis of Professor Asker show that the aggregate diversion ratio is higher than the critical loss threshold when applying a 5% SSNIP, which suggests that the market for Android app stores is well defined. The results show that the aggregate diversion ratio is lower than the critical loss threshold when applying a 10% SSNIP, which suggests that the market should be widened. And Professor Asker argued that these results show that the Android mobile app distribution market fails the HMT and one should rely on the 10% SSNIP threshold.
2191 But Ms Edwards-Warren said that even if the diversion ratios used by Professor Asker were well estimated, which she did not believe they were, she considered that these results were at best borderline, and did not point strongly either to the market being too narrow or too wide. Further, she said that the failure of the test at the 10% level could be an indication of the cellophane fallacy.
2192 In her view, because of these flaws in the design, implementation and interpretation of the test, it is not appropriate to place any weight on the results of the critical loss analysis of Professor Asker.
2193 But even if one accepted the methodology and inputs, she said that the results do not universally suggest that the market should be wider than the Android mobile app distribution market.
2194 Furthermore, the implication of the analysis is that, if one were to accept that the market should be widened, such that the test is re-run to include direct downloading onto Android devices in the market, the test passes under all scenarios.
2195 So, Ms Edwards-Warren said that at most the analysis suggests that the market should include direct downloads in the market for Android mobile app distribution, but not that it should be widened further.
2196 And according to Ms Edwards-Warren, this slightly wider market definition would have a limited impact on her analysis, for example, by slightly changing her market share calculations, and would not have affected her overall conclusions on the effect or likely effect of the relevant Google conduct.
2197 In summary, according to Ms Edwards-Warren, to the extent that I place weight on Professor Asker’s results, the correct interpretation is that the market for Android mobile app distribution might include direct downloads, and that it should not be widened any further. Ms Edwards-Warren explained in detail the reasons for her views and it is appropriate to set out some aspects.
Critical loss equations – standard and platform
2198 Now as she said, a standard critical loss analysis is sometimes used as part of the market definition exercise in competition inquiries. It seeks to determine whether actual losses from a price increase would be higher or lower than the critical loss threshold. If the test finds that the actual losses are higher, that means that the price increase is unprofitable and so the market needs to be widened.
2199 The standard formula to calculate the critical loss threshold is 𝐶𝐿=𝑥/(𝑚+𝑥), where 𝑚 is the percentage margin and 𝑥 is the percentage price increase.
2200 Ms Edwards-Warren’s table 11 below sets out illustrative critical loss thresholds for different combinations of percentage margins for both 5% and 10% price increases. It illustrates how the critical loss threshold decreases as the margin increases.
2201 If a firm earns a margin of 50%, a 5% price increase results in a 9% critical loss threshold. That is, if the actual lost revenue from a price increase over a set of products is larger than 9%, the price increase is unprofitable, which implies that the relevant market is wider than this set of products. If the margin is instead 75%, the actual loss only needs to be larger than 6% to render a 5% price increase unprofitable.
2202 Now as I have explained, Professor Asker extended the standard critical loss formula to account for the sensitivity of developer pricing in response to an increase in the service fee. Professor Asker derived a platform Lerner index to calculate the critical loss threshold. To do so, and as I have explained, he adjusted the standard Lerner index formula to additionally account for the elasticity of developer pricing in response to an increase in service fee. He argued that this adjustment was needed as the Play Store sets service fees for developers, who in turn set prices for consumers, hence a measure of pass-through should be included in the platform Lerner index.
2203 The platform Lerner index formula derived by Professor Asker therefore reflects the relationship between a platform’s margins and the consumer price elasticity of demand and developer pass-through elasticity. It accounts for the fact that the service fee is not imposed directly on consumers.
2204 Using this index, Professor Asker demonstrated that a high margin can be associated with high elasticity of smart mobile device user demand for digital content. Professor Asker used this finding to support the argument that the high margin reported by Professor Davila cannot be used as evidence of Google’s market power.
2205 But according to Ms Edwards-Warren, neither the use of the standard Lerner index nor the specific modification that Professor Asker derived is well suited for use in the present case.
2206 Ms Edwards-Warren said that the Lerner index has significant limitations in the digital world where there are high economies of scale/scope and close to zero marginal costs.
2207 When estimating economic margins and therefore the Lerner index, the only relevant costs are variable costs. Ms Edwards-Warren said that this is a well-known flaw with the Lerner index. A high Lerner index may not reflect market power, but rather a firm with high fixed costs.
2208 Where firms have high fixed costs, they may price substantially above their marginal costs to cover their fixed costs. These substantial fixed costs will lead to a high Lerner-index, whether the market is highly competitive or monopolistic.
2209 The markets relevant to this case are characterised by these features, being high fixed costs, close to zero marginal costs, and large economies of scale.
2210 In E Lindenberg and S Ross, “Tobin’s q Ratio and Industrial Organization” (1981) 54(1) Journal of Business 1, the authors examine the adequacy of using the Lerner index in such markets with high fixed costs and large economies of scale and conclude that (at 28):
… In these cases, the Lerner index is inadequate in explaining market power because it does not recognize that some of the deviation of [price] from [marginal cost] comes from either efficient use of scale or the need to cover fixed costs and does not contribute to market value in excess of replacement cost. …
2211 App distribution is characterised by high fixed costs, close to zero marginal costs and large economies of scale. For such markets, the Lerner index is an inadequate tool for approximating price elasticity.
2212 Further, Ms Edwards-Warren said that the platform Lerner index derived by Professor Asker leads to inconceivably high elasticities under various assumptions.
2213 In particular, exhibit 85 of Professor Asker’s report shows that where the assumed margin is lower, say 34.7% in 2013, the implied price elasticity of demand for the Play Store is 12.5, significantly higher than any of the examples produced by Professor Asker. This high elasticity estimate would imply that demand for the Play Store is more elastic than that of Kellogg’s corn flakes, Mountain Dew, automobile models and Milwaukee’s Best beer, which are all the examples used by Professor Asker.
2214 Given the evidence of the Play Store's very high share of app downloads presented in her first report, Ms Edwards-Warren considered the elasticities inferred from the platform Lerner index to be inconceivably high, reflecting difficulties with relying upon the platform Lerner index.
The inputs into the critical loss equation
2215 Now as Ms Edwards-Warren discussed, the standard critical loss analysis of Professor Asker requires an estimate of Play Store margins.
2216 Professor Asker considered that robust economic margin estimates are not available. He did not have the data that would enable him to accurately estimate them. Nonetheless, to conduct his analysis he proceeded using the accounting margins estimated by Professor Davila and Mr Holt. This was reasonable given the lack of other estimates on file, and notwithstanding that accounting margins and economic margins may vary, with the latter taking into account opportunity cost.
2217 The platform critical loss threshold of Professor Asker required an estimate of Play Store margins, and an estimate of the developer pass-through elasticity which measures the extent to which developers pass on a change in the service fee to users.
2218 To calculate the developer pass-through elasticity, Professor Asker divided the product of an assumed pass-through rate, the percentage service fee and the percentage increase in the service fee, by the percentage increase in service fee.
2219 This calculation reflects the percent by which developer pricing changes in response to a given percent change in service fees.
2220 Professor Asker assumed that the pass-through rate is 100%, that is, that developers pass-through service fee increases in full to users.
2221 But Ms Edwards-Warren did not consider this to be supported by the evidence. Further, Professor Asker said that this assumption was conservative, but Ms Edwards-Warren was of the view that that was incorrect.
2222 She said that the critical loss threshold is lower when a lower pass-through rate is assumed. Given the way that the test was applied by Professor Asker, being an assessment of whether aggregate diversion to Samsung is higher than the critical loss threshold, a lower threshold makes it more likely that the test will pass and the Android mobile app distribution market will be well defined.
2223 Conversely, assuming 100% pass through, as Professor Asker does, makes it more likely that the test will fail and the Android mobile app distribution market will not be well defined.
The actual losses as compared with the critical loss threshold
2224 Now as Ms Edwards-Warren explained, the usual application of a critical loss analysis is to compare the critical loss threshold, which is the percentage lost revenue which would make a price increase unprofitable, and actual losses, to assess whether they are greater or less than the critical loss.
2225 If actual losses exceed the critical loss, then a price increase is not profitable. The HMT fails and the market should be widened.
2226 Professor Asker did not use estimates of actual losses to compare to the critical loss threshold. Instead, he compared the critical loss to estimates of the aggregate diversion ratio from the Play Store to other Android app stores.
2227 Professor Asker relied on a finding in the economic literature that the actual loss is less than the critical loss, and the market is correctly defined, if the aggregate diversion ratio to other products in the candidate market is more than the critical loss. Professor Asker used aggregate diversion ratios instead of actual loss estimates.
2228 Professor Asker therefore compared the critical loss threshold, which is the percentage lost revenue which would make a price increase unprofitable and the proportion of switching from the Play Store to other products in the candidate market being the Samsung Galaxy Store to assess whether losses are greater or less than the critical loss.
2229 If the aggregate diversion ratio is higher than the critical loss, then a price increase is profitable. The HMT passes and the market is well defined. So, if the diversion ratio from the Play Store to the Samsung Galaxy Store exceeds the critical loss threshold, Professor Asker would consider the market for Android mobile app distribution to be well defined.
2230 Ms Edwards-Warren said that she had not seen the test applied this way in practice, but she understood that it is a tool that has been used in merger assessments in the US. She queried Professor Asker’s application of the aggregate diversion ratios approach to a conduct case such as that before me. I will return to this topic later.
2231 Professor Asker also did not consider whether diversion ratios from the Play Store to other Android app stores were suppressed because of the relevant Google conduct. Moreover, the diversion ratio estimate from the Play Store to the Samsung Galaxy Store that Professor Asker relied upon is the one estimated from the Fortnite hotfix analysis.
2232 Ms Edwards-Warren considered these diversion ratios to be incorrectly estimated.
The results of Professor Asker’s analysis
2233 Now Professor Asker found that the standard critical loss threshold for a 10% price increase during the period 2017 to 2022 is between 11.0% and 11.8%. Further, he found that the platform critical loss threshold for a 10% price increase during the period 2017 to 2022 is between 14.5% and 15.4%.
2234 Moreover, as these thresholds are higher than the estimated aggregate diversion ratio to Samsung (9.4%), Professor Asker found that the test fails, and that the market should be wider than the Android mobile app distribution market.
2235 Now as Ms Edwards-Warren noted, Professor Asker did not present results for a 5% price increase. He explained in a footnote that the test passes if conducted using a 5% price increase:
… the critical loss analysis that I conduct indicates it is not profitable for a hypothetical monopolist of Android app stores to raise prices by 10 percent, but it is profitable for them to do so by 5 percent under the conservative assumptions embodied in the critical loss test I evaluate… …because my specific application of critical loss analysis is conservative… …I do not view a critical loss analysis with a 5 percent threshold as dispositive for market definition.
2236 Now as to the interpretation of these results for the definition of the market, Ms Edwards-Warren said that putting to one side the errors in Professor Asker’s analysis and taking the results presented by Professor Asker as given, the results from the critical loss analysis would suggest that the relevant market should be wider than the Android mobile app distribution market.
2237 But the next appropriate step is to include the next closest substitute in the market and re-run the analysis. In her view, direct downloads were the only other option in the data/analysis available on the same device for Fortnite users on Android. Other options involved switching devices.
2238 Ms Edwards-Warren said that conducting the same critical loss analysis on an Android mobile app distribution market and including direct downloads results in a limited expansion of the Android mobile app distribution market which is sufficient to define a relevant market. And in her view there was no further need to expand the market to include any other alternative platform.
2239 Specifically, this limited expansion of the Android mobile app distribution market results in an aggregated diversion ratio of 21.2%. Further, this aggregated diversion ratio is higher than any standard or platform critical loss threshold estimated by Professor Asker between 2017 and 2022.
2240 So, Ms Edwards-Warren said that a market combining both the Android mobile app distribution market and direct downloads would be well defined.
2241 Let me turn to another topic concerning the interpretation of the difference in results under 5% and 10% price increases.
2242 Professor Asker asked whether a hypothetical monopolist of Android mobile app distribution would find it profit-maximising to increase the Play Store service fee by at least 5%. I have discussed elsewhere that one should consider whether a hypothetical monopolist would find it profit-increasing to raise prices.
2243 Now Professor Asker found that it is not profitable for a hypothetical monopolist of Android app stores to raise prices by 10%, but is profitable for them to do so by 5%. That is, on this version of the test, while the Android mobile app distribution market fails Professor Asker’s critical loss test using a 10% price increase, it passes using a 5% price increase.
2244 Ms Edwards-Warren said that such a result could be consistent with the Android mobile app distribution market being the relevant market and the failure of the test at a 10% price increase being the result of the cellophane fallacy.
2245 Professor Asker did not consider such interpretations of the result that the Android mobile app distribution market passes the test using a 5% increase but fails using a 10% increase.
2246 Instead, he dismissed the results using a 5% price increase. First, he said that the result that a 10% price increase is not profit-increasing means that it is not profit-maximising to raise prices by 5%. Second, he said that given the conservative assumptions applied, a 5% price increase being profit-increasing is not dispositive for market definition.
2247 Now in Ms Edwards-Warren’s view, a more appropriate interpretation is that these results are borderline at best, even if one accepted that Professor Asker’s inputs into the calculation were accurate. That is because the test passes under a 5% price increase and fails under a 10% price increase.
2248 Furthermore, Ms Edwards-Warren said that the results are sensitive to the inputs relied upon. Let me elaborate on her evidence in that respect.
2249 Now to further test the sensitivity of the critical loss analysis to the value of the inputs assumed by Professor Asker, Ms Edwards-Warren computed critical loss thresholds based on a range of values for each input.
2250 Now the standard critical loss threshold requires an estimate of the Play Store margin. The platform critical loss threshold requires an estimate of the Play Store margin and an assumed pass-through rate of the increase in service fee by developers to consumers. Both thresholds were to be compared to an estimate of the aggregate diversion ratio to Samsung. The test was carried out for both a 5% and 10% price increase.
2251 Ms Edwards-Warren examined the range of standard and platform critical loss thresholds that arise from different combinations of these inputs and her table 12 below summarised the range of values which she selected for each input to the critical loss threshold calculations and explained why those ranges were selected.
2252 Ms Edwards-Warren then compared the standard and platform critical loss thresholds estimated from the range of inputs above to estimates of the aggregate diversion ratios for the Samsung Galaxy Store using diversion ratios estimated by Professor Asker as well as those estimated by Professor Goldfarb based on a similar four-week time period for comparability.
2253 Ms Edwards-Warren’s figure 8 below presents the results. It compares the standard critical loss thresholds estimated based on a range of inputs to diversion ratios for the Samsung Galaxy Store from Professor Asker and from Professor Goldfarb.
2254 The horizontal axis shows the increase in the service fee, that is, the SSNIP being approximated. It ranges from 5% to 10%.
2255 Further, the vertical axis shows the critical loss threshold that results depending on the different combinations of inputs. The grey region on the graph shows all possible outcomes for the critical loss threshold depending on the assumptions with respect to margin and pass-through rate.
2256 Further, the red region identifies the range where diversion to the Samsung Galaxy Store would be insufficient for the Android mobile app distribution market to pass the HMT, and therefore the Android mobile app distribution market is not well defined, under any standard critical loss threshold.
2257 Further, the green region identifies the range where diversion to the Samsung Galaxy Store would be sufficient for the Android mobile app distribution market to pass the HMT, and therefore the Android mobile app distribution market is well defined, under any standard critical loss threshold.
2258 Further, the red dashed lines reflect diversion ratios estimated by Professor Asker.
2259 Further, the blue dashed lines reflect diversion ratios estimated by Professor Goldfarb based on a similar four-week time period as used by Professor Asker.
2260 Ms Edwards-Warren said, and I accept, that the figure shows that, depending on the assumptions made about pass-through and margins, there is a range of critical loss thresholds.
2261 If one posits a 5% price increase, the test passes under all possible combinations of critical loss threshold and diversion ratio.
2262 It is only when one posits a price increase of more than 8% that the test passes under some of Professor Asker’s diversion ratio estimates under some scenarios reflecting certain assumptions regarding margins and pass-through.
2263 The results using the diversion ratios of Professor Asker do not universally point to the Android mobile app distribution market being poorly defined.
2264 The results using the diversion ratios of Professor Goldfarb universally point to the Android mobile app distribution market being well defined.
2265 Ms Edwards-Warren’s figure 9 below presents a similar comparison to the platform critical loss thresholds estimated based on a range of inputs outlined in table 12 above.
2266 Similarly, the figure above shows that diversion ratios estimated by Professor Asker are sometimes above and sometimes below the range of critical loss thresholds, and they do not universally point to the Android mobile app distribution market being well defined or not.
2267 The diversion ratios to the Samsung Galaxy Store estimated by Professor Goldfarb, based on a similar four-week time period used by Professor Asker, are higher than all platform critical loss thresholds calculated, thus universally pointing to the Android mobile app distribution market being well defined.
2268 Let me turn now to Google’s principal arguments based upon the evidence that I have just summarised given by Professor Asker and some criticisms of the evidence of Ms Edwards-Warren. Some of what follows will concern matters I have already touched upon in my discussion of Professor Asker’s and Ms Edwards-Warren’s views.
Google’s arguments
2269 Google says that Professor Asker demonstrated using a critical loss analysis that the proposed Android mobile app distribution market fails the HMT with a 10% price increase based on the substitution patterns he observed in the data.
2270 Couching the matter in profit-maximising terms, Google says that critical loss analysis starts by asking the following question: would a hypothetical monopolist of the candidate market find it profit-maximising to increase the price of one of its products, say Product A, by at least X %? The profit-maximising price increase is at least X % if an increase of twice the size (2X %) is profitable. This occurs when the actual loss in sales, for a 2X % price increase, is less than what is called the critical loss threshold.
2271 To determine the actual loss in sales, one must balance two competing effects. On the one hand, by increasing the price, the firm will lose customers from Product A. On the other hand, the firm, as the hypothetical monopolist, can recapture some of those lost consumers through the other products it owns, that is, everything else in the candidate market except Product A. The amount of lost Product A sales can be calculated using consumer elasticity, where the elasticity can be imputed using the Lerner index. The amount of recapture can be calculated using an aggregate diversion ratio, that is, how much is diverted to all other products in the candidate market.
2272 Google says that the benefit of the critical loss analysis is that it provides a parsimonious way of implementing a quantitative HMT, which in this case only requires four necessary inputs being margins, pass-through, diversion estimates and a hypothetical price increase. Let me elaborate a little on what I have already said.
2273 First, as to margin, this input is the margin for the product of interest, which is part of the Lerner index formula. For this, Professor Asker relied on gross profit margins as estimated by Professor Davila. Between 2017 and 2022, Professor Davila’s estimates for margins were approximately 75% to 81%. Epic relies on a similar range.
2274 Second, as to developer pass-through rate, this input measures how much developers pass on an increase in the service fee to consumers. This is relevant for the platform Lerner index that Professor Asker derives, which adapts the standard Lerner index to account for the fact that the Play Store does not set consumer prices directly.
2275 Google says that rather than estimating the pass-through rate, Professor Asker conservatively assumed full 100% pass-through as that implies the lowest possible consumer price elasticity. In other words, he assessed whether consumer substitution alone can discipline the hypothetical monopolist.
2276 Google says that because the structure of the critical loss test constrains developers to only substitute by passing through service fees, when assuming lower levels of pass-through it would be necessary to adapt the critical loss framework to allow for other ways developers can substitute.
2277 Now as I have already indicated, Ms Edwards-Warren disagreed with the assumption of full pass-through, but Google says that she provided no greater specificity than saying it is highly unlikely that there is full or even significant pass-through. Moreover, Google says that there is no empirical evidence to support Epic’s claim that pass-through is likely to be below 20%.
2278 Google says that in the absence of any evidence, all possible pass-through values between 0% to 100% should be considered to test the robustness of Epic’s proposed market, as Professor Asker did by evaluating the critical loss test using the standard formulae, which are equivalent to 0% pass-through.
2279 Third, as to diversion, this input is the aggregate diversion ratio, which in this case means the diversion from the Play Store to all other app stores in the proposed market. For this input, Professor Asker used his estimates of diversion to the Samsung Galaxy Store based on the hotfix analysis given that the Galaxy Store is the largest Android app store in Australia other than the Play Store and the only one that had Fortnite. As to the relevant diversion ratio estimates, his range was 10.1% to 13.2%.
2280 Fourth, as to price increase, this input is the hypothetical price increase in the service fee that is being tested to see if it is profitable.
2281 As I have already indicated, Professor Asker assessed whether a 10% price increase is profitable to test if the profit-maximising price is above 5%. I have said elsewhere that the relevant test should not focus on the profit-maximising price. Ms Edwards-Warren only required that the hypothetical monopolist find it profitable to increase its price by 5%.
2282 Now Google says that the Lerner index is appropriate and reliable in the circumstances of this case.
2283 As I have already said, underpinning the critical loss analysis is the Lerner index. The Lerner index is a standard formulation in economics that captures the relationship between margins and elasticities.
2284 Google says that the traditional Lerner index does not apply in this setting because the Play Store does not set prices for consumers. Consumer prices are set by developers. Professor Asker re-derived the Lerner index for this setting, which captures the fact that Play Store margins are related to both consumer elasticity and developer pass-through.
2285 Epic says that the Lerner index is not appropriate in this setting and that Professor Asker’s platform Lerner index is inappropriate. But Google says that Epic is wrong for the following reasons.
2286 First, Epic says that the Lerner index does not apply to Google because it does not act in a profit-maximising manner and therefore bias would be introduced. This claim is based on the suggestion that because of regulatory and political scrutiny, Google does not act in a profit-maximising manner.
2287 Google says that Epic points to no evidence to support its claim that Google is not profit-maximising, and nor did it put this proposition to any Google lay witness. Further, there is no evidence or analysis provided by Epic as to what direction the bias would go, if any, or to explain how or why regulatory or political pressure would somehow mean that Google is not acting rationally and in a profit-maximising manner.
2288 Second, Epic claims that the Lerner index is inappropriate in markets with high fixed costs, close to zero marginal costs and large economies of scale.
2289 Now Google challenges the high fixed costs characterisation of the Play Store’s position. But even if Google’s fixed costs are high, Google says that Epic and Ms Edwards-Warren have misinterpreted the academic literature. As I have already indicated, Professor Asker said that a well-known flaw of the Lerner index is that a high Lerner index may not reflect market power, but rather a firm with high fixed costs. This means that the Lerner index is conservative for estimating price elasticity and market power when analysing an industry with high fixed costs and close to zero marginal costs.
2290 Third, Google says that Epic mischaracterised the consumer elasticities implied by the platform Lerner index. Epic says that Professor Asker’s platform Lerner index is unreliable because it leads to inconceivably high elasticities that would imply price elasticities for Google Play Store that are greater than everyday consumables, such as soft drinks or breakfast cereals.
2291 It is said that Epic provides no explanation or reasoning for why demand for the Play Store should be more inelastic than demand for a box of cornflakes or a bottle of a carbonated beverage.
2292 In fact, the Play Store having more elastic demand is consistent with the numerous ways that consumers can transact for digital content outside of Google Play.
2293 Moreover, Epic also says that developer pass-through is low. But Google says that low pass-through is consistent with high consumer price elasticities, that is, developers would not pass on a price increase because consumers are highly responsive to price changes.
2294 Let me turn to another matter.
2295 As I have said, the critical loss analysis requires as an input the aggregate diversion in response to the hypothetical price increase. Professor Asker used the best estimate for this, being the diversion from the Play Store to the Samsung Galaxy Store after the hotfix. Google says that this is a reasonable estimate for the aggregate diversion ratio for the following reasons.
2296 First, the hotfix is a natural experiment that can be used to estimate substitution in response to a SSNIP. Google says that this is not an extreme event, but an informative one. Both Professor Asker and Professor Goldfarb considered the hotfix to be a natural experiment that is useful for measuring substitution.
2297 It is standard practice for market definition by economists and competition authorities to rely on the exogenous entry or exit of a firm’s offering in a candidate product market to analyse diversion.
2298 For example, in P Davis and E Garcés (2009) the authors use the example of a plant closure to illustrate how to use a natural experiment to identify diversion ratios. Other natural experiments that have been studied include unexpected plant closures due to extreme weather conditions, the entry or exit of a single grocery store, and the entry or exit of a single petrol station.
2299 The diversion ratios estimated from these analyses are regarded as reasonable approximations to those estimated from a SSNIP.
2300 Second, despite Epic challenging Professor Asker’s analysis in cross-examination, Google says that Epic has not identified any evidence that the diversion ratios estimated from the hotfix would differ from those estimated from a smaller change in price or quality.
2301 Ms Edwards-Warren says that the diversion ratios could differ to the extent that the Play Store spender who diverts spending in response to a SSNIP (the marginal consumer) is different from the users who spent via the Play Store prior to the hotfix (the average consumer).
2302 But Google says that Ms Edwards-Warren did not evaluate that possibility despite the availability of the necessary data. Ms Edwards-Warren did not provide any evidence of the claimed difference, how large that purported difference is, and in what ways the estimates would be biased as a result of that purported difference.
2303 Third, Google says that Ms Edwards-Warren’s assertion is inconsistent with the economics of how marginal and average consumers would substitute in response to a SSNIP and the data available in this case. Epic simultaneously claims that the hotfix was extreme while also claiming that users were largely unaffected until the new Fortnite season was released two weeks after the hotfix.
2304 That would mean that the period immediately after the hotfix is more informative as to how marginal consumers behave rather than average consumers, consistent with Professor Asker’s view that the initial hotfix period is closer to a SSNIP than the new season release because it was a smaller quality degradation.
2305 During that period, Professor Asker illustrated that diversion was primarily to console stores and diversion to the Samsung Galaxy Store was limited. It was only after the new season release that diversion to the Samsung Galaxy Store increased, though this was short-lived.
2306 This indicates that, if anything, the marginal consumer is more likely to divert to console stores than the average consumer, being the opposite outcome to that asserted by Ms Edwards-Warren. Let me move to another topic.
2307 Google says that the critical loss analysis is informative in conduct cases as well as in merger cases and has made the following points.
2308 The critical loss analysis has long been a widely used tool in competition analysis and critical loss analysis can be informative about market definition. Epic criticised Professor Asker’s use of the aggregate diversion ratios formulation of a critical loss test pioneered by Professor Katz and Professor Shapiro, and incorrectly said that the aggregate diversion ratios formulation is only appropriate in merger analysis and not in conduct cases. But Google says that Epic is wrong for the following reasons.
2309 First, the use of the aggregate diversion ratios formulation of critical loss analysis is to implement a quantitative HMT in a parsimonious way. By Epic’s logic, so Google says, the aggregate diversion ratios formulation of the critical loss analysis would be appropriate to analyse a hypothetical merger between all Android app stores, but it would be inappropriate to analyse the conduct of a hypothetical monopolist of all Android app stores.
2310 Under Epic’s view, so Google says, the only valid critical loss analysis in a conduct case requires measuring actual losses rather than estimating those losses via the aggregate diversion ratios formulation. This is economically nonsensical. The standard aggregate diversion ratios formulation of critical loss is used because mathematically there is a one-to-one correspondence between the aggregate diversion ratios and actual losses. Actual losses exceed critical losses if and only if the aggregate diversion ratio is below the critical loss threshold. There is no suggestion that the underlying mathematical foundation presented in M Katz and C Shapiro (2003) is in dispute.
2311 Second, Epic relied on Ms Edwards-Warren’s assertion that the critical loss analysis has been criticised and that it is not a universally accepted tool. But Google says that Ms Edwards-Warren did not provide detail as to what these criticisms were and whether they entail that the critical loss analysis cannot be applied to a conduct case.
2312 Third, Epic said that it is inappropriate to use the aggregate diversion ratios formulation of critical loss analysis in a conduct case because the alleged conduct may have an impact on competition and also impact the level of observed diversion to products in the candidate market. To correct for this, Epic claims that a buffer should be built into the analysis. But Google says that this contention is misconceived for several reasons.
2313 Google says that Epic neither explains how large the purported buffer should be nor provides any evidence that absent the conduct diversion to the Samsung Galaxy Store would be higher or by how much.
2314 It also says that Epic does not grapple with the widespread availability of the Samsung Galaxy Store. Epic is merely speculating that including such a buffer would mean that its proposed market passes the HMT.
2315 Further, in any event, Google says that there are many ways in which Professor Asker’s critical loss analysis is already conservative and so builds in a buffer.
2316 For example, the critical loss analysis cannot measure diversion to the iOS App Store or to the web given that the hotfix also affected iOS, and given that Fortnite did not distribute content via the web at the time of the hotfix.
2317 Google says that at some level, Epic’s concern appears to be a variation on the theme of the cellophane fallacy discussed by Ms Edwards-Warren, which Professor Asker had already accounted for in his analysis. He did so by conducting the critical loss analysis using margins estimated by Mr Holt under what Mr Holt claims is a competitive service fee of 15%.
2318 Google says that Epic’s proposed market fails even under these margins, which indicates that the cellophane fallacy is not a concern. Let me move to another matter.
2319 Google says that Epic’s criticisms regarding developer pass-through rates are unfounded.
2320 Epic criticised Professor Asker’s initial assumption of 100% developer pass-through and said that it is likely as low as 20%. But Google says that I should reject this criticism.
2321 Google says that Epic has presented no evidence on plausible pass-through rates. Ms Edwards-Warren did not comment on current or reasonable values of pass-through and made it clear that she did not have an answer on the precise figures of pass-through.
2322 Whilst Ms Edwards-Warren said that it is unlikely for there to be significant pass-through, she provided no explanation of what “significant” means.
2323 Professor Asker explained that he considered low pass-through to be unlikely and chose a somewhat arbitrary cut of 20% to explain his reasoning. So, the assertion of developer pass-through being as low as 20% is simply without basis.
2324 In any event, Google says that Professor Asker considered a range of pass-through assumptions.
2325 Generally, Google says that Professor Asker’s critical loss analysis empirically demonstrates that the posited Android mobile app distribution market fails the HMT.
2326 The Android mobile app distribution market fails the HMT if the diversion ratio to the Samsung Galaxy Store is below the critical loss threshold. The values estimated for these two statistics are as follows.
2327 In respect of the diversion ratio to the Samsung Galaxy Store, the relevant diversion ratio estimates have been discussed by me earlier, and as to those on which Professor Asker relied, the range is 10.1% to 13.2%.
2328 Google says that in respect of the critical loss threshold, the plausible critical loss thresholds for a 10% price increase range from 11.3% to 15.4% when examining developer pass-through rates from 5% to 100% and gross margins from 75% to 80%. And it says that on Epic’s claim that pass-through could be as low as 20%, the thresholds range from 11.3% to 12.5%.
2329 So, Google says that using a 100% developer pass-through rate and 80% margin, the critical loss threshold is 14.5%.
2330 With this threshold, Google says that Epic’s proposed market fails the HMT under every estimate that Professor Asker prefers.
2331 Further, Google says that using even a 5% developer pass-through rate and 80% margin, the critical loss threshold is 11.3%.
2332 So, Google says that Epic’s proposed market fails the HMT under 6 out of 8 estimates that Professor Asker recommended adopting, so it cannot be relied upon to conclude that the proposed market would pass the HMT. This is so particularly given the several conservative features of Professor Asker’s critical loss analysis, including that diversion to iOS is not taken into account by the hotfix analysis, that the analysis does not consider closer substitutes before weaker ones, and that the hypothesised price increase applies only to the Play Store rather than to all products in the candidate market.
2333 As a result, Google says that Professor Asker’s critical loss analysis demonstrates that, even when adopting the inputs advanced by Epic’s own experts, Epic’s Android mobile app distribution market does not have robust empirical support for a 10% SSNIP.
2334 Google says that it is not sufficient to find one specification where the market passes. Epic is required to show that its proposed market is well-defined, which would necessitate it passing critical loss under a range of reasonable assumptions and specifications.
2335 Google says that Epic has not discharged that onus. It says that it is incorrect to characterise these results as borderline, as Ms Edwards-Warren does, including for the following reasons.
2336 First, even if that characterisation were true, what is borderline are not the results, but the candidate market. The exercise is asking whether the market has robust support. It does not.
2337 Second, the characterisation of the results as borderline relies on using the 5% price increase as an informative input value. But it is not an informative value input, because such a formulation is inconsistent with the standard HMT.
2338 Third, the results indicate that the proposed market fails the HMT under a range of reasonable estimates. These results suggest that the market is too narrowly defined.
2339 Fourth, even if Professor Goldfarb’s preferred range of 10.1 to 18.7% diversion to the Samsung Galaxy Store were accepted, Google says that the plausible critical loss thresholds range from 11.3% to 15.4%. As such, Google says that it cannot be concluded from Professor Goldfarb’s diversion estimates that Epic’s market is well-defined. To do so would require putting greater precision on Professor Goldfarb’s estimates than he was willing to do.
2340 In summary, Google says that given that the critical loss analysis shows that the market fails the HMT, the candidate market must be expanded.
Analysis
2341 Now in my view Professor Asker’s critical loss analysis has several methodological difficulties as Ms Edwards-Warren pointed out and I have accepted.
2342 But even if those difficulties are put to one side, adopting reasonable estimates of relevant parameters leads to the conclusion that there is a well-defined Android mobile app distribution market. Let me descend into the detail, but noting at the outset that some of what follows concerns concepts or criticisms that I have already touched on.
2343 Now I accept that a critical loss analysis is a method of implementing a quantitative SSNIP test with limited inputs. It involves comparing a critical loss threshold with an estimate of actual loss. And the critical loss threshold depends on the SSNIP percentage being examined, such as 5 or 10%, and a percentage gross margin.
2344 If actual loss exceeds the threshold, the candidate market fails the HMT. This means that the market is not well defined and should be widened.
2345 As I have already indicated, estimates of actual loss following a SSNIP are not available in this case, and so in place of estimates of actual loss, Professor Asker relied upon an alternative methodology proposed by economists M Katz and C Shapiro (2003) in the horizontal merger context, which explains how aggregate diversion ratios can be used in place of estimates of actual loss to implement a critical loss analysis.
2346 In the aggregate diversion ratios approach, if aggregate diversion is lower than the critical loss threshold, the candidate market fails the HMT and the market is not well defined and should be widened. But if aggregate diversion is higher than the critical loss threshold, the market is well defined.
2347 Now as Ms Edwards-Warren explained, the essential concept in the merger context was to consider the hypothetical monopolist of products sold by two merging firms and to ask if prices were increased on one of the products sold by the hypothetical monopolist (Product A), whether the aggregate diversion in sales from Product A to the hypothetical monopolist’s other products would be sufficient to make up for the losses on Product A. The aggregate diversion ratio is the share of diversion captured by other products within the candidate market.
2348 But in the present context, Professor Asker adapted the analysis by considering a hypothetical monopolist of all Android app stores and asking whether if the hypothetical monopolist increased its prices on the Play Store there be sufficient diversion to other Android app stores, specifically the Samsung Galaxy Store, to make up for the losses in sales to the Play Store. Professor Asker estimated the aggregate diversion using diversion ratios calculated from the Fortnite analysis.
2349 And using the aggregate diversion ratios approach, Professor Asker applied the price increase to just one product in the relevant candidate market, being the commission rate of the Play Store, rather than all products within the candidate market, being the commission rate of all Android app stores. Professor Asker considered this to be conservative.
2350 But as Ms Edwards-Warren explained, whilst that is true in theory, Professor Asker’s critical loss implementation is very close to asking about the hypothetical monopolist in the candidate market increasing its prices over all of its products, due to the prominence of the Play Store. Professor Asker accepted that due to the prominence of the Play Store, the distinction between applying the price increase to one versus all products in the candidate market is potentially small.
2351 Now as I have indicated, Professor Asker developed a platform critical loss threshold which assumed that developers pass through a percentage of a service fee change to users. At 0% pass through, the platform critical loss threshold is equal to the standard critical loss threshold. It sets the lower bound to the platform critical loss threshold. And at pass-through rates above 0%, the platform critical loss threshold is always higher than the standard critical loss threshold.
2352 But Professor Asker’s adoption of the aggregate diversion ratios approach to a conduct case such as the present is questionable for the reasons that Ms Edwards-Warren explained.
2353 First, Professor Asker’s application of the aggregate diversion ratios approach to a conduct case is not supported by the academic literature that he relied upon. Professor Asker accepted that M Katz and C Shapiro (2003) concerned market definition in the context of a horizontal merger. Professor Asker also accepted that the authors did not suggest that it should be adopted in a case where there was alleged to be pre-existing anti-competitive conduct.
2354 As I have indicated, Ms Edwards-Warren noted that whilst she has not seen the aggregate diversion ratios approach applied in her experience, it is a tool that has been used in merger assessments in the US. But I accept what she says that the aggregate diversion ratios approach has been criticised and it is not a universally accepted tool.
2355 Second, Professor Asker’s application of the aggregate diversion ratios approach to a conduct case has not been accepted by a US court in a non-merger case.
2356 Third, in a case where there is alleged anti-competitive conduct, the aggregate diversion ratios approach requires building into the analysis a buffer when using the diversion ratios for the firm affected by the alleged conduct. In such a case, the diversion to the second firm would be limited if the impugned conduct is found to be made out.
2357 Now Epic’s case is that Google has engaged in conduct which has had the effect of impairing the competitiveness of other Android stores, but Professor Asker did not build in any such buffer.
2358 Now Professor Asker said that no such buffer was needed, as his analysis omitted websites and iOS, which are factors taking away options that may otherwise attract people away from the Samsung Galaxy Store to other options. But I agree with Epic that Professor Asker has provided no evidence to suggest that these omissions would have a greater impact than the effect of the relevant Google conduct on the Galaxy Store.
2359 Let me turn to another question as to whether the diversion following the removal of Fortnite necessarily reflects what would occur in response to a small change in price or quality.
2360 Ms Edwards-Warren said that a methodological issue with the critical loss analysis is that, in relying upon the patterns of diversion following the removal to draw conclusions about how users would substitute in response to a small change in price or quality, Professor Asker assumed that the marginal customer behaves in the same way as the remainder of the consumer base.
2361 But as to the appropriateness of this assumption, Ms Edwards-Warren said that it depends on whether the marginal consumers who would respond to a price increase would respond in exactly the same way that all consumers responded to the Fortnite removal event. This is because when one is examining an extreme event, like the removal event, it is possible to conceptualise the event as an infinite price increase whereby no user can afford to purchase the product any longer, and so every user has to switch and make a switching decision.
2362 Now rather than presenting any analysis to support the reasonableness of this assumption, Professor Asker defended his position on the basis that he had seen no evidence to indicate that diversion ratios estimated from the removal of Fortnite would differ from those estimated from a smaller change in price or quality. But I agree with Ms Edwards-Warren and Epic that this response is problematic given that his analysis of diversion in response to the removal event underpins his conclusions regarding market definition.
2363 Let me now turn to the Lerner index. As Epic points out and as Ms Edwards-Warren discussed in her evidence which I have already referred to, a difficulty with the critical loss analysis relates to the Lerner index. Professor Asker’s Lerner indices were inputs into his critical loss analysis. Professor Asker relied upon the standard Lerner index and his modified platform version to calculate the standard and platform critical loss thresholds relevant to the Play Store.
2364 Professor Asker’s platform Lerner index leads to unrealistically high elasticities under various assumptions. So, for example, demand for the Play Store would be more responsive to price changes than demand for everyday consumables, such as soft drinks or breakfast cereals.
2365 Now exhibit 85 of Professor Asker’s report, which used Professor Davila’s margin estimates, shows that where the assumed margin is lower, say 34.7% in 2013, the implied price elasticity of demand for smart mobile device users is 12.5. This high elasticity estimate would imply that demand for the Play Store is more elastic than that of Professor Asker’s examples being Kellogg’s corn flakes and Milwaukee’s Best beer of all things.
2366 But given the Play Store's very high share of app downloads, Ms Edwards-Warren considered the elasticities inferred from the platform Lerner index to be inconceivably high, reflecting problems with relying on that index.
2367 Further, Ms Edwards-Warren analysed the price elasticity estimated from the Lerner index as a function of the service fee. Her figure 32 below plots the price elasticity of smart mobile device user demand as a function of the service fee, assuming a 77% profit margin, which is the 2022 margin reported in Professor Davila’s evidence.
2368 If one assumes that the service fee is lower than 30%, say at 15% being a level applied by Google in some contexts and cases, figure 32 shows that at a 15% service fee the implied elasticity of smartphone demand is around 10, being significantly higher than say Kellogg’s corn flakes.
2369 Further, the relevant literature establishes that the Lerner index is an inadequate tool for approximating price elasticity in relation to markets with high fixed costs, close to zero marginal costs and large economies of scale, therefore making the Lerner index not appropriate for this case.
2370 Now I have discussed the Lerner index, but let me address some other inputs into the critical loss analysis for a given price increase being the gross margin percentage and the developer pass through rate.
2371 Now as to the gross margin percentage, Google’s own records show a gross margin percentage for the Play Store between 2017 and 2022 of between [REDACTED]. This is consistent with Professor Davila’s calculations of the Play Store’s gross margins. Professor Easton did not challenge Professor Davila’s estimates of the Play Store’s gross margin in his report.
2372 Now as to pass-through and as I have already indicated, Professor Asker’s critical loss analysis assumed that developers pass-through 100% of the hypothetical price increase on the Play Store service fee to users.
2373 Professor Asker said that this was a conservative assumption, but this was not correct for the reasons given by Epic. The higher the pass-through rate, the higher the platform critical loss threshold. The higher the pass-through rate, the less likely Epic’s proposed market would pass the HMT. The evidence supports a conclusion that a pass-through rate as low as 20% is a likely outcome.
2374 Now Professor Asker said that he applied a pass-through rate of 100% as it acted as an upper bound, while his standard critical loss threshold, which is the equivalent of the platform critical loss threshold with a pass-through of 0%, acted as a lower bound. But there is nothing to suggest that an extreme pass-through rate of 100% is appropriate in this case.
2375 Professor Asker considered that economic theory indicates that pass-through of less than around 20% was unlikely, but explained that he did not have a basis to determine what pass-through might be above this somewhat arbitrary threshold.
2376 Ms Edwards-Warren considered that the rate is likely to be less than complete in industries with ad valorem pricing and low marginal costs. Ms Edwards-Warren considered it is highly unlikely that there is full or even significant pass-through.
2377 On the basis of her evidence, which I accept, I can reasonably regard a developer pass-through rate as low as 20% as a likely outcome.
2378 Further, a problem with Google’s position is that it is a consequence of its profit-maximising approach that the hypothetical monopolist must be able to profitably implement a 20% increase in prices. But the SSNIP is usually referred to as a price increase of 5 to 10%.
2379 Further, as to the results of Professor Asker’s critical loss analysis, once it is accepted that Professor Goldfarb’s 10.1 to 18.7% range of Samsung diversion estimates are reasonable, and the 15.8% estimate is the most accurate, Google’s position becomes problematic. As I have said earlier, I have accepted Professor Goldfarb’s estimates.
2380 In summary, I agree with Epic that Professor Asker’s methodological errors and assumptions bias his results towards finding a broader market. Professor Asker’s calculation of diversion to the Samsung Galaxy Store, being the aggregate diversion ratio, is flawed and unreliably low.
2381 Further, I agree with Epic that Professor Asker erred in assuming that 100% developer pass-through is conservative.
2382 Further, I agree with Epic that the aggregate diversion ratios approach is not well suited for non-merger cases where the aggregate diversion ratio may be suppressed by anti-competitive conduct.
2383 Now as Epic points out, one can correct for a number of these errors or model different parameters. Professor Goldfarb corrected for Professor Asker’s errors in calculating the Samsung diversion ratio and found a diversion ratio of between 10.1 to 18.7%. His preferred diversion ratio was 15.8%. Ms Edwards-Warren calculated the platform critical loss thresholds at various combinations of gross margin percentage and developer pass-through rate, and a 5 to 10% price increase range.
2384 So, in relation to a 5% price increase, even on Professor Asker’s preferred diversion figures or on Professor Goldfarb’s figures, if the gross margin is between 70 and 80% and even on the assumption of 100% pass-through, a 5% increase would be profitable for the hypothetical monopolist under a critical loss analysis.
2385 Further, in relation to a 9% price increase, and assuming Professor Goldfarb’s preferred diversion ratio of 15.8% was correct, even on the assumption of 100% pass-through and between 70 and 80% gross margin, a 9% platform increase would be profitable for the hypothetical monopolist under a critical loss analysis.
2386 Further, in relation to a 10% price increase, and assuming the top of the diversion range that Professor Goldfarb suggested of 18.7%, the price increase would always be profitable, even on the assumption of 100% pass-through and a gross margin percentage of 70%, under a critical loss analysis.
2387 Further, in relation to a 10% price increase, but using Professor Goldfarb’s preferred 15.8% diversion figure, it would only be unprofitable if the gross margin was 70% and the developer pass-through rate exceeded 85%.
2388 What this all shows, as Ms Edwards-Warren correctly demonstrated, is that given Google’s gross margins, the likely developer pass-through rates, Professor Goldfarb’s estimates of diversion and the real possibility of anti-competitive conduct reducing the observed diversion rates, the critical loss analysis supports the conclusion that the Android mobile app distribution market is well-defined, even on a 10% SSNIP.
2389 Drawing the threads together, let me summarize where I have got to based upon Ms Edwards-Warren’s evidence and Epic’s position, which I have accepted.
2390 To recap, the results of the analysis by Professor Asker show that the aggregate diversion ratio is higher than the critical loss threshold when applying a 5% SSNIP, which suggests that the Android mobile app distribution market is well defined. But the results show that the aggregate diversion ratio is lower than the critical loss threshold when applying a 10% SSNIP, which suggests that the market should be widened.
2391 Now Professor Asker argued that these results show that the Android mobile app distribution market failed the HMT and one should rely on the 10% SSNIP threshold.
2392 But even if the diversion ratios used by Professor Asker were well estimated, these results are at best borderline, and do not point strongly either to the market being too narrow or too wide. The failure of the test at the 10% level could be an indication of the cellophane fallacy, as Ms Edwards-Warren pointed out.
2393 But because of the flaws in the design, implementation and interpretation of the test, it is not appropriate to place significant weight on the results of his critical loss analysis in any event for the following reasons in summary.
2394 First, Professor Asker used two critical loss equations, but neither equation is well suited for a market like app distribution which is characterised by high fixed costs, close to zero marginal costs and large economies of scale. And for such markets, the Lerner index, on which the critical loss is based, is an inadequate tool for approximating price elasticity.
2395 Second, Professor Asker assumed a 100% pass-through rate from developers to users which he states is conservative. But the test is more likely to be passed with a lower pass-through rate. And it is unlikely that the pass-through rate is very high or close to 100%.
2396 Third, Professor Asker did not use estimates of actual losses to compare to the critical loss. He compared the critical loss to estimates of the aggregate diversion ratio from the Play Store to other Android app stores.
2397 Fourth, Professor Asker used a diversion ratio from the Play Store to Samsung Galaxy Store calculated from the Fortnite hotfix analysis, which is flawed. And he did not consider whether diversion ratios from the Play Store to other Android app stores were suppressed because of the relevant Google conduct.
2398 But even if one accepted the methodology and inputs, as I have said, the results do not universally suggest that the market should be wider than the Android mobile app distribution market.
2399 Further, Professor Asker erroneously considered whether a SSNIP is profit-maximising rather than profit-increasing, which is the equivalent to doubling the magnitude of the price increase and only considering a 10% price increase.
2400 Finally, whatever the various difficulties with Professor Asker’s critical loss analysis, his analysis shows that even on his lower estimates of diversion to the Samsung Galaxy Store, a hypothetical monopolist of the Android mobile app distribution market could profitably implement a 5% price increase.
2401 But as I have said, if one adopts Professor Goldfarb’s estimates of Samsung diversion and reasonable assumptions of developer pass-through, Professor Asker’s critical loss analysis shows that a hypothetical monopolist of the Android mobile app distribution market could profitably implement a 10% price increase.
2402 So, and as Epic rightly said, irrespective of the debate about whether the HMT involves a profit maximising or profit increasing criterion, Professor Asker’s critical loss analysis suggests that the Android mobile app distribution market is well-defined. The analysis indicates that a SSNIP of 10% would be profitable to the hypothetical monopolist of the Android mobile app distribution market, and accordingly a SSNIP of 5% would be profit-maximising.
What are the close substitutes, if any?
2403 Given that I have identified the relevant focal product, what, if any, close competitive constraints exist on the supply of that product? That exercise is undertaken by reference to the likelihood of substitution to other products.
2404 To be relevant to the analysis, substitution between services involves a shift by developers and/or users, or in some cases suppliers, from one service to another in response to a small but significant change in relative prices or quality. To be included in the same market, two services must be close substitutes in this sense.
2405 In considering the close substitutes for Android app distribution services, the task is to assess what, if any, alternatives users and developers would switch to in response to a small but significant change in the relative price or quality of those services.
2406 Google says that the Play Store is exposed to competition within the Android ecosystem. This includes competition from other Android app stores, pre-installed apps on a mobile device, and sideloading of apps by an end user. It is also said that the Play Store faces competition from non-mobile platforms and the use of gaming consoles and PCs.
2407 Let me summarise the evidence as to whether there are any such close substitutes.
2408 I should say upfront that I agree with Epic that other Android app stores are the only close substitutes for the services supplied by the Play Store.
2409 Further, Professor Asker centred much of his evidence of substitution around whether products could be substitutes in theory. According to Professor Asker, web apps and native apps could be substitutes if there exists apps with relatively higher use of web apps or browsers over native apps. Web apps and native apps could also be substitutes if developers ever create both a web app or native app, or only a web app. And he presented some evidence on consumers switching between Android smart mobile devices and iOS devices as evidence of substitution between apps on these devices.
2410 Professor Asker’s evidence of theoretical substitution did not show whether consumers or developers consider the use of one product to be reasonably interchangeable with another. Moreover, evidence of some users ever using more than one app channel or developers having apps on more than one channel is consistent with these app channels being independent products. The same point holds true for payment channels.
2411 But I should say that in summary I am in substantial agreement with Google concerning the available choices save that they do not rise to the level of being close substitutes for market definition purposes, save for other Android app stores. Moreover, the existence of such technical or non-close substitutes does not deny or negate Google’s substantial market power as I have discussed elsewhere.
2412 Let me now go through some of the possibilities that have been discussed in the evidence.
Android app stores other than the Play Store
2413 Clearly, the distribution services supplied by other Android app stores are substitutable for the services supplied by Google through the Play Store.
2414 This includes app stores on Android devices other than the Play Store, including OEM app stores such as the Samsung Galaxy Store, Huawei App Gallery, Xiaomi Market, Vivo App Store, and Oppo App Market, and third-party app stores such as Uptodown, the Amazon App Store, Aptoide, F-Droid and One Store.
2415 This extends to app stores however they come to appear on an Android device, including whether they are pre-installed or directly downloaded.
2416 Other Android app stores and the Play Store are substitutes. The services supplied by other Android app stores on mobile devices are substitutable for the services supplied by Google through the Play Store, and they are constraints.
2417 First, other Android app stores are functionally comparable to the Play Store in their distribution of developer apps and, like the Play Store, can be used to distribute a large number of apps to Android users. Further, the Samsung Galaxy Store is pre-installed on two-thirds of all Android devices in Australia.
2418 Second, competitive pressures from other Android app stores not only exist, but are increasing. Google’s internal documents make many references to the competitive threat posed by other Android app stores.
2419 They record that there is increased competition arising from Samsung promoting its own products, launching a rewards program on the Galaxy Store and aggressively driving exclusive games, such that it is a key competitor that has taken aggressive actions to grow market share. These actions include pursuing gaming on its store and growing its services business, differentiating hardware, and appealing to younger users.
2420 Further, they record that the Amazon Appstore was emerging as a challenge to the Play Store in gaming globally, including by acquiring top game titles and engaging high value users to grow its market share. It has also aggressively pursued gaming on its store by funding in-app purchase discounts of up to 20% to attract users, growing its services business, differentiating hardware, and appealing to younger users.
2421 Further, alternative Android app stores can each pursue an area of focus that is unique and thereby put pressure on the Play Store to follow.
2422 Further, key competitors have taken aggressive action to grow their user bases. OneStore has lowered revenue share to court developers, and ecosystem partners such as Samsung, OneStore, and the Amazon Appstore have invested in game distribution and exclusive content. Further, Amazon in Japan is an illustration of the severity of the threats that Google faces. This app store has used heavy discounts to attract the Play Store’s high value users. Google faces the risk of becoming a “showroom” for Amazon or other app stores.
2423 Further, there is a risk of major developers de-prioritising the Play Store or distributing less on the Play Store, in the place of pursuing gaming opportunities with competitors like Samsung and the OneStore.
2424 Third, Google has responded to the competitive threats from other Android app stores with competitive programs, such as Google Play Points, which is a loyalty program aimed at high value users.
2425 The Play Store has a very high share of app downloads to Android devices, being roughly 97.9% in Australia and 91.4% globally, and pre-installations on Android devices.
2426 But whilst Google’s high share of Android app downloads shows that the Play Store is a highly popular app store within the Android ecosystem, it is by no means evident that Android device users lack genuine alternatives to the Play Store for obtaining apps and, importantly, for purchasing app-based digital content. There is no sense in which Android device users are locked in to using the Play Store. This is for several reasons.
2427 First, even on their Android device, users have a range of readily available and convenient alternative options for obtaining apps and making purchases of app-based digital content. In fact, over 84% of the top 50 apps by spend on the Play Store in Australia are available on Android devices by a means other than the Play Store. The options available to, and utilised by, users are as follows.
2428 In respect of users using another Android app store, there are a range of Android app stores from which users can obtain apps on their device. These include OEM stores such as the Samsung Galaxy Store or the Vivo app store, the ONE Store developed by Korean carriers and third-party app stores such as the Amazon Appstore.
2429 In Australia, roughly 72% of Android devices come with an alternative app store pre-loaded including 67% of devices having the Samsung Galaxy Store pre-installed. And insofar as an app store is not pre-installed, it can be sideloaded. At least 5% of Android devices have at least one sideloaded app store. The pre-installed app stores are easy to access, typically being placed on the device home screen and not being subject to any unknown source warnings.
2430 Further, the Android app stores to which users have access typically carry many of the apps published on the Play Store. For example, the Amazon Appstore carries 72% and the Samsung Galaxy Store carries 34% of the top 50 apps by spend on the Play Store.
2431 In summary, other Android app stores provide a competitive constraint on the Play Store to such an extent that they are substitutes.
Direct downloading/sideloading
2432 Another possible substitute relevant to Android devices is the possibility of users directly downloading individual apps to their devices without the use of an app store.
2433 Ms Edwards-Warren and Professor Asker agreed that there is a measure of substitutability between direct downloading of individual apps and the service supplied by an Android app store, but they disagreed as to the extent.
2434 Google says that sideloading is a close substitute for an Android app store. Now I disagree but let me identify some of its arguments.
2435 Now although Epic says that there are functional limitations with sideloading, including the fact that sideloaded apps cannot be automatically updated, Google’s witness Mr Cunningham said that sideloading is a straightforward process and in his experience takes merely an estimated 15 to 30 seconds for a user to follow installation flows and successfully sideload an app. Epic itself has described the process as being simple and easy to navigate.
2436 Further, in October 2021, Android 12 introduced the ability for non-preloaded sources of apps to install app updates without requiring user involvement. So sideloaded apps can be updated automatically.
2437 Further, although Epic says that users and developers do not consider sideloading to be a close substitute for Android app stores, Google says that there is evidence that users and developers in practice can and do sideload.
2438 Further, Google says that Professor Asker’s analysis of the Fortnite spending data before and after the hotfix is consistent with users viewing sideloading as a close substitute. Now I accept that there is evidence that for at least some users, sideloading is a viable substitute.
2439 Further, although Epic says that there are significant switching costs associated with sideloading for users and developers, Google says that Epic has provided no quantification of what those costs may be. Further, in any event, from the developer’s perspective, sideloading would be a cheaper option to deploy because it would avoid paying app store commissions.
2440 Further, the suggestion that there are prohibitive switching costs that prevent sideloading is inconsistent with the evidence of Android Fortnite user spending patterns after the hotfix.
2441 Further, although Epic says that sideloading is a form of self-supply of distribution services, and therefore not a close substitute, Google says that if a developer is readily able to bypass the Play Store by self-supplying distribution with sideloading, it will have significant countervailing power. If so, this constitutes a constraint on Google.
2442 So, Google says that sideloading is a close constraint on the Play Store. But I disagree and on this aspect largely agree with Epic’s position.
2443 Now Ms Edwards-Warren considered that there is only limited substitutability, and it is unlikely to be an option for developers who rely on the Play Store or another Android app store for discoverability.
2444 Direct downloading of individual apps relies upon the user being aware of the specific developer’s app and the ability to download that app from the specific developer’s website. For that reason, direct downloading is not a sufficient constraint on distribution via Android app stores to be in the same market as Android app stores.
2445 Contrastingly, Professor Asker considered direct downloading of individual apps as sufficiently substitutable to impose equivalent or greater constraints on the Play Store as services supplied by third-party Android app stores.
2446 I prefer Ms Edwards-Warren’s view. The direct downloading of individual Android apps from a website on an Android device is not a close substitute for distribution through an Android app store.
2447 First, there are inherent functional limitations with direct downloading for both developers and users, which prevent a meaningful amount of switching from occurring.
2448 Second, users and developers do not consider direct downloading to be a close substitute to downloading from an Android app store.
2449 Third, there are significant switching costs associated with directly downloading apps for users and developers.
2450 Fourth, for direct downloading, developers distribute their own app directly to users without an intermediary. This is a form of self-supply of distribution services.
2451 Now direct downloading has functional limitations which prevent a meaningful amount of switching.
2452 There are significant limitations on users acquiring apps by direct download as compared to an Android app store. This in turn reduces the desirability of distributing apps via direct download from the perspective of developers. Given network effects, if app developers anticipate that only a minority of users will sideload apps, it will make them less likely to make direct downloads available, which in turn makes sideloading a less commonly sought alternative by users.
2453 First, there are significant discoverability challenges associated with distributing apps via direct download. This method of distribution requires users to navigate through their web browser to a developer’s website for each app they wish to download. Users are only likely to discover apps available via direct download if they are specifically looking for the app. App stores, by comparison, contain a library of categorised and searchable apps from multiple developers.
2454 Now direct downloading might be an option for popular apps that have high awareness among Android smart mobile device users outside of the Play Store, but it is unlikely to be an option for apps that rely on the Play Store or alternative app stores for discoverability.
2455 Mr Sweeney’s evidence was that it would be more difficult for Epic to attract users to the Epic Games Store on Android if Epic only distributed the Epic Games Store on Android devices via direct download.
2456 This is because the process of direct downloading an app from a website involves more time and effort than downloading it from an app store. It requires the user to navigate to the developer’s website using their mobile web browser app. In contrast, storefronts such as the Play Store and the App Store have search functions, provide users with suggested and recommended apps and group apps by category to enable apps to be more easily discovered if the user were not actively looking for the specific app. Further, many Android device users have become accustomed to downloading apps only from app stores, and not directly from developers’ websites.
2457 Further, Mr Weissinger explained that Android users would be unlikely to discover an app that was made available outside the Play Store through direct download or via the Galaxy Store, unless they were specifically looking for that app and were aware that there were alternative options to the Play Store which they could use to download the app.
2458 Second, users must endure the install flow that is imposed by the technical restrictions, which materially degrades the direct download experience as compared to that of downloading and installing an app through an app store with privileged install permissions.
2459 The preponderance of the evidence is that additional steps and frictions in the download and install process act as a disincentive to Android device users from directly downloading apps, as I have discussed elsewhere.
2460 Further, the frictions have a compounding effect, because users who have experienced the frictions associated with direct downloading once will then anticipate the frictions on subsequent occasions, reducing the share of users opting for direct downloads from a website in the future.
2461 Further, as well as encountering frictions during the downloading process, users who directly download apps encounter additional frictions when updating those apps. Those frictions are generally not present when users download apps from Android app stores. Many app stores as an additional service automatically update apps that users have installed from their stores. But Google does not make its automatic update functionality available to directly downloaded apps. So, if users only access an app by sideloading, rather than obtaining it through the Play Store, the process of updating that app is more difficult as the user will not receive updates through the Play Store.
2462 Further, users and developers do not consider direct downloading to be a close substitute to Android app stores.
2463 Let me say something about the developers.
2464 Now only six of the top 50 apps (or 12%) by consumer spending on the Play Store in Australia in 2021 are available for direct download. This small percentage of developers making their apps available for direct download indicates that developers do not consider distributing their apps via direct download to be a viable alternative to app store distribution.
2465 Mr Grant’s understanding was that the vast majority of developers do not make their mobile apps available for direct download. And even where users can navigate to a developer’s website and attempt to install an app, the result is often that the website link will redirect users to an app store.
2466 Further, the fact that some developers offer their apps for direct download in addition to distributing their apps through an app store is not evidence that, in response to a SSNIP on the commission payable to the app store, developers would stop distributing via Android app stores and exclusively offer their app for direct download. It is also not evidence that users would switch to directly downloading their apps.
2467 Epic’s unsuccessful attempt to distribute Fortnite on Android outside of the Play Store demonstrates the lack of substitutability for developers as between Android app store distribution and direct downloading.
2468 As Mr Weissinger explained, the Fortnite usage statistics on Android from the launch of Fortnite in around August 2018 to March 2020 demonstrate that Epic was unable to acquire a significant user base by making the game available outside of the Play Store via direct download from Epic’s website.
2469 This was so despite Epic’s significant endeavours to promote the launch of Fortnite via direct download and the Galaxy Store when it launched in August 2018, including by, in the months following the launch, allocating over USD 7 million a month to advertisements aimed at encouraging users to directly download Fortnite.
2470 This demonstrates that even when developers attempt to remedy the discoverability and friction issues associated with direct downloads by deploying large and sophisticated marketing campaigns, distribution via direct download is not a viable alternative to app store distribution.
2471 Let me say something about the users.
2472 The low take-up of direct downloading reveals that users do not consider direct downloading of individual apps to be a substitute for downloading apps via Android app stores.
2473 In 2020, no more than 3% of apps in Australia, and 12% globally, were distributed to Android devices via direct download. In contrast, 75% of apps in Australia, and 80% globally, were distributed through an app store.
2474 The data Ms Edwards-Warren analysed recorded both downloads made either directly from an app developer’s website or via directly downloaded third-party app stores, described as an “unknown source” download in the dataset.
2475 So, the 3% figure calculated for direct downloads is the upper bound, and the true proportion of apps distributed via direct download is likely to be lower.
2476 Google’s own documents confirm that direct downloading of individual apps by users is limited.
2477 One undated internal presentation titled “Special Topic: Off-Play Installs (a.k.a. Sideloading)” showed that off-Play Store installs accounted for 12% of all installs globally and came from three main sources, the largest being the “Package Installer” source, which includes direct downloading and apps downloaded from third-party app stores. “Package Installer” accounted for 79% of all off-Play Store installs.
2478 Ms Edwards-Warren considered this document and concluded that “Package Installer” accounts for approximately 9.5% of all installs globally. The document also identified India, Indonesia, Iran and Iraq as countries with over 15% of installs occurring via off-Play Store installs, whereas off-Play Store installs accounted for 3.6% of downloads in Japan and 4.4% in the United States. Data specific to Australia was not included.
2479 These statistics support the conclusion that Android device users have likely grown accustomed to searching for and downloading apps through the Play Store, this being a further barrier to substitution.
2480 Further, there are significant switching costs associated with directly downloading apps for users and developers.
2481 For Android device users, the cost of directly downloading an app onto an Android device in place of downloading via an Android app store is closely linked with the functional differences, in particular the additional steps required and frictions introduced by the technical restrictions. This is supported by the data on the limited prevalence of direct downloading.
2482 Further, a developer wishing to distribute apps via direct downloading would need a website and a mechanism for promoting and marketing its apps to Android users.
2483 It follows that if a developer does not already have an appropriate website, then the cost of switching away from an Android app store to distribution via direct downloading is likely to be significant.
2484 Developers also incur additional costs in reaching users when switching to distribution via direct download.
2485 Epic had to spend millions of dollars on marketing and advertising targeted at acquiring users via a direct download distribution channel, which it was ultimately unable to recoup. Many developers are not able to make such a financial outlay.
2486 It is too great a barrier for small developers and a sizeable disincentive for large developers to switch from Android app store distribution to direct downloading. To go from the use of an app store for distribution to direct downloading essentially involves the developer having to self-supply its own distribution service, which is likely to carry with it its own inherent costs.
2487 All of these matters further support the conclusion that direct downloading of individual apps is not a close substitute for distribution via Android app stores for either users or developers. Moreover, such a possibility does not deny or negate Google’s substantial market power.
2488 Let me turn to another topic.
The possibility of pre-installation
2489 Android apps can be installed onto OEM devices before those devices are sold to users, such that the app is available to the user "out of the box". This method of app distribution is referred to as pre-installation, and an app that is installed in this way is known as a pre-installed app.
2490 Pre-installation of individual apps is not a substitute for distribution via Android app stores for a large number of developers.
2491 Now the only area of dispute between the economists is whether pre-installation of individual apps is a substitute for distribution via Android app stores for a small number of large developers.
2492 Ms Edwards-Warren said that pre-installation of individual apps does not constrain Google, and so ought not be included in her Android mobile app distribution market.
2493 Contrastingly, Professor Asker was of the view that pre-installation of individual apps is a substitute for distribution via Android app stores for large developers. But he said that there was a lack of data necessary to quantitatively evaluate whether substitution by large developers to pre-installation, in conjunction with other substitutes, would on its own be sufficient to discipline a hypothetical monopolist of Android app distribution.
2494 Accordingly, the narrow area of disagreement between the economists has no impact on the question of market definition.
2495 Now whilst Professor Asker said that only a few large developers would need to substitute to distributing their apps via pre-installation in response to a price increase by the hypothetical monopolist to discipline that hypothetical monopolist, he did not ultimately identify sufficient evidence to lead him to conclude that pre-installation of individual apps ought be included in the Android mobile app distribution market.
2496 Let me turn to Google’s arguments.
2497 Google says that the issue concerning pre-installed apps is whether they are a substitute for distribution via Android app stores for enough large developers to constrain the Play Store.
2498 Now Epic says that they are not, because it is costly to negotiate pre-installation agreements with developers, OEMs are reluctant to pre-install apps, and pre-installed apps encounter discoverability issues. But Google makes a number of points.
2499 First, Google says that large developers have successfully utilised pre-installation, indicating that consumers are willing to follow them to the pre-installed app. Out of over 5 million new Android smartphones active in Australia in 2021, the number of new pre-installations was 3.7 million for Microsoft OneDrive, 3.3 million for Facebook and 2.7 million for Netflix. This does not reflect reluctance on the part of OEMs or developers with respect to pre-installation.
2500 Second, Google says that Epic has provided no evidence to support its proposition that pre-installed apps face discoverability issues, particularly in the case of well-known apps.
2501 Third, Google says that Epic itself reached pre-installation agreements for the Fortnite installer or the Epic Games App stubs with Samsung, Huawei, Sony and LG. And this was at a time when Fortnite accounted for less than 0.1% of the Play Store in-app purchases revenue in Australia when it was on the Play Store.
2502 So, there is little basis for thinking that large developers would have difficulty negotiating pre-installation agreements with OEMs, particularly when apps developed by major developers like Microsoft (Microsoft OneDrive, Microsoft Outlook), Meta (Facebook), Netflix (Netflix) and Amazon (Amazon Kindle) are distributed on Android devices in Australia in substantial numbers via pre-installation.
2503 Fourth, Google says that it would only take a few of Google’s top 25 developers, who account for nearly half of the Play Store’s service fee revenues, to substitute to pre-installation to meaningfully constrain the Play Store.
2504 But on this aspect of the case, in my view the evidence establishes that pre-installation of individual apps is not a close substitute for distribution via Android app stores, even for large developers.
2505 I accept Ms Edwards-Warren’s conclusion about that for the reasons she gave. It is inefficient and costly for developers to negotiate pre-installation agreements for individual apps. Further, OEMs are reluctant to pre-install third-party apps. And further, pre-installed apps encounter discoverability issues and account for a small fraction of total Android app installs.
2506 In any event, Professor Asker conceded that he had insufficient information to conclude that pre-installation would discipline a hypothetical monopolist of Android apps distribution. Accordingly, the narrow area of disagreement between the economists has no impact on the question of market definition.
2507 But even if I preferred Professor Asker’s view on the issue of substitution for a small number of large developers, I would not conclude on the available evidence that pre-installation is a sufficiently strong competitive constraint on distribution via Android app stores to bring pre-installation within the Android mobile app distribution market.
2508 Further, it is inefficient and costly for developers, including large developers, to reach Android users at scale by pre-installing individual apps. That is because doing so requires developers to reach pre-installation agreements with numerous OEMs and carriers, typically including individual agreements with local sales teams for each OEM in each local market.
2509 Clearly, a large majority of developers that distribute through the Play Store lack the resources to successfully negotiate pre-installation deals with OEMs.
2510 But even if an agreement is negotiated, it is unlikely to apply to all geographic markets. Further, it may only apply to a limited set of devices or models including, typically, only new devices. Further, it could be time limited.
2511 Further, any agreement with an OEM as distinct from a carrier will typically only apply to unlocked devices, as opposed to locked devices, which are sold by carriers as part of retail mobile contracts and plans. A separate pre-installation agreement would likely need to be negotiated with the carrier in respect of locked devices, which typically differ from country to country.
2512 By comparison, distributing an app on an Android app store is much easier for developers because it provides a single and accessible mechanism by which developers everywhere can distribute their apps to a global audience.
2513 The technical infrastructure to efficiently distribute apps and app updates on billions of devices in around 190 countries around the world on an ongoing and timely basis is complex, and is one of the services that the Play Store provides to developers.
2514 App developers would therefore incur significant switching costs in switching from distribution via an Android app store to distributing via pre-installation.
2515 Further, as I have said above OEMs are reluctant to pre-install third-party apps. Moreover, the challenges encountered by developers when negotiating pre-installation agreements with OEMs are compounded by the fact that the number of spaces available for pre-installed apps on Android devices is limited. Google, the OEM and the carrier typically pre-install a large number of their own apps on Android devices.
2516 There is also evidence of user resistance to pre-installed apps. There is a perception among device users that pre-installed apps are bloatware, meaning that they are not useful and unnecessarily take up storage and screen space on the device. Having a number of pre-installed apps serving similar purposes creates a bad user experience, and tends to lead to devices being filled with bloatware that users do not want.
2517 A 2015 internal Google presentation titled “Application discussion” recorded that 66% of Samsung users were dissatisfied or very dissatisfied with having multiple pre-installed apps on their devices which serve similar purposes.
2518 That document also recorded Samsung’s “[p]reload app reduction target” and sets out the number of pre-installed apps across various devices. In each case, the device is dominated by pre-installed apps owned by Samsung, Google and the carrier, and the reduction target contemplates reducing the number of third-party pre-installed apps from between seven and 11 down to between two and four.
2519 The conclusion recorded is that “[r]educing lots of preloaded apps by focusing on high-value/usage can help Samsung provide a better, uncluttered Android experience”.
2520 In contrast, an Android app store can distribute notionally an unlimited number of apps. The number of apps available on Android app stores is orders of magnitude higher than the number of apps typically pre-installed. Moreover, pre-installation is not an option for many app developers given that it would be impossible to pre-install the millions of apps available via Android app stores. There are over two million apps on the Play Store.
2521 The inherent limitations mean that pre-installation of individual apps is an option for a limited number of apps only.
2522 Further, given that OEMs are driven by user demands, user resistance to pre-installed apps constitutes another barrier to app distribution via pre-installation.
2523 Further, pre-installed apps suffer from issues with discoverability unless they are placed prominently on a user’s device, for instance, on the default home screen (DHS). DHS placement maximises the discoverability of the app as users can more readily see and access the app, and are therefore more likely to open and use it. But discoverability is limited if an app is on the “plus one” screen, meaning it is less likely that users will notice and open the app. But it is challenging for developers to secure DHS placement.
2524 In the case of Epic's negotiations with LG and Sony in relation to the pre-installation of the Fortnite installer and the Epic Games App, Epic was not able to place the Fortnite installer app stub on the DHS of those OEMs’ devices. Rather, it was and would have been placed on the plus one screen of the relevant devices.
2525 On Samsung devices, the Fortnite installer stub was located within Samsung’s Game Launcher, which was located in the “app tray”, requiring users to swipe on their device to locate the app, rather than the DHS of the relevant Samsung devices.
2526 So, pre-installation of individual apps is not a comparable distribution method from a device user's perspective given the passive nature of app acquisition and lower app discoverability. Further, pre-installed apps are a small fraction of total app installs.
2527 Moreover, pre-installation is not an option for many developers.
2528 Now Professor Asker maintained that a number of large developers with substantial consumer spending could viably use pre-installation to distribute content. Professor Asker identified 10 examples of such large developers in support of that proposition. But even if Professor Asker is correct in suggesting that his 10 identified large developers could feasibly substitute to pre-installation, substitution by those developers would not discipline the Play Store.
2529 Of the 10 developers identified by Professor Asker, only five of those apps contribute to Play Store revenue, as five are consumption-only apps. As Ms Edwards-Warren explained, the five apps listed as having high spending via the Play Store being Microsoft OneDrive, Facebook, Dropbox, Linkedin and Evernote each accounted for a maximum of 0.31%, and 0.81% in aggregate, of Google’s revenues from the Play Store in Australia in 2021. So, even if these apps could reasonably substitute all consumer spending towards pre-installed versions of their app, it would unlikely be sufficient to discipline a hypothetical monopolist.
2530 In summary, the possibility of pre-installation goes nowhere in terms of market definition. Moreover, to state the obvious, that possibility does not deny or negate Google’s substantial market power. Let me now deal with some other topics.
App stores on gaming consoles and PCs
2531 Google says that the fact that users and developers can and do choose between Android and non-mobile platforms respectively for purchasing app-based digital content and developing apps means that the Play Store faces a significant threat to its revenue from other platforms. And Google says that given that its service fee revenue is highly concentrated amongst users and developers, this revenue risk from other platforms represents a competitive constraint.
2532 It is said that there are four key sources of evidence which demonstrate this substitution, and therefore a competitive constraint, between the Play Store and app stores on gaming consoles and PCs.
2533 First, there are internal Google documents recording Google’s perception of competitive constraint from gaming consoles and PCs.
2534 Second, there are communications and agreements between Epic and gaming console operators.
2535 Third, there is the Fortnite spend data and the spending patterns that it shows, which I have discussed elsewhere.
2536 Fourth, there is the quantitative analysis by Professor Asker and Professor Goldfarb which I have separately discussed in detail.
2537 Let me deal with the first and second aspects in this part of my reasons.
2538 Now Google says that there is evidence of Google’s perception of competition from consoles and PC.
2539 Google’s internal documents record perceptions of competition with, and competitive threat from, PC and gaming console platforms. For example, the following may be noted.
2540 A February 2018 presentation titled Project Hug: Risk & Leakage Model, in the section headed “Market dynamics”, lists “PC/Console” operators alongside mobile app stores and describes their competitive activities. Another slide states “[d]evelopers have invested in PC/Console and don't value Play's position; need to give partners more back because they’ve invested”.
2541 A further February 2018 presentation titled Project Banyan, Hug and RSA / Play Kicker: Risk & Leakage Models records the same perception as the Project Hug: Risk & Leakage Model presentation. Further, on a slide titled “Mitigation effectiveness”, which refers to Project Hug and the “Samsung Deal” (Banyan), it rates mitigation effectiveness of Hug with respect to the Epic Store, Samsung Store, Amazon Store and PC-Dev Store. The reference to “Epic Store” and “PC-Dev Store” are references to PC stores.
2542 Google says that this all reflects a perception on its part that there is some competition with PC and console operators as well as mobile app stores. Moreover, there is little doubt that Google’s perception is that lines between platforms are becoming blurred such that there is competition across them.
2543 Further, Google itself has been interested in how Android and the Play Store compare with other platforms including gaming consoles, which is consistent with perceiving gaming consoles to be competitors to some extent
2544 Further, Google says that there is evidence of console operators’ perception of competition from other platforms. Major gaming console operators perceived a real and substantial competitive threat to their in-app transaction commission revenue from other platforms including Android.
2545 Google says that these fears were expressed and acted upon when Epic sought to include cross-progression and cross-wallet functionality in the versions of Fortnite on the Sony PlayStation, Microsoft Xbox and Nintendo Switch consoles. Google says that such fears reflect the essence of competitive constraint between platforms for revenue-generating transactions.
2546 First, Google says that in the case of the Sony PlayStation, there is a “most favoured nations” clause in the cross-platform policy schedule to Sony’s PlayStation Global Developer & Publisher Agreement with Epic concerning Fortnite, both in the 2019 policy schedule and the current 2022 policy schedule.
2547 The policy schedule essentially permits Fortnite users to engage in cross-platform gameplay, being online play with users on other permitted platforms, cross-platform progression, being the transfer of progress in the game across permitted platforms, and cross-platform commerce, being the ability to use digital content and virtual currency purchased on PlayStation on other permitted platforms and vice versa. The permitted platforms are PC (Windows PC, Mac OS or Linux OS), mobile (iOS or Android), console (Xbox and Nintendo Switch) and streaming.
2548 And the relevant effect of the “most favoured nations” provisions of the schedule is that Epic must offer Sony the opportunity to sell on the PlayStation equivalent digital content and virtual currency made available on other platforms, but limited to non-exclusive content in the 2022 version.
2549 Further, Epic must offer Sony a wholesale price no higher than the wholesale price for equivalent digital content and virtual currency on other platforms, or where Epic controls the retail price, a wholesale price that is no higher [REDACTED] of the retail price of equivalent digital content and virtual currency on other platforms.
2550 Further, if the ratio of PlayStation’s cross-platform revenue share to its gameplay share is below [REDACTED] Epic must pay Sony [REDACTED] of the difference between [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
2551 Now it would seem that the commercial object of such provisions is to ensure that PlayStation is not competitively disadvantaged in price or quality terms on Fortnite in-app purchases relative to other platforms, and compensate Sony if users switch their spending (but not use) to other platforms.
2552 Google says that the inference that arises from the inclusion of these restrictions is that Sony was concerned that cross-wallet and cross-progression functionality in Fortnite would allow users to switch their spending to other platforms and that this represented a strong competitive threat to Sony’s PlayStation commission revenue.
2553 Second, Google says that in the case of Microsoft’s Xbox gaming console, emails between Epic and Microsoft executives record similar competitive concerns held by Microsoft with respect to cross-progression and cross-wallet in Fortnite. In particular, the following may be noted.
2554 When Mr Sweeney in January 2018 raised the possibility of Xbox participating in Fortnite cross-progression and cross-wallet across platforms including iOS and Android, Mr Spencer of Microsoft expressed concern about digital items on Xbox being uncompetitively priced relative to other platforms, and the revenue loss to Microsoft that this would cause.
2555 In March 2018, Microsoft’s proposal for Fortnite cross-progression between Xbox and other platforms, but not cross-wallet, was that Epic must offer content parity across platforms on digital items, and must not intentionally drive purchases of V-Bucks and digital content to one platform versus another.
2556 More recently in June 2020, when Mr Sweeney made a proposal to Mr Spencer to use XCloud for its games in exchange opening up mobile platforms and connecting app stores, Mr Spencer expressed the view in an email to Mr Sweeney on 10 June 2020 that allowing third-party app stores to sell their games on Xbox “breaks the model”, as there would be no revenue back to Microsoft.
2557 These communications reflect a perception on Microsoft’s part that when cross-progression and/or cross-wallet functionality across platforms is enabled within a game, users will treat different participating platforms including mobile as substitutable transaction venues.
2558 The fact that Microsoft was not prepared to allow cross-progression or cross-wallet without mitigating the threat to its revenue gives rise to an inference that Microsoft perceived this form of substitution to be a competitive constraint.
2559 Third, Google says that in the case of the Nintendo Switch, in July 2018 Epic and Nintendo discussed the inclusion of cross-wallet functionality in the Nintendo version of Fortnite. In that context, a Nintendo executive expressed concern that allowing users to buy V-Bucks on other platforms and use them on the Nintendo Switch could cannibalise Nintendo’s commission revenue. This represented a perception on Nintendo’s part that cross-wallet functionality allows users to substitute between platforms for making in-app purchases.
2560 Now I agree with Epic that developers and users would not switch away from using Android app distribution services to obtaining app distribution services on PCs or consoles as a result of small but significant changes in the relative price or quality of Android app distribution services.
2561 Pointing out the obvious, Epic says that mobile devices and non-mobile devices serve quite distinct purposes. They have distinct user bases and, insofar as those user bases overlap, the use to which each device type is put is complementary or supplementary.
2562 Moreover, developers who wish to have their apps accessed and used in the contexts in which Android devices are used will need to develop their app for Android, and have it distributed using Android app distribution services.
2563 And clearly, the distinct roles of mobile and non-mobile devices are reflected in several observable characteristics about the industry. Many mobile apps are not available on PCs or consoles, and vice versa. And a material proportion of Android device users do not have a PC and/or console, and are unlikely to obtain one in response to an increase in the price of Android app distribution services.
2564 As Epic says, from a user’s perspective, if the app they wish to use is not available on non-mobile platforms, they will not switch to using those alternative platforms. And even where an app is available on both mobile and non-mobile platforms, users are unlikely to consider these as close substitutes.
2565 Further, there are important technical differences between mobile and non-mobile devices that mean that they lend themselves to use in different contexts or for different purposes.
2566 The considerations discussed by Professor Goldfarb under the term “device first” explain this phenomenon. As he explained, in the case of mobile devices, usage is often a function of situational convenience. So, should the user’s desired app be unavailable on their mobile device, a user is more likely to switch to using a different app on that device, or engage in a different activity entirely, rather than switch to a non-mobile device to access the app.
2567 Because users do not substitute PC and console devices for Android devices, developers must develop Android apps to access Android users. Consequently, developers are unlikely to consider distribution of their app on non-mobile devices as a substitute for distribution on Android. Further, many apps developed for mobile are not developed for PCs or consoles, limiting the ability or willingness of users to switch between the two.
2568 Now central to Professor Asker’s view on this topic was his econometric analysis of switching by Fortnite users from the Play Store to PCs and consoles. But as I have discussed elsewhere, Professor Asker’s analysis had various problematic aspects. But in any event, most other apps cannot be used across platforms in the same way as Fortnite. So the conclusions which Professor Asker draws from his analysis of Fortnite do not have general application.
2569 Now I accept that Google has genuinely perceived from time to time competitive constraint from gaming consoles and PCs. But none of this amounts to close substitution or would deny or negate Google’s market power as I have discussed elsewhere.
2570 Further, I also accept that communications and agreements between Epic and gaming console operators reflect a perception of competition from other platforms. But again, none of this amounts to close competition or would deny what I have said elsewhere on market power.
2571 Let me now say something about out-of-app payments.
Out-of-app payments
2572 Now Professor Asker said that developers that pay the Play Store’s service fee can transact with consumers that download their app from the Play Store outside of the app for content that consumers then use within the app. As a result, he said that relevant substitution possibilities that should be considered include “rival transaction venues”.
2573 But this is all a variation on Professor Hitt’s and Mr Houston’s theory that I have discussed in my reasons in the Apple proceeding that there is a “transaction” market. It has little substance. And importantly, it has nothing to do with substitution for distribution services.
2574 Epic made the correct and obvious point that the ability of users to acquire content outside of an Android app, but use it within the Android app, is dependent on them having obtained the native app via a distribution method. That is ordinarily done through an Android app store, involving the provision by Google of its app distribution services. So, the postulated constraint involves no substitution away from those distribution services.
2575 But in any event, as Epic says, the possibility of users purchasing digital content outside of an Android app, then consuming it in an Android app, does not constrain the hypothetical monopolist in its provision of Android app distribution services.
2576 First, for those apps that do not offer digital content outside of the developer’s Android app, out-of-app purchases are not possible.
2577 Second, many developers do not set different prices on different channels.
2578 Third, even for apps where out-of-app purchases are possible, users may not be aware of that possibility.
2579 Fourth, Google’s anti-steering rule prohibits developers from even telling their users about an out-of-app solution via in-app promotions or user-interface flow.
2580 Fifth, even where users are aware of the possibility, users are unlikely to divert unless they are aware that alternative payment solutions are cheaper. But it is often difficult for consumers to obtain comparative information about pricing of app content across different sources.
2581 But in any event, even if all those difficulties were overcome, users are unlikely to engage with the process of conducting out-of-app payments instead of in-app purchases on native apps.
2582 But even if the ability to purchase digital content outside of an Android app then consume it in the Android app were to impose some constraint upon the hypothetical monopolist’s app distribution services, that would not warrant treating these other “rival transaction venues” as a substitute for distribution services.
2583 As Epic says, the constraint would simply be a product of the hypothetical monopolist’s present monetisation strategy, to which it cannot be assumed to be wedded.
2584 The hypothetical monopolist’s app distribution services are not the subject of any constraint from out-of-app purchases, particularly in circumstances where the hypothetical monopolist could change how it monetises its services.
2585 Finally, if it is necessary to state the obvious, Apple’s App Store and the services it provides is not a close substitute. I have dealt with the topic of competition with iOS and the App Store in a separate section of my reasons.
2586 Now let me approach questions of substitution and choice from another angle by focusing more specifically on, first, the perspective of developers and, second, the perspective of users. But contrary to what Google has put to me, these choices, save for other Android app stores, do not amount to substitutes for market definition purposes and nor do they negate or deny Google’s market power.
2587 Now I should say that I have addressed web apps and cloud streaming services in my reasons in the Apple proceeding and adopt what I have said there.
Other possible choices for users
2588 As Google has said, in respect of users using a web app, website or streaming app, another option for using apps and purchasing app-based digital content on Android devices is to use the device’s web browser.
2589 Further, there are many apps which offer out-of-app purchases on websites for which the Play Store receives no service fee revenue when users subscribe outside the app.
2590 The Play Store also earns no service fee revenue when users purchase in-app content via the developer’s website, which is common among some gaming apps. This too is an option for purchasing app-based digital content that users have available to them.
2591 Further, for Android users who own other kinds of devices, such as an iOS device, a PC or a games console, there are many apps that provide the option of using the app and/or purchasing app-based digital content on a non-Android device instead of an Android device, being of course multi-homing.
2592 Professor Asker’s analysis demonstrated that of the top 50 apps by spend on the Play Store in Australia, 92% offer an alternative non-mobile transaction venue. Professor Asker’s analysis demonstrated that of the top 25 game apps by spend on the Play Store, 22 can be played on non-mobile platforms, 19 have cross-progression functionality and 14 have cross-wallet functionality.
2593 Ms Edwards-Warren extended this analysis to show which other platforms could be used for these apps. Her analysis demonstrated that all 25 can be used on iOS, 17 can be used on PC in native form and 20 can be used on PC if browser-based formats are included. Further, 3 can be used on game consoles and 1 can be used on a cloud game streaming platform. Her analysis also demonstrated similar numbers for cross-wallet functionality, with digital content for 12 apps additionally available for purchase on a web shop.
2594 Professor Asker’s analysis also demonstrated that of the top 25 non-game apps by spend on the Play Store, 23 can be used on non-mobile platforms, 21 have cross-wallet functionality and 18 offer cross-platform subscription functionality.
2595 Now the ability for multi-homing users to switch between platforms is also not limited to switching completely to another platform for the purpose of using an app or purchasing app-based digital content.
2596 The cross-wallet functionality means that for many apps the user can de-couple their app use from their app spend. This allows partial switching between platforms, because a user can play on one platform, and spend on another.
2597 Google faces the risk of users purchasing virtual currency and digital content outside the Play Store and its service fee being bypassed. App users can and might choose to purchase content on other platforms notwithstanding that they consume that content on mobile.
2598 But I do agree with Epic that the choices available to multi-homing users are limited. This is supported by the fact that the estimates of iOS and Android user multi-homing, and user multi-homing across mobile and non-mobile devices, are low.
2599 But I also agree that the analysis of the Fortnite spending data confirms that Android device users both have the choice and actually exercise the choice to purchase in-app digital content on alternative platforms notwithstanding that they use the Fortnite app downloaded from the Play Store.
2600 Epic’s own internal analysis shows that users who first started playing Fortnite on Android predominantly purchase Fortnite in-app digital content on other platforms. There is 21.6% of spend on Android versus 34.9% of spend on PlayStation 4, 19% of spend on Xbox, 4.8% of spend on Nintendo Switch, 14.6% of spend on PC and 5.2% of spend on iOS. This spending pattern only makes sense if there is significant multi-homing.
2601 Further, there is some evidence that some users might primarily play Fortnite on Android but deliberately choose to boot up their console to make in-app purchases.
2602 Now Epic said that the top games on the Play Store typically are not available on gaming consoles or PC app stores, and vice versa. And it relied on a s 50 summary of screenshots of app store websites showing the extent to which top free, grossing and selling games on the Play Store are available on PlayStation, Xbox and the Microsoft PC store, and the extent to which top selling games on Steam, top games on PlayStation and most played games on Xbox are available on the Play Store.
2603 But Google pointed out that the majority of the top free, grossing and selling games on the Play Store are available on PC using an emulator of the native app or via a web browser. Likewise, about half of the top PlayStation and Xbox games are available on the Play Store as mobile versions, and more than half are available to play on Android devices via cloud streaming services. So, users have a choice of platforms with respect to top games on Android.
2604 Further, all Android device users have the option of switching to iOS when it comes time to replace their device, which typically has an expected life of 3.2 years.
2605 Based on survey data identified by both Ms Edwards-Warren and Professor Asker, a significant proportion of Android users in fact switch to iOS when they replace their device. Surveys identified by Ms Edwards-Warren show that on average 11% of Android smartphone users and 29% of Android tablet users switch to iOS. Surveys identified by Professor Asker show that between 8% and 25% of Android smartphone users switch to iOS. So, switching between device operating systems is an option for some users.
2606 Now Epic relies principally on the views of Ms Edwards-Warren and Professor Dhar concerning the significance of user switching from Android devices to iOS devices in response to a change in app price or quality, or in-app digital content price or quality. I have discussed Professor Dhar’s evidence elsewhere.
2607 Ms Edwards-Warren expressed a view to the effect that a small increase in the service fee would not make much difference to Android device users having regard to the purchase price of a new iOS device.
2608 Ms Edwards-Warren’s proposition was that a 10% increase in the service fee, if fully passed on, would amount to a 3% increase for the user in app-based digital content spend, which is insufficient to justify purchasing a USD 900 iOS device based on the average user spending USD 235 per year on the Play Store.
2609 I should say here that I have accepted Ms Edwards-Warren’s position on this aspect.
The choices available to developers
2610 Let me say something about the choices available to developers which Google has identified and with which I agree, although I would say that although I have found that developers have some options available to them, these do not amount to a close competitive constraint upon Google for market definition purposes.
2611 Like Android device users, app developers have viable choices available to them for distributing and monetising their apps. These choices are also not necessarily all or nothing, because developers can pursue several different distribution and monetisation options simultaneously. But there are limits to how many options a developer can pursue at once, and faced with finite resources, developers typically must at least prioritise some options over others, if not choose between them.
2612 Now the choices for developers start with options as to the platform for which they make or through which they distribute their apps. These options include mobile platforms, that is, Android and/or iOS, gaming console platforms, PC, web apps, websites and streaming services. Sometimes, the extent to which these options are attractive to a developer may depend on the nature of the app they intend to make.
2613 In the gaming app context, a high fidelity AAA game app may be more appropriate for a gaming console and PC than a mobile or web-based format, and developers may target the applicable platform accordingly. Likewise, whilst a casual game designed for a mobile environment may work well in a web-based format, it might not be appropriate for a gaming console or PC. Some developers therefore may choose to develop their game for a specific format.
2614 High fidelity role-playing games, shooter games and car racing games now can be played on mobile devices and not just gaming consoles and PC. This has been driven by improvements in technology, particularly for mobile, and users becoming more comfortable with using virtual thumb sticks on a glass screen.
2615 Further, whilst some casual games made for mobile are not made for gaming consoles, they can appear on PCs. Indeed, Epic’s s 50 summary regarding the platform availability of top games, and Google’s addendum to that s 50 summary, show that the top games on the Play Store typically are available on at least one other non-mobile platform.
2616 Likewise, most top games on gaming consoles or PC are available on Android via cloud streaming services, and half are available in a mobile version on Android.
2617 Further, in the non-gaming app context, although gaming consoles would not be a relevant platform choice, developers still have a choice as to other platforms for which to make their app such as mobile, and within that Android and/or iOS, PC, or web-based, whether as a web app or website.
2618 The availability of such choices is confirmed by the evidence which shows that developers often choose to make their non-game app for multiple platforms. For example, Professor Asker’s analysis found that all but two of the top 25 non-game apps on the Play Store are available on non-mobile platforms or via the web including webstores and have cross-wallet or cross-progression functionality.
2619 Generally, I accept that to some extent developers can in many cases choose between platforms when deciding whether to make an app for a platform, or the extent to which they will invest in a particular platform.
2620 Let me say something further about the distribution options within the Android ecosystem.
2621 If a developer chooses to develop an app for Android devices, the Play Store is not the only means by which it can make its app available to Android device users. The evidence shows that developers have several viable distribution options within the Android ecosystem other than the Play Store.
2622 First, there are several Android app stores through which developers can distribute their apps. These app stores are a realistic option for developers in Australia given that roughly 72% of Android devices come with an alternative app store pre-loaded, including 67% of devices having the Samsung Galaxy Store pre-installed, and that at least 5% of Android devices have at least one sideloaded app store.
2623 Second, just as sideloading is an option for users, sideloading is an option for developers to distribute their apps. But how viable this option is was a matter in contest between the parties. I tend to agree with Google that this option is more viable than Epic would suggest. Nevertheless, this possibility does not take Google far in terms of market definition. It is still an inferior option. Certainly it does not go close to suggesting close substitutability, although Ms Edwards-Warren was not as dogmatic as I am.
2624 Further, for some developers, particularly significant ones, pre-installation is an alternative for making an app available to users. But not all app developers would be able to do a deal with an OEM to pre-install their apps on Android devices.
2625 Further, developers have the option of making their app available as a web app or website, and many do so. Many prominent developers offer their app both as a native app and a web app or website. So, developers can and do choose between native apps and web based apps, and often use both.
2626 Further, game developers have the option of making their games available to Android device users via cloud game streaming. This is a viable option, even for high fidelity or high quality games.
2627 Let me now at this point say something about the available choices as to monetisation strategy. The options available to developers are not limited to the platforms on which they make their apps, or the distribution channels within those platforms. Developers also have various options with respect to how they monetise their apps and games, as Google points out and as I have also described elsewhere.
2628 First, there is the “free to play” or “freemium” model, whereby the app or game is free to download, but digital content within the app or game including perhaps extended game play requires an in-app purchase.
2629 Second, there is the “advertising” model, whereby the developer displays paid advertisements to users within the app or game and earns revenue on those advertisements from the advertiser.
2630 Third, there is the “premium” or “pay upfront” model, whereby the developer charges a price to download the app.
2631 Fourth, there is the “subscription” model, which involves offering access to digital content within the app if the user pays a regular subscription.
2632 Fifth, there is participation in Google’s Play Pass, which is a subscription service sold by Google which provides users with access to a bundle of more than 1,000 apps.
2633 Sixth, one can have a combination of any one or more of the above monetisation strategies.
2634 Now not all of these monetisation strategies result in revenue for the Play Store. So, if a developer chooses the advertising model, the Play Store does not receive any service fees on the ads displayed within the app. Further, under the subscription model, the developer has the option of making their app consumption only, which means that users can only access digital content within the app if they pay for digital content or a subscription outside the app. So, the digital content or subscription is not offered as an in-app purchase.
2635 Developers have options as to the transaction venues that they use for monetising their apps. The fact that developers can sell access to app-based digital content via a subscription or one-off purchase outside the app on a website means that developers can choose to distribute their app through the Play Store but avoid paying service fees by offering out of app purchases.
2636 Further, as Google says, the fact that app developers can offer cross-play, cross-progression and cross-wallet functionality in their apps means that developers can choose to distribute their app through the Play Store, but avoid paying service fees when users choose to purchase in-app content on a different platform, such as in a version of the app on a gaming console or PC.
The concentrated nature of the Play Store’s revenue
2637 Let me finally deal with one more topic raised by Google concerning what it says is the risk presented by the concentrated nature of the Play Store’s revenue.
2638 Now the evidence establishes that the Play Store’s apps and games revenue is heavily concentrated in numerous respects.
2639 So, a May 2019 Project Magical Bridge document records that apps and games revenue is highly concentrated in the following ways: by category, with 88% of revenue coming from games rather than non-game apps; by developer business model, with 94% from in-app purchases; by geography, with 29% from the United States, 22% from Japan, 13% from Korea; by developer, with less than 1% of developers accounting for 90% of spend; and by user, with 3% of users being high value users who account for 50% of revenue.
2640 So, the Play Store’s revenue is vulnerable to advances by other participants in the ecosystem, who may naturally seek to target the highest value developers on the Play Store, and to developer and user choices. Perception of this risk is also reflected in Google’s internal documents.
2641 So, it may only take a small number of prominent developers to make choices that deprive the Play Store of revenue to have a significant impact on Google’s profitability.
2642 So, if a handful of prominent developers threaten to switch to alternative means of distribution, Google may have to respond by enhancing its value proposition for them. Likewise, if high value users are switching to alternative app stores in order to obtain their favourite games, Google may have to respond by enhancing its value proposition for them. There are subtleties to the developer position which I will discuss later when I address Project Hug and “beacons of the ecosystem”.
2643 Undoubtedly this is relevant to any competitive constraint that Google may face, although it has little if anything to do with market definition as such given that on any view users and developers do not act as a close constraint.
Summary
2644 In terms of the question of substitution, my principal conclusions are the following.
2645 First, the only close substitute for Android app distribution services is other Android app stores. Android app stores do provide a competitive constraint on the Play Store such as to be a close substitute.
2646 Second, there is some substitutability between sideloading of apps and Android app distribution services, but it is not a close constraint, and users and developers do not consider it to be a close substitute.
2647 Third, the pre-installation of apps is not a close substitute for Android app distribution services.
2648 Fourth, there is some competition with PC and console operators and mobile app stores, but there is not close substitution.
2649 Fifth, out of app payments would not constrain the hypothetical monopolist of Android app distribution services.
2650 Now I should note that the fact that I have found that various other products and services are not close constraints and therefore are not part of the relevant product dimension of market definition does not entail that the availability of such products and services do not provide some form of competitive constraint. In my view they do provide a competitive constraint to some extent, although not such as to deny Google’s substantial market power in the relevant market.
Is there any competitive tension between Google and Apple?
2651 Now I accept that Google faces some competitive constraints from Apple and the App Store with respect to Android OS and the Play Store.
2652 First, Google perceives a threat of losing developers wholly or partially to iOS and has in some respects sought to mitigate this threat.
2653 Second, Google perceives a threat of losing users wholly or partially to iOS and has in some respects sought to mitigate this threat.
2654 Now in my view Epic understates the level of competition and Google overstates such a level. But on any view, Apple does not provide any close competitive constraint.
2655 I have discussed this question to some extent in my reasons in Epic v Apple in considering the question from the perspective of Apple. Let me now look at this from the perspective of Google and users or developers concerning Android apps.
2656 Now in my view services for the distribution of native apps on iOS are not a close substitute for Android app distribution services for users or developers, largely for the reasons that Epic has pointed out.
2657 First, native iOS apps will not function on Android devices, such that users would have to switch from an Android device to an iOS device before they could make use of services for the distribution of native apps on iOS.
2658 Second, developers who switch to services for the distribution of native apps on iOS would be unable to reach Android device users through those services.
2659 Third, it is uncommon for Android device users to multi-home and users face significant barriers to switching from Android to iOS devices.
2660 Fourth, in deciding what mobile device to purchase, users do not place any real weight on the price of apps and in-app purchases or the number and variety of apps. I note that that proposition is reasonably justified by Professor Dhar’s surveys.
2661 Fifth, Android device and iOS device users represent distinct user bases. Developers do not distribute iOS apps instead of Android apps.
2662 Now I have discussed the detail of this elsewhere. Let me turn to some more specific aspects of Google’s position and the various points that it has made, many of which have some merit putting to one side for the moment that it overstates its position at times.
Google’s arguments
2663 Google says that the evidence demonstrates that there is actual and potential substitution of users and developers, including in terms of relative investment and release prioritisation particularly by developers of popular apps, between Android and iOS devices. And this is amplified by the presence of same-side and cross-side network effects between users and developers.
2664 Further, Google says that competition with iOS is a principal driver of Google’s strategy for Android and the Play Store, its constant investment in the development of innovative features for Android devices, and the pricing and quality of the services provided by the Play Store.
2665 Further, Google says that there are strong and enduring economic incentives for Google to partner with OEMs to ensure that Android devices are developed, promoted and remain attractive for users and developers. That is because Google can only monetise on Android when users actively engage with their devices.
2666 Further, Google says that unlike iOS, Android is a free and open-source operating system which is available for use and modification. This means that Android is susceptible to fragmentation. But fragmentation is not a problem for iOS devices because Apple does not face this externality by virtue of its vertically integrated model.
2667 Google says that whilst this means that Android’s openness and flexibility contrasts with Apple, it also means that the success of Android is dependent on the following matters.
2668 First, Google’s success is dependent on attracting OEMs to build Android-compatible devices, particularly high-end devices that are closely competitive with Apple’s devices. Google says that its primary motivation in partnering with OEMs is to compete with Apple and to prevent users choosing iOS over Android.
2669 Second, Google’s success is dependent on securing developers to create apps for Android and incentivising them to invest in and prioritise their Android apps. This is one of the ways in which Google competes with Apple.
2670 Third, Google is ultimately dependent on users purchasing and continuing to purchase Android devices. And the initiatives implemented by Google to attract iOS users and retain Android users is another way in which Google and Apple compete and is reflected in the rates of switching between these ecosystems.
2671 Google says that it competes with Apple to draw users and developers to its platform, including in respect of features of the operating system, security functions and ease of use. Mr Gennai gave evidence that competition with Apple for both users and developers is a “fundamental driver” for its investment in the Android ecosystem.
2672 Further, Google says that the empirical evidence suggests a high degree of switching between users of Android devices and iOS devices, with the Android-to-iOS switching rate having reached 25% in 2015. Professor Asker also estimated that the net switching rate from 2019 to 2021 ranged between 5% to 13% in the direction of iOS.
2673 Further, Google says that Epic’s contention that the switching rates should be considered in the context of users who were already changing their smartphones oversimplifies the switching process. Google says that the focus on the small window in which users are actively looking for a new device is misplaced, as a decision to switch in that period will be informed by the user’s experience of their existing device over its lifetime.
2674 Further, Google says that in recognising both the prospect and reality of a user switching between Android and iOS devices, Google has undertaken several initiatives designed to achieve the following objectives. It made the following points.
2675 First, Google has sought to increase the number of users switching to Android devices from iOS devices. So, in November 2020 Google entered into a “Go-To-Market” agreement with Samsung whereby it agreed to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. The agreement noted the desire of Samsung and Google to collaborate to promote the sales of Samsung’s Android phones and tablets. For a device to qualify for a payment under the agreement, it was required to have [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] The agreement reflects two matters. Google was incentivising Samsung to compete for iOS users, [REDACTED][REDACTED] reflecting the competition which Android devices face from iOS devices. Further, it was in Samsung’s commercial interests to collaborate with Google in the promotion of Samsung devices, in competition with iOS devices.
2676 Second, Google has sought to invest in improving the quality and affordability of Android, together with enhancing the switching experience from iOS to Android, and highlighting new features, form factors and the perception of “newness” of Android devices. Apple also uses the marketing strategy of perceived “newness”.
2677 Third, Google has sought to retain Android users generally, and otherwise reduce the level of churn to iOS. Google has partnered with OEMs for the purpose of increasing the competitiveness of Android devices relative to iOS devices. Google’s promotion of a consistent, premium and high-quality out-of-the-box and continuing experience for Android users is to ensure that Android devices remain competitive with, and to attempt to reduce switching to, iOS devices.
2678 Fourth, Google has sought to retain and win high value users (HVUs) from iOS, including by developing and introducing a loyalty reward program on the Play Store as a direct response to competition from other app stores in Japan for HVUs.
2679 Fifth, Google has sought to retain and win high value gamers, and in that respect has recognised that Android’s overall health could be improved by reducing iOS churn.
2680 Further, the purchase of an Android device by a user is necessarily a loss of sale opportunity for Apple’s iOS and vice versa. Further, if OEMs lose Android device sales to iOS devices, Google will lose Android users and earn less from the Android OS.
2681 Further, Google says that it competes with Apple for developers.
2682 Google faces competition to distribute apps, including from iOS. Often, developers do not develop apps for both Android and iOS by default. They often make a choice between the two and prioritise developing apps for certain platforms or ecosystems, with Epic and many others developers having prioritised launching on iOS rather than Android.
2683 Further, the Play Store’s strategy is based on the fact that user take-up of Android devices will be adversely affected by any significant difference between the quality and diversity of apps available on the Apple’s App Store.
2684 Further, Google says that it has recognised that the impact of popular apps launching exclusively on iOS, or on iOS before Android, is amplified by same-side network effects. The concern for sim-shipping partially stemmed from the technical debt that historically existed between Android and iOS, where developers, particularly gaming developers, faced technical issues in creating games for Android as opposed to iOS.
2685 Google says that this asymmetry between apps available on Android and iOS impacts Google’s ability to compete. As such, Google recognised that attracting a wide range of quality developers to Android would enable Google to close the gap between it and iOS at a faster rate.
2686 Let me turn to the question of fee changes. Google says that it has revised its service fee in direct response to Apple’s reduction of subscription rates from 30% to 15% in 2016.
2687 Mr Feng’s evidence was that Google’s price reductions were founded on a concern that if Google did not make the same changes as Apple, it would make the Play Store less competitive and less attractive to developers for investing in Android apps distributed via the Play Store.
2688 Google has reduced its fees to 15% on the first USD 1 million in revenue for all developers in the United States, in direct response to Apple’s introduction of its small business program, which implemented reductions for only those developers who made less than USD 1 million per year.
2689 In this way, Google says that it was not simply mimicking Apple. It was actively seeking to undercut iOS. As Mr Gennai says, had Google failed to respond to Apple’s initiative, it would have jeopardised developers’ investment in the Play Store and, ultimately, user and OEM participation in the Android ecosystem. This is supported by the contemporaneous Google documents.
2690 For example, in an 18 November 2020 internal Google email Mr Samat said:
As you’ve seen today apple made their announcement about 15% for devs making $1m or less
…
Do we need to follow suit with a change and how quickly? My sense is we will have pressure from these same sized devs and thus need to do something. But we shouldn’t necessarily do the exact same thing as our challenges are different. For example, I could see us going to zero percent for devs less than $100k and then 15% up to $1m and then 30%.
…
2691 Google says that this communication, which was sent on the same day that Apple introduced its small business program, sits at odds with Epic’s suggestion that Google would have responded at a quicker pace if the App Store and the Play Store were truly substitutes.
2692 The evidence further demonstrates that the Play Store price changes were not immediate because Apple’s changes prompted a thorough and detailed pricing and business model review by Google. The reality was that the issue was complex and took some time to resolve.
2693 Further, Google says that it has also continually initiated, and responded to, pricing changes on the App Store. Exhibit 40 of Professor Asker’s report, which is worth setting out here, sets out a timeline showing both Apple’s and Google’s changes to service fees in the period between July 2008 and March 2022:
2694 As is apparent from exhibit 40, there were multiple price changes with each of Apple and Android as the first initiators.
2695 Further, Google says that the criticism that Apple did not respond to certain service fee changes made by Google goes nowhere. The important point to focus the competition inquiry on is why Google made that change, which was to better compete against Apple and iOS.
2696 Further, Google says that it competes with Apple on device quality and price.
2697 Further, Google says that it continually introduces new features to Android in response to developments on iOS and to front-run iOS, with the Play Store seeking to outperform the App Store with new innovations.
2698 Further, Google says that there is competitive rivalry between Google and Apple with respect to app store pricing.
2699 Now Epic says that Google does not compete with Apple because the only three service fee changes that Google identifies with respect to Apple were not driven by the need to compete with Apple, but were rather to address regulatory concerns.
2700 But Google says that the evidence shows that its perception of the need to compete with Apple was a significant motivating factor in each change to its service fee.
2701 The first change was a reduction in the service fee from 30% to 15% for subscriptions that had been active for more than one year, effective 1 January 2018.
2702 Google says that what prompted it to consider this change was that Apple had reduced its commission for subscriptions active for more than one year from 30% to 15% in June 2016, and the concern that if Google did not follow suit, the Play Store would be less competitive and less attractive to developers investing in the Play Store.
2703 In a 31 July 2017 internal presentation titled “Subscriptions V2 Follow-Up” that considered the potential change for subscriptions, Google referred to the app store commissions then charged by Apple and Amazon, and described potential competitive responses from both Apple and Amazon.
2704 Google says that when it came to make the service fee change, bringing the service fee into line with Apple was one of five reasons for doing so.
2705 In cross-examination, Mr Feng gave evidence that this was an instance of Google competing closely with iOS, and Google had received a substantial number of inquiries about whether and when it would at least match Apple.
2706 The time it took Google to make this change does not gainsay that it was in part a response to Apple. Mr Feng denied that Google waited, and said that “sometimes things take a long time at Google”.
2707 The second change was a reduction in the service fee to 15% for the first USD 1 million earned each year by all developers, effective 1 July 2021.
2708 This service fee change was the ultimate conclusion of Project Runway, which was a project led by Mr Feng that had the purpose of considering how Google could respond to Apple’s reduced 15% commission for small business developers announced on 18 November 2020.
2709 Google says that this evidence is corroborated by the fact that a November 2020 presentation titled “Project Runway”, just after Apple announced its 15% commission for small business developers, was focused on options to respond to Apple, and viewed “Do Nothing” as “Not recommended” and “Match Apple” as “Insufficient”.
2710 It is also supported by an 18 November 2020 internal email from Mr Samat, which was sent on the same day as Apple introduced its small business program, in which he said:
As you've seen today apple made their announcement about 15% for devs making $1m or less
…
Do we need to follow suit with a change and how quickly? My sense is we will have pressure from these same sized devs and thus need to do something. But we shouldn't necessarily do the exact same thing as our challenges are different. For example, I could see us going to zero percent for devs less than $100k and then 15% up to $1m and then 30%. …
…
2711 Google says that its service fee change went further than Apple’s because it applied to all developers, not just those earning less than USD 1 million, and Mr Feng regarded this as a “potentially subtle, but very important difference”. This is competition at work.
2712 Mr Feng also gave evidence that he considered this change to be critical for ensuring that the Play Store remained competitive with the App Store, and maintained this view in cross-examination. And whilst Mr Feng acknowledged that one motivation for the change was responding to regulatory pressure, he disagreed that it was the primary reason or that the change otherwise would not have been made.
2713 The third change was a reduction in the service fee for subscriptions to 15% in the first year, effective 1 January 2022. Mr Gennai gave evidence that this change was made to ensure the Play Store would remain competitive with the App Store. Google says that Epic has not pointed to any document which contradicts that rationale for this particular service fee change. With the change, the Play Store undercut the fee rate applied by the App Store which applies a 30% rate to subscriptions in the first year.
2714 Further, there are several app categories for which the Play Store charges are lower service fee than Apple, which is also consistent with the Play Store facing competitive constraint from the App Store.
2715 Let me turn to another topic. Google says that it closely monitors the quality of user and developer experiences, and the competitiveness of Android as against iOS. It has made the following points.
2716 First, Google says that it has monitored the gap between Android and iOS, particularly in respect of app quality, high value gaming and monetisation. Google has sought to compare performance on Android and iOS, and track results over time in respect of game quality metrics. It has also noted that top games do not perform as well on Android, and that the monetisation gap was caused in part by high value gamers favouring iOS devices over Android devices.
2717 Second, Google says that it has monitored the performance of the Play Store as against the App Store, including the range and flexibility of distribution of apps, number of installs, total consumer spend, top gaming releases and sim-ships on each platform.
2718 Third, Google says that it has monitored the revenue share on the Play Store as compared to the App Store and Apple’s revenue share for subscriptions.
2719 Fourth, Google says that it has monitored developments with Apple gaming initiatives such as Apple Arcade, and has perceived the need for Google to develop its cross-screen capabilities in light of the stronger alternatives.
2720 Fifth, Google says that it has monitored Apple’s initiatives with developers, including the reductions in service fees and the way it implemented the small business program. These were not only identified and reported internally within Google immediately, but steps were taken to respond swiftly.
2721 Further, Google says that it has frequently benchmarked itself against Apple and iOS and has made the following points.
2722 First, Google had regard to Apple’s responses arising from the setting of Google’s subscription fees in 2017. In particular, Google compared the revenue share models of Apple and Amazon.
2723 Second, the change in Apple’s service fees prompted Google to consider how Google could respond to Apple’s initiative. Contrary to Epic’s assertion that Google’s strategy vis-à-vis Apple was to engage in “mimicry”, as part of continually re-evaluating its business model, Google determined that such a strategy (“match Apple”) would be “insufficient”, instead opting to undercut Apple. Google also assessed Apple’s potential response if Google was to create its own independent business model for the Play Store.
2724 Third, Google has conducted surveys of users to ascertain perceptions of its brand, product quality and general attractiveness to users, as compared to iOS and how to better improve the Android experience to draw iOS customers.
2725 Fourth, Google has commissioned surveys of developers who distributed their app or game through the Play Store in respect of their perceptions of brand quality, safety, privacy, value and developer experiences generally, including metrics which compare their experiences against the experiences on the App Store.
2726 Further, Google pointed to the following witnesses’ evidence concerning Google’s perception of competition with iOS for developers.
2727 Mr Gennai gave evidence that Google perceives a risk that developers will not spend time creating apps for Android at all, or will make apps for iOS first, or will not invest in sufficient quality on Android apps, leaving Google at a competitive disadvantage to iOS. Developers often make a choice between Android and iOS and prioritise certain platforms or ecosystems.
2728 Mr Rawles gave evidence that Google is principally concerned with ensuring that game developers choose to develop for Android alongside iOS, that is, they do not choose to only develop for iOS or iOS first.
2729 Ms Kochikar gave evidence that attracting a wide range of quality developers to Android would enable Google to close the gap between it and iOS at a faster rate.
2730 Google says that this evidence was supported by its internal documents. It referred to the following documentary material.
2731 A 9 April 2015 presentation titled “Reinventing Strategic Merchandising” identified as a high priority the need to encourage developers to invest in apps for Android, to sim-ship on Android and iOS and to invest in new features and updates on Android on par with iOS. It recorded that a significant proportion of apps launched on iOS were launched first on iOS or only on iOS. It also recorded what action Google considered it needed to take for apps that ship first or only on iOS, namely to ensure the same performance as iOS so that developers have incentives to develop for Android and do so at the same time as iOS.
2732 An April 2017 presentation titled “Android Games Strategy Review” recorded that Android users at that time had a “suboptimal gaming experience” versus iOS, and that there were “gaps in premium titles & indies” and “big simship misses”. In other words, developers were either not launching significant titles on Android, or releasing them after iOS. Developers preferred to launch on iOS due to better revenue growth and monetisation, and made inferior quality apps for Android OS due to performance issues.
2733 An internal email dated 15 May 2018 from Ms Kochikar recorded the concern that “Indies” were continuing to launch exclusively on iOS, reinforcing iOS as “the gaming platform”, and stated Google’s perception that it needs to “combat” Apple. It also recorded that high fidelity games were “gated by lots of tech issues across Android,” creating “the risk of an iOS only launch”. Ms Kochikar’s “nightmare scenario” was a big game from a large developer launching first on iOS.
2734 In an internal Google email on 8 February 2019, Mr Gennai said that “if an Android user has to think even twice about whether a game is available on their Android phone, we’ve already lost a battle to Apple”.
2735 A November 2020 presentation titled “App Quality Gap 1. Initial thoughts & learning plan” records Google’s analysis of whether an app quality gap to iOS exists. It shows not only a consumer perception of an app quality gap, but that a quality gap continues to exist as a matter of fact. It also records developer feedback that developers follow an iOS “first business strategy” and design first for iOS.
2736 Another November 2020 presentation titled “The Gen Z Effect: Tech, trends, and truths for a new(er) generation” records that the Play Store does not have some of the apps relative to the App Store which Generation Z users care about.
2737 Further, Google says that its concern about sim-shipping on Android OS reflects its perception that it is in a contest with Apple’s iOS.
2738 Further, Google says that there is a perception of competition between iOS and Android for users. It referred to the following documents.
2739 A 22 July 2016 presentation titled “Close-the-Gap” records Google’s concern about a widening app store revenue gap between the Play Store and the App Store. It observes that past the Play Store revenue growth versus iOS was due to improvements in the Play Store’s app catalogue, which reflects the need to incentivise developers to make apps for Android, and in the Play Store’s billing infrastructure. But at that time, there was a gap in app store revenue and in the apps available on Android versus iOS. Google identified strategies to mitigate this gap, including 19 action plans.
2740 An April 2017 presentation titled “Android Games Strategy Review” also recorded a monetisation gap versus iOS with respect to the Play Store, and that high value gamers favour iOS. The document drew a connection between high value gamer preference and the fact that Android lags iOS on tablet and has a frustrating user experience when games do not work on Android devices.
2741 In a 17 April 2018 email, Google’s director of Android Play Partnerships, Mr Richard Turner, described an “existential threat” from iOS, because the iPhone had won market share in premium devices and was threatening to win Android users of mid-range devices. The plea to the recipient of the email, Mr Rosenberg, was to increase focus and efforts on “defending Android share in the mid-range from iOS”.
2742 A 4 December 2019 presentation titled “JP Play OS Platform Gap” recorded that despite Android having a 50/50 OS share with iOS in Japan, consumer spend was heavily skewed to iOS and Android’s share had decreased from 46.9% to 38.8% over the past four years. The issue causing this was a significant gap in Japan between iOS and Android amongst HVUs and young gamers. The presentation also recorded a concern about the potential for a similar gap to develop in the United States and identified potential pilot programs to mitigate this loss of share.
2743 Further, Google pointed out that an important cohort of first-time smartphone purchasers are young users. Two-thirds of first-time smartphone purchasers in 2018 were so-called millennials. Further, Google was concerned about Android’s low popularity amongst Generation Z users.
2744 Further, it said that 4 to 6% of smartphone purchases in Australia in 2021 were from first-time purchasers. Accordingly, the possibility of first-time smartphone purchasers choosing iOS devices poses an additional constraint on Google.
2745 Further, Google made reference to the following other evidence.
2746 Mr Feng’s view was that the Play Store competes with the App Store, as well as with other distribution channels available on Android and other digital content distribution platforms such as gaming consoles.
2747 Further, Ms Kochikar said that Google’s objective in entering into a deal with Samsung in April 2019 for the provision of exclusive content to Samsung users via the Play Store was to allow Android devices to compete with iOS.
2748 Further, Mr Gennai’s evidence was that iOS is Android’s closest competitor in competing for developers, primarily because the large number of iOS users makes iOS a highly attractive platform for developers to develop apps for. Mr Gennai also gave evidence that there are some apps that exist on both Android and iOS, but with quality differences. He said that these differences were a regular focus of app reviews and some media commentary, often with a sentiment favouring iOS. Mr Gennai said that this has been a longstanding concern of the Play Store team and is a reason why Google works hard to assist developers and encourage them to invest in developing for Android. Further, Mr Gennai gave evidence concerning the reasons why developers may launch on iOS instead of Android.
2749 I should say that I have reflected on all such evidence although I do think that Ms Kochikar and Mr Gennai were prone to exaggeration as to the level of competition between iOS and Android.
Analysis
2750 Now as I have discussed in my reasons in the Epic v Apple proceeding, Apple says that Google and Apple compete for the business of developers, including the transactions that take place in respect of developers’ apps. Further, I have discussed the parties’ various positions concerning competing app stores.
2751 I would incorporate by reference in these reasons what I said in my Apple reasons concerning the relevant evidence, arguments and findings. Let me deal with some additional matters or other dimensions to matters that I have already discussed.
2752 Now as Epic points out, the long-standing commercial agreements in place between Google and Apple are the opposite of what one would expect to find if they were close competitors. In truth, Apple and Google describe themselves as partners, and recognise that their relationship is mutually beneficial. That is not the language of rivalrous firms seeking to replace each other. Let me elaborate here, although I have touched on these issues elsewhere.
2753 Although Apple is not an Android device OEM, Google has entered into agreements with Apple which are relevant to Apple and Google’s contentions that they compete with one another.
2754 On 20 December 2002, Google and Apple entered into a contract known as the information services agreement.
2755 The information services agreement contains terms under which Apple has agreed to make certain Google services, including Google Search, available on Apple smart mobile devices. It has been amended at least nine times.
2756 Pursuant to amendment eight to the information services agreement, effective as of 30 September 2016, the following may be noted as Epic has pointed out.
2757 First, Apple agreed to make Google Search the default search engine in all geographies for use in its web browser software on iOS and other operating systems made generally available by Apple, or the Microsoft Windows operating system. “Default” here means that Google Search will automatically be used for responding to search queries initiated from Apple’s web browser software, unless the user selects a different search service.
2758 Second, Apple agreed to provide [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
2759 Third, Google agreed to pay Apple a percentage of its net ad revenue, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
2760 Further, Google agreed to pay Apple a percentage of its “Google app” search application/Chrome net ad revenue [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
2761 So, Apple receives a significant sum from Google per year. A Google presentation titled “Apple Deal Staples” records that payments to Apple were expected to grow 41% in 2018, from USD 6.7 billion to USD 9.4 billion. Those payments are now well over USD 10 billion per annum. And Google earns billions of dollars per year in advertising revenues from being the default search engine in Apple’s web browser.
2762 Further, on 15 May 2014, Google and Apple also entered into a joint cooperation agreement. Under the terms of this agreement, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] This is hardly the stuff of vigorous competition, with [REDACTED][REDACTED][REDACTED] being the usual weapon of choice, deploying hordes of feral [REDACTED]
2763 Let me move to another topic. As Epic says, Google’s principal concern is to quash competition from other Android app stores.
2764 Now Google says that it nonetheless competes closely with Apple to attract a greater share of developers’ finite investment resources. Google says that it seeks to encourage game developers to sim-ship games on iOS and Android, as well as to build higher quality games for Android.
2765 But I agree with Epic that sim-shipping does no more than ensure that the Play Store receives releases at the same time as the App Store. Such measures would not bring about any switching from Apple to Google and do not show Google seeking to compete with Apple for developers or users.
2766 Further, Google says that its strategy for the Play Store is premised, in part, on the proposition that consumers’ take-up of Android devices will be adversely affected by any significant difference between the quality and diversity of apps available on the App Store relative to the quality and diversity of apps available on the Play Store. Yet, as Epic points out, it is curious that Google distributes a number of its proprietary apps through the App Store. Those apps include Google Maps, Google Chrome, Search, YouTube, Gmail, Google Drive, YouTube Music, and Google Photos.
2767 I tend to agree with Epic that Google’s conduct in making its highly popular apps available on the App Store is inconsistent with the premise described.
2768 Further, I am here not concerned with any direct or indirect competition for the supply of devices in any mobile devices market. I am here concerned with discussing the question of app distribution, although, undoubtedly, direct or indirect competition for the supply of mobile devices is a relevant contextual matter.
2769 Further, I agree with Epic that there has not been meaningful price competition between Google and Apple in respect of app distribution. The following matters are sourced to the evidence that I have discussed elsewhere as correctly summarised by Epic.
2770 Now with the exception of developers offering subscriptions, Google has charged developers a 30% commission on earnings over $1 million for approximately 13 years with no change. It has persisted with the 30% commission rate despite being aware of significant developer dissatisfaction towards it.
2771 Further, on the two occasions when Google has modified its commission following changes in Apple’s pricing, those modifications did no more than match, rather than undercut, Apple’s pricing, and would seem to have been motivated by regulatory and reputational aspects as opposed to competitive pressures.
2772 Further, as I have discussed elsewhere, the 30% commission is not a competitive price. It is not calculated by reference to Google’s costs of supply and it is not set at a level which would entice developers away from competing app stores.
2773 Moreover, Google’s internal documents observe that there is no real rationale for the quantum of the commission other than matching the fees charged to developers by Apple.
2774 Now Mr Feng sought to justify the 30% commission broadly on the grounds of the value that Google considers that developers derive from the Play Store. But I agree with Epic that that reflects a supplier setting a price unilaterally and then seeking to justify the price that it has already set. Developers may derive value by reason of being able to distribute Android apps and earn 70% of the price which users pay. But that says nothing about whether that rate is competitive.
2775 Further, Google has not changed the price it charges developers on their earnings over $1 million in about 15 years, and those are the developers from which Google derives the most revenue. The equivalent position applies in respect of Apple.
2776 Further, I agree with Epic that Google and Apple do not exhibit the sense of urgency that typifies rivalrous behaviour.
2777 As Ms Edwards-Warren said, if consumers do in fact switch readily in response to changes in price or quality, one would not expect to see the types of lags in price responses that she observed.
2778 Further, as Epic has said, Apple’s and Google’s changes to their commissions in respect of small developers has primarily benefited the long tail of small app developers or, in the case of the Play Store, the first $1 million of an app developer’s revenues, and has not affected the bulk of the App Store and Play Store’s revenues.
2779 But as Professor Wright observed, competitive pressure, if it exists, generally incentivises firms to:
… offer discounts to their largest customers on the supplier side given these suppliers may be in a better position to switch their business to competitors if they do not get a discount.
2780 So the pattern observed as to Apple’s and Google’s charges and behaviour is not consistent with strong competitive rivalry.
2781 Indeed, as Epic says, Apple and Google’s approach stands in contrast to Steam’s response to price competition from the Epic Games Store which resulted in the largest developers benefitting from the largest commission reductions consistent with a rational response in the face of competition.
2782 Further, as Epic correctly points out, the evidence also shows that the Play Store and App Store do not compete on quality.
2783 Now Professor Hitt and Mr Houston listed developments which they said showed that Apple strives to provide a high quality of service. Similarly, Professor Asker identified what he called competitive responses based on Google’s introduction of similar innovations on Android. Again, parallel technical development does not amount to close competition.
2784 But as Epic pointed out, ten of the 15 innovations identified by Professor Asker have a lag time of more than one year. It makes the obvious point that if Google and Apple were investing in the Play Store and the App Store in response to competitive pressure from each other, one would expect to see short lag times between Google and Apple’s respective innovations and responses to prevent user and developer switching.
2785 Moreover, as Professor Wright pointed out, the investments made by Google and Apple are equally consistent with investments made by a dominant firm in each case. And as he said, it is well established that monopolists can have an incentive to invest. And it is problematic to in effect reason, say, that an entrenched monopolist like Google does not have market power in the market for online searches because they have implemented several innovations to their search engine.
2786 Further, Ms Edwards-Warren observed that a hypothetical monopolist would invest if the return on its investment meant that it was going to increase its profit. So, it does not follow that just because Google invests to attract developers and users to the platform, it must be facing competitive constraints. I tend to accept her view that Google would make those investments regardless of whether it was facing competitive constraints or not.
2787 Finally, I agree with Epic that most references to iOS within Google documents can best be understood as a form of benchmarking exercise. But as Ms Edwards-Warren said:
… even if there is some competition between the iOS and Android ecosystems as a whole, and benchmarking of specific components within each ecosystem, this does not imply that Android Smart Mobile Device users would view the Apple App Store as a viable alternative to the Play Store (or other Android app stores) in response to a small increase in app distribution service fees.
2788 Generally, as I have said in my reasons in the Epic v Apple proceeding, there is no evidence that Apple and Google closely compete to distribute apps and parallelism is not competition.
2789 In summary, the evidence does not demonstrate that Google is significantly constrained by Apple within the relevant market.
Market power – Android mobile app distribution
2790 Epic says that Google has and had during the relevant period a substantial degree of power in the Android mobile app distribution market, but Google does not accept this.
2791 Now the principles relating to the concept of substantial market power are largely uncontroversial. But Google emphasised three matters.
2792 First, substantial market power is the capacity of a firm to act persistently in a manner substantially unconstrained by the conduct of competitors. So, if the firm has the capacity to raise prices above the supply cost without rivals taking away customers in due time, or to persistently exclude competition with restrictive conduct, this constitutes substantial market power.
2793 Google says that it did not have and does not have that capacity with respect to supplying Android OS licenses or with respect to the services which the Play Store supplies, even in Epic’s pleaded markets.
2794 Second, a necessary condition of substantial market power is the existence of barriers to entry. Absent barriers to entry, even a monopolist will be effectively constrained due to the standing credible threat of entry by rational firms if it were to raise prices and start making supra-competitive profits.
2795 Now Google says that this is important with respect to the Play Store. It says that the evidence does not support a conclusion that there are high barriers to entry. It says that there are plenty of Android app stores and web stores. Epic itself is now launching its Epic Games Store on mobile, and so is Microsoft. Google says that this is fatal to Epic’s claim that Google has substantial market power with respect to the Play Store.
2796 But in my view Google’s position as the first mover has fortified or entrenched its position to a significant extent.
2797 Third, matters such as high market shares and high profits are merely factors that may or may not be indicative of market power, but they are not determinative. I should note that forensically speaking, these factors favour Epic’s position on market power.
2798 Now Professor Asker gave relevant evidence on this topic, most of which I accept at the level of generality with which he expressed himself. Let me synthesise and set out some of his themes.
2799 The key economic concept behind market power is that a firm can elevate prices or worsen quality relative to competitive levels because its customers lack available substitutes.
2800 In that sense, the question of whether a firm has market power is closely related to defining relevant markets and the HMT.
2801 Typically, in a competition inquiry, economic analysis proceeds by first defining relevant markets and then assessing the extent of a firm’s market power within that market.
2802 Economists typically look at several indicia to assess the extent of a firm’s market power, including market shares, investment or innovation, ease of entry, and profit margins. None of these indicia on their own are dispositive as to market power, and economists instead rely on the weight of evidence by examining multiple indicia.
2803 First, market shares are commonly used to infer market power. Inference is done either by examining shares directly, by computing various market concentration metrics, or both. Market shares are generally measured as revenue shares or quantity shares. The idea is that a firm with a high market share in a relevant antitrust market may face a limited number of strong competitors or, equivalently, compete against fewer compelling substitute products.
2804 There is no bright-line threshold for market shares that separates the absence of market power from its existence. But market shares below 30% are generally viewed as insufficient for conduct to give rise to any competition concern.
2805 High market shares can go together with a lack of market power. This can occur when a firm outcompetes existing rivals but faces potential entrants or fringe competitors that can readily enter or expand and compete successfully.
2806 When this occurs, even a firm with high market share can be constrained by potential entrants and potential expansionists to whom its customers could substitute in the event the firm raised price or worsened quality. Typically, for this to occur the market needs to exhibit low barriers to entry or expansion relative to the returns a firm can earn by entering or expanding were the incumbent to raise its prices. A market with these characteristics is often referred to as contestable.
2807 Second, when a firm continues to make substantial investments in its product(s), economists recognise this as reflecting competitive rivalry.
2808 Investment in developing or providing better products reflects an effort to respond to the presence of competitively relevant substitutes.
2809 In certain contexts, it is important to distinguish investment designed to grow a market versus investment that is part of competitive rivalry. This is because firms with market power can continue to invest in a product to attract new customers that are not purchasing rival products.
2810 The way to distinguish these types of investments is to understand what types of customers the firm is trying to attract or retain. If the firm is trying to prevent a rival from poaching customers, or to attract a rival’s customers, the investment is consistent with competition rather than growing the market.
2811 Third, the competitiveness of a market is determined by both the rivalry of firms active in the market and by the prospect of entry by competitors should prices be too high, or product quality be too low.
2812 So, investigating the scope for the entry of new products, firms, or forms of product delivery, for example, can be relevant to the assessment of market power.
2813 Fourth, profit margins can be informative as to market power. But inferring market power from profit margins is complicated by measurement issues, by determining the relevant competitive benchmark, and by understanding what might constitute a high profit margin. I have discussed these matters and the relevant theory in detail in my reasons in Epic v Apple.
2814 Economic profits account for opportunity costs facing a firm, that is, costs a firm incurs by not having deployed its resources elsewhere and earned a return from doing so. The cost of something is what you give up to get it. The opportunity cost of an item refers to all the things that must be forgone to acquire that item. When economists speak of a firm’s cost of production, they include all the opportunity costs of making its output of goods and services as well as all explicit and implicit costs.
2815 An economist measures a firm’s economic profit as the firm’s total revenue minus all the explicit, implicit and opportunity costs of producing the goods and services sold. Contrastingly, an accountant measures the firm’s accounting profit as the firm’s total revenue minus only the firm’s explicit costs.
2816 These measures of accounting profits have value to firms and other relevant parties, but do not capture the relevant economic information of interest. Accountants are often focused on the profitability of the business overall, often from a retrospective viewpoint and often shaped by compliance with government regulation.
2817 Now determining what constitutes a high margin requires an understanding of the institutional features of the market. But another way of determining what constitutes a high margin is to compare a firm’s margins to a competitive benchmark.
2818 Economists can seek to find a competitive benchmark or benchmarks that may serve as proxies for what margins would be in the but for world. The relevant competitive benchmark needs to reflect the dynamics of the industry that would prevail in the but for world, some of which would be the same as in the actual world.
2819 So, it should account for ex ante risk and the need to cover fixed costs of production and product development being overhead costs without which the product would not exist. It should also reflect the competitive dynamics that would reasonably be expected to arise in the but for world. So, it is inappropriate to use a commodity market for a benchmark when the but for world is likely to include meaningfully differentiated products.
2820 Now a failure to use an appropriate competitive benchmark can incorrectly result in inferences of high margins that may, instead, reflect a necessary condition for competition to exist in the market in question, for example, risk-adjusted return on investments in fixed costs.
2821 Let me now turn to some specific topics.
Are there high barriers to entry?
2822 Google says that Epic needs to establish high barriers to entry for rival Android app stores before one can conclude that Google has substantial market power with respect to the Play Store.
2823 Now Epic says that high barriers exist because the OEM agreements give the Play Store prominent placement on Android devices and make it difficult for rival apps stores to obtain distribution via pre-installation, sideloading or the Play Store. Further, Epic says that the Project Hug agreements prevented rival app stores obtaining exclusive content from prominent app developers. But Google says that this is incorrect regarding the OEM agreements and Project Hug.
2824 Further, as to barriers to entry, Google says that Epic ignores the evidence of extensive past, present and future entry by numerous rival Android app stores, which demonstrates that barriers to entry are marginal to non-existent. It points to the following matters.
2825 First, it says that there are many services that exist to facilitate app developers creating webstores as an alternative means of selling app-based digital content on Android, including Xsolla and ID3. This means that the cost of entry by developer web stores is low.
2826 Second, it says that the low barriers to entry for webstores are corroborated by the fact most of the top 10 apps within the top five 5 categories of apps use webstores. So, of the top 10 apps in each category, 9 game apps have a webstore, 10 entertainment apps have a webstore, 6 social apps have a webstore, 10 health and fitness apps have a webstore and 7 lifestyle apps have a webstore. And across all categories, 19 of the top 25 app developers in Australia on the Play Store use a webstore.
2827 Third, it says that several Android app stores have entered the marketplace since 2009, including Samsung Galaxy Store, Aptoide, Amazon Appstore and Huawei AppGallery, and many operate today.
2828 Fourth, Google says that Epic is launching the Epic Games Store on Android no matter what the conditions, and even if the technical restrictions and the prohibition on app stores being distributed via the Play Store remain in place. It says that such a proposal or intention is inconsistent with the existence of any barrier to entry or expansion for rival Android app stores.
2829 Fifth, Microsoft announced that it would be launching its own mobile app store in July 2024.
2830 Now I agree with Epic that there are high barriers to entry.
2831 There have been and there remain formidable barriers to entry and expansion in the Android mobile app distribution market by reason of the various contractual arrangements that Google insists upon. It is not in doubt that the ability of a firm to prevent entry by potential competitors by reason of contractual arrangements is a matter to which I can and do have regard in considering the extent of Google’s market power (s 46(4)(b)), and irrespective of whether such contractual arrangements or their imposition separately give rise to competition contraventions.
2832 First, by reason of the MADA terms, the Play Store is pre-installed on all Android devices, and placed on the default home screen (DHS) or in the case of certain Samsung devices in the device hotseat. The placement requirements under the MADA assist in blocking the viability of rival Android app stores, such as Amazon’s app store, by impinging on their discoverability by users. Securing DHS placement exclusivity for the Play Store limits discoverability.
2833 The requirement for DHS placement for the Play Store has existed since 2014.
2834 The DHS placement drives users to select the Play Store over a rival app store, and ensures that the Play Store remains the obvious and simple choice for Android device users looking for apps, which is likely to continue driving widespread usage of the Play Store.
2835 Given the MADA requirements for both pre-installation and DHS placement on all Android devices, developers are and will remain highly unlikely to forgo distribution through the Play Store in favour of a rival Android app store.
2836 Second, although OEMs have the capacity to pre-install their own app stores and place them on the DHS, they can only do so on their own devices, whereas the Play Store is pre-installed on all Android devices. And they cannot do so exclusively but only together with the Play Store, due to the MADA terms.
2837 Now Samsung users have, since about January 2019, had the Galaxy Store appearing on the DHS. But that has made little difference to the Play Store’s dominance. This is due to Google’s brand salience and perceived quality perceptions of the Play Store due to the fact that the Galaxy Store was not available on the DHS prior to 2019.
2838 Third, whilst it is possible for rival app stores to obtain distribution via pre-installation deals with OEMs, Google’s conduct hinders this method of distribution, and this method can be costly and time-consuming.
2839 Fourth, by reason of the RSA3s and MIAs which Google entered into during the relevant period, a number of OEMs were incentivised to refrain from pre-installing or promoting any alternative Android app store and to increase the Play Store’s revenues.
2840 Fifth, by reason of clause 4.5 of the DDA, as well as clause 4.1 of the device and network abuse policy, a rival app store cannot obtain distribution services from the Play Store. In other words, the most effective Android app distribution channel is closed to alternative app stores.
2841 Sixth, although a developer of a rival Android app store might distribute the app store from a website via sideloading, this method presents challenges for such an app store being discovered by users.
2842 Further, until October 2021, Google did not permit directly downloaded app stores to perform a critical function, which was to update apps automatically.
2843 Further, even if a user does manage to find a rival app store on the web and seeks to sideload it to their Android device, they will confront the technical restrictions. This will likely cause a significant portion of users to abandon the installation process and the rival app store altogether.
2844 Seventh, during the relevant period, by reason of the GVP and AVP agreements, rival Android app stores were unable to offer exclusive or differentiated content, or even early access to content, from the major developers who were party to those agreements with Google. This is a real impediment to the success of a rival Android app store, since, without access to exclusive or differentiated content from key app developers, it will be even more difficult to entice users and developers away from the Play Store.
2845 Eighth, the Play Store benefits from network effects. Its value and utility to both users and developers increases as more users download, and more developers distribute, through the store. In contrast, rival Android app stores generally do not enjoy this benefit.
2846 As Google itself noted in a 4 September 2014 presentation titled Project Gabby:
3rd-party app store strategy was based on competing on completeness, but suffered from chicken-and-egg problem: Not enough eyeballs to get the catalog, didn’t have the catalog to get the eyeballs.
2847 Ninth, establishing and attempting to grow a rival Android app store capable of competing with and constraining the Play Store is likely to be expensive. A developer of a prospective alternative app store faces significant set up and scaling costs, including costs of servers and data centres, app curation, security, and customer acquisition including advertising. Most expensive of all will be the cost of persuading developers to distribute through a store which at least initially will have few users.
2848 Let me turn to another topic.
Does Google have a large market share and if so what is its relevance?
2849 Google says that the Play Store’s high market share with respect to Android app downloads and monthly active users is not an indication of market power in circumstances where there are low barriers to entry. But as I have explained, I have rejected Google’s assertion that there are low barriers to entry.
2850 Further, Google says that the competitive constraint imposed on the Play Store by rival Android app stores is substantial. Moreover, it says that Google not only perceives rival Android app stores to be a strong competitive threat, but regularly has responded with competitive conduct to meet this threat.
2851 So, Google Play Points was a response to the threat of high value users switching to the Samsung Galaxy Store and Amazon Appstore, as well as to Apple’s App Store.
2852 Further, as to Project Hug, Google says that its provision of substantial and costly incentives for large developers to remain on the Play Store would be irrational if it had substantial market power and was not exposed to competitive threats.
2853 But in my view Google has a very large market share. Moreover, I agree with Epic that Google’s competitors are weak relative to Google’s position.
2854 Now Google says that unlike for iOS, app developers can choose to distribute their apps via other Android app stores. It says that there is strong competition provided by other Android app stores. And it points to some statistics to the effect that a large number of apps are available across a range of Android app stores.
2855 But these statistics ignore the extent to which Android device users actually use the Play Store, both in terms of time spent and the proportion of app downloads, relative to the various other Android app stores.
2856 Clearly the Play Store has a dominant position in respect of the proportion of Android devices on which the Play Store is installed relative to competing Android app stores. Unless I state otherwise, I am using the concept of dominance here and in other parts of my reasons in an informal sense rather than addressing the economic concept of market dominance in a formal sense.
2857 This dominance can be seen from the following different metrics.
2858 First, as to pre-installations, from December 2017 to September 2022, the Play Store was pre-installed on between 97.7 and 99.6% of active Android devices in Australia, and between 97.2 and 99.2% of active Android devices worldwide excluding China.
2859 Its closest rival on this measure is the Galaxy Store, which was pre-installed on about 66% of Android devices shipped in Australia and about 40% globally excluding China.
2860 No other app store has been pre-installed on more than 5% of Android devices shipped in Australia, or more than about 13% globally excluding China, since 2016.
2861 Second, as to installations, app store visits, and app store time, an analysis prepared by Google in October 2019 revealed the following.
2862 As to installations, according to a 31 October 2019 presentation titled OEM App Store Share Analysis: Android Ecosystem Analytics, the Play Store was “installed on ~100 percent of 28DA devices in each region”, while no other OEM app store was installed on more than 50% of devices globally or in Southeast Asia. Further, of the OEM app stores, the Galaxy Store was installed on 41% of devices globally, with the next highest install shares being Xiaomi Market at 7%, Oppo Apps at 4%, and Vivo App Store at 3%.
2863 As to app store visits, the same presentation noted that “[f]or each region, the majority (>90%) of all app store visits in a month are to the Play Store”. Globally, that figure was 94%. Further, globally, only 2% of all app store visits in a month were to the Galaxy Store, while 1% were to Xiaomi Market, 2% were to Oppo Apps, and 1% were to Vivo App Store. Further, “[d]espite users with Chinese OEM app stores being MAU, the visits in a month make up only a tiny fraction of the region’s total app store visits (<3% of Play Store total visits)”.
2864 And as to app store time, the same presentation noted that “[f]or each region, the majority (>92%) of monthly app store time spent is in the Play Store”. Globally, that figure was 96%. Globally, only 2% of monthly app store time spent was in the Galaxy Store, while 1% was in Xiaomi Market, 1% was in Oppo Apps, and 1% was in Vivo App Store.
2865 Third, as to the volume of downloads, Ms Edwards-Warren estimated that in 2020, some 97.9% of new app downloads to Android devices in Australia that occurred through an app store were undertaken via the Play Store, while globally excluding China some 91.4% of new app downloads from an app store occurred via the Play Store.
2866 Its closest rival in Australia being the Galaxy Store had a share of only 1.5%. Its closest rival globally, being the Oppo Store had a share of only 2.5% and the Galaxy Store’s global share was 1.5%. The Play Store’s share of app downloads was very similar in 2019 and 2021.
2867 Fourth, as to the time spent by users and considering the position of the Play Store’s so-called closest competitor, the Galaxy Store and its use by Samsung users, being those one would expect to use the Galaxy Store the most, Google noted in a 19 March 2019 presentation titled “Samsung Galaxy Store Landscape” that, globally, the following position applied.
2868 About 83% of all Samsung monthly active users (MAUs) visit the Play Store for more than 10 seconds per month, while only about 19% visit the Galaxy Store for more than 10 seconds per month.
2869 Further, about 77% of all Samsung MAUs visit the Play Store for more than 10 seconds two or more times per month, while only about 12% visit the Galaxy Store for more than 10 seconds two or more times per month.
2870 Further, those MAUs who do visit the Galaxy Store for more than 10 seconds two or more times per month only stay within the Galaxy Store for about 2% of the time that they stay within the Play Store.
2871 Fifth, data compiled by Google in 2017 indicated the following. In Japan, the Amazon App Store’s MAUs were 1.4% of the Play Store’s MAUs, while Amazon’s app installs were only 0.02% of the Play Store’s app installs. In South Korea, OneStore’s MAUs were 20.8% of the Play Store’s MAU, while OneStore’s app installs were only 0.7% of the Play Store’s app installs. In India, 9Apps’ MAUs were 16.4% of the Play Store’s MAUs, while 9Apps’ app installs were only 3.6% of the Play Store’s app installs. Globally, Samsung’s MAUs were 13% of the Play Store’s MAUs, while Samsung’s app installs were only 0.2% of the Play Store’s app installs. And in the US, UK and Germany, the Amazon App Store’s MAUs were 15.1% of the Play Store’s MAUs, while Amazon’s app installs were only 0.01% of the Play Store’s app installs.
2872 If other methods of Android app distribution besides app stores are included, the picture does not materially alter.
2873 In 2020, the Play Store accounted for 73% of new app downloads in both Australia and globally. OEM and third-party app stores accounted for only 2% of new app downloads in Australia and 7% globally. Further, direct downloading, or downloads from directly downloaded app stores, accounted for 3% of new app downloads in Australia and 12% globally.
2874 A 2016 Google presentation titled Special Topic: Off-Play Installs recorded that installs from outside the Play Store represented 12% of all installs and derived from three main sources, being sideloading, pre-installed third-party app stores, and device hacks. For ten different countries, sideloading accounted for less than 12% of installs in six of them, less than 20% in the next three, and 69% in Iran; users in Iran cannot download paid apps or make in-app purchases via the Play Store. In other words, in all bar 4 countries for which a breakdown is given, sideloading accounted for less than 12% of off-Play Store installs in 2016.
2875 In a February 2018 presentation titled Project Hug: Risk & Leakage Model, Google identified Samsung as “the only OEM with sufficient share to plausibly build its own store in key Play markets”.
2876 Nonetheless, according to a February 2019 presentation titled Project Banyan Phase 1: Ecosystem Overview, Google found it “[c]hallenging to see Galaxy Store becoming attractive enough to developers to be a successful, sustainable stand-alone business” and considered that the Galaxy Store would need to acquire “exclusive rights” that would “build a user base” in order to succeed.
2877 The Galaxy Store is installed on more Android devices than any other rival Android app store. Yet Google concluded in a July 2019 presentation titled Samsung Update that “the cannibalization of Play Store revenue due to Galaxy Store is none to minimal”, that the Galaxy Store was likely “operating under net loss”; and “in absence of ‘exclusive hit-titles’ on Galaxy store, the projected trajectory is in red as well”.
2878 Further, even Samsung users who have the Galaxy Store pre-installed on their devices spend substantially more of their time within the Play Store than they do within the Galaxy Store.
2879 In my view the evidence demonstrates that the Play Store is not subject to strong competition from other Android app stores. The Play Store enjoys dominance in the Android mobile app distribution market and has significant market power.
2880 Let me turn to another topic.
Is there any meaningful or significant countervailing power of users and developers?
2881 Now ss 46(4) and (6) of the CCA provide:
(4) In determining for the purposes of this section the degree of power that a body corporate or bodies corporate have in a market:
(a) regard must be had to the extent to which the conduct of the body corporate or of any of those bodies corporate in that market is constrained by the conduct of:
(i) competitors, or potential competitors, of the body corporate or of any of those bodies corporate in that market; or
(ii) persons to whom or from whom the body corporate or any of those bodies corporate supplies or acquires goods or services in that market; and
(b) regard may be had to the power the body corporate or bodies corporate have in that market that results from:
(i) any contracts, arrangements or understandings that the body corporate or bodies corporate have with another party or other parties; or
(ii) any proposed contracts, arrangements or understandings that the body corporate or bodies corporate may have with another party or other parties.
…
(6) Subsections (4) and (5) do not limit the matters to which regard may be had in determining, for the purposes of this section, the degree of power that a body corporate or bodies corporate has or have in a market.
2882 Google says that app developers have significant countervailing power.
2883 It says that developers have several options available to them for wholly or partially bypassing the Play Store’s service fee, particularly with respect to paid in-app transactions for digital content.
2884 These options include offering a webstore for purchases of app based digital content, converting their app to a consumption only app, distributing their app via rival Android app stores or direct download or, for some app developers, pre-installation.
2885 But in my view, and as Epic correctly points out, users and developers lack significant countervailing power and, moreover, Google behaves as if it is unconstrained by competitors.
2886 There is an absence of countervailing power on the part of users and developers.
2887 Further, Google has been able to and has acted in a manner unconstrained by competitors, including by imposing tying arrangements, insisting on contracts of adhesion and unilaterally altering contractual terms.
2888 Google is not constrained by countervailing power held by Android device users.
2889 Now one way in which users might exercise any countervailing power is by switching to alternative app stores or direct download. Such alternatives are available, but are generally not taken by users. Alternative app stores had a share below 2% in Australia and below 3% globally, and direct downloading only constitutes 3% of new app downloads in Australia.
2890 Further, Google is not significantly constrained by countervailing power held by developers. Relatedly, Google behaves towards developers as if unconstrained by competitors. This is demonstrated by various matters.
2891 First, Google has for many years insisted that all developers must enter into a standard form DDA. Further, as a business matter, Google does not negotiate the DDA, even for large developers. All developers are on the same DDA with no exceptions. Moreover, the vast majority of developers perceive that they have no real choice but to accept Google’s terms.
2892 Second, by the terms of the DDA, Google has a number of powers which, in combination, place developers at its mercy.
2893 Google may alter the terms of the DDA unilaterally at any time with 30 days’ notice to the developer. If developers do not agree with Google’s changes to the DDA, their sole and exclusive remedy is to terminate their use of the Play Store.
2894 Google may also terminate its DDA with a developer for no reason at all on 30 days’ notice. Termination of the DDA will cause the developer to lose the ability to distribute or update their apps previously distributed through the Play Store. Moreover, current users of their apps will not be able to make any in-app purchases within those apps.
2895 These rights provide Google with very significant leverage over developers.
2896 Third, Google has unilaterally amended the DDA despite complaints and protests from developers.
2897 In particular, in January 2021 Google unilaterally amended its payments policy to remove the external consumption exemption, which required thousands of developers to use Google Play Billing and to pay a service fee on in-app purchases of digital content that, until then, had been exempt from these requirements. Google was able to do this despite the fact that many developers did not wish to use Google Play Billing, and had voiced significant complaints about Google Play Billing to Google.
2898 Further, in 2014 Google unilaterally amended the DDA to tighten clause 4.5 of the DDA to prohibit developers from using the Play Store to distribute “any product that facilitates the distribution of [Android] apps”. Google imposed this change even though some developers, including large developers such as Amazon and Facebook, wanted to continue distributing Android apps through their Play Store apps.
2899 Fourth, there is no evidence of material switching by developers from the Play Store to rival Android app stores.
2900 Fifth, most developers could not make a credible threat to leave the Play Store given that doing so would involve forgoing access to the large and valuable Play Store app user base and would be likely to reduce their profits. And where a developer does pose a credible threat of leaving the Play Store, the evidence concerning Project Hug shows that Google can and will offer it a sweetheart deal.
2901 Clearly, these larger developers do not constrain Google and do not “protect” the smaller developers. Moreover, the larger developers are identifiable to Google and can be offered better terms without requiring Google to offer better terms to all developers. This is borne out by what has been described elsewhere in these reasons as Mr Gennai’s 2019 Play problem statement, which discloses that Google’s tactic with Project Hug was not to compete with new entrants on price across the board, but to offer special benefits to a small number of “strategic partners”, and so lowering the “effective rev-share” for those few whilst maintaining the prevailing rate for every other developer.
2902 In respect of the millions of developers across the world who are not “beacons of the ecosystem”, there is no evidence that Google feels constrained to compromise its demands under the DDA.
2903 In any case, Google’s conduct is inconsistent with it being constrained by any countervailing power of larger developers. If Google was so constrained, one would expect to see a pricing structure which contained discounts for large developers. There is only one example of this outside of Project Hug in evidence being Spotify.
2904 Spotify pays a 4% service fee when Google Play Billing is used and 0% when its own payment solution is used.
2905 A July 2020 Google presentation titled Spotify Economic Review described the rationale for this deal as being to address “Spotify’s compliance with Google Play payments policy”, “[r]egulatory risk mitigation”, “subscription revenue” and “public advocacy”.
2906 In fact, Google’s pricing structure is the opposite of what one would expect if it were constrained by the larger developers. Clearly, Google in respect of its rates has not given larger customers larger discounts on the rates as compared with smaller customers, which is what one would normally expect if the larger customers had significant countervailing power.
2907 Sixth, Google price discriminates. It selectively determines which apps, and therefore which developers, have to pay the service fee. It exempts for example sellers of physical goods and services. This is a further indication of Google’s freedom from competitive constraint.
2908 Seventh, Google’s ability to engage in the conduct concerning the parsimonious reductions to its commissions in the context of developer only billing and user choice billing and how the reduced commissions were set well demonstrates its substantial market power in both the Android app distribution market and the payment solutions market. I have discussed the detail of this elsewhere.
2909 Finally, it is convenient to note here that other products and services do not provide significant competitive constraints and do not negate or diminish Google’s substantial market power to any significant extent. I have discussed substitution questions elsewhere when addressing market definition. There are some substitutes as I have previously discussed. But these are not close substitutes and do not significantly constrain Google’s market power.
The service fee and its variation(s)
2910 Clause 3.4 of the DDA provides that a service fee, which may be revised by Google from time to time, will be calculated and charged on the sales price of the developer’s products.
2911 The service fee is only payable on apps and in-app products sold through the Play Store’s billing system or through an alternative billing system, the latter being a system permitted under Google’s user choice billing (UCB) or developer only billing (DOB) programs.
2912 The service fee payable by app developers under the DDA has varied over time to time, as summarised in the following table which I have already set out but it is convenient to again reproduce here:
Time Period | Service Fee for subscriptions | Service Fee for developer's first US$1 million | Service Fee for developers under special programs | Service Fee for all other Play Store revenue |
Mar 2011 – 23 May 2012 | - | 30% | - | 30% |
24 May 2012 – 31 Dec 2017 | 30% | |||
1 Jan 2018 – 22 June 2021 | 30%, then 15% for automatically renewing subscriptions | |||
23 June 2021 – 30 June 2021 | 15% or lower | |||
1 July 2021 – 31 Dec 2021 | 15% or 30%, then 15% for automatically renewing subscriptions | 15% | ||
1 Jan 2022 – present | 15% for all subscriptions |
2913 As the table shows, the present service fee varies depending on the developer’s revenue and the type of digital content offered for sale.
2914 Generally, developers now pay a service fee of 15% on the first USD 1 million of revenue earned by the developer each year; a service fee of 30% of revenue in excess of USD 1 million of revenue each year; and a service fee of 15% of revenue for automatically renewing subscriptions regardless of the revenue earned by the developer.
2915 Developers eligible for special programs pay a 15% or lower service fee. These programs generally target media companies, or developers offering video, audio or music subscriptions, or digital books.
2916 In addition, Google charges a varied service fee in circumstances where UCB or DOB apply.
2917 Outside of special programs for eligible developers, UCB, and DOB, Google has made only limited changes to the service fee that it charges for in-app purchases of digital content over time. When in-app purchases were first introduced to the Android Market in 2011, the service fee for such purchases was 30%. Some 13 years later, the service fee is still 30%, save for the first USD 1 million in earnings each year and subscriptions, both of which are charged at 15%.
2918 Google’s service fees are similar to those generally charged by Apple, although there are two differences. First, Apple charges a 15% fee to developers whose earnings were under USD 1 million in the prior year, as opposed to charging all developers 15% on their first USD 1 million. Second, Apple’s fee for subscriptions is 30% in the first year and 15% thereafter.
2919 Now the first change to Google’s subscription pricing occurred with effect from 1 January 2018, when Google reduced its service fee for subscriptions that had been active for more than one year from 30 to 15%.
2920 Google witnesses said that this change was driven by a need to remain price competitive with Apple, which had reduced its fee on subscriptions active for more than one year from 30 to 15% some 18 months earlier, with effect from 13 June 2016.
2921 But the document in which this change was proposed, a document that Mr Feng co-presented, gave five reasons for the change, only one of which related to Apple.
2922 Mr Feng acknowledged that these were the five “main justifications for the change”.
2923 The other four reasons for the change listed in the document included encouraging subscription developers to adopt Google Play Billing and easing the path to a potential Play Store payment policy change, being the removal of the external consumption exemption. As to Apple, the document merely said, “Bring Play’s pricing for subscription SKUs in line with market – Apple offers 30% for 12 months, 15% thereafter”.
2924 Bringing one’s pricing into line with the market is not competing on price. Mr Feng agreed that there was no attempt to do any better than Apple at this time.
2925 Google’s behaviour did not amount to competing with Apple on price, or on any other metric. That is a fortiori when the price adjustment was made some 18 months after that of Apple. And it is especially true in this case, given the other reasons for the change.
2926 As far back as March 2017, Google had considered that a “Rev share change needs to be part of the mix to help land [the] policy change”, that is, the removal of the external consumption exemption. That consideration is expressly identified as a reason for this change in the October 2017 document which Mr Feng helped to prepare and present.
2927 Google felt that improving the price of its subscription offering would lay the groundwork for the policy change, in the face of the adverse developer and regulatory reactions which were anticipated. This was not an instance of price competition vis-à-vis Apple.
2928 Let me turn to some other changes.
2929 On 18 November 2020, Apple announced a small business program, whereby its service fee was reduced to 15% for those developers who earned less than USD 1 million in the prior year.
2930 With effect from 1 July 2021, Google reduced its service fee to 15% for the first USD 1 million earned each year by all developers. In October 2021, Google reduced the service fee for subscriptions to 15% in the first year.
2931 One of the motivations for making the first of those changes was the pressure Google was facing from regulators. But neither Mr Feng nor Mr Gennai accepted that these changes were made largely due to regulatory pressure and for PR reasons, and instead insisted that they were examples of competition with Apple.
2932 Their evidence is not supported by the contemporaneous documents.
2933 In an internal document dated 16 November 2020 titled Project Runway: Proposal for changes to Play business model, Google set out its hypotheses, including that “[w]e have an a la carte menu of additional levers to pull in a set of forecasted PR/regulatory scenarios for further discussion”, and “[w]e should proactively make moderate changes in 2021 to forestall more drastic required changes”.
2934 Under the heading “Scenario Planning”, the following scenarios were contemplated.
2935 The first stated:
* Should we be REQUIRED to adjust our service fee, we would need to re-imagine the store promotional strategy and GPB strategy.
* If government mandated requirement to make play billing optional, we respond with aggressive store changes and perhaps lower service fee …
2936 The second stated “[i]f government mandated price for play billing (say 20% or cost + 5%) (WIP, needs more thinking)…”.
2937 The third stated:
* We c/should VOLUNTARILY adjust our service fee now to improve optics, align value delivered with fees charged, and reduce agitation --
…
* We recommend the first magical bridge option (30% for the first year after user purchase, 15% thereafter) …
…
* Match Apple’s discount for small developers and perhaps be more aggressive by tiering it lower in emerging markets.
…
2938 The last scenario essentially describes the course that Google ultimately took.
2939 Mr Gennai tried to dismiss this document as a “group of five people” who were just speculating. Like much of his evidence, this was advocacy. The document does not contain speculation. It contains a record of essentially what Google did in the following year.
2940 And it is significant that the document makes no reference to a supposed competitive dynamic with Apple as somehow necessitating or justifying its proposals. Rather, the focus is on “forestall[ing] more drastic required changes” by way of regulation and “optics”.
2941 On 21 November 2020, the day of Apple’s small business announcement, Mr Samat prepared a document which commenced with a summary of Apple’s small business program announcement, including reactions from the press and developers. The document then provides an overview of the reaction from regulators, which includes that Apple’s announcement had been “informally described … as too little too late and will not help Apple’s position in the Digital Markets Act debate in Europe” and that Google was “expecting to receive” a request from South Korean legislators to “follow Apple’s lead”.
2942 The document then set out Google’s “take”, as follows:
Waiting for Apple to make the first move has been our plan. Our strategy has been to wait to make any public revenue share changes until Apple moved first. We did not want to move downward on rev share while Apple stayed at 30%, nor did we want to give them the opportunity to “one-up” any announcement we made and cause us to need to react again.
We have a very similar program scoped out…
We will take the next several weeks to gain more feedback on how Apple’s changes landed. The benefit of going second here is we have the opportunity to be more thoughtful and take into account the reaction. …
2943 So, Google wanted Apple to lower its prices and was not at all concerned that this would cause Google to lose customers.
2944 Mr Gennai denied the plain meaning of this document. It undermined his affidavit evidence and Google’s contention that it was engaging in price competition with Apple.
2945 Google’s motives are confirmed by a 2 December 2020 document titled Runway January 2021 Announcement Proposal and Status, which records that Google had “decided to announce in January 2021 an adjustment to our fee schedule, focused on providing relief to small developers and defusing some of the regulatory pressure experienced in several countries”.
2946 Defusing regulatory pressure was the real reason for this change, though Mr Gennai denied this.
2947 The following “goals” are then set out in the document:
Defuse immediate regulatory pressure
Be seen as helping people build their business…
Reduce the new perceived gap between Apple and Play’s billing policies
Continue to allow Apple to make first moves on service fee structure changes
2948 The penultimate “goal” was not about price competition but about the regulatory pressure that had arisen due to the “gap between Apple and Play’s billing policies”. That it was not about price competition is confirmed by the last goal.
2949 The document then outlines the “Desired PR and Regulatory Landings” and says “our message will be evaluated based on how many devs pay less. Press will line us up vs Apple”. Again, it was all about “PR and regulatory landings”, not winning customers from Apple.
2950 Tellingly, a drafting comment records:
… we need a headline PR/reg message – esp given that the message is the primary goal in this effort … Arguably the most believable, as well as most helpful reason is competitive pressure/response…Helpful to our case – if we’re trying to create the meme intense competitive pressure.
2951 In other words, competition was a “message” or “meme” Google was “trying to create”. If competition were the reality, this would not have been necessary.
2952 In cross-examination, Mr Feng sought to minimise this document as merely reflecting the views of its author, Mr Bankhead. I do not accept that evidence. It was self-serving and inconsistent with the extensive comments, reflecting real engagement among various contributors, including one as senior as Mr Samat. Further, the import of this document is similar to the earlier two documents.
2953 Let me say something about the possible changes to the business model and removing the payments tie.
2954 Now some developers have complained that they could not pay the 30% commission because of the impact on their ability to do business. Additionally, Google has been concerned about regulatory pressure over the level of the service fee.
2955 The service fee has been repeatedly described within Google’s own documents as “arbitrary”. That is an apt characterisation, since the 30% fee bears no discernible relationship to Google’s costs.
2956 In an August 2018 memorandum, Ms Kochikar’s subordinate described Google’s then service fee of 30% for all as “Status quo. It’s what Apple does” and said it had “No rationale. Unfeasible for many business models”.
2957 Similarly, in its March 2019 presentation titled Exploring New Business Models, Google observed that the 30% rate has “No rationale, other than copying Apple” and is “untenable for many apps/games developers”.
2958 Indeed, Google was aware that that 30% commission rate was out of proportion to the value certain developers were receiving through Google Play Billing.
2959 Now Project Magical Bridge considered alternative business models that included charging developers separately for different services, including for payment solutions.
2960 Google engaged in a lengthy examination of billing optionality, whereby developers would have the opportunity to acquire their own payment solution.
2961 There was never any dispute about whether it was technically possible to separate the billing system from other aspects of Google Play Billing. From the launch of the Play Store until 29 March 2011, Google did not offer a payment solution for in-app purchases and developers adopted their own payment solutions during that period. And in the 15 or so countries where Google Play Billing is not offered, developers incorporate alternative payment solutions into their apps.
2962 Further, Google has separated the billing system in South Korea. In jurisdictions where UCB is available, the alternative billing system is a separate and distinct service.
2963 I have discussed the detail of all of this elsewhere.
2964 Generally, outside of special programs for eligible developers, being UCB and DOB, Google has made only limited changes to the service fee that it charges for in-app purchases of digital content over time.
2965 When in-app purchases were first introduced to Android Market in 2011, the service fee for such purchases was 30%. Some 13 years later, the service fee is still 30%, save for the first USD 1 million in earnings each year and subscriptions, both of which are charged at 15%.
2966 Moreover, where Google has made changes to its commission rates, those changes were not principally driven by price competition or non-price competition, but by regulatory pressure or other factors.
2967 Google has continued to charge the 30% commission rate despite significant developer dissatisfaction, with some developers describing the fee as a “tax” and an “exorbitant tax”. Moreover, some developers have complained that they could not pay 30% because it was impacting the viability of their businesses.
2968 I agree with Epic that Google’s ability to largely maintain prices that are deeply unpopular with developers all over the world, for some 13 years, and not have to adjust them even once due to the forces of competition, is evidence of a very substantial degree of market power.
Service fees – their comparability with “competitors”
2969 Now Google says that the service fees that the Play Store charges are not significantly above competitive benchmarks.
2970 It says that as demonstrated by Professor Asker’s analysis in exhibit 106 of his first report, the Play Store’s service fees are the same or lower than its competitors across several important indicia. Exhibit 106 is as follows:
2971 First, compared with mobile app stores, the Play Store’s headline rate of 30% is the same as the headline rates charged by Apple’s App Store, Samsung Galaxy Store, [REDACTED] and Huawei AppGallery.
2972 Further, the Play Store’s service fee on subscriptions of 15% is lower than the fees for subscriptions on Apple’s App Store, Samsung Galaxy Store, [REDACTED] and Huawei AppGallery.
2973 Second, compared with PC app stores, the Play Store’s service fee is the same or lower than the headline rates charged by Mac App Store, [REDACTED] and GOG.
2974 The Play Store also has a lower service fee than Steam on subscriptions and also the first USD 1 million of the developers’ revenue, and the same service fee on transactions where the developer’s revenue is USD 1 million to USD 10 million.
2975 Third, compared with game console app stores, the Play Store’s service fee is the same or lower except for developers earning more than USD 10 million on Steam or for game app subscriptions on the Microsoft store on Xbox.
2976 Now Google says that there are three main exceptions to its service fee being comparable or lower than its rivals, being the Epic Games Store on PC, the Microsoft Store on PC, and itch.io on PC. But for the reasons identified by Professor Asker in his first report, these app stores are likely of much lower quality than the Play Store, given their much smaller reach, amongst other factors.
2977 So, Google says that the suggestion that its service fee is not comparable to competitive benchmarks should be rejected.
2978 Further, Google says that the Play Store’s service fees also have not increased since they were first introduced at a time when the Play Store manifestly had no market power. And instead, there have been several rate reductions.
2979 But in my view Google’s market power is further demonstrated by the fact that its service fee bears no relationship to supply costs and has not once been varied due to competitive pressure.
2980 And Google has had an ability to charge prices well above the supply cost without rivals taking away customers.
2981 The Play Store’s service fees are higher than those of other mobile app stores or PC app stores besides Apple, which is a monopolist. Developers pay 15% for earnings on subscriptions and on the first USD 1 million in revenue per annum. Thereafter, developers pay a 30% service fee on non-subscription revenue.
2982 There are several PC app stores that charge less to developers.
2983 The Epic Games Store charges a commission of 12% on paid apps and in-app purchases of digital content. And in response to the Epic Games Store’ entry, in December 2018, Steam reduced its commissions such that it charges a 30% commission on the first USD 10 million in app developer revenues, 25% on app developer revenue between USD 10 million and USD 50 million and 20% commission on app developer revenue over USD 50 million.
2984 Now although the Steam percentages appear similar to the service fees imposed by Google, the difference lies in the reversal of the scale for the commission structure as against the Play Store’s service fees. For Steam, the percentage payable decreases as developer revenue increases, meaning that large developers are charged materially less than they are charged by the Play Store, with a gap of up to 10%.
2985 Further, in March 2019, about four months after the Epic Games Store launch, Microsoft lowered its commission rate for all non-gaming apps distributed on PC through the Microsoft Store from 30 to 15%. In April 2021, Microsoft announced and then subsequently lowered its commission rate for PC gaming apps to 12%, matching the Epic Games Store’s commission rate.
2986 Since 1 July 2018, the ONE Store has charged developers a 20% commission rate for paid apps and in-app purchases, while each of [REDACTED] and Samsung Galaxy Store charge lower commission rates upon negotiation.
2987 Further, smaller PC app stores charge even lower commissions. Game Jolt caps commission rates at 10%, itch.io permits developers to select commissions between 0% and 100%, and the Shopify App Store charges app developers a commission rate of 20% which developers can then apply to reduce further.
The arbitrariness of the service fees
2988 Now the service fee has been repeatedly described within Google’s own documents as “arbitrary” and it bears little, if any, discernible relationship to Google’s costs. Let me elaborate.
2989 In evidence were numerous internal Google documents recording or reflecting the fact that the 30% or 15% commission was arbitrary. In my view the fact that Google was able to get away with this and for so long is a symptom or reflection of its substantial degree of market power in the Android mobile app distribution market. Let me refer to some of the highlights.
2990 First, on 12 January 2017, Mr Samat wrote in an email exchange with Mr Brandon Barras and Ms Kirsten Rasanen:
An alternative to dropping the rev share here could be a one time commitment to go-marketing funds for 2017 to help drive growth in exchange for them getting onto play billing. This would cost us quite a bit in 2017 but could make us more money in the medium term. Once we go to 15% right off the bat there is no coming back and it puts pressure for us to do the same on other verticals.
ios's billing isn't 15% in the first year -- it's 30% then 15%, yes? Do we need to go right to 15% here? I think a longer term view here might be helpful -- I think the product team and bd should sit down and think this through a bit. For example, if we put in place a promotions and loyalty system that developers can implement in their app to help subscription based services retain and reengagement consumers across ad networks and via play store / play marketing channels we could do something clever in the future and say:
It's 30% for subs in year 1. But 50% of that we hold in an account for you to use our promotion systems to retain subs -- our goal is to help you build a long term business with loyal users. Any sub that makes it to the 1 year renewal point billing drops to 15%.
If we go to 15% right now in year 1 there is no way to go back and implement these kinds of things so it is really important to think through where we want to go.
Also, you mentioned in your summary Brandon "undetermined platform value". Are these dating companies all in the US? Do they have plans to go international? Does our billing perform worse for all of them? I have some trouble believing that because a lot these companies are smaller and unlikely to have developed sophisticated declines / involuntary chum efforts. Although I could be surprised by how bad we are at this perhaps.
Also, PaulF: I think all this 30%, 15% stuff is pretty arbitrary. The cost should be a function of the LTV and cost of acquisition in the category. Not to make things too complicated, but in the retail world Amazon marketplace charges a variable rate per category based on the underlying margin and cost structure of those goods. It shows respect for the partners business to understand things at this level -- and provides flexibility to be able to adjust as needed. In the case of Play the reality is each partner would likely just have one rate they'd need to deal with (vs. retailers who sell across categories quite often). Any thoughts on this?
(My emphasis)
2991 Second, in August 2018, Mr Karam who reported to Ms Kochikar sent a memorandum titled Democratized Payments 2020 which contained the following:
Problem
Developers build apps & games to delight their users. They stick around if they’re able to build sustainable businesses. From Fortune 500 companies to hobbyists, sustainable user engagement and revenue drives whether they invest or divest. Without engaging and innovative apps & games, a user’s Android phone is less compelling. Without delighted users, Android isn’t sustainable as a developer platform. And hence the ecosystem symbiosis (or potential lack thereof) continues…
We’ve come a long way since Android Market launched in 2008. With availability in 220+ countries and 50+ forms of payment accepted, Google Play as a distribution platform is compelling to developers. However, only a small % of developers choose Google Play as a payments provider. Based on our research (include link), this is largely because the fees are nonviable for the vast majority of developers (big and small).
So despite building tools which are meant to enable seamless billing capabilities, we’ve inadvertently enabled some of the largest companies to bypass our system and made it harder for less resourced developers to sustain businesses on Android. Let’s call this the In-App Billing Paradox.
Why is this important? Why now?
This paradox results in a cascade of less meaningful outcomes for users, developers, and Android as a platform. Less consistent purchasing experiences increase user frustration and churn (“you want me to enter 12 fields of data with my fingers to subscribe?!?”). Which limits sufficient monetization to the most established/largest developers who have built strong enough inelasticity to encourage sufficient paying user bases. Which results in less diversity for users and Android.
Wait, what about iOS?
Apple pioneered the 30% revenue share as a relic of the music industry royalties business model. Their revenue mostly comes from hardware margins so they have less incentive to change the model. It’s also not particularly Googley to follow the precedent without deep thought.
(My emphasis)
2992 Nevertheless, as to the passage that I have just emphasised, Google was quite content to engage in the practice of conscious parallelism.
2993 The document also contained the following table:
2994 The first two line entries in the table, and particularly the comments in the columns “Rationale” and “Cons” said it all. There was little if any rationale for the percentages chosen. And as to the “Fixed 30% for all”, it was said that “[it’s] what Apple does”.
2995 Third, in March 2019, in a slide presentation titled Exploring New Business Models, with Mr Feng shown as a custodian, the following slides appeared:
2996 Clearly, these slides demonstrate Google’s perception that there was no rationale for the 30% other than to copy Apple. Indeed there was no rationale for the 20%.
2997 Further, there is some revealing costing concerning Google Play Billing. Google’s own costing showed that the break even cost was 6%. But to this would have to be an allowance for fixed costs. Yet the “discount” that it was to offer developers for DOB was only 3% or 4%; hardly a realistic commercial or economic option for them on Google’s own assessment and which of course it well knew and likely intended so as to make it unpalatable for developers.
2998 Fourth, in terms of similar themes, in a slide presentation in April 2019 titled Play Business Model Thoughts the following slides appeared:
2999 Clearly, there was little if any rationale given for the 30% or indeed 20%.
3000 Fifth, another set of May 2019 slides titled Project Magical Bridge had a note on one slide of “30% somewhat arbitrary, but very clear and easy to understand”.
3001 Sixth, in an internal Google memorandum / email on or about 17 November 2020, the following was recorded:
…
The problem(s):
* Value delivered to developers by Google Play is not aligned with how much developers pay
* Some devs pay too much. Some pay too little.
* Some categories of apps pay nothing at all. (In fact, most apps pay nothing at all)
* The value provided from Play changes over an app’s lifecycle (at the start, Play helps them a lot, but over time as they build brand, infrastructure and have already acquired a loyal core user base Play’s value declines)
* The pricing (30% rev share on in app purchases) feels arbitrary and high to developers
…
In the case of in-app purchases and subscriptions, it is reasonably fair to say that developers feel the price they pay is less fair over time as their app and brand becomes bigger and they have acquired their user base.
A better model would be one that takes these existing approaches and adjusts them, rigorously with data, to ensure a more sustainable value exchange.
Specifically:
In categories where in app purchasing for digital goods (subscriptions, or in app items) is present, Play could employ a per app category rate card structure (e.g. Games has a different rate than Fitness or Music).
That rate card should reflect two elements:
* As apps get large, have established user bases, and monetize effectively the value of Play goes down and thus revenue share should also go down.
* Geographic presence. The rates paid should be judged at a country by country level as opposed to globally. This solves for two problems (a) developers might be local to one country but value delivered to them declines from Play as they grow to be large and have an established user base and (b) when they expand to another country Play often adds a lot of value.
…
3002 This material also has significance for other parts of Epic’s case, including Google’s conduct on billing, Google Play Billing, the discounts on commissions that Google has given to developers where alternative billing arrangements are permitted, the relevance to any counterfactual analysis and also the relevance to the class applicants’ case.
3003 I agree with Epic that this ability to price at a level that bears no real relationship to one’s supply cost, to the point where the price is just an arbitrary number, is evidence of a very substantial degree of market power.
Profitability of the Play Store
3004 Epic says that Google’s market power is demonstrated by the profitability of the Play Store. Epic says that Google has generated significant profits to say the least over a sustained period. But Google says that there are three difficulties with Epic’s position.
3005 First, it says that Epic’s reliance on Google Play’s management profit and loss statements (P&Ls) is inapposite because they did not have the function of assessing Google Play’s profitability or the Play Store’s profitability. In these reasons, metrics for the former have been used as a proxy for metrics for the latter as I will explain in a moment.
3006 Second, it says that Professor Davila’s analysis was flawed, both in an absolute and comparative sense, such as to render his conclusions unreliable.
3007 Third, it says that even if Professor Davila’s estimates of Google Play’s profitability are taken into account, they do not establish that Google Play is earning supra-competitive profits.
3008 Google seeks to impugn Professor Davila’s opinion as to the profitability of the Play Store, and relies on the expert opinion of Professor Peter Easton. Professor Davila and Professor Easton participated in a conclave and prepared a joint report, together with Mr Samuel whose evidence I have discussed in my reasons in Epic v Apple.
3009 I should also note here that lay evidence was also called by Google on the topic. Mr Christian Cramer, the finance director for Google Play, gave written evidence in chief. He was cross-examined by Mr Prince for Epic and Mr De Young KC for the class applicants. I found Mr Cramer’s evidence to be direct, straight-forward and precise.
3010 Now in terms of the experts, I have already made some general observations concerning Professor Davila in the Apple proceeding which I would repeat here. But let me say something further concerning Professor Easton.
3011 As I have indicated, Professor Easton, a professor of accountancy at the University of Notre Dame, US, gave expert evidence for Google concerning Professor Davila’s assessment of the profitability of the Play Store. He was cross-examined on the topic by Mr Rich SC for Epic.
3012 Professor Easton separately gave a written report responding to Mr Holt’s evidence. I should note that there was a joint expert report given by Professor Easton and Mr Holt. In the concurrent evidence session Professor Easton was cross-examined by Mr De Young KC for the class applicants and Mr Holt was cross-examined by Mr Peter Strickland for Google.
3013 It suffices at the present time to say that I had no difficulty with Professor Easton’s expertise or reliability. In terms of the subject matter of his opinions and what I have ultimately accepted, I have addressed such questions later.
3014 I should also say that in my reasons in Epic v Apple I have discussed the difference between accounting profits and economic profits and the underlying literature. This section takes that theoretical foundation as a given.
Google’s internal financial documents
3015 Now it would seem, as Epic has correctly said, that Google’s internal financial documents typically refer to financial metrics for Google Play rather than the Play Store.
3016 Google Play has three revenue sources. First, there is what is known as Apps and Games (A&G), being paid app downloads, in-app purchases, and app subscriptions on the Play Store. Second, there is what is known as Play Ads, being advertising on the Play Store. Third, there is what is known as VX, which has changed over time but today only includes books.
3017 Almost all of Google Play’s revenue comes from A&G and Play Ads. The VX segment generally has a neutral impact on Google Play’s gross margin. As a result, the financial performance of Google Play as recorded in Google’s internal documents is a reasonable proxy for the financial performance of the Play Store and I have proceeded accordingly.
3018 I should also make one other thing clear. The Play Store itself is often referred to as Google Play, although in my reasons here and in Epic v Apple I have preferred to refer to the Play Store. But in this part of my reasons, where I refer to Google Play I am referring to the business division with these three revenue sources.
3019 Now Google’s internal documents establish that Google tracks the financial performance of Google Play closely. Further, they establish that Google Play is, and has been, highly profitable for Google.
3020 Mr Cramer gave evidence that within the platforms and ecosystems (P&E) division, of which Google Play is a part, each product team prepares annual plans that typically include the previous year’s actual performance.
3021 The annual plans are presented to Google’s CFO, Ms Porat, and those presentations usually contain a summary P&L for Google Play.
3022 Mr Cramer’s team also prepares financial information regarding Google Play for inclusion in presentations to Alphabet’s board of directors.
3023 The annual plans are sometimes accompanied by finance planning decks that typically contain management P&Ls, which capture financial information such as revenue, costs of sale, gross profit or gross margin, operating expenses and operating income for each product. In addition, Mr Cramer and his team also prepare monthly P&L updates. The financial reporting process has been unchanged since 2017.
3024 Google’s senior management rely on internal P&L figures to understand how the business is performing against Google’s internal plans and P&L figures are an important input to the decision making of Google Play management.
3025 The table below sets out key financial metrics for Google Play during the period 2017 to 2022 based on Google’s internal P&Ls. For all years except 2021, the figures are drawn from the annual plans described above. The 2021 figures are drawn from a Google Play quarterly earnings review. The figures for 2017 to 2021 are actual results, whilst the figures for 2022 are a “V10 forecast”, which means that they are actual figures up to October and forecast figures for the remainder of that year.
Google Play P&L | ||||||
($ millions) | 2017 | 2018 | 2019 | 2020 | [REDACTED] | [REDACTED] |
Revenue | $6,848 | $8,878 | $11,259 | $14,662 | [REDACTED] | [REDACTED] |
Gross Profit | $4,821 | $6,678 | $8,645 | $11,444 | [REDACTED] | [REDACTED] |
GM% | 70.4% | 75.2% | 76.8% | 78.1% | [REDACTED] | [REDACTED] |
OPEX | $1,212 | $1,489 | $1,594 | $1,827 | [REDACTED] | [REDACTED] |
Operating Income | $3,609 | $5,189 | $7,051 | $9,617 | [REDACTED] | [REDACTED] |
Operating margin % | 52.7% | 58.4% | 62.7% | 65.6% | [REDACTED] | [REDACTED] |
3026 These figures demonstrate that Google Play is a highly profitable business unit for Google. This view is shared within Google.
3027 In a 20 September 2018 presentation to the CFO council titled Play Update @ CFO Council, the council being a group of finance leaders for various products in Google, Mr Cramer told Ms Porat that Google Play was very large, growing at healthy rates, highly profitable, and had consistently improving margins.
3028 As Epic points out, given that this was Google’s internal view in 2018, that can only be more true now as Google Play’s profits and margins have significantly improved since that time.
3029 In a 15 July 2020 presentation titled Google Play: Alphabet Board Update, the Alphabet board was told that:
Play is one of the world’s largest commerce platforms with >250M people transacting in an year, and also one of the most profitable businesses (>60% margin) and a key contributor to the Alphabet P/L.
3030 Now the consistent year-on-year growth of revenue, gross profit and operating income of Google Play from 2016 to 2021, and the relatively small increase in costs and opex, provides some evidence that the Play Store does not face substantial competition from other platforms and that there are significant barriers to entry.
3031 Now during cross-examination, Google’s counsel put a number of aides memoire to Professor Davila.
3032 Those were prepared by Google’s consultants, not by Professor Easton, and they purport to present profitability metrics which reflect various adjustments to Professor Davila’s approach in response to Professor Easton’s criticisms, including an adjustment to Android allocation. This exercise culminated in one aide memoire that captured the combined effects of all of Google’s adjustments. The metrics were return on gross profit (ROGP), return on assets (ROA) and return on capital employed (ROCE). I should also say that from time to time the metric of return on sales (ROS) has also sometimes been used instead of ROGP in some of the accounting material. I have set out one of Google’s aides memoire as an annexure to my reasons.
3033 The results of the profitability ratios for FY17 to FY22 are summarised below:
FY17 | FY18 | FY19 | FY20 | FY21 | FY22 | |
ROGP | 62.5% | 71.3% | 75.9% | 79.1% | 81.7% | 71.3% |
ROA | 76.7% | 86% | 81% | 86.1% | 110.4% | 88.4% |
ROCE | 174% | 157.5% | 134% | 157.4% | 194.6% | 151.3% |
3034 Now the Google aide memoire correctly sets out the combined arithmetic effect of Google's proposed adjustments. But Epic does not accept that all of Google's adjustments are reasonable or supported by the evidence.
3035 But in any event, what these figures show is that, according to Google’s own analysis, even if I were to accept all of Professor Easton’s criticisms regarding Professor Davila’s approach, the Play Store would still be highly profitable.
3036 Let me further address the detail of this evidence.
3037 Epic has prepared its own aide memoire which incorporates only those adjustments to Professor Davila's approach that have some evidentiary basis. Epic's aide memoire, which shows the combined effect of Epic's adjustments, is set out as an annexure to my reasons.
3038 Epic's adjustments to the allocation of Android costs to the Play Store, the Play Store's operating profit and the Play Store's balance sheet follows Epic's aide memoire.
3039 Let me make the following points concerning the adjustments made by Google and Epic's response to them.
3040 First, in respect of Android cost allocation, Google's aide memoire allocates 23.1% of Android costs to the Play Store which is the median percentage of Play Store revenue that was generated through Android between September 2016 and July 2019.
3041 Epic's aide memoire allocates half of that amount being 11.55% having regard to Google documents which indicate that between 50 to 60% of Android costs are dedicated to Pixel and therefore should not be allocated to the Play Store.
3042 The difference between the two methods is summarised in Epic’s aide memoire in the section described as Epic's adjustment of Android costs allocation.
3043 Second, on the topic of Pixel, it was put to Professor Davila that Pixel brings substantial value to Google Play. He agreed that value goes both ways between Google Play and Pixel but said that he had not estimated the value that Pixel brought to Google Play because it is very small.
3044 Now Google's counsel sought to rely on a Google document dated 25 January 2019 titled Phones 5Y Plan Update to establish that Pixel drives a significant amount of value for Google Play. But that document is Google's projection as at the beginning of 2019 of the future value that Pixel would bring. In particular, the document projected that over the six year period from 2018 to 2023, Pixel would generate a total indirect gross profit of [REDACTED] for Google. Approximately 28.125% of non-incremental gross profit would be generated from Google Play. The balance would be generated from Google Search. Adopting that percentage split for the amount of value Pixel was expected to bring to Google, Pixel was projected to generate a total of approximately [REDACTED] in gross profit for Play over a six year period, leading to an average annual gross profit of approximately [REDACTED]. That is less than [REDACTED] of Google Play's annual gross profit from 2018 onwards. Further, as Epic points out, the projections in the January 2019 document were very optimistic even in the near term.
3045 I agree with Epic that on the evidence, Pixel is an insignificant driver of value to Google Play and therefore to the Play Store and it is not appropriate to allocate any Android cost related to Pixel.
3046 Third, in respect of indirect revenue, Google's aide memoire excludes Professor Davila's allocation of indirect revenue. Epic’s aide memoire also adopts that adjustment on the basis of Professor Davila's evidence that if his interpretation of the Google document from which he derived the indirect revenue figure was incorrect, it would be reasonable to exclude those revenues. But Epic's primary position is that the Google document establishes that the Play Store does generate significant indirect revenue for Google.
3047 Now it should be noted that the inclusion of a portion of Android operating expenses in addition to that already allocated by Professor Davila and the non-inclusion of indirect revenue both reduce Google Play’s and therefore the Play Store’s operating profit, although the difference is relatively slight. These adjustments also result in a number of consequential adjustments to the value of the relevant assets, irrespective of any other changes. This is because Professor Davila allocated a number of assets based on expenses or operating profit.
3048 Fourth, in respect of the revenue-based allocation of certain assets, Google's aide memoire adopts a revenue-based methodology to allocate the value of certain Alphabet assets rather than the expense-based methodology employed by Professor Davila. Epic's aide memoire does not adopt this adjustment. Professor Davila's evidence was that a revenue-based methodology would be inferior. Professor Davila was not challenged on that evidence and there was no evidence to the contrary from Professor Easton.
3049 Fifth, in respect of European Commission fines, Google's aide memoire excludes as free financing for the Play Store a component of the accrued expenses and other current liabilities line item on Alphabet's balance sheet which relates to certain fines imposed on Alphabet by the European Commission. Epic's aide memoire also adopts this adjustment. Professor Davila accepted that certain of the European Commission fines did not relate to Google Play and therefore to the Play Store and that Alphabet had incurred costly debt to finance those liabilities.
3050 Sixth, in respect of non-current income tax, Google's aide memoire excludes the line item non-current income tax on Alphabet's balance sheet as a basis for calculating free financing that is available to Google Play and therefore to the Play Store. Epic's aide memoire also adopts that adjustment. Professor Davila accepted that his allocation of free financing may have been overstated due to a substantial amount of Alphabet's non-current income tax being the result of a one-time transition tax incurred in 2017 that did not relate to the Play Store.
3051 Seventh, in respect of deferred income tax, Google's aide memoire excludes the line item deferred income taxes on Alphabet's balance sheet as a basis for calculating free financing. Google's justification for this adjustment is unclear given that the one-time transition tax referred to above was recorded in a separate line item. Professor Davila was not specifically cross-examined on his allocation of deferred income tax. Epic's aide memoire does not include this adjustment.
3052 Now the results of the three key profitability metrics during the period 2017 to 2022 in Google's aide memoire and Epic's aide memoire are summarised in the table below and show that on either party's formulation Google Play and therefore the Play Store remains highly profitable in an accounting sense.
Summary table of aides-memoire
FY17 | FY18 | FY19 | FY20 | FY21 | FY22 | |
Google aide ROGP | 62.5% | 71.3% | 75.9% | 79.1% | 81.7% | 71.3% |
Epic aide ROGP | 67% | 75.1% | 79.3% | 82.1% | 84.6% | 74.6% |
Google aide ROA | 76.7% | 86% | 81% | 86.1% | 110.4% | 88.4% |
Epic aide ROA | 107.1% | 137.6% | 136.6% | 152.8% | 194.9% | 139.5% |
Google aide ROCE | 174% | 157.5% | 134% | 157.4% | 194.6% | 151.3% |
Epic aide ROCE | 401.8% | 454.8% | 380% | 705.1% | 751.9% | 377.1% |
3053 I have set out the specific aides-memoire in an annexure to my reasons.
Can any conclusions be drawn from the Play Store’s profitability in an accounting sense?
3054 In my view Professor Davila’s evidence confirms that Google Play and therefore the Play Store have been and are highly profitable at the least in an accounting sense. Professor Davila assessed the profitability from FY12 to FY22 according to three metrics being ROS / ROGP, ROA and ROCE.
3055 Professor Davila’s results are summarised in the table below, both including and excluding indirect revenues that Professor Davila allocated.
3056 Professor Davila concluded that by any measure of performance, Google Play and therefore the Play Store is highly profitable.
3057 Now it is to be noted that Professor Easton was not asked to express an opinion on the profitability of Google Play and therefore the Play Store and did not do so, even though he accepted that it would have been possible.
3058 Professor Easton’s evidence was consequently limited to critiquing Professor Davila’s approach.
3059 First, in Professor Easton’s opinion, a flaw with Professor Davila’s approach was that he did not evaluate the profitability of the Play Store as though it were a stand-alone entity. I agree with Google that this is a limitation such that although I can draw some conclusions from Professor Davila’s analysis, I cannot draw strong conclusions concerning economic profitability.
3060 Second, and relatedly, Professor Easton criticised Professor Davila for not sufficiently accounting for internally generated intangible assets, that is, those that do not appear on the balance sheet, that are necessary to operate the Play Store.
3061 Professor Easton’s criticism was predicated on intangible assets being relevant to the operation of the Play Store on a stand-alone basis.
3062 Professor Easton made references to intangible assets that he described as patents and technologies related to Android, the value associated with the Google and Android brands and the intellectual capital that Alphabet has developed. But he did not identify the purportedly relevant intangible assets with any precision, and nor did he ascribe a value to them. He speculated that a substantial portion of Alphabet’s investment in Android and the related intangible assets may specifically benefit the Play Store.
3063 Now I agree with Google that it is necessary to account for or make some adjustment for the use of intangible assets by the Play Store.
3064 Professor Davila said that Google’s intangible assets are accessed by most participants in the Android ecosystem for a nominal fee and therefore are not a part of the Play Store’s asset base. Further, Professor Davila did not allocate any brand-associated costs to the Play Store because he had not seen any evidence of the Google brand being a central aspect of the Play Store’s operations.
3065 But I am not convinced that Professor Davila’s approach is sound.
3066 Third, Professor Easton criticised Professor Davila for failing to allocate all expenses that are necessary to operate the Play Store either on a stand-alone basis or as a division within Alphabet.
3067 Now Professor Davila used Google’s internal financial reports and cost allocation methodology as his starting point because in his view Google’s management was in the best position to know how resources are consumed within its business. Google Play’s management P&Ls include direct costs and costs allocated from other parts of Alphabet.
3068 Google’s corporate finance team uses a range of methodologies to allocate costs based on the nature of the cost in question.
3069 In cross-examination, Professor Easton accepted that Google's management was best placed to judge the use which is made of shared resources, and that he was not in a better position than Google's management to allocate costs between the various divisions of Google.
3070 Now in April 2021, Google reviewed the cost allocations that were being made to Google Play. Other than the possibility of allocating Android costs to Google Play, the review only identified three areas for potential further allocation to the Google Play P&L, being Play Ads marketing, Play Ads technical infrastructure, and a portion of the Play Trust and Security Cost Centre. But the total amount of those allocations was only approximately [REDACTED], which was less than [REDACTED] of Google Play’s revenues. These potential allocations were, relatively, very small or negligible.
3071 Now Mr Cramer gave evidence that there were costs within Google that were not even considered for allocation. He identified platforms infrastructure for payments or ads, which he accepted were at least partially allocated to Google Play. He identified Google’s brand. And he identified Google’s research on artificial intelligence, for which he said Google Play did receive some allocations.
3072 Mr Cramer accepted that corporate finance at Google was responsible for allocations and he only knew some of the allocation methodologies employed, not all of them, and typically only at a very high level. In those circumstances, his evidence regarding theoretical and ill-defined costs that are not captured by Google’s sophisticated financial reporting system is problematic to say the least. Those costs were not identified for allocation to Google Play in any internal document.
3073 Professor Easton also gave evidence that Google’s internal accounts do not capture the full amount of indirect costs necessary to operate the Play Store. But when asked to identify what costs were not captured, Professor Easton only identified advertising costs, before then accepting that Google does allocate marketing costs to the Play Store. Further, Google’s management is in a better position to judge the appropriate proportion of marketing costs to allocate. Professor Easton’s evidence regarding vague unallocated costs does not really assist me. The relevant Google documents in important respects speak for themselves.
3074 Now the remaining criticism of Professor Davila’s approach to expense allocation relates to Android costs, where he allocated a portion of Android costs, being between 6.4 to 8.7% from FY17 to FY22, to the Play Store using Google Services’ total revenue as the allocation criteria. Google does not allocate Android costs to the Play Store.
3075 Professor Easton criticised Professor Davila for not using an alternative basis for attributing revenue generated through Android to the Play Store, which would lead to a greater allocation of those costs.
3076 Now Professor Davila accepted that an alternative methodology, which was based on a 23.1% attribution of revenue generated through Android to the Play Store, was reasonable. But he said that his approach was conservative in that it was based on allocating Android’s full costs, despite a 2021 Google document indicating that 60% of Android’s engineering resources are dedicated to Pixel. A 2022 presentation titled “P&E FY22 Planning: Supplemental Financial Overview Slides” also suggests that around [REDACTED] of total Android costs relate to the hardware and core phone service on Pixel.
3077 I agree with Epic that this suggests that an allocation of approximately 11.55% of Android costs, that is, 23.1% multiplied by 50%, could reasonably be made to the Play Store. That allocation is only marginally higher than Professor Davila’s figure and does not materially impact the profitability of the Play Store.
3078 So, in summary, the evidence establishes that based on the figures for Google Play and other evidence, the Play Store is and has been highly profitable at least in an accounting sense. Now before drawing conclusions from this concerning market power, let me deal with one other matter.
3079 Now if the purpose of the inquiry is to understand the true economic profitability of Google Play from the perspective of understanding whether its profits are supra-competitive, I agree with Google that it is necessary to calculate its profit on a standalone company basis, because Google Play presently forms part of a conglomerate company, Alphabet.
3080 Professor Easton gave two reasons why this is so, which I accept.
3081 The first reason was that if one wants to assess whether the profitability of a business unit is attractive by reference to comparator companies, which are typically standalone companies, it is necessary to perform the comparison on a like for like basis.
3082 The problem with using the internal management accounts of a business unit like Google Play is that, unlike a standalone comparator company, the internal accounts will not include all the costs necessary to operate the business on a standalone basis, either because some of its costs are shared or common costs, or because some costs are simply not allocated at all. Nor will the internal management accounts include all the assets necessary to operate the business, unlike the balance sheet of a comparator company.
3083 Comparing the internal management accounts of the business unit with standalone comparator companies is not like for like.
3084 The second reason is that if one wants to assess whether the profitability of a business unit is attractive in an absolute sense, one needs to evaluate the factors that could be causing its profitability to appear attractive.
3085 In other words, it is important to assess whether the attractiveness of the business unit’s profit is generated by the underlying business itself, or whether it is driven by the fact that it only receives an allocation of the shared and common costs necessary to operate the business, or the fact that it is benefiting from shared internally generated intangible assets that are not reported on its balance sheet.
3086 It is common ground that under GAAP requirements, internally generated intangible assets are not reported on Alphabet’s balance sheet.
3087 Further, Professor Easton also explained why it is not possible to use the balance sheet figures for calculating an economically meaning ROCE.
3088 The reason why these matters are important is that if one does not add in the costs necessary to operate the business unit, that is, Google Play, as a standalone company, one will not have isolated the profitability of that business unit from the cost efficiency benefit it receives by being part of a conglomerate, that is, Alphabet. Likewise, if one does not add the assets necessary to operate the business unit, that is, Google Play, as a standalone company, one will not have isolated the capital employed by that business unit from the capital efficiency benefit it receives from being part of a conglomerate, that is, Alphabet.
3089 The underlying profitability of Google Play needs to be isolated from the benefits of conglomeration to ascertain whether it is attractive or supra-competitive, because otherwise the business unit will appear more profitable than it truly is.
3090 Now Professor Davila initially tried to deny the obvious proposition that a business unit within a conglomerate typically benefits from cost savings, because costs may be shared across business units, whereas if it were to operate as an independent company, it would incur all of those costs. This was notwithstanding the fact that he acknowledged in his reply report that certain costs would have to be taken into consideration if Google Play’s profitability was estimated on the basis of it being an independent company.
3091 But the basis for Professor Davila’s denial in cross-examination was literature cited in his reply report. When taken to the relevant article on which he relied, he conceded that it concerned the banking industry and did not apply to other industries or Google Play, and that it found cost economies of scope with the only dis-economies being related to revenue. He also conceded that he was not suggesting that Google Play suffers revenue dis-economies.
3092 It follows that I do not accept his initial denial. In any event, he ultimately accepted that if a business unit did have significant shared costs, such as R&D expense for artificial intelligence or brand costs, conglomeration brings cost savings.
3093 Further, it typically is not possible to rely on internal management accounts of a business unit as a proxy for its profitability on a standalone company basis.
3094 Internal management accounts are prepared for the purpose of assisting management to do their job better. They may or may not include indirect costs of the business unit. And if they do, it typically is an allocation of the company’s shared and common costs.
3095 There are no set rules, standards or principles to be followed in allocating costs in management accounting, and there is no rule that management accounts must include all costs necessary to operate a division. Allocation choices have to be made, and there is no one right way to allocate costs in management accounting. These observations apply to Google Play’s internal management P&Ls.
3096 Mr Cramer gave evidence that the management P&Ls do not capture the full costs incurred by Google in order to support Google Play. Nor is it the function of management P&Ls to do so. The management P&Ls which appear in the annual plans and monthly financial reviews of Google Play are generated for the limited and specific purpose of assisting the business leadership to budget and to track the performance of Google Play against the annual plan. It is not the purpose of management P&Ls to show the standalone profitability of Google Play.
3097 Google Play is part of the Google Services segment which consists of a series of interconnected businesses, including platforms and ecosystems. Google Play is a product within platforms and ecosystems. Google Play does not operate as a standalone and discrete business. It, along with the other products within the Google Services segment, rely upon and are supported by significant investments made by Alphabet across all product areas within the Google Services segment, the costs of which do not appear on management P&Ls.
3098 So, Google Play is dependent upon the Android ecosystem to exist and yet the costs of Android are not recorded on the Google Play management P&L. Instead, Android maintains its own management P&L. Other costs required to support Google Play which do not appear on management P&Ls include costs associated with supporting payments and ads platforms, value that Google Play derives from the Google brand, and research and development costs, such as research into artificial intelligence, which benefit Google Play and other products.
3099 Mr Cramer and Professor Easton identified key costs that do not appear on Google Play’s management P&L but need to be taken into account in assessing Google Play’s profitability. These include general marketing, brand and research and development (R&D) costs. This list is not exhaustive.
3100 So, Professor Davila failed to properly engage with unallocated costs in analysing the profitability of Google Play.
3101 Further, because the basis of Professor Davila’s profitability analysis was Google Play’s internal management accounts, it cannot provide an estimate or proxy for the underlying profitability of Google Play on a standalone basis. Professor Davila conceded that he did not calculate Google Play’s gross profit, operating profit, assets and capital on a standalone company basis. He therefore did not seek to include in his profitability calculation all the costs and assets necessary to operate Google Play on a standalone basis, and nor were his ROA and ROCE ratios calculated on that basis.
3102 Further, it follows from this that had Professor Davila assessed the profitability of Google Play as an independent company, his gross profit and operating profit calculations for Google Play would have been different, and likely significantly so.
3103 In this regard, Professor Davila accepted that if Google were an independent company of Alphabet it would need to incur costs of accessing Google’s brand or costs of developing an equivalent brand, and those costs would need to be added to the Google Play management P&L in the form of marketing expenses. Further, it would have to incur costs from Google to use its ads platform to continue dealing with ads on Google Play. Further, it would need to account for the full cost of R&D for technology used by Google Play on Google Play’s management P&L. Further, it would need to account for the value of the positioning of Google Play on devices on Google Play’s management P&L.
3104 As to Professor Davila’s opinion that if Google Play were an independent company it would not have to pay any Android costs because Android is open source, I do not accept this.
3105 Google Play is a means by which Google monetises Android. If Google Play were to spin off as a separate and distinct company from Alphabet, the costs of Android would need to be accounted for either in the sale price at which Google Play was sold, in which case Android would be an asset on Google Play’s balance sheet, or it might be the case that the new independent company would need to enter a licensing agreement with Google in respect of Android.
3106 In summary, Professor Davila’s estimate of Google Play’s profitability as a division of Alphabet fails to account for all the common and joint costs that benefit Google Play that are not accounted for on Google’s management P&L. Further, the ROA and ROCE ratios fail to account for all the assets necessary to operate Google Play.
3107 Further, when Mr Cramer was asked about his reporting to Ms Porat in the 20 September 2018 presentation to the CFO council discussed above that Google Play was very large and growing at healthy rates, that it was highly profitable, and that it had consistently improving margins, Mr Cramer said that such statements were true in the context of the management P&L. So, those statements are only true if one takes into account the limitations of the management P&Ls.
3108 Epic also says that an adverse inference should be drawn against Google because Mr Cramer and Professor Easton were not asked to assess the profitability of Google Play. But in my view that point goes nowhere given that the profitability of Google Play forms no part of Google’s case. Indeed, Google’s position is that the profitability of Google Play is irrelevant to the question of market power. The onus is on Epic to prove Google Play’s profitability on which it relies, and its purported relevance to the question of whether Google has substantial market power.
3109 But in any event, Mr Cramer was called to address the appropriate use and function of Google Play’s internal management P&Ls, for which he is responsible for preparing and overseeing.
3110 Whilst his evidence was that investment across all product areas is ultimately determined by the Alphabet board and the allocation of indirect costs is made by corporate finance, the profitability of Google Play on a standalone basis is not something Mr Cramer, the Alphabet board or corporate finance assesses.
3111 Such matters are beyond Mr Cramer’s knowledge and control. He was in no position to assess the profitability of Google Play in the relevant sense.
3112 Further, Google says that Professor Davila’s estimates of Google Play’s ROGP, ROA and ROCE are flawed even if it were appropriate to use Google Play’s management P&Ls. Google made the following points that I tend to agree with.
3113 First, Professor Davila failed to properly account for the intangible assets that are necessary to operate Google Play despite acknowledging that this is necessary for the analysis.
3114 Professor Davila allocated a percentage of the intangible assets on the balance sheet of Alphabet to Google Play based on the ratio of the revenue of Google Play to the revenue of Alphabet despite acknowledging that he had no information on how these assets are distributed across divisions at Alphabet. He undertook no analysis to show whether 3.8 to 8.1% of the intangible assets of Alphabet would be sufficient to support Google Play as an independent company.
3115 Further, Professor Davila should have enquired but failed to enquire as to what intangible assets are necessary to operate Google Play.
3116 In relation to intangible assets not recorded on Alphabet’s balance sheet, like the Google brand, Professor Davila also made no attempt to include these in his estimate of Google Play’s assets and therefore its capital employed.
3117 Professor Davila’s failure to account for off-balance sheet intangible assets necessary to operate Google Play renders his profitability ratios unreliable. It is not possible to calculate a meaningful ROCE or assess the attractiveness of Alphabet or Google Play’s profitability merely by looking at the figures in the reported balance sheet.
3118 Second, Professor Davila inappropriately allocated something he called “indirect revenue” to Google Play based on an erroneous interpretation of one Google document, being an undated presentation titled P&E 2021 Annual Plan: Play Sandbox.
3119 Specifically, Professor Davila assumed that Google Play led to the revenue figures recorded in the five product areas other than Google Play on slide 8478.R. But Professor Davila’s interpretation of the document is problematic.
3120 Slide 8476.R was as follows:
3121 Slide 8478.R was as follows:
3122 The slide is saying that Google Play only led to a very small amount of these revenue figures. This is for the following reasons.
3123 It is plain from slide 8478.R itself, informed by the context of slide 8476.R, that the revenues recorded for the five product areas other than Google Play are total revenues.
3124 So, when slide 8478.R states that “Play is a catalyst for significant additional games spend through other properties/channels”, it is not saying that Google Play led to the total revenue figures on this slide. Rather, what it is saying is that Google Play indirectly contributed to some additional revenue within these amounts.
3125 Further, it is clear that the major share of this so-called catalytic effect was on gaming ads, which are already part of Google Play’s P&L being the ads for games on Google Play, given it has the thickest arrow.
3126 In addition, it is clear that Google Play led to very small proportions of the revenue figures for Ads on Games and YouTube Ads on Gaming Content, particularly given the description “Play signals drove +1% gaming watch time”.
3127 Professor Davila accepted that if he were to assume that Google’s interpretation of slide 8478.R is correct, it would result in different numbers, and that this was the basis for him having conducted a sensitivity analysis which removed the indirect revenue from his calculations. He also conceded that he could have misinterpreted the slide.
3128 So, it was not appropriate for Professor Davila to include indirect revenue in the calculation of Google Play’s profitability.
3129 Third, in relation to Android costs, which were not on the Google Play P&L at all, Professor Davila allocated a fraction of Android costs to Google Play based on the proportion of Google Play’s revenue to the revenue of Google Services revenues. On that basis, he allocated between 1.0% and 8.7% of his estimated Android costs to Google Play. But there were several problems with this allocation methodology.
3130 Professor Davila provided no basis for adopting a revenue-based allocation method when he also described Android costs as discretionary fixed costs that are not directly related to revenues.
3131 He also did not grapple with the fact that Google Play cannot exist without Android OS and that any costs allocation should take into account that fact.
3132 Further, Professor Davila conceded that his revenue allocation method assumed that Android contributed equally to every dollar the Google Services division earns, when factually that is incorrect. Whilst all of Google Play’s revenue is via Android, only a small proportion of Google Search revenue comes from Android. So, Professor Davila’s allocation methodology was unreasonable.
3133 A more appropriate methodology would have been to allocate Android costs to Google Play based on its share of revenue that was actually via Android. Professor Davila also agreed that this would be a reasonable methodology.
3134 In addition, Professor Davila could have performed such an allocation, because he had identified documents in his report which suggest that Google Play’s revenue is 22% to 27% of the revenue generated via Android.
3135 To justify his inadequate allocation of Android costs to Google Play, Professor Davila relied on a single sentence in a 2021 Google document titled 2021 Plan Review: PA: Platforms & Ecosystems to suggest that 60% of Android costs are related to the Pixel smartphone.
3136 But the document does not support Professor Davila’s contention that 60% of Android’s costs are related to Pixel. Even if it did, it is not clear over what period that might have been the case.
3137 Epic also relies on a slide of a 2022 document titled P&E FY22 Planning: Supplemental Financial Overview Slides to suggest that around [REDACTED] of total Android costs relate to the hardware and core phone service on Pixel. The slide does not support Epic’s assertion. Further, it is not clear that items labelled as Core Phone Service, Device Ecosystem including Developer Productivity / Relations, Platform Support and Core OS Support & Inclusion, Brand Marketing A&P and Go-to-market do not benefit Google Play.
3138 There is no basis to Epic’s assertion that Professor Davila’s allocation of Android’s costs is conservative on the basis that a majority of Android costs support Pixel.
Comparative analysis
3139 Now Epic says that Professor Davila’s comparative analysis of the Play Store’s profitability relative to other entities provides further evidence of its very high profitability.
3140 Professor Davila undertook a process to identify 20 external companies and two divisions within Google against which he benchmarked the profitability of the Play Store for the years FY15 to FY22. Professor Davila concluded that the Play Store is above all of the selected businesses in every profitability metric used.
3141 But I agree with Google and Professor Easton that the comparator entities used by Professor Davila are not sufficiently similar to the Play Store.
3142 Further, Professor Davila acknowledged that the firm with the largest number of overlapping characteristics with the Play Store is Apple’s App Store. But Professor Davila did not attempt to compare the Play Store to the App Store, not because he did not have the underlying financial data to do so, which he did as Epic’s accounting expert in the Apple proceeding, but because he was instructed not to. But in any event, Apple’s figures are infected by the exercise of market power.
3143 Professor Davila’s default position was that the Play Store and his comparable companies were sufficiently similar because they were all digital platforms selling digital goods or services. But certain companies also provided other services.
3144 I agree with Google that the purported similarity at such a high level of abstraction offers no assistance. To say that an app store is the same as any other digital business is akin to saying all physical businesses are the same because within the four walls of the store they all sell physical goods and services, and any other differences do not matter.
3145 Professor Davila accepted the following propositions which undermine his assertion that the comparable companies that he has selected are meaningful for the purposes of comparison with the Play Store.
3146 First, the task required was to select companies that were as similar as possible in terms of their characteristics and dimensions including sector or subsector, industry, exposure to the same economic conditions, size, products and services, customers and end markets, distribution channels, geography and risk profile. The Play Store’s core sector is app stores, but it is in a narrow definition of an industry.
3147 Second, Apple’s App Store is the best comparator for the Play Store because it has the largest number of overlapping characteristics with the Play Store as both are app distributors.
3148 Third, despite having identified over 80 Android app stores, including the Samsung Galaxy Store and Amazon Appstore, he did not include any of those app stores as part of his comparator analysis. Further, he analysed the profitability of Microsoft, Sony and Nintendo but did not include their app stores as part of his comparator analysis.
3149 Fourth, the VX segment, which is a division of Alphabet, is a different business from the Play Store because one is trading digital goods that are videos whereas the other is trading digital goods that are apps. Further, the VX segment did not satisfy Professor Davila’s criterion that the comparator companies have revenues greater than USD 2 billion in any financial year between FY15 and FY22. When this was pointed out to Professor Davila, he suggested that the criterion only applies to external companies, not internal divisions.
3150 Fifth, Airbnb, Booking Holdings and Expedia have different customers, are in a different market, in a different industry and provide services different from the Play Store.
3151 Sixth, time could remove idiosyncratic risks but not risks associated with specific industries and economic conditions over time.
3152 Seventh, Roku sells and distributes physical TVs through which users can connect to third-party platforms. Although Professor Davila sought to defend his inclusion of Roku as a comparator, he accepted that it was furthest apart in his group of comparable companies.
3153 Eighth, Spotify and Netflix have different customers and end markets from the Play Store.
3154 Ninth, Coinbase, Intercontinental, Cboe and CME provide more services and products than simply that of a digital platform. They provide clearing, banking and market data services, are in a different industry to the Play Store and must respond to different regulatory requirements.
3155 So, Professor Davila’s comparative analysis is unreliable because the comparable companies that he has selected are inappropriate for benchmarking the Play Store’s profitability.
3156 I agree with Google that the comparable companies are not sufficiently similar to the Play Store such that any comparative analysis of the Play Store’s profitability in relation to them is not that useful.
Summary
3157 I am prepared to accept that Google Play and accordingly the Play Store are highly profitable in an accounting sense, notwithstanding that there are significant deficiencies in Professor Davila’s analysis concerning the omission of some assets and the failure to deal with the stand-alone basis.
3158 But I accept the force of Google’s points to the effect that no cogent analysis has been done concerning economic profitability.
3159 Nevertheless and despite these deficiencies, the high accounting profitability of Google Play and the Play Store is consistent with Google having and exercising substantial market power.
Conclusion
3160 In summary, Google has a substantial degree of power in the Android mobile app distribution market.
3161 Moreover, let it be assumed that Apple’s App Store should be included within the relevant market, and so the market is one which encompassed the distribution of both iOS and Android apps. In that market, Google still holds substantial market power. Section 46(7) of the CCA makes clear that two suppliers may each have substantial market power. Further, the market would still be highly concentrated, with only two mobile app stores accounting for almost all app downloads.
3162 For all these reasons, I am satisfied that Google has substantial market power with respect to the services which the Play Store provides.
Market definition — the mobile OS licensing market
3163 Google supplies by way of licence a mobile OS to OEMs. The only close substitutes were other licensable mobile OSs. During the relevant period, these were open source Android, Windows 10 Mobile, Sailfish and Tizen.
3164 A mobile OS is essential to the functionality of a smart mobile device. Every OEM that does not have its own, as Apple does, must license a mobile OS from a third party.
3165 I agree with Epic that there are no real alternatives to OEMs acquiring a licensable mobile OS, let alone close substitutes. And clearly, non-licensable mobile OSs such as iOS or Fire OS do not act as a competitive constraint on the supply of licensable mobile OSs. Essentially, this is because non-licensable mobile OSs are not available to OEMs.
3166 Further, as Epic says, there is no evidence that the developers of non-licensable mobile OSs have licensed or will ever license their OSs to third-party OEMs. And the prospect that Apple will alter its longstanding approach and begin licensing iOS to third party OEMs at short notice is unreal. Further, Amazon’s and Huawei’s lack of success in selling Fire OS and Harmony OS devices outside China makes it unlikely that either could successfully license their mobile OS at short notice, even if they wanted to.
3167 Accordingly, there is no sufficient reason to conclude that developers of non-licensable mobile OSs would commence licensing those mobile OSs in response to a small but significant change in the price or quality of licensable mobile OSs. Non-licensable mobile OSs are not within the same market as licensable mobile OSs.
3168 Moreover, I agree with Epic that non-licensable mobile OSs also do not pose an indirect competitive constraint through the ability of users to switch smart mobile devices, given that users are very unlikely to switch to a smart mobile device that uses iOS or another non-licensable OS in response to a small but significant change in the price or quality of licensable mobile OSs. There are various reasons for this.
3169 First, such switching requires users to acquire a new device which is expensive and normally happens infrequently.
3170 Second, switching to a device with a different OS involves additional financial and non-financial costs, such as needing to replace accessories only compatible with particular devices, repurchasing or replacing apps acquired on the previous OS, and spending time learning how to use a device on the new OS.
3171 Third, iOS mobile devices are typically more expensive than Android mobile devices and in the lower price bands there are no iOS devices to switch to.
3172 Fourth, customer loyalty to a particular operating system is usually high and users have a low propensity to switch mobile OSs.
3173 Further, operating systems designed for other device types, such as PCs and gaming consoles, also do not provide any competitive constraint on the supply of licensable mobile OSs. OEMs are unable to switch from a mobile OS to operating systems not designed for smart mobile devices.
3174 Further, smart mobile device users will not switch to a different device type in response to a small change in the price or quality of licensable mobile OSs because smart mobile devices address needs that are different from those addressed by PCs and gaming consoles, and they offer advantages to consumers that PCs and gaming consoles do not.
3175 Further, there is no real prospect of developers of OSs for non-mobile devices supplying mobile OSs at short notice.
3176 Further, porting an OS from one type of hardware to another is difficult, can affect performance and functionality, and involves significant time and cost.
3177 For these reasons, I agree with Epic that the market in which Google supplies the Android OS and GMS is the market for licensable mobile OSs, which I have referred to as the mobile OS licensing market. Moreover, this is the market in which Google engages in the OEM restrictive conduct.
3178 Further, the geographic dimension of the market is at least as wide as Australia, and may be global, excluding China.
3179 Now before proceeding further I should deal with one matter of terminology that has created difficulty in the case.
3180 Epic has used the composite description of GMS Android, but to my way of thinking one has GMS on the one hand and the Android OS on the other hand, with of course the former being built upon or using the latter as a foundation.
3181 Moreover, in terms of the expression Android OS one needs to be careful. There is of course an open source version of the Android OS. But I am here dealing with a form of the Android OS that GMS uses and with which it is compatible and which GMS devices use and run on. Now if the versions of Android OS are one and the same, then all well and good. But if they are slightly different then I am referring in the following discussion to the Android OS version that GMS devices run on including the various applications of GMS.
Google’s arguments
3182 Now Google contends that the pleaded mobile OS licensing market is not a relevant or appropriate market in which to assess whether Google relevantly has substantial market power.
3183 First, Google says that the mobile OS licensing market does not include any transactions from which Google earns anything more than a de minimis amount of revenue with respect to the supply of its Android OS. This is because the supply of Android OS itself generates negligible revenue because Google licenses it free of charge.
3184 Instead, Google earns revenue from and recovers its investment in Android OS from transactions with respect to services that it offers on Android mobile devices such as Google Search advertising fees and the Play Store service fees.
3185 So, Google says that the mobile OS licensing market cannot provide any useful lens or focusing process for analysing whether Google has market power with respect to Android OS, because the transactions which affect Google’s competitive incentives with respect to Android are not captured.
3186 Google says that the relevant market in which Google supplies Android OS therefore needs to be broadened so that it captures Google’s relevant competitive incentives and the rivalry with respect to those transactions.
3187 Second, Google says that Epic’s attempt to limit the focus of the analysis to a focal product of a licence to distribute a product it calls GMS Android is misconceived because there is no such product, and puts form over economic substance. I should say now that I agree with Google on that question. For the present discussion I have distinguished between the Android OS and GMS.
3188 Third, Google says that the pleaded mobile OS licensing market is too narrow because it fails to include the strong and close indirect competitive constraint imposed by iOS mobile devices on the supply of Android OS via a direct constraint on Android mobile devices, instead including weaker constraints such as Sailfish and Tizen despite adducing no evidence that customers switch to them or that they are a greater constraint than iOS.
3189 Now I would note here that I accept that there is no dispute between Professor Asker and Ms Edwards-Warren that such indirect constraints from vertically integrated mobile OS / mobile device suppliers need to be considered in the market definition exercise, and I have considered such matters.
3190 Further, it is not contentious that if Google loses users to iOS, it will earn less revenue from Android OS via services like the Play Store and Google Search, and that this amounts to indirect competition from Apple.
3191 Further, Google says that the approach of including indirect constraints from a downstream vertically integrated supplier is justified. It says that there is no reason in principle why a market for competition law purposes cannot include multiple functional levels, and it may be appropriate to do so when downstream activities constrain upstream behaviour.
3192 Now I agree that the issue is whether the constraint posed by iOS devices with respect to Android devices is a sufficiently close constraint on the supply of Android OS to OEMs at the upstream functional level. Google says that it plainly is, but I disagree.
3193 Fourth, Google says that Apple as a vertically integrated supplier of a mobile OS and mobile devices could provide a close indirect competitive constraint on Android OS. But Google says that Epic has failed to provide any conclusive evidence that iOS is not a close competitive constraint on Android OS.
3194 Fifth, Google says that Epic has failed to capture relevant incentives and rivalry affecting the asserted licensing market.
3195 Google licenses Android OS to OEMs for free or with no monetary price, and instead generates revenues when GMS apps such as Google Search and the Play Store are preinstalled by OEMs and users actively engage with them.
3196 Google says that a narrow focus on Android OS therefore does not capture Google’s incentives, because it would exclude any focus on transactions from which Google earns revenue from Android devices.
3197 So, Google says that the pleaded market ignores and excludes the transactions which ultimately generate revenue for Google based on Android OS, and so it is not possible to assess whether Google has market power with respect to Android if the source of its incentives is not included.
3198 Now Epic points to Ms Edwards-Warren’s evidence that the restrictions on OEMs in the MADAs and AFA/ACCs are a form of consideration for the operating system. But Google says that as Professor Asker explained, given that there is no price, it is unclear how price would change or indeed how the terms of the underlying OEM agreements would change with a change in competition.
3199 Google says that the terms of the OEM agreements themselves are simply not a flow of money that an economist would call a price, or that an economist could use to perform the HMT, whether as a qualitative or quantitative exercise.
3200 Further and in any event, Google says that to say that the OEM agreement restrictions benefit Google and are a form of consideration does not grapple with Google ultimately earning revenue and profits from users actively engaging with Google services on devices running the Android OS.
3201 Further, Google says that even if the OEM agreements are beneficial to it, they are still not the transactions from which Google generates revenue and profit from its investment in Android OS. Google only earns revenues if Android devices reach the hands of users and users engage with GMS apps.
3202 Google says that unless the relevant revenue generating transactions are included somewhere, the mobile OS licensing market cannot illuminate how the relevant conduct affects competitive incentives and rivalry with respect to licensed mobile OSs.
3203 Now as Google points out, Epic says that the appropriate focal product is GMS Android, being a so called combination of the Android OS and GMS software, for which Epic says Google supplies OEMs with a licence, in contrast to the OS enabled smartphone proposed by Professor Asker. Epic sought to justify this by two points.
3204 First, the contractual terms of the OEM agreements show that this is the substance of what Google supplies to OEMs.
3205 Second, Professor Asker’s OS enabled smartphones market sidesteps the conduct occurring between Google and the OEMs. But Google says that this position has several problems.
3206 First, Google says that there is no such thing as GMS Android. It is not a product which Google supplies. Google supplies Android OS to OEMs for free under an open source licence via the AOSP. Google also supplies a licence under the MADA to use the GMS apps and the Android trademark on devices that run on Android OS and comply with an ACC. Google says that these are separate services, and OEMs have a choice whether to use Android OS on its own, or whether to also acquire a licence to use GMS apps. I accept this analysis, but with the rider that some aspects of GMS are relevant to the operating system.
3207 Second, Google says that whilst it is true that Google supplies an open source licence to Android OS and that, under the MADAs, Google supplies a licence to distribute GMS on Android compatible devices and display the “Android” and “Google” trademarks, this is not a simple upstream / downstream situation.
3208 Google says that it charges no fee and earns no margin in the supposed upstream market. Indeed, the OEMs pay nothing to Google even when they sell mobile devices in the supposed downstream market.
3209 Google says that what that demonstrates is that the monetary returns Google earns from Android OS and from licensing the use of GMS and the “Android” and “Google” trademarks are derived elsewhere and from sources other than the OEMs.
3210 And consistently with this, Google says that its interaction in a vertical sense does not cease when it supplies the OEM with a licence to Android OS, because consumers can interact with GMS apps on their Android device. Those are the interactions through which Google earns revenues.
3211 So, Google says that it is apparent that Google’s and the OEMs’ dealings in the alleged upstream market are actually in the nature of a cooperative dealing between OEMs and Google, directed at producing Android enabled devices that consumers demand, and from the supply of which they mutually benefit.
3212 Google says that the AFAs, ACCs and MADAs significantly affect the look, feel and operation of the Android device that OEMs make and supply.
3213 And it says that in an economic sense, this reflects a cooperative supply of a product which combines hardware, a mobile OS and software applications. Neither Google nor the OEMs earn revenues unless the resulting bundle is attractive to consumers, and both ultimately only monetise their investments in that bundle if it is sufficiently attractive to consumers.
3214 So, Google says that Professor Asker’s view of the product as an OS enabled smartphone, which combines the hardware and software that comprise the product collectively supplied by Google and the OEMs, reflects the economic nature of what is going on and the product that is being supplied.
The position of the OEMs
3215 Now Google says that Epic has adduced little evidence to understand the true position of OEMs or their commercial incentives to participate in the Android ecosystem. It has adduced no evidence from any OEM to suggest that they consider the OEM restrictive terms to be restrictive or contrary to their interests. Nor has it adduced evidence as to how OEMs might operate if the OEM restrictive terms were removed. And it has adduced no evidence that would permit an understanding of the financial position of OEMs, the nature and extent of their commercial incentives to participate in the Android ecosystem or how those incentives may be affected by the relief which Epic seeks. Google says that these omissions have consequences for the analysis of the case at hand.
3216 First, they impact the market definition inquiry and the evaluation of Epic’s proposed mobile OS licensing market. Google says that one cannot select what emerges as the clearest picture of the relevant competitive process without first obtaining a detailed understanding and proper characterisation of the commerce in question.
3217 Second, they impact the question of market power. Google says that one cannot understand whether Google has market power in the putative mobile OS licensing market without understanding the countervailing power of OEMs.
3218 But on these points, it is convenient to dispose of them now by making several points.
3219 First, there was documentary and witness evidence dealing with the OEMs’ position and incentives as to how they dealt with the parties to this litigation on relevant questions. The evidence may not have been directly from an OEM but it was evidence from counterparties to any dealings.
3220 Second, the economic expert evidence before me clearly could speak to these topics albeit in a secondary fashion.
3221 Third, both Epic and Google chose not to call or subpoena the direct evidence of an OEM witness, no doubt for good reason.
3222 Generally, I must deal with the evidence before me, which was more than adequate to address the general positions and incentives of OEMs relevant to the competition questions.
Analysis
3223 Now I agree with Epic that there is, and throughout the relevant period there has been, a market in Australia for the supply of licensable mobile operating systems. That is the market in which Google supplies the Android OS and some aspects of GMS relevant to the operating system to OEMs and engages in the OEM restrictive conduct.
3224 Now the first step of the market definition process is to identify the focal product which is supplied by Google. It is from that starting point that one can consider the relevant substitution between products which marks out the field of rivalry that comprises the relevant market.
3225 When defining a market for the purpose of analysing the effect of particular conduct, the candidate market should reflect the relevant product, the customers who acquire the product, and the conduct being analysed.
3226 For present purposes, the relevant product is the Android OS and some aspects of GMS relevant to the operating system, the customers who acquire that product by way of licence are mobile device OEMs, and the conduct being analysed is Google’s conduct in imposing and enforcing certain contractual terms in connexion with the licensing of the Android OS and GMS to OEMs.
3227 The pertinent contractual terms encompassed by the OEM restrictive conduct have been discussed elsewhere.
3228 In summary, when an OEM enters into a MADA and accompanying AFA or ACC, Google grants that OEM a licence to distribute devices with Android OS and GMS and to use the Android trademark.
3229 In exchange for that licence, OEMs make various contractual commitments to Google. Those commitments include a promise to pre-install various Google apps and a promise to place the Play Store on the device’s default home screen. They also include a promise to comply with the technical restrictions. Each of those matters are of commercial benefit to Google.
3230 Most OEMs have also entered into RSAs. Pursuant to the standard form of RSA, Google promises to pay the OEM a share of specified Google revenues, being essentially Google Search revenues, in exchange for the OEM configuring its devices in particular ways, but only if the OEM remains compliant with its MADA.
3231 Further, under the RSA3s, Google promises to pay OEMs a share of Play Store revenues and/or Google Search revenue in respect of devices configured as Premier tier devices. In return, OEMs promise to refrain from preinstalling on Premier Tier devices any other app store or any app that was not already being distributed through the Play Store.
3232 The substance of what is supplied by Google to OEMs is the licence to distribute devices with Android OS and GMS pre-installed and to use the Android trademark for that purpose. This is the correct starting point.
3233 Professor Asker’s starting point is different. His position is that the appropriate starting product is OS enabled smartphones. His reason for identifying that as a starting point has changed over time.
3234 In his report, Professor Asker identified the relevant product as OS enabled smartphones. His report did not address the fact that this was a focal product which is not supplied by Google, other than in respect of the Google Pixel smartphone, which only accounted for 1.7% of smartphone shipments in Australia in 2021.
3235 Professor Asker identified his first justification for this starting point being that the various agreements such as MADAs, AFAs/ACCs and RSAs each influence competition for the products OEMs supply, that is, smartphones.
3236 But any upstream input to a product might influence competition in respect of a downstream product.
3237 As Epic points out, an anticompetitive agreement between suppliers of engines may affect Toyota’s ability to compete with other car manufacturers for the retail sale of cars. But that does not have the consequence that the relevant market in which to analyse alleged anti-competitive effects of the engine supplier’s agreements with car manufacturers is the retail car market.
3238 Moreover, the question of how one product influences competition in respect of another product arises at a later stage of the application of the HMT test, namely, at the point of assessing substitutes. It does not arise in identifying the focal product which is the starting point for that analysis.
3239 Further, I agree with Epic that Professor Asker’s approach to the selection of the focal product in his report side-steps the conduct which is occurring as between Google and OEMs in a series of contractual arrangements relating to the licensing of the Android OS, GMS and the Android trademark. Rather, Professor Asker focuses on a different product sold by OEMs to end-users, who are not parties to the contracts at issue.
3240 Now Professor Asker provided two further justifications for his selection of the focal product.
3241 First, he put forward the justification that Google effectively pays OEMs to use Android via RSAs and that to treat the Android OS, GMS and the smartphone as separate products would embrace the awkwardness of characterising OEMs as purchasing Android from Google at a negative price.
3242 Second, he put forward the justification that Google and OEMs “jointly” supply Android smartphones because all Android smartphones operate the Android OS supplied by Google.
3243 But I would reject these justifications for the reasons given by Epic.
3244 As to Professor Asker’s negative price justification, there are two problematic aspects.
3245 First, GMS is licensed under the MADA, not the RSA, and OEMs can enter into a MADA without entering into an RSA.
3246 Second, if one considers the substance of the economic exchange between Google and OEMs, OEMs receive the benefit of a licence to distribute devices with GMS and the Android OS and to use the Android trademark, and Google receives contractual promises from those OEMs which are of commercial benefit to Google.
3247 So, from an economic point of view, Google provides the licensable OS in exchange for various contractual promises which are of value to Google. And the contractual promises are the economic price OEMs pay for the licence to distribute devices with GMS and the Android OS and to use the Android trademark.
3248 Now in Professor Asker’s evidence, he accepted that OEMs assumed a range of obligations towards Google under the MADA that have real economic value.
3249 Professor Asker’s ultimate point on his negative price justification can be reduced to the proposition that not having a dollar price makes it more difficult to apply the hypothetical monopolist test. But that is not a reason to ignore the commercial reality of the market. A quest for a monetary price to use in a test, which is merely an aid to focus the enquiry, cannot be allowed to dictate the focal product.
3250 So, Professor Asker’s negative price justification for his focal product can be put to one side.
3251 As to Professor Asker’s joint supplier justification, Google is not a joint supplier of Android smartphones with OEMs. Google supplies the operating system to the OEM who produces a smartphone which it sells to consumers. As Epic points out, Google is no more a joint supplier of the smartphone than any other input supplier, such as the supplier of the semiconductors that are essential to the smartphone’s operation.
3252 Further, as to Professor Asker’s joint supplier justification, Professor Asker in his evidence sought to justify the idea that Google and OEMs were joint suppliers of smartphones on the basis that Google has an ongoing relationship with the consumer arising from its apps appearing on the smartphone, which are subsequently monetised by Google. For those reasons Professor Asker asserted that Google has an enduring interest in consumers purchasing and using their smartphones.
3253 Now that explanation did not appear in the joint expert report and appears to have been an attempt by Professor Asker to resuscitate the idea that Google jointly supplies smartphones, in tacit recognition of the difficulties associated with his having identified a focal product that is not offered by Google in any meaningful sense.
3254 But in any event the explanation should also be rejected. It conflates two different products offered to different customers on different terms by different suppliers. The OS is offered by Google to its customers, OEMs. The smartphone is offered by OEMs to their customers, end users.
3255 It is artificial to suggest that purchasers of smartphones “receive” an OS from Google. Those customers purchase a smartphone supplied by the OEM. Google may supply other services to the consumer once that purchase has occurred, such as the distribution services which are supplied via the Play Store. That does not make Google jointly responsible for the supply of the smartphone to the user.
3256 Now ultimately, Professor Asker agreed that for the purpose of identifying a focal product, I could proceed on the basis that there may ultimately be two separate markets, one for operating systems and one for OS enabled smartphones.
3257 Professor Asker’s analysis was focused on supporting an ultimate conclusion as to the relevant market, rather than starting with the product that Google actually supplies, the customers to whom it supplies that product, and the alleged contravening conduct.
3258 Further, Professor Asker was unable to identify a cogent reason as to why GMS and the Android OS should not be seen as an upstream input being the OS to a downstream product being the Android smartphone or, as I have referred to, the GMS device.
3259 In my view Ms Edwards-Warren’s analysis as to the relevant focal product is to be preferred to that of Professor Asker.
3260 Now once the focal product is correctly identified as the licence to distribute the Android OS, the next step is to consider whether there are any close substitutes which should be included in the same market.
3261 A mobile OS is essential to the functionality of a smart mobile device. Every OEM that does not have its own mobile OS such as Apple must license a mobile OS from a third party. Accordingly, other licensable mobile OSs are potential substitutes.
3262 During the relevant period, these potential substitutes were the open source version of the Android OS, Windows 10 Mobile, Sailfish and Tizen, which were within the market.
3263 Now operating systems designed for other device types, such as PCs and gaming consoles do not provide any competitive constraint on the supply of licensable mobile OSs because OEMs are unable to switch from a mobile OS to operating systems not designed for smart mobile devices. Such operating systems are not within the relevant market.
3264 That leaves a final possible substitute, being an OS that is not currently licensable such as iOS or Fire OS.
3265 As to that, developers of non-licensable mobile OSs will not license their OSs to third party OEMs. So, Apple will not alter its longstanding approach and begin licensing iOS to third party OEMs. Such a possibility would not constrain a supplier of licensable mobile OSs directly.
3266 The remaining question is whether the competition between Apple and OEMs in respect of the distribution of smartphones provides an indirect competitive constraint on licensable mobile OSs, and in particular GMS and the Android OS, through the ability of users to switch smartphones.
3267 The theory is that in response to a small but significant change in the price or quality of licensable mobile OSs, users may switch to iOS smartphones and that this possibility would constrain a supplier of licensable mobile OSs, such that both types of OS should be considered to be within the same market.
3268 Now Ms Edwards-Warren concluded that such switching by users is a theoretical rather than a real possibility, a conclusion with which I agree. Users are very unlikely to switch to an iOS smartphone in response to a small but significant change in the price or quality of licensable mobile OSs.
3269 First, such switching requires users to acquire a new device which is expensive and normally happens infrequently.
3270 Second, switching to a device with a different OS involves additional financial and non-financial costs, such as the need to replace accessories, repurchase or replace apps acquired on the previous OS, and spending time learning how to use a device on the new OS.
3271 Third, iOS devices are typically more expensive than Android mobile devices, such that many users of lower priced Android phones are unlikely to have a similarly affordable iOS alternative.
3272 Fourth, customer loyalty to a particular operating system is usually high and users have a low propensity to switch mobile OSs.
3273 Now Professor Asker initially contended that the competition for sales of smartphones constrains Google in its supply of GMS and the Android OS. But I would reject that position for the following reasons.
3274 Professor Asker’s theory rests on the proposition that competition between iOS and Android smartphones provides a constraint on Google in the mobile OS licensing market. But that rests on the following reasoning.
3275 First, if Google increased the price or decreased the quality of GMS and the Android OS by a small but significant amount, this would cause OEM providers to increase the price or decrease the quality of the Android smartphones they produce.
3276 Second, the resulting increase in price or decrease in quality of Android smartphones would cause users to substitute from Android smartphones to iOS smartphones.
3277 But there are two reasons that these steps are unlikely to hold, as Epic correctly pointed out.
3278 First, the cost of the operating system is only one part of the cost to the OEM of producing smartphones. There are other costs involved including the costs of components such as the processor, memory and camera.
3279 Epic gave the following example. Assume the value of the OS is $10, the other components cost $80, and the OEM sells the smartphone to consumers at $100. A 10% SSNIP applied to the OS is $1. But even if the OEM passes that increase through in full, the price of the phone increases by only 1%.
3280 Professor Asker’s analysis fails to analyse, or even consider, what proportion of the costs of a smartphone are represented by the OS. It is implausible that an Android device user would switch to an iOS device in response to what is a very small proportion of the price of the device, even assuming the increase is passed on to consumers in full.
3281 Second, Professor Asker’s logic assumes that the OEM will pass through any increased cost or decreased quality from the operating system. But Professor Asker made no attempt to calculate any pass through rate.
3282 Any pass through is likely to be incomplete, particularly because smartphones are differentiated products. For example, OEMs may well seek to offset a decrease in quality in the OS by reducing the price of their smartphone. That would mean there is no pass through at all. Again, Professor Asker’s analysis does not attempt to grapple with that step.
3283 I reject Professor Asker’s speculative contention that consumers might switch to iOS devices in a meaningful way in response to a small but significant increase in the cost or decrease in quality of GMS and the Android OS.
3284 Further, the geographic dimension of Epic’s posited market is at least as wide as Australia, and may be global but excluding China. The geographic element of Google’s posited market is global. But nothing turns on the difference, and so I will not linger on that question.
Is the decision in Metcash of any assistance to market definition in the present context?
3285 Let me deal with another aspect concerning the decision of the Full Court in Australian Competition and Consumer Commission v Metcash Trading Ltd (2011) 198 FCR 397 and Yates J’s analysis concerning market definition from which Mr Moore SC sought to draw considerable support in advancing his case that there was no mobile OS licensing market.
3286 Now in Metcash it was held to be appropriate in terms of market definition to collapse the relevant wholesale and retail levels of the relevant products because of, inter-alia, the vertically integrated operations and further that the price to independent retailers was constrained more by the retail end than the wholesale end.
3287 Part of the relevant and entertaining exchange between myself and Mr Moore SC was as follows:
MR MOORE: Epic makes, we say, the same mistake made by the ACCC in the Metcash case. In that case, Metcash was engaged in the wholesale supply of groceries to independent supermarkets. It was buying the Franklins business – one of the largest alternative wholesale suppliers to independent supermarkets – and if you focused on the product that Metcash was supplying, you would say that was a wholesale service and, indeed, it was going to become a virtual monopoly in the supply of that service, and that’s how the ACCC put it. However, the court, at first instance and on appeal, held that the relevant market for analysis was the retail market, which included Coles and Woolworths. That was a market that Metcash did not even participate in directly. It supplied no services in that market. Nevertheless, it was held that the activity of Coles and Woolworths was a constraint on the ability of Metcash to set prices in its wholesale business and, therefore, was the relevant market for analysis.
Now, in the present case, Google’s activity in licensing Android to OEMs is, we say, centrally directed to and constrained by competition in the sale of devices and at the ecosystem level more generally. The evidence makes plain that the whole of the economic activity is directed to that end point, including because it is, of course, the means by which Google makes money. And further, Google participates directly in that end market. Just to take an example of that, it pays Samsung an amount for each person who switches from iOS to Android and if it was simply participating in a licensing market, it would say, “There you go. We’ve licensed you the software. It’s up to you what you want to do with it. We don’t care what happens thereafter. Our participation is at the licensing level, and that’s the end of it.” But that’s not the way that this market works. Google’s licensing is directly relevant to its interest in the downstream market, and the success of that downstream market is how Google monetises its investment in Android.
HIS HONOUR: Now, we’re going to have to break that down a bit. I know that you’re proposing to do so.
MR MOORE: Yes.
HIS HONOUR: When you’re dealing with functional levels – and you’re right, Metcash makes very clear that you can collapse the functional levels, particularly if you’re, say, at the wholesale level, and you want to collapse wholesale and retail levels, because there’s such activity in the retail level which closely constrains the activity of the wholesale level.
MR MOORE: Yes.
HIS HONOUR: But superimposed on that is an analysis of vertically integrated operators, isn’t it?
MR MOORE: Yes.
HIS HONOUR: If you’ve got vertically integrated operators, who operate at both the wholesale and the retail level, that can support the collapsing of the functional levels for obvious reasons.
MR MOORE: Yes.
HIS HONOUR: And you ask yourself here, well, is Google vertically integrated, and in relation to what? You might say it’s vertically integrated in relation to the operating system and its apps and the Play Store and that sort of thing. So do you follow what I mean. So it’s a very – it’s a tricky thing to do. I mean, I can accept exactly what you say about there are obviously competitive constraints, ultimately coming from the sale of devices – Android devices – and the competition with Apple. I can accept that. But that’s getting a bit more remote than the sort of justification used in Metcash for the collapsing of the two functional levels. Now, that’s – as I say, there’s a lot to unravel, isn’t there, to see what analogy Metcash might be on the facts with the case that we have here, accepting that you’re right and Metcash – it does justify you collapsing functional levels, and it’s misconceived to talk about substitutability because the concept of substitutability applies to the product dimension of the market or the geographic dimension.
MR MOORE: Correct.
HIS HONOUR: But it makes a nonsense to talk about substitutability when you’re talking about the functional question.
MR MOORE: Correct. And that – so that’s the first reason why I mention it, just to say just answering the question what does Google supply doesn’t answer the ultimate question.
HIS HONOUR: That’s true.
MR MOORE: But secondly, we do say that Apple is vertically integrated. Apple does not separately license its software to manufacturers to manufacture devices in the market. It does the manufacturing itself. It has contractors who do it, but it’s vertically integrated. So we are competing with a vertically integrated competitor.
HIS HONOUR: But you are vertically integrated in a different way on one view, or don’t you accept that characterisation?
MR MOORE: Well, we have an aspect of vertical integration because we sell our own devices.
HIS HONOUR: Well, that’s true. But that’s pretty minor.
MR MOORE: And there’s a little bit of that. That’s pretty minor. Exactly.
HIS HONOUR: I wasn’t thinking of that sort of integration. But you operate at different levels, don’t you, in relation to the Android market, for want of a better expression, dealing with the licensing of the operating system, a premium version of that, for want of a better expression, plus you’ve got the Play Store.
MR MOORE: Correct. But that, in one sense, is the point. What we don’t just do is license software to OEMs and wash our hands of it.
HIS HONOUR: True.
MR MOORE: We are competing with a vertically integrated supplier. Our interest, therefore, is well, what happens to our Android operating system in the device market or in the retail market? How successful is it? Including because – and this is significant – and unlike Metcash, so this case in one sense has factors that bring it even closer to a need to look at the integration, which is that we don’t earn our money just from licensing our software. That’s not how we monetise. We earn our money from activity in that downstream market. We directly invest in that downstream market. We provide incentives to the OEMs and the like to succeed. And then we, of course, earn money from Play Store revenue and search revenue in that downstream market, and so it’s that downstream market that all of our economic endeavour is directed towards, and that’s where we’re constrained by iOS. That’s the direct competition.
HIS HONOUR: So on the facts for Metcash, you were looking at wholesale pricing.
MR MOORE: Yes.
HIS HONOUR: And whether that was constrained by activity in the retail level.
MR MOORE: Yes.
HIS HONOUR: But here we’re not talking about you in terms of pricing of the licensing of the operating system.
MR MOORE: Yes.
HIS HONOUR: So that’s a – and, of course, the HMT analysis discussed in Metcash was looking at that question from the perspective of the wholesale prices that Metcash could charge and what increase could it get away with, and it couldn’t get away with very much, and it wasn’t because of Franklins; there was closer constraints because of the integrated operators – you know, the large supermarket chains at the wholesale and retail level. So they’re quite a different situation. But you would say it’s a different situation, and it’s even a stronger case for you.
MR MOORE: Correct. It’s a different situation in our favour.
HIS HONOUR: Yes, I understand that.
MR MOORE: What was going ---
HIS HONOUR: Well, that’s your argument.
3288 But in my view Metcash does not greatly assist Google in seeking to establish that there is no separate mobile OS licensing market, and in particular by seeking to collapse functional levels.
3289 First, I am not faced with competing vertically integrated players in the Android system. Relevantly, Google is the only relevant vertically integrated operator in this context. Contrastingly, in Metcash there were multiple integrated operators at the wholesale and retail level and it made sense to collapse the functional levels. As was said at [301], and in later endorsing the primary judge’s analysis:
The primary judge further found (at [339]-[341]) that the grocery industry was characterised by a high degree of vertical integration in the distribution supply chain. The major supermarket chains placed a very significant constraint on the capacity of independent retailers to increase price or decrease other services without the likely loss of business. That constraint also constrained the capacity of a wholesaler (specifically, Metcash) to increase its prices to independent retailers.
3290 Second, there is no relevant lateral competitor in terms of the supply of the Android OS.
3291 Third, I am not here talking about any constraint on the pricing of the mobile operating system.
3292 Fourth, even if one considered the nature and extent of any competitive constraint arising from the downstream smartphone market, the evidence established, as Mr Young KC correctly contended, that any competition downstream between Apple, other OEMs and Google to a very small extent for the sale of smartphones did not operate as a close constraint upon Google upstream in its supply of OS licences. So the scenario before me was quite different to that considered in Metcash.
3293 Fifth, no one doubts what was said in Metcash at [266] that:
These authorities show that, as a matter of principle, there is no reason why, for competition law purposes, a market cannot be defined by reference to multiple functional levels. They illustrate that it might be appropriate to do so where downstream activities function to constrain upstream behaviour. Whether that is so depends on the facts presented for consideration and the evaluation of those facts by the relevant decision-maker.
3294 And related to this point, I had the following discussion with Mr Rich SC, in a permissible tag-team approach with Mr Young KC:
MR RICH: And we simply say that, on the facts presented for consideration by your Honour, this is not a case in which it would be appropriate to define a market by reference to multiple functional levels. And as Mr Young adverted to earlier, the different – the facts in Metcash were very different in terms of – and your Honour recalls that the findings about any increase in the wholesale price being immediately felt in the downstream market in Metcash, the impact was such that even very small increases in the wholesale price of the packaged groceries would cause significant difficulties for retailers, could cause them to cease to be viable due to competition with the major supermarkets. ...
HIS HONOUR: Well, the way that the retail prices operated, and given that you had integrated operators, that was a much closer constraint ---
MR RICH: Indeed.
HIS HONOUR: --- at the wholesale level than just somebody laterally competing with Metcash ---
MR RICH: Indeed.
HIS HONOUR: --- which was Franklins.
MR RICH: And your Honour will also remember that the grocery industry was a highly competitive one characterised by high volumes and low margins, and it was a market that was extremely sensitive to switching, in large part due to the lack of barriers to switching and the speed with which customers could switch. Every single time they go shopping, they were free and able to go into a different store. And it’s just a very different universe to the one which confronts your Honour on the facts of this case.
3295 In summary, the case before me does not justify collapsing various functional levels. So, unlike Metcash, it is appropriate to treat separately the mobile OS licensing level.
3296 For the reasons given, the relevant market, for the purpose of analysing the OEM restrictions, is the mobile OS licensing market.
Mobile OS licensing market – market power
3297 Given that there is a market for the supply of licensable mobile operating systems, it seems to me that Google has a substantial degree of power in that market.
Google’s arguments
3298 Now Google says that it is not persistently able to act in a manner unconstrained by competition. And it says that Epic has failed to establish that Google has the capacity to act unconstrained with respect to Android OS. This is for the following several reasons.
3299 First, Google says that there is a strong and close competitive constraint imposed by iOS, and Apple iOS devices, on Google. Google says that it constantly needs to invest in quality improvements with respect to the Android OS so that developers do not switch all or part of their investment to iOS, and so that users do not increasingly switch to iOS devices or spend more on in-app purchases on iOS devices. It says that the existence of this strong and close competitive constraint is inconsistent with the existence of market power with respect to Android OS.
3300 Second, Google says that it continues to invest in the quality and capability of Android OS, including in response to iOS.
3301 It says that the evidence makes clear Google’s perception that it continually needs to invest in Android OS quality to reduce the quality gap to iOS, and the fact that it does so.
3302 So, a Google presentation titled Premium Device Services Monetisation dated October 2019 showed concern about a substantial hardware and services monetisation gap between iOS and Android devices, and that the Android ecosystem health was “in jeopardy”. The document identified that Google needed to invest in various ways to mitigate the problem it was facing, including by sharing more revenue with OEMs and investing in the quality of Android OS and Android devices. This is evidence of constraint, not an absence of constraint.
3303 Further, Google has sought to innovate first relative to Apple’s iOS, or followed suit with a competitive response in similar OS features. Professor Asker considered these innovations and responses to be consistent with meaningful competition between Android OS and iOS.
3304 Google says that these innovations and continued investments in Android OS evidence a lack of ability to act in a manner unconstrained by competition, because such investments would not be necessary if Google and OEMs thought user switching to iOS was only a limited possibility.
3305 Ms Edwards-Warren suggested that this is not meaningful competition with iOS because of the time lag between competitive responses, but this was nothing but a bare assertion made without any analysis which could show that Google’s continued Android investment results from anything other than constraint.
3306 Likewise, since 2017 Google has continued to make innovations notwithstanding device saturation in the market for OS-enabled smartphones.
3307 These innovations and continued investments in Android OS evidence a lack of ability to act in a manner unconstrained by competition, because such investments do not correspond with attempting to grow the overall market, as it was already saturated, and would not be necessary if Google and OEMs thought user switching to iOS was only a limited possibility.
3308 Third, Google points out that Android OS is licensed to OEMs for free. Google earns no revenue from OEMs in exchange for this licence. This fact is inconsistent with an ability to persistently raise price above efficient costs.
3309 Epic’s response to this is to highlight the fact that Google receives value from its agreements with OEMs. However, the fact that Google receives value from the contractual terms of its OEM agreements does not mean it is receiving a price in the relevant economic sense. This is because it is not something that actually generates direct revenue and profit for Google.
3310 As Professor Asker observed during the concurrent evidence session, the terms of the OEM agreements themselves are simply not a flow of money that an economist would call a price.
3311 Further, Google has an agreement under which it pays Samsung “bounties” for competing more vigorously with Apple by switching users from iOS devices to Samsung Android devices. This tells against Google possessing any market power with respect to Android OS, because it indicates a concern on Google’s part about a threat of losing Android device users to iOS and winning them back. If Google had market power with respect to Android OS, this would not be a concern, because it would not need to compete vigorously in this respect.
3312 Fourth, Epic has not established that OEMs lack countervailing power with respect to Android OS. To the contrary, the evidence establishes that OEMs do have choices that provide them with substantial bargaining power vis-à-vis Google. One needs to consider the extent to which OEMs have countervailing power, including by reason of the need for Google to support the economics of ongoing Android device manufacturing. For example, the following may be noted.
3313 The prominent OEMs who make Android devices have a broader set of substitution possibilities than licensing or developing another mobile OS.
3314 Samsung, OPPO and Lenovo are all manufacturers of a range of electronic devices and appliances. The fact that they can switch some or all of their investment to making other products provides them with an ability to bypass Google’s Android OS in their quest for making a return on their investments. This threat is real. It is what LG did in 2021. It announced that it was closing its mobile phone business to focus its resources on making other products.
3315 Further, the fact that OEMs have countervailing power in their negotiations with Google is also corroborated by the RSAs, which have the effect that Google essentially pays some OEMs to make Android devices. If Google had substantial market power with respect to Android OS, it is unlikely that it would need to provide those OEMs with incentives to make and supply Android devices.
3316 Finally, with respect to barriers to entry, Epic suggests that the MADAs, AFAs/ACCs and RSAs raise barriers to entry for the development of rival mobile OSs and that force OEMs to make an “all or nothing” choice. But the following may be noted.
3317 First, the MADAs, AFAs/ACCs and RSAs do not prevent OEMs from developing their own mobile OS and supplying mobile devices using that OS. There is no all or nothing choice imposed on OEMs. They are free to make and supply GMS and Android OS devices at the same time as making and supplying non-Android devices. For example, Microsoft’s Windows Mobile was an example of a mobile OS that OEMs used notwithstanding that they also made and supplied GMS and Android OS devices.
3318 Second, the RSAs do not erect a barrier to entry for any rival mobile OS. A maker of a rival mobile OS could offer similar incentives to encourage OEMs to make mobile devices using its OS. There is nothing in the RSAs that would prevent OEMs from licensing a rival mobile OS, and nothing to stop a rival mobile OS supplier doing so.
3319 So, whilst it is true that an OEM or third party would incur significant costs in developing a rival mobile OS, as Google did in developing Android OS, the OEM agreements do not impose some insurmountable obstacle that would prevent this from occurring. Nor does it prevent OEMs from licensing and selling devices using a non-Android OS.
Google’s justifications
3320 Now Epic maintains that the AFAs and ACCs are elements of Google’s alleged market power in its asserted mobile OS licensing market. It says that Google insists upon OEMs entering into ACCs, and implies that OEMs enter into such agreements against their will.
3321 Epic says that if an OEM wanted to comply with the CDD, it could do so without signing an ACC. The proposition appears to be that OEMs must be acting under compulsion in agreeing to be bound by the ACC because it requires them to do that which they could do voluntarily without an ACC. Epic says that the source of that compulsion is that Google will only licence the GMS apps under a MADA if OEMs agree to be bound by an ACC.
3322 But Google says that this ignores the economic problem that the ACCs, and the AFAs before them, are intended to solve, and which is a benefit to the Android ecosystem as a whole.
3323 As I have said, the AFAs and ACCs address the risk of device fragmentation. The nature of that risk is that individual OEMs, acting unilaterally, may take steps in respect of their own devices that would, through the mechanism of indirect network effects, adversely affect the incentives of developers to develop for Android and for users to take up Android devices.
3324 That problem is not solved by providing OEMs with a CDD and hoping that they follow it. That type of approach brought about the demise of earlier operating systems through device fragmentation.
3325 What the ACCs accomplish is that Android OEMs are bound by agreement to adhere to clear compatibility baseline standards, which facilitates confidence in the ecosystem on the part of developers and users. Through indirect network effects, such confidence accrues to the benefit of all participants in the Android ecosystem, including OEMs.
3326 Now Epic assumes that OEMs would prefer not to be bound by ACCs. But I will not assume that the OEMs lack sophistication in conducting their commercial affairs, including in connection with the Android ecosystem. The Android OEMs are some of the largest equipment manufacturers in the world, and include Sony and Samsung. The notion that they do not perceive benefit in the existence of a common compatibility standard across Android, and in the existence of contractual commitments that create confidence that those standards will be adhered to, is commercially unreal.
3327 I infer that the true reason that OEMs enter into ACCs, and previously entered into AFAs, is that they recognise that they are amongst the ultimate beneficiaries of coordinated and enforceable Android compatibility standards. It is in the OEMs’ collective interest that each OEM is bound by such standards.
3328 Let me say something about the provisions of the AFAs and ACCs that limit the OEM’s ability to distribute forked Android devices. Epic says that under the AFAs, OEMs agreed only to distribute devices developed to run on the Android OS if those devices were Android compatible devices. That is also the case under the ACCs, subject to certain exceptions. One such exception is that OEMs may manufacture devices that are not Android compatible devices for a third-party as long as such devices are marketed under a third-party brand by the third-party. That exception minimises the risk of confusion as to the traits and compatibility of an Android-branded device.
3329 Epic says that these aspects of the AFAs and ACCs have the effect of committing OEMs to only distribute Android compatible devices and to refrain from manufacturing, distributing or marketing, except as third-party brands, any smart mobile devices that operate on an Android fork or are otherwise non-compliant with the CDD.
3330 But the words “or are otherwise non-compliant with the CDD” are a misdescription because the relevant clauses of the AFA and ACCs only apply to devices developed specifically to run on Android. That is, the AFAs and ACCs do not prevent manufacturers from distributing any devices other than devices that run on Android forks. They do not prevent OEMs from distributing devices that operate on operating systems other than those based on the Android OS.
3331 The true position is that the ACCs and the AFAs before them do not restrict the freedom of signatory OEMs to manufacture mobile devices generally, save in the case of devices that are Android forks and, in the case of the ACCs, subject to further exceptions.
3332 That limitation is sensible having regard to the interests of the ecosystem as whole. It fosters confidence on the part of developers and users that all of an OEM’s Android devices will comply with the CDD and pass the CTS. In this way, developers and users can have confidence that all Android devices produced by an OEM under a specific brand are Android compatible devices. Developers avoid the need to develop numerous versions of their apps to cater to differing versions of Android deployed on each OEM’s devices and users can expect that their favourite Android apps will be available on all Android compatible devices. That confidence accrues to the benefit of all participants in the Android ecosystem by making it easier for both users and developers to take up Android, and thereby improves the competitiveness of Android against rival platforms.
Analysis
3333 But in my view, Google has a substantial degree of power in the mobile OS licensing market.
3334 Let me first say something about market shares and the lack of alternatives.
3335 As Epic points out, throughout the relevant period, Google, as the licensor of GMS and Android OS, has been the only supplier of licensable mobile OSs with a material share of supply. In Australia and globally, Google’s share of the supply of licensable mobile OSs (units shipped) was at least 99.9% in each year from 2017 to 2022.
3336 Google is, effectively, a monopoly supplier of licensable mobile OSs globally (excluding China) and in Australia, which tends to suggest that Google does not face any material competitive constraint from rival suppliers of licensable mobile OSs.
3337 OEMs must enter into a MADA with Google in order to use the Android trademark and distribute GMS and Android OS. Whilst OEMs theoretically can do without GMS, the practical reality is that they must license GMS Android if they wish to sell smartphones profitably.
3338 The other licensable mobile OSs that OEMs might choose have an exceedingly small market share, being less than 0.1%. OEMs that choose an alternative option also have market shares that are tiny.
3339 Further, Android devices without a GMS licence cannot access Google Play Services and are functionally limited as a result. For example, 826 of the top 1000 Android apps rely on one or more of the Google Play Services APIs for basic functionality.
3340 Further, it would seem that GMS makes devices more saleable and that users would expect popular Google apps such as Google Maps on their devices.
3341 Now I accept that theoretically OEMs have a choice whether to enter into a MADA and install GMS, but there is no OEM that distributes Android compatible devices without GMS outside of China. The vast majority of Android devices outside of China are distributed with GMS pre-installed.
3342 Now Professor Asker seemed to accept that OEMs have little alternative but to license GMS and Android OS if they wish to sell smartphones. But he contended that OEMs nonetheless have strong negotiating power or countervailing power with Google, by reason of their option to re-allocate production resources away from the production of Android devices to other products, such as televisions. But as Epic points out, this is premised on two assumptions.
3343 Now one assumption is that OEMs manufacturing Android devices for sale in Australia during the relevant period included companies that make a range of mobile devices other than Android smartphones and tablets, but that assumption has not been made good.
3344 The other assumption is that Google needs to incentivise OEMs to manufacture Google Android devices outside of China or else risk OEMs leaving the ecosystem, but this amounts to saying that Google’s market power is constrained by the possibility of OEMs ceasing to manufacture Android devices entirely, which proposition has not been made good.
3345 There is no evidence of OEMs at any time during the relevant period threatening to re-allocate resources away from the production of Android devices to other things, in order to extract price concessions from Google or better terms more generally.
3346 Now there was some evidence to the effect that certain OEMs were struggling to keep up with Apple, but that does not amount to evidence of a real risk of OEMs ceasing to manufacture Android devices entirely or relying upon that possibility in negotiations with Google.
3347 Further, Professor Asker’s reliance on a press release by LG went nowhere for the reasons explained by Epic.
3348 Further, it is difficult to understand how competition between Android device OEMs would constrain Google.
3349 In the absence of any evidence of a material risk of OEMs ceasing to manufacture Android devices by reason of their low margins, I reject the proposition that Google’s market power is so constrained by such a possibility that it lacks substantial market power.
3350 Moreover, and as Ms Edwards-Warren pointed out, if an OEM’s outside option is to stop producing smartphones and to start producing something else entirely, this indicates a lack of competition in OS, and that Google has already managed to extract the economic rents available to the OEM in the production of smartphones. It is not an indication of a lack of substantial market power in the mobile OS licensing market.
3351 Let me at this point move on to discussing barriers to entry, where the evidence shows that there have been and remain substantial barriers to entry and expansion in the mobile OS licensing market, such that there is no real prospect of rivals threatening Google’s dominance within a realistic time frame.
3352 First, potential entrants or those seeking to expand their market share face what Epic correctly describes as a chicken and egg problem because the success of an operating system depends upon its ability to attract OEMs to develop compatible devices, its ability to attract developers to develop a critical mass of apps compatible with the operating system, and its ability to attract users. These requirements are interdependent.
3353 OEMs will not develop compatible devices without a sufficient number of users willing to buy devices running the operating system. But there will not be a sufficient number of such users without a critical mass of apps compatible with that operating system. But developers will not develop apps unless there is a sufficient number of users to make it worthwhile.
3354 As Epic rightly points out, Google overcame that chicken and egg problem many years ago and now benefits from network effects. The value and utility of GMS and the Android OS has grown and continues to grow as more OEMs, developers, and users participate in its ecosystem. That represents a significant barrier to new entrants.
3355 Second, there are legal barriers in the form of Google’s ownership of AOSP, GMS, Google Play Services and the Android trademark. If an OEM wishes to pre-install GMS and the Android OS, including any of the five Google apps which are among the top ten most used Play Store apps in Australia, on any of its devices and market its products as “Android”, it has no choice but to deal with Google, rather than a new entrant to the market.
3356 Third, by making each OEM’s licence to distribute GMS and the Android OS and use of the Android trademark conditional upon compliance with the ACC, Google has prevented OEMs from choosing to distribute both Android devices and devices using an Android fork. It forces OEMs to make an all or nothing choice between GMS and the Android OS and that of any rival that is offering to license an Android fork.
3357 Any rival mobile OS based on Android would have to persuade OEMs to forego entirely the ability to use the Android trademark and distribute GMS and the Android OS. It is unlikely that OEMs would do so, in order to distribute devices with an unproven new licensable mobile OS, or an existing mobile OS whose market share is tiny relative to that of GMS and the Android OS.
3358 Fourth, by offering incentive payments under RSAs, RSA3s and MIAs, as well as making those incentive payments conditional upon ongoing compliance with the MADA, Google has ensured that there are adverse financial consequences for OEMs that choose to distribute devices which do not have GMS and the Android OS pre-installed. Not only will the OEM receive no incentive payments in respect of those devices, but if the OEM distributes devices with an Android fork pre-installed, the OEM will breach its ACC and MADA, and thereby lose its right to a share of ongoing revenues earned from all the Android devices it has distributed to date. This creates a material disincentive for OEMs to switch to an alternate mobile OS and another barrier for a new entrant.
3359 Fifth, Google is able to compel the pre-installation and premium placement of its own apps by way of the MADA. By contrast, when it initially launched Android Market, the predecessor to the Play Store, Google paid OEMs and carriers 25% of the revenue generated by paid apps, and ultimately in-app purchases, in order to incentivise OEMs and carriers to pre-install Android Market.
3360 Further, Google also has complete control over which of its own apps it designates as GMS apps for the purposes of the MADA. This, in turn, reinforces Google’s market power as it attracts more users to GMS apps and makes devices without GMS apps less desirable for users.
3361 Sixth, there are significant costs associated with developing a commercially viable mobile OS, including the costs of developing all the services, interfaces, and core components needed to power an operating system, of attracting a large enough app developer base to create a sufficiently large app library, and of finding a hardware manufacturer that is willing and able to manufacture smart mobile devices running an OS besides GMS and the Android OS.
3362 As Epic points out, the practical difficulty of overcoming these barriers is demonstrated by the historical absence of meaningful new entry or expansion, and by the commercial failures of Amazon with Fire OS, and the failure of Microsoft with Windows Phone OS and Windows 10 Mobile.
3363 Let me now say something about the existence of terms excluding competition, which as Epic correctly contends are relevant to the question of market power.
3364 Google’s requirements under the MADA, AFA/ACCs and RSAs are all examples of contractual arrangements which protect Google’s position as a monopoly supplier of licensable OSs. In addition to their role in raising barriers to entry for new rivals, this is a further indication of Google’s substantial market power.
3365 Finally, Google clearly has power in such a market such as, for example, the capacity to reduce quality.
3366 In summary, in the mobile OS licensing market, Google is an effective monopolist, with a 99.9% share of the market.
3367 By means of the various contractual provisions at issue in this case it has erected significant barriers to entry and expansion, such that it is not constrained by even the threat of entry or expansion.
3368 It is operating in a manner different from the behaviour that a competitive market would enforce on a corporation facing otherwise similar cost and demand conditions.
3369 I agree with Epic that Google has a substantial degree of power in the mobile OS licensing market.
3370 Now as to conduct, Epic has not put a case concerning conduct with an anti-competitive purpose or effect in that market. Rather, Epic says that Google possessing substantial market power in the mobile OS licensing market has engaged in conduct in that market for the purpose or effect of substantially lessening competition in the Android app distribution market.
3371 Now I have discussed in my reasons in Epic v Apple the question of causation and its relevance to s 46, and it is unnecessary to repeat the detail of that discussion here.
3372 I discussed various possible approaches concerning how s 46 should be looked at, and opted for the first approach there discussed. So, s 46 is to be read such that some form of causation is to be taken as necessarily implicit in the statutory test and assumed by the legislature to apply and be conclusively assumed if all conditions for the statutory proscription in each case have been satisfied and without more. So, in other words, no separate causal link needs to be stipulated, demonstrated or proven.
3373 But I also said in my reasons in Epic v Apple that if the third approach applied, there would be no difficulty concerning two of the three markets raised by Epic concerning Google. But a difficulty on causation, if it was required, might arise concerning the mobile OS licensing market and Google’s substantial market power therein.
3374 Let it be assumed that there is such a market and Google has substantial market power therein, as I have decided. And let it be assumed that some form of causation needs to be shown, assuming that I am wrong in applying the first approach.
3375 How and what is such causation to be applied and how does it link up to the impugned conduct as I have found?
3376 Now at this point I do not need to answer such questions. I have addressed the impugned conduct question in other sections of my reasons. To the extent that such impugned conduct, as I have found, is somehow linked to Google’s substantial market power in the mobile OS licensing market, I have identified this to the extent necessary elsewhere in my reasons. If that is identified and there is such a link, then if the third approach is applied, I would have no difficulty in finding the necessary causal link.
The MADAs — general
3377 Now as I have indicated earlier, Google has entered into MADAs with various OEMs, pursuant to which Google licenses the OEMs to use a suite of apps, SDKs and APIs that together make up Google Mobile Services (GMS) which include familiar Google apps such as Google Search, the Play Store, Google Maps, Chrome and YouTube.
3378 But it is not mandatory for an Android OEM to enter a MADA. OEMs are free to manufacture and market Android devices without entering a MADA if they wish.
3379 Moreover, entering a MADA does not oblige the OEM to pre-install GMS apps, but provides a license for the GMS apps and imposes certain requirements if the OEM does elect to pre-install them on any or all of their devices, which they can do on a device by device basis.
3380 Google does not charge OEMs a fee to enter into the MADA and does not charge OEMs a fee to license the GMS apps outside Europe and Turkey, where it has done so to comply with decisions of the European Commission and Turkish Competition Board.
3381 The MADAs require OEMs that decide to pre-install GMS apps on a device by device basis to pre-install all core applications and flexible applications applicable for the territory in which the device is first turned on. In Australia, the core applications are Google Search, Google Chrome, the Play Store, Gmail, Google Maps and YouTube.
3382 If GMS apps are installed, the Play Store must be placed on the DHS of the device, although users are thereafter free to relocate or hide it.
3383 I will refer to an Android compatible device with GMS installed as a GMS Android device.
3384 OEMs that wish to develop, manufacture and sell GMS Android devices are required to enter into a MADA with Google, which requirement is how Google licenses OEMs to use Google’s proprietary software and intellectual property.
3385 Under the MADAs, Google also licenses OEMs to use the “Android” and “Google” trademarks in relation to GMS Android devices. Now outside of Europe and Turkey, Google does not charge OEMs a licensing or other fee under the MADAs.
3386 Now under the MADAs, Google grants OEMs a non-exclusive licence to distribute GMS on and only on Android compatible devices, which licence is subject to the OEM complying with a valid and effective AFA or ACC. It may be terminated immediately by Google if the OEM terminates its ACC.
3387 Now the distribution licence granted under a MADA is subject to the GMS requirements. Some of the GMS requirements form part of the technical restrictions which I have already identified and will not repeat here. The remaining relevant GMS requirements do not form part of the technical restrictions and are as follows.
3388 First, an OEM must pre-install all core applications on the device, including the Play Store. Further, new product launches must pre-install all core services and apps in the latest GMS bundle no later than 60 days after the latest bundle is released by Google.
3389 Second, an OEM must feature on the default home screen (DHS) of the device the Google Search widget, the Play Store app icon and a folder labelled “Google” containing the core applications.
3390 Third, an OEM must place the Play Store in the apps menu and, specifically, within the top level of the apps menu and not any folder on the apps menu.
3391 Now GMS includes the APIs known as Google Play Services. GMS also includes the core applications, being Google proprietary apps being the Play Store, Search, Chrome, Google Maps, Gmail and YouTube, and flexible applications, being additional Google proprietary apps which differ between territories and, in Australia, include Drive, YouTube Music, Play Movies, Duo and Photos.
3392 It is not possible for a device to utilise the Google Play Services APIs unless the Play Store is installed. The remaining five core applications were among the top six apps by usage in the Play Store as of April 2023.
3393 Under the MADAs, OEMs are only permitted to distribute a device containing GMS if all core applications including the Play Store and flexible applications have been pre-installed on that device, save as approved by Google in writing.
3394 It is not permissible for OEMs to choose which of those GMS apps they wish to pre-install and which they do not. Google lauds this as a virtue, being a requirement that ensures a consistent out-of-the box experience for users.
3395 As I have indicated, the MADA also grants the OEM a licence to display Google owned trademarks, which include the Android trademark, “solely for the purposes of this Agreement”. Those purposes are to grant the OEM a licence to distribute devices with GMS installed and to prescribe the conditions of that grant. So, the licence to use the Android trademark permits use of that trademark in connection with the distribution of Android devices. It does not permit use of the Android trademark in connection with the distribution of devices that do not have GMS installed.
3396 Now Google maintains that OEMs which have signed a MADA can choose, on a device-by-device basis, whether to pre-install GMS. But OEMs have no practical choice to do otherwise, and the putative choice is only ever exercised one way.
3397 Moreover, the evidence before me has not identified a single OEM that distributes non-forked Android devices outside China without pre-installing GMS. In other words, it would appear that there is no OEM that signed a MADA but chose to distribute some Android devices without GMS.
3398 So, apart from devices being distributed in China or on an Android fork to which a MADA does not apply, in substance all Android-based mobile devices in the world are distributed with GMS pre-installed.
3399 Let me now elaborate further on the placement requirements pertaining to the GMS apps that are prescribed by the MADAs.
3400 Specifically, OEMs must place on the device’s DHS the icons which give access to the Google Search app, the Play Store and a folder providing direct access to icons for the core and flexible applications.
3401 OEMs must also ensure that any GMS app that is not a core or a flexible application is placed no more than one level below the DHS.
3402 Samsung’s MADA imposes placement requirements to the same effect, although since 8 January 2018 those requirements have been varied in respect of three categories of device being the Galaxy S9, Galaxy Note9 and Galaxy Fold.
3403 On those devices, Samsung may remove all app icons from the DHS. But where Samsung does so, the Play Store must be placed in the “device hotseat”, which is the dock along the bottom row of every screen, including the DHS. And a folder of pre-installed GMS apps must be placed in the first row of the application tray, which is accessed by swiping up from the bottom of the DHS.
3404 Further, the MADA provides that OEMs may not distribute an Android compatible device without Google’s written approval prior to the launch of each device model, and OEMs must send the final software build of their Android compatible devices, as well as test reports confirming that they pass the CTS, to Google for final approval. Google provides such approval in its sole discretion.
3405 This aspect of the MADA was described by Google’s executives in 2010 as a poison pill. It was designed to prevent a loss of control by Google, that is, to ensure no-one but Google would control the Android ecosystem. Mr Gennai denied this, but I agree with Epic that the expression has no other likely meaning in this context.
3406 Further, to comply with decisions of the European Commission and the Turkish Competition Board, Google entered into different versions of the MADA in the European Economic Area (EEA) and Turkey. These are known as EMADAs and TMADAs respectively.
3407 Under the EMADAs and TMADAs, Google Search and the Chrome app are not included in the GMS licence granted to OEMs for devices that are distributed in the EEA and in Turkey. Instead, Google Search and Chrome are separately licensed to OEMs at no cost. OEMs must pay a licensing fee to Google to license the remaining GMS APIs and apps, including the Play Store. Otherwise, the EMADAs and TMADAs are in substantially similar form to the MADAs.
3408 Further, the MADAs are expressly non-exclusive insofar as they confer pre-installation and placement rights on Google in respect of the GMS apps.
3409 For example, recital C to the MADA between Google and Beijing Xiaomi Mobile Software Co Ltd states:
Nothing in this Agreement is intended to restrict [the Company] or end users from installing third-party services on devices with Google’s suite of mobile services, including services with similar functionality.
3410 That recital is given operative effect by Section 4.6:
No Exclusivity: Other than the placement and set-up requirements for Google Applications set forth in Section 4.4, this Agreement does not restrict or limit [the Company] from preloading or determining the placement of its own or third party applications or services on its Android devices.
3411 The effect is that provided that the OEM satisfies the placement and set-up requirements for “Google Applications”, which includes the GMS apps, the OEM is free to pre-install and determine the placement of any of its own apps or any third party apps including any app stores, that it chooses.
3412 The placement requirements stipulated for the Google applications in the MADA are not such as to foreclose OEMs granting other apps including app stores equivalent prominence or placement to the Play Store.
3413 Android mobile devices have space for between 16 and 24 app icons on the DHS. Accounting for the space required for the Play Store icon, the Google Search widget and the Google folder, there are, at a minimum, ten other tiles on the DHS where apps can be placed.
3414 So, there is ample room for an OEM to pre-install its own app store or a third-party app store on the DHS if it chooses to do so, which it is free to do under the terms of the MADA. Samsung has so done so. Different placement requirements apply to certain Samsung devices.
Do aspects of the MADAs have an anti-competitive purpose?
3415 What is the end which Google seeks to achieve by including contractual provisions mandating the pre-installation of, and DHS placement for, the Play Store on every single Android device?
3416 Epic says that Google is aiming to maintain the Play Store’s position as the pre-eminent distributor of Android apps by, first, ensuring that it is the only Android app store with global reach excluding China, and second, by maximising the prospect that Android device users will continue to choose the Play Store rather than any alternative Android app store.
3417 Epic says that collectively, the impugned provisions of the MADA achieve that end in the following ways.
3418 First, Epic says that by reason of the MADA pre-installation requirement, the Play Store is ubiquitous within the Android ecosystem, installed on virtually all Android devices globally outside of China. It is not practicable for any other app store to achieve anything close to commensurate reach, and none have done so. The Galaxy Store’s reach is closest, but even it is pre-installed on only about 40% of Android devices globally outside China. No other app store is pre-installed on more than about 13% globally outside China.
3419 Second, Epic says that by reason of the MADA pre-installation requirement, the Play Store is more discoverable than any rival Android app store. Being installed on virtually all Android devices means that more users will see the Play Store than will see any rival app store. In contrast, most of the time, a rival Android app store will have to rely on advertising or word of mouth to be discovered by Android device users.
3420 Third, Epic says that by the MADA pre-installation requirement, Google ensures that no other Android app store can ever be the only app store pre-installed on an Android device. The best any rival can hope to achieve is to be pre-installed together with the Play Store.
3421 Fourth, Epic says that by the MADA DHS placement requirement, Google has maximised the chance that users will follow that flow and will see, open, and use the Play Store app. Whilst it is possible for a rival Android app store to also obtain DHS placement, it will only be able to do so on a fraction of Android devices, with the sole exception of Samsung. So, in practice rival Android app stores will be limited to less than half of Android devices globally.
3422 Fifth, Epic says that by the MADA DHS placement requirement, Google has ensured that no other Android app store can ever be the only app store pre-installed on the DHS of an Android device. The best any rival can hope to achieve is to be pre-installed alongside the Play Store.
3423 Now Google’s documents refer to the financial benefits to Google of having the Play Store on the DHS of Android devices. So, as Epic points out, a March 2015 document titled Android BD Overview refers to ensuring home screen placement of “Play & Search” as a key opportunity to improve monetization and it recommended continuing to ensure home screen placement of Play on devices to “ignite Play performance”. It also presented data showing that home screen placement resulted in substantially more revenues for Search and the Play Store relative to placement off the home screen.
3424 Further, the MADA requirements for Play Store pre-installation and DHS placement do not stand alone. According to the Play problem statement authored by Mr Gennai, which I have discussed elsewhere, they form part of a multi-layered defence of the Play Store as the preeminent Android app store, being focused around major points of distribution.
3425 Sixth, Epic says that both the MADA pre-installation requirement and the DHS placement requirement drive network effects, making it harder for rival app stores to compete.
3426 Generally, Epic says that these were the results that Google sought to achieve by the inclusion of the impugned provisions in the MADA.
3427 Epic says that Google’s overall purpose was to maintain the Play Store’s position as the pre-eminent distributor of Android apps by ensuring that it is the only Android app store with global reach outside China, and by maximising the prospect that Android device users will continue to choose the Play Store rather than any alternative Android app store.
3428 Epic also points to the following matters.
3429 A 2016 survey titled Google Play Competitive Usage found that the Play Store not only has a very large market share, but also that users learned about the Play Store “mostly from being preinstalled on phone”, whereas they “learn about competitive app stores primarily through word of mouth or advertising”. And users were “generally equally satisfied with competitors vs Play store, except when it comes to the quantity of apps available”.
3430 Further, the requirement that the Play Store be placed on the DHS of Android devices has formed part of the MADA since about 2014. It was included at the insistence of Mr Pichai, who was the head of Android at the time.
3431 In an email to Mr Pichai on 12 December 2010, Mr Alan Eustace said:
…
We’ve done dozens of studies on the Explorer default search flows to know that adding any steps between a user and an action dramatically reduces the chances that they will follow that flow. …Our job is to make it easier to choose a Google search page than it is to choose Bing search page. …
…
3432 In an email to Mr Eustace on 14 December 2010, Mr Pichai said that he had “done more here at Google to drive defaults than anyone else”. That comment was made in response to an observation that the Google icon was not on the home screen of the Chrome OS.
3433 Epic says that such observations are equally applicable to the placement of an app store icon on a mobile device. Mr Pichai understood home screen placement to “drive defaults”, that is, to dramatically increase the chance that users will follow the relevant flow and choose Google’s service rather than a competitor’s service.
3434 Epic says that the person primarily responsible for the inclusion of the MADA DHS placement requirement was the current CEO of Google and Alphabet, Mr Pichai. Mr Pichai has not been called to give evidence in these proceedings and Epic says that his absence has not been explained.
3435 Further, Epic points out that Ms Kochikar under cross-examination accepted the significance and the value of DHS placement.
3436 Further, Epic points out that although Mr Gennai conceded that the home screen of an Android device is where apps are most easily discovered or seen by Android device users, and that Google insists upon DHS placement for the Play Store because it perceives that such placement improves the chances that users will access the Play Store, Mr Gennai sought to downplay the significance of DHS placement for the Play Store. I should say here that I agree with Epic that his evidence was tailored to assist Google’s case.
3437 Further, I accept the evidence of Professor Luca, which I have discussed elsewhere, that DHS placement is a significant benefit to the Play Store. Professor Luca concluded that the Play Store exhibits the properties of a default choice for users. His evidence supported the proposition that the likely effect of the relevant conduct is that Android device users are more likely to choose the Play Store compared to alternatives app stores relative to a world in which the Play Store is not required to be pre-installed on Android devices’ DHSs.
3438 Now of course the MADAs do not prohibit OEMs from pre-installing additional apps besides the GMS apps. But there are over two million apps on the Play Store, whereas the median number of apps pre-installed on Android devices by each of the five most prominent OEMs is between 56 and 136. Most of those apps will be GMS apps, or apps developed by the OEM and/or carrier.
3439 So, there is only very limited opportunity for third-party developers to have their apps pre-installed at all, let alone on the DHS. Relatively few third-party apps are pre-installed on an Android device. And OEMs are reducing the number of pre-installed third-party apps due to user concerns about bloatware and a cluttered user experience. In contrast, pre-installation on every Android device is guaranteed for Google’s nominated apps, including the Play Store.
3440 Further, Epic says that a consequence of the Play Store being pre-installed on every Android device is that no other Android app store can ever be the only app store pre-installed on such a device. Likewise, a consequence of the Play Store being pre-installed on the DHS of every Android device is that no other Android app store can ever be the only app store pre-installed on the DHS of such a device.
3441 So, Epic says that all any rival app store can ever hope to achieve is that it may be pre-installed on the same device and on the same screen as the Play Store. So, given the terms of the MADA, a rival Android app store will never have exclusivity, or a more prominent placement, “out-of-the-box”.
3442 Further, Epic says that in cases where the OEM or carrier pre-installs their own app store, the prospects of a third-party app store being pre-installed are lower, since there would then be three app stores pre-installed on the one device.
3443 Epic points out that Google made that assessment when considering the risk that the Amazon App Store would be pre-installed on a screen, but not the DHS, of Samsung devices. It concluded that that was a low risk, including because of a Samsung “allergy” to having three Android stores preloaded on their devices which would lead to a bad user experience.
Analysis
3444 Now as Google points out, the MADAs do not prevent OEMs from pre-installing apps including rival app stores on Android devices, from placing those apps on the DHS, or from making alternative app stores equally discoverable relative to the Play Store. Indeed, the MADAs contain express clauses that confirm that OEMs are not prevented from doing so.
3445 Indeed, as Google points out, there are four principal problems with Epic’s claims with respect to the pre-installation and placement requirements of the MADAs.
3446 First, the purpose of the pre-installation and placement provisions is to provide a consistent high quality out-of-the box user experience on the OEM’s devices, including by ensuring that users have a reliable app store to meet their initial requirements, and to provide Google with a means of securing the distribution via pre-installation of GMS apps on those devices. That is not a proscribed purpose.
3447 Second, the pre-installation and placement requirements are non-exclusive, operate on a device by device basis, and do not in any way restrain, restrict or foreclose the pre-installation, placement or promotion of any other apps, including first party or third party app stores, on Android devices.
3448 Third, there is no evidence that any developers have been prevented or hindered from obtaining pre-installation of their apps or app stores by reason of the pre-installation of the Play Store or its placement on the DHS of any devices. Epic’s own success in obtaining pre-installation deals is contrary to Epic’s case on this point.
3449 Fourth, Epic has not proved that OEMs would elect to make any different pre-installation and placement decisions in the counterfactual such that there is any real commercial likelihood that competition would be different in a future without the MADA pre-installation and placement requirements.
3450 Further, I agree with Google that the MADAs secure various benefits to Google, to OEMs, to users, and to the Android ecosystem as a whole.
3451 First, the MADAs license OEMs to use a highly desirable package of Google-owned software applications that enable OEMs to provide users with a high quality out-of-the-box user experience on GMS Android devices.
3452 Second, by licensing the core GMS apps, the MADAs ensure the consistency of experience across Android devices.
3453 Third, the MADAs impose security obligations on OEMs, including requirements to provide security updates to devices for a specified period after the device launch date.
3454 Fourth, from Google’s perspective, the MADAs provide a means by which Google obtains wide distribution of the GMS apps throughout the Android ecosystem.
3455 Let me elaborate on some aspects.
3456 Now as I have said, the purpose of the pre-installation and placement provisions of the MADAs is to provide a consistent high quality out-of-the-box user experience on the OEM’s devices, including by ensuring that users have a reliable app store to meet their initial requirements, and to provide Google with a means of securing the distribution via pre-installation of GMS apps on those devices. But I agree with Google that that purpose does not involve or reflect any subjective intention to lessen competition.
3457 Users expect a baseline set of functionalities on their mobile devices out-of-the-box, which the GMS apps provide. Consumer surveys conducted by or for Google confirm that users place considerable value on having the GMS apps installed.
3458 A 2019 Google survey of US smartphone purchasers found that 85% of respondents considered pre-installed GMS apps to be somewhat or very convenient.
3459 In terms of the Play Store specifically, a 2018 survey of Korean users found that 91% of users liked having their favourite app store pre-installed and placed within easy reach on their Android device, and 95% of respondents said that the Play Store was their favourite app store notwithstanding that a majority of respondents had three app stores installed on their device.
3460 Further, as Google points out, the counterparties to the MADAs are some of the world’s largest equipment manufacturers of smartphones and other devices and it is unlikely that they would agree to the terms of the MADA unless they were of the view that the pre-installation and placement of the GMS apps on their devices would be attractive to users and promote the sale of those devices.
3461 Epic said that Google aimed to maintain the Play Store’s position as the pre-eminent distributor of Android apps by, first, ensuring it is the only Android app store with global (excluding China) reach, and second, by maximising the prospect that Android device users will continue to choose the Play Store rather than any alternative Android app store.
3462 Epic says that that is a purpose of substantially lessening competition. But I reject that submission for the reasons largely given by Google.
3463 First, it is an inaccurate statement of Google’s purpose. The MADAs date from the early days of Android, and from a time when the predominant mobile operating systems were Blackberry and Symbian, and have not changed materially in the interim. So, it is unlikely that Google had a substantial subjective purpose when including pre-installation and placement provisions in the MADAs of maintaining some pre-eminent position within Android for the Play Store.
3464 Moreover, and as I have said, the evidence demonstrates that the true purpose of the pre-installation and placement requirements relating to the GMS apps on Android devices is to provide a consistent high quality out-of-the-box user experience on the OEM’s devices, through the distribution and prominent placement of its apps on those devices.
3465 That is not a proscribed purpose. As Google says, it is not an intention to harm the competitive process but to enable Android devices to compete more effectively and enhance the viability of the Android ecosystem.
3466 Further, even if one was to regard Google’s pecuniary interest in securing the distribution and placement of its apps as a standalone substantial purpose of the relevant provisions, that also is not a proscribed purpose. The end sought to be achieved, being distribution and promotion of the GMS apps, does not involve any harm to the competitive process.
3467 Second, even if I were to accept Epic’s submission as to Google’s purpose, that is also not a proscribed purpose. Much of what Epic has said about Google’s purpose is really a claim about Google’s motive, which is not the relevant inquiry.
3468 In any event, I agree with Google that what Epic says was the end sought to be achieved by the conduct did not involve any harm to competition. Even as characterised by Epic, the conduct was not directed at preventing or hindering apps or rival app stores from being pre-installed or given favourable placement on Android devices. It was not directed at preventing competition from any app store. App stores are free to compete.
3469 Third, it may be accepted that the manifest effect of a provision in an agreement may be the clearest indication of its purpose, but that observation does not assist Epic.
3470 I agree with Google that Epic has not demonstrated that the competitive process has been harmed by the pre-installation and placement provisions of the MADAs, including because those provisions have not foreclosed rival app stores being pre-installed and given equal or superior placement to the Play Store.
3471 So, there is no anti-competitive effect from which a proscribed purpose can be inferred. Let me elaborate further on the effect question.
Do aspects of the MADAs have an anti-competitive effect?
3472 Let me begin by setting out Epic’s case on this aspect.
3473 Now Google insists that all OEMs who wish to distribute GMS Android must sign a MADA whose terms oblige the OEM to pre-install the Play Store on the DHS of every Android device it distributes.
3474 Epic says that these terms ensure that the Play Store is the only Android app store with global reach outside of China, and maximise the prospect that Android device users will continue to choose the Play Store rather than any alternative Android app store. They ensure that the Play Store is pre-installed in the most prominent location on most Android devices globally outside of China.
3475 Further, the DHS is the premium, most valuable placement on an Android device because it maximises the discoverability of the app. It means that the Play Store will be seen more often and more readily than an app that is placed anywhere else on an Android device.
3476 Further, although users can remove the Play Store from the home screen of their device if they wish, the dominance of the Play Store within the Android ecosystem demonstrates that this does not occur to any significant extent.
3477 Further, as a result of the MADA Play Store pre-installation and DHS placement requirements, it is desirable, if not a requirement, for developers wishing to reach Android device users at scale to distribute their apps via the Play Store. This increases the attractiveness of the Play Store for users. This causes the network effects to compound and to reinforce the Play Store’s dominance.
3478 Further, Epic says that by reason of the MADA Play Store pre-installation and DHS placement requirements, the following occurs.
3479 The Play Store is installed on virtually all Android devices globally outside of China, whereas it is not practicable for any other app store to achieve anything close to commensurate reach. No other app store has done so.
3480 Further, the Play Store is more discoverable than any rival Android app store. Being installed on virtually all Android devices means that more users will see the Play Store than will see any rival. Most of the time, a rival Android app store will have to rely on advertising or word of mouth to be discovered by Android device users.
3481 Further, no other Android app store can ever be the only app store pre-installed on the DHS of an Android device. The best that any rival can hope to achieve is to be pre-installed with the Play Store.
3482 Further, Epic says that whilst it is possible for a rival Android app store to also obtain DHS placement, it will only be able to do so on a fraction of Android devices, with the sole exception of Samsung, which will still in practice be limited to less than half of Android devices globally.
3483 Let me say something about Epic’s case concerning the relevant counterfactual.
3484 Epic says that removal of the MADA Play Store pre-installation and DHS placement requirements will mean that OEMs have the freedom not to pre-install the Play Store or to demote the Play Store from the DHS. It says that this has at least five consequences likely to enhance competition.
3485 First, OEMs would be able to invest in and promote their own app stores in ways that have not been worthwhile given the MADA restrictions.
3486 In circumstances where the Play Store has made billions of dollars from Android app distribution year after year, at least some OEMs are likely to attempt to secure some of this revenue for themselves once the contractual fetters have been removed.
3487 Second, deals between OEMs and third-party app stores are more likely. The ability to compete for premium placement on the DHS and for pre-installation exclusivity improves the commercial proposition for a third-party app store.
3488 So, OEMs may consider that they can negotiate better terms with third-party app stores than they have been able to achieve to date.
3489 Indeed, the fact that Google licences GMS Android in exchange for pre-installation and placement requirements is evidence that these are valuable rights which OEMs are likely to be able to exploit in a variety of ways absent the restrictions.
3490 Third, whether it is a third-party app store or an OEM app store, the ability to attract a greater number of users via DHS placement is likely to provide that app store with the commercial incentive to invest and innovate in ways that they have not done to date. So, they may seek to differentiate themselves from the Play Store by means of the way that users search for apps, the particular apps available, differentiated developer content, or a range of other dimensions. The emergence of specialised app stores is also a possibility.
3491 Fourth, if OEM or third-party app stores begin to be pre-installed on the DHS of Android devices with the Play Store either absent or demoted to another screen, then developers are more likely to seek to distribute their apps through those OEM or third-party app stores.
3492 Fifth, even if OEMs choose not to pre-install rival Android app stores, or remove or demote the Play Store, the option to do so would improve OEMs’ negotiating position vis-a-vis Google and thereby increase the competitive pressure on the Play Store.
3493 It would mean that Google would be required to ensure that OEMs pre-install the Play Store by reason of the Play Store’s quality relative to its competitors, rather than because they have no choice.
3494 In other words, the threat that OEMs could make other choices would itself expose the Play Store to competition in a way to which it has never been exposed.
3495 The Play Store would find itself subject to a dynamic process generated by market pressure from alternative sources of supply and the desire to keep ahead.
3496 In general, Epic says that each of these consequences would likely result in a greater degree of rivalry, as well as increased incentives and opportunities for rival app stores to invest, innovate and grow within the Android mobile app distribution market.
3497 Now Professor Asker said that in a counterfactual world without the pre-installation and DHS placement requirements imposed under the MADA, there are two likely possibilities. He said that either nothing changes between the but for and actual worlds, or the but for world would have a worse competitive process than the actual world.
3498 Professor Asker said that the former possibility emerges if Google is permitted to pay OEMs to pre-install and place the Play Store on the DHS of their devices.
3499 Professor Asker said that the latter possibility emerges if Google is not permitted to incentivise pre-installation and placement.
3500 Professor Asker concluded that the consequence of these two likely possibilities was that the MADA restrictions do not have any detrimental effect on competition.
3501 Now as to the first scenario where it is said that nothing would change between the but for and actual worlds, Epic made the following points.
3502 Professor Asker’s view that the counterfactual does not differ from the factual is premised on his view that absent the pre-installation and placement restrictions in the MADA, it is highly likely that Google would implement a monetisation strategy that uses a combination of incentives and disincentives to recreate outcomes in the actual world, assuming it is permitted to take that course.
3503 Specifically, he considered that Google would offer OEMs a per-device payment to pre-install the Play Store and place it on the DHS, and charge OEMs the same price to license its GMS apps.
3504 The result is that any OEM that chose to pre-install all GMS apps and the Play Store and place the Play Store on the DHS would have a net zero payment flow and achieve the same outcome as in the actual world.
3505 Unsurprisingly, given the net zero outcome created by this combination of incentives and disincentives, Professor Asker concluded that it is highly likely that OEMs would choose to recreate the actual world for almost all Android phones.
3506 Now Epic said that there are three problems with Professor Asker’s conceptual approach.
3507 First, rather than considering all realistic futures with and without the restrictions in the MADA, Professor Asker identified a single commercial strategy that he described without evidence as likely to be pursued by Google in the counterfactual, and then assessed that strategy against the factual. But in assessing the nature and extent of competition in a market with and without the impugned conduct, one must have regard to all commercially realistic counterfactuals, rather than just one or two.
3508 Second, Professor Asker’s conclusion that it is highly likely Google would implement his proposed monetisation strategy in the counterfactual is speculative. There is no evidence from Google to support that conclusion.
3509 Third, what Professor Asker identified as highly likely to occur is in fact unlikely to occur.
3510 Epic says that it would not be open to Google to offer OEMs a combination of incentives and disincentives in the counterfactual that have the purpose and effect of foreclosing an equally efficient app store from being pre-installed on OEMs’ devices, or placed on the DHS, whether exclusively or as an available option.
3511 The premise of the counterfactual is that while Google is entitled to monetise its investment in GMS Android, it is also required to comply with Australian competition law. So, it is not entitled to engage in conduct for the purpose of foreclosing competition. Professor Asker’s description of Google’s likely monetisation strategy in the counterfactual would amount to impermissible foreclosure.
3512 Clearly, when identifying commercially realistic counterfactuals it is not appropriate to postulate the existence of unlawful acts on the part of the party whose conduct is impugned.
3513 Further, Professor Asker also sought to justify his conclusions on the basis that in the counterfactual, OEMs would likely continue to have the incentive to pre-install the Play Store and place it on the DHS of devices because consumers like and expect to have the Play Store on their phones.
3514 But Epic says that this treats the counterfactual as if it were an all-or-nothing proposition, with only one likely outcome. There is no basis to conclude that there is only one real chance or commercial likelihood in a future without the conduct, let alone that it is Professor Asker’s postulated scenario.
3515 Moreover, Epic says that one should not accept the premise that there will be no demand for alternative app stores to be pre-installed on Android devices. App stores may emerge in the counterfactual that are equal to the Play Store in quality, or at least relevantly differentiated, such that some users perceive them to be of higher quality than the Play Store, or more relevant to their interests. Some may offer lower prices.
3516 Epic says that once these possibilities are recognised, it follows that there is a real commercial likelihood that the counterfactual world is one in which user demand is not such as to drive all OEMs to continue to pre-install the Play Store and place it on the DHS of all their devices.
3517 The mere threat that the Play Store might not be pre-installed or given a premium placement is enough to meaningfully impact the competitive process, because the option to remove or demote the Play Store would improve OEMs’ negotiating position vis-a-vis Google and thereby increase competitive pressure on the Play Store.
3518 Now as to the second scenario where it is said that the counterfactual world is likely to have a worse competitive process than the actual world, Epic made the following points.
3519 Professor Asker’s second alternative is premised on the assumption that in the counterfactual, Google is not permitted to pay or otherwise compensate OEMs in any way to pre-install the Play Store, or require that OEMs pre-install and place the Play Store to license other GMS apps. Making that assumption, Professor Asker said that OEMs would likely exclusively pre-install their own app stores to avoid risking the Play Store cannibalising their own app store. Epic says that there are four reasons why that assertion should be rejected.
3520 First, no one has said that Google would not be entitled to compensate OEMs for pre-installation and placement of the Play Store in the counterfactual.
3521 Second, not all OEMs have their own app stores. Motorola and Sony do not have their own app stores. And those that do have their own app stores may want to pre-install specialist app stores that complement their own offering or that have differentiated content.
3522 Third, the evidence contradicts the assertion that OEMs would likely exclusively pre-install their own app stores in the counterfactual.
3523 Epic made arrangements to pre-install the Epic Games app on OnePlus and Sony devices, only for Google’s RSA3s to prevent those plans.
3524 Further, in February 2018, Google employees internally estimated potential revenue impacts on the Play Store if Epic launched the Epic Games Store on Android. Google thought that there was a real commercial likelihood of deals being struck between Epic and OEMs to pre-install the Epic Games Store, even in the factual.
3525 Fourth, even if OEMs were to exclusively pre-install their own app stores, it does not follow that such a world is not more competitive than the factual. App store fragmentation is pro-competitive.
3526 In general, Epic says that I should reject Professor Asker’s assertion that the counterfactual world absent the MADA restrictions would either simply reflect the factual or result in worse competitive outcomes.
3527 Let me deal with another topic concerning Professor Asker’s asserted pro-competitive benefits.
3528 Professor Asker said that the contractual restrictions in the MADA are necessary in order to address the co-ordinated adoption problem in respect of the Play Store, to prevent app store fragmentation and to ensure a consistent out-of-the-box experience.
3529 But Professor Asker said that a counterfactual world absent the restrictions in the MADA is the same as the factual. But if that were so, Epic says that it could not be said that the MADA restrictions are necessary to achieve pro-competitive ends. Nevertheless, Epic said the following concerning each of the putative benefits.
3530 First, Professor Asker’s co-ordinated adoption problem, also referred to as the chicken-and-egg problem, arises when potential users will not adopt a new multi-sided platform unless other users also adopt it, on the same and other sides. In the present context, this problem describes the need for the Play Store to have a substantial number of users to attract developers and vice versa.
3531 Now Epic says that the co-ordinated adoption problem is a challenge for new entrants. To the extent that it was faced by the Play Store, it has long since been overcome. The Play Store accounted for 97.9% of downloads via Android app stores in Australia in 2020. It benefits from strong network effects rendering the co-ordinated adoption problem inapplicable. This is borne out by Google documents.
3532 An April 2017 Google presentation titled Amazon Competitor deep dive – Apr. 2017 noted that “Play benefits from network effects. Users come to Play because we have by far the most compelling catalogue of apps / games … games developers come to Play because that’s where the users are”.
3533 Contrastingly, a September 2014 Google presentation titled Project Gabby noted that other third party app stores suffered from the “chicken and egg problem: not enough eyeballs to get the catalog, didn’t have the catalog to get the eyeballs”.
3534 Now Professor Asker said that the co-ordinated adoption problem is an ongoing problem for Google, and presented cautionary tales of platform failure due to overlooking this problem. But the platforms cited by Professor Asker failed due to being replaced by a superior, more innovative product. For example, the primary reason that Symbian failed was that better products came to market, namely Android and iOS. In Ms Kochikar’s words, “Symbian was designed for mobile phones before they became computers”; and “[t]hings went from consumer electronics to computing, and computing is a different paradigm”.
3535 More generally, the failure of a platform by reason of the emergence of a superior, more innovative product is competition in action.
3536 Second, Professor Asker said that the MADA restrictions are a means of supporting Google’s efforts to mitigate app store fragmentation.
3537 Professor Asker described app store fragmentation as arising when no single app store publishes a comprehensive set of Android apps and no single app store is generally available on all Android devices.
3538 Professor Asker said that the MADA requirement to pre-install the Play Store on all GMS devices helps to mitigate this problem by ensuring that a single app store with a complete catalogue of content is available on nearly all Android devices.
3539 But Epic said that what Professor Asker referred to as app store fragmentation is properly characterised as competition and product differentiation in app distribution.
3540 Competitive markets are necessarily more fragmented than a monopoly market. Similarly, product differentiation is not necessarily harmful to competition. It is part of the competitive process and a way in which competitors respond to differences in consumer tastes. As a result, it tends to increase variety and customer choice, which is itself a benefit to consumers.
3541 App store fragmentation can enhance competition within Android. There is no evidence of any harm to competition from app store fragmentation on PC or MacOS.
3542 Finally, Professor Asker said that the MADA ensures a consistent out-of-the-box experience for Android smartphone consumers.
3543 What was in essence being said was that if a mobile ecosystem, such as Android, comprises devices that do not have a consistent baseline level of experience and functionality out-of-the-box, it is unlikely to remain competitive with other mobile ecosystems such as iOS.
3544 But Epic says that in the counterfactual, OEMs would be incentivised to achieve a high-quality and desirable out-of-the-box experience to sell their devices to users. OEMs are unlikely to harm themselves by differentiating their own devices in such a way that makes them undesirable.
3545 If the Play Store is the most desirable and highest quality Android app store, OEMs may well choose to keep it on the DHS of their devices because this will satisfy consumers. But this would be the result of competition on the merits, rather than being imposed by Google’s OEM restrictive conduct. If not, they may choose other options.
3546 So, Professor Asker’s so-called problem is solved by competition, rather than by Google being the arbiter of what each Android device user’s out-of-the-box experience is.
3547 So, the apparent benefit referred to by Professor Asker is a benefit for Google, not for the competitive process. And if such a benefit existed at all, it would arise in a different market, being the smartphone market.
Analysis
3548 In my view, and for the reasons that Google has largely given, the pre-installation and placement provisions of the MADA do not have the effect or likely effect of substantially lessening competition because those provisions are non-exclusive and do not foreclose the pre-installation or placement of other apps or app stores.
3549 As Google says, the MADAs are expressly non-exclusive and provide that OEMs remain free to install their own apps or third-party apps on their devices.
3550 Further, the MADAs also expressly provide that they do not limit the placement of the OEM’s own apps or any third party apps, subject only to complying with the placement obligations to Google under the MADAs.
3551 Further, as Google says, the placement requirements in respect of the GMS apps do not practically foreclose OEMs granting other apps including app stores the equivalent or superior prominence or placement to Google apps, including the Play Store.
3552 Moreover, OEMs can and do pre-install alternative app stores to the Play Store on the DHS of Android devices.
3553 Since February 2019, Samsung devices in Australia, which accounted for 67% of active devices, were shipped with the Samsung Galaxy Store pre-installed on the DHS. And on Samsung devices, the default position of the Samsung Galaxy Store is even more prominent than the Play Store, in that it is the first application icon from left to right on the home screen. That is particularly significant in circumstances where a substantial majority of active Android devices in Australia are Samsung devices.
3554 I agree with Google that the approach adopted by Samsung demonstrates that the pre-installation and placement provisions of the MADA do not prevent or hinder OEMs from pre-installing rival app stores on the DHS, or giving those stores prominence equal to or greater than that given to the Play Store.
3555 Further, as Google says, there is no evidence that any rival app store has ever been prevented or hindered from obtaining pre-installation or DHS placement on Android devices by reason of the MADAs.
3556 Indeed, as Google points out, Epic’s own experience demonstrates that it was able to obtain pre-installation deals with numerous OEMs.
3557 In August 2018, Epic entered into a collaboration agreement with Samsung in relation to the distribution of Epic’s apps on Samsung devices. Under the collaboration agreement, Samsung agreed to use commercially reasonable efforts to make the “Fortnite Launcher” and “Fortnite” available to users by pre-installing a “stub” on specified Samsung devices. Samsung also agreed that should Epic make the Epic Games app generally available to users of Android devices during the initial three year term of the collaboration agreement, Samsung would distribute a stub of the Epic Games app on specified Samsung devices.
3558 Now the Epic Games app contemplated by the agreement was an app store. Epic Games app was defined to mean “any updated version of the Fortnite Installer… that includes app store functionality such as app installation, app update, display and curation”. The collaboration agreement contemplated that the Epic Games app would offer users both apps developed by third party developers and apps developed by Epic.
3559 Further, clause 8.1 of the collaboration agreement provided for revenue sharing between Epic and Samsung in respect of in-app purchases in apps downloaded from the Epic Games app. So, where users made purchases in an app distributed by the Epic Games app, Epic would pay a revenue share to Samsung where users accessed the Epic Games app via the pre-installed stub on their Samsung device. The agreed share was that Samsung would keep [REDACTED] of net revenue for in-app purchases in apps downloaded from the Epic Games app in the first 18 months of the collaboration agreement, and [REDACTED] thereafter.
3560 So, the practical effect of the collaboration agreement was that Epic secured a pre-installation deal with Samsung in respect of its own rival app store.
3561 Now admittedly, what was pre-installed was a “stub”, rather than the Epic Games app itself. But I agree with Google that that is an inconsequential distinction given that it appears to have been Mr Sweeney’s strategy to negotiate with OEMs and carriers for the pre-installation of “stubs”. Mr Sweeney said that users who download the Epic Games app via the pre-installed stub on Samsung devices do not encounter any security warnings.
3562 So, as Google correctly points out, Epic’s own experience is that it is commercially realistic to secure the pre-installation of a rival app store with an OEM. And as Google says, it is significant that that OEM was Samsung, which was the largest OEM by number of Android devices and an OEM that pre-installs its own proprietary app store on its devices.
3563 Now Epic has pointed to a March 2019 Google presentation titled Project Banyan // PM – HL in which the author’s assessment was that Samsung had an allergy to having three Android stores preloaded on their devices because of user experience issues. But Samsung’s actions in agreeing to the collaboration agreement demonstrate that Samsung apparently has no allergy to having a third app store on its devices, at least in circumstances where that app store is willing to enter into a revenue sharing agreement with Samsung.
3564 Further, as Google says, Epic’s success in negotiating pre-installation with Samsung was also not an isolated case. Epic successfully negotiated pre-installation deals in respect of the Fortnite installer or Epic Games installer with each of Huawei, LG and Sony.
3565 So it would seem that the pre-installation and placement provisions in the MADAs have not prevented or hindered the pre-installation of apps, including rival app stores.
3566 Further, I agree with Google that Epic’s effects case with respect to the pre-installation and placement provisions of the MADAs also fails because it has not demonstrated that there is or at any relevant time was a real commercial likelihood of increased competition in a future without the pre-installation and placement provisions.
3567 Epic says that in the absence of the pre-installation and placement requirements for the Play Store, OEMs would exercise more choice over, first, whether to remove or demote the Play Store, second, whether to pre-install rival app stores and, third, where to place the icons for app stores on Android smart mobile devices.
3568 But as Google says, the mere existence of such choice is insufficient because it does not establish that there is a commercially realistic likelihood that OEMs would exercise that choice in a way that would involve any substantial increase in competition relative to a future without the provisions.
3569 I agree with Google that Epic has not shown that OEMs would make different decisions or that any change would constitute a substantial lessening of competition.
3570 It is also notable, in relation to Epic’s contentions about what OEMs would do in the absence of the MADA’s pre-installation and placement requirements, that Samsung, which accounts for 67% of devices of active Australian devices, already pre-installs the Galaxy Store on those devices and does so in a more prominent manner than the Play Store.
3571 Now to assess whether conduct has the effect or likely effect of substantially lessening competition, it is insufficient simply to identify that OEMs would have additional choice in the counterfactual. What is required is an assessment of how OEMs would realistically exercise such a choice.
3572 Without an assessment of what the likely or realistic but for market outcomes would be, I cannot reach any view as to whether competition is lessened relative to such market outcomes.
3573 Epic has adduced no evidence to suggest that there is a real commercial likelihood that OEMs would elect not to pre-install the Play Store on the DHSs of their devices if given greater choice to do so.
3574 Now it is not sufficient in a competition case to assess competitive effects by reference to mere speculative possibilities without any evidentiary foundation.
3575 I agree with Google that Epic has failed to prove that there would be any commercially realistic possibility that OEMs would act differently in the absence of the pre-installation and placement terms in the MADAs.
3576 Further, there is no evidence to suggest that any rival app store has ever sought, or would ever seek, exclusive pre-installation on the DHS of any Android device, in circumstances where OEMs would seriously countenance such a proposal.
3577 I agree with Google that the notion that some unidentified third-party app store might seek an exclusive DHS pre-installation and placement deal in the future, and that OEMs might seriously countenance such an arrangement, is both speculative and improbable.
3578 Further, as Google legitimately hypothesised, consider what would occur in a future without the pre-installation and placement provisions as a matter of real commercial likelihood.
3579 In a future where OEMs could choose whether to display the Play Store icon and where to place it, OEMs would have a strong incentive to pre-install the Play Store on their devices. Clearly, OEMs have an incentive to pre-install app stores that make their devices more attractive to consumers. And clearly, in choosing whether to pre-install the Play Store, an OEM would take into account whether or not it would sell any phones at all or sell a reduced number of phones if those devices did not have the Play Store on them.
3580 In those circumstances, I agree with Google that there are strong reasons why OEMs would, as a matter of commercial reality, likely continue to pre-install the Play Store in the counterfactual.
3581 First, the Play Store has been throughout the relevant period the leading app store on Android. It has provided the largest range of apps, with over two times the number of apps of the next largest store on Android. It offers discovery features that are likely to be attractive to users. So, an OEM that did not have the Play Store pre-installed on its devices would risk making a phone that does not meet user preferences. Now I should say here that Epic would say that this reputation has all been brought about by Google’s misuse of market power. But I have not accepted many aspects of that case.
3582 I agree with Google that the commercial reality is that in the interests of creating a consistent out-of-the-box experience across Android, it is unsurprising that there be some stipulation as to what that consistent experience will be. The MADA achieves that. That consistency benefits the participants in the Android ecosystem as a whole, by facilitating greater competition between OEMs by making it easier to move between OEMs’ Android devices.
3583 Second, in any event, in the absence of the MADAs, Google would remain free to compete on the merits to secure pre-installation and placement deals with OEMs by offering OEMs better prices or better quality. Google has powerful incentives to make such offers to OEMs given the value it derives from pre-installation and placement on Android devices.
3584 In my view, in summary, Epic has not made out its case concerning an effect or likely effect of substantially lessening competition.
The revenue share agreements including the RSA3s and MIAs – general
3585 Epic says that the terms of Google’s RSA3s disincentivised OEMs from distributing an Android device with any pre-installed app that was substantially similar to the Play Store. Epic’s complaint relates to certain terms contained in the RSA3s relating to Google’s Premier tier devices.
3586 In 2019, Google began offering the RSA3s under the Premier device program, which offered participating OEMs incentives for configuring devices as Premier devices, including the following incentives. Google offered a higher percentage of Search revenue as compared to other categories of devices. Google offered a percentage of Google’s revenue from the Play Store transactions on Premier devices, which was not payable on other categories of devices. And Google offered other financial incentives, such as monthly bonuses, for certain OEMs.
3587 Now for a device to be configured as a Premier device and qualify for the revenue payments, it had to meet various requirements including the following.
3588 The device could not include any service that was substantially similar to the Play Store, nor any application, service, icon, launcher, over the air prompt or functionality that had the primary purpose of providing access to any service that was substantially similar to the Play Store. Further, the icon for the Play Store had to be placed on the default home screen (DHS) and the Play Store had to be set as the default marketplace for applications, games, books, movies, music and all other digital content including subscriptions. Moreover, the device could not pre-install any app that was substantially similar to the Play Store, or any launcher, over the air prompt or functionality that had the primary purpose of providing services substantially similar to the Play Store. Further, the device could only pre-install apps that were available on the Play Store , which did not overlap with the functionality or features of the Play Store, and did not include privileged install permissions. So, any pre-installation of non-Google apps had to be those apps which were available on the Play Store and which did not contain privileged install permissions except for an app owned by the OEM or certain carriers. Further, the device could not allow the OEM or any third-party to promote, introduce or suggest to a user any service that was substantially similar to the Play Store.
3589 Further, in 2020 Google entered into mobile incentive agreements (MIAs) with Motorola and LG which entitled each of these OEMs to monthly payments and bonuses in respect of revenue generated from “Foundation devices” and Premier devices configured to include the requirements that I have just described.
3590 Generally, Epic’s case is that the RSA3s discouraged OEMs from pre-installing any app which was not available on the Play Store, including an alternative app store. And it is said that the RSA3s incentivised OEMs to set the Play Store as the “default” app store on Android devices, including on the home screen.
3591 It is said that the RSA3s prevented or hindered OEMs from distributing Android devices which did not have the Play Store pre-installed and placed on the device’s DHS, or which did not comply with the CDD or GMS requirements.
3592 It is said that the RSA3s prevented or hindered app developers from distributing alternative app stores, or other Android apps through pre-installation, direct download or through an alternative app, and from making alternative app stores’ apps equally discoverable on the devices, relative to the Play Store.
3593 Ultimately, Epic says that these matters either individually or cumulatively with other pleaded agreements had the purpose, effect or likely effect of substantially lessening competition in the Australian Android app distribution market.
3594 Let me turn to the relevant facts and the agreements and begin by saying something about the standard RSAs before I turn to the RSA3s.
Standard RSAs
3595 Now I should note at the outset that it was not mandatory for an OEM to enter into an RSA with Google. But most OEMs have done so. Indeed, in November 2021, about 97% of Android devices that were active worldwide excluding China were manufactured by an OEM that had an RSA with Google.
3596 Under a standard RSA, Google promised to pay the OEM a share of specified Google revenues, being essentially advertising revenues generated from Google Search results displayed on the OEM’s devices, in exchange for the OEM configuring its devices in particular ways. Such revenues were only payable in respect of Android compatible devices distributed by the OEM. Further, a standard RSA required the OEM to comply with its MADA. Google would not enter into an RSA with an Android OEM unless it agreed to be bound by a MADA.
3597 In this way, it does not seem to be in contest that standard RSAs incentivised OEMs to comply with the ACCs, the restrictive terms imposed under the MADA including the requirement to pre-install the Play Store on the DHS, and the technical restrictions.
3598 The RSAs were a carrot which enticed OEMs to sign and abide by those agreements. They incentivised the distribution, pre-installation, and placement of Google’s apps within the Android ecosystem.
3599 In an email dated 24 January 2019, Mr Gennai described MADAs and RSAs as principally app distribution contracts and incentives and went on to refer to the RSAs as “a financial exchange for enhanced visibility of our applications” and said that they were used “principally to solve Google problems”, which were identified earlier as including “[h]ow a user experiences Google on their device (preload, placement, exclusivity, etc.)”.
3600 Now in cross-examination, Mr Gennai denied that the purpose of the RSAs and the MADAs was to have Google’s own apps widely distributed throughout the Android ecosystem, despite having written that they were principally app distribution contracts and incentives. Mr Gennai conceded that that was an important purpose of the MADAs. But he denied that an important purpose of the RSAs was to obtain wide distribution of Google’s apps. I do not accept Mr Gennai’s spin.
3601 Let me turn to the RSA3s.
RSA3s
3602 Now from the start of the relevant period until mid-2019, RSAs do not appear to have contained specific requirements relating to the Play Store or to have provided OEMs with a share of revenues generated through the Play Store.
3603 But by late June 2019, Google had developed and its business council had approved what has been described as the Google Distribution on Android Framework (GDAF). RSAs were then modified in accordance with the GDAF. The modified versions have been referred to within Google and by the parties before me as RSA3s.
3604 At least six of the selected OEMs subsequently entered into an RSA3, each of which had a term of either two or three years.
3605 By August 2022, 39% of all new device activations globally excluding China were covered by an RSA3, increased from only 9% in 2020. Some 65% of those devices were classified as Premier tier devices.
3606 Now the GDAF provided for three tiers of Android device configurations, with each tier being more prescriptive than the last, and with OEMs being entitled to receive the greatest share of Google revenues in respect of devices configured as Premier tier devices.
3607 Under the RSA3s, Google promised OEMs who configured their devices as Premier tier devices a greater share of Google Search advertising revenues generated from those devices and, for certain OEMs, a share of Play Store revenues.
3608 For a device to qualify as a Premier tier device under an RSA3, OEMs were required to configure the device in accordance with the requirements that I have previously described.
3609 Now from 31 July 2020, the Premier device program requirements document relevantly provided that all Premier devices had to adhere to the requirements described in the CDD and the GMS requirements. It was further provided that a Premier device could only pre-install an app that was available on the Play Store, that did not overlap with the functionality or features of the Play Store, Chrome, Google Search, and other specified GMS apps, and that did not contain privileged install permissions, which is a concept and functionality that I have discussed elsewhere.
3610 Additionally, the RSA3s provided that the OEM had to remain in compliance with its MADA and that the RSA3 would automatically terminate if that MADA was terminated for any reason.
3611 So, through the MADAs, OEMs were required to pre-install the Play Store. And through the RSA3s, Google incentivised OEMs to refrain from pre-installing any other app store or any app at all that was not already being distributed through the Play Store.
3612 Now I accept that the provisions of the RSA3s must be read as a whole to obtain a complete and objective understanding of the impugned conduct.
3613 As I have said, an RSA3 provides the OEM with a share in Google’s revenues, being a share in Google’s Search advertising and/or Play Store transaction revenues on their devices, in exchange for the OEM’s promotion of Google Search, the Play Store and Google Assistant on those devices.
3614 In more specific terms, in addition to the Basic tier requirements applicable to all devices under the terms of RSA3s, OEMs were provided with a choice, on a device-by-device basis, to configure Android devices as either Optimized devices under the “Optimized tier” or “Tier 2”, or Premier devices under the “Premier tier”.
3615 The RSA3s make plain that an OEM who chooses to enter into the agreement is under no obligation to configure any Basic tier device so that it meets the additional requirements of an Optimized tier device or a Premier tier device. This freedom for OEMs is significant.
3616 Participation in an RSA3 was voluntary. And even if an OEM entered into an RSA3, they remained free to negotiate alternative arrangements with rival app stores on those devices that they chose not to configure as Premier devices.
3617 Further, even if OEMs chose to configure devices under the Basic tier or the Optimized tier, they remained free to pre-install alternative app stores to the Play Store, given that there was no requirement to exclusively pre-install or promote the Play Store on these devices.
3618 Now to qualify a device under the Basic tier, OEMs had to meet three requirements. First, there were certain setup requirements, including the implementation of an appropriate client ID on the device. Second, there were service access point requirements, including setting the default home page/start page and new tab page for pre-installed browsers and search intents to google.com or, if applicable, the relevant country’s local Google domain, and placing a Google-provided widget on the DHS. Third, there were basic device configuration requirements, including not enabling any alternative supportive service on the DHS or “minus one” screen and retaining the initial factory settings for preloaded Google apps, including not prompting or promoting a user to change these settings.
3619 Now none of these requirements included the exclusive pre-installation or promotion of the Play Store on the Android device.
3620 Further, subject to meeting those requirements, OEMs were eligible for the payment of, for example, [REDACTED] net ad revenue, where an Optimized tier was available under the RSA3, or [REDACTED] net ad revenue, where an Optimized tier was not available under the RSA3, generated from ads displayed on a results page for these Basic tier devices.
3621 As such, Google did not confine payments to devices designated under the Premier tier only. Instead Google extended them to Basic tier devices for which OEMs were free to pre-install alternative app stores.
3622 Now to qualify a device under the Optimized tier or Optimized tier A, OEMs had to meet the three requirements outlined above in respect of the Basic tier, together with the following additional requirements. First, there were additional service access point requirements. Second, there was a requirement not to enable an app which had the primary purpose of providing access to a service which was substantially similar to Google Search, Google Lens or Google Assistant, including on the DHS or “minus one” screen. Third, there was a requirement not to introduce, promote or suggest to an end user a substantially similar alternative to Google Search, Google Assistant or Google Lens. And fourth, there was a requirement to retain the default settings from the initial factory settings for preloaded Google apps, including Google Search and Google Assistant, and to not prompt or promote a user to change those settings.
3623 Further, some OEMs were also provided an additional choice of configuring devices under an Optimized tier B for Android devices distributed in Australia, which required them to comply with the matters set out above, together with further service access point requirements.
3624 Now as with the Basic tier, none of these requirements included the exclusive pre-installation or promotion of the Play Store on the Android device.
3625 Now subject to meeting these requirements, OEMs were eligible for up to [REDACTED] net ad revenue generated from ads displayed on a results page for these Optimized tier or Optimized tier A devices, and an additional [REDACTED] net Play Store transaction revenue generated from Play Store transactions for Optimized tier B devices.
3626 Let me turn to the matter of the Premier devices under the RSA3s, which are the crux of Epic’s case in this context. The Premier tier of revenue sharing was first introduced under the RSA3s.
3627 Now compared to the requirements under the Basic and Optimized tiers of the RSA3s, the Premier tier set out additional device requirements that an OEM had to meet in respect of device configuration, security and product development. But in exchange, OEMs were provided with an increased percentage of Google’s shared revenue as compared to Basic and Optimized tier devices, being [REDACTED] to [REDACTED] of net ad revenue and, for select OEMs, [REDACTED] to [REDACTED] of net Play Store transaction revenue.
3628 Now to qualify a device under the Premier tier, OEMs were required to meet the Premier tier provisions including the following aspects, the highlights of which I have already touched on.
3629 First, the Android device had to meet particular setup requirements, including the utilisation of Google Assistant and Google Search on nominated search access points like the Chrome browser and all search intent actions or requests.
3630 Second, the Android device could not include any application or functionality which had the “primary purpose of providing access to any Alternate Service.” This was defined to include a service that was substantially similar to the Play Store.
3631 Third, as I have already said, the Android device could not introduce, promote or suggest to an end user a substantially similar alternative to the Play Store, Google Search, Google Assistant, or Google Lens.
3632 Fourth, as I have already said, the Android device could not include any pre-installed installers with silent install or updating privileges.
3633 Fifth, only those apps that were available on the Play Store could be pre-installed on the device.
3634 Sixth, the OEM had to, for a period of 24 months from the launch date of the device, upgrade specific portions of the device to the latest version of Android OS within a set time, being generally 120 days.
3635 Seventh, the OEM had to, for a period of 36 months from the date that the Android device was launched, implement security updates on the Premier device to ensure that a set proportion of those devices received security patches within 80 days. The OEM also had to inform Google of any stability problems or other problems with meeting this target. Notably, an OEM’s failure to complete the security updates could result in a reduction in their payment of revenue shares.
3636 Eighth, the OEM had to collaborate with Google to develop and optimise Android software and the Premier devices, including the technical development of the devices, testing and verifying devices and fixing bugs that may impact the performance of any Google products and services on the device.
3637 Now on 10 November 2020, Google entered into a version of an RSA3 with Samsung, but the Samsung RSA3 did not contain the Premier tier provisions. Further, as I have explained below, an MIA was entered into. Both of these agreements are still on foot.
3638 Google calculated that the total payment to Samsung over four years would be approximately USD 7.5 to 8.3 billion.
3639 Now I would note that nothing in the RSA3s restricted end users from installing or using alternatives to Google applications. And an end user was free to sideload any application onto their device.
3640 Further, OEMs could seek a waiver of any of the requirements contained in the RSAs. Google has in fact approved OEM requests for waivers to pre-install alternative apps, including the Fortnite installer.
3641 Let me say something about the MIAs.
The MIAs
3642 Now around the same time as the RSA3s were being rolled out, Motorola, LG and Samsung entered into MIAs with Google.
3643 The MIAs for Motorola and LG specified very similar Premier device requirements to those specified in the RSA3s.
3644 Those MIAs relevantly entitled Motorola and LG to a monthly incentive payment if a minimum percentage of their devices activated that month were Premier devices. The amount of that payment increased if the percentage exceeded higher thresholds. The greater the proportion of activated devices that were Premier devices, the greater the amount payable by Google. Motorola’s and LG’s entitlement to these incentives was conditional upon ongoing compliance with their MADAs.
3645 Now as for Samsung, throughout the relevant period it has been a party to an RSA, but not an RSA3. The first RSA was entered into in September 2017 and entitled Samsung to receive [REDACTED] of net advertising revenues earned from its devices, provided that Samsung complied with its MADA and AFA. But on 10 November 2020, Google entered into both a replacement RSA and an MIA with Samsung.
3646 The second RSA had a four-year term and contained relevantly similar terms to the first, although with varying revenue shares.
3647 The MIA had a four and a half year term and entitled Samsung to [REDACATED] [REDACTED] of between [REDACTED] of certain kinds of advertising revenues earned from Samsung devices. The MIA also entitled Samsung to a bonus payment.
3648 Now neither Samsung’s RSA nor its MIA entitled Samsung to a share of Play Store revenues and nor did the agreements impose restrictions on Samsung relating to the Play Store besides those prescribed in the MADA. The Samsung RSA and MIA made Samsung’s revenue share entitlements conditional upon Samsung complying with its MADA. Further, Google could terminate both agreements if the MADA was terminated.
3649 The Samsung agreements were in a different form to the RSA3s and the MIAs with Motorola and LG.
The RSA4s
3650 Now Google’s agreement with Motorola, which holds a small market share of Android devices, is the only RSA3 with an OEM that remains active, except for Google’s RSA3 with Samsung that never contained the Premier tier provisions.
3651 The Motorola RSA3 was amended effective 1 July 2023 to, in substance, extend the contract while seeking to modify its key product requirements to better align with those of the RSA4s with OEMs. This included the removal of the requirement not to pre-install a service that is substantially similar to the Play Store.
3652 Now the RSA3s with OEMs were superseded by a revised form of the MIAs or the RSA4s. The RSA4s provide for OEMs to promote Android devices in accordance with certain tiered configurations, in exchange for a share of ad revenue, the Play Store transaction revenue and/or bounty payments.
3653 From August 2022 Google has entered into RSA4 agreements with five other OEMs, namely Oppo / OnePlus, Xiaomi, Nokia, Sony and Vivo. The timing of these agreements post-dates litigation commenced by Epic challenging the legality of the Play Store exclusivity provisions in the RSA3 agreements.
3654 The RSA4 agreements generally take the form of a MIA. None of the configuration requirements under the RSA4 agreements prohibit OEMs from pre-installing an app that is substantially similar to the Play Store or promoting an alternative app store to the Play Store.
3655 Under their RSA4s, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
3656 Now whilst OEMs who choose to enter into an RSA4 for Android devices in Australia must comply with basic setup requirements under Basic Feature tier 1 to receive a bounty payment, they may on a device-by-device basis choose to earn, where offered to the applicable OEM, the following further amounts.
3657 First, they may earn [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
3658 Second, they may earn [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
3659 Third, they may earn [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
3660 Now as compared to the RSA3s, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
3661 Like the RSA3s, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
3662 Now the RSA4s do not contain the Premier tier provisions or any substantively similar provisions. The RSA4s are similar to the RSA3s except that they remove the requirement not to install any app store other than the Play Store and not to pre-install any app that is not available on the Play Store. Further, whilst there remains a requirement for preloaded apps to also be distributed via the Play Store, an exception is made for other app stores. As such, the provisions do not foreclose the pre-installation of rival app stores to the Play Store and the RSA4s do not contain those aspects of RSA3s about which Epic complains.
3663 Further, the continuation of payments without any obligation to exclusively pre-install the Play Store cannot mean that OEMs are disincentivised from preloading other app stores.
3664 That must be the case, even if OEMs are still receiving Play Store revenues. Those payments will follow under the terms of RSA4s even if an alternate app store is installed by the OEM.
3665 Now I accept that the RSA3 agreements have largely been superseded by the RSA4 agreements. The RSA4 agreements do not contain requirements prohibiting OEMs from pre-installing rival app stores. But Google continues to share Play Store revenues with certain OEMs under the RSA4 agreements meaning that OEMs’ incentives continue to be aligned with the Play Store’s success.
3666 Now Google did not call a witness with personal knowledge concerning the RSA4s. It would seem that the decision to switch from RSA3s to RSA4s may have happened after Mr Gennai left the Android team.
3667 Now Google says that the features of the RSA4s corroborate the purposes it has put in respect of RSA3s. In particular, Google says that its RSA4s reflect Google’s continued desire to deepen its partnership with OEMs to enhance the security, performance and the technical advancement of Android devices. This in turn further confirms Google’s desire to improve the attractiveness of Android devices to end users and, ultimately, to ensure that Android and the Play Store compete against iOS and Apple.
3668 Further, Google says that the fact that it continues to provide a share of its revenue to those OEMs who choose to partner with it in the enhancement and promotion of Android is significant as to purpose.
3669 Google says that the purpose of the Premier tier provisions could not have been to incentivise OEMs, through lucrative revenue shares payments, to refrain from pre-installing any rival app store to the Play Store. This is because the payments remained even in the absence of the Premier tier provisions.
3670 So, Google says that the evidence supports the notion that OEMs were not being paid to protect the Play Store. They were being paid to promote the whole of the Android ecosystem and to enhance the competitiveness of Android devices against iOS devices.
3671 But I agree with Epic that Google’s reliance on the RSA4s should be treated with scepticism given that no mention of their existence was made until after the trial began and no evidence was led as to the reasons that they were introduced.
3672 I have put the RSA4s question to one side. There are no relevant competition questions or consequences concerning the RSA4s that I need to deal with for present purposes.
3673 Let me proceed then to the competition questions concerning the RSA3s.
Do aspects of the RSA3s have an anti-competitive purpose?
3674 Google says that the RSA3s reflect the co-incident interests of Google and its Android OEM partners in ensuring consistent, high quality, secure and technologically advanced devices are available to end users, particularly outside of China, to compete with iOS devices.
3675 As such, it says that the RSA3s are pro-consumer and pro-competitive in nature, purpose and effect.
3676 Further, Google says that the impugned provisions of the RSA3s were applicable to only a small number of Android devices, where OEMs could choose, on a device-by-device basis, to configure a device in accordance with the requirements of those provisions.
3677 In any event, Google says that the impugned provisions have been superseded by the introduction of Google’s new mobile incentive agreements with OEMs being the RSA4s, which do not contain any restrictions on pre-installing rival app stores.
3678 Google expanded on its position by making the following points.
3679 Google made reference to the context and background to the RSA3s as set out in the October 2019 Google presentation titled Premium Devices Services Monetization.
3680 The presentation recorded that “Apple captures 75%+ of industry profits” (taking into account both hardware and software) and “key partners (Samsung, LGE, Lenovo) are struggling to keep up”. The presentation stated that “[w]ith the exception of Samsung, all other OEMs without a large China footprint (e.g. Lenovo, LG) have negative gross margins”. The concern expressed was that the poor financial health of the OEMs would have consequences for the Android ecosystem as a whole. They wrote that “Android OEMs fail to generate material services revenues; therefore, ecosystem health may be in jeopardy”.
3681 As set out in that presentation, Google perceived that Apple was capturing more than 75% of industry profits and that Android OEMs, and in particular non-Chinese OEMs, were struggling.
3682 The presentation discussed the reasons for this state of affairs, including that Android OEMs were failing to generate material services revenues such that the health of the Android ecosystem could be in jeopardy. The presentation observed that “[g]reater participation in Google Forward experiences could enable Google to share additional revenue with partners”. The same slide identified the required action as soliciting greater buy-in for Google Forward type experiences, with users also benefiting from superior user experiences and device performance, noting that committing to a “Google-forward” experience could reduce user confusion around duplicate app stores and services and that fewer pre-loads could also partially mitigate device performance impact on Google Search and YouTube revenues.
3683 RSAs were identified as enabling additional ways to further collaborate with partners, and as providing a mechanism to “help fund the ecosystem”. Three levels of experiences for partners were identified, including the “Google Forward” devices which would highlight Google’s apps and services working together, enhance safety and security with regular security patches, and deliver up-to-date devices with the latest features.
3684 So, the “Google Forward” experience was devised, being Premier devices providing a better user experience and supporting the ability for Android devices to compete against Apple devices and supporting OEMs with additional revenue in return.
3685 Google says that the true purposes of the Premier tier provisions in the RSA3s were both pro-consumer and pro-competitive in nature. They can be described as follows.
3686 It says that one purpose was to increase competition within the Android ecosystem by enhancing the ease of use, and ability to switch between, Android devices by configuring Premier devices consistently across brands.
3687 This purpose is demonstrated by clause 3.8 of the Premier device program requirements:
Premier requirements have been designed to ensure that Premier Devices are consistent in their core interaction patterns. The requirements are designed to provide enough flexibility to allow partners to express their brand and enable a visually coherent design across their product portfolio while enabling cross-device consistency…
…
* Premier Devices SHOULD be consistent across brands ... This is achieved through a consistent set of pre-loaded applications and the common structure of views such as Home screen, Notification shade, and Settings app.
* Premier Devices SHOULD be easy to use and switch between. This is enabled through consistent interaction patterns, consistent OS structure, and consistent application pre-loads
…
3688 It says that another purpose was to increase competition between Android and iOS through the following matters.
3689 First, one matter was to ensure that users enjoyed a consistent, premium quality and highly functional out-of-the-box experience with Android devices. Google intended that as a result of these qualities Android devices and the Android ecosystem more generally would remain competitive with, and reduce switching to, iOS devices. Indeed, in an undated presentation titled Android Marketing in 2021 Google recognised that “to win in the long run, we need to have preferred devices, not just affordable devices.”
3690 Second, another matter was to enhance the security, performance and technical advancement of Android devices. This was made explicit in the Premier tier provisions. It was said in the terms of the RSA3s that a failure to satisfactorily comply with the security requirements may result in a reduction in payment of shared revenue to the OEM.
3691 Google recognised that improved security and functionality, and the avoidance of hostile malware being installed, increased the attractiveness of Android devices to end users, which enhanced the competitiveness of Android OS and the Play Store as against Apple.
3692 This was part of Google’s reasoning to expand its partnership with more OEMs. That is, the payment of revenue shares was a means to encourage OEMs to collaborate with Google to develop secure and high-performing devices to compete against Apple.
3693 Third, another matter noted in an October 2020 presentation titled Android Commercial Agreements was to align “OEMs with Google’s vision of Mobile on Android” by providing incentives for OEMs to invest in developing high-quality Android devices and enhancing the overall Android ecosystem, including by providing them with a share of revenue.
3694 Such investment was necessary in circumstances where, in comparison to Apple, Google’s Android partners outside of China were “struggling to keep up” and were not generating significant revenues from the sale of low to mid-end products.
3695 The investment was also necessary in circumstances where the Play Store business was vulnerable and under increasing pressure given its heavy concentration across business models, geographies, users and developers. This jeopardised the health and viability of the Android ecosystem.
3696 It is in this context that the presentation seeking approval for the RSA3s stated that “ecosystem dynamics have changed and competition has increased.”
3697 Accordingly, Google’s provision of a portion of its revenue to OEMs was intended to help fund the ecosystem in terms of its growth and viability and facilitate a combination of services more attractive to end users. The overall objective and effect of this was to enhance Google’s ability to compete with iOS devices.
3698 Google says that none of these purposes were directed towards conduct which is anti-competitive in nature. Nor did the RSA3s have the effect, or likely effect, of substantially lessening competition.
3699 Google said that its purpose in relation to the RSAs was and is threefold.
3700 One purpose is to enable Google to compete for search promotion opportunities efficiently and effectively by providing a revenue incentive to OEMs in exchange for them promoting Google Search on their Android devices.
3701 Another purpose is to enhance usability and security by requiring OEMs to make security and operating system updates more frequently.
3702 Yet another purpose is to support OEMs with additional revenue.
3703 Google considers it necessary to support OEMs with additional revenue to ensure that the OEMs have sufficient incentives to invest in manufacturing Android devices.
3704 Now an issue within the Android ecosystem in recent years has been that OEMs have suffered poor and declining profitability, particularly because of competition with iOS. The following may be noted.
3705 In a 2016 Google presentation titled Android Overview, it was recorded that “iPhone 6 Doing Really Well” but “Key Android Partners Not Making Any Money …”. The same slide recorded that Samsung had reported increased phone shipments, but declining profitability, while LG had suffered a $67.8 million loss in its mobile division in the preceding three months.
3706 On 17 April 2018, Mr Richard Turner, director of Android platform partnerships at Google for Latin America, Europe, the Middle East and Africa emailed Mr Jamie Rosenberg and said:
…
I very genuinely think we face an existential threat from iPhone - they have won convincingly in premium already, if they take the mid-range it will be game over for Android as we know it. It’s simple economics - there is no money to be made at the entry level for OEM's, their only hope for profitable revenue now is in the mid-range.
…
3707 A May 2019 presentation titled Android 101, prepared by the Android Google Business team, stated that “[p]rofitability story remains challenging… may get worse over time”. The same slide indicated that LG had incurred a loss in its mobile business in each quarter from Q2 2016 to Q1 2019. It showed that Sony had incurred losses on its mobile business in FY2017 and FY2018, with a projected larger loss in FY2019. I have already referred to the October 2019 presentation.
3708 A May 2020 business council presentation titled Samsung Revenue Share Renewal in relation to the proposed Samsung RSA recorded that “Android share relative to Apple is continuing to decline in in (sic) $400+ tier in US/EEA and JP” and that “[c]ontinued trends result in losing [REDACTED] [REDACTED] across top markets to iOS annually”. It went on to state that, if the current trend of Android share loss to iOS was not reversed, “Google stands to lose [REDACTED] [REDACTED] in margin by 2024”. It also noted that “Samsung is falling further behind Apple as [Apple] is further leaning on services margin to re-invest in the product and GTM”. “GTM” in this context means “go to market”.
3709 Now the OEMs include some of the world’s largest equipment manufacturers, whose products include a wide range of consumer goods.
3710 Those developers do not need to manufacture mobile devices. They will only do so if the returns from doing so are judged to be more attractive than the other alternatives. So much is demonstrated by LG’s decision in April 2021 to exit the mobile phone market by 31 July of that year. In its 5 April 2021 press release announcing that decision titled LG To Close Mobile Phone Business Worldwide, LG said:
… LG Electronics Inc. announced that it is closing its mobile business unit. The decision was approved by its board of directors earlier today.
LG’s strategic decision to exit the incredibly competitive mobile phone sector will enable the company to focus resources in growth areas such as electric vehicle components, connected devices, smart homes, robotics, artificial intelligence and business-to-business solutions, as well as platforms and services.
…
3711 Notably it was the “incredibly competitive” nature of the mobile phone sector, together with the alternative capital investment options available to LG, that drove its exit.
3712 Google says that these matters are of significance for five reasons.
3713 First, it says that they reveal the nature of the commercial relationship between Google and the OEMs. Google is not properly characterised as a mere upstream supplier of software to OEMs. Rather, it engages with OEMs to support and financially incentivise them to manufacture, sell and promote Android compatible devices that are competitive with iOS devices, to the benefit of the Android ecosystem.
3714 Second, it says that the evidence does not demonstrate the existence of any inequality of bargaining power between Google and OEMs. Rather, it indicates that OEMs have alternatives to manufacturing Android devices. Google recognises this and pays revenue share to certain OEMs to ensure that there is sufficient incentive for them to continue to manufacture and market devices for the Android ecosystem.
3715 Google says that that is not conduct which is consistent with Google having market power in some mobile OS licensing market.
3716 Third, Google says that for both Google and OEMs, the competitive constraint imposed on Android by iOS is a serious threat.
3717 Google’s ordinary course of business documents reflect an ever-present concern about competition from iOS. In those circumstances, Epic’s suggestion that Apple and iOS do not closely constrain Google is at odds with commercial reality.
3718 The clearest picture of the relevant competitive process must account for and reflect the competition that exists between iOS and Android devices, and the manner in which that competition constrains Google in its dealings with both OEMs and developers.
3719 Fourth, Google says that its revenue sharing arrangements with OEMs cannot be characterised simplistically as agreements in Google’s self-interest. Those agreements serve larger purposes, including ensuring that OEMs have sufficient incentive to manufacture and market high quality Android devices that will appeal to users and prove competitive with iOS devices. Through the mechanism of indirect network effects, this is to the benefit of the whole Android ecosystem, including because it improves the universe of Android devices that developers can develop apps for.
3720 Fifth, it says that one cannot assume that the contractual provisions that Epic impugns can be removed without affecting the Android ecosystem as a whole.
3721 More generally, Google says that the practical and commercial effect of the conduct also does not support an inference that Google held the prescribed purpose.
3722 Contrary to the suggestion that the OEMs had no choice but to create Premier devices, Google says that OEMs could choose, on a device by device basis, whether they wished to configure a device in accordance with the Premier tier provisions.
3723 OEMs could choose to configure devices to the Basic or Optimized tiers, where exclusive pre-installation of the Play Store was not required. Many OEMs made that choice, and most devices were not designated Premier devices. This provision also left it open for OEMs to pre-install competing app stores for devices not designated under the Premier tier. This choice is at odds with an allegation of exclusive dealing, or a substantial purpose of shutting out rival app stores from access to Android devices.
3724 Further, Google provided a share of revenue payments on Basic and Optimized tier devices which did not include any requirements to exclusively pre-install the Play Store. That is, the payments were not limited to Premier devices or, by extension, exclusive pre-installation of the Play Store.
3725 Indeed, Google says that it was in its commercial interest to ensure that Android devices were in the hands of the maximum number of end users. That is because very early on, Google realised that to succeed in mobile devices, Google needed the ability to innovate, implement its app/service vision in a scaleable manner, and retain access to users.
3726 That reflects Google’s obvious commercial purpose for the RSAs, being the production of high quality, Google-forward devices and the enhanced visibility of Google applications on Android devices. But this does not result in or evidence anti-competitive conduct.
3727 And in addition to the matters related to security, the evidence suggests that the purpose of Google’s payment of revenue shares was not to ensure that OEMs did not pre-install any app store other than the Play Store.
3728 Further, Google could not have held the purpose of substantially lessening competition in circumstances where the Samsung RSA did not contain the Premier tier provisions. This is because, given Samsung’s share of Android devices in Australia, over two-thirds of Android devices would never have been affected by the provisions, and had an alternative app store pre-installed alongside the Play Store.
3729 Google also says that it could not have held the proscribed purpose in circumstances where it provided a waiver to Sony under the RSA3 to preload the Fortnite installer on its devices. As Google put the matter, if the end it sought to achieve was to hinder or prevent apps like the Fortnite installer from being installed on Android devices, why would it have granted the waiver? The grant of the waiver tells against the inference of any such purpose.
3730 Further, it is said that an anti-competitive purpose should not be inferred from Google documents which suggest that the RSA3s were to “protect Google” or that the revenue payments under the RSA3s were directed at achieving “platform protections” or to “protect” the Play Store. The use of colourful language must be read in context and is often the reflection of vigorous competition in action.
3731 Professor Hovenkamp, as quoted in Seven Network News Ltd v News Ltd [2007] FCA 1062 at [2490], said in H Hovenkamp, The Antitrust Enterprise: Principle and Execution (Harvard University Press, 2005) at 61:
In markets of every type sales personnel are urged to “destroy” or “kill” the competition or to sink new rivals before they have a chance. But this is nothing more than the rhetoric of competition, which anti-trust seeks to preserve …
3732 Further, Google says that its purpose in offering the RSA3s was pro-consumer and pro-competitive.
3733 Mr Gennai accepted that to some degree the RSA3s had the purpose of aligning the interests of OEMs with the Play Store. But he rejected the proposition that it was an important purpose of the RSAs to obtain wide distribution of Google’s apps throughout the Android ecosystem.
3734 Mr Gennai denied that Google’s agreement to share revenue with OEMs was to disincentivise them from preloading alternative app stores to the Play Store.
3735 Mr Gennai denied that Google’s strategy was to make it more difficult for third parties to distribute app stores within the Android ecosystem, such that developers thereby become dependent on the Play Store.
3736 Further, Professor Asker said that the Basic and Premier tiers of the RSA3s supported the use of revenue sharing to address the coordinated adoption problem suffered by mature platforms by providing incentives to OEMs to engage with, and invest in, the Android ecosystem. Professor Asker also said that, given the value placed by Google on supporting the Android ecosystem, he would expect Google to be able and willing to offer a significant and flexible payment. He noted that the basic RSA structure reflected this capacity.
3737 For these reasons, Google says that the Premier tier provisions and the RSAs more generally are an illustration of competition on the merits, directed towards outcomes which are both pro-consumer and pro-competitive.
Analysis
3738 Now in my view the purpose of the Premier tier provisions of the RSA3s was to substantially lessen competition in the Android mobile app distribution market by preventing or hindering the pre-installation of app stores other than the Play Store and ensuring that the Play Store remained the predominant supplier of Android app distribution services.
3739 I agree with Epic that this purpose can be inferred from Google’s conduct. Specifically, by entering into RSA3s with OEMs, Google ensured that OEMs would have no choice but to distribute Android devices, and refrain from pre-installing or promoting alternative app stores, by doing the following.
3740 First, Google required OEMs to comply with the MADA, including the requirement for pre-installation of the Play Store on mobile devices, as an express term of the RSA3s. That is, as a condition for any payments made under the RSA3s, OEMs were required to comply with the MADA.
3741 Second, Google incentivised OEMs to enter into RSA3s to receive lucrative revenue shares and to refrain from pre-installing any app store other than the Play Store.
3742 I agree with Epic that in this way, Google ensured that there were adverse financial consequences for OEMs that chose to distribute devices which did not have GMS Android pre-installed, which, in turn, prevented or hindered other app stores from competing and provided material protection to the Play Store against competitors.
3743 The June 2019 GDAF presentation titled “PEX & BC review: Google Distribution on Android Framework” that went to Google’s business council described the framework’s objective as being to protect Google from key strategic risks. It said that ecosystem dynamics had changed and competition had increased.
3744 So far as the Play Store and Android were concerned, the presentation highlighted that Chinese OEMs, which could not install GMS on devices distributed in China, had alternative stores preloaded on ~80% of Android devices, and had a meaningful overlap with the Play Store offering.
3745 The presentation also said that Huawei was “working on their own OS”; Samsung had “ramped up investments into their own store with S10 launch”; and “[i]f Play is less relevant for OEMs, MADA protections may be at risk (leading to higher TAC)”.
3746 The business council was asked to approve USD 2.9B in expenditure, being USD 141M more than the status quo, in 2020 alone, rising to USD 4.5B, being USD 600M more than the status quo, in 2023 across Google Search and the Play Store for carriers and non-Samsung OEMs to secure platform protections for Google Search, and the Play Store and critical apps protections on more devices.
3747 More specifically, it was asked to approve offering up to 16% Play Store revenue shares to OEMs, spending an estimated USD 35M in 2020 and up to USD 240M in 2023, in addition to the “bonus tier” of the standard RSAs, “to secure Play exclusivity, Android upgrades, and distribution for critical apps”.
3748 The GDAF presentation went on to state that the “Google Forward Tier”, that is, the Premier tier, “protects against Play risk with OEMs, complementing Hug and Banyan”.
3749 So, I agree with Epic that the RSA3s and MIAs were not introduced in isolation, but were part of a broader strategy to protect the Play Store against the risk of competition. That strategy also involved Project Hug and Project Banyan.
3750 The business council was told that Google “need[ed] to invest in Android OEMs to hedge against ecosystem fragmentation”, with the “Worst Case Scenario” being depicted as one in which there were separate “ecosystems” of Samsung users, Chinese OEM users, and “Google’s Android” users.
3751 It is evident from the design of GDAF that the type of fragmentation that Google was worried about was one in which users or groups of users ceased to use the Play Store and Google Search.
3752 So, the top priorities for the “Google forward tier” were identified as including “[o]ptimized for Search & Play Monetization”, with a reference to “Core Search & Play provisions (e.g. Hotword, Discover, Play DHS exclusivity)”. Indeed, the “Core Search and Play provisions” were described as “non-negotiable” parts of the GDAF, as was “no duplication of GMS apps”.
3753 Moreover, the minutes for the business council meeting, contained in an email on 21 June 2019 from Mr Bipin Khurana to the business council members, said that the “rationale” for the GDAF included “[s]ecur[ing] platform protections for Search, and Play and critical apps protections on more devices”; and that “[s]haring Play revenue share minimizes the risk of OEMs seeing -1 screen and 1P App Store as attractive additional revenue streams”. The last point identified the objective as dissuading OEMs from pre-installing other Android app stores, including their own.
3754 Moreover, on 26 March 2019, Mr Gennai had written an email which he copied to Mr Rosenberg and Mr Sayigh. That email addressed the proposed Project Banyan deal with Samsung.
3755 In response to the suggestion that Google should pay Samsung USD 250M in cash over five years to compensate for any lost Galaxy Store profits, Mr Gennai said that “a rev-share would be better at disincentivizing other app stores being preloaded (given it’d defray revenues), which is why I liked the idea of offering a rev-share across Search and Play”.
3756 It is not in doubt that paying an OEM a share of Play Store revenues would disincentivise the preloading of other app stores.
3757 In my view Google agreed to pay OEMs a share of Play Store revenues on Premier devices to disincentivise those OEMs from preloading any app store besides the Play Store. And it would seem that Google thereby sought to prevent or hinder those rival stores from being distributed via pre-installation on Android devices.
3758 Now about three months before the business council approved the GDAF, Mr Gennai wrote what I have referred to elsewhere as his Play problem statement. A tactic which Mr Gennai described in that document was a defence of the Play Store “as the preeminent Android app distribution store … focused around major points of distribution, particularly in aligning Android’s largest OEMs around Play as an app distribution source.”
3759 Now the major points of distribution on Android at least included pre-installed app stores. And a way to align Android’s largest OEMs around the Play Store as an app distribution source could be to enter into RSAs with those OEMs under which they earned a share of Play Store revenues.
3760 But Mr Gennai denied that the RSA3s were an implementation of his tactic. He also denied they were entered into for the purpose of ensuring the Play Store remained the pre-eminent Android app distribution source. I do not accept either of those denials. The GDAF was expressly designed to protect the Play Store, and it did so by aligning the interests of several large OEMs with those of the Play Store as an exclusive source of Android app distribution.
3761 Further, the “tighten Android” document includes a comment dated 17 August 2019, directed at Mr Gennai, being “do u want to talk about this? _Assigned to Paul Gennai_”. According to the metadata provided by Google when it was discovered, the document was created on 16 August 2019, Mr Gennai was its sole custodian, and its author was karthikmoorthy@google.com. The orders pursuant to which the metadata was provided defined the custodian as follows: “Name of person from where Documents/files were collected”.
3762 Given these facts, the likelihood is that Mr Gennai did at least read the document on or about 17 August 2019.
3763 In cross-examination, Mr Gennai said he did not believe he prepared the “tighten Android” document. He said that he did not know who drafted it and that he had no recollection of it. He said that he did not know how to interpret the document and that he was not sure what it related to.
3764 But in my view and as Epic has said, there is no mystery or uncertainty. The slide to which Mr Gennai’s attention was directed is headed “[h]ow to think about increasing leverage for Play and growing revenues in a future proof way”. The slide then depicts three different ways of achieving those ends. One of those ways was to “tighten Android” through “[e]cosystem access points” to give Google “[m]ore negotiation power with devs”.
3765 Ecosystem access points are places where developers can gain access to the Android ecosystem by distributing their apps. In other words, ecosystem access points are or at least include app stores. Tightening those access points would make it more difficult for developers to distribute their apps to Android device users. In turn, it would give Google “[m]ore negotiation power with devs” because they would need the Play Store more than ever.
3766 The mechanism proposed for “tightening Android” was a “[c]ommercial partnership with large 3P OEM store”, and the document suggested “[p]artner with Xiaomi, Huawei by sharing Play rev share in exchange for Play exclusivity”.
3767 Play exclusivity meant no other pre-installed app stores. Android would be “tightened” by this mechanism because developers would have fewer app stores through which to distribute their apps to Android device users at scale.
3768 Of course, six months later, Google entered into an RSA3 with Xiaomi, by which it shared Play Store revenues with Xiaomi in exchange for Play Store exclusivity. Google entered into additional RSA3s and MIAs to similar effect with other OEMs at around the same time. None of that is a coincidence.
3769 When Mr Gennai was confronted with the fact that tightening “Android Ecosystem access points” was the same idea he had expressed in his Play Problem Statement, where his words were “the defense of Google Play as the preeminent Android app distribution store can be focused around major points of distribution”, he said that “I genuinely do not know how to interpret the phrase “ecosystem access points” in the context of this slide”. That was not a truthful answer.
3770 Mr Gennai then said that he would rather not speak to the document. That is because he understood what it meant, and he was concerned that its content was damaging for Google.
3771 The RSA3s and the MIAs entered into with Motorola and LG were intended to “tighten Android” by reducing the number and reach of alternative app stores, that is, “[e]cosystem access points”, thus defending the Play Store’s position as the pre-eminent source of Android app distribution and increasing Google’s “negotiation power” with developers.
3772 Further, Mr Gennai said that he understood that an OEM’s own app store was excluded from the RSA3 exclusivity requirements that precluded the pre-installation of an alternative app store.
3773 The RSA3s that are in evidence contain no such exemption, save for the MIAs entered into by LG and Motorola, which are superfluous since neither LG nor Motorola operates an app store.
3774 Indeed, a general exemption of the kind suggested by Mr Gennai would contradict the plain words of the Premier device program requirements.
3775 In summary, and as I have said earlier, under the RSA3s Google promised to pay OEMs different shares of revenue in exchange for the OEM configuring their devices in particular ways. Where an OEM configured their devices as Premier tier devices, the OEM was entitled to a share of Play Store revenue and/or advertising revenue in exchange for not pre-installing any other app store or any app that was not also available on the Play Store.
3776 Under the MIAs, Google paid two OEMs, namely, Motorola and LG, a monthly incentive payment based on the number of devices activated that month which were Premier devices, with similar requirements for Premier devices as described in respect of the RSA3s.
3777 Now the objective of the standard RSAs was to incentivise OEMs to accept and abide by the MADAs, including the Play Store pre-installation and DHS placement terms.
3778 Contrastingly, the RSA3s and the MIAs concerning Motorola and LG were intended to disincentivise the pre-installation of rival Android app stores. I agree with Epic that that is the manifest effect of the inclusion, within the Premier tier device requirements, of stipulations to the effect that the device must not include any service that is substantially similar to the Play Store or that overlaps with the functionality or features of the Play Store. And as Epic says, this all manifests an intention to prevent or hinder the distribution of rival Android app stores, with Google offering to pay OEMs money in exchange for their not pre-installing the Play Store’s rivals. Moreover, the amount payable by Google increased with the Play Store’s revenues, enhancing the disincentive to pre-install any rival and invest in OEMs’ own app stores.
3779 In summary, Google’s purpose in offering, entering into and enforcing the RSA3s and relevant MIAs was to prevent or hinder the distribution of rival Android app stores. So, Google had the requisite s 46 purpose in offering, entering into and enforcing the RSA3s and relevant MIAs.
Do aspects of the RSA3s have an anti-competitive effect?
3780 Now Epic says that the effect of the RSA3s and MIAs with Motorola and LG is that Google paid OEMs a share of Play Store revenues and/or advertising revenues in return for the OEM agreeing not to pre-install any third-party app store and not to pre-install any app which is not on the Play Store.
3781 Epic says that the first aspect of that restriction removes an avenue for every rival app store to be distributed on Android devices. The second aspect of that restriction removes an avenue for a developer seeking to distribute their app outside of the Play Store. In addition, Epic says that by giving the OEMs a share of Play Store revenues, those OEMs are invested at least in part in the success of the Play Store. That dulls their incentive to invest in and compete via their own app store.
3782 So, Epic says that there are two effects that are material to the competition analysis.
3783 First, it says that by providing OEMs with a share of Play Store revenues, those OEMs are disincentivised from spending effort or money investing in their own app stores which might otherwise provide real competition with the Play Store.
3784 Second, it says that the prohibitions on pre-installing other app stores or apps which are not on the Play Store also cuts off another avenue for competition with the Play Store.
3785 Epic says that by removing an avenue for every rival app store to be distributed on Android devices, Google hindered the ability of all other Android app stores to compete with the Play Store.
3786 Epic says that such rivals cannot be distributed via the Play Store given clause 4.5 of the DDA and, further, that direct distribution via sideloading is hampered by the technical restrictions. It says that pre-installation deals were the only other avenue through which rival app stores could reach Android devices. Google effectively closed that avenue on many devices.
3787 Further, Epic says that the real world effects of the RSA3s are exemplified by Epic’s dealings with OnePlus, Sony, and LG. Epic says that each of those OEMs was apparently prepared to pre-install the Fortnite installer and the Epic Games app until they signed an RSA3. Once they signed an RSA3, those OEMs were no longer prepared to do so. I will address the position of OnePlus, Sony and LG in a moment.
3788 Now Google says that the universe of affected devices is very small, covering only 8 to 9% of devices in Australia, such that the RSA3s did not have any effect or likely effect on competition. But Epic says that those statistics do not provide the full story.
3789 The proportion of newly activated Android devices to which the Premier-tier requirements applied increased from 0% in 2019 to approximately 25% in the first eight months of 2022 globally excluding China. That is a more informative metric by which to gauge whether rival Android app stores were competitively disadvantaged, or likely to be disadvantaged, by the Premier-tier requirements of the RSAs. OEMs are only competing for pre-installation on new devices rather than devices already owned by consumers.
3790 In addition, Epic says that it is unlikely that a rival Android app store would at least initially seek to reach an agreement with either Google, given Google’s insistence on the prominence of the Play Store, or Samsung, given that it avoids pre-installing three app stores.
3791 Once Samsung and Google devices are removed, the share of devices to which the Premier-tier requirements applied is 39% of newly activated Android devices.
3792 Now as I have said already, most of these agreements have expired. The only RSA3 agreement still in effect is that with Motorola. This agreement was also amended in July 2023 to remove the requirement preventing the OEM from pre-installing any third-party app store. But Epic says that the fact that such agreements have since expired does not mean that they did not have the effect of substantially lessening competition whilst they subsisted.
3793 Now Professor Asker said that the contractual restrictions in the RSA3s assisted Google in addressing the coordinated adoption problem, and assisted Google to address externalities regarding security. But Epic says that the so-called security benefit lacks substance. And Epic says that the coordinated adoption problem is a problem that Google no longer faces.
3794 Epic says that the question of timing is particularly relevant in respect of the RSA3s. The Play Store, which was then the Android Market, was launched in Australia in 2009. By contrast, the RSA3s were not contemplated before June 2019.
3795 In those 10 years, the Play Store had grown to achieve near monopoly status. In those circumstances, the suggestion that the RSA3s were aimed at overcoming the chicken and egg problem cannot be accepted.
3796 Further, Professor Asker’s reason for suggesting that the RSA3s were necessary to address the coordinated adoption problem was that, without them, Google would not have been able to incentivise OEMs to sustain engagement with or continued investment in Android.
3797 But Epic says that the sections of the RSA3s which would be removed in a counterfactual world are the provisions requiring OEMs to exclusively pre-install the Play Store and the provisions prohibiting the pre-installation of apps that are not available on the Play Store.
3798 Epic says that this would not affect Google’s ability to do commercial deals with OEMs. It could do so without closing off avenues for competing app stores and developers to reach Android device users.
3799 Epic says that the RSA3s had the effect of tightening access to the Android ecosystem and prevented or hindered developers from distributing apps that facilitated the distribution of other apps.
3800 Epic said that so much is evident from Epic’s experience with OnePlus. Epic made the following points.
OnePlus dealings
3801 In 2019, Epic began negotiating with OnePlus for the installation of the Epic Games app on all existing, new, and unlocked OnePlus devices, as well as improving the install flow so that users would not confront the technical restrictions.
3802 On 26 February 2020, Mr Stolfus of Epic sent an email recording that Epic and OnePlus had reached agreement in-principle on key terms. First, OnePlus would pre-install the Epic Games app on all of its devices via a software update. Second, the Epic Games app would be located within OnePlus’s Game Space app. Third, the install flow for the Epic Games app and any apps installed via the Epic Games app would not confront any of the technical restrictions.
3803 But on the same day OnePlus entered into an RSA3 with Google and Google Asia Pacific. Under that agreement, OnePlus was entitled to a share of Play Store revenues earned from Premier devices.
3804 In March 2020, about 1 month after the RSA3 was signed, OnePlus informed Google that OnePlus was “partnering with Epic Games to boost Android gaming experience, including preloading a Fortnite installer”. Google noted that this would fail the Premier device requirements under the RSA3, but that OnePlus was trying to keep its devices on the Premier tier.
3805 Epic says that Google, knowing that Epic was aiming to have the Epic Games app preloaded on OnePlus devices, discussed alternative options with OnePlus and advised OnePlus as follows.
3806 First, Google said that OnePlus was unlikely to keep its devices on the Premier tier if a first party installer with INSTALL_PACKAGES was used to install Fortnite and a first-party installer with REQUEST_INSTALL_PACKAGES was used to install other games.
3807 Second, Google said that it had “strong security concerns” about the option of OnePlus treating the Epic Games App as a privileged app, on the basis “the app will have privilege to all dangerous permissions”. Again, that objection lacked foundation. There is no reason why Epic could not be trusted with a privileged installation permission, but Google or OnePlus could.
3808 Third, Google said that it would consider granting an RSA3 “waiver” if OnePlus only pre-installed an installer “to install Fortnite only”. Another option was to pre-install Fortnite only, but Google noted that this “will provide very limited incentives to Epic and carriers”.
3809 OnePlus proposed to further discuss with Epic the options of pre-installing Fortnite only or pre-installing an installer that would only install Fortnite.
3810 In the meantime, the RSA3 waiver request from OnePlus made its way higher up the chain at Google, whereupon Ms Kartesheva, who appears to have been a member of Mr Gennai’s strategy team at the time, wrote in an email on 28 March 2020 that “I was under the impression that we signed the premier deal to specifically prevent these situations”.
3811 So, it seems apparent that the objective of the RSA3s was to prevent the pre-installation of rival app stores or apps that distribute other apps. Mr Gennai then said on 28 March 2020 “[i]f they’re going to preload a store, seems fairly justified that we won’t pay that component of the deal, right?”. Mr Wang, to whom OnePlus had reached out, agreed but said it was “worthy to consider” allowing an installer that only installed Fortnite.
3812 But within two weeks, OnePlus advised Google that it had:
… decided NOT to pursue EPIC/Fortnite installer waiver request on premier devices and will continue with premier tier configuration … as they prioritise Google partnerships. …
3813 Google’s refusal to waive the RSA3 requirements to permit OnePlus to pre-install the Epic Games app on its devices caused the proposed agreement between OnePlus and Epic to stall. It was never concluded.
3814 The only pre-installation agreement Epic made with OnePlus was confined to certain devices in India.
3815 By that agreement, OnePlus undertook to pre-install the Epic Games app on devices sold in India, preload the Epic Games app in the Game Space app via a software update to devices sold within India, and provide Epic with an optimised install flow which bypassed the technical restrictions.
3816 Further, Epic made the following further points concerning the effect of the RSA3s on Epic's pre-installation negotiations with Sony and LG.
Sony dealings
3817 In March 2019, before the advent of the RSA3s, Epic entered into an agreement with Sony for the pre-installation of the Fortnite installer app and the Epic Games app once it launched, on the “plus-one” screen of certain Sony mobile devices.
3818 In October 2019, Sony obtained consent from its carriers to pursue the transition to the Epic Games app.
3819 But on 26 March 2020, Sony executed an RSA3 with Google under which Sony was entitled to a higher share of advertising revenues from devices which did not pre-install any service substantially similar to the Play Store.
3820 Sony never pre-installed the Epic Games app. Epic’s agreement with Sony expired in March 2021 and was not renewed or replaced.
LG dealings
3821 In April 2019, Epic entered into an agreement with LG for the pre-installation of the Fortnite installer app and the Epic Games app once it launched, on the “plus-one” screen of certain new LG mobile devices.
3822 But in an email on 17 January 2020, Mr Kwangsub Shin of Epic Games noted that LG said that it did not think carriers would allow pre-installation of the Epic Games app, and moreover, that “LG is under pressure to sign [a] new contract from Google that Google will pay 2-3 times more fee if LG signs a contract that LG never pre-install any 3rd party app store on their devices”.
3823 Later, in an email on 28 January 2020, Mr Shin noted that “LG said it’s very hard to convince carriers to pre-install Epic Games app and Google is trying to get rid of any 3rd party stores from OEMs including LG”.
3824 Epic’s agreement with LG expired around the end of March 2020 and was not renewed or replaced.
3825 In early April 2020, LG entered into its MIA with Google.
3826 Under that agreement, LG became entitled to monthly incentive payments which increased in size the higher the proportion of LG’s devices that did not pre-install a service substantially similar to the Play Store.
3827 On 14 April 2020, Epic approached LG about a potential one-click pre-installation approach for the Epic Games app. LG’s response in an email on 20 April 2020 was that it “has some contract with Google to block side downloading off Google Play Store this year. Surely we can do preinstall apps or stub apps if those use Google playstore”.
3828 Similarly, in an email on 17 July 2020, Mr Shin or Epic noted that LG had told Epic that it “cannot preinstall Epic Games app because of Google”, but was interested in pre-installing a “Fortnite Google Play Store version”.
Analysis
3829 Now I do not accept Epic’s contention that the terms and enforcement of the RSA3s had the effect or likely effect of substantially lessening competition by creating and sustaining many barriers to entry in the Android mobile app distribution market which operated to prevent or hinder competition in that market.
3830 I do not accept that the apparent disincentive for an OEM to pre-install or promote an alternative app store has prevented Epic from pre-installing the Epic Games App on Sony, LG and OnePlus devices.
3831 Epic’s contention fails on the evidence for several reasons, as Google points out.
3832 As Google says, the Premier tier provisions were inapplicable to most Android devices activated in Australia because the Samsung RSA3 did not include the Premier tier provisions. This meant that none of the Samsung devices, which accounted for 67% of all active Android devices in Australia and each of which had the Samsung Galaxy Store pre-installed and placed on their DHS, were configured as Premier devices.
3833 I agree with Google that there is no basis to exclude Samsung devices from the analysis of the effect of the provisions. As Google says, that is because, having made no contractual commitments to pre-install the Play Store as the exclusive app store or only preload those apps that are available on the Play Store on the device, it is open for a third-party app store to reach a pre-installation agreement with Samsung in respect of their own products and services. This is what happened with the collaboration agreement.
3834 Further, although the collaboration agreement was reached in the period before the RSA3s were in place, it indicates that third-party app developers could reach agreements with OEMs in respect of most Android devices.
3835 Accordingly, as Google says, no significant effect or likely effect on competition could result from the Premier tier provisions.
3836 Relatedly, as Google says, OEMs only chose to designate a small number of devices under the Premier tier provisions, namely, 8% of active Australian Android devices and 9% of Australian Android device activations, with Samsung devices correctly included in the analysis.
3837 The low number of active Premier devices is illustrated graphically at exhibit 98 of Professor Asker’s expert report across the 10 largest OEMs in Australia in respect of devices that were active within 28 days of 28 December 2023:
3838 As is apparent from exhibit 98, the total portion of active Android devices which are designated as Premier devices was small and consistently remained small.
3839 So, over 90% of Android devices in Australia were not subject to the Premier tier provisions. Further, 76% of consumer spending via the Play Store in Australia occurred on Samsung devices, that is, smartphones which were not Premier devices.
3840 So, I agree with Google that Epic or other rival app stores could not have suffered any material disadvantage by virtue of the Play Store being exclusively pre-installed on a Premier device.
3841 As a result, Epic could not have been prevented or hindered from competing with the Play Store by the operation of the Premier tier provisions in the RSA3s.
3842 Further, it also follows that the clause in the Premier device program requirements preventing OEMs from preloading apps that were unavailable in the Play Store on a Premier device without Google’s consent did not have the effect, or likely effect, of substantially lessening competition.
3843 Further, the share of active devices in Australia which are designated under the Premier tier has not materially increased, on a year-on-year analysis, since the RSA3s were introduced.
3844 So, as exhibit 97 of Professor Asker’s report illustrates, there were only 1.1% of active devices in Australia designated as Premier devices in 2020, with this increasing at a diminishing rate between 2021 to 2023. In fact, less than 16% of new devices in each month between January 2019 and December 2023 were designated as Premier devices and that figure has generally been declining since December 2021.
3845 So from the data it would seem that OEMs were not incentivised to pre-install the Play Store to the exclusion of any rival app stores or that Premier devices have the propensity to grow to capture a large portion of Android devices in the future.
3846 I agree with Google that the result suggests that the RSA3s did not have the effect, or likely effect, of competitively disadvantaging rivals in any substantive way.
3847 Further, some OEMs were, in fact, incentivised to pre-install and promote alternative app stores to the Play Store. Indeed, Samsung had its own Galaxy Store pre-installed on its mobile devices, and the majority of active Android devices in Australia have pre-installed app stores other than the Play Store.
3848 Further, as Google says, factors other than the RSA3s have resulted in OEMs failing to pre-install the Epic Games app.
3849 The terms of the Premier tier provisions and the RSA3s more generally were optional in nature. They did not foreclose another app store from negotiating its own agreement with an OEM. And OEMs could choose, on a device-by-device basis, whether they wished to configure a device in accordance with the Premier tier provisions.
3850 So, rival app stores were not foreclosed from negotiating and pre-installing their own products and services on Android devices, and the vast majority of Android devices were not designated as Premier devices.
3851 In my view OEMs were not constrained in their ability to do this. As Google says, they had the freedom to pre-install any other application, either on all of their devices if they elected not to designate any devices under the Premier tier, or on a device-by-device basis if they elected to have some devices configured as Premier devices.
3852 Further, rival app stores retained their ability to compete against the Play Store through sideloading. Nothing in the Premier tier provisions prevented or deterred an end user from installing any third-party app of their choice, including a rival to the Play Store. In fact, the provisions of the RSAs expressly allowed end users to do so.
3853 Further, the RSA3s with the OEMs, including the Premier tier provisions, were short term contracts and therefore not likely to have any extended or permanent effect.
3854 The terms of the RSA3s with many OEMs applied for a period of one or two years. To the extent that the RSA3s provided for automatic renewal, this cannot be equated to a contract of unqualified duration, with the renewal only extending for a period of 12 months. Similarly, on mutual agreement of the parties, an extension of the term of the RSA3 could be implemented, but only for a period of 12 months.
3855 As Google says, given these matters and the limited number of devices designated under the Premier tier, it follows that the impact or likely impact of the provisions is not material.
3856 Let me say something further concerning LG, Sony and OnePlus.
Alleged conduct with respect to LG, Sony and OnePlus
3857 Google made the following points with which I agree.
3858 Epic relied on the example of its dealings with LG, Sony and OnePlus as evidence that the RSA3s had the effect of tightening access to the Android ecosystem and prevented or hindered developers from distributing apps that facilitated the distribution of other apps.
3859 But I agree with Google that the evidence does not support the allegation that Google engaged in any conduct that prevented or hindered the Epic Games app being pre-installed on LG, Sony and OnePlus. Epic’s plans were frustrated by causes unrelated to Google, including a resistance by the carriers and, in some cases, causes traceable to Epic’s own conduct.
3860 Epic launched Fortnite on Android in August 2018, including by launching the Fortnite installer on the Samsung Galaxy Store and by pre-installation of a “stub” of the Fortnite installer on certain Samsung devices pursuant to the Samsung collaboration agreement. A stub is, in effect, a small file that links to an internet location from which the full app can be downloaded.
3861 During the period January to April 2019, Epic entered into three further agreements with OEMs, being Huawei, Sony and LG, but none of these agreements provided for Epic to share revenue generated from Fortnite with the OEM.
3862 The Huawei agreement provided for both pre-installation and inclusion of the Epic Games installer, which was in effect the Fortnite installer, in Huawei’s app store, the Huawei AppGallery.
3863 LG and Epic did not agree to the inclusion of Fortnite within LG’s app store, LG Smart World. But LG agreed to pre-install the Epic Games installer on certain devices under the LG agreement, subject to “circumstances where such preloads or distribution is not allowed … under an existing restriction with a third party operator … ”, that is, carriers or “such third party operator still demands that any part or portion of the Epic Games Installer software be altered or removed … ”.
3864 So, as Google says, the carriers were given the right to say no to a proposed pre-installation of the Epic Games installer.
3865 Sony did not have its own app store and agreed to pre-install the Epic Games installer on certain devices, but again subject to “the approval of Sony’s channel customer”, that is, a carrier(s).
3866 By March 2020, Epic’s OEM strategy had proved successful. Its deals with Samsung, Huawei, Sony and LG meant that it had agreements with OEMs that accounted for approximately 85% of Android devices capable of running Fortnite.
3867 As Google points out, despite the success of its OEM strategy, in the latter part of 2019 and early 2020, Epic determined to change that strategy in two respects, which led to the end of its OEM partnerships.
3868 First, Epic demanded that LG and Sony pre-install the Epic Games app in lieu of the Fortnite or Epic Games installer. Now the Fortnite installer was an app that facilitated the download and update of a single game (Fortnite). But the Epic Games app was effectively an app store, albeit one that was initially limited to some of Epic’s proprietary game titles including Fortnite. The Epic Games app is not the same as the Epic Games Store.
3869 I agree with Google that Epic’s suggestion that its agreements with LG and Sony contemplated a transition to the Epic Games app once it launched is incorrect. Rather, the change in Epic’s strategy destabilised Epic’s dealings with Sony and LG, both of whom declined Epic’s proposal, having been unaware of the extent of Epic’s plans to ultimately transition to the Epic Games app upon entering into their respective agreements.
3870 As Google says, one reason for that response is that LG and Sony expected that Japanese and Korean carriers would not agree to the change. That reaction is unsurprising given that these carriers had their own app stores.
3871 It is apparent that Sony and LG saw a significant difference between pre-loading a single popular game and permitting Epic to pre-load an app store on their devices for free.
3872 Second, as Google says, it would seem that Epic pushed OEMs to adopt new installation flows or methods, including an optimised “silent” install flow, which would have bypassed the need for users to navigate through the default sideloading install flow and grant the REQUEST_INSTALL_PACKAGES permission to the Epic Games app before using it to install other apps. The proposed install flow raised security concerns for the OEMs as it could have introduced security vulnerabilities to their devices if implemented. Further, it also did not comply with the GMS requirements.
3873 Let me elaborate in more detail concerning the position of LG, where the proposal to transition from the Fortnite installer to the Epic Games app was a significant concern to it. I essentially accept Google’s chronology of events.
3874 Around 17 January 2020, and consistent with its pre-installation agreement with Epic, LG informed Epic that the proposed transition was a major issue with carriers. LG said that the carriers had allowed the installation of the Fortnite installer because it was just one game, and that the move to the Epic Games app would require a renegotiation by LG with the carriers.
3875 LG also informed Epic that it was under pressure to sign a new contract from Google and that Google would pay 2 to 3 times more in fees if LG agreed to not pre-install any 3rd party app store on their devices. LG went on to say that LG refused to sign the contract because LG had a pre-installation contract with Epic.
3876 LG said that if the Fortnite installer was withheld by Epic from the forthcoming LG device, LG would proceed to sign the contract with Google.
3877 In response, in February 2020, Epic gave LG an ultimatum. Epic said that it would not be moving forward with any partners who did not install the Epic Games app.
3878 It appears that this impasse between Epic and LG was never resolved. The LG agreement expired according to its terms on 1 April 2020 and does not appear to have been renewed.
3879 Epic’s partnership with LG ultimately ended due to Epic’s insistence on pre-installation of the Epic Games app. It appears that the relationship with LG would have continued if Epic had persisted with the Fortnite installer only.
3880 So, Epic’s claim that Google caused the demise of Epic’s relationship with LG is unsupported by the evidence.
3881 Whilst LG did ultimately enter into a MIA with Google in April 2020 and informed Epic accordingly, the break in Epic’s relationship with LG occurred months earlier and for reasons that had nothing to do with Google.
3882 LG had told Epic in January 2020 that the issue was the carriers, not Google, and that LG would honour its agreement with Epic and not sign any agreement with Google if Epic did not insist on transitioning to the Epic Games app.
3883 Epic refused to deal with LG on that basis. It was Epic’s own agenda, rather than any arrangement between LG and Google, that caused Epic’s agreement with LG to come to an end.
3884 Let me now elaborate on the position of Sony which is similar.
3885 Sony objected to the fact that Epic’s proposal to transition from the Fortnite installer to the Epic Games app was proposed with no notice or plan.
3886 Consistent with its pre-installation agreement with Epic, Sony said that it would need to provide carriers with additional information for the carriers to accept the proposed transition.
3887 On 24 September 2019, Mr Daniel Steingrimsson of Sony advised in an email to Epic that there was “still heavy concern and reservation by the [carriers] with regards to the deployment window”, noting that “Japanese organizations move very slowly and securing approvals takes a long lead time (months at minimum)”. Sony noted that it may be particularly difficult to obtain approval from the Japanese carrier DoCoMo.
3888 Sony ultimately succeeded in convincing the relevant carriers to agree to the pre-installation of the Epic Games app, which occurred in late October 2019.
3889 On 23 March 2020, two days prior to the date of execution of an RSA3 between Google and Sony, Sony sought a waiver from Google to preload the Fortnite installer for two Xperia 1 II models, which the parties had agreed would be covered by the proposed RSA3.
3890 On 25 March 2020, Mr Cramer of Google granted Sony the requested waiver, which had the effect of allowing Sony to pre-install the Fortnite installer with an INSTALL_PACKAGES permissions on the Experia 1 II devices manufactured for Japanese carriers DoCoMo and KDDI.
3891 I agree with Google that this evidence is inconsistent with Epic’s case in relation to the alleged conduct and impact of RSA3s concerning Sony. Further, it would seem that Google did not stand in the way of OEMs wanting to pre-install third-party apps, including the Fortnite installer and Epic Games app. The evidence shows that even in its most significant markets in terms of Play revenue, Google approved the pre-installation of the Fortnite installer when that was the deal the OEM in fact wished to pursue.
3892 Now in September 2020, when Epic’s agreement with Sony was due to be renegotiated, Sony again raised concerns about Epic’s approach to pre-installing the Epic Games app as opposed to the Fortnite installer. Sony perceived a lack of ongoing support by Epic for the version of Fortnite installed through pre-installation after Epic launched Fortnite on the Play Store in April 2020. Sony proposed pre-installing a game centric installer, that is, the Fortnite installer as opposed to the Epic Games app or a placement inside Sony’s “Game Enhancer” app, which could drive significant traffic to the Epic Games website where users could download the Epic Games app.
3893 Epic rejected Sony’s proposals. In an email on 21 September 2020 from Mr Stolfus to Mr Steingrimsson it was said that that position was likely to “kill our immediate opportunity to partner”.
3894 Further, as Google points out, in October 2020, Sony wrote to Epic noting that the parties were in the last weeks of their existing contract. Sony invited Epic to continue discussions as to further collaboration. There is no evidence to suggest that Epic responded to that inquiry.
3895 Finally, let me address in further detail the position concerning OnePlus.
3896 Epic did not conclude a pre-installation contract with OnePlus in 2019. Nevertheless, during 2019 and early 2020, Epic and OnePlus engaged in discussions regarding the possibility of OnePlus pre-installing software on OnePlus mobile devices that could achieve a “silent” install of, at first, the Fortnite installer, and later, the Epic Games app.
3897 As Google says, Epic’s desire in pursuing a “silent” install flow was to enable the frictionless installation of the Epic Games app and apps installed via the Epic Games app, for example, Fortnite, in a manner equal to the app being pre-installed with the INSTALL_PACKAGES permission.
3898 Google put forward in submissions the following chronology with which I largely agree.
3899 By the end of February 2020, Epic and OnePlus were in discussions about a potential solution that would meet Epic’s technical requirements. The solution was described by Mr Hans Stolfus of Epic in an email dated 26 February 2020 as one which would “provid[e] Epic with a “preinstall” of the Epic Games App on all of [OnePlus’] devices via software update” and “an optimized installation flow for the download of the Epic Games App” which would “remove all Google-based security prompts such as “Unknown Sources”, as well as any apps/games installed through the Epic Games App (i.e. Fortnite)”.
3900 But on or around 25 March 2020, OnePlus realised during the final stage of testing that the OnePlus solution did not satisfy the GMS requirements and failed the GMS test suite. This ultimately meant that it could not be implemented in North America and Europe.
3901 Despite its desire to partner with Epic, OnePlus also echoed Google’s security concerns about the OnePlus solution.
3902 OnePlus sought information in an email on 26 March 2020 from Mr Eric Gass about how Epic was “ensuring [that] the APK delivered by Epic Games has no security issues”. OnePlus later relayed Google’s concern to Epic, according to an internal email from Mr Stolfus of Epic dated 31 March 2020, that the OnePlus solution “creates a security conflict”. It was also noted in an email from Mr Gass on 2 April 2020 that the requirement to disable the unknown sources setting “is a security requirement to protect users”.
3903 Notwithstanding, on 27 March 2020 OnePlus sought to explore with Google how it could pre-install the Epic Games app in accordance with both the GMS requirements and Epic’s technical requirements. Google offered five different solutions.
3904 Between 25 March 2020 and 2 April 2020, OnePlus put several solutions to Epic that could have resulted in the pre-installation of Epic’s games, but these were rejected, as the following chronology put forward by Google demonstrates.
3905 On 25 March 2020, OnePlus proposed “a slightly adjusted install flow” that it thought “could make the experience of trusting of unknown sources better from the user journey”. Epic rejected this solution during a call on the same day.
3906 On 27 March 2020, OnePlus proposed “preloading an app that has INSTALL_PACKAGES permission and is restricted to only update Fortnite”. This proposal involved “a preload of the Epic Games APK and Fortnite Installer APK”, with “[t]he Epic Games app [being] visible in Settings -> Apps & notifications”. Epic rejected this solution, saying in an email on 27 March 2020 from Mr Stolfus to OnePlus that the proposal “does not meet the original goals of the partnership from an Epic perspective”.
3907 On 30 March 2020, OnePlus proposed having a OnePlus installer handle the installation of the Fortnite installer with Google. OnePlus expressed confidence that this solution was likely to be able to be approved by Google. Epic rejected this solution because it did not achieve its “original goals”.
3908 On 2 April 2020, OnePlus proposed “two possibilities for a game app that contains more than one game”. Epic did not take up the opportunity to explore or pursue these possibilities.
3909 I agree with Google that these events show that OnePlus was committed to the Epic partnership, including doing what it could “from a hardware and software standpoint to optimize all future game experiences” and “help achieve the wider goals of Epic on Android”, as was said in an internal email from Mr Stolfus on 31 March 2020. Despite this, Epic declined OnePlus’ proposals, with the result that OnePlus ultimately determined not to seek any waiver of the GMS requirements from Google. OnePlus also never requested the relevant waiver from Google. OnePlus decided against applying for the relevant waiver because Epic had rejected OnePlus’ proposed solutions for the pre-installation of Fortnite, which OnePlus expected Google would approve.
3910 It would seem to me, and as Google correctly pointed out, that Epic was the source of the demise of the proposal rather than Google.
3911 Let me make one other general point.
3912 In summary, I agree with Google that it was Epic’s aggressive shift from a strategy of pre-installing a single app to a strategy of pre-installing an app store in a specified and non-negotiable manner that ultimately frustrated Epic’s dealings with LG, Sony and OnePlus.
3913 Further and in any event, I agree with Google that the relevant OEM alleged conduct could not have had the effect or likely effect of substantially lessening competition in any relevant market.
3914 LG, Sony and OnePlus each had a tiny and insignificant share of Android mobile devices in Australia in the relevant period. In December 2020, for example, they accounted for a combined total of less than 3.5% of Android devices in Australia. The share of active devices accounted for by these OEMs’ Premier tier devices is smaller still (0.1% in 2020).
3915 So it would seem that the alleged conduct could only ever have prevented the pre-installation of the Epic Games app on 3.5% of devices in Australia.
3916 As Google has said, that could not amount to a substantial lessening of competition. Where 72% of active Android devices in Australia have a non-Play Store app store installed, any effect of the alleged conduct would be limited to pre-installation and would not prevent the devices accessing the same apps by way of sideloading. And the conduct was in respect of a single and nascent app store, offering only a small number of proprietary apps.
Summary
3917 In summary then, Epic has not satisfied me of the requisite effect or likely effect for the purposes of s 46.
3918 Let me turn to another topic.
Project Banyan and Project Hug – genesis and elements
3919 It is now convenient for me at this point to discuss Project Banyan and Project Hug. Let me begin with Project Banyan.
Project Banyan
3920 As Epic points out, Project Banyan was conceived and planned around the same time as Project Hug.
3921 Moreover, both projects were approved by Google’s business council at the same meeting. According to a 9 April 2019 presentation titled Boosting Top Game Developer Support & Securing Play Distribution on Samsung Devices, it was stressed that both programs were needed.
3922 Now although Google did not ultimately conclude the particular Samsung deal that became the subject of Project Banyan, I agree with Epic that Google’s conduct and objectives relating to Project Banyan illuminate its purpose in implementing Project Hug. Let me go back into history a little.
3923 Prior to November 2013, Google held discussions with Samsung about Samsung ceasing to compete with the Play Store in app distribution.
3924 According to a 24 November 2013 email from Mr Roche, Samsung’s duplication of Google’s services on Android was “one of the critical issues with the partnership” and Samsung Apps, which was the predecessor to the Galaxy Store, was “one of the most glaring”.
3925 Now around that time, Samsung reached out to Google and made a proposal on the features that they would need to fully embrace the Play Store. And this was seen by Google executives as an important opportunity to move Samsung away from their own store.
3926 Mr Siliski, the Google executive who thought that moving Samsung away from its own app store was an important opportunity, had previously talked this over with Mr Rosenberg. Mr Siliski said in a 26 November 2013 email to Mr Roche that “we were aligned”.
3927 A meeting was arranged with Mr Gennai and others on 9 December 2013. According to an email from Mr Roche to Mr Siliski on 6 December 2013, the “key asks from Samsung” to be discussed included “Samsung Apps should no longer compete directly with Google Play”, and “Samsung Apps could link to Google Play for many purchases if the right infrastructure is in place”.
3928 On or around 23 May 2016, Mr Gennai prepared a document entitled “Next Steps With Samsung”. Now Mr Gennai said that he did not believe that he was the author, but the metadata produced by Google names Mr Gennai as both the author and a custodian. I am satisfied that he was either the author or an author.
3929 The document identified possible attendees including Mr Rosenberg and Mr Samat. It recorded a “[t]eam recommendation” to “attempt to solve buckets 1-3 … in this round of meetings”. Bucket 1 was “Samsung adopts Play Auto-Installs”, which is a mechanism whereby the Play Store delivers apps to mobile devices over-the-air; once installed, those apps are Play Store apps. Bucket 2 was “Samsung Zone in Play replaces Galaxy Store”. What “Samsung Gets” from Bucket 2 was identified as “Stop wasting resources on Galaxy Store”, and the “Google Gets” was identified as “No Galaxy Store”.
3930 The document set out three different “Stories”, being different ways that Google could pitch the proposed deal to Samsung. Each of those “Stories” included, as an element of the pitch, “[w]e’d like Samsung to phase out the Galaxy Store” or “Samsung phases out Galaxy Store”.
3931 So it would seem that in mid-2016, Google was planning to put to Samsung a deal which involved Samsung phasing out the Galaxy Store and ceasing to compete with the Play Store in app distribution.
3932 Further, part of the evidence before me was a set of meeting notes sent in an email on 2 June 2016 from Ms D’Silva to several Google staff members, which meeting involved inter-alia Mr Lockheimer, Mr Rosenberg, Mr Samat, and Mr Gennai. It is apparent from the meeting notes that the attendees discussed a slide deck that covered the topic of Samsung shutting down the Galaxy app store.
3933 The meeting notes record discussion to the effect that “[w]e should be talking about shutting down their app store. Note that the proposal from last time may still not be on the table -- but let’s position this meeting as picking up from where we left”. So, it would seem that Google had previously talked with Samsung about shutting down their app store and intended to do so again.
3934 Let me move further forward in the chronology.
3935 On 11 December 2018, Mr Gennai drafted an “EoY risk snippet” for the Alphabet board of directors where he highlighted various risks for the board including “[r]eports that Samsung is … rebooting there [sic] app store as ‘Galaxy Store’ with renewed focus”.
3936 By 9 January 2019, according to a document titled Sunday / JY Lee prep doc, Google perceived that Samsung was “expand[ing] their ambitions in app & distribution”. It drew that conclusion from Samsung’s 2018 agreement with Epic to pre-install Fortnite on certain devices, from market intelligence, and from the fact that Samsung had begun to pre-install the Galaxy Store on the DHS of its devices. Previously, its icon had been placed on a screen that was not the DHS.
3937 Further, in an email on 11 January 2019, Mr Gennai said that OEMs were looking to increase their services revenue and to differentiate their devices with content, so as to distinguish their devices from those of competitors by using their pre-loaded content, software and apps.
3938 In February 2019, Google prepared a presentation titled Project Banyan Phase 1: Ecosystem Overview. Mr Gennai received it at about that time and was on the steering team for the project. The presentation identified an “Existential Question”, being “[h]ow do we continue to keep Play as the preeminent distribution platform for Android?”. I agree with Epic that that was a key question which Project Banyan set out to resolve.
3939 A substantial objective of Project Banyan at that time was to work out how to keep the Play Store as the pre-eminent distribution platform for Android. This is confirmed by the three “major milestones” identified in the presentation, which involved identifying “[w]hat are the biggest risks to Play’s value proposition to partners” including “the most likely scenarios for alternative app distribution”, “[w]hat should be our priorities to address these risks”, and “[w]hat initiatives should we prioritize for 2019?”
3940 In addition, the presentation went on to articulate “Key Questions” for Project Banyan, including “[w]hat are some future scenarios that would challenge Google Play’s continued growth as the leading Android app store?” and “[h]ow could Play prepare for these possible futures by changing its product or business model?” I also agree with Epic that those questions were not materially different from the “Existential Question”.
3941 Further, various “working hypotheses & assumptions” were identified in the presentation as “guiding our scenarios”. Samsung was identified as “the only OEM with sufficient share to plausibly build its own store in key Play markets”. Google found it “[c]hallenging to see Galaxy Store becoming attractive enough to developers to be a successful, sustainable stand-alone business” and considered that the Galaxy Store would need to acquire “exclusive rights” that would “build a user base” in order to succeed.
3942 But the presentation recorded that Samsung was “[a]ggressively pursuing exclusive deals with major Android game developers”. So, one of the scenarios being considered as part of Project Banyan was the risk of Samsung seeking to grow the Galaxy Store by doing exclusive deals with major game titles.
3943 Now it would seem apparent from the February 2019 presentation that Project Banyan was not initially limited to a proposed deal with Samsung, but had a broader scope. But it came to be regarded as synonymous with a proposed deal with Samsung.
3944 Now a March 2019 presentation titled Project Banyan // PM – HL was devoted to a potential Samsung deal. The presentation described the “Goal” of Project Banyan as to “[p]rovide Samsung a path to de-prioritise Galaxy store investment for Android Game distribution while meeting their P&L needs and stated strategic goals”. Now Mr Gennai said that this was not his recollection. But Mr Gennai was on the steering team and saw the document. It is readily apparent that Google was asking Samsung to “de-prioritise Galaxy store investment”, and that this was Google’s goal in pursuing the proposed Project Banyan deal with Samsung.
3945 The presentation stated that the “Galaxy Store could be moderately successful as a standalone store if Samsung digs in”. Epic put to me that “moderately successful” appears to mean a net profit of only USD 240M in 2022, versus Samsung’s annual profit from other activities of two orders of magnitude greater. I am inclined to agree.
3946 Now the offer that Google intended to explore with Samsung as part of Project Banyan included formalising the Galaxy Store “as a partner for delivering games from the Play Store” via Alley-oop, being a technology that enabled users to initiate the download of an app by clicking an icon or advertisement outside the Play Store which triggered the delivery of the app through the Play Store’s delivery infrastructure. The concept being proposed was that users would download Play Store apps without leaving the Galaxy Store.
3947 Now the March 2019 presentation also stated that “Samsung Galaxy Store becomes an additional discovery surface area”. Clearly, if the proposal were accepted the Galaxy Store would have been an additional location from which users could acquire Play Store apps.
3948 Now Mr Gennai resisted the idea that the Galaxy Store would effectively become an extension of the Play Store and would not be competing with the Play Store, but in my view that would likely have been the case. Moreover, Google’s proposal was that the apps in question would use Google Play Billing.
3949 On 25 March 2019, Mr Atul Kumar sent Mr Gennai an update on the Samsung proposal, which was copied to Mr Rosenberg and Mr Samer Sayigh. That email recorded Google’s estimate of “Galaxy store 2019 net profit ranges from -$15M to $75M”. It also recorded Mr Kolotouros’ suggestion that Google offer Samsung USD 50 million per year over five years, subject to Google’s “gets”, including “product integration”. I agree with Epic that despite Mr Gennai’s denial, it is apparent that these lump sum payments were intended to compensate Samsung for giving up its Galaxy Store profits.
3950 On 29 March 2019, Mr Gennai sent an email to Mr Sayigh which incorporated “text from the other thread”. That text included “[g]etting the deal done with Samsung is very far from a certainty. This is a conversation we’ve attempted to have many times in the past”. This was a reference to Google’s prior discussions with Samsung about shutting down their app store. Clearly, the objective of the Project Banyan deal was the same as that of the prior discussions, namely, for Samsung to cease competing with the Play Store in app distribution.
3951 On 8 April 2019, an email was sent by Mr Michael Murphy to Google’s business council and numerous senior executives, which included information about the proposed Samsung deal, including that it involved “[u]p to $60M annual payment for 4 years to make Samsung whole for foregone store services revenue”, and “Play to provide infrastructure support to Galaxy Store (including Play Billing); Samsung will forgo store services revenue.”
3952 Now as I have already indicated, on 9 April 2019 Project Banyan and Project Hug were presented to the business council who was told that these two programs were to be deployed in conjunction and that both programs were needed.
3953 Now according to the 9 April 2019 presentation that I mentioned at the outset, so far as Project Banyan was concerned it was described to the business council as “[s]ecur[ing] and enhanc[ing] Play distribution on Samsung” and “[m]otivat[ing] Samsung to prioritize Play”, that is, to prioritise the Play Store over the Galaxy Store. Google’s proposal to Samsung was pitched as a “Collaboration” involving a “Play-powered Galaxy Store”, with “Play as delivery infrastructure for Galaxy Store”.
3954 The “Google Gets” from the proposed Samsung deal included “Play hosts Galaxy Store games/apps, and provides billing, security, and updates”. So, all apps nominally distributed by the Galaxy Store would use Google Play Billing and therefore generate in-app purchase revenues for Google, not Samsung. Another “Google Get” was “Play and Galaxy Store are only app stores on Default Home Screen”. A “Preliminary Term Sheet” was also set out in the business council presentation. It referred to the same “Google Gets” and confirmed that the proposed deal was to apply to all Samsung-owned surface areas that facilitate the download of Android mobile apps, including Galaxy Store and Game Launcher.
3955 The business council was told that an “[u]pfront cash payment [was] needed to address their Galaxy Store P&L” and its quantum was “anchor[ed] on the range of net profit that we estimate Galaxy Store makes”. As I have said, the upfront cash payment was intended to compensate Samsung for giving up its Galaxy Store profits.
3956 As Epic correctly characterised the matter, and indeed consistently with the answers Ms Kochikar gave under cross-examination, the Samsung deal put before the business council was an arrangement under which Samsung would cease to compete with the Play Store in app distribution. Instead, as I have said, all apps listed in the Galaxy Store would be distributed to users by the Play Store’s infrastructure and they would all use Google Play Billing. Google rather than Samsung would earn a share of the revenues generated from in-app purchases made within those apps. And as I have indicated, Google would pay Samsung USD 50 million per year to compensate it for any profits lost as a result of giving up its app store profits.
3957 Clearly, in my view the result which Google was seeking to achieve was that Samsung would not compete with the Play Store. Now Mr Gennai refused to concede even this effect, saying “No, [competing] is exactly what enabling them to differentiate via content would allow them to do”. But as Epic points out, differentiated store content that is distributed by, and which generates revenue for, the Play Store might help Samsung to compete with its OEM rivals to sell devices, but it does not involve competing with the Play Store in app distribution. Further, Mr Gennai’s refuge in the possibility that Samsung might earn revenues for in app purchases went nowhere.
3958 On 19 April 2019 the business council finalised approval of Project Hug and Project Banyan.
3959 On 26 April 2019 and within three weeks of the business council’s approval, Google made a presentation to Samsung titled “Building unique app experiences for Samsung devices and users” which included the following “asks of Samsung”: (a) “Google Play Store to host all Android app APKs that are distributed through Galaxy Store or any other Company app which distributes APKs”; (b) “Google to provide all billing, security, and app updates through the Google Play Store infrastructure”; (c) “No 3P app stores to be placed on the Default Home Screen”; and (d) “No 3P app stores to be linked to any Assistive services on device”.
3960 I agree with Epic that it is readily apparent that each of Google’s “asks” was directed at preventing or hindering competition in Android app distribution.
3961 On 29 May 2019 Mr Rosenberg sent an email to Mr Lockheimer and others which said:
…
… On [the Project Banyan proposal], [a Samsung executive] acknowledged the questions going back and forth between the teams and said they are still discussing internally… He asked me if there was a way to achieve our goals with the proposal but still accommodate their desire to process transactions via their payment system. I said we put a lot of thought into our proposal about how to align incentives to have a single voice to the ecosystem, and so that the teams were not out competing with each other. We simply had not figured out how what he’s asking for wouldn’t throw incentives out of alignment. So we looked for other ways to address what we felt were their true goals, make them whole on any economics they were seeing today, and keep our eyes on the prize of helping Samsung sell more devices.
He said, “So you’re basically asking us to get out of the app store business.” I said, “We’re proposing that we focus together on helping you achieve your goals in a different way, and in a way that keeps us aligned to collaborate technically and with our message to the ecosystem.”
…
3962 As to the reference to the Samsung executive saying “you’re basically asking us to get out of the app store business.”, clearly, that was the substance of Google’s proposal. Mr Rosenberg’s response to the Samsung executive confirms this. Further confirmation is supplied by the balance of Mr Rosenberg’s email and his references to aligning incentives, having a single voice in the ecosystem and ensuring that the teams were not out competing each other.
3963 I agree with Epic that this was all the antithesis of competition and reflected Google’s purpose.
3964 On 20 June 2019, Samsung sent Google a proposed terms sheet titled Google-Samsung Store Agreement Term Sheet. The terms sheet described the “Goal” of the proposed agreement as “[p]revent unnecessary competition on store” and “[u]nified window for app distribution to allow streamlined cycle for app development, distribution and update”, which was the antithesis of competing app stores. Samsung was to refrain from competing with Google in app distribution services, and this is what Google was trying to achieve with Project Banyan. I reject Mr Gennai’s evidence to the contrary, which is at odds with the contemporaneous documents and any sensible commercial reading thereof.
3965 But soon afterwards, Project Banyan was halted.
3966 In a 12 July 2019 email from Mr Rosenberg stating that work on the project was being halted, he said “[w]e’re working internally with Legal to reevaluate our options, and we’ll be back in touch once we have clear guidance on the direction this deal should take”. This was the only explanation thrown up to me by the evidence.
3967 In my view Project Banyan had the purpose of substantially lessening competition. Indeed, and as Epic has invited me to do, I also infer that the anti-competitive purpose of Project Hug and the Games Velocity Program (GVP) agreements, which I will get to in a moment, was similar to the anti-competitive purpose of Project Banyan.
3968 Now Google says that the fact that it established two distinct programs, one called Project Hug and the other called Project Banyan, suggests that it saw those as distinct projects, the objects of which were not the same. It says that it would make little sense to have two programs if the ends sought to be achieved through one program were the same as those sought to be achieved by the other. But this is a glib description. In my view the evidence demonstrates an overlapping common purpose of the two projects even if each also had other separate and non-overlapping objectives.
3969 Let me now deal with the principal competition questions concerning Project Hug, the GVP agreements and the Apps Velocity Program (AVP) agreements.
Project Hug
3970 Now the catalyst for Project Hug appears to have been Epic’s decision to launch Fortnite on Android outside the Play Store which Google was informed of in June 2018.
3971 It would seem that Google perceived this to be a threat to the Play Store’s dominance in Android app distribution, so it sought to contain the contagion that it feared would result by offering Epic benefits worth over USD 200 million to reverse its decision.
3972 Let me at this point say something about a proposed deal between Google and Epic.
3973 The deal that Google offered to Epic was set out in a presentation titled EPIC / Fortnite BC Deal Review made to the business council on 19 July 2018. It consisted of benefits said to be worth USD 208 million to Epic, in exchange for Epic agreeing, first, to launch Fortnite and other titles for Android on the Play Store first or sim-ship, second, to ensure that the Play Store was at parity or better on pricing, content and promotions versus other platforms, and, third, to prioritise Pixel devices for its Android launch.
3974 The express objective of the proposed deal according to this presentation was to “[p]artner with Epic to secure Fortnite’s launch on Play and help them achieve their goals in the gaming industry”.
3975 The rationale included that “[n]ot having Fortnite on Play creates significant risks for Android ecosystem & Play business”, including “$130M (up to $250M) direct revenue loss for Play” and “[d]ownstream impact of $550M (up to $3.6B) potential revenue loss if broad contagion to other developers”. So, Google was concerned about the direct revenue loss it would suffer from not having Fortnite on the Play Store. Google estimated that loss to be between USD 130 million and USD 250 million.
3976 The contagion referred to was a fear that if Epic were successful in distributing outside the Play Store, other developers would have the same idea and do the same thing. Google was concerned that if developers started distributing apps directly, the Play Store would no longer intermediate the relationship between developers and users. So, Google assessed that there was a potential contagion risk, being that other developers would follow Epic’s lead and likewise launch their titles on Android outside of the Play Store. That loss was estimated to be between USD 421 million and up to around USD 3.3 billion, depending on the extent to which developers launched off the Play Store.
3977 Now the concept of contagion appears to be used in the Fortnite deal review and elsewhere to refer specifically to the commercial risks arising out of Epic’s decision to launch off the Play Store and Google’s reaction to that decision. The risk was that other developers would follow Epic and launch on Android outside of the Play Store. Alternatively, the risk was that other developers would seek similarly favourable deals from Google in order to launch on the Play Store. So, the specific risk was that the Play Store would lose its customers.
3978 Further, Google perceived that Epic was not unique in having competitive alternatives to the Play Store. That is why there was a risk that Epic’s approach would spread. The reference to contagion reflects Google’s assessment that the risk that developers would forgo the Play Store was real and immediate, and not merely potential or prospective.
3979 Google’s concern about contagion was further explained in the presentation. It calculated the total value at risk as USD 3.6 billion and the probability weighted risk as USD 550 million. This calculation involved attributing a 30% probability to “[p]owerful developers able to go on their own”, a 15% probability to “[m]ajor developers will co-launch off Play”, and an 8% probability to “[a]ll remaining titles co-launch off Play”. Each of those scenarios contemplated developers distributing their apps on Android, either outside the Play Store or both through the Play Store and elsewhere on Android.
3980 In other words, the risk that was quantified in the presentation was not that developers would cease to distribute their apps within the Android ecosystem, but that they would do so wholly or partly outside the Play Store.
3981 Mention was made in the Fortnite deal review of an additional risk that “users could switch to iPhone”, but that risk was neither valued nor was its probability assessed. It was not the larger concern.
3982 Now the contagion risk that attended Epic’s launch of Fortnite outside the Play Store was regarded as serious by senior executives within Google, including Mr Rosenberg. Several of the company’s most senior executives were called on to discuss the matter, including the CEO, the CFO, the chief business officer and the head legal counsel.
3983 The Fortnite deal review also warned of a “[f]ragmented app ecosystem”, saying that “Fortnite may legitimize “Samsung” store & 3rd party stores; fragmenting app distribution on Android”. Ms Kochikar ultimately conceded that that was a concern about having more than one app store on Android.
3984 What Google was concerned about was competition for the distribution of Android apps, although Google was also concerned to some extent about competition with iOS. Now on iOS there was a monopoly app store, whereas on Android, there was a prospect of some competition. On iOS there are no choices and only one place to distribute apps.
3985 Google was concerned that an indirect impact of Epic launching outside of the Play Store was that users could switch to iPhone resulting in further substantial downside. The mechanism by which that could occur was through the fragmentation of app distribution on Android, resulting in inconsistent access to AAA games and an increased perception gap compared to the iOS ecosystem.
3986 The risk of fragmentation or fracture was a risk that Android users would have to search in multiple places on Android to find the content that they wanted.
3987 The concern was that users would leave Android for iOS if, unlike iOS, there was no comprehensive source of apps on Android. So much is evident from a comment made by Mr Rosenberg in the 19 July 2018 Fortnite deal review itself being that the proposal “prevents fragmenting of Android developer ecosystem, which could have substantial knock-on effects to user experience and drive more users to iOS”.
3988 Mr Rosenberg directly linked the risk of increased fragmentation in app distribution on Android to the consequence of increased churn to iOS. This is because app store fragmentation can be costly for developers and users and so reduce Android’s attractiveness for both groups.
3989 Now the business council approved the proposed deal with Epic, and Mr Lockheimer and Mr Rosenberg were among its deal representatives. Minutes of the business council meeting recorded in an internal email on 19 July 2018 noted discussion about the “high risk of contagion”, being a “high risk that other games seek other distribution channels as well”.
3990 Further, the minutes record discussion to the effect that “Fortnite is an unprecedented game and the technical/UI hurdles for users will limit appetite of other developers to seek similar terms”. The “UI hurdles for users” were those presented by the unknown sources install flow. The install flow was considered to limit the risk that other developers who lacked an unprecedented game would seek to distribute directly to Android device users. Further, Google recognised that the risk of others doing the same thing as Epic was lower because the unknown sources install flow would limit their appetite to do so. In other words, at the highest levels, Google recognised that the unknown sources install flow reduced the likelihood of competition in Android app distribution.
3991 Google’s recognition of the role that the unknown sources install flow plays in developer distribution decisions is also apparent from the explanation given to Mr Schindler, who was not at the business council meeting, of the key assumptions underlying management’s calculation of the probability weighted value at risk.
3992 Mr Ahmed’s explanation shows that Google’s assessment was that the probability of developers directly distributing their apps outside the Play Store was reduced on account of the hurdle presented by the unknown sources install flow. He said in an email to Mr Schindler on 21 July 2018 that:
Probability factor was based on discussions with [Business Development] and their close understanding of developers, their drivers and capabilities along with the understanding that it is not a simple process to expect to “sideload” on Android and expect to monetize at the same levels of that through Play.
3993 Now Epic turned down Google’s proposal and made no counterproposal. Google also considered making an equity investment in Epic, on the basis that a large strategic investment into Epic could help advance broader discussions about using the Play Store for Fortnite. Google surmised that anything short of a controlling stake would limit Google’s ability to influence Epic’s trajectory. The proposed investment did not eventuate.
3994 Let me at this point say something more about the genesis of Project Hug.
3995 In an internal 7 August 2018 email it was recorded that Google was “putting together a hug developers close and show love plan” in response to what was referred to as the Fortnite situation. This plan was initially referred to as Project Bear Hug. It later became known as Project Hug.
3996 Ms Kochikar was involved in Project Hug from the beginning, and it became part of her day-to-day responsibilities.
3997 One of the early tasks that Google needed to undertake was to quantify the direct and indirect costs associated with leakage on Android, that is, the amount that Google stood to lose if developers distributed their apps within the Android ecosystem but outside the Play Store.
3998 Google needed to consider the scale and scope of the investment that it should make to stop at risk developers from defecting, that is, from ceasing to distribute apps through the Play Store.
3999 On 11 October 2018, Ms Kochikar had an email exchange with Mr Gutterman, who worked for her. Mr Gutterman had responded to another team member by “add[ing] some color to the expectations around sim-ship here”. That “color” included that Google was “still digging out from Android tech debt” and was “at least 2-3 years from making Android a predictable platform to build games for”. He added that “developers are making a sensible economic decision by shipping to iOS and then Android in sequence”.
4000 Ms Kochikar agreed with Mr Gutterman’s assessment and continued as follows:
I also want to point out that we should not conflate games launching first on iOS to be a risk to Android. Premium games have ALWAYS launched first on iOS and do significantly better on iOS. Previously MOST apps and games launched first on iOS, as we closed our technical debt … sim ship increased steadily.
The Bear Hug effort is to address fragmentation WITHIN the Android ecosystem. We are unlikely to be able to Bear Hug our way out of the technical debt when compared to iOS. For example: I don't think Civilization VI will work on Android as it is currently. It is 2.5x the size of Fortnite, starting price is $23.99, and has in app items which are around $10. For this to work, we not only have to pay down the tech debt on Android, we need to implement a lot of the premium gaming features contemplated by Greg and Tian.
…
4001 In my view this email indicates that the or a substantial purpose of Project Hug was “to address fragmentation WITHIN the Android ecosystem”. The email also demonstrates that Google did not perceive the fact that premium games tended to launch first on iOS as “a risk to Android”. That had “ALWAYS” happened.
4002 It is also apparent from the email that Ms Kochikar expected that premium games would increasingly sim-ship as Google continued to narrow its “tech debt”, which had occurred already with “other games and apps”. But I agree with Epic that narrowing the “tech debt” with iOS was an effort that was separate from “Bear Hug”. As Ms Kochikar conceded, “Bear Hug is a commercial program. It can’t fix the technical debt.” The “Bear Hug effort” was not about technical debt. It was intended to address something quite different, namely, “fragmentation WITHIN the Android ecosystem”.
4003 Now in cross-examination Ms Kochikar did not accept the plain meaning of her own words. When it was suggested to her that the view she expressed in her email was that games have always launched first on iOS and that is not a risk to Android, Ms Kochikar said “[t]hat’s not how to read it”, “it is being taken out of context”, and “that’s not how I meant it”. She then conceded that she had told Mr Gutterman that she did not perceive the fact that these games might launch first on iOS to be a risk to Android, qualifying her concession by saying it was a “very small group of games”.
4004 Moreover, Ms Kochikar made the following concessions. First, she conceded that Google was trying to address fragmentation within Android. Second, she conceded that Google was trying to address fragmentation in the distribution of apps. Third, she conceded that the fragmentation Google was seeking to address within Android included growing competition with third-party app stores.
4005 Further, she conceded that the real concern behind Project Hug was that high-quality developers would cease distributing Android apps through the Play Store and begin doing so through other Android distribution channels.
4006 Now Google says that Epic’s assertion relies on a misunderstanding of Ms Kochikar’s email to Mr Gutterman on 11 October 2018, which I have just referred to.
4007 Whilst the email expressly referred to the fact that “[p]remium games have ALWAYS launched first on iOS”, Mr Rich SC sought to extract a more general proposition from Ms Kochikar, being that games generally had always launched first on iOS, and that doing so was not a risk to Android. Ms Kochikar rejected that proposition, observing specifically that she was referring in the email only to a small subset of developers whose games “can’t work on Android”.
4008 Google says that in Ms Kochikar’s email of 11 October 2018 she was specifically referencing a subset of games that, in her view, were better suited to iOS than Android and unlikely to be attracted to Android given the nature of those games and the way developers monetised them. In that email it was being indicated that a Project Hug agreement would not be sufficient to induce the developer of Civilization VI to sim-ship on Android and iOS because of both the technical debt between Android and iOS and because Android would need to implement “premium game features” that it did not have.
4009 Moreover, there is no inconsistency between the proposition that Project Hug was directed at addressing “fragmentation WITHIN the Android ecosystem” and the proposition that it also less directly concerned competition with iOS.
4010 Now in late 2018, Google remained concerned about the contagion risk arising from Fortnite’s launch off-Play. Some developers were telling Google that they were going to set up their own app store.
4011 On 11 December 2018, Mr Gennai in an email to Ms Mona Gohil referred to “Epic launching an app store -- initially on PC, but later on Android” and said, “[t]his, along with other large titles assessing distribution options (Riot, etc.) may put pressure on Play business.”
4012 In December 2018, Google learned that Riot Games, a subsidiary of Tencent, would “be deciding whether to launch League of Legends on or off Play by end of January ‘19”. Google considered League of Legends to have “the highest potential (to become a billion-dollar franchise on Android) yet the most significant leakage risk”, with “the potential to become a watershed event for Tencent’s portfolio’s future publishing direction, even for the industry”. Google saw “the potential for [League of Legends] to become a marquee title supporting” the launch of Epic Games Store on Android.
4013 In early 2019, Google agreed to provide Riot with marketing funds of USD 10 million in relation to Riot’s launch of new titles on the Play Store. Google did so in order to stop Riot's “inhouse “app store” efforts and bring their billion dollar League of Legends franchise and other mobile games to Play”.
4014 In a later undated document titled “Riot GVP Deal”, which was drafted for the business council, Google described these events as “pull[ing] [out] all stops … to get Riot to stop their inhouse “app store” efforts and bring their billion dollar League of Legends franchise and other mobile games to Play.”
4015 On 11 January 2019, Mr Gennai in an email to Mr Srikanth Krishnamachari referred to “increasing app store competition on Android”, both from OEMs looking to increase services revenue or differentiate devices with content, and from “other large platforms (like Epic)”.
4016 In January 2019 in a presentation for the “Play Monthly” meeting, there was reference to “Android risk that game developers stop distributing (or distribute less) on Play”, which was elaborated as “Store rivals aggressively competing for game dev attention and exclusive content –> many devs evaluating other distribution options”.
4017 Clearly, this was specifically an Android risk, that is, it was occurring within the Android ecosystem. And as I have indicated, the fragmentation risk was a subset of the risks that Project Hug was to address.
4018 Now Ms Kochikar was asked whether this risk was a major concern of Project Hug and she described it as “a concern”. Ultimately, she said that it “was a key concern, yes”. Ms Kochikar was then asked what the major concern of Project Hug was, if it were not fragmentation risk. It would seem that fragmentation risk was the major concern.
4019 Now the January 2019 presentation referred to various other matters, all of which were said to create “risk that major devs de-prioritize Play, which is bad for Play’s business, but also damages the UX on Android as Android distribution is fractured”. As Epic correctly said, by “fractured”, Google meant that users might come to the Play Store and not find the app they were looking for. Clearly, it did not want an app to be found elsewhere on Android but not on the Play Store.
4020 Further, the presentation went on to identify what was a key goal of Project Hug, namely, to “[m]otivate developers, particularly those at higher risk … to prioritise Google Play”. This involved “Prioritz[ing] Play (+Android)”, which had four aspects to it: (a) “[s]im-ship on Android and iOS”; (b) [l]aunch on Play on “day 1” of Android launch; (c) “[k]eep title available on Play”; and (d) “[p]rioritize Play over 3P Android distribution points”.
4021 Now it was put to Ms Kochikar that sim-ship on Android and iOS was something Google wanted to achieve, but it was not the principal reason that Google was undertaking Project Hug.
4022 Indeed, in Ms Kochikar’s 11 October 2018 email she made it clear that the purpose of Project Hug was “to address fragmentation WITHIN the Android ecosystem” and that premium games launching first on iOS was something that had “ALWAYS” occurred, and was a separate issue caused by technical debt.
4023 It was also put to Ms Kochikar that the reason Google was doing Project Hug was to address fragmentation within the Android ecosystem, but her answer was that “[i]t was a reason. Sim-ship with iOS was an equally important reason”. But this was not saying that sim-ship with iOS was more important than addressing fragmentation within Android.
4024 Further, Ms Kochikar agreed that it was an objective of Project Hug to achieve prioritisation of the Play Store over third-party Android distribution points, but denied that this was a key objective and added unresponsive evidence about her work being “so focused on iOS”.
4025 I agree with Epic that unresponsive answers of this kind, adding gratuitous references to iOS or competition, peppered Ms Kochikar’s evidence. They demonstrated her propensity and eagerness to act as an advocate for the position that Google was pushing to me on the purpose of Project Hug. In my view, although the question of sim-ship was of course an issue, it was not the key purpose.
4026 Further, in February 2019 in the executive summary of a Project Hug presentation so dated and titled Mobile Game Developer Support (Project Hug), which both Ms Kochikar and Mr Gennai saw at the time, Google described the context for Project Hug as one in which “[g]ame developers have more, and more attractive, mobile distribution choices / channels on Android than ever before”.
4027 Now as Epic points out, the words “mobile” and “on Android” make explicit that Project Hug was primarily seeking to address the risk to Google of developers choosing to distribute their Android mobile apps elsewhere within the Android ecosystem but outside the Play Store. The executive summary observed that “Google can lower developer propensity to churn from Play, and boost developer adoption of other Google products and services, with x-PA ‘service packs’ designed to meet the needs of each segment”.
4028 Further, the presentation identified the “Increasing Distribution Competition” as “3P platform stores (e.g., Amazon) and OEM stores” and “[d]evelopers exploring 1P solutions (e.g., Epic).” Clearly, this referred to competition within the Android ecosystem.
4029 Further, there was reference to “[d]eveloper churn risk”. The “churn risk” was that developers would stop distributing or distribute less on the Play Store and shift their distribution to another Android app distribution channel. The “churn risk” was a focus of Project Hug. Clearly, the emphasis was on risks to Google posed by other modes of app distribution within the Android ecosystem.
4030 Further, the goals of Project Hug were described in the presentation as “Desired Developer Behaviours” that included “[l]aunch on Play on “day 1” of mobile launch” and “[m]aintain game parity across platforms”. If both of those goals were achieved, no third-party app store would be able to offer content from the Hug developers that was different from the content offered by the Play Store. Further, if both of those goals were achieved, none of the Hug developers would be able to distribute directly to Android device users content that was different from that which was available on the Play Store.
4031 Now by the time of the presentation, Google had identified 22 gaming app developers as the targets of Project Hug. These were said to “[d]rive disproportionate value to Google” and to be “[b]eacons of the ecosystem”. I agree with Epic that the latter phrase should be understood as meaning what it says, namely, that other developers in the ecosystem were likely to follow the lead of these 22. Apparently, the 22 developers were chosen because they had the greatest number of users and the most prolific games on Play and because, wherever they went, users and developers were likely to follow, or so Google perceived.
4032 The presentation also included the words “[m]ay forgo Play (& Android)”. When asked whether the focus of Project Hug was on preventing fragmentation within the Android ecosystem, Ms Kochikar agreed that that was an objective, but added “and Android” was “an equally important objective”. Now there are stray references to iOS and cryptic phrases like “and Android” in the contemporaneous documents, but nothing to demonstrate that preventing developers from forgoing the Android ecosystem altogether, or competition with iOS, or building “mobile first games”, was a major or even an equally important purpose of Project Hug.
4033 Instead, the contemporaneous Project Hug documents show that Project Hug was predominantly concerned with the risks to Google of alternative app distribution channels within Android, and how to mitigate them.
4034 When I asked Ms Kochikar about the thrust of the February 2019 presentation, she agreed that Project Hug was essentially about the possibilities within the Android ecosystem and minimising the churn away from the Play Store.
4035 Now Mr Gennai was also cross-examined about the words “[m]ay forgo Play (& Android)” in the February 2019 presentation. The following exchange occurred:
MR RICH: Now, the – at the bottom on the right, there’s a bolded heading that says – or bolded wording that says:
May forego Play (& Android).
Do you see that?
MR GENNAI: I do, yes.
Q: Now, you agree with me, don’t you, that a large developer like ABK, for example, was not going to just abandon three billion Android device users and just go to iOS, was it?
A: Ideally not on a persistent basis, no.
Q; You didn’t see that happening, did you?
A: Did we – did we see them never launch an app? Eventually, they would launch an app. We saw long periods of time with delays.
Q: I’m not asking you about launching an app, sir. I’m asking you about whether you saw it happening – that is, that ABK was going to abandon three billion device users and just go to iOS. You didn’t see that happening, did you?
A: ABK specifically? I don’t recall.
Q: You agree with me that that was not going to happen, and you didn’t think that was a likely prospect at all, did you?
A: At launch, we absolutely saw that happen.
Q: Your concern was that these developers may forego distribution on the Play Store and go elsewhere on Android, wasn’t it?
A: It was a combination of things that I think are expressed on this slide.
Q: Can you answer my question: yes or no?
A: It is incomplete.
4036 But the answers given by Mr Gennai are inconsistent with those he gave in cross-examination during the US trial. There, Mr Gennai said that developers “could just withdraw from Android entirely and keep focusing on iOS” but when the US cross-examiner confronted him with the question that was put to him before me, he confessed “[w]e didn’t see it” and when asked to confirm “You did not see that?”, he agreed “No”.
4037 Before me, Mr Gennai used phrases like “[i]deally not on a persistent basis”; “did we see them never launch an app? Eventually, they would launch an app”; “ABK specifically? I don’t recall”; and “[a]t launch, we absolutely saw that happen.”
4038 Moreover, in the US, when counsel suggested that the risk was that these developers “could leave Google Play and go elsewhere on Android, and that other developers might follow suit to alternative app distribution channels on Android”, Mr Gennai said “[y]es”. But before me, when it was put to Mr Gennai that the concern “was that these developers may forgo distribution on the Play Store and go elsewhere on Android?”, he did not agree, saying “[i]t was a combination of things that I think are expressed on this slide” and declined to give a yes or no answer.
4039 After he was shown the US transcript, Mr Gennai changed tack again, pretending not to understand the word “abandon”, a word which he had no difficulty understanding and responding to in the US trial. He then changed the subject by talking about whether developers would “launch on iOS first before Android”. But a temporal preference for launching on iOS first has nothing to do with abandoning or forgoing Android. Indeed, after a lengthy objection, Mr Gennai was squarely asked “[y]ou do not understand the phrase, “abandon three billion Android devices” to mean launch first on iOS, do you?” and he agreed “I do not, no”.
4040 Mr Gennai then gave evidence in which he largely accepted what had been put to him initially, being that the Project Hug developers were not going to abandon Android and he did not see that happening, but that he was worried about that. His cross examination elicited the following:
MR RICH: Now, you agree with me, don’t you, that large developers like those the subject of Project Hug were not going to forgo distributing their apps to three billion Android devices, were they?
MR GENNAI: Eventually, they would likely.
…
Q: Your assessment at the time was that these large developers, the target of Project Hug, would continue to distribute their apps on the Android ecosystem into the future, wasn’t it?
A: That it would be likely.
Q: And you didn’t think there was a realistic prospect that these particular developers would cease to distribute their apps to the Android ecosystem in the future, did you?
A: I was – I was worried about that.
Q: I suggest to you you weren’t worried about that – that you didn’t see it happening?
A: I didn’t see it happening.
4041 Now when it was pointed out to Mr Gennai that his claim that he was worried about the Project Hug developers ceasing to distribute their apps on Android was inconsistent with his evidence in the US trial, he claimed to have misunderstood the word “abandon” both during the US trial and before me.
4042 In my view, the answers that Mr Gennai gave in the US trial were accurate, but he sought to avoid giving the same answers before me.
4043 Let me deal with another aspect of Mr Gennai’s evidence concerning his 19 February 2019 email to Mr Samer Sayigh and Mr Shafiq Ahmed.
4044 In his affidavit he referred to his 19 February 2019 email in which he said that one of the reasons he favoured Project Hug was that it targeted the largest game developers which had the most options available to them. Mr Gennai claimed in his affidavit that what he meant by this was that those developers:
… have many alternatives to launching on Google Play. They can launch on other platforms (PC, console, iOS), launch on other Android app stores, create their own Android app stores or use sideloading, among other options. I considered that these alternatives meant there was a real risk Google Play would lose one or more of these game developers. …
4045 But that evidence was problematic, as is apparent from the text of the email, particularly the second half.
4046 The email was referring to other options within the Android ecosystem only, contrary to the impression that Mr Gennai sought to create that Project Hug was substantially also concerned with competition with iOS, consoles, and PCs.
4047 The entire email string is worth setting out here to demonstrate that point.
4048 On 19 February 2019, Mr Gennai said to Mr Sayigh and Mr Ahmed:
Okay, have been doing some thinking based on our chat at 4. Apologies for the stream of consciousness, but I’ve been meaning to get some of this out of my head for a while now.
The big question: Why Hug and Banyan at the same time / how should we think about investment?
Three top level problems we’re looking to solve:
1. Scaled developers with major brands (either a single title or a portfoliio (sic) can decide to go-it-alone / develop their own distribution [Epic, Riot, Tencent]
2. OEMs / carriers with existing distribution can enter the app distribution business, with the aim of differentiation. Lowers the need to directly earn revenues, focuses their competition on rev-share + incentives for exclusives [Samsung, OneStore, Huawei]
3. OEMs / carriers looking to maximize dollars earned per device preload other stores for a quick dollar [Amazon]
I realize there’s others on the list (emulators, etc.), but these, to me, are the largest / most pressing.
There’s shared problems in all instances:
* Revenue loss from fragmented user behavior (direct loss)
* General Android perception / share loss (indirect loss, but very large)
* User security and privacy (indirect loss, feeds into the above)
We can solve these problems by changing some combination of developer and OEM / carrier behavior. If either get entirely solved, our risk goes away.
Solving either side is a question of scale. Some ideal world exists where (2) and (3) solved through contracts and incentives, and the GMS Android works more like Apple. However, I’d contend that this isn’t practically possible, needed or potentially even preferable.
* Possible: Even with rational economics, partners aren’t always rational. For instance, it’s coin-flip whether Samsung is truly interested in engaging. OneStore / Korean telecoms providers certainly won’t, even if they wanted to
* Needed: Smaller stores aren’t really an issue here, it’s an issue when there’s the perception of multiple platforms. The “3 store strategy” point
* Preferable: Android is open, and we need to keep it that way. I don’t think it’s in anybody’s interests to reduce down to one distributor
This is all a long way of saying: If a store is becoming large enough that it appears to be a true platform on a platform / builds user awareness, it can have effects that we truly need to consider. This is how I think about Samsung. But we have no idea if they’re really going to come to the table.
For other OEMs, it’s a question of whether they’re really capable / interested in starting their own store vs. taking quick money from others. This is where Amazon could play. If Amazon were to make a scaled play across the non-Samsung OEMs, we’d have something to worry about. But that doesn’t seem to be playing out right now, at least on the app store side. If it did, we’d likely want to invest some money to protect. Again, the issue is about big stores having mind-share, not lots of smaller competitors.
So, if all that’s true, why do Hug? I would say there’s a few good reasons:
1. As I’ve said above, I strongly doubt that we’ll be able to get a firm hold on distribution through incentives. There’ll always be reasons for competition here, but hopefully we can keep it healthy.
2. The largest developers are those that have the most options available to them. Some can go-it-alone, others can be persuaded by other stores (which, per 1, will certainly still exist), and others will look for direct distribution through preload
3. We have no idea what things will look like in 5 years time, but developers using more Google services will be safer than those that aren’t. As platforms shift, things move to streaming, etc., we don’t want the perception of Google to be “they deliver file blobs to services”. A developer building on Google Cloud will be much more valuable to Google
4. Irrespective of any of this, it’s useful to contend against the ‘app store tax’ meme, irrespective of what position we land in. I recognize though that this is super hard to value
So should we invest in Hug right now? Yes. Should we do that in a way that the investment can be scaled back as things begin to feel safer (if ever)? Also yes.
…
4049 On 21 February 2019, Mr Sayigh replied:
A few points to underscore:
* While it makes sense to focus the risk assessment on Play revenue, let’s not lose sight of non-Play risks associated with fragmented app & game distribution on Android. User experience / perception on Android could be negatively impacted, including security / malware concerns (headlines like this & this also don’t help Google’s ‘Trust & Safety’ OKR). More prevalent exclusives can also lead to catalog gaps and restricted title availability across Android, which isn’t a great user experience. The potential impact to Android retention would be more concerning than Play.
* As a reminder, Hug has 3 goals (more detail here):
1. Devs prioritize Play (this could partially be solved via influencing OEM / carrier behavior, but agree with Paul’s points around why its highly unlikely that we solve all of this via OEM / Carrier)
2. Devs adopt more of Google’s services (unique to Hug; not addressed by OEM / Carrier).
3. Devs improve sentiment around Play revenue share, as we boost value (unique to Hug; not addressed by OEM / Carrier). This can help reduce pricing pressure on Play / helps us avoid a price war. We want the narrative to be, “Sure other channels can offer better pricing, but we offer a whole lot more for our price (we’re not just a dumb pipe and payment processing)”. Ideally, our developers champion this…
Super good points
The x-PA credit programs help us progress goals 2 & 3 (which are effectively what Paul references at the end of his note in #3 and #4).
I also think we can include mechanisms which allow us to modify and/or dial down the targeted service packs as needed in future years… But that’ll be harder to do specifically for the broad-based, public credit programs.
4050 On 22 February 2019, Mr Gennai further replied:
Ahead of the meeting this afternoon, I wanted to give some more context on a conversation with Jamie yesterday. Samer’s already heard much of this.
As you already both know, Jamie’s very eager to get a plan up to Ruth for approval ASAP. In my discussion, I noted that the broader credit program for the torso / tail is still under a lot of operational review and detailed design, but his comment was that we shouldn’t wait to secure broader approval for the idea from Hiroshi and Ruth while we wait for that to be complete. His hope is that we could secure provisional approval on the basis of sorting through the execution challenges. Note that he’s fully aware that it's impossible at this stage to announce at GDC given how early a signal that would provide. Perhaps we can shoot for IO.
We then talked in pretty good detail about the issues around sizing the problem / approaching it from two different angles (Hug and OEM agreements). A few thoughts out of that:
* Hug shouldn’t be proposed purely as a defensive measure. In addition to better enabling developer loyalty in the near term, there is a large component that is about driving incremental usage of a broader set of Google products. This means that the spend comes at a discount on the ads side (revenue comes back + additional spend from new users that the UA acquires), can spur a nascent business on the Cloud side, and generally aligns developers closer to us as we developer newer businesses (Yeti, etc.)
* There is an aspect of this that’s about getting ahead of pressure on the 30%. We don’t know what Samsung is exactly going to do, what Huawei could do, and what Epic and others are already doing. In this regard, I actually wonder if there’s an aspect here of comparing the Hug cost to what a broader switch to 80/20 rev-share would look like if pressure were to escalate there
* Assuming that we can get Samsung (or any other OEM) on-board is one hell of a bet, and while we’ll try, it can’t be guaranteed. And, irrespective of what we do there, other competitors will remain: Amazon, One Store, and others. Right now is the time to intuitively invest to stay ahead of things
So, all this is a long way of saying that Jamie wants to get a proposal lined up quickly :-)
Looking forward to discussing this afternoon
4051 Now another document prepared by Google in February 2019 and around this time, although incorrectly dated February 2018, was titled Project Hug: Risk & Leakage Model, which described how “[d]evelopments in the ecosystem are motivating and creating opportunities for partners to explore Play alternatives” and noted that “[e]cosystem partners are investing in Game Distribution + exclusive content acquisition”. It then identified and assessed alternative distribution channels.
4052 Now the alternative distribution channels assessed by the risk and leakage model for Project Hug were all Android distribution channels. And Ms Kochikar agreed that it was the risk of increasing distribution through these alternative Android distribution channels that Project Hug was intended to address.
4053 The first alternative identified by the risk and leakage model was distribution via OEMs, and specifically, “Samsung app store goes big with exclusive AAA games, building a gaming distribution platform”. Google’s working hypotheses relevant to that scenario included that “Samsung is the only OEM with sufficient share to plausibly build its own store in key Play markets”. In other words, no other OEM’s app store had a market share sufficient to threaten the Play Store in key markets.
4054 The second alternative identified by the risk and leakage model was distribution by developers themselves, either through “[m]ajor gaming platforms build[ing] a store with titles from multiple developers” or an “AAA gaming developer goes direct through side- or pre-loading”. Google’s working hypotheses relevant to that scenario included that “[m]ajor of any new distribution platform”. It is to be noted that the word “platform” was used here to describe another form of distribution on Android.
4055 Another working hypothesis adopted by Google at the time was that “[u]sers would switch to a new distribution channel only with a strong draw - exclusive titles, device UX, and/or sustained pricing advantage”.
4056 The risk and leakage model also explained that “Hug can mitigate the early, riskiest stages” of the development of an alternative Android app store. It could do so because participation in Project Hug would prevent exclusivity, and Google’s assessment was that the risk probability of another store taking revenues from Play was very low whilst that store had “few exclusives”. Clearly, Google was cognisant of the importance of securing exclusive content to the prospects of a rival store successfully enticing users away from the Play Store.
4057 Google appreciated at that time that if developers participated in Project Hug, that would prevent any other Android app store from securing their titles exclusively. And clearly Google understood that an effective way to hinder the development of third-party app stores would be to deny them exclusive access to titles from Project Hug developers.
4058 Now Ms Kochikar gave the following evidence:
MR RICH: Ms Kochikar, do you agree that an effect of the deals that were done as part of Project Hug was to prevent other Android app stores from being able to offer differentiated content from the Hug developers?
MS KOCHIKAR: That is an effect, yes.
Q: And do you agree with me that Google understood when it was rolling out the Project Hug agreements that that would be a likely effect of those agreements?
A: A likely effect, but we didn’t know whether developers would sign these contracts.
Q: Indeed. But you – do you agree with me that Google understood that if developers signed the Project Hug agreements, those agreements would have the effect of preventing any third-party Android app store from being able to offer differentiated content from these developers?
A: Yes. That’s what this is saying, so it’s on the document.
Q: Do you agree with me that that was an effect which Google intended to achieve by the Project Hug agreements?
A: I’ve never heard that as a stated purpose for Project Hug in any of our discussions.
Q: Well, I suggest to you that that was – that was a purpose of the program from the beginning?
A: I would say no.
4059 Now I do not accept Ms Kochikar’s denials of an anti-competitive purpose.
4060 First, she admitted that Google understood that that would be the effect of the agreements, and I do not accept that Google did not intend to achieve an effect which it was aware of when the agreements were made.
4061 Second, her denials are inconsistent with the text of the risk and leakage model, including one of its diagrams which was as follows:
4062 Google set out to mitigate the early and riskiest stages of the development of alternative Android app stores by preventing them from obtaining exclusive or differentiated content from the Hug developers.
4063 On 28 February 2019, Mr Kumar, who was a member of Mr Gennai’s strategy team, sent an email to Mr Gennai titled Hug vs Banyan, which contained the text of and embedded a link to what Mr Kumar described as “a memo that lays out the rationale and how we are thinking about the investment across different constituencies”. A memorandum in virtually identical terms to the email version was discovered from the electronic files of Ms Kochikar.
4064 The text of the memorandum contained within the email laid out “the case of why we need to invest in different constituencies”, those being OEMs, developers, and users. It addressed the “order of investment”, as follows:
…
For any alternative mobile store to be successful at scale (success defined as combination of adoption scale and financial success for the store operator & developers). So, critical mass of Android gamers and titles migrate to alternate store and generate meaningful customer spend), it would need at least a couple of titles from our top ~25 developers identified by Hug (they represent biggest IP, command large user base and disproportionate share of consumer spend). This is true irrespective of which scenarios we are analyzing, be it carriers store, Epic Store, Galaxy Store, Amazon, etc. They are also the primary contributors to Play numbers – quarter over quarter.
So, based on the above two strategic reasons, we recommend that we do Hug first (which in turn, will help lower the likelihood of all other scenarios). …
…
4065 This reveals that Google’s view was that no alternative mobile store would be successful at scale without titles from the developers targeted by Project Hug. And it reveals Google’s perception that Project Hug would lower the likelihood of all other scenarios it was analysing, including potential competition from Epic, Samsung, and Amazon. Project Hug was likely to have that effect because it would prevent those rival stores from obtaining exclusive or differentiated content from the very developers whose content those rival stores needed to be successful at scale.
4066 Now although Mr Gennai was not prepared to concede that others necessarily shared the views recorded in Mr Kumar’s email, nevertheless the email began by saying that the memorandum “lays out the rationale and how we are thinking”. No evidence was given that anyone at the time expressly disagreed with Mr Kumar.
4067 In any event, at the time of Project Hug Ms Kochikar agreed with the view that “[f]or any alternative mobile store to be successful at scale … it would need at least a couple of titles from our top ~25 developers identified by Hug”, although she said under cross-examination “but it doesn’t say ‘exclusively’ over here”.
4068 But Ms Kochikar had said that at the time of Project Hug, her view was that users would switch to a new distribution channel only with a strong draw being exclusive titles, device UX, and/or sustained pricing advantage. And she accepted that it was understood within Google that if it could bring about a situation where major game developers were unable to distribute exclusively outside the Play Store, then users were unlikely to switch away from the Play Store to another distribution source on Android.
4069 Later in her cross-examination Ms Kochikar gave the following evidence:
MR RICH: Now, at this time, when Project Hug was being rolled out, Play Store already had lots and lots of users; correct?
MS KOCHIKAR: Yes.
Q: Other Android storefronts didn’t have nearly so many users; correct?
A: Yes.
Q: And in order to entice users away from Play, the other app stores on Android likely needed differentiated content from Play; correct?
A: Probably.
Q: And Project Hug denied that possibility, so far as the participating developers were concerned, didn’t it?
A: As an effect, yes.
4070 In summary to this point, I have little doubt that Project Hug was predominantly concerned with addressing the choices available to developers within the Android ecosystem. But of course that is not inconsistent with it also being concerned with iOS to some extent.
4071 Now on 26 March 2019, Mr Gennai wrote what has come to be known before me as the Play problem statement. The metadata indicates that the document was also held in the electronic files of Mr Rosenberg, Mr Samat, Ms Kochikar, and Mr Wang. Mr Gennai accepted that he likely shared it with Mr Rosenberg, but he was not sure whether it was he or Mr Rosenberg who shared it with the others.
4072 The Play problem statement began with an observation that “the long-standing growth and (potentially) fundamental business model of Google Play is under pressure in 2019”. This was said to be “driven by a confluence of factors”, including the “size and margins of the market making it attractive for new entrants”.
4073 Mr Gennai maintained that he was referring to the “market”, not to the Play Store, but given that the Play Store’s market share is over 90% in the context of Android app stores this distinction does not make any difference to the substantive point. And Mr Gennai was clearly referring to the Play Store’s margins and not the margins of other Android app stores with very small market shares.
4074 Further, by “new entrants”, Mr Gennai meant companies that wanted to compete with the Play Store in the distribution of Android apps. And clearly he anticipated that those new entrants may compete on price, that is, revenue share.
4075 Now another factor identified in the Play problem statement as putting pressure on the Play Store’s business model was a “meme” related to the “app store tax … putting pressure on Play’s 30%” and “[l]arger developers who have more standalone capabilities (and often differentiated content) are leveraging this discontent to attempt to negotiate differentiated rates or go-it-alone”.
4076 Mr Gennai agreed that by “go-it-alone”, he was talking about distribution elsewhere on Android and was not talking about developers forgoing Android and going to iOS. He meant developers distributing their own apps within the Android ecosystem.
4077 The Play problem statement then declared that “[t]hese problems are very real and playing out in the market in 2019. Epic/Fortnite, Galaxy Store, conversations with large developers at GDC, etc.”. Mr Gennai continued “[w]e propose to solve these challenges through a combination of tactics that are required in conjunction”.
4078 Let me now address the three tactics Mr Gennai outlined to address these challenges, with the first tactic being Project Hug.
4079 The explanation of that tactic supplied in the Play problem statement focused on the benefits that Google would provide to the Project Hug developers, rather than on what Google would get in return for those benefits.
4080 Now when Mr Gennai referred to “competing on price (rev share)” as “prone to be a race to the bottom”, he meant that reducing the Play Store’s service fee in response to lower fees that may be offered by new entrants was likely to drive prices down.
4081 Mr Gennai denied this, suggesting that he was referring to negotiations with the Project Hug developers driving prices down. But that evidence was problematic to say the least.
4082 Google’s tactic was not to compete with new entrants on price across the board, but to offer special benefits to the small number of strategic partners targeted by Project Hug, and so lowering the effective revenue share rate for those few, whilst maintaining the prevailing rate for every other developer.
4083 What is left unsaid in the Play problem statement is that the quid pro quo for lowering the effective revenue share rate for strategic partners included obligations to “[l]aunch on Play on “day 1” of mobile launch” and to “[m]aintain game parity across platforms” such that no new entrant would be able to offer content from those strategic partners that was different from the content offered by the Play Store.
4084 This was important because as Mr Kumar explained, “[f]or any alternative mobile store to be successful at scale … it would need at least a couple of titles from our top ~25 developers identified by Hug”. That is why Google felt it did not need to compete on price “across the board”. It was enough to keep the strategic partners happy, because without differentiated content from them no new entrant was likely to succeed. Mr Gennai denied this, but that was his logic and it is consistent with the contemporaneous documents.
4085 The second tactic was expressed to be “Samsung (and maybe Huawei)”.
4086 Now when taken to that tactic, being specifically Mr Gennai’s own words that “the defense of Google Play as the preeminent Android app distribution store can be focused around major points of distribution”, Mr Gennai disowned this comment and the Play problem statement generally.
4087 He said that “it was a tactic being discussed on the team”, and he said that “this email is summarising conversations that I had heard.” He also said that “[i]t’s the team – the team’s ideas”. He also said that he was “trying to clarify what I think the team’s point of view is”.
4088 Again, that evidence is problematic. The document itself, which Mr Gennai admits writing and providing to his superior, states that “[w]e propose to solve these challenges through a combination of tactics that are required in conjunction”.
4089 Mr Gennai’s next move was to claim that the second tactic related to defending the Play Store against competition from the iOS App Store. Yet it had nothing to do with defending against competition from iOS. Mr Gennai’s own words in the Play problem statement make explicit that the second tactic was about “the defense of Google Play as the preeminent Android app distribution store”. Moreover, that tactic was required to solve the challenges identified earlier in the document, none of which pertained to competition from iOS.
4090 What the second tactic was about was tightening access to the Android ecosystem, particularly by “aligning”, that is, co-opting, the “largest OEMs around Play as an app distribution source”. Mr Gennai conceded that in referring to Samsung, he likely had in mind an arrangement with Samsung of the sort proposed in the March 2019 Project Banyan presentation, which I have previously referred to, where the Galaxy Store would become an extension of the Play Store and cease to compete with the Play Store.
4091 The third tactic described in the Play problem statement was “the business model project”. Mr Gennai said that he did not remember what project he was talking about. Nonetheless, he confirmed that his view at the time was that the prevailing 30% revenue share may not be sustainable and that Google ought to change the business model, or at least the revenue share rate, before regulators forced Google to do so.
4092 Let me now say something about the approval of Project Hug.
4093 Now as I have said earlier, on 8 April 2019, an email was sent by Mr Murphy to Google’s business council and numerous senior executives pertaining to Project Hug and Project Banyan. So far as Project Hug is concerned, the email attached materials and identified that one rationale in support of the program was to mitigate the risk that top game developers de-prioritise the Play Store for title distribution, and so reduce developer churn and protect users’ experience.
4094 And as I have said earlier, on 9 April 2019 the business council met for the purpose of considering whether to approve Project Hug and Project Banyan. As I have said earlier, there was a presentation made to the business council which stated that developers were increasingly considering distribution off the Play Store through alternative Android channels, and that this could entail significant Play Store revenue/margin loss. But reference was also made to Android-to-iOS churn.
4095 The minutes of the business council meeting contained in an internal email from Mr Murphy on 9 April 2019 record that the discussion canvassed “[i]ncreasing tension in ecosystem”. Ms Kochikar, who attended the meeting, agreed that that was a reference to the Android ecosystem.
4096 The minutes also record discussion about the “risk of disintermediation in specific market niches” and note that the “challenge is to demonstrate more value for revenue share or face risk of migration to competing app store platforms”. The “risk of disintermediation” referred to a risk of distribution occurring on Android outside the Play Store, and the “competing app store platforms” were Android competitors.
4097 Indeed, the minutes confirm that Project Hug was “designed to mitigate against downside risk for Play Store”. The minutes do not record any discussion about iOS.
4098 Now another shorter April 2019 presentation of 7 pages titled Project Hug: Boosting Top Game Developer Support, Across Google which summarises the key aspects of Project Hug and which is marked “BC approved” begins with the proposition that “[m]obile gaming is a large and growing opportunity (and competitors are very aware!)”. So, Google perceived that it faced existing competitors on Android who were aware of the growing commercial opportunity presented by mobile gaming and were positioning to compete for it. I also note that this presentation stated “[n]ew developer types are pursuing mobile (e.g. AAA PC / Console developers)”. There was also a reference to the targeting of 22 developers as “[b]eacons of the ecosystem”. It is worth setting out the following slides from this presentation:
4099 Further, the specific 9 April 2019 presentation that I referred to earlier identified a number of “challenges” including “[i]ncreasing competition (OEMs, 3P Stores)” which meant that there was a “risk of top developer churn”. Another challenge was the fragmentation risk and its consequences in terms of a loss of users to iOS. The presentation recorded “Android-to-iOS churn, due to fractured app distribution and security risks on Android”.
4100 Under the heading “context”, it was recorded that “Play’s business is concentrated among top developers” and that loss of those developers “either to competitors or by ‘going-it-alone’ on Android, would significantly impact Play’s business”. The same slide recorded that 3% of buyers, being the “HVUs” (high-value users), accounted for 50% of spend in apps and games.
4101 Under “[r]ecent ecosystem trends”, the presentation stated that competitors were aggressively pursuing gaming. The listed competitors included the Samsung Galaxy Store, Amazon App Store, OneStore and Epic Games Store:
4102 The slide records that the Play Store’s competitors were pursuing a range of competitive strategies. The Samsung Galaxy Store was offering 20% revenue share and was pursuing top titles as both exclusive titles and co-listed titles. OneStore was offering a 20% revenue share and allowed third-party billing with 5% revenue share. The Amazon Appstore was funding in-app purchases by offering discounts of up to 20% to attract users. The Epic Games Store was anticipated to launch a mobile store in 2019 or 2020 and to offer 12% revenue share on mobile. So, the Play Store’s rivals were pursuing a range of competitive strategies, including competition on price. Now whilst the Samsung Galaxy Store, Amazon App Store and OneStore were each smaller than the Play Store, each had a meaningful share of monthly active users in the countries in which it overlapped with the Play Store.
4103 Further, the presentation set out an assessment of the financial risks to the Play Store’s revenues posed by these threats:
4104 Now in terms of this slide, the two largest threats identified in terms of lost revenue and margin to the Play Store were the Samsung Galaxy Store and the Amazon App Store. Those were the Play Store’s largest and most longstanding competitors on Android. Again, this underscores that the threat Google perceived was from extant competitors on Android.
4105 Whilst the Epic Games Store and developer stores were also considered, the business council was not considering the issue as one of potential future competition. As it saw it, the competition was coming from its primary competitors on Android, with whom it had competed directly for many years. The concern as presented to the business council was not principally about a threat posed by new entrants or some other nascent threat at all.
4106 Further, the slide repeats the concern from the Fortnite deal review that the loss of these large developers from the Play Store would lead to churn from Android to iOS. The concern with fragmentation was repeated, with the slide noting “[f]riction navigating various app stores” and “[t]op titles not available on all devices”, as would occur, for example, if titles were only available in one OEM’s app store.
4107 Further, the minutes of the discussion at the 9 April 2019 meeting of the business council record that one observation made during the discussion was that the “challenge is to demonstrate more value for revenue share or face risk of migration to competing app store platforms”. This was a reference to other Android app stores.
4108 So, the challenge as understood by the business council was to demonstrate to developers that the GVP agreements would give them “more value” for the the Play Store revenue share that they were paying. In other words, it was to demonstrate that, under the GVP, they would be getting an effective discount on the Play Store’s service fee.
4109 In this way, the program was understood by Google’s business council as involving, in essence, the offering of discounts to key developers to stop them switching (or “migrating”) to rival Android app stores. In other words, it involved offering better prices to existing customers to stop them leaving to competitors.
4110 On 19 April 2019, Google’s business council approved the Project Hug and Project Banyan proposals.
4111 Let me now turn to the implementation of Project Hug and the entry into of the GVP agreements.
The Games Velocity Program
4112 Now following the business council’s approval, Google proceeded to implement Project Hug, which was rebadged for external consumption as the Games Velocity Program or GVP in short.
4113 Now whilst that was occurring, on 11 June 2019, Mr Samat sent an email to Ms Kochikar saying, on the assumption Google did not do a deal with Samsung, that “we should think about how to compete”. He reasoned that Samsung’s tactics “will be straightforward” and will include “[e]xclusives and unique content”. Ms Kochikar responded by saying “Hug provides terms to prevent Samsung exclusives for the most lucrative and risky devs (22 currently). We believe this will persuade other devs to follow suit.”
4114 So, Google was aware, whilst the GVP arrangements were being negotiated, that the arrangements would deny Samsung the ability to pursue one of its more likely tactics to compete with the Play Store, namely, obtaining exclusive content. This would make it more difficult for Samsung to compete against the Play Store. That was a substantial purpose of the GVP arrangements.
4115 Further, a Play Apps & Games update dated 18 July 2019 described Project Hug as “[d]e-risking 3P stores”. Ms Kochikar received that presentation and likely attended the relevant meeting. So, Project Hug de-risked for Google third-party app stores by preventing any of them from obtaining differentiated content from any of the targeted developers. It is clear to me that the de-risking was an intended effect of Project Hug.
4116 Now by December 2019, nine of the 22 targeted developers had signed GVP agreements with Google, eight developers were actively reviewing GVP agreements, four developers being Tencent, Activision, Blizzard and Supercell were holding out, and one developer had been removed as a target due to underperformance.
4117 According to an internal Google email dated 11 December 2019, one of the hold outs told Google that if a deal could not be reached, “they will launch their own mobile distribution platform” in partnership with another company, which Google presumed was Epic.
4118 By August 2020, 18 of now 21 targeted developers representing “18% of total Play spend” had signed GVP agreements, with “$390M Play margin loss risk mitigated (2019-2020)”. Project Hug was assessed as meeting objectives and effective at mitigating margin loss risk from off-Play distribution.
4119 Now one remaining hold out was Tencent, which held interests in several game developers, including four of the top ten top grossing game developers on the Play Store accounting for 12.5% of Play Store revenue collectively.
4120 Google’s strategy for engaging with Tencent was predicated on a belief that Tencent’s evolving business strategy would likely lead to both partnership opportunities first, then direct competition with Google. According to an October 2020 presentation titled “Google – Tencent Engagement Strategy of Gaming”, Google speculated that Tencent “is likely to develop its own or leverage its portfolio companies’ platforms for game distribution, content distribution and community development once it gains momentum”, in which scenario “Tencent and its portfolio companies collectively will pose greater competitive risks to Google”.
4121 The goal which Google articulated was “to alter Tencent’s expansion path and keep it as a content provider”. Project Hug or the GVP was aimed at achieving that goal.
4122 Clearly, one of the goals of Project Hug so far as Tencent was concerned was to alter Tencent’s expansion path, keep it as a content provider, and prevent it from becoming a competitor.
4123 Google ultimately sought approval to offer Tencent a bespoke GVP deal which went beyond the standard terms, which approval was granted by the business council in June 2020. Tencent signed a GVP agreement with Google in December 2020.
4124 By June 2021, 20 of the now 21 targeted developers, representing 20% of Play Store spend, had signed GVP agreements. In May 2022, the final target, Supercell, entered into an agreement with Google. So, Google ultimately entered into agreements with each of the 21 gaming app developers targeted as part of Project Hug.
4125 Now the GVP agreements took the form of an addendum to each developer’s DDA.
4126 Under the GVP agreements, Google promised benefits such as marketing support, advertising credits, and a share of Google’s Play Store revenue from the developer’s apps to be provided in the form of Google Cloud credits. Google’s commitments were tailored to suit each developer. Google offered developers four service packs and developers were free to choose which of those were most beneficial to them. In exchange for Google’s commitments, developers generally agreed to commit to the following obligations during the term of the GVP agreement.
4127 First, they agreed to sim-ship which required the developer to release all mobile titles on the Play Store at the same time or before their release on any other mobile distribution channel, including iOS.
4128 Second, they agreed to promote all mobile titles on the Play Store in the same or an equivalent manner as the equivalent title was promoted on a comparable platform. I will refer to this as the promotion clause.
4129 Third, they agreed to ensure that the core content, features and functionality of mobile titles available on the Play Store were the same as on comparable platforms and through other mobile distribution channels. I will refer to this as the content parity clause.
4130 Fourth, they agreed to not remove any mobile titles from the Play Store unless required by Google, an applicable law, or as otherwise agreed in writing between the parties. I will refer to this as the non-removal clause.
4131 Fifth, they agreed to make good faith efforts to include each title in pre-registration, open beta, and other relevant early access programs. I will refer to this as the early access clause.
4132 Now only the sim-ship clause and the content parity clause, with some variation in their precise terms, appear in all of the GVP agreements. Some developers were otherwise able to negotiate out of the promotion clause, non-removal clause and early access clause.
4133 The sim-ship clause and the content parity clause were designed to ensure that users of the Play Store had access to equal content, both in terms of the timing of access and the quality of content, as the Play Store’s competitors including iOS.
4134 The sim-ship clause did not prevent developers from co-listing titles on rival app stores. The very nature of sim-shipping presupposes that developers would co-list their titles elsewhere. All that the GVP sought to achieve was to ensure that titles remained on the Play Store. Developers could distribute anywhere else on Android.
4135 The content parity clause applied to core content, features and functionality. It did not prevent other app stores and developers from negotiating for differentiated content to be made available to users. Core content, features and functionality refers to how a game is played. The content parity clause therefore required that the core gameplay be the same across different platforms and channels so that players on the Play Store were not disadvantaged against players on other platforms.
4136 So, the content parity clause did not prevent developers from offering differentiated content that was not core content, such as in-game cosmetics or skins, being costumes for in-game characters. Similarly, the content parity clause did not prevent developers offering promotions like customised marketing campaigns and discounts exclusively on other channels.
4137 In this way, the content parity clause did not prevent developers from offering differentiated content on rival app stores.
4138 Now two of the GVP agreements provided that in-game sponsorships, or promotional content or activities, should only be made available on other platforms for a limited period of time so as to prevent Play from being significantly or persistently disadvantaged, and that the developer should make good faith efforts to provide the same or similar sponsorship and promotional content for participating titles on the Play Store. But these requirements did not prevent the two developers from offering differentiated content. Indeed the two developers could do so for a period of time provided that the differentiated content did not significantly or persistently disadvantage the Play Store.
4139 Further, no other GVP agreement imposed any requirements on developers seeking to differentiate non-core gaming content and features on alternate distribution platforms.
4140 Further, the non-removal clause required developers not to remove any titles from distribution on Play for the term of the GVP agreement, which ensured that developers continued to make their games available on the Play Store for as long as those titles were still available through other channels and platforms.
4141 Further, the promotion clause required developers to ensure parity of promotion such that the Play Store would not be disadvantaged in terms of the quality and promotion of the developer’s apps.
4142 Further, the early access clause required developers to make good faith efforts to include their apps in pre-registrations, open betas and other early access programs on the Play Store.
4143 Now apart from the GVP agreement with Tencent, no GVP agreement contained a price parity provision. So, all of the other developers who entered into a GVP agreement could offer the same content on rival Android app stores, or other platforms, at lower prices than the prices offered on the Play Store.
4144 The Tencent GVP agreement obliged Tencent to ensure that prices for its Android apps on the Play Store were at least as favourable as the prices on any other platform, and to make available within the Play Store all product and service offerings applicable to its Android apps that are available on any other platform.
4145 Now as to the duration of the GVP agreements, after the term of the relevant GVP agreement expired, the developer’s obligations ceased. But Google’s commitments under separate addenda, for example the offer of Cloud credits, could continue to have effect according to the terms of those addenda, which could be renewed without renewing the terms of the GVP agreement.
4146 The period(s) of the GVP agreements varied as follows. Thirteen of them ran for near to or exactly three years, one ran for two-and-one-half years, one ran for two years, one ran for fifteen months, and two ran for one year or less.
4147 Now the GVP agreements achieved the goals of ensuring that the developer launched its Play Store apps on day 1 of their mobile launch, maintained content parity across platforms, and ensured that at no stage after launch and during the term would one of the developer’s apps be available elsewhere but not on the Play Store.
4148 Clearly then, those terms had the effect of preventing a rival Android app store from differentiating itself from the Play Store by offering content from the Project Hug developers that was not available on the Play Store.
4149 Now Mr Gennai denied that it was an important objective of Project Hug to ensure that no rival Android app store could offer digital content from the Project Hug developers that was not also available from the Play Store. But I agree with Epic that that denial is inconsistent with the contemporaneous documents and other evidence.
4150 It is clear that the effect of the sim-ship and content parity clauses in the GVP agreements shows that those clauses were not aimed at keeping popular apps on the Play Store, but at ensuring that rival stores would not have content from the Project Hug developers sooner, or that was different from, what was available on the Play Store.
4151 Those clauses were directed at hindering rivals from competing by enticing users away from the Play Store.
4152 Now Google says that the GVP agreements were made with a limited number of developers.
4153 But Google specifically targeted the developers with whom the GVP agreements were made because those developers were “beacons of the ecosystem”, that is, other developers were likely to follow their lead to any alternative Android distribution channel.
4154 Further, Google’s own assessment was that “[f]or any alternative mobile store to be successful at scale … it would need at least a couple of titles from our top ~25 developers identified by Hug”.
4155 In other words, to prevent any alternative mobile store from succeeding it was sufficient to enter into GVP agreements with a limited number of major developers, which is what Google did through Project Hug.
4156 I agree with Epic that if anything, the fact that Google only felt it necessary to enter into GVP agreements with 20 or so developers to smother the competitive threats that prompted Project Hug is demonstrative of both Google’s market power and of the effectiveness of Project Hug in neutralising those threats.
4157 Further, it is also essential to view Project Hug not in an atomised way, but as part of the broader scheme of restrictions that has been detailed in the evidence.
4158 Now Google says that Project Hug did not require the targeted developers to distribute their content exclusively through the Play Store. But the reality is that the Play Store was the incumbent. It already had the users.
4159 If rival stores were to entice users to switch away from the Play Store, they needed to give users a reason to switch. Merely offering the same content as the Play Store was not likely to entice users to switch.
4160 Further, Project Hug was not only about ensuring that key developers continued to distribute their apps through the Play Store.
4161 A substantial purpose was to make it unlikely that alternative Android app stores could succeed, by denying them the capacity to obtain differentiated content from targeted developers.
4162 Currently, only one of the GVP agreements with the initial Project Hug developers remains on foot. All other GVP agreements with those developers have expired. Let me turn to another matter.
4163 Now in June 2021, Google decided to extend Project Hug to nine additional developers, which extension became known as GVP 2.0. By that time, Google considered that the original GVP had met its objectives.
4164 It targeted GVP 2.0 at nine of the Play Store’s large and growing developers, one of which was Garena.
4165 An internal Google document from June 2019 describes Garena as “an increasingly high risk of disintermediation to Play”, having “all the key ingredients (users, brand, partnerships, payment infrastructure) in place to realistically pursue off-Play strategies.” GVP 2.0 was said to be “a strategic lever for us to incentivize Garena and mitigate these disintermediation risks”.
4166 Ms Kochikar accepted that the concerns about contagion risk and off-Play distribution which motivated Project Hug continued in relation to GVP 2.0. She agreed that the purpose of GVP 2.0 was to mitigate the disintermediation risks referred to in the document concerning Garena.
4167 Now four GVP 2.0 agreements remain on foot being agreements with PLR Worldwide Sales Limited, Garena Online Private Ltd, Lilith HK Network Limited and CyberAgent Inc.
The Apps Velocity Program
4168 Let me now say something about the Apps Velocity Program agreements.
4169 In early 2020, Google decided to extend Project Hug to 20 top non-game app developers. The proposed extension which was badged as the Apps Velocity Program or AVP in short was presented to the business council in February and approved on 6 March 2020.
4170 Google thereafter entered into AVP agreements with four developers, being Calm, Smule, Age of Learning and Bumble.
4171 The AVP agreements were structured as addenda to the existing DDAs between Google and the relevant developers. Under the AVP agreements, Google agreed to provide certain benefits to app developers such as marketing support, credit for purchasing advertisements through Google, and credit for the Google Cloud platform. In exchange, the developers agreed to the following restrictions subject to minor variations.
4172 First, the developers’ designated apps were required to use Google Play Billing as the sole payment solution across devices in all markets in which the designated apps were available on the Play Store.
4173 Second, the developers’ designated apps were required to have the same core content and features as any comparable product, being a non-Play Store application or service that is the same as the applicable title or any in-app purchase product or subscription product that can be used in those titles. Further, the developers were required to promote the designated apps in the same or an equivalent manner.
4174 Third, the app developers’ designated apps were required to make available the same SKUs or service tiers on the Play Store as on other platforms.
4175 Fourth, Calm and Smule were required to ensure that the subscription and/or purchase price applicable to each designated app on the Play Store was at least as favourable as the subscription and/or purchase price of comparable products. Further, Age of Learning was required to ensure that the subscription and/or purchase price applicable to each designated app offered on the Play Store was at least as favourable as the subscription and/or purchase price of the same designated app on other mobile app-purchase platforms that are comparable to the Play Store. Finally, Bumble’s AVP agreement did not contain a price parity clause.
4176 Let me now turn to the question of the purpose and effect of Project Hug, the GVP agreements and the AVP agreements relevant to the context of Epic’s s 46 case.
What was the purpose of Project Hug, the GVP agreements and the AVP agreements?
4177 Now Google disputes that Project Hug and the associated agreements were embarked upon or entered into by Google with the purpose or likely effect of substantially lessening competition.
4178 Google says that after Epic determined not to launch Fortnite on the Play Store in June 2018, and to instead launch on the Samsung Galaxy Store, Google was concerned that other major game developers may likewise elect to launch their games only with the Play Store’s competitors on Android, being the Samsung Galaxy Store, Amazon App Store, OneStore and the Epic Games Store whose entry Google anticipated.
4179 Google perceived that if that occurred, it would lose developers and ultimately users to its rivals and suffer a substantial loss in revenue. Google also perceived that it would lose users to iOS if Android continued to experience delays and reduced investment by developers in the launch of games on Android.
4180 In addition, Google believed that the loss of major developers from the Play Store would lead to a fragmented or fractured user experience on Android relative to iOS. This was because whereas the App Store offers a single, comprehensive and convenient source for apps on iOS, users on Android would potentially have to search through multiple app stores to find the apps they were looking for. Google anticipated that the resulting poor user experience would drive more Android users to iOS, which would in turn lead to developers reducing their investments in Android.
4181 Google says that Project Hug, the GVP agreements and the AVP agreements were a competitive response to this extant threat. The response involved Google offering a small number of its largest and most important developers better terms and more value in an effort to entice them to offer their products on the Play Store at the same time as its competitors, including the App Store. That is competition on price and quality. It is competition on the merits.
4182 In respect of Project Hug, Google says that Epic has confused the protection of competition with the protection of competitors. I agree that the correct focus should be on the former.
4183 Google says that its purpose in connection with Project Hug, the GVP agreements and the AVP agreements was not a proscribed purpose.
4184 Google says that the end Google sought to achieve through these initiatives was to ensure that, in respect of the small number of developers targeted by the GVP, the relevant developers’ content was available on the Play Store. Google did not seek to forestall other app stores or websites from offering the same content or doing so at prices below those available on the Play Store. It wanted to ensure that its users retained access to the same breadth and quality of games as the users of rival stores or platforms. It was no part of Google’s subjective purpose to harm the competitive process.
4185 Google says that the purpose of the GVP and the GVP agreements was to retain customers, that is, to keep certain game developers’ content on the Play Store. That was the end that Google sought to achieve. That is not a proscribed purpose.
4186 Google says that it was not its subjective purpose to prevent or hinder the development of rival Android app stores by making it impossible for them to offer differentiated content.
4187 First, it says that the purpose of keeping Google’s customers by offering them better terms is consistent with the material that was before the business council in April 2019. And it says that that material is not consistent with the proposition that the GVP agreements were motivated by the purpose asserted by Epic.
4188 Second, it says that the purpose of keeping Google’s customers was consistent with the evidence of Ms Kochikar. Google was not seeking to deny rival app stores access to exclusive content. Google’s subjective purpose was to keep developers’ content on the Play Store.
4189 Now Epic says that Ms Kochikar conceded that one of the goals of Project Hug was to prevent Tencent becoming a competitor. But Google says that Ms Kochikar’s evidence was that the relevant purpose was in fact to keep Tencent as a partner, that is, a customer. Now she accepted that one could say that that would prevent it from becoming a competitor. But Google says that that is not a proscribed purpose.
4190 Google says that Tencent was offered improved terms from Google to entice Tencent to continue working with Play rather than self-supplying. But it says that offering a customer better prices or terms to keep their business is competition on the merits. And that is so whether the most likely alternative available to that customer in the absence of improved prices is self-supply or switching to a rival supplier.
4191 Further, Google says that even if it had the subjective intention of preventing Tencent from becoming a competitor, that of itself does not establish an intention to substantially lessen competition. It says that entry by Tencent alone would not alter competition in a manner that was relevant or meaningful to the competitive process.
4192 Third, Google says that its purpose may readily be inferred from what it sought, and did not seek, in the GVP agreements.
4193 Google says that it did not seek exclusivity of distribution in the GVP agreements. Developers were free to distribute their titles anywhere else on Android and iOS provided that the content was also on the Play Store. Google says that had it intended to act in an anti-competitive way, one would have expected Google to require exclusivity of distribution from the Project Hug developers so that rival app stores could not have their content at all.
4194 Further, Google says that it did not require exclusivity notwithstanding the fact that it had quantified co-listing of titles off the Play Store to be a significant revenue risk for the Play Store.
4195 It says that in the Fortnite deal review, Google quantified the expected loss caused by downstream “contagion” if major developers and all remaining titles co-listed off Play, that is, they were launched on the Play Store as well as elsewhere on Android. The estimated revenue loss from major developers co-listing was between USD 61 million and USD 410 million, and if all remaining titles co-listed, the revenue loss would be between USD 180 million and USD 2.3 billion.
4196 Google says that notwithstanding that Google recognised revenue loss from co-listing titles as a significant competitive risk, the GVP agreements did not prevent developers from co-listing titles on rival app stores. Google says that if it had intended to hinder or prevent competition through Project Hug, it would have insisted on exclusivity of distribution from the Project Hug developers.
4197 Fourth, Google says that the GVP agreements did not prevent developers from offering differentiated content on rival app stores.
4198 The content parity clause only applied to core content, features and functionality. It did not prevent or hinder developers from offering sponsorships and promotions on rival app stores. Apart from two GVP agreements, no requirements were placed on developers in relation to the distribution of differentiated content on rival app stores. Google says that had it intended to hinder or prevent rival app stores from obtaining differentiated content from the Project Hug developers, it could have required content parity for both core and non-core content and features.
4199 Fifth, Google says that Epic’s position presupposes that the development of rival Android app stores necessarily requires differentiated content. But it says that that was not its internal assessment at the time. That being so, it says that it is unlikely that Google would have sought to impair the development of rival Android app stores by denying them exclusive content.
4200 Further, Google says that an important point of differentiation between rival app stores is competition on price. It says that content is not the only way in which rival app stores compete and seek to differentiate themselves. It says that at the time the business council approved the GVP in April 2019, Google was aware that rival Android app stores offered developers lower revenue share pricing models than the Play Store.
4201 Google says that the assessment within Google was that a rival Android app store could successfully compete on price, without needing exclusivity from developers. That being the assessment, Google says that it would be incongruous if its intention in pursuing the GVP was to prevent or hinder the development of rival Android app stores by making it impossible for them to offer differentiated content when its own assessment was that differentiated content was not necessary for such development.
4202 Sixth, Google says that with only one exception, the GVP agreements did not require price parity. It says that if it intended Project Hug and the GVP to prevent or hinder rival app stores from competing, it would have required price parity from the developers. It says that without such a clause, an obvious way in which rival app stores might compete is through offering the same content as was on the Play Store but at lower prices.
4203 Google says that the fact that it did not seek price parity from the GVP agreements is consistent with the proposition that those agreements were not seeking to hinder or prevent competition.
4204 Let me now address another matter. Epic says that I should infer that the purpose of Project Hug and the GVP was the same as the purpose of Project Banyan, but Google says that the evidence is to the contrary.
4205 First, Google says that the fact that it established two distinct programs, one called Project Hug and the other called Project Banyan, suggests that it saw those as distinct projects, the objects of which were not the same.
4206 Second, Google points out that Project Banyan did not proceed, as I have detailed earlier. Google says that the fact that Project Banyan was stopped, yet Project Hug continued in these circumstances suggests that Google did not perceive the two projects to serve the same ends. More generally Google says that the conduct relating to Project Hug and its ends bear no resemblance to Project Banyan.
4207 Let me deal with another matter.
4208 Epic says that Project Hug and the GVP were concerned only with fragmentation within the Android ecosystem. But Google says Project Hug and the GVP were addressed to both competition within Android and competition with iOS. Google has made several points.
4209 First, Google says that given the contemporaneous business records concerning the GVP and the Fortnite deal review, it is apparent that there was a genuine concern on the part of Google that Android users would churn to iOS if there was app store fragmentation on Android.
4210 Second, it says that the sim-ship clause in the GVP agreements extends to require developers to sim-ship their games on iOS and the Play Store. It says that an obligation to sim-ship across iOS and Android is more onerous to the developer than an obligation only to sim-ship on Android. As such, Google says that as a matter of economic logic, developers would demand a higher price for the obligation to sim-ship on iOS and the Play Store than they would to only sim-ship on Android.
4211 Further, and in summary, Google says that when one has regard to the materials that were before the business council in April 2019, Google says that the following conclusions can be drawn.
4212 First, the impetus for the GVP was that the Play Store’s existing competitors, including the Samsung Galaxy Store, Amazon App Store and One Store, were competing for the opportunity presented by mobile gaming. It is said that the competitive threat posed was real.
4213 Second, Google was concerned that a further consequence of the Play Store losing titles to its competitors would be fragmentation on Android, resulting in churn to iOS.
4214 Third, the strategy behind the GVP was to offer the relevant developers an effective discount on the service fee by offering increased value across a range of Google services, so as to keep developers by offering better quality adjusted prices.
4215 I should say for completeness that Google denies any anti-competitive purpose concerning the AVP and the AVP agreements and makes analogous points.
Analysis
4216 In my view, Google in implementing Project Hug, the GVP agreements and the AVP agreements acted for the purpose of substantially lessening competition in the Android app distribution market.
4217 Now Project Hug’s catalyst was Epic’s decision to launch Fortnite on Android outside the Play Store. This sparked a fear within Google of “broad contagion to other developers”, that is, a fear that if Epic were successful in distributing Android apps outside the Play Store, then other developers would get the same idea and do the same thing.
4218 As the chronology above has demonstrated, having tried and failed to buy off Epic with a special deal, Google changed course and by August 2018, was “putting together a hug developers close and show love plan” in response to the “fortnite situation”, being ultimately Project Hug.
4219 The purpose of Project Hug was to prevent or hinder the development of rival Android app stores by making it impossible for them to offer differentiated content from the participating Hug developers.
4220 Google understood that rival Android app stores likely required such differentiated content in order to succeed at scale, and that, if it could prevent rival Android app stores from offering differentiated content from the participating Hug developers, then users were unlikely to switch from the Play Store to rival Android app stores. As Google presentations recorded, Project Hug’s purpose was to “de-risk” rival app stores on Android by preventing them from obtaining differentiated content.
4221 Google’s purpose in including the “sim-ship”, “non-removal” and “content parity” provisions in the GVP agreements, and the “content parity”, “price parity” and “non-removal” provisions in the AVP agreements, was to prevent or hinder competition from rival Android app stores.
4222 That purpose is further demonstrated by a Google paper dated October 2020 titled Google – Tencent Engagement Strategy on Gaming that contained the following chart:
4223 Ms Kochikar accepted that one of the goals of Project Hug was to prevent Tencent becoming a content provider.
4224 Now although the Project Banyan deal was not entered into, I agree with Epic that it reveals much about Google’s purpose in rolling out Project Hug, which was conceived and planned around the same time. Both were seen by Google as tactics that were required in conjunction. They were approved by the business council at the same meeting, during which it was stressed that both programs were needed. They were needed for the same reason, namely, to protect the Play Store against competition.
4225 I agree with Epic that the evidence demonstrates an overlapping common purpose of the two projects even if each also had other separate and non-overlapping objectives.
4226 I note for example that in a May 2019 slide presentation titled Project Magical Bridge, the following slides appeared:
4227 In summary, in my view Google in implementing Project Hug, the GVP agreements and the AVP agreements acted for the purpose of substantially lessening competition in the Android app distribution market.
4228 Further, as I will discuss now, its conduct concerning Project Hug and the GVP agreements had the likely effect of substantially lessening competition, although it did not have that actual effect. In saying that, I am dealing with the concept of likely in terms of a real chance.
What was the effect in competition terms of Project Hug and the GVP agreements?
4229 Now I accept that nothing in Part IV requires a competitor, even one with market power, to sit idly by as its customers switch to its rivals. When a firm charges its customers less, or gives its customers more, to convince them not to switch to competitors, that is competition in action. That is so even if the effect of that conduct is ultimately that customers do not switch and this adversely affects competitors. This reflects a basic reality that competition itself is typically harmful to competitors.
4230 Further, I also accept that maintaining and strengthening relationships with customers is essential for Google to remain competitive. Charging developers less, or giving them more, in order to strengthen or maintain those customer relationships and attract investment from those developers in content for both Android and the Play Store is one way in which Google can compete with other app stores.
4231 Now Epic asserts that the effect of Project Hug was to prevent or hinder the development or expansion of rival Android app stores, but Google says that there is no evidence of that. But Google says that even if there was, that effect without more does not involve a substantial lessening of competition where the mechanism of that effect is competition itself.
4232 Google says that Project Hug and the GVP agreements did not have the effect or likely effect of substantially lessening competition.
4233 First, Google says that the effect of the GVP agreements was to provide developers with more value from Google across a range of services, and thereby to provide an effective discount on the Play Store’s service fee. It involved, in substance, offering developers more to keep their business. In that way, it was a competitive response to the threats Google faced within the Android ecosystem, and the risks that such threats posed to the competitiveness of Android against iOS.
4234 Even if the effect of the GVP agreements was to prevent rival Android app stores from obtaining differentiated content, that of itself does not constitute a harm to competition.
4235 When one competitor drops its prices to keep its customers, one likely consequence is that its competitors will not win the business of those customers. That is not a harm to competition. That is competition at work.
4236 Further, Google says that the GVP agreements did not preclude the most effective means by which a rival app store might get itself off the ground. GVP was dealing with extant competitive threats from rival app stores. Epic’s assertion wrongly presupposes that exclusive content is the most effective means by which a rival app store can compete. But an equally effective means to compete is on price and many rival app stores do so compete.
4237 Second, Google says that Epic has adduced no evidence that any rival app store was ever prevented from obtaining differentiated content from the GVP developers because of the GVP agreements.
4238 Third, Google says that Project Hug, ultimately renamed as the GVP, lacked the scale to competitively disadvantage rival Android app stores.
4239 Google says that in this respect, the 20 developers that signed GVP agreements accounted for [REDACTED] of the Play Store’s service fee revenue in Australia in 2021. Further, the GVP developers were only 20 amongst more than 1 million developers that publish Android apps. Of the more than 1 million developers, approximately 394 of those developers, who were in the top 1% of developers by service fee revenue in Australia and accounted for 78% of the Play Store’s service fee revenue, did not sign a GVP agreement.
4240 Further, Google says that 24 of the top 30 developers by the Play Store’s service fee revenue in Australia were not offered and did not sign a GVP agreement. Those 24 developers accounted for 39% of the Play Store’s service fee revenue in Australia.
4241 So, Google says that the evidence does not support Epic’s claim that the GVP or Project Hug meaningfully competitively disadvantaged or was likely to have disadvantaged rival Android app stores.
4242 Fourth, Google says that the GVP agreements did not prevent developers from publishing content on rival Android app stores or from enabling their apps to be sideloaded. Indeed, 12 of the participating developers continued to distribute through other Android app stores after signing GVP agreements. This included highly popular apps.
4243 Fifth, Google says that it considered GVP to be a success because developers were prioritising the Play Store with 184 titles sim-shipped on the Play Store and for other reasons. Google did not consider GVP to be a success because it quashed a nascent threat to the Play Store’s dominance.
4244 Again, Google considered renewing, and did renew, certain GVP agreements (but not others) based on whether developers were growing on the Play Store. Google says that it is not that GVP agreements were not renewed because Google succeeded in substantially lessening competition.
4245 In summary, Google says that the effect or likely effect of the GVP or Project Hug was not, and is not, anti-competitive.
4246 Finally, let me say something about what Google has said about GVP 2.0 and AVP.
4247 As I have indicated, in early 2021, GVP 2.0 was approved. Google says that the purpose of GVP 2.0 was the same as the purpose of the GVP. Google offered better terms to a limited number of game developers with a view to ensuring that they launched their content on the Play Store. Google says that this is competition on the merits.
4248 Ultimately only 4 developers signed a GVP agreement as part of GVP 2.0.
4249 Google says that the terms of the GVP 2.0 agreements are materially the same as those for the GVP. They contained a sim-ship clause and content parity clause, and depending on the particular agreement may have contained a promotion clause, non-removal clause and/or early access clause.
4250 Again, none of the GVP 2.0 agreements required the developers to distribute content exclusively on the Play Store, nor did they prevent developers from offering differentiated content on rival app stores.
4251 Further, Google points out that none of the GVP 2.0 agreements contained a price parity clause and so developers could offer better prices for the same content in other app stores and app distribution channels.
4252 Further, Google says that GVP 2.0 did not have the effect or likely effect of substantially lessening competition. It says that retaining customers through offering better terms is competition. Moreover, Google says that Epic has adduced no evidence that any rival app store was ever prevented from obtaining differentiated content from any developer as a result of the GVP 2.0 agreements.
4253 Now as to the AVP, the AVP applied to non-gaming developers. Google only ever signed 4 AVP agreements. It says that no part of the AVP agreements required developers to offer content exclusively on the Play Store nor did it prevent developers from distributing differentiated content on other app stores. It says that the AVP agreements had no effect or likely effect on competition, particularly in circumstances where the program involved only 4 developers.
4254 It says that Epic has adduced no evidence that any rival app store was ever prevented from obtaining differentiated content from the AVP developers as a result of the AVP agreements.
4255 I agree with Google’s position on the AVP agreements and have put them to one side.
Analysis
4256 In my view the likely effect of Project Hug and the GVP agreements was to prevent or hinder the development or expansion of rival Android app stores, by making it impossible for them to offer differentiated content from the participating Project Hug developers. Without such differentiated content, rival Android app stores were never likely to succeed at scale, and users were unlikely to switch from the Play Store to rival Android app stores.
4257 Now I agree with Google that it is for Epic to prove that in the absence of the impugned conduct or provisions, some alternative state of affairs that involves a substantial improvement in competition is likely in the requisite sense. That requires a proper focus on the alternative, including so that the competitive effect of the conduct or provision can be measured including as to whether it is substantial.
4258 Epic’s counterfactual analysis is focused on the proposition that developers would have more choice absent the impugned conduct or provision.
4259 Now Google says that even if any increased choice were to exist absent the impugned conduct, that would not itself amount to any relevant change in the conditions of competition. Instead, one must consider how that increased choice likely would be exercised. Google says that the evidence did not reveal whether and how developers would likely exercise the choice that Epic posits.
4260 Google says that Epic did not prove that there is any realistic prospect that developers would make different choices if the impugned provisions were removed or the conduct not engaged in.
4261 Google says that as such, the evidence before me rises no higher than showing a mere possibility of a change in the absence of the impugned conduct. Such a mere possibility or a speculative, theoretical possibility falls short of a likely effect on competition. Let me refer to two authorities.
4262 First, in Australian Competition and Consumer Commission v Metcash Trading Ltd (2011) 198 FCR 297, Yates J said (at [235]):
… The primary judge was called upon to make a “real world” assessment based on matters that were commercially relevant and meaningful. The primary judge did so. His Honour was not required to move on mere possibilities, let alone speculative possibilities. Indeed, to have done so would have involved error.
4263 Second, in Australian Competition and Consumer Commission v Pacific National Pty Ltd (2020) 277 FCR 49, Middleton and O’Bryan JJ found that the possibility of a new entry in the relevant time frame was a mere possibility and, accordingly, was speculative. Further, their Honours determined that (at [262]):
… The ACCC did not adduce evidence concerning the likelihood of entry by any other company. As a result, the evidence at trial only supported a finding that new entry was possible (in the sense of a mere possibility).
4264 Google says that at its highest, Epic’s evidence suggests that there is a mere possibility that developers would choose alternative options in the absence of the impugned conduct or provisions. But that says nothing about whether it is likely that they would, in fact, do so, and whether it would make any meaningful difference to the competitive process if they did.
4265 On that basis, Google says that Epic has failed to prove that the conduct had the effect or likely effect of substantially lessening competition.
4266 Google says that if there is no evidence of the likelihood that developers would meaningfully change their behaviour in the absence of the impugned conduct or provisions, then I must find that there was no likely effect of substantially lessening competition.
4267 Further, Google says that a proper consideration of the counterfactual in competition cases, as compared to tort matters, does not involve a static inquiry which removes the impugned conduct but keeps all else equal. That approach is at odds with an inquiry that is focused on an assessment of all commercially realistic futures without the impugned conduct. In general, the proper approach is to assess the counterfactual by reference to the commercial realities which may follow as a consequence of the removal of the conduct. On this last point I agree with Google.
4268 Now in my view, in the counterfactual, the Project Hug developers would be free to distribute differentiated or exclusive content through rival Android app stores, which those stores would promote so as to entice users away from the Play Store. Content of that nature would also give rival stores credibility in the eyes of users and other developers, which would assist those stores to grow.
4269 And during the development of Project Hug, that is what Google was worried might occur if it did not take action.
4270 Seen in that light, the GVP agreements, although limited in number, in likely effect precluded the most effective means by which a rival app store might get itself off the ground.
4271 The GVP agreements prevented prospective competitors to the Play Store doing precisely what the Epic Games Store did when it entered the PC app store market, namely, entering into exclusivity agreements with key developers whose apps were most likely to attract users.
4272 Now Google says that because the number of GVP agreements were limited and the total revenue of the particular developers is limited, the agreements do not or did not substantially lessen competition.
4273 But as to the number of agreements, the reality is that Google chose the particular developers precisely because they were influential and were likely to take other developers with them if they departed the Play Store.
4274 As Google itself recognised, the developers chosen were “beacons of the ecosystem”. If those developers did not have the capacity to make a material impact in the app distribution market, Google would not have targeted them.
4275 Further, as to the total revenue, at the time the GVP agreements were introduced the target developers accounted for 31% of Play Store revenues globally. Professor Asker’s focus on the Australian revenue share for those developers is beside the point, since a rival app store will be concerned with its ability to compete for global, not only Australian, revenues.
4276 Google also says that neither the GVP agreements nor the AVP agreements require Play Store exclusivity. But in circumstances where the Play Store is the incumbent, it does not require exclusive content in order to maintain its user base. Rather, as Epic points out, it is prospective rivals who require exclusive or differentiated content, to draw users away from the Play Store. Project Hug denied them that content.
4277 Further, Google considered Project Hug to be a success, that is, it successfully contained the contagion risk and quashed the nascent threat to the Play Store’s dominance. As Epic correctly says, it was for that reason that Google did not consider it necessary to extend the agreements.
4278 Now Professor Asker said that the GVP agreements addressed the coordinated adoption problem in respect of the Play Store and also seek to prevent app store fragmentation. But in respect of the coordinated adoption problem, Google does not have that problem. That point goes nowhere. Further, requiring developers to “sim-ship” their titles on the Play Store is of commercial benefit to Google only. Further, I agree with Epic that the notion that preventing app store fragmentation is a benefit to competition, a point pushed at one stage by Mr Moore SC, pushes the envelope to say the least.
4279 In my view, Project Hug and the GVP agreements had the likely effect of substantially lessening competition. But I am not convinced that it has been shown that they had that actual effect.
Summary
4280 I have found that Google’s conduct in implementing Project Hug, the GVP agreements and the AVP agreements had the purpose of substantially lessening competition in the Android app distribution market. And such conduct had such a likely effect, although not an actual effect, concerning Project Hug and the GVP agreements, but not the AVP agreements.
Clause 4.5 of the DDA – prohibiting the distribution of rival app stores
4281 Clause 4.5 of the DDA prohibits developers from using the Play Store:
… to distribute or make available any Product that has a purpose that facilitates the distribution of software applications and games for use on Android devices outside of Google Play.
4282 So, clause 4.5 prohibits a developer from distributing an app store or any app that facilitates the distribution of another app through the Play Store.
4283 Clause 4.5 prevents the developer of a rival Android app store, or indeed of any app that distributes another app, from distributing those products to users through the pre-eminent Android app distribution service. The clause applies to all rival app stores or apps which distribute other apps regardless of their content, security credentials or policies toward users.
Epic’s arguments
4284 Epic says that the purpose of clause 4.5 is to prevent or hinder the Play Store’s competitors from obtaining distribution services that would enable rival app stores to reach Android device users at scale. It is said that the anti-competitive purpose of clause 4.5 is evident from its language and its effect.
4285 Further, Epic says that Google’s internal documents reflect that its purpose is to protect the Play Store against competition.
4286 Prior to September 2014, clause 4.5 was headed “Non-Compete” and its purpose was described by Mr Dan Morrill, a Google employee who was “in the room” when clause 4.5 was included in the DDA, in an email on 20 May 2009 as follows:
… the intent of that clause is indeed 100% protectionist. :) It is explicitly intended to prevent people from using the Market to distribute a competing app store. It’s even described as “Non-Compete” in the DDA. *We* don’t necessarily care, but the existence of this clause is a concession to the carriers: their revenue share means little if it’s that easy to bypass it.
… None of us in the room were particularly happy about it, but it seemed like a decent balance between the interests of someone like [Electronic Arts] who wants to link to a page with all their games, and the carriers’ interests in the non-compete.
4287 Now Epic says that prior to 25 September 2014, clause 4.5 only prohibited products whose primary purpose was to facilitate the distribution of Android apps. So, apps which in fact distributed other apps but whose primary purpose was something besides the distribution of other apps such as a social media platform were able to be distributed through the Play Store in compliance with the DDA.
4288 But Epic says that by June 2013, Mr Rosenberg had identified and informed Mr Pichai, the then head of Android, in an email on 17 June 2013 that the Play Store’s “long-term strategic threat comes from mobile-first players co-opting Google’s position in [app] discovery on mobile. This is our area of primary strategic concern”.
4289 Mr Rosenberg explained the concern to Mr Pichai in the following terms:
…
* There are several large ecosystems developing strong positions in mobile content discovery, directing their massive audiences toward mobile content.
* Web companies like Facebook and Twitter are transitioning their existing web audiences to mobile, becoming key arbiters of traffic. …
* Mobile-first businesses like Kakao, Line and Gree are leveraging millions of daily visitors built from other businesses … to take strong positions in mobile discovery
* These businesses form a strategic, long-term threat to Google (not only Google Play)
* Facebook and Twitter are … accumulating huge audiences and impressions that can then be monetized by directing towards apps, brands and content (Kakao’s strategy is now becoming similar).
* These businesses are taking a stronger position in the high-value role of discovery, while reducing Google’s role to fulfilment and payments. Longer term, there is a threat of the fulfilment & payment role being co-opted as well.
* Kakao, a messaging platform with near 100% penetration in Korea, has pushed the boundaries the furthest and stands as a realistic model for what Facebook could do in the US and elsewhere in the world.
…
4290 Further, Epic says that Mr Gennai gave evidence that by 2014, social media apps were emerging as a potential alternative means by which apps could be distributed to users in competition with the Play Store, and Project Gabby was established to explore the consequences and possible responses to these developments.
4291 Epic says that in cross-examination, Mr Gennai was taken to a 9 April 2014 document titled “Project Gabby” of which he was the author. The document summarises why “[o]utside of China / Kindle Fire, other Android storefronts are relatively small”, whereas social media apps were “[m]oving toward a platform for apps and games”, becoming “[s]ubstitutes for App Discovery” and threatened the Play Store’s revenue. The former “suffered from chicken-and-egg problem: Not enough eyeballs to get the catalog, didn’t have the catalog to get the eyeballs”. The latter were “different”: these “would-be competitors start with an existing, highly-trafficked app and converting into a distribution vehicle”. Moreover, social messaging was already “#1 owner of attention on mobile with strong network effect”, with “[m]assive penetration”, and was “[d]ominating mobile usage time”.
4292 Now Mr Gennai sought to dismiss much of this on the basis that he was guessing. But Epic says that he was applying his judgment being familiar with industry developments.
4293 The document also asks “[w]hat do our contracts say?” and then refers to “New DDA (Sept 15)”, setting out the proposed amended clause 4.5, with the following “[t]ake-away: Any app that distributes apps themselves must be preloaded or distributed via alternate means, like direct download, or download facilitated by a 3rd party app.”
4294 So, Epic says that this was the intended effect of the “New DDA” and was specifically the intended effect of the proposed amendment to clause 4.5 set out on the face of the document. But Mr Gennai insisted that “[t]hat was my understanding of the policy the entire time. I’m summarising the agreement there.”
4295 Epic says that it would seem clear that prior to its amendment in 2014, the prohibition in clause 4.5 only applied to apps whose primary purpose was to distribute other apps outside the Play Store.
4296 Epic says that Mr Gennai problematically maintained that Google’s policy had never changed and was merely clarified. He sought to maintain this despite being shown the pre-amendment form of clause 4.5 and the proposed wording amendments, despite being shown that Google summarised the amendments as “[r]emove ‘primary purpose’ test from clause”, despite being shown text describing the “Business Impact” of the amendments as “[p]revent more apps from directing users off Play”, and despite being shown that Google’s assessment was that some apps would not contravene the existing policy but would contravene the proposed policy.
4297 Now Epic says that the 9 April 2014 “Project Gabby” document continued with the question “[w]hat can we do about it?” One answer provided was “[r]evised contracts”. Epic says that the past tense is significant. The solution was not to come up with a new amendment. Rather, the revised DDA had already been prepared and both the revision and its effect or “Take-away” had been described on the previous slide. That was one thing Google could “do about” the competitive threat posed by social media apps.
4298 Now Mr Gennai denied that the contractual revision he had in mind when drafting the document was clause 4.5 of the DDA. Ultimately, Mr Gennai said Mr Rosenberg and/or Mr Lockheimer would have had the authority to approve the amendment to clause 4.5, not him.
4299 In September 2014, Google amended clause 4.5 of the DDA in response to the emerging threat of competition for the Play Store from social media and other apps whose primary purpose was not app distribution.
4300 Epic says that by amending clause 4.5 in the way it did, Google forced those potential competitors to choose between becoming a competing platform for app discovery or continuing to distribute their apps through Android’s pre-eminent app store. Epic says that the outcome that Google sought to achieve and did achieve was that these developers would choose the latter path and would never become the platforms for app discovery that Google was afraid of competing against.
4301 Now Google says that the purpose of clause 4.5 is not to hinder competition from rival app stores at all, but instead to prevent what it calls “free-riding”. But Epic says that even putting the events just discussed to one side, this assertion is not supported by the terms of clause 4.5. It says that what that clause actually targets is not free-riders but competitors.
4302 Epic says that if Google’s objective in clause 4.5 was to prevent free-riding rather than competition, it would charge rival app stores a price for the services being provided to them through the Play Store. Instead, Google bans rivals altogether, whether they are prepared to pay a fee for distribution or not. It does so to protect the Play Store against competition.
4303 Further, it says that there is no reason why Google could not charge rival app stores a fee for distribution services supplied by the Play Store.
4304 Now Mr Gennai said that the platform is too complex to police a system whereby third-party app stores report information to Google for the purposes of calculating a fee which could be audited. But Epic says that that assertion was not maintainable given that something similar already occurs with user choice billing and developer only billing.
4305 Epic says that if the end Google was seeking to achieve was that of ensuring that developers were not able to free-ride on its investments in the Play Store, Google would find a way to charge those developers a fee.
4306 Instead, Google has imposed a blanket prohibition on the distribution of rival app stores and apps that distribute other apps, regardless of whether their developers are prepared to pay a fee. Google has chosen to impose a blanket prohibition because its objective is not to prevent free-riding but to prevent or hinder the Play Store’s competitors from using a distribution service that would enable them to reach almost all Android device users.
4307 Clearly, so Epic says, what Google sought to achieve by clause 4.5 of the DDA in its current form was to close off the Play Store to any app that could be used to distribute other Android apps in competition with the Play Store.
4308 Now Google also says that clause 4.5 helps to maintain the security of apps available, directly or indirectly, via the Play Store because third-party app stores carry apps that have not been seen or reviewed by Google.
4309 But Epic says that applying that reasoning, Google would refuse to distribute Chrome and other web browser apps via the Play Store, since browser apps can be used to download any app whatsoever from the internet, which may not have been seen or reviewed by Google. And Epic says that it is also implausible to suggest that clause 4.5 ensures that Google’s brand is not diminished.
4310 Epic says that except for the assertions of Mr Gennai, who was not the decision-maker, Google has not adduced evidence, whether from a witness or by way of contemporaneous records, that its subjective purpose when including clause 4.5 in the DDA was to prevent free-riding.
4311 Further, Epic says that in Google’s device and network abuse policy, which developers are obliged to comply with by clause 4.1 of the DDA, it is provided that “an app may not download executable code … from a source other than Google Play”. That language is similar in effect to clause 4.5 of the DDA, in that it likewise prohibits apps that facilitate the download of another app otherwise than through the Play Store. That prohibition has the same anti-competitive purpose as clause 4.5.
4312 Further, Epic says that the balance of the device and network abuse policy prohibits apps downloaded from the Play Store from updating themselves using any method other than the Play Store’s update mechanism. This aspect of the policy means that if Google terminates a developer’s DDA, none of that developer’s apps previously distributed through the Play Store can be updated.
4313 Now Google says that clause 4.5 of the DDA is justified on security grounds. It says that the prohibition on distributing an app store through the Play Store is necessary for Google to provide users with the same quality, safety, and security that users and developers have come to expect of content accessed via the Play Store, to prevent reputational harm to Google, and to prevent free-riding. But Epic says that there are no quality, safety or security implications of distributing app stores through the Play Store that do not already exist in relation to various kinds of app that the Play Store already hosts, such as web browsers, file sharing apps, messaging apps and email apps.
4314 Epic says that contrary to Google’s contentions, the prohibition is unnecessary for Google to provide users with the same quality, safety and security as in respect of other content accessed via the Play Store.
4315 Google draws an analogy between a third-party app store being hosted on the Play Store, and “a tunnel beneath the perimeter security offered by Google Play – a tunnel into the wider online world”. But Epic says that Google appears unconcerned with any such “tunnel”, even if it poses a known security risk, so long as it does not constitute a competitive threat to the Play Store. Epic has made the following points.
4316 The Play Store hosts a variety of apps that facilitate the transfer of apps, including browser apps, messaging apps like WhatsApp, email apps, and peer-to-peer sharing apps like SHAREit, Xender, JioShare, InShare and ShareKaro.
4317 Google knows that it is common for peer-to-peer apps to facilitate the sharing of installed apps.
4318 The fact that apps such as WhatsApp and SHAREit might also be commonly, or even typically, used to share other kinds of files does not alter the fact that apps of that kind can, and are, commonly used to distribute apps. Moreover, the apps that are commonly distributed in that way are varied in terms of quality, safety and security.
4319 To take SHAREit as an example, Mr Porst frankly conceded that “it is actually pretty bad, for what it’s worth, so they distribute a lot of malware”. Yet SHAREit can be distributed on the Play Store, whereas a third-party app store with a minimal or zero malware install rate is prohibited.
4320 Further, Epic made reference to Professor Somayaji’s opinion that the Play Store is technically capable of distributing alternative app stores, and that making such stores available on the Play Store would not reduce the quality, safety or security of the Play Store.
4321 In summary, Epic says that the purpose of clause 4.5 was and is to prevent or hinder the Play Store’s competitors from being distributed to Android device users. So much is evident from its language and effect, and the internal email from Mr Morrill on 20 May 2009 which I have already referred to.
4322 Further, Epic says that Google’s conduct in September 2014 in amending clause 4.5 to remove the exemption for apps whose primary purpose was not app distribution also confirms the anti-competitive purpose of the provision.
4323 Epic says that what Google sought to achieve by clause 4.5 was to close off the Play Store to any app that could be used to distribute other Android apps in competition with the Play Store.
4324 Now Google has identified two different purposes for clause 4.5, being the prevention of free-riding and the maintenance of security.
4325 Now as to free-riding, Epic says that this is not supported by the text or effect of clause 4.5. The clause targets competitors, not free-riders.
4326 If Google’s objective in clause 4.5 were to prevent free-riding rather than competition, it would charge rival app stores a price for the distribution services being provided to them through the Play Store. Instead, Google bans rivals altogether, whether they are prepared to pay a fee for distribution or not. It does so to protect the Play Store against competition.
4327 As to security, Epic says that this is a pretext. It says that applying the same logic, Google would refuse to distribute Chrome and other web browser apps via the Play Store, since browser apps can be used to download any app whatsoever from the internet, which may not have been seen or reviewed by Google.
4328 Epic says that leaving aside bare assertions from Mr Gennai, Google has not adduced evidence, whether from a witness or by way of contemporaneous records, that its subjective purpose when including clause 4.5 in the DDA was to prevent free-riding, or some other lawful reason.
4329 And it says that the bare assertions in the affidavit of Mr Gennai can be disregarded, both because he was not the decision-maker and by reason of the numerous difficulties with his evidence.
4330 Further, in terms of Epic’s effects case it says that the effect of clause 4.5 of the DDA is to prevent developers from distributing an alternative app store via the Play Store. The clause prevents rival Android app stores from using the pre-eminent means of distribution to Android device users, that is, the Play Store. No other Android app store has a share of app store downloads above about 2.5%.
4331 So, Epic says that clause 4.5 of the DDA hinders the ability of rival stores to emerge or expand. They are compelled to use means of distribution that lack the same reach as the Play Store and are therefore less effective.
4332 Moreover, Epic makes the following points in terms of any relevant counterfactual.
4333 Epic says that if clause 4.5 of the DDA was to be removed, app developers could distribute rival Android app stores via the Play Store on terms that Google chooses, subject to compliance with competition law. Rival app stores could be distributed to almost every Android device in the world through the most popular Android app distribution channel.
4334 It says that developers of rival app stores are highly likely to wish to distribute via the Play Store, given that it accounts for 73% of all new app downloads in Australia and coincidentally 73% globally excluding China, and over 97% of all new app downloads from Android app stores in Australia and 91% globally excluding China.
4335 It says that given the position that the Play Store enjoys as a result of Google’s contractual restrictions, there is a real commercial likelihood app developers would seek to distribute rival Android app stores on the Play Store if permitted to do so.
4336 Indeed, Epic says that there is evidence of demand from app developers to distribute store-like apps through the Play Store.
4337 In September 2014, Amazon released an updated version of its Amazon mobile App Store, which was available on the Play Store at the time. The updated version included a new section within the app, “Apps & Games”, which allowed Android device users to purchase and download apps to their Android devices from within the Amazon mobile app.
4338 Shortly after, Google revised its DDA such that any product which had a “purpose” to facilitate app distribution outside the Play Store was prohibited from being distributed on the Play Store. Before this revision, only products with the “primary purpose” of facilitating app distribution outside the Play Store were prohibited. This amendment to clause 4.5 of the DDA reflected an acknowledgement by Google that there is demand from developers to distribute rival Android app stores via the Play Store.
4339 Further, Epic’s evidence is that if Epic could distribute the Epic Games Store via the Play Store, it would do so. In June 2020, Epic sought permission to distribute a mobile version of the Epic Games Store through the Play Store. Google denied that request.
4340 Now Google says that the removal of clause 4.5 of the DDA would amount to or facilitate free-riding, because it would allow Epic to use the services of a competitor while permitting Epic to bypass the payment of any fee to Google.
4341 But Epic says that its counterfactual is not premised on an assumption that third-party app stores would be able to distribute via the Play Store for free.
4342 Further, Epic says that it is not required to show precisely how Google would monetise its app distribution services in the counterfactual. But the assumption is that Google will not do so in a way that contravenes the CCA.
4343 Making that assumption, Epic says that in the counterfactual rival Android app stores could obtain global distribution to virtually every Android device outside China, on terms that do not have the purpose or effect of substantially lessening competition. And on any view, it says that that will be a more competitive app distribution market than the present, where rival app stores cannot obtain global distribution anywhere, on any terms.
4344 Now Professor Asker’s posited counterfactual was a world in which clause 4.5 of the DDA is removed and Google imposes a $15 charge per download for rival Android app stores. Professor Asker concluded that no rival would distribute via the Play Store if such a charge were levied.
4345 But Epic says that there is no evidence from Google that it would impose a charge in the counterfactual and no evidence that, if it did this, the likely quantum would be $15 per download.
4346 Further, Professor Asker’s charge was calculated by reference to the lifetime value (LTV) of an Android device user to Google over the course of the lifespan of the relevant device and multiplying that by 30%.
4347 Epic says that Professor Asker did not explain why LTV was a useful basis for calculating the charge. Indeed, using LTV is odd given that it includes non-Play Store revenue such as advertising revenue from the device.
4348 Finally, Epic says that Professor Asker’s posited counterfactual has little merit.
Analysis
4349 I should say upfront that I agree with Google that the clause 4.5 restriction does not have a purpose, effect or likely effect of substantially lessening competition.
4350 As Google points out, the prohibition is similar to one adopted by nearly all app stores. It is a conventional provision to prevent the expropriation of investment in the app store, motivated by ordinary commercial and security considerations.
4351 First, as Google says, the prohibition on distributing other app stores through the Play Store mitigates the security risk that would otherwise arise.
4352 Mr Feng, who has been involved in internal discussions at Google about clause 4.5, gave evidence that Google has no scaleable way of ensuring the security, safety and policy compliance of apps which are distributed through third-party app stores and no way of evaluating all the different apps in those stores or removing harmful apps.
4353 Similarly, Mr Porst, who manages app security on Android, gave evidence that:
I do not believe that it would be safe to permit the distribution of other app stores through Google Play. This is because Google cannot review all apps being distributed on other app stores for malware or potentially harmful behavior and would be reliant on the other app stores implementing their own security measures. …
…
Even if Google could somehow analyze all apps (and updates to them over time, which can be numerous, frequent and significant) listed on all other app stores before they are distributed to users on Android devices, the lack of control Google has or could exercise over other app stores means that there would inevitably be a delay in malicious apps being removed from an app store (unlike the situation on Google Play, where Google could prevent publication of the app and ban the developer account). Off-Play app stores might not agree with Google’s assessment, and may refuse to remove the malicious app. That risks harm to users and their devices whilst the issue is communicated and resolved, or for longer if the other app stores do not agree with Google’s assessment that the app is malicious. To the best of my knowledge, Google does not have any contractual arrangements with off-Play app stores permitting Google to make or suggest changes to the content of their app stores.
4354 Mr Porst added that allowing other app stores to be distributed on the Play Store would enable developers to bypass Google’s app review process by simply launching their app on a different store, which store in turn is accessible on the Play Store. Clause 4.5 mitigates this security risk by ensuring that third-party app stores are not on the Play Store.
4355 Second, and relatedly, Google makes the fair point that clause 4.5 improves the competitiveness of the Play Store by preventing the reputational harm it inevitably would suffer if third-party app stores were distributed on the Play Store and later found to contain PHAs.
4356 Mr Porst gave evidence that the reasons for not distributing other app stores through the Play Store concern user safety and security, the user experience generally, and the flow-on effects on the reputation of the Android ecosystem.
4357 Mr Feng explained:
I think that this user-driven and trust-driven approach is a fundamental component of what Google Play does. If users began to encounter issues with third party app stores (and apps distributed via those stores) distributed through Google Play, I think that the impact on Google Play would be immense in terms of brand damage, erosion of user trust and, ultimately, the number of users of Google Play and Android more generally. This is because users are more likely to think that Android is unsafe generally, and in particular they are likely to blame Google for permitting Google Play to distribute unsafe third party app stores. Users rightly expect Google to only distribute safe software and to carefully monitor what is available on Google Play … I consider that there would be considerable risk that a user would think that Google is implicitly endorsing or representing as safe a third party app store if it was available on Google Play. …
4358 Another important aspect to the reputation dynamic is that Google is combating a perception, amongst users, and amongst developers, that Android is less safe than iOS.
4359 So, for the Play Store to compete effectively with the iOS App Store, it is important that users trust the high level of security on Android generally, and more specifically that they trust the safety of the Play Store. Clause 4.5 assists with this objective.
4360 Now Epic says that clause 4.5 of the DDA has the purpose of stifling emerging competition for the Play Store.
4361 First, Epic says that an anti-competitive purpose can be inferred from an amendment to clause 4.5 in September 2014.
4362 Prior to September 2014, clause 4.5 read:
Non-Compete. You may not use the Market to distribute or make available any Product whose primary purpose is to facilitate the distribution of software applications and games for use on Android devices outside of the Market.
4363 In September 2014, clause 4.5 was amended to read:
You may not use Google Play to distribute or make available any Product that has a purpose that facilitates the distribution of software applications and games for use on Android devices outside of Google Play.
4364 Epic says that Google amended clause 4.5 because it was concerned that social media, and companies like Amazon, whose primary purpose was not necessarily to distribute apps, were emerging as potential competitors to the Play Store.
4365 But as Google says, the competitive threat from Amazon arises from the Amazon Appstore, and that app store fell within the prohibition in the previous version of the provision. The purpose of the provision did not change. App stores were always prohibited. As Google said, the amendment removed the potential for debate about whether the primary purpose was the distribution of apps.
4366 Second, Epic says that if Google’s objective was to prevent free-riding, it could have charged third-party app stores a price for the services being provided rather than instituting a blanket prohibition.
4367 But as Google says, restrictions on carrying a competitor app store prevent the appropriation of assets. I agree with Google that companies ordinarily should not have to host their competitors in return for payment. That would inhibit true competition and inhibit dynamic efficiency.
4368 Third, Epic says that the purpose of clause 4.5 cannot be security-related because the Play Store distributes messaging apps, web browsers and peer-to-peer apps, all of which can be used to distribute apps and which pose no different security risk to third-party app stores. But I agree with Google that that argument has little substance.
4369 Fourth, the matters that I am just about to discuss below also point against Google having an anti-competitive purpose. Indeed, they rather suggest a purpose consistent with the very essence of competition.
4370 In my view Epic has not demonstrated that clause 4.5 has the purpose of substantially lessening competition.
Epic’s effects case
4371 Now as Google correctly characterised the matter in my view, Epic’s case in relation to clause 4.5 is, in essence, a case about compulsory access. Epic seeks access to the Play Store’s customer base, search and discovery facilities, advertising and promotion, software and technology, and any other functions and services used in the provision of the Play Store, for Epic’s benefit.
4372 Epic seeks an order that Google permit app developers to submit and distribute through the Play Store Android apps which create an interface for displaying third-party apps and/or apps which may be used by Android smart mobile device users to download and/or update third-party apps.
4373 It also seeks an order varying the DDA, not only by excising clause 4.5, but by inserting a provision that authorises and permits an app developer to submit and display on the Play Store an Android app which creates an interface for displaying third-party apps and/or which may be used by an Android smart mobile device user to download and/or update third-party apps. That is not stated to be conditional upon reaching agreement as to payment, or any other term.
4374 But I agree with Google that such an order would require Google to aid a competitive rival by giving Epic and other rivals access to its distribution platform, including by providing immediate access to the Play Store’s users that Google has built up through sustained and substantial investment.
4375 As Googe says, Epic would not receive this if it was competing on the merits and was required to build up its own customer base and other facilities for the discovery of and access to its app. Such an order would confer a special advantage on Epic that is otherwise not available in a competitive market.
4376 Further, we are not here dealing with the concept of a natural monopoly.
4377 Now Epic says that as an app store is a type of app, there should be no objection to placing it on the Play Store. But as Google says, app stores can install other apps and therefore contain a vector for malware. A developer with an app is a customer and a potential source of revenue to Google. But in the present context, a developer with an app store is also a competitor.
4378 Clearly, in the absence of a natural monopoly scenario, a company is not usually required to host a rival’s business.
4379 I agree with Google that as a matter of economic theory, the prevention of free-riding is not a restriction on competition, because free-riding is not legitimate competition. Free-riding defeats the ultimate benefits of competition because it is destructive of efficiency. As Google says, if a firm cannot realise the benefits of its commercial endeavours, it will not pursue those endeavours or will not pursue them as vigorously or completely.
4380 Google has given the following summary of the conceptual questions and considerations which I largely agree with.
4381 Free-riding can be problematic if it reduces the incentives of a firm to invest, because the return from investing will be appropriated by other firms or will not be recovered. All else being equal, conduct that prevents free-riding on a firm’s investments such that the firm is unable to earn a competitive rate of return does not harm competition and preserves investment incentives.
4382 Moreover, the very essence of competition should involve incentivising or encouraging a potential rival or new entrant to independently compete on their merits rather than being parasitic on the endeavours of others!
4383 So, compulsory access is normally the subject of special provisions and requires the satisfaction of preconditions that the service in question has natural monopoly characteristics, meaning that it is unable to be economically duplicated and there is no other way of competing with that facility. But that is not the case here.
4384 In the absence of the existence of those conditions, the requirement to host a competitor confers a privileged access and a bypass of the competitive process. Preventing such privileged access does not amount to a substantial lessening of competition.
4385 Now as Google points out, a restriction along the lines of clause 4.5 is largely standard for app stores. The evidence suggests that 11 out of 13 app stores analysed, including all mobile app stores, two PC stores and all but one of the console stores for which information was available, had a provision restricting the distribution of a rival app store. This included all major Android app stores. But of course such a general practice does not necessarily mean that it is not anti-competitive.
4386 Let me say something on the question of security, albeit that in my view Google’s concerns were overstated.
4387 I agree with Google to some extent that hosting third-party app stores on the Play Store also poses a security risk and related reputational risk for the Play Store and Android and clause 4.5 in part addresses this risk.
4388 The Play Store provides various benefits and features including a comprehensive scan and review of apps published on the Play Store. The Play Store also provides re-review of apps to determine whether apps are safe and whether apps comply with Google’s policies in relation to app content. This feature is a form of quality assurance to users.
4389 If a rival app store were placed on the Play Store, such an app store and apps installed from that app store could appear to have come from a source approved by Google and so have the imprimatur of Google.
4390 Currently, Google has no visibility or control over the apps in a rival’s app store, and is constrained in its ability to review each and every app and app update that that app store may distribute. I accept that an app store implicitly endorses every app that it lists, which would include apps that are app stores.
4391 Further, I accept Google’s point that requiring Google to distribute third-party app stores would necessitate fundamental changes to how the Play Store operates, including how it reviews apps distributed by third-party app stores.
4392 Further, Mr Porst explained that third-party app stores contain greater security risks than file-sharing apps, web browsers or messaging apps. Indeed, apparently Google had had the experience of seeing multiple stores that were created specifically for distributing malware, and so would have a 100% malware distribution rate, which is more than any kind of distribution rate that one would see for WhatsApp or for a file-sharing application.
4393 Further, distributors of malware, pirated apps, and/or objectionable content would also want their apps or app stores on the Play Store. As Google says, in seeking to prohibit clause 4.5 and replace it with a standardless must-carry obligation, Epic would be exposing Google to an obligation to carry malware stores or stores with questionable content or security.
4394 Now Epic says that having a rival app store on the Play Store is akin to the Play Store hosting other types of apps that can install apps, and it gave various examples being messaging apps such as WhatsApp and file sharing apps such as SHAREit. But there is an important distinction as Google points out. The other app types have a primary purpose other than distributing and installing apps.
4395 WhatsApp is primarily used to send messages. SHAREit is primarily used to share files of many types such as photos, videos and documents. For apps received through WhatsApp or SHAREit, the user would also see a specific sender, which makes it clear that the material is not provided by WhatsApp or SHAREit. A person using WhatsApp who receives an executable file would expect to exercise greater caution before installing an app sent by this method. This would be reinforced by the unknown source flow that a user would experience the first time they endeavoured to install an app from WhatsApp or SHAREit.
4396 But contrastingly, as Google points out, the primary function of an app store is to distribute executable files and users go to app stores specifically to install apps on their devices.
4397 Moreover, by hosting an app store on the Play Store, users would understand Google to be indicating that the app store was a safe place from which to install apps.
4398 Further, as Google points out, not allowing third-party app stores on the Play Store is consistent with the advice of government bodies and other entities, which recommend against installing apps on users' devices unless they are from a trusted source such as the App Store or the Play Store.
4399 Let me now say something about the counterfactual. Now as Google says, even if one was to undertake a counterfactual analysis to assess whether clause 4.5 had the effect of substantially lessening competition, Google would be entitled to impose terms including a fee on access. Google would be entitled to charge the rival app store for access to the customer base and other services.
4400 I also accept that in calculating the access fee, Google would take into account the opportunity cost of providing access to a rival. I accept that Google would be concerned with how much custom would be diverted to a rival by virtue of the access and that this would be taken into account in terms of the economic cost of provision. Putting it another way, I accept that the charge would reflect a reasonable return on the value of access being provided.
4401 Now as Google says, it is for Epic to establish a real possibility that any third-party app store is likely to obtain access to the Play Store, and obtain sufficient competitive benefit from such access, in the relevant counterfactual such that clause 4.5 can be assessed as having the likely effect of substantially lessening competition. And I agree with Google that Epic has not established this.
Summary
4402 So, in terms of clause 4.5 of the DDA and the ban on, in effect, an app store within an app store, I am not prepared to find that Google imposed this with the purpose or effect or likely effect of substantially lessening competition in the Android app distribution services market.
4403 First, it must be recalled that Google has permitted direct downloading or sideloading of other competing Android app stores. So such competition was not substantially hindered by Google.
4404 Second, such a ban is targeted if at all against competitors rather than competition.
4405 Third, Google seems to have had various purposes for such a ban. One purpose was to address security risk as Google perceived it. Another purpose was to prevent free riders. And an associated purpose was to protect the asset that it had invested in and built up.
4406 Clearly there was no anti-competitive purpose. Moreover, given the other avenues for the direct downloading or side-loading of alternative Android app stores, in my view no actual or likely anti-competitive effect has been shown. Let me now turn to a new topic concerning Google’s technical restrictions and begin with security.
Android ecosystem security – General
4407 Now Professor Somayaji gave expert evidence for Epic on Google technology and security questions. I have made some preliminary observations concerning his evidence in the Apple proceeding which I would repeat here. I should also say here that relevant numbering or lettering of tables and figures preserve the referencing used by Professor Somayaji or used by any other expert witness that I have referenced.
4408 Let me say something about Google’s witnesses concerning technology and security.
4409 Mr Sebastian Porst, a senior engineering manager at Google Germany GmbH, gave written evidence in chief principally concerning the real time scanning of apps. He was cross-examined by Dr Higgins SC for Epic.
4410 He was technically very proficient and refreshingly precise. This was a pleasant contrast with some of Google’s other witnesses that engaged in marketing speak or were otherwise pushing the corporate line when the opportunity arose in cross-examination. In short, I found him to be a model witness. Nothing more need be said.
4411 Mr Edward Cunningham, a director of product management at Google UK Limited, gave written evidence in chief. He was extensively cross-examined by Dr Higgins SC.
4412 I found Mr Cunningham to be a careful and reliable witness. Further, he had considerable expertise in the technical questions that he was addressing. Occasionally he was a little overly cautious. But at all events, I had no major reservations with Mr Cunningham’s reliability. And indeed he made appropriate concessions from time to time. I have discussed specific subject matter elsewhere.
4413 Professor Patrick Traynor, a professor of computer science and engineering at the University of Florida, gave expert evidence for Google. He dealt with topics relevant to security and technology and responded to Professor Somayaji’s evidence. He also separately addressed questions of real time scanning and installation of apps questions. Professor Traynor also participated in a joint expert report with Professor Somayaji and Professor Rubin, the Apple expert whose evidence I have discussed elsewhere. Professor Traynor was cross-examined by Dr Higgins SC for Epic.
4414 Clearly, Professor Traynor was also technically very proficient. I have no difficulty with his expertise or reliability. In terms of the subject matter of his opinions and what I have ultimately accepted, I have addressed such questions elsewhere.
4415 I should say that of all three witnesses on these topics, namely, Professor Somayaji, Professor Traynor and Professor Rubin, I have drawn the most from the first two experts.
General technical and security concepts
4416 Before I descend into the detail, it is useful to begin with some general matters.
4417 Google adopts multi-layered defences against malicious software and unauthorised use. So, no single layer of defence provides complete security for a system but the layers work together to achieve as high a degree of security as possible. A layered security model is used for GMS devices.
4418 There are OS-level protections such as application sandboxing and a permissions system. These control what apps do and do not run in a manner that is agnostic as to the channels through which apps are distributed. The OS-level technologies include file access control technologies, digital code signing and app sandboxing, which apply on GMS devices subject to policies regarding the application of these technologies.
4419 But it is not contentious that OS-level security protections are not sufficient on their own to protect against malicious and unwanted apps. There are various possibilities. So, a sandbox could be compromised. Further, malware in the form of elevated privilege abuse, which is code that compromises the integrity of the system by breaking the app sandbox, could gain elevated privileges or change or disable access to core security-related functions. Obviously, there are other possibilities.
4420 Further, Google undertakes comprehensive and sophisticated scanning and review of apps submitted for publication on the Play Store and some apps not released on the Play Store. This process is most comprehensive for apps in the former category, that is, apps that a developer wishes to release on the Play Store, including updates.
4421 The comprehensive scan and review involves different types of analysis. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. I will return to these questions later.
4422 Further, Google requires unknown sources warnings on GMS devices, the detail of which I have discussed elsewhere.
4423 Let me turn to some general concepts and for that purpose it is convenient to set out some extracts from Professor Somayaji’s evidence or to paraphrase parts thereof. Now although there is some overlap with what I have said in my reasons in Epic v Apple, this is necessary for comprehension. Further, I am dealing here with matters relevant to the Google/Android context.
4424 Android is a mix of proprietary and open source software. Proprietary here means software that is licensed under a restrictive license that gives distributors and end users strictly circumscribed rights to duplicate, inspect, modify, and even reverse engineer the code. In contrast, open source is software whose license places very few restrictions on such activities.
4425 The code for some programming languages, such as JavaScript, are distributed as source code, as the source code was designed to be the format that was executed via a runtime rather than being converted, that is, compiled to machine code.
4426 WebAssembly is a newer byte code language that replaces some JavaScript in web applications, as WebAssembly can be faster to run than JavaScript. Byte code is a type of intermediate code made up of platform-agnostic instructions which are dynamically translated into machine code by runtimes.
4427 In the context of Android, “DEX” files are individual bytecode files that are translated by the “Android RunTime”, which is part of the Android Open Source Project (AOSP).
4428 Most software is distributed as machine code encapsulated in some mix of object, library, and executable files, enabling programs to be run but not easily inspected or modified. Open source software is, in part, software for which the source code is made available.
4429 For a license to meet the requirements of open source as defined by the Open Source Initiative (OSI), others must be allowed to modify the software and to redistribute the modified versions without owing any licensing fee or placing a variety of other restrictions on the software’s use. The OSI, founded in 1998, is an organisation that maintains the definition of open source and promotes the use of open source licenses.
4430 The core technology of Android is developed by Google as open source software and is distributed by them through the AOSP. Because it is open source, anyone can take AOSP code and use it as the base of their own operating system. These operating systems are “forks” of Android, meaning they are modified versions of AOSP code. But a device running an Android fork can only be recognised as Android if it is certified by Google, which requires ongoing compliance with a variety of legal and technical constraints.
4431 Now in what follows, the term “Android” refers to an AOSP–based operating system that is certified by Google running on devices produced by Google and other OEMs using or installed with GMS or capable of doing so. Contrastingly, the term “Android fork” or Android-like operating systems refers to AOSP–based operating systems that are not certified by Google such as Amazon’s Fire OS.
4432 Now Professor Somayaji’s focus was on Android running on touchscreen-based smartphones and tablets such as the Google Pixel phones or the Samsung Galaxy Tab tablets, as these are the devices for which most Android apps are developed and where most run.
4433 As I have explained elsewhere, an application or app is a computer program that provides functionality beyond that supplied by the operating system. Indeed, the purpose of an operating system is to provide the infrastructure needed to run apps. Apps can have a very narrow purpose like a calculator or can be very general. Apps also can be specific to a particular operating system such as native apps or platform agnostic such as web apps.
4434 Whilst there exist programming languages, libraries, graphical user interface toolkits, and development environments that can be used to make apps that can run on many operating systems, today cross-platform apps are mostly created using web technologies.
4435 Interestingly enough, the primary language of Android, Java, was designed to create apps that run on multiple operating systems. But Android’s version of Java is not easily portable to other operating systems.
4436 Now as I have explained elsewhere, an app store is an app that connects to an internet service in order to facilitate the installation of additional apps onto a device. An app store has an explicitly defined set of apps that can be searched using keywords or other criteria. Apps can also be browsed, typically via lists sorted by name, developer, category, or other characteristics. Once an app is selected and authorised for installation, the app is transferred to the system or device, verified by the operating system, and then installed. App stores also normally facilitate the maintenance and updating of installed apps.
4437 App stores are available on a variety of platforms. Cloud-based services, network-attached storage servers, game consoles, and other systems all have app stores, but Professor Somayaji’s focus was on the app stores on GMS devices.
4438 Professor Somayaji expressed the following opinions, which I accept unless I state otherwise or indicate qualifications.
The question of device compatibility
4439 Now a consistent theme that emerges across some devices and software products is the limited functionality available for devices outside of their native ecosystem, not only with the iOS ecosystem but also with the Android ecosystem.
4440 Some products such as AirPods and Pixel Buds, support only basic functionality for Android and iOS phones, respectively, without the operating system integration and extra features that normally distinguish these products from standard Bluetooth headsets, even though these products have many features in common.
4441 On the smartwatch side, the Apple Watch cannot be set up without being connected to an iPhone. Certain Wear OS devices, such as the Pixel Watch and Galaxy Watch, cannot be set up out of the box without being connected to an Android phone.
4442 The interoperability issues extend to other devices and proprietary services. Android users cannot stream music reliably to a HomePod, cannot stream content to their Apple TV, any iCloud data they have will not be accessible outside of a web app, and they will lose access to iMessage. Similarly, iPhone users have reduced functionality with some Android-focused accessories such as the Pixel Watch, Galaxy Watch, and Pixel Buds and lose access to in-app purchases made through the Play Store.
4443 When a user wishes to move to a new operating system, they need to learn how to use the new operating system, move their apps and their data to the new system, and connect the new system to the services and other devices that they use. A lack of interoperability can make what should be a relatively straightforward process much more difficult due to data and service incompatibilities.
4444 Lack of interoperability is not the result of an inherent incompatibility between Apple’s devices and Google’s devices, but rather is the result of decisions by them to not extend access to proprietary technology to third parties. Whilst Apple and increasingly Google add proprietary hardware to their devices, interoperability often requires that devices have the right code at the operating system level, and that code could be developed by third parties given appropriate access to the operating system. But mobile device ecosystems do not give such access today, as security mechanisms limit app functionality and mostly forbid operating system modifications. Even if access were granted, figuring out how to interoperate with a complex system requires significant expertise and effort.
4445 But interoperability does happen in select cases. Apple does make apps for Android such as Apple Music and Apple TV, Google makes many apps for iOS, and many companies maintain their apps for both iOS and Android. Devices making use of standards such as Bluetooth work with both operating systems.
4446 Indeed, interoperating between iOS and Android may be relatively easy for users who mostly rely on apps, services, and devices that are well supported in both ecosystems.
4447 For a user to avoid interoperability issues, they must make a conscious effort to avoid non-portable functionality. Users have to avoid the first-party solutions for messaging, photo management, and purchases and instead use cross-platform solutions for these and other tasks. They also must avoid purchasing hardware companion devices that are designed to work specifically with one or another operating system. But in so doing, users miss out on the enhanced usability, functionality, and integration provided by first-party proprietary solutions.
4448 Many users naturally do not want forgo these advantages, and so they end up committed to one ecosystem or another, even though most of what they do and most device functionality is well supported in both. A single device, service, or app can be enough to keep a user in one ecosystem or another, if it is important enough to them.
4449 Technical standards allow hardware and software to interoperate by giving them a common set of interfaces with which to interact. Interoperability with standards is relatively straightforward. Implement the standard properly and you can interact with any other system implementing the same standard.
4450 But interoperability with proprietary technology requires ongoing development effort and sufficient access to implement and integrate the software necessary to support interoperability. The polish and ease of use of many proprietary solutions, such as AirPods or Pixel Buds, is only possible because these devices have special built-in support in iOS and Android. Without such support, much of their advanced functionality simply is not possible to implement in the other ecosystem.
4451 Let me now turn to the question of operating systems.
Android operating system – some detail
4452 Professor Somayaji’s figure 3 shows the technical components of the Android operating system:
4453 As shown in figure 3, Android is an operating system that uses Linux as its kernel. Because it has many user space components that go beyond the standard functionality of a UNIX-like operating system, Android can be considered its own operating system rather than yet another version of Linux. Whilst there exist open source operating systems where user space and kernel space components are developed together as one project, Linux as a term only refers to the kernel the operating system runs rather than the entire system. “Linux distribution” is the term given to an operating system that uses the Linux kernel along with various other normally open source programs to make a complete working operating system. Most Linux distributions are designed to be UNIX-like, in reference to the UNIX operating system that was first developed in the 1970’s at AT&T.
4454 Whilst almost nobody runs UNIX today, as few bother to get the certifications needed to use the UNIX trademark, most operating systems in use today are, at least in part, UNIX-like, including Windows.
4455 In particular, the hardware abstraction layer, Android runtime, and Java API framework are specific to Android.
4456 Whilst Android applications can use the functionality provided by the Linux kernel and the standard C library, as do most applications for UNIX-like systems, Android applications normally run on the Java runtime rather than as native code and use Android’s Java-based APIs. Whilst Android’s Java has always used its own runtime and has many Android-specific Java libraries, it was originally based on the Java created by Sun and now owned by Oracle.
4457 Although newer Android applications are written in Kotlin, a newer programming language designed to improve programmer efficiency and program reliability, Kotlin smoothly interoperates with existing Android Java code.
4458 All of the components shown in figure 3 are part of AOSP and are licensed using various open source licenses. Because AOSP is open source, anybody can download, modify, and distribute their versions of an AOSP–based operating system. But such operating systems cannot be called Android since Google holds that trademark and only allows certified versions to use it. Nevertheless, many have used AOSP as the basis for their operating systems. These systems are Android-like because they share much of their code and many APIs with Android. But in practice Android-like systems cannot run many, if not most, Android applications because Android is more than the code in AOSP, and the reasons for this are related to the fragmented Android installed base.
Android fragmentation
4459 Android fragmentation refers to the significant diversity in the versions and modifications of the Android OS used across various devices. There are two main types of fragmentation, being OEM fragmentation and version fragmentation.
4460 OEM fragmentation refers to the modifications made by OEMs to the stock Android OS, creating their own customised versions. These customisations can include unique interfaces, features, and pre-installed applications tailored to a specific brand or device.
4461 Version fragmentation, on the other hand, occurs when different devices run on various versions of the Android OS, ranging from older to the most recent releases.
4462 These two types of fragmentation are distinct but interrelated.
4463 First, on OEM fragmentation, Google research from 2016 found that over 1,300 total OEM brands had produced Android devices. With many OEMs producing multiple different Android devices, total Android device combinations exceeded 24,000.
4464 With respect to version fragmentation, the Android installed base, being the population of devices in use running Android, is extremely fragmented between Android versions. A report from early 2023, summarised in table 1 below, found that the most recent Android version only had an approximately 5% share of the install base. The most popular version of Android by install base share was Android 11, a release which is now four versions outdated and was released on September 8, 2020; apparently, there is now Android 15.
Table 1: Android Version Fragmentation in January 2023
Android Version | Share of Android Devices |
Android 13 | 5.2% |
Android 12 | 18.9% |
Android 11 | 24.4% |
Android 10 | 19.5% |
Android 9 | 13.2% |
Android 8 | 9.5% |
Android 7 | 3.5% |
4465 Whilst some version fragmentation in Android devices results from users not upgrading, most of it occurs because many devices do not support newer Android versions. With the core of Android being open source, this lack of upgrades might seem paradoxical. Indeed, even the latest versions of Linux can run on ten-year or older hardware. But whilst Android’s core is open source, versions of Android installed on devices also consist of OEM proprietary code and in many cases Google proprietary code. While open source portions receive regular updates, OEM proprietary code becomes outdated as hardware becomes obsolete. Unlike Linux’s open source drivers, Android device drivers are proprietary, written by vendors and OEMs for specific phones. Updating device-specific code for newer Android versions is costly, leading manufacturers to limit updates for older hardware. Consequently, almost all Android devices only receive updates for a few years, after which the core operating system cannot be changed.
4466 Another factor is that many mobile devices do not run “stock” Android as produced by Google. Instead, they take the AOSP code as a base and make their own proprietary changes. Sometimes these changes can be limited in scope, such as modifying the camera app to take advantage of special features provided by the hardware. But others can be complex and invasive, for example changing the interface in drastic ways to make it resemble peer operating systems. When Google releases a new version of Android through AOSP, anyone who has created a modified version of Android has to port their changes to the new release. When the changes are complex, this process is non-trivial and can require several months or longer. As a result, some devices consistently run older versions of Android even when brand new.
4467 A by-product of this version fragmentation is that developers are left with a conundrum. They can target older versions of Android to maintain compatibility with most devices, as newer releases can generally run applications targeting older APIs, but at the cost of missing out on the latest Android features and thus potentially producing an inferior application. Alternately, they can target the APIs present in the latest Android versions, but then their apps can only run on the latest devices which are a fraction of the total potential user base.
4468 Google provides a proprietary compatibility layer that allows developers to use the latest APIs while maintaining compatibility with older Android releases. This compatibility layer greatly reduces the impact of version fragmentation on developers because they can continue to use many of the newest APIs and components on older devices. But the price for targeting this API is that their apps will not run on many Android-like systems, being forked versions of Android. Version fragmentation in Android also has significant security implications.
Android security and its evolution
4469 Now Android security has evolved significantly since its inception in 2008. Professor Somayaji’s figure 4 shows an illustrative, non-exhaustive selection of security features added to Android over its development history:
4470 Early versions of Android relied on the standard Linux security model that was originally designed to separate the files and processes of multiple users working on the same computer. With Android, those “users” were repurposed to represent applications, with each application having its own separate user ID and its files marked as only being accessible by that application via that assigned user ID. These initial protections were found to be insufficient, and so additional mechanisms were added to increase the separation between applications, to mitigate software vulnerabilities in the kernel, operating system services and applications, to prevent unauthorised applications from being installed, and to prevent data leaks when devices are stolen.
4471 The high level of version fragmentation in the Android ecosystem, to a degree, impacts its overall security. But many but not all of these security issues are mitigated through the use of GMS, elements of which are relevant to security.
4472 Some of the technical components of GMS provide security assurance by regularly updating app security features and scanning for potential threats.
Relationship between Google and device makers
4473 The production of Android devices involves collaboration between Google and three other agents, being silicon manufacturer partners, device makers or OEMs, and carriers. These entities are represented in Professor Somayaji’s figure 5 below, which depicts a Google diagram taken directly from Android documentation. Silicon manufacturers are companies that produce the chips that power Android devices such as Qualcomm and MediaTek. OEMs are companies that design and manufacture Android devices such as Samsung, Sony, and LG. Carriers refer to wireless carriers such as Optus, Telstra and TPG (Vodafone) that provide essential mobile services such as phone calls, text, and data usage.
4474 Android at its core is an open source operating system. When Google releases a new version of Android, it makes the corresponding information and source code publicly available through AOSP. The process of integrating a new version of the operating system into an Android device starts with silicon manufacturers. Silicon manufacturers take the released code from AOSP as a base and add code to support their systems-on-a-chip so to speak and additional support chips that provide other necessary functionality such as cellular connectivity. This process produces a board support package. The OEMs then take the package of their chosen systems-on-a-chip and add code to support additional hardware such as cameras and displays, modifying the core operating system to enable differentiation from other devices by changing the Android user interface and adding their own custom and third-party applications, and so producing software that runs on a specific model of phone. This process gives rise to OEM fragmentation. Finally, carriers will certify a phone to run on their network and in so doing may require minor changes to functionality and their own apps to be added to the phone’s installed operating system.
4475 Android being an open source operating system technically allows OEMs to modify the AOSP code to suit their purposes. But the actual extent of their modification is shaped by Google’s control of the Android ecosystem.
Android licensing requirements for OEMs
4476 Google’s Android code is made up of open source and licensable components, allowing OEMs to license Android for devices they produce. This is in contrast to Apple’s iOS, which is only available on Apple-manufactured devices and cannot be licensed by third-party OEMs. Android OEMs start by copying the AOSP code as a base and then making modifications to configure AOSP code to their specific device. OEM modifications can include the following aspects.
4477 First, they can include adding custom modules and libraries to support OEM-specific functionality. Doing so allows OEMs to add custom software features for users. For example, Samsung, a popular OEM, includes libraries and services in their version of Android to support Bixby, Samsung’s proprietary personal assistant.
4478 Second, they can include adding custom UI elements to create an OEM-specific look and feel for the device software. Doing so allows OEMs to add a custom, differentiated interface for users. For example, Samsung adds their proprietary “One UI” to their version of Android, which integrates recognisable Samsung UI elements into the operating system.
4479 Third, they can include adding custom, device-specific drivers to the Android kernel allows Android to interact with the device hardware. Adding these drivers is necessary for Android to be able to communicate with the memory chip, CPU, device sensors, and other components of the OEM’s device hardware. For example, Samsung adds a driver for the S-Pen, a stylus accessory that serves as a sensor input for a number of user actions such as note taking and triggering the camera shutter.
4480 OEMs’ ability to modify any component of the Android operating system is limited by Google’s contractual restrictions on kernel-level changes.
4481 The kernel, being the heart of the operating system, controls computer hardware, system resources, and access privileges for other components. Consequently, kernel code and the capability to update it in case of vulnerabilities are crucial for device security. Google’s relevant contracts prohibit OEMs from directly modifying the kernel code or managing kernel software updates. Instead, Google oversees the kernel code and provides patches when modifications are necessary. As a result, kernel code and Google’s update ability remain consistent across Android devices, regardless of the manufacturer.
4482 Google was not able to do timely kernel updates with earlier versions of Android. But with the introduction of Project Treble in 2017, Google modularised Android’s core operating system framework code to isolate it from code added by OEMs. OEM code can still influence the operating system’s behaviour, but it now communicates with the base code through a specialised vendor interface, which is implemented in a hardware abstraction layer, rather than OEMs modifying the operating system framework directly. This partition allows Google to maintain and update the operating system framework independently of OEM code updates; but because the vendor interface is closely tied to the version of the Linux kernel, a newer kernel version will likely break the vendor interface. As a result, this change only enabled a couple of more years of operating system updates on most devices.
4483 After OEMs modify the AOSP code as described above, the resulting operating system software is based on the AOSP code but enhanced with OEM-specific code. But at this stage of development, the OEM-altered operating system is not acknowledged as an official Android version by Google, nor does it provide essential Android features such as access to Google Maps, Google Chrome, and crucial security features like Google’s malware scanning. These features are excluded from the open-source AOSP code and require licensing from Google for usage.
4484 To enable the operating system to utilise these additional features and be recognised as an official Android version by Google, OEMs must complete two further steps. First, they must join Google’s Android compatibility program. Second, they must obtain GMS certification directly from Google to be able to include proprietary apps and Google Play Services with the device. These steps impose both contractual and technical requirements on OEMs and their devices. Versions that have fulfilled both steps are GMS certified Android versions.
4485 Professor Somayaji’s figure 6 provides an overview of the process for creating GMS certified Android versions:
Android compatibility program
4486 Introduced alongside early versions of Android, the Android compatibility program is a Google-run program that sets requirements for devices to be officially recognised by Google as Android devices. If a device is not part of this program, it is not recognised by Google as part of the Android ecosystem. In order for an OEM’s device to be so certified, the OEM’s modified version of Android must be approved by Google.
4487 In order to receive certification, OEMs must sign the Android Compatibility Commitment, which I have referred to elsewhere as the ACC. The ACC requires that OEMs’ devices comply with the software and hardware specifications enumerated in Google’s Compatibility Definition Document, which I have referred to elsewhere as the CDD. For the purposes of his analysis, Professor Somayaji focused on software specifications rather than hardware specifications, the latter of which were less relevant to the questions posed to him. Requirements in the CDD are split into eight main categories, shown in Professor Somayaji’s table 6:
4488 The requirements in the CDD from an operating system perspective set baseline standards for the configuration, behaviour, and security of Android versions. Requirements include specifications for what APIs certified Android versions can support and what permissions they can grant to applications.
4489 Google develops and maintains an automated software testing suite being the Compatibility Testing Suite, which I have referred to elsewhere as the CTS, to ensure compliance with the CDD. The CTS scans OEM-modified versions of Android and determines whether they meet the technical requirements in the CDD. If an OEM’s version of Android passes the CTS and the OEM enrols in the compatibility program, the OEM’s version of Android is recognised as a certified version of Android, and the OEM’s device is recognised by Google as an Android device. Once this occurs, the OEM can apply for GMS certification.
Google Mobile Services
4490 GMS is a set of proprietary software developed by Google, including various apps and Google Play Services, which run on top of certified Android versions. Popular Google apps such as Google Chrome, Gmail, Google Maps, and YouTube, are part of GMS.
4491 GMS includes a broad set of APIs and services for Android app development that are withheld from the open source AOSP code such as APIs that enable location services, APIs that allow for data collection, and APIs that enable gaming features.
4492 The functionality that is needed to run many popular Android apps, such as WhatsApp and Instagram, rely on Google Play Services. Unlike the code included in AOSP, GMS software is proprietary and must be licensed from Google directly.
4493 To obtain a GMS license, an OEM’s version of Android must already be certified. After certification, OEMs must then, first, sign a MADA with Google, the contents of which constrain certain device behaviours, and second, pass an additional round of review by Google. After these steps, OEMs can add GMS software to their devices.
Apps included in GMS
4494 With GMS certification, prerequisite conditions for OEMs to pre-install GMS apps onto their devices include that they must install the whole set of core GMS apps and that Google Search and Play Store must be placed on the home screen of the device and all other Google apps no more than one level below the home screen.
4495 The core set of GMS apps are listed in Professor Somayaji’s table 7 below. Five of these apps, being Google Search, Gmail, Google Chrome, YouTube, and Google Maps, are among the top 10 most used Play Store apps in Australia.
4496 Devices that are not GMS certified cannot ship with any of the apps listed above pre-installed. But devices that are GMS certified are required to ship with all of the apps above pre-installed. Access to GMS apps provides various benefits for Android users, including integration with other services offered by Google that allow for a unified user experience. So, existing Google users can sync data such as bookmarks, history, passwords, and other settings across platforms with Google Chrome.
Google Play Services
4497 Along with the apps described above, GMS also includes key modules and APIs that enable core functionality for many Android apps such as Spotify or WhatsApp, and services such as Google Account sign-in. Collectively, these modules and APIs are called Google Play Services. When an OEM licenses GMS, both the OEM’s device and apps running on the OEM’s device can make use of Google Play Services. Conversely, without a GMS license, Google Play Services cannot be accessed, which can result in a loss of functionality as described further below.
4498 Most modules included with Google Play Services enable device functionality that augments the basic operating system capabilities included with AOSP code. Example modules include “SetupWizard” which facilitates device setup when it is first powered on, “AndroidPlatformServices” which helps facilitate updates to the Android platform by Google, “GooglePackageInstaller” which gives users an interface to decide the runtime permissions of applications such as camera access, and “GoogleContactSyncAdapter” which allows users to sync their saved contacts across devices.
4499 Beyond the modules described above, Google Play Services also includes a “GmsCore” module which provides APIs to enhance capabilities of apps running on Android. These APIs allow apps to make use of additional features which are not available with AOSP code. To access these APIs, Google provides a suite of SDKs to developers building on GMS devices. The Google Play Service SDKs enhance both complex computational capabilities, for example, APIs included with the “ML Kit” SDK allow for machine learning models to run in an app, as well as basic app functions, for example, “Firebase Cloud Messaging” allows apps to send push notifications to users.
4500 SDKs offered through Google Play Services in association with GmsCore are listed in Professor Somayaji’s table 8:
4501 When developers develop apps using APIs or SDKs included with the GmsCore module, their apps become dependent on GMS services and can only run as intended on GMS certified devices. So, a lack of access to GMS services can affect both the basic functionality of the Android operating system as well as the functionality of apps running on the operating system.
4502 Google Play Services are necessary for a number of key operating system features not available in AOSP alone.
4503 First, there is the feature of Google account syncing. GMS certified devices are associated with the user’s Google Account, enabling contact, calendar, Wi-Fi, video game save data, and settings information to be automatically synced to the device on initial setup. This feature is dependent on the “Google Sign-In” API, which is not available to devices that are not GMS certified.
4504 Second, there is the Google Fast Pair service, which is a feature that uses Bluetooth Low Energy to detect and pair with nearby Bluetooth accessories such as headphones or speakers, facilitating an easy pairing of such accessories with the user’s device. This functionality depends on the Nearby Connections API, which is not available to non GMS certified devices.
4505 Third, there are modular software updates. The SDKs provided with Google Play Services enable apps to run on a GMS software layer above the core AOSP operating system. A practical benefit of this system is that APIs and services associated with GMS can be updated independently of the underlying operating system. In the absence of GMS, fixing vulnerabilities in APIs and services can require an update to the operating system by the OEM, which is a more technically involved process and is dependent on the extent to which the OEM continues to support and update their Android version. Additionally, automatic updates of apps are not a feature of AOSP but are rather a feature of the Play Store.
4506 Fourth, GMS certified devices include Google Play Protect, which is Google’s malware protection service. Google Play Protect performs cloud-based and on-device malware detection for apps published on Play Store, as well as apps from other sources such as pre-installation, direct download and third-party app stores. I will return to the detail of this in a moment.
4507 Further, let me say something about the impact of the lack of GMS access on app functionality.
4508 For many Android apps, access to Google Play Services is necessary for them to function properly. When an app is developed to make use of one or more of the Google Play Service APIs and SDKs, lack of access to Google Play Services may cause the app to either lose functionality or fail to operate. Examples of popular apps that depend on Google Play Services, and cannot be run on non-GMS-certified versions of Android, are listed in Professor Somayaji’s table 9:
4509 Android versions of the apps listed above being unable to run on non-GMS-certified versions of Android limits the user experience for devices not subscribed to GMS.
Requirements for accessing GMS
4510 Once an OEM’s Android version passes the CTS, it is eligible to receive GMS certification from Google.
4511 To be able to ship a device with GMS, the OEM must license GMS from Google through a contractual process, and the OEM’s specific Android device must be GMS-certified by Google, which requires the device to pass additional compliance tests administered by Google.
4512 Google requires OEMs to adhere to contractual agreements contained in the MADAs in order to license GMS and use the Android trademark in relation to their device.
4513 Once signed, the MADA authorises OEMs to use GMS on their devices. But the MADA does not leave OEMs free to use Google’s services as they see fit. The MADA separately imposes a number of requirements on the OEM’s device, some of which relate to the installation and visibility of Google applications and services. Some requirements pertain to how the OEM configures the application interface, including a requirement that Google Search and the Play Store must be located on the home screen of the device in addition to being pre-installed. In addition, users cannot delete some of Google’s pre-installed GMS apps such as Google Chrome and Google Calendar. Instead, they can only disable the apps. Disabled apps will not appear on the home screen or the app list, but unlike uninstalled apps, they will continue to take up the phone’s memory.
GMS certification — device compliance tests
4514 After licensing GMS, OEMs must submit their version of Android to Google for GMS-certification, which involves passing a series of compliance tests.
4515 The compliance tests required to receive GMS certification are additional to the CTS. The GMS tests are used to establish that the OEM’s Android version is compatible with Google services and that it complies with the security requirements for GMS. Now whilst the MADA concerns conditions under which Google permits an OEM to use GMS apps and services, for GMS certification Google requires that the OEM’s device can properly run Google apps and services. The tests are listed in Professor Somayaji’s table 11:
4516 If an OEM’s version of Android passes the tests shown above successfully, the OEM is eligible to receive GMS certification for their device. Once the device is GMS-certified, Google registers the device fingerprint with Google Play Protect certification. This certification indicates that Google has a record of the test results for the device, and it allows OEMs to ship devices with GMS software pre-installed.
App distribution
4517 Now I have already discussed this question and Professor Somayaji’s evidence in my reasons in Epic v Apple and would adopt for present purposes that discussion. Let me add some further detail concerning the Google context.
4518 The Play Store has a review process designed in part to exclude malware. But in practice attackers do get their malicious apps listed in the Play Store, just as they can get their apps highly ranked in web search engines. The core reason both can lead users to malware is the same. Both accept submissions from virtually any source, and both use complex yet imperfect methods to screen and rank results so as to minimise the chances users will be directed to sources that could cause harm.
4519 Whilst most Android users obtain apps through app stores, Android also allows them to directly download and install software from anywhere on the internet. But direct app download is not a simple alternative to using app stores on Android, as it involves multiple intricate steps and necessitates acknowledging warnings about potential harm from directly downloading and installing apps.
4520 These complex user experiences and warnings may be suitable for unfamiliar apps from unknown developers since malicious apps can indeed be installed through direct downloads.
4521 But for apps originating from reputable developers, these warnings and installation complications are unhelpful and potentially misleading in terms of security. In fact, excessive warnings on apps known to be safe might desensitise users to those warnings, potentially increasing security risks.
4522 Contrastingly, Windows and macOS eliminate warnings for directly downloaded apps that have been scrutinised or are from trusted developers, applying warnings selectively only to apps of uncertain provenance.
4523 Whilst technical mechanisms can help improve the security of app distribution in any context, ultimately secure app distribution relies on users having a process by which they can be assured they are installing only trustworthy apps.
4524 In Professor Somayaji’s opinion, secure app distribution can be achieved through one or both of app audits and developer vetting processes.
4525 But there is no technical reason why Google’s Play Store would be exclusively suited to facilitate secure distribution. To the contrary, the Play Store has often been a source of untrustworthy apps, with many known instances of malicious apps being distributed after having been approved by the Play Store review process.
4526 So, inhibiting app installation outside of the Play Store does not guarantee that users are not exposed to malware. Whilst the damage these apps have done has been limited by the restrictions Android places on apps at the operating system level, these same restrictions apply to all apps on Android, no matter how they were installed.
4527 Whilst increased scrutiny in the review process could in principle lower the rates of malware in the Play Store, in Professor Somayaji’s opinion, problems arise not primarily because of inadequate review, but because there are almost no barriers to submitting apps in the first place. Attackers can try and try again indefinitely, with new accounts if necessary, until their app is approved.
4528 In his opinion, increasing support for app distribution outside of the Play Store would not decrease the security of Android devices, so long as there remain ways for users to determine whether apps and developers have been vetted, who has done the vetting, and by what process the apps have been vetted. Third-party app stores, as one alternative, have the ability to maintain security guarantees for users, as there are examples of them having strong security records both on Android and on other platforms. Alternatively, allowing apps to be directly downloaded can also be secure so long as users can verify the authorship of apps.
4529 Further, as to native apps and web apps, I have addressed this topic in my reasons in Epic v Apple and do not need to say anything further here.
In-app payments
4530 Let me at this point introduce Professor Somayaji’s views concerning payment solutions although I will return to this topic in more detail in a separate section of my reasons.
4531 Google Play Billing on Android is a digital payment solution which includes features to enable the processing of digital payments, such as a payment gateway, fraud management system, and a checkout interface, as well as features to enable digital inventory management, such as receipt management.
4532 Whilst Google policy requires that all Android apps use Google Play Billing to process transactions of digital goods, there is no technical or security basis for this requirement.
4533 Digital payment solutions, which support the acceptance and processing of payment for digital in-app purchases, are not a technology that is unique to Google. Rather, it is a commoditised technology that is implemented by many third parties in the digital payments industry.
4534 Further, digital inventory management, the additional process which supports the delivery of purchased digital goods, is implemented by databases. Like digital payment solutions, databases are not technologies unique to Google. Rather, they are commoditised technologies that are implemented by many third parties in the digital payments industry. Organisations such as Stripe, Square, Braintree, and Adyen support payment processing. Stripe, Square, Braintree, and Adyen also offer inventory management services, providing equivalent functionality to that offered by Google Play Billing.
4535 Google Play Billing is distinguished by its integration with the Android platform. Other solutions are technically feasible and offer comparable levels of functionality, security, and privacy as digital payment solutions. Android has been and continues to be capable of supporting alternative in-app payment acceptance and processing solutions for Play Store apps, and in fact it already does so for physical goods.
4536 Generally, according to Professor Somayaji, Google Play Billing does not improve the overall security and privacy of end users. There are already many other third-party, alternative digital payment solutions that provide the same functionality and process much higher transaction volumes involving the exchange of much larger amounts of money. Ultimately, according to Professor Somayaji, alternative in-app digital payment solutions to Google Play Billing would have no material effect on the security of Android devices because Android apps already support third-party alternative payment solutions, further enabled by third-party digital inventory systems.
4537 Let me now say something more about security.
Google Play Protect and other security features
4538 It is convenient to discuss as necessary background to my later discussion some evidence concerning Google’s security features. For this purpose I have again drawn in part from Professor Somayaji’s evidence and also, where indicated, Professor Traynor’s evidence.
4539 Google Play Protect (GPP) is on-device anti-malware software that is pre-installed on GMS devices. It is also available for download as a standalone app from the Play Store. A key function of GPP is to scan apps downloaded from off-Play sources, at the time of their installation, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4540 Every one to two days, GPP also scans all apps on a device regardless of their download source, that is, whether on- or off-Play, to determine if those apps are malware.
4541 In either case, if GPP identifies that an app is in Google’s malware database and has been classified as a PHA or MUwS, GPP can take a number of steps. Those steps include warning the user, preventing the installation and, if the app has already been installed, disabling or remotely uninstalling it.
4542 Now GPP is linked with Google Play Services. As a result, GPP only runs on GMS devices, which come pre-installed with Google Play Services. Running as the primary source of malware detection on GMS devices, GPP scans apps both on the Play Store and outside of the Play Store.
4543 In terms of specific techniques for malware detection, GPP, as well as malware detectors on macOS and Windows, perform a combination of signature scanning, which involves matching segments of app code against a database of known malware, heuristic analysis, which involves identifying sequences of commands and instructions not typically found in a well-intentioned app, and behavioural analysis, which involves detecting unusual and potentially malicious behaviour whilst the app runs. Such systems all perform malware scanning when new apps are downloaded. Scanning workloads are shared between the on-device processors and remote servers belonging to Apple, Google, and Microsoft. Typically, on-device scanning will perform a more basic analysis to save system resources, whilst server scanning will employ more intensive analysis processes.
4544 Let me go into some more detail concerning GPP. On GMS devices GPP conducts three types of checks unless disabled.
4545 First, as I have indicated, GPP checks whether apps that a device attempts to install from outside the Play Store, including from unknown sources and preloaded app stores, are on Google’s database of known PHAs and some MUwS; this is what is known as a legacy scan.
4546 If an app is on that malware database, GPP warns the user about the app. The warning identifies the name of the app and provides a reason for the warning. Depending on the severity of the malware found on the app, GPP gives the user a choice about whether to install the app or prevents its installation.
4547 As to the legacy scan, GPP compares [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4548 In addition, in order for the legacy scan to run fully, GPP requires an active internet connection. If a device is offline, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4549 Now in countries without readily accessible and consistent internet connection, users rarely or never go online, but there is a peer-to-peer file sharing community through which a lot of malware is distributed. In those settings, the ability of GPP to prevent the installation of malware is even more constrained.
4550 Second, if an app is not on the Google malware database, in certain countries, GPP may conduct a real time scan of the app that a user is seeking to install. GPP checks whether an app has been previously scanned by Google’s backend app scanning and review infrastructure. If the app has previously been reviewed, the installation process for the app resumes. If the app has not previously been reviewed, GPP provides the user with the option of scanning the app, abandoning the install or installing the app. If a user opts for scanning the app, a portion of the app’s code is analysed by that infrastructure and provides a verdict about whether or not the app is potentially harmful. If the scan does not detect malware, the installation process for the app will resume. If the scan determines the app is unsafe or harmful, GPP warns the user about the app. Depending on the level of danger found to be associated with the app, GPP gives the user a choice about whether to install the app or prevents its installation.
4551 As to the real time scan, it involves a [REDACTED] of part of an app’s code and [REDACTED] [REDACTED] not the [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] nor any human review undertaken as part of Google’s back end scanning and review process.
4552 Third, and as I have indicated, every one to two days GPP checks whether apps that are already installed are on Google’s database of known PHAs. This check applies to all apps regardless of their source, including apps downloaded and installed from the Play Store. If an installed app on a GMS device is found to be a PHA, GPP warns the user about the app or, for more severe PHA categories, uninstalls the app.
[REDACTED]
4553 Google uses [REDACTED] its scanning system, which runs on Google's backend servers and devices, to determine whether to classify apps as PHAs or MUwS. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4554 The primary context in which Google currently deploys [REDACTED] is the scanning of apps distributed via the Play Store, whereby Google uses [REDACTED] to scan apps and app updates. Those apps are either uploaded by developers via a secure developer’s portal, or they are apps that Google itself has developed. Upon scanning an app, Google updates its malware database. That database relevantly consists of [REDACTED] for those apps, as well as associated information pertaining to the results of scanning.
4555 Now [REDACTED] does not only scan apps that are submitted for distribution on the Play Store. Developers and users can cause off Play Store apps to be scanned by [REDACTED]. They may do so by submitting apps to the website virustotal.com, which allows anybody to upload Android apps for scanning. Google has access to, and subsequently scans, any Android app uploaded. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].
4556 In addition to these two sources, Google has commercial relationships with independent companies which send APK files directly to Google for scanning. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4557 Let me at this point say something more about real time scanning.
Real time scanning
4558 Recently there has been the addition of real time scanning of apps obtained outside of the Play Store and that have never been scanned before by Google’s backend scanning technology, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4559 So, [REDACTED] can be queried, in real time, as to whether an app has or has not been previously given a full scan, rather than just being checked against a record of known PHAs and MUwS on the Google malware database.
4560 Now Professor Somayaji discussed whether it was technically feasible to provide real time protection on app installation. Professor Somayaji looked at the example of Windows anti-malware systems. But his position was also based on the inference that the majority of app installations are likely to be of apps that have already been analysed by [REDACTED]
4561 In his view, in an app installation context, all that needs to be done is a check of whether an app has been scanned or not. If it has been scanned previously and was deemed safe, the installation may proceed. If not, then the user should be informed that the app has not yet been analysed and, depending upon the user’s desired security posture, the installation should be cancelled, deferred, or allowed after a clear warning.
4562 Real time scanning gives some security benefits in the last scenario. The existence of real time scanning shows that the [REDACTED] database can be accessed in real time as that is what must be queried by GPP in order to determine whether an app needs to be scanned or not. This information could be used to provide the user with more actionable context at installation time.
4563 GPP’s new real time scanning of directly downloaded and alternative app store apps is an incremental improvement in security.
4564 Now whilst real time scanning improves security, its existence shows that appropriate context could be provided to users when they attempt to install directly downloaded or alternative app store apps. This context could be very close to that provided by the Play Store. Such context is essential in helping users to avoid installing malicious apps. In Professor Somayaji’s opinion, adding this context would be a much greater security upgrade than real time scanning.
4565 Now Professor Traynor also gave evidence on the topic of real time scanning. In his view, although the addition of the real time scan capability to GPP does improve security outcomes, GPP, even with the real time scan, is not sufficient on its own to keep Android users safe from malware and that user notifications for unknown sources are reasonable and proportionate.
4566 In his view, real time scanning adds an additional layer of protection for users who install apps from unknown sources. But real time scanning has several limitations and does not offer the same protection as the Play Store app review process. The Play Store app review process is more comprehensive because [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4567 Let me set out some further technical details as pointed out by Professor Traynor.
4568 When real time scanning is triggered, the user encounters a screen flow where they are asked whether they want to scan the app before installing it. They can also choose not to install the app, or to click “More details” to reveal more text and the option to click “Install anyway.”
4569 The real time scanning occurs [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [[REDACTED]
4570 Real time scanning is designed to take at most 60 seconds to complete on the user’s device, to minimise the added friction they encounter. If users feel that the real time scanning feature takes too long to complete, it could cause them to disable GPP altogether on their device, which could lead to worse security outcomes for those users.
4571 If the user clicks on “Scan app” in the prompt, the on-device GPP software collects important signals from the app and uploads them to Google’s back-end infrastructure, [REDACTED] for a server-side code level evaluation.
4572 Specifically, GPP [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4573 If the scan does not identify any security issues, the app is installed. If the scan determines that the app is either “unsafe” or “harmful,” the user will be prompted to abort the installation but can still choose to install the app anyway. If the scan identifies that the app contains particularly dangerous forms of malware, such as phishing or ransomware, GPP will automatically block the installation.
4574 One benefit of real time scanning is that it offers additional protection against apps from off Play sources that Google has never scanned before but that can easily be identified as malware by an automated process.
4575 Another benefit of real time scanning is that it can offer protection [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4576 Professor Traynor made some further points as to the limitations relating to the real time scanning feature in GPP.
4577 The real time scanning feature receives some information about the app, but the information is limited, which results in several technical limitations on real time scanning. Given these constraints, [REDACTED] Google’s server-side automated backend infrastructure, can perform only a limited review as part of real time scanning.
4578 [REDACTED] performs some types of [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4579 In addition, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4580 Dynamic analysis [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4581 Real time scanning involves [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4582 The real time scanning does not involve any human review.
4583 Further, as Professor Traynor explained, another limitation is that the scan is designed to complete within 60 seconds, including the time to upload and unpack the app and its components. Google engineers who designed the feature [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4584 Further, as Professor Traynor explained, because real time scanning is a feature of GPP, it has several of the limitations of GPP. For example, users can disable GPP, which would prevent real time scanning from being triggered on those devices. Also, GPP requires an active internet connection, which could limit the effectiveness of real time scanning for users in remote areas or who may otherwise not have constant internet access.
Relevant differences
4585 Let me summarise the relevant differences between Google’s app review processes, as explained by the two security experts.
4586 As part of GPP, the role of real time scanning within the Android security architecture is not the same as the Play Store app review process.
4587 The Play Store app review process encompasses many processes, whilst review of off Play Store apps and GPP offer complementary but different layers of protection. As a result, real time scanning does not provide the same protection as either [REDACTED] review of off Play Store apps or the Play Store app review process.
4588 Google uses [REDACTED] to review some apps from off Play Store sources. For instance, it scans apps from off Play sources that are uploaded to [REDACTED] through an on-device feature of GPP called [REDACTED] Google also receives apps to review from sources where developers can upload their apps.
4589 The Play Store app review process is more extensive than is possible for off Play Store apps.
4590 For apps submitted to the Play Store, Google has access to source code uploaded by the developer, whereas for off Play Store apps the code has to be reverse-engineered using tools that have certain technical limitations.
4591 For apps submitted to the Play Store, Google can also communicate with developers to rectify any security concerns that may emerge during app review. This type of communication may not be possible with all developers of off Play Store apps.
4592 Another benefit of the Play Store is that developers who want to obfuscate certain types of code for benign purposes can generate and upload de-obfuscation files for both DEX and native code that allows the code to be de-obfuscated for purposes such as detecting and fixing bugs in the app.
4593 Although the review of off Play Store apps through channels such as [REDACTED] is not as extensive as the Play Store app review process, it is more extensive than real time scanning.
4594 The full automated [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4595 Off Play Store app review can also trigger human review, although in practice off Play Store apps are less likely to go through human review than apps submitted to the Play Store.
The advanced protection program
4596 In addition to basic malware protection technology deployed for most consumers, Google offers the advanced protection program on Android. The advanced protection program is intended for users who are at risk of targeted attack, examples of which include political campaigns, celebrities, activist groups, journalists, and business leaders. The advanced protection program uses much stricter policies, requiring a physical security key for two-factor authentication, limiting third-party app access to Google account data, and offering additional safeguards against phishing attacks. Additionally, the program limits app installations to Play Store and app stores that are pre-installed on the device by the manufacturer through the Android Debug Bridge, removing the option to install apps via direct download.
Behavioural economics evidence
4597 I will return to the technical restrictions in more detail in a moment, but let me for the moment divert into the area of behavioural economics. There are two aspects of the case against Google to which principles of behavioural economics are relevant.
4598 One aspect of Epic’s case concerning Google’s anti-competitive conduct is the MADA requirement that the Play Store be placed on the default home screen (DHS) of Android devices. It is suggested that principles of behavioural economics support the idea that those placement requirements have had the effect of increasing the likelihood of the Play Store being used by Android users as their default app store.
4599 Another aspect of Epic’s case concerning Google’s anti-competitive conduct is the various hurdles it places in front of users who seek to directly download apps to their Android devices. It is said that principles of behavioural economics provide further reasons to conclude that the technical restrictions increase the likelihood of users abandoning or not going ahead with their direct download.
4600 Before proceeding further, let me say something about the expert evidence concerning the field of behavioural economics.
4601 Professor Michael Luca, an associate professor of business administration at the Harvard Business School at the time of trial and now a professor at John Hopkins University and an expert in behavioural economics, gave expert evidence for Epic in the Google proceeding concerning choices made by Android smart mobile device users. He also gave evidence concerning the likely effect of Google’s pre-installation conduct on the behaviour of users. He also responded to Professor Uri Gneezy’s evidence.
4602 There was also a joint expert report prepared by Professor Luca, Professor Gneezy and Professor Goldfarb which was tendered.
4603 Professor Luca was cross-examined by Mr Yezerski SC for Google in a joint session with Professor Gneezy. Professor Goldfarb also participated to a limited extent.
4604 There is no doubting Professor Luca’s expertise and the reliability of most of his evidence.
4605 Professor Gneezy, a professor of economics at the Rady School of Management, University of California (San Diego) gave evidence responding to Professor Luca. He also participated in a joint expert report with Professor Luca and Professor Goldfarb. Again there is no doubting his expertise.
4606 He was cross-examined by Mr Anais d’Arville for Apple.
4607 Now Professor Luca applied well-established behavioural economics principles of default bias, salience, time and effort costs, risk aversion, and inertia to analyse the likely effects of Google's pre-installation conduct and technical restrictions on Android users.
4608 In respect of Google's pre-installation conduct, Professor Luca concluded that because of the Play Store's pre-installation and DHS placement, the Play Store exhibits the properties of a default choice for users who are likely to consider it as the main or default option for app downloads. That is because Google's conduct reduces frictions involved in accessing and using the Play Store. These frictions, and the increased salience and awareness of the Play Store, are likely to increase the share of Android users who download an app via the Play Store relative to other app stores.
4609 Professor Luca also concluded that DHS placement is likely perceived as a signal of app store quality to Android users, and such perceptions are likely to persist due to consumer inertia.
4610 In respect of the technical restrictions, Professor Luca concluded the following.
4611 First, friction in the direct downloading process because of Google's technical restrictions in the form of time and effort costs increases the likelihood of Android users abandoning the process.
4612 Second, friction in the direct downloading process because of Google's technical restrictions encountered by users upon first use is likely perceived by Android users as a recommendation against future direct downloading.
4613 Third, the warning messages have the effect of making purported risks more salient and may lead to some Android users abandoning the process.
4614 In Professor Luca’s view, these consequences have the likely effect that Android users are more likely to download an app via the Play Store relative to other competing Android app stores.
4615 Now these propositions were disputed by Google. Professor Gneezy said that it is not possible to draw conclusions about Android users’ behaviour, whether the direction of that effect or its magnitude, without some form of empirical evidence drawn from the relevant factual context in which the inquiry takes place.
4616 But ultimately, I accept Professor Luca’s evidence. Professor Gneezy did not convincingly undermine Professor Luca's conclusion about the likely direction of the relevant effect.
4617 Let me elaborate in more detail on the evidence.
Pre-installation conduct – Professor Luca
4618 Professor Luca explained that pre-installation of the Play Store on the DHS gives rise to a phenomenon known as “default bias” in the behavioural economics literature.
4619 Default bias describes the tendency of Android users to stick with the default option even if they would prefer an alternative when given an option to choose.
4620 Professor Luca explained that the Play Store is positioned as a default by reason of its pre-installation on the DHS, the effect of which is to increase use of the Play Store among Android users and reduce the use of alternative app stores.
4621 The effect of default bias on consumer behaviour has been observed in diverse settings and is recorded in findings from qualitative and quantitative research in a broad range of behavioural economic literature.
4622 Professor Luca referred to a specific example of the effect of defaults having been studied by reference to default search engines on smartphone web browsers.
4623 In F Decarolis, M Li and F Paternollo, “Competition and Defaults in Online Search” (2023) (Discussion Paper, Centre for Economic Policy Research), the authors measured the effect of the introduction of certain “choice screens” on Android users' choice of search engine on their smartphones following the removal of a requirement that Google Search be pre-installed as the default search engine.
4624 As Professor Luca explained, the study found that in each jurisdiction, changing the default search engine setting was effective in reducing the proportion of Android users that chose to use Google Search and increasing the proportion of users who chose to use an alternative search engine.
4625 The paper demonstrated that the introduction of choice screens required users to make an active choice and that such interventions reduced Google's market share in search.
4626 Professor Luca concluded that the likely effect of Google's pre-installation conduct is that Android users are more likely to choose the Play Store compared to alternatives app stores relative to a world in which the Play Store is not required to be pre-installed on Android devices' DHSs. The primary reasons for Professor Luca's conclusions were as follows.
4627 First, when an alternative app store is pre-installed on the Android device DHS together with the Play Store, such that there may be two default app stores, the Play Store is more likely to be chosen by an Android user relative to a world in which the Play Store is not required to be pre-installed on the DHS.
4628 This effect is exacerbated in circumstances where the alternative app store was previously pre-installed on the Android device in a location other than the DHS, as was the case with the Samsung Galaxy Store prior to 2019, due to consumer inertia and the persistence of reputation.
4629 Second, when an alternative app store is pre-installed on the Android device in a location other than the DHS, Android users must incur search costs to locate the alternative app store. Android users do not incur those costs to select the Play Store because its placement on the DHS of the device renders it an Android user's default choice due to its salience.
4630 In addition, placement of the Play Store on the DHS is likely to be interpreted by Android users as a signal of the Play Store's quality relative to alternative app stores, the effect of which is to reinforce the Play Store as the default choice.
4631 Third, when no alternative app store is pre-installed on the Android device, Android users must incur search and time costs, in other words, frictions, to consider and locate an alternative app store. The extent of those costs are exacerbated in this context by the effect of Google's technical restrictions.
Technical restrictions – Professor Luca
4632 Now it was not in contest between Professor Luca and Professor Gneezy that the warning screens which are a consequence of Google's technical restrictions introduce time and effort costs for Android users. It was not in contest that the pop-ups introduce friction.
4633 Professor Luca explained that general principles from behavioural economics literature mean that the impact of warning messages is likely to depend both on which information is provided and the way in which it is presented.
4634 Applying these principles, Professor Luca concluded that Google's technical restrictions are likely to result in some Android users abandoning the direct download process. One reason for that is that Google's warnings are a one size fits all warning, which do not provide Android users with information which would explain or quantify the purported risks associated with the direct download.
4635 Professor Luca said that the warnings contained in the direct downloading process are not just informational interventions, but also emphasise risks and create frictions, thereby warning Android users not to proceed with the direct download. This effect is compounded by a phenomenon observed in behavioural economic literature called “ambiguity aversion” which provides that individuals tend to overestimate risks in circumstances where there is uncertainty as to the magnitude of the risk.
4636 Professor Luca said that his conclusion was consistent with the findings of empirical research published by Google employees, being A Felt et al, “Improving SSL Warnings: Comprehension and Adherence” (2015) (Conference Paper, CHI 2015 Crossings, Korea), which demonstrated Google's ability to steer Android user behaviour using warning messages without improving Android users' understanding of the purported risks.
4637 In addition, Professor Luca said that an Android user encountering the steps in the sideloading process for the first time may interpret those steps and warnings as a recommendation against future sideloading, including because Android users are likely to anticipate that the frictions will exist during subsequent direct downloads from the same source.
4638 For these reasons, Professor Luca concluded that the technical restrictions are likely to result in some Android users abandoning the direct download process.
Professor Gneezy’s evidence and Google’s arguments
4639 Now it is said by Google that Professor Luca did not undertake any empirical analysis to assess the effects or likely effects of Google’s pre-installation conduct or Google’s technical restrictions. Instead, Professor Luca relied on behavioural economics concepts and studies performed in other settings to make predictions as to the likely effects of the impugned conduct.
4640 Professor Gneezy’s view was that the approach adopted by Professor Luca was unsound and at odds with the fundamental tenet of behavioural economics that any analysis must be based upon observed behaviour rather than theoretical models or assumptions. Professor Gneezy emphasised that human behaviour is often context-specific and hard to predict. For this reason, it is dangerous to extrapolate conclusions across different contexts. Indeed, behavioural scientists are frequently wrong with their initial hypotheses of how people will behave in a given setting.
4641 Google said that Professor Luca’s evidence amounted to no more than the proposition that Google’s pre-installation conduct and Google’s technical restrictions made it more likely, to an unspecified, unquantified and unknowable degree, that Android smart mobile device users would use the Play Store relative to possible counterfactuals. Professor Luca conceded that his evidence did not include any assessment of the magnitude of the likely effect of either Google’s pre-installation conduct or Google’s technical restrictions.
4642 In other words, whilst Professor Luca said that the conduct likely increased the number of users using the Play Store, he could not say, and did not say, by how much.
4643 Google said that the questions addressed by Professor Luca, being how Google’s pre-installation conduct and Google’s technical restrictions likely affected users, were at most only preliminary steps towards what would be the requisite enquiry for determining whether that conduct had a proscribed effect or likely effect on competition.
4644 But Google said that the upshot of Professor Luca’s evidence was that even at that intermediate stage, Professor Luca could offer no view as to the size of any likely effect on user behaviour. That being so, Google says that Professor Luca’s evidence affords no basis upon which I could properly conclude that any effect or likely effect on user behaviour was one that was meaningful or relevant to the competitive process.
4645 But irrespective of this point, Google said that there are additional reasons why Professor Luca’s evidence is inutile.
4646 First, Professor Luca ventured opinions without any empirical analysis notwithstanding the fundamental tenet of behavioural economics that conclusions as to how individuals behave in particular settings require empirical evidence from the setting in question.
4647 Second, with respect to Google’s pre-installation conduct, Professor Luca assumed that OEMs would, on occasion, elect not to pre-install the Play Store absent the provisions of the MADA. But I should say now that such an assumption is not completely unrealistic.
4648 Third, Professor Luca misapplied the behavioural economics literature relating to default effects to the settings at issue before me where there is no default in the relevant sense.
4649 Fourth, with respect to Google’s technical restrictions, Professor Luca’s conclusions were drawn from academic literature concerning the effect of different warnings in various settings, which bear no meaningful resemblance to the warnings that I am concerned with.
4650 Professor Gneezy said that it is standard practice in this field to start with a set of hypotheses informed by theory and previous empirical findings from relevant contexts, and then to design experiments that test those theories by replicating real-world decision environments.
4651 One reason why empirical testing is central to the discipline is that behaviour often depends on the specific context in which it occurs. Given that behaviour depends upon context, it is problematic to extrapolate conclusions across contexts. Professor Gneezy said that Professor Luca’s own published work confirmed these matters.
4652 Now Professor Luca offered conclusions as to the likely effects of Google’s pre-installation conduct and Google’s technical restrictions based solely on generalising from behavioural effects observed in other contexts, and without empirical evidence relevant to the context in question. But Professor Gneezy said that whilst it may be tempting to assume that a behavioural economist might be able to offer educated guesses as to how Google’s pre-installation conduct and Google’s technical restrictions may impact users’ conduct, that assumption is not supported by the behavioural economics literature.
4653 In his view, the academic literature indicates that behavioural scientists are not adept at predicting behavioural effects in real world contexts in the absence of empirical evidence. Further, he pointed out that although Professor Luca’s analysis depended on the proposition that the relevant conduct involves the use of choice architecture practices or nudges that can have large effects on consumer choice, there is now growing scepticism in the behavioural economics literature that such features change behaviour. In his view, more recent studies suggest that the effectiveness of nudges is limited at best. Moreover, he thought that academic researchers significantly over-estimate the impact of nudges.
4654 So, in the absence of context specific empirical analysis, it was Professor Gneezy’s view that Professor Luca’s views lacked a proper foundation. Let me address some other specific points concerning the pre-installation conduct that Google advanced.
Pre-installation conduct
4655 Google said that there are three further bases upon which I should reject Professor Luca’s evidence regarding the likely effect of Google’s pre-installation conduct on the behaviour of Android smart mobile device users.
4656 First, Professor Luca’s reasoning in respect of that conduct depended upon a speculative and unproven assumption, being that in the absence of the pre-installation requirements in the MADA, some OEMs would elect not to pre-install the Play Store on their devices’ DHS. But as I have said above, this assumption is not unrealistic.
4657 Professor Luca considered three distinct scenarios in relation to Google’s pre-installation conduct. In scenario (a), the Play Store is pre-installed on the DHS of an Android smart mobile device and no rival app store is pre-installed on the device. In scenario (b), the Play Store and a rival app store are both pre-installed on the DHS of the device. And in scenario (c), the Play Store is pre-installed on the DHS of the device and a rival app store is pre-installed on a subsequent screen.
4658 In each of those scenarios, Professor Luca made the same assumption that at least some of the time, the OEM would choose not to have the Play Store pre-installed, or so prominently displayed, resulting in more varied home screen options.
4659 Now this assumption, which Professor Luca was not instructed to make, was significant to Professor Luca’s conclusions. It was this assumption that allowed him to conclude in each scenario that Google’s pre-installation conduct made the Play Store more salient and easier to find relative to the counterfactual. That is because the logical consequence of the assumption is that the Play Store would be pre-installed on a smaller proportion of Android smart mobile devices in the counterfactual than in the factual.
4660 In this way, Google says that Professor Luca largely assumed his result. His reasoning reduced to the proposition that if the Play Store was pre-installed on a smaller proportion of Android smart mobile devices in the counterfactual than it is today, the number of users using the Play Store would be smaller to some unquantified extent.
4661 But Google says that the problem with that conclusion is that it depends upon an assumption that Epic has not sought to prove and which is not established by the evidence.
4662 It is said that any assessment of whether OEMs would at least some of the time choose not to have the Play Store pre-installed would require a consideration of the benefits and costs to OEMs of pre-installing the Play Store in the counterfactual.
4663 Now the benefits of pre-installing the Play Store to OEMs include that OEMs have a clear incentive to pre-install app stores that make their devices attractive to users, and the Play Store is attractive to users because it has the largest range of apps of any app store on Android.
4664 Conversely, even assuming that a rival app store would be willing to pay OEMs for pre-installation in the counterfactual, OEMs would need to weigh the value of that potential revenue against any competing offer by Google, as well as the revenue impact of lost device sales resulting from the absence of the Play Store on the OEM’s devices.
4665 Epic has not sought to prove how OEMs would weigh these matters, much less establish that any OEMs would ever elect not to pre-install the Play Store in the counterfactual.
4666 So, Google says that Professor Luca’s reasoning in relation to Google’s pre-installation conduct hinges upon a doubtful and unproven assumption that OEMs would make different pre-installation choices in the counterfactual. At best, that assumption rises no higher than a mere speculative possibility.
4667 Second, the focus of Professor Luca’s analysis in relation to Google’s pre-installation conduct was limited to conduct that occurs when a person first unboxes a new Android smart mobile device. But that is not the only occasion on which an Android smart mobile device user makes a choice as to which app store to use.
4668 The choice of which app store to use is not a one-time choice. To the contrary, Android smart mobile device users will potentially revisit their choice of app store hundreds or thousands of times over the life of their mobile device.
4669 Professor Luca accepted that, in principle, a user can revisit their choice each time they need to use an app store. And over time, in exercising that choice, the specific choice of app store the user makes will potentially be affected by how the app store has performed in the past, whether the user considers it to be a good app store, the prices charged by the app store and the quality of the app store.
4670 Further, the DHS is not immutable. Once the device is in the hands of the user, the user is free to rearrange apps or even remove them if they choose.
4671 In these circumstances, it is problematic to focus only on a user’s first decision as to which app store to use, rather than accounting for the reality that users can make different choices over time and are more likely to be influenced in those decisions by the characteristics of the app store than choice architecture.
4672 Third, Google said that Professor Luca’s use of the behavioural economics literature relating to default bias was questionable, and he sought to extrapolate from that literature to a context that is meaningfully different. It is said that the difficulty with that analysis is that Google’s pre-installation conduct does not involve a “default” in the sense that that term is used in the behavioural economics literature concerning default bias. That literature relates to the tendency of humans in some settings to adhere to pre-selected choices, being those that operate unless an individual opts-out.
4673 The significance of this for present purposes is that at least two of the three pre-installation scenarios considered by Professor Luca do not involve any “pre-selected choice” of app store. In each of scenarios (b) and (c), the Android smart mobile device comes pre-installed with the Play Store and another app store.
4674 In scenario (b), the Play Store and another app store are both pre-installed on the DHS. There is no “default” in the sense used in the academic literature because there is no “pre-selected choice” that will apply unless the user opts-out. In scenario (b) the user must make an active choice as to which app store to use. Scenario (b) of course is the scenario that exists in relation to all Samsung phones, and so is the scenario that applies in the case of most active Android smart mobile devices in Australia.
4675 Similarly, in scenario (c), the Play Store and another app store are each pre-installed on the Android smart mobile device, albeit that the rival app store is not on the DHS. This scenario requires the user to make an active choice between app stores. For that reason, it does not involve a “default” in the sense that that term is used in the behavioural economics literature.
4676 So, the sources cited in Professor Luca’s report to support the general claim about the effect of default options on individuals’ behaviour use definitions of default that differ from the definition presented in Professor Luca’s report and from the way that the Play Store is presented to Android users. Specifically, the sources cited in Professor Luca’s report use the concept of default to refer to a pre-selected option that decision-makers need to engage with if they want to make a different decision. The definitions in the literature refer to pre-selected options that decision-makers need to engage with if they want to make a different choice, but not to pre-defined layouts.
4677 Now Google says that the difference between the way Professor Luca used the term “default” and the way it is used in the academic literature is not semantic or inconsequential.
4678 The default bias that is described in the literature is specifically a bias that is sometimes observed and relates to not opting-out of a pre-selected choice.
4679 The effectiveness of opt-out or pre-selected choice scenarios stems from human cognitive tendencies to prefer the path of least resistance and to avoid the effort of actively choosing alternatives.
4680 Such scenarios are to be contrasted with circumstances of forced or required choice, where no choice is made without active decision-making by the user. In the latter scenario, the absence of a pre-selected choice means that none of the available alternative choices represents the path of least resistance for the individual.
4681 That difference has meaningful implications for how decision-making may vary between scenarios involving pre-selected choice and scenarios involving forced choice. So, it follows that there is a meaningful difference between a pre-selected choice scenario and what occurs in at least scenario (b) and scenario (c) where an active choice between app stores is required.
4682 Google said that one therefore cannot extrapolate from the default effects literature to reach reliable conclusions as to the likely effects of Google’s pre-installation conduct. And it is well-recognised in the field of behavioural economics that caution is required before seeking to generalise between contexts or settings, or from one lab study to the next. Moreover, that danger is only increased by assuming that the behavioural effects of opt-out choices are generalisable to contexts involving active choice between alternatives.
4683 Now in cross-examination, Professor Luca sought to resist the proposition that the behavioural economics literature relating to “default effects” was limited to pre-selected choices. He referred to K Haggag and G Paci, “Default Tips” (2014) 6(3) American Economic Journal 1. But according to Google, that paper offers no support for the proposition that a “default” in the behavioural economics literature has any wider meaning than a pre-selected choice. That study concerned the effect on consumer tipping of presenting three pre-selected tipping options to riders in New York taxis, together with an option for the user to enter a different amount. The authors of that study expressly recognised that the scenario did not involve a “default” in the sense used in the behavioural economics literature. They said:
The design of this choice context is not typical of the default effects literature. In order to complete a transaction, customers had to enter a tip amount. As such, our study is closely related to the literature on active choice, a type of design in which customers are not provided with a no-action option, and are thus required to actively choose among a set of similarly presented options (e.g., Carroll et al. (2009) in the context of retirement savings).
(emphasis in original)
4684 According to Google these observations indicate why one should exercise caution in reading the paper by Assistant Professor Haggag and Dr Paci as expanding the literature on default effects beyond opt-out decision making contexts. The authors themselves recognised that they were dealing with a different and unusual choice context, and one involving an active choice rather than a conventional default.
4685 Google says that it follows that I cannot properly conclude that the “default effects” literature which forms the core of Professor Luca’s analysis with respect to Google’s pre-installation conduct is of any utility in assessing the likely effects of the conduct in scenario (b) and scenario (c). And it says that this renders Professor Luca’s analysis inutile generally in assessing the likely effect of Google’s pre-installation conduct on user behaviour, particularly given that scenario (b) applies to most Android smart mobile devices in Australia.
Technical restrictions
4686 Let me say something more about the technical restrictions. Google made two other points about Professor Luca’s evidence regarding Google’s technical restrictions.
4687 First, some of Professor Luca’s views with respect to Google’s technical restrictions were in respect of screens and language that are not controlled by Google and which do not arise from the Android operating system or the GMS apps. I should say that I agree with Google’s criticisms in this respect.
4688 Second, Professor Luca said that Google has conducted research that is focused on developing warnings that are more effective at steering user behaviour. And he said that Google has pointed to its ability to steer behaviour through the way in which options and information are presented, including the concepts of attention and default bias. Professor Luca noted that for instance in A Felt et al (2015), Google researchers said that:
We wanted adherence to be a more visually attractive choice than non-adherence. The safe button is therefore a bright blue color that stands out against the background. Other Google properties use the same blue button style for primary actions, so people should associate the button style with a default choice. In contrast, the unsafe choice is a dark gray text link.
4689 But Google said that this article has nothing to do with Android or the unknown source warning or setting. It is an article written by Google employees and academics at the University of Pennsylvania in 2015 concerning the use of secure socket layer (SSL) warnings in Google Chrome. The authors describe how they set out to both improve user comprehension of SSL warnings and to encourage users to act in a conservative, safe manner. Given that the authors were seeking to encourage a particular behaviour, they adopted what they described as an “opinionated design” to promote safe choice. That choice involved deliberately making the preferred choice the more visually attractive of the two choices, including by indicating the safe choice using a bright blue colour that stood out against the background. The authors hypothesised that users would associate that blue button style with a default choice. By contrast, the choice that was not recommended remained in a dark grey text.
4690 But the unknown sources warnings and screens have none of the features referred to in the article as conveying an “opinionated choice”. They do not use the blue button style that was adopted in that study to convey a default choice. And nor do they exhibit any of the other features of the warnings in the SSL warnings study that could be said to steer users to a particular choice.
4691 The unknown sources warning presents the options “cancel” and “settings” in the same colour, size and font, without highlighting any other feature that would convey any recommendation to users.
4692 So, Google says that there is no basis upon which one can extrapolate from the SSL warnings study that Google uses the same or similar techniques in the design of the unknown sources warning or screen flow. I tend to agree with Google’s position and have put that 2015 research paper to one side.
4693 In summary, Google says that Professor Luca’s hypotheses as to the likely effect of Google’s technical restrictions are unreliable in the absence of any context specific empirical investigation.
Analysis
4694 I largely reject the substance of Google’s and Professor Gneezy’s criticisms of Professor Luca’s evidence, although some of their detailed points were not completely devoid of merit.
4695 Now as I have said already, Professor Gneezy said that the first and foremost principle of behavioural economics is that behavioural economics requires empirical evidence specific to the relevant context to generate reliable conclusions. By reason of this principle, Professor Gneezy was unable to accept any of Professor Luca’s conclusions in respect of either Google’s pre-installation conduct or the effect of the technical restrictions. This extended to being unable to reach reliable conclusions even in respect of the direction of the effect that a default might have on Android user behaviour.
4696 But I reject Professor Gneezy’s approach, largely given my analysis of Professor Luca’s evidence and some of the points Epic has made.
4697 First, Professor Gneezy’s narrow approach involves the rejection of the idea that findings by academics about human behaviour in the field of behavioural economics can extend beyond the very specific findings in a particular instance.
4698 But it would seem that most of the literature referred to by Professor Luca supports his analysis. Professor Gneezy’s rejection of the relevance of that literature was unorthodox.
4699 I agree with Epic that the unrealistic specificity required by Professor Gneezy’s approach can be seen by his rejection of the relevance of the paper of F Decarolis, M Li and F Paternollo (2023), which was cited by Professor Luca. That paper showed that defaults have an effect within the smartphone usage environment. Yet Professor Gneezy’s position was that the paper was not useful. He said that the paper related to a different environment. He said that the search engine that one uses is very different from the app store that one uses. But in my view, a default search engine choice for a smartphone user is a sufficiently useful guide to the effect of defaults for a smartphone user seeking an app store.
4700 Second, Professor Gneezy’s rejection of the idea of generally applicable principles within behavioural economics appears to be in tension with his own work. In U Gneezy and J List, The Why Axis: Hidden Motives and the Undiscovered Economics of Everyday Life (2013, Public Affairs), Professor Gneezy referred to recognised concepts from behavioural economics such as present bias, loss aversion and anchoring in general terms. There is no suggestion in his book that those principles are not broadly applicable or that they are only applicable to particular contexts which have been identified by specific academic papers.
4701 When faced with the concept of present bias in cross-examination, Professor Gneezy initially suggested that its applicability also required proof by reference to data. When shown a statement of the principle from his book, he seemed to accept that the principle applied to many cases.
4702 Third, Professor Gneezy’s rejection of the idea of default effects as generally applicable is also contrary to his own work. A 2019 paper, namely B Chandar et al, “The Drivers of Social Preferences: Evidence from a Nationwide Tipping Field Experiment” (2019, Working Paper, National Bureau of Economic Research), of which Professor Gneezy was a co-author, analysed the effect of changing the default amount shown to Uber riders. The experiment varied the default tip amounts that Uber riders were shown at the end of a ride and identified that average tips increased by 2.5% when moving from the low default tip options to the high default tip options.
4703 After noting that defaults have been shown to be quite influential in a variety of domains, the paper concluded that the default effect was lower than had been found in other academic papers, but that “[o]verall, our results support the notion that defaults impact tipping levels”.
4704 In his reply report, Professor Luca also referred to the content of a podcast in which the paper’s other author, Mr John List, referred to the study and said:
When you have higher presets, people tip less often but they end up tipping more in the end. So, if you want to increase tipping, what you want is a higher preset. Within reason.
4705 Now in the concurrent evidence session, Professor Gneezy said that the paper was about “how defaults don’t really work”. And in respect of Mr List’s statement, Professor Gneezy said “[t]he citation from John List is simply incorrect. It was done before we ran our analysis”. Professor Gneezy’s statements at the least were problematic.
4706 Fourth, and as Epic correctly pointed out, the significant value to Google of the pre-installation requirements is evidenced by the very existence of the relevant contracts. There is no reason for Google to mandate such requirements without the ultimate result being valuable.
4707 Now Professor Gneezy’s problematic view was that this does not matter because Google does not have any insight into how its users behave. But interestingly, Google, with the vast array of data about its users that it has at its disposal, did not brief Professor Gneezy with any evidence, statistics or assumptions about those matters.
4708 In my view the effect of Google's MIAs and RSAs with OEMs is to make the Play Store a default option for many Android users. That position means that the consequences of having a default choice is that Android users are more likely to choose the Play Store. It is analogous to the effect of defaults in search engines as identified in the literature.
4709 Fifth, Professor Gneezy insisted that to consider the effect of Google’s conduct on Android user behaviour it was necessary to have specific information about the costs and benefits of that conduct because that is the basis upon which Android users will make any decision.
4710 But I agree with Epic that that requirement does not account for the systematic impact of behavioural biases on Android users' behaviour.
4711 Professor Luca said that default settings can affect both perceived benefits, that is, consumers can naturally interpret a preset option as a recommendation, and also affect costs, in the sense that users must give time and attention to the choice of whether to deviate from the default setting in addition to the actual time required to acquire the alternative option. Indeed, default effects can in some settings be insensitive to perceived benefits and costs, suggesting that default effects can also reflect inattention.
4712 So, in this context, some Android users may not even consider the fact that there are alternative ways to download apps at the time of download.
4713 So, as Epic said, it was unnecessary for Professor Luca to carry out the very specific cost/benefit analysis which Professor Gneezy appears to require. Android users are unlikely to carry out a specific cost/benefit analysis about which app store to use or whether to directly download every time they download an app. And as Professor Luca observed, there are many instances where people go through small and repeated decisions on auto-pilot and do not weigh the costs and benefits of all the small choices they have.
4714 In summary, I accept Professor Luca's evidence as to the impact of the DHS placement of the Play Store and the frictions arising from the technical restrictions. It was based on general and well accepted principles described in behavioural economics literature to which Professor Luca made reference.
4715 Further, Professor Luca’s evidence also had the advantage of being consistent with the commercial evidence of the Epic and Google lay witnesses and the views expressed by Google’s executives in their internal considerations in various contemporaneous documents.
4716 But to so accept Professor Luca’s evidence says nothing about the competition consequences to be drawn concerning the two aspects of Epic’s case concerning Google’s anti-competitive conduct that I outlined at the commencement of this section of my reasons. Let me return to the technical restrictions.
The technical restrictions
4717 Now the AFAs and ACCs provide that OEMs may distribute devices being Android compatible devices, which is defined to be an Android device that complies with the Android compatibility definition document (CDD). This is all part of the Android compatibility program that I have touched on earlier.
4718 The MADA likewise incorporates the requirements of the CDD, first, by making the GMS distribution licence subject to compliance with a valid and effective ACC and, second, by confining the GMS distribution licence to Android compatible devices.
4719 Further, the device must pass applicable testing suites, including the Compatibility Testing Suite (CTS) and the GMS Testing Suite (GTS).
4720 Now the CDD contains numerous requirements for the configuration, behaviour, and security of Android devices. Let me refer to some requirements that are presently relevant.
4721 Section 4 requires that device implementations must have an activity that handles the “android.settings.MANAGE_UNKNOWN_APP_SOURCES”.
4722 So, the Android device must have a screen that handles the MANAGE_UNKNOWN_APP_SOURCES intent. This intent causes the device settings to be shown, which then allows for the enabling of installations from so-called unknown sources.
4723 Section 4 provides that device implementations:
MUST NOT install application packages from unknown sources, unless the app that requests the installation meets all the following requirements:
* It MUST declare the REQUEST_INSTALL_PACKAGES … permission or …
* It MUST have been granted permission by the user to install apps from unknown sources.
SHOULD provide a user affordance to grant/revoke the permission to install apps from unknown sources per application …
4724 Now to understand the relationship between the relevant requirements and the install flow experienced by users, it is necessary to address certain terminology.
4725 A “source” is Google technical parlance for an installer, being an app or component, responsible for installing other apps onto the device. So, the Play Store is an installer or source. So too is Chrome when it is used to install another app.
4726 Now installation permissions govern the ability of apps to install other apps. And relevantly there are two types of installation permission on Android, being the “INSTALL_PACKAGES” permission, which is also known as the privileged installation permission, and the “REQUEST_INSTALL_PACKAGES” permission.
4727 An app with the privileged installation permission can install other apps without obtaining user confirmation. The permission facilitates the installation of apps with a single click. So, when a user finds an app on the Play Store, the permission enables the user to install that app by clicking “install”.
4728 Now the OEM decides whether to grant a pre-installed app the INSTALL_PACKAGES permission. Where an OEM pre-installs the Play Store onto an Android compatible device, the OEM gives the Play Store the INSTALL_PACKAGES permission.
4729 Contrastingly, an “unknown source” is a source that has not been granted a privileged installation permission, and which instead requires the user to have granted it the “REQUEST_INSTALL_PACKAGES” permission to install other apps.
4730 Now in order for an app that does not have the privileged install permission to be permitted to install an APK, a user must grant that app the REQUEST_INSTALL_PACKAGES permission.
4731 I should also note that in the context of Google’s terminology, sideloading is the process of a user installing an app on an Android mobile device using a source that does not have a privileged installation permission. In other words, sideloading is the process of installing an app using an unknown source.
4732 Now web browsers and third-party app stores that are not pre-installed must use the REQUEST_INSTALL_PACKAGES permission to install other apps and are therefore “unknown sources”.
4733 Consequently, an app installation using either one of those sources results in a higher degree of installation friction experienced by users, in that, unless and until the user grants the source an installation permission, the user must go through a series of warning screens and prompts to change their device settings before they might ultimately allow the installation to occur. That series of warning screens and prompts is known as the unknown source install flow.
4734 Now before proceeding further, let me also say something about aspects of the GMS requirements that are relevant in the present context.
4735 The GMS distribution licence granted under a MADA is subject to the GMS requirements which set out the technical requirements that Android devices shipped with GMS must meet. Some of the GMS requirements form part of the technical restrictions relevant to this case.
4736 Section 6.1 provides that “Every GMS Device MUST preload GooglePackageInstaller in place of AOSP PackageInstaller”.
4737 A package installer is a system application that is responsible for handling the installation and uninstallation of apps on the device; the package installer confirms that an app that is attempting to install other apps has permission to do so, or has otherwise sought the consent of the user to install apps.
4738 The Google package installer app is responsible for initiating the unknown source install flow, including displaying the so-called unknown source warning that users experience when sideloading an app.
4739 The Google package installer app includes the unknown source warning. I should note at this point that OEMs cannot modify the code of the Google package installer app, but they can modify the default text of the unknown source warning as Mr Moore SC repeatedly reminded me.
4740 Now as should be apparent, the CDD requires that a user only installs apps from an unknown source if they grant the REQUEST_INSTALL_PACKAGES permission to the source. The GMS requirements require that for GMS devices running Android 8 and higher, that permission must be granted on a per-app, that is, a per-source basis.
4741 The permission is granted through the settings app, which contains a default unknown source setting screen and default text for that screen where the REQUEST_INSTALL_PACKAGES permission can be granted. On the default unknown source setting screen, a user can toggle a button to allow installation of apps from the unknown source to which the screen relates, which source is identified on that screen by name and icon.
4742 Now on GMS devices, OEMs are not required to show a warning on the unknown source setting screen. They can modify the settings app including this screen, and can even add additional steps to the sideloading flow. So, Samsung and Xiaomi, which are OEMs of GMS devices, have changed the unknown source setting screen and Xiaomi has even added an additional step to the sideloading flow.
4743 Now the Google package installer app contains the installation prompt and dialogs for install progress with default text. The default text on the installation prompt asks “[d]o you want to install this app?”, with an option to tap “Cancel” or “Install”. As with the unknown source warning, OEMs cannot modify the code underpinning this prompt or the dialogs but can modify the default text.
4744 Section 6.4 provides that on “GMS Devices running Android 7.x and earlier releases, the Unknown sources setting MUST be disabled by default. This is a security requirement to protect users.”
4745 This has the effect of denying installation permission to any source that is a non-privileged installer, unless and until the user alters the unknown sources setting, which for devices running Android 7 and earlier is a global setting.
4746 Further, section 6.4 provides that:
…
Android 8.0 and higher replace the global unknown sources setting with the Allow app installs setting on a per-app basis. Turning on this setting grants the REQUEST_INSTALL_PACKAGES permission that allows the granted app to provide other apps for installation. GMS devices MUST NOT implicitly grant this permission to any preloaded or downloaded third party app.
Note: This change is not applicable to the privileged apps having INSTALL_PACKAGES permission.
…
4747 Now as I have indicated, the INSTALL_PACKAGES permission is a privileged installation permission. The REQUEST_INSTALL_PACKAGES permission is not a privileged installation permission. It allows an app to request consent from the user to act as a source for the installation of apps.
4748 So, a user will encounter the unknown source install flow each time they seek to sideload an app from a given non-privileged installer, unless and until they grant that installer an installation permission.
4749 Now as I have indicated, the GMS requirements provide that a GMS device must comply with the CDD and pass applicable testing suites, including the CTS which tests for compliance with the CDD, and the GTS which tests for compliance with the GMS requirements.
4750 And relevantly, a device will not comply with the GMS requirements or pass the GTS if a pre-installed app has been granted a privileged installation permission without being approved by Google for inclusion on an “allow-list”, that is, for the grant of a privileged installation permission. So, ultimate control over whether an app store or other app can be pre-installed with a privileged install permission rests with Google, not the OEMs.
4751 For completeness I should note at this point that the remaining relevant GMS requirements do not form part of the technical restrictions. Briefly, these are as follows. Section 2.2 provides that new product launches must pre-install “all Core services and apps in the latest GMS bundle no later than 60 days after the latest bundle is released by Google.”. Section 3.1 provides that the default home screen (DHS) must feature the Google Search widget, the Play Store icon and a folder labelled “Google” containing the core applications. And section 3.3 provides that all GMS apps must be placed in the apps menu and that the Play Store should be placed in the top level of the apps menu and not in any folder. I have discussed these in detail elsewhere in my reasons.
4752 In summary, Epic’s case is that Google through its contractual arrangements, and by enforcing compliance with the CDD and the GMS requirements, has imposed on all OEMs who wish to distribute Android smart mobile devices with GMS a requirement that the OEM must configure their Android smart mobile device so that a user who attempts to download an app from an unknown source is confronted with all or at least some of the following requirements.
4753 First, the user is confronted with a browser warning in a specified form.
4754 Second, the user is confronted with a statement that for their own security their device is not allowed to install unknown apps on their Android smart mobile device.
4755 Third, the user is confronted with another warning that their Android smart mobile device is more vulnerable to attack by “unknown apps” and that “by installing apps from this source the user agrees they are responsible for any damage to their device or loss of data that may result from the app”.
4756 Fourth, the user is told or it is apparent that to proceed with the installation, the user must toggle a setting to indicate that they wish to make the change to the default setting.
4757 Now before proceeding further, let me set out some further evidence of Professor Somayaji.
Some expert evidence
4758 Now as I have said earlier, Google makes the code implementing most of the Android operating system available as open source through AOSP. Google allows OEMs to modify the code from AOSP and then licenses additional Android features and their own apps on top of the OEM’s modified version.
4759 Many Android OEMs make extensive changes to the AOSP code at all levels from drivers to libraries to core applications. To ensure that Android remains a consistent platform for developers to target, Google has explicitly defined much of what it means to be an Android device through the CDD and the CTS. Licensing requirements and private tests of GMS establish an additional level of consistency. Security is a key part of the Android platform, and so it is also part of compliance testing, featuring in several sections of the CDD. The requirements under the “Security Model Compatibility” category of the CDD help ensure that operating system security mechanisms are not tampered with by OEMs.
4760 Sections 9.1 and 9.3 of the CDD ensure that the Android model of authentication and access control is preserved in ACP-certified Android versions. Sections 9.2 and 9.7 ensure that the Android application sandboxing mechanisms are properly implemented in ACP-certified Android versions. Sections 9.10 and 9.11 require the use of cryptographic signature verification for ACP-certified Android versions.
4761 The CDD serves to establish some degree of functional commonality to devices that use the Android trademark, minimising the impact of vendor fragmentation. But newer versions of Android add new APIs and sometimes change old ones. Because of version fragmentation, developers can find it difficult to make use of newer AOSP APIs if they wish to make their apps available to the widest audience. Further, most Android devices stop getting operating system updates after a few years, leaving them vulnerable to unpatched security vulnerabilities. GMS-certified Android versions have a way around both of these problems through Google Play Services. GMS-certified devices get updates to significant parts of Android’s functionality through Google Play Services, including security-critical portions such as the embedded web browser. As I have endeavoured to explain earlier in my reasons, Google Play Services is part of GMS and consists of key modules and APIs that enable core functionality for many Android apps and services.
4762 Now whilst compatibility tests and GMS certification can improve device security, by improving the security of Android components through Google Play Services and gaining access to Google-proprietary security tools such as Google Play Protect, OEMs sign MADA agreements because they need GMS, particularly Google Play Services, in order for their apps to run the Android software users expect.
4763 But not all components of the MADA agreement improve devices from a technical security and functionality perspective. In particular, the contractual requirements of MADA that pertain to app pre-installation and visibility do not meaningfully contribute to platform security.
4764 Now I should say before proceeding further that Professor Somayaji evaluated the extent to which the distribution of third-party app stores through the Play Store could affect the quality, safety, and security of the Play Store. But I have not accepted Epic’s case on this aspect and it is unnecessary to set out Professor Somayaji’s detailed evidence on the subject, which of course I have considered.
4765 Let me turn to some of the expert evidence concerning the question of installation frictions.
Installation frictions
4766 Now I have no doubt that installation friction has a substantial impact on whether users choose to install an app. Google’s internal research shows that 62% of users who encountered Google Chrome’s installation friction followed through and changed their device settings to install the app. In other words, the friction resulted in a 38% drop in conversion for users attempting to install the app.
4767 Now Professor Somayaji described some of the key security implications of the friction Google applies on alternative distribution channels for apps on Android.
4768 Professor Somayaji expressed the view that the friction on third-party app stores and direct downloads hinders users from installing and updating those apps on Android devices.
4769 In his opinion, when users are subjected to warnings too frequently, they experience what is known as warning fatigue. Warning fatigue means that users become desensitised to the warnings that are presented to them and pay diminishing attention to similar warnings in the future. Platforms that issue warnings gratuitously put users more at risk by making them less likely to heed similar warnings for installations that are in fact dangerous. As a result, it also is Professor Somayaji’s opinion that friction on Android applied to safe app installations has the effect of decreasing the security of the platform.
4770 Further, in general, installation friction discourages users from installing apps. The more steps and warnings required to install, the less likely a user is to complete the installation. In Professor Somayaji’s opinion, friction is a net positive to security if and only if it is proportionate to security risk. If friction is proportionate to security risk, users will be less likely to install risky apps and will be informed, as much as security warnings are able to provide helpful information, about risks associated with the app which may help them to exercise prudence when they use the app after choosing to install it. Both of these behaviours have a positive impact on security in the context of risky apps.
4771 But if friction is not proportionate to security risk, it may have a net neutral to net negative impact on device security. To see how friction could have a negative effect on security, consider an example where a platform supports two app stores, one of which is more secure than the other. If the more secure app store experiences more installation friction than the less secure app store, the friction does more harm than good. In such an example, the friction is inversely proportionate to security risk. In other words, the effect of the friction that makes users less likely to install dangerous apps is applied in the wrong direction. Instead of enhancing security, the friction would drive users away from the safer app store and towards the less safe app store.
4772 In addition, if friction is routinely applied to safe, credible apps, users can become desensitised to it. If users are used to clicking through friction steps and warnings for apps they trust, they are less likely to be affected by friction when it is applied to apps they should not trust. Due to desensitisation, even if friction is applied to apps randomly with no correlation to security risk, it can have negative effects on platform security.
4773 Now Professor Somayaji considered Windows as an example of a platform that scales friction to the degree of risk associated with individual apps procured from the web. On Windows, friction for apps downloaded directly from the web varies depending on the extent to which the developer has been verified as trustworthy. For apps downloaded from the web, there are three possible cases being, first, the app has been signed by a developer with an extended validation (EV) certificate, which represents the highest level of vetting, second, the app has been signed by an organisation validation (OV) certificate, which represents a lower level of vetting or, third, the app has not been signed by any certificate. He explained the procurement friction in each case. The least amount of friction is present for developers with EV certificates, whereas the most amount of friction is present for developers with no certificate. This variation is summarised in Professor Somayaji’s table 19:
4774 This represents a helpful application of friction, since the friction is applied proportionately to the security risk associated with different levels of developer certification.
4775 Now it is necessary to provide some factual background on developer certificates and requirements for issuing them.
4776 EV and OV certificates are granted by certificate authorities, which are organisations that vet developers and grant certificates as a service. For the purposes of Windows, certificates are valid if they come from certificate authorities recognised by Microsoft as trusted. Though multiple certificate authorities exist, they all must apply a set of standard requirements in order to distribute EV and OV certificates. A summary of the requirements that certificate authorities must apply to developer organisations before granting them EV and OV certificates is provided in Professor Somayaji’s table 20:
4777 Broadly, the purpose of the certifications is to validate that the developer is legitimate and trustworthy. Windows uses certificate information to scale the degree of friction applied to app procurement. Professor Somayaji discussed each of the three cases described earlier in turn, being the procurement of an app that has been signed by a developer with an EV certificate, the procurement of an app that has been signed by an OV certificate and the procurement of an app that has not been signed by any certificate.
4778 Now in cases where the app comes from an EV-certified developer, friction is relatively minimal. Confirmation screens shown to the user present them with information on the app developer, as well as an indication that the developer’s identity has been verified. The procurement process is shown in Professor Somayaji’s figure 19:
4779 These screenshots depict the process.
4780 The friction on Windows for direct downloading apps from EV-certified developers is much less extensive than it is on Android. On Android, by contrast, all applications from the web are subjected to the same friction regardless of the developer’s certification. Another key difference is that the Windows approval screen communicates to the user the verified identity of the developer, equipping the user to make an informed decision on whether or not to trust the developer. As of Windows 10, apps directly downloaded from the web can be automatically updated after installation.
4781 Beyond the standard build, Windows 10 and 11 offer an “S mode” which establishes additional restrictions such that users can only download apps available in the Microsoft Store. OEMs can choose to install S mode Windows on some devices, meaning a manufacturer can produce laptops with Windows 11 S as well as with the regular Windows 11. But S mode is not intended for default users but rather to serve specific use cases, such as in the education sector where additional control and limitations on student machines may be desired.
4782 Now in cases where the app comes from a developer who is OV-certified but not EV-certified, an additional layer of friction is added. OV-certified apps trigger a “SmartScreen” warning when the app is installed. Windows gives OV-certified apps the opportunity to prove themselves as safe. If a given OV-certified app is downloaded a sufficient number of times by Windows users without security incident, Windows will stop showing the SmartScreen warning when new users install it. The SmartScreen warning is shown in Professor Somayaji’s figure 20:
4783 Similar to Android warnings, the language of the SmartScreen warning informs users of the risk of running an unknown app. The key difference with Windows is that Windows offers trustworthy apps and developers a way around the SmartScreen warning through EV-certification or a sufficient number of safe app downloads, whereas Android applies friction to all apps from the web indiscriminately. Additionally, the SmartScreen warning will communicate to the user the identity of the publisher if known.
4784 Further, in cases where the app comes from a developer without any certification, users see the SmartScreen warning as well as a different warning than the one shown in step 3 of figure 19. The warning in step 3 is replaced with a more severe warning, an example of which is shown in Professor Somayaji’s figure 21:
4785 The warning for unverified developers shown in figure 21 is similar to the warnings shown during the Android direct download process in that it alerts users of the dangers of running unknown apps on the device. The difference on Windows is that this warning is only shown when an app is truly unknown, not for all apps downloaded from the web as Android does.
4786 Further, direct download on Android is supported, but friction applied by Google is much more severe for directly downloaded apps than it is for apps from the Play Store. In addition to being severe, Google’s friction on direct download is uniform. All apps are subject to the same friction when procured via direct download, regardless of developer or any validation of the app itself. This friction is present for both third-party app stores installed through the web as well as regular apps installed through the web. Unlike other operating systems like Windows, Google’s warnings do not communicate to users the verified identity of the developer, arming the user with less information to decide whether or not to install a given app.
4787 Professor Somayaji considered the technical necessity of Google’s approach. He expressed the view that there is no technical reason why Google needs to apply severe friction uniformly.
4788 Cryptographic signing technology allows operating systems to verify the identity of an app’s developer, the authenticity of an app, as well as any other certifications attributed to the app. A signature can indicate that a developer has passed some sort of background check, for example, Microsoft’s use of OV and EV certificates, or it can indicate that an app has been audited, for example, Apple’s app notarization.
4789 I note that Google has access to the same standard certificates that Microsoft does, and Google already audits apps through its Play Store processes. In other words, Android has the technical means to retrieve verification information about the app that would be relevant to evaluating whether it is trustworthy, even if that app is distributed on the web, and Google already has the technical infrastructure needed to make this work.
4790 Next, Professor Somayaji considered the security impact of Google’s approach. It is his opinion that Google’s application of uniform, severe friction to apps procured through direct download cannot be justified from a technical security perspective.
4791 Let me begin by saying something about the security analysis of friction for third-party app stores.
4792 Friction is a positive for security if it drives users away from dangerous apps and towards safe apps. The same is true for app stores; friction is a positive for security if it is applied to risky app stores more heavily than safe app stores. But if more friction is applied to safe app stores than less safe app stores, the friction will have a negative impact on security due to warning fatigue. It is Professor Somayaji’s opinion that third-parties like Steam are just as capable, if not more capable, of fostering high-trust and secure app stores as Google. So, there is no compelling security reason why third-party app stores should uniformly experience more friction when downloaded from the web than the Play Store does as part of GMS.
4793 There is a notable contradiction in Google’s policy regarding installation friction on Android. Internal Google documents show an understanding on Google’s part that pre-installed apps are a more significant vector for malware than apps installed from the web. Despite that, Google eliminates friction for pre-installed apps and app stores, while imposing heavy friction on app stores installed through the web. This inconsistency in Google’s policy undermines the effectiveness of their friction-based security measures.
4794 Let me say something about the security analysis of friction for non-app-store applications.
4795 It is Professor Somayaji’s opinion that Google’s uniform application of severe friction to apps procured through direct download cannot be justified from a technical security perspective.
4796 It is also his opinion that friction is appropriate for apps that are likely to be risky, so he did not intend to suggest that Google would be better served by removing friction altogether. If it were the case that Google had no way of verifying the authenticity, developer, or security of apps downloaded through the web, the uniform application of severe friction might be appropriate.
4797 But Google has the technical mechanisms to verify the app’s developer, whether the app is an authentic version of the developer’s product, and whether the app has passed security scans run by Google. In fact, Google’s scanning has reviewed a substantial portion of off-Play-Store Android apps ([REDACTED] in 2019).
4798 Google’s on-device scanner, Google Play Protect, checks all apps when they are downloaded to an Android device regardless of their sources and conducts periodic scans of all apps on the device. Given the available technology to verify developers, the availability of Google’s automated scanners, and the extent to which Google has already profiled the vast majority of directly downloaded apps, in Professor Somayaji’s opinion Google’s implementation of friction is flawed from a security perspective, since the degree of friction does not scale with the degree of risk.
4799 This is in contrast to the Windows platform, which I described above. Windows reduces friction when developers have been accredited under OV or EV certification, or after apps have reached a certain number of downloads onto Windows machines without security incident. Notarized direct download on macOS represents a similar possible model under which apps are accredited not on the basis of their developer but on the basis of having passed a malware scan. As previously discussed, Apple notarizes macOS apps by automatically scanning them for malicious content and signs them if they pass the scan. Then, users can download notarized apps from any procurement source with minimal friction, and Apple is able to verify that the app has already passed Apple’s notarization scan.
4800 Ultimately, Google’s decision to uniformly apply severe friction to apps installed from the web while applying minimal friction to apps on the Play Store is not one that finds a basis in legitimate security concerns. As a review of curation models shows, the Play Store does not present users with a substantially safer set of apps than what third-party curators, such as Steam, can offer. As a review of friction models shows, Google does not use indicia of trust to scale friction in the way that Windows does, resulting in a cumbersome experience procuring trustworthy apps from the web without any security benefit for end users.
4801 Let me turn to another topic concerning developer-facing restrictions on obtaining pre-installation and offering direct download.
4802 Professor Somayaji considered developer-facing restrictions which may hinder developers from offering apps or third-party app stores through either pre-installation or direct download. In general, it is his opinion that some degree of curation of apps offered through pre-installation and direct download can have security benefits. For instance, it is legitimate from a security perspective for Android to curate out any apps which are known to have failed a malware scan or were submitted by developers known to be prolific publishers of malware. But Google’s approach to restricting developers in what they can make available for pre-installation and direct download goes beyond security necessity.
4803 Primarily, developer-facing hinderances to obtaining pre-installation and offering direct-download arise from restrictions on access to key app permissions. In particular, and as I have discussed earlier, Google regulates use of the “INSTALL_PACKAGES” and “REQUEST_INSTALL_PACKAGES” permissions. These permissions provide apps the ability to install other apps or automatically update. Their use is restricted for Android app developers publishing apps for pre-installation or direct download.
Pre-installation
4804 Apps with the “INSTALL_PACKAGES” permission are allowed to install downloaded files without the user’s confirmation. Typically, apps like app stores, or package installers, being software that is responsible for the steps involved in the installation of an app, use this permission to install apps from the web or update previously installed apps automatically. For an app store, the ability to install other apps on the device is a pre-requisite, and the INSTALL_PACKAGES permission is a necessary one to facilitate frictionless installation. A key advantage that pre-installed apps with this specific permission have over apps directly downloaded is that such apps do not require users to adjust device settings to allow installations. Instead, they can install apps from a pre-installed app store without having to go through warning screens and prompts to change the device settings.
4805 Google [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
4806 Even with [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] But the pre-installation of apps is contractually restricted through the use of revenue share agreements.
Direct download
4807 Professor Somayaji described the requirements for offering app stores and other apps for direct download. Let me repeat some of what I have already said.
4808 Unlike with pre-installed apps, Google does not allow apps distributed through direct download to use the INSTALL_PACKAGES permission. Instead, directly downloaded apps that require the ability to install other apps need to use the REQUEST_INSTALL_PACKAGES permission.
4809 This permission works much like INSTALL_PACKAGES, but imposes additional friction before the user can install packages through the app. In particular, REQUEST_INSTALL_PACKAGES requires the user to change their device settings in order to allow the installations.
4810 The requirement that directly downloaded apps use REQUEST_INSTALL_PACKAGES rather than INSTALL_PACKAGES results in a much higher degree of installation friction experienced by users. Since Android 12, Google has allowed an easier route for third-party app stores to provide updates to the apps installed through them. To allow for auto-updating of apps installed through a third-party app store, a user is required to change their device setting once. In earlier versions of Android, a user had to change their device setting before allowing each update.
4811 Now the restriction forbidding directly downloaded apps from using INSTALL_PACKAGES means that any directly downloaded app attempting to install another app will face installation friction. This applies to apps such as third-party app stores, web browsers, and package installers that may be offered via direct download. Because this policy applies indiscriminately to all apps offered via direct download, the result is a degree of installation friction which is both severe and uniform across directly downloaded apps.
4812 In Professor Somayaji’s opinion, the friction implemented by Google for installing directly downloaded apps is not proportionate to security risk and is therefore flawed from a security perspective.
4813 In the case of pre-installation, Google’s restrictions on third-party app stores and other apps constitute a form of curation in that Google only allows specifically authorised pre-installed apps to use the INSTALL_PACKAGES restriction. Broadly, curating pre-installed apps that use high-risk permissions can benefit the security of end users. But the challenge with Google’s specific restrictions on pre-installed apps is the degree to which the requirements are arbitrary and unrelated to app safety.
4814 The goal of curation from a security perspective should be to ensure that apps originate from trustworthy entities through developer vetting and that individual apps are free of clear security risks and malware through app audits. To that end, Google’s requirement that pre-installed apps accessing INSTALL_PACKAGES not be “known PHAs,” or potentially harmful applications, is helpful. But Google’s requirements that apps fit into one of eight categories as described in table 21, and that they must function as required, is unnecessary and is overly restrictive.
4815 Further, many of the specific requirements within each category of apps eligible for allow-listing, defined in the right-hand column of table 21, are not strongly related to security. For instance, Google requires that some apps’ “name, icon, or UI (if any) have to portray that its purpose is to download/install apps,” a rule that has more to do with interface design practices than technical security. Further, Google’s requirement that browsers and file managers cannot have one-click installation does not add to security when applied to safe and trusted applications. Overall, it is Professor Somayaji’s opinion that the specific requirements and categories of Google’s allow-listing process are not justified by legitimate technical security interests.
Real-world impact of installation frictions
4816 Let me begin with some introductory remarks.
4817 Epic’s case is that by reason of the technical restrictions, a user cannot download and install an app from a new non-privileged source without manually granting permission to install apps from that source, without being confronted with explicit warnings that their device and data are more vulnerable to attack from “unknown apps”, without having to agree to bear responsibility for any damage to their phone or loss of data that may result from their use of “unknown apps”, and without having to navigate additional steps.
4818 Contrastingly, Android apps and app stores which are pre-installed with a privileged install permission including the Play Store can install other apps via a “one click” process.
4819 Now installation friction comprises both the warnings presented to users as well as the total number of steps required for installation.
4820 The unknown source install flow, including the number, form, and sequence of the frictions it entails not only makes the sideloading process more difficult and time consuming than downloading and installing apps through the Play Store, but is apt to cause users to think sideloading is positively harmful, and deter them from undertaking or completing the process.
4821 Installation friction has a substantial impact on whether users choose to install an app and installation friction discourages users from installing apps. Each additional step or warning makes it less likely that the user will complete the installation.
4822 Indeed, Mr Cunningham conceded that Google’s default installation flow presented what were commonly described within Google as pain points for users seeking to install apps from third-party app stores.
4823 Further, in the September 2018 presentation titled AP-PS: Unknown Sources, which was authored or contributed to by Mr Cunningham, it was noted that installing Fortnite on a device using a non-privileged installer involved “[m]uch more friction” than if the user were using a pre-installed installer.
4824 In the same presentation, it was observed that “adding any kind of friction will reduce installs (proposition is that there is about a 20% drop off for every acquisition in play, so for non play [we] expect similar)”.
4825 The proposition of a “20% drop off for every acquisition in play” can be taken to mean that the introduction of any kind of friction into the Play Store installation flow results in about 20% of users abandoning the installation.
4826 As to the statement “so for non play [we] expect similar”, I agree with Epic that it would seem that Google believes that the same proposition applies in the case of any kind of friction introduced into the installation flow for non-privileged installers.
4827 Now as Epic says, the significant effect of installation frictions also accords with Google’s reasoning when it first introduced in April 2008 an unknown source warning as follows: “For security, your device is set to block installation of applications not sourced in the Android Market”.
4828 On 24 April 2008, in an email exchange in which Mr Lockheimer participated, it was said that Google introduced an unknown source warning in order to “convince the many to go to the [Android Market, now the Play Store]” for their apps, “where much of our security exists for their protection”.
4829 It was also stressed how effective Google expected the warning to be by saying “[i]f this warning doesn’t prevent over 90% of users from side-loading (which is the number we used to convince T-Mobile) then we have failed and sold T-Mobile on the wrong information.”
4830 So, I agree with Epic that an objective of the unknown source warning was to prevent sideloading. Further, another objective was to encourage users to obtain their apps from the then Android Market, which is now the Play Store, instead.
4831 Further, the unknown sources install flow would seem to be a significant impediment to developers successfully distributing their Android apps via this method.
4832 As Epic notes, a 2016 Google document titled Special Topic: Off-Play Installs records that installs from outside the Play Store represented 12% of all installs and derived from three main sources being sideloading, pre-installed third-party app stores and device hacks. The same document breaks down the figures for ten different countries and shows that sideloading accounted for less than 12% of installs in six of them, less than 20% in the next three, and 69% in Iran. Users in Iran cannot download paid apps or make in-app purchases via the Play Store. In other words, in all but four countries for which a breakdown is given, sideloading accounted for less than 12% of off-Play installs in 2016.
4833 Further, in 2020, sideloading accounted for at most 3% of new app installs in Australia and 12% globally. Further, in 2020, only 12.46% of GMS devices in Australia sideloaded an app, as compared to 37% of GMS devices globally. Apparently a device needed to sideload only a single app to be counted in those statistics.
4834 Now before proceeding further, and as Epic correctly points out, the context in which Google imposes the technical restrictions must first be considered.
4835 Now an Android package file, that is, an APK file can be downloaded to the user’s device by various means, including from the internet by using a web browser and by using an app that functions as an app store.
4836 The Google package installer initiates the unknown source install flow when a non-privileged installer attempts to install an APK file, and that non-privileged installer does not declare, that is, the user has not granted, the REQUEST_INSTALL_PACKAGES permission.
4837 The Google package installer does so irrespective of the non-privileged installer in question, and irrespective of the developer or contents of the particular APK file that the user is seeking to sideload.
4838 The main difference in the install flow experienced when sideloading an app by using a web browser, as compared to using a sideloaded app store, is that the former will typically include a browser confirmation and, in the case of Chrome, will include a browser warning.
4839 Now web browsers do not generally receive a privileged installation permission. In respect of GMS devices, Google does not generally approve browsers for inclusion on its “allowlist” for the grant of a privileged installation permission.
Browser warnings
4840 Let me say something about browser warnings as part of the context.
4841 Web browsers typically alert users when they are downloading a file. Google Chrome does so by displaying to the user a browser warning, which warns that the file “might be harmful”, and asks the user to confirm whether they “want to download [the file] anyway?”.
4842 Professor Somayaji considered the browser warning to form part of the install flow that a user must navigate when sideloading an app using a web browser such as Chrome. In his view, a user experiences app installation as a single process in which every prompt and message jointly influence a user’s perception of the risk associated with installing an app. He said that as it is the user who experiences friction, it is appropriate to consider the impact of friction from the user’s perspective.
4843 Mr Cunningham considered the browser warning to be a typical step in the install flow of a sideloaded app store, in the event that the user is using a web browser to do so, and where that web browser implements a browser warning.
4844 Indeed, Google characterises the display of a browser warning as the first of four steps that users click through when sideloading an app from a web browser, and which is said to apply to every download through a given browser.
4845 Now of course it is the web browser, rather than the device’s OS, which renders the browser warning. And Google only controls the browser warning on Google Chrome because that is Google’s own web browser.
4846 Now Google sought to minimise the relevance of Chrome’s browser warning to the typical sideloading install flow by pointing out that not only does Google not control the browser warning on browsers other than Chrome, but that the developers of other browsers can and do deploy different, and less scary, language in their browser warnings. But Epic pointed out that this attempt at minimization was problematic and made the following three points.
4847 First, Google’s own 2021 data indicates that the top source for sideloaded app stores on Android mobile devices was direct downloading using a web browser, with 69% of those app stores having been downloaded in that way. The next highest source was file managers, which accounted for only 15% of downloads. I will infer that a similar pattern still applies now.
4848 Second, Chrome is the most widely used web browser in the world and has a market share of approximately 63%, with Safari in second place at approximately 13%. Further, Chrome is a core application under the MADA. And save for certain geographic areas including China, Chrome is invariably pre-installed on Android devices. Moreover, Google requires that certain OEMs set Chrome as the default web browser under the terms of their RSA.
4849 Third, the Chrome browser warning and the text contained in it are each included by Google in Chromium open source code. Further, other web browsers such as Microsoft Edge and Samsung Internet are based on Chromium.
4850 I agree with Epic that the installation friction contributed by Chrome’s browser warning forms part of the context in which the additional installation friction imposed by the unknown source install flow falls to be evaluated.
Customising the unknown source install flow
4851 Now the next matter by way of context is the extent to which OEMs can and do customise the unknown source install flow. The following would not appear to be contentious.
4852 OEMs cannot modify the steps involved in the sideloading flow mandated by the Google package installer, namely, the unknown source warning, the installation confirmation and the dialogues for install progress, success and failure.
4853 In theory, OEMs can modify the text of the unknown source warning. But Mr Cunningham was not aware of any of the large OEMs having done so, and there is no evidence before me of any OEMs having done so.
4854 Now there is a second way in which OEMs can customise the unknown source install flow, namely, by modifying the settings app.
4855 On Android devices, the unknown source warning is generated by the Google package installer. Tapping on “settings”, within that dialogue box, takes the user to the unknown source settings screen. That screen is generated by the settings app, not by the Google package installer.
4856 Now the unknown source settings screen can be modified by OEMs. But Google provides OEMs with the default code for the settings app and the default text for the unknown source settings screen, which comprises the warnings displayed on that screen.
4857 Mr Cunningham gave evidence of two OEMs, Samsung and Xiaomi, that have modified the unknown source setting screen and its text, and said that he was aware of only two OEMs who have made changes to Google’s default sideloading notification flow.
4858 Mr Cunningham also agreed in general terms with the proposition that OEMs generally maintain the default sideloading notification flow provided by Google, save that they make cosmetic changes to their settings app.
4859 Similarly, Mr Porst accepted that Google’s default implementation of this setting is a suggestion for the OEMs to follow, and to the best of his knowledge the OEMs follow it.
4860 In those circumstances, I infer that most of the time OEMs do not modify the default text of the unknown source warning, and otherwise most of the time follow the default implementation provided by Google.
Developers have some control over friction
4861 Let me deal with another matter of context. As I have said above, developers of sources for Android apps have some latitude as to the extent of installation friction that users will be exposed to when sideloading an app from their source.
4862 The developer of a source can decide how to initiate the sideloading notification flow from their source, for example, by coding the source such that it prompts the user to grant the REQUEST_INSTALL_PACKAGES permission.
4863 In that way, the developer can choose to direct the user to the unknown source setting screen in advance of any unknown source warning appearing.
4864 Now Google seeks to minimise the real-world effects of its imposition of the technical restrictions. But I am sceptical of any such attempt and agree with Epic as to the following matters.
4865 First, web browsers are a widely used method for obtaining apps on Android and they are by a significant margin the most important source for sideloaded app stores. Chrome is the most widely used browser by a very significant margin.
4866 Google does not develop Chrome so as to direct users to the unknown source setting screen in advance of any unknown source warning appearing, and there is no evidence of any other web browser that does so.
4867 Second, even in the case of sources that are developed in such a way that users are pre-emptively shown a dialogue box with an option to tap through to the unknown source setting screen, the only way in which installation friction might thereby be reduced is by the developer of the install source choosing different, and less scary, language in that dialogue, as compared to the default text supplied by Google in the unknown source warning.
4868 Otherwise, any additional dialogue boxes, screens or information displayed to a user would simply give rise to additional installation friction.
4869 Third, there is no evidence of any propensity of developers to develop their install sources in the way suggested by Mr Cunningham. Such evidence as there is rises no higher than the evidence that Professor Somayaji gave under cross-examination, as summarised above, and to which I ascribe little weight.
4870 Let me now turn to Google’s position and deal with the substance of the case.
Configuration and sideloading
4871 Google has given the following description concerning questions of configuration and sideloading with which I agree.
4872 An OEM is not required to configure GMS devices with a browser warning, with words to the effect that the APK can harm their device, and which asks whether the user wishes to keep the APK anyway. The browser is separate from the device built by the OEM and Android OS, which is placed by the OEM onto their device.
4873 Further, an OEM is not required to configure GMS devices so that, after a user indicates that they wish to keep an app, the user is confronted with a statement that for their own security their device is not allowed to install unknown apps on their device, with an option to cancel the installation or to alter their device settings.
4874 OEMs are required to configure GMS devices with an unknown source warning. But OEMs can modify the default text and developers can modify the process for installing an app.
4875 Further, OEMs need to configure GMS devices so that a user can only install apps from an unknown source if they grant a permission to that app to do so, being the REQUEST_INSTALL_PACKAGES permission, and that permission is granted in the settings app.
4876 But OEMs do not need to configure GMS devices so that when the user navigates to the settings app, another warning appears stating that their device is more vulnerable to attack by “unknown apps” and that by installing apps from this source the user agrees that they are responsible for any damage to their device or loss of data that may result from the app.
4877 Also, OEMs do not need to configure GMS devices so that a user needs to toggle the setting to indicate that they wish to make the change to the default setting. The settings app, including the code for that app and text shown to users, can be modified by OEMs.
4878 Further, OEMs need to configure GMS devices with an installation confirmation prompt that appears for each app to be installed from an unknown source, and installation proceeds after a user confirms that they wish to install the app. The default text of that prompt asks the user whether they want to install the app, but the OEM can modify the text.
4879 So, there are only three configuration requirements for GMS devices.
4880 First, an unknown source warning must appear when a user attempts to install an app from an unknown source.
4881 Second, the user must grant a permission to that source to install other apps.
4882 Third, after that permission is granted, an installation prompt and dialogs for installation progress must appear for each app that a user attempts to install from an unknown source.
4883 But the first requirement can be bypassed by the developer if the developer’s app takes the user straight to the settings screen to grant a permission to the source to install other apps.
4884 Further, on Android, permissions determine what an app can and cannot do. They capture the user’s consent to an app’s functionality. Whether an app can install another app is determined by two types of permissions as I have already mentioned. One has the INSTALL_PACKAGES permission, also known as the privileged install permission, which allows apps to install other apps. Further, one has the REQUEST_INSTALL_PACKAGES permission, also known as the install unknown apps permission, which allows an app to act as an install source for sideloading.
Browser warning
4885 Google does not require OEMs to configure GMS devices with a browser warning. Google made the following points with which I agree.
4886 Warnings may be shown when a user seeks to download an app from a web browser but such warnings are not the product of the MADAs, the CDD or the GMS requirements, or any other act taken by Google in determining compliance with the CDD and GMS requirements. Browsers and any warnings they generate are provided by the developers of each browser.
4887 Google controls the browser warning that appears when a user downloads an APK from Google Chrome but Epic makes no claim about Chrome, which is separate from Android OS and the Play Store. The Chrome team works independently of the Play Store team.
4888 Google says that Epic’s assertion that browser warnings form part of the install flow is irrelevant and goes nowhere. Browser warnings are not a form of installation friction because at the point of downloading an APK, no installation has occurred. Downloading is the process of putting a file onto a device. Installation is the process by which an APK is made known to the operating system, which performs steps to prepare the app for use.
4889 Moreover, Epic ignores the fact that browser warnings are commonplace and justified. The primary standards body for the World Wide Web, W3C, considers such warnings to be best practice.
4890 Further, browser warnings pop up only when a device is trying to download an executable file, rather than any regular document or file. An executable file could run arbitrary code that has not yet been analysed. The warnings alert the user that they are about to download an APK, which by its nature is risky as it allows the execution of arbitrary code, and provides the user with the opportunity to confirm their choice to download the app. They give the user the opportunity to prevent unwanted downloads of APKs and ensure that browsers do not silently download potentially malicious executable files on users’ devices.
4891 Relatedly, browser warnings mitigate the risk of “drive-by-downloads” which attempt to automatically download apps when the user simply navigates to a website without the user choosing to download an app.
4892 The browser warning is displayed regardless of whether or not the APK is, in fact, malicious. This is because at the point of download it may not be known whether the APK is malicious. The browser warning is comprehensible. Users may not know that APK files in general may be harmful and the browser warning alerts users. At that point, it is not known whether the file is malicious or potentially harmful. And it is not possible for a browser to know that a file is safe before it is installed.
4893 Further, in addition to appearing on Chrome as a one-step prompt, browser warnings appear on Samsung Internet and Microsoft Edge as a two-step prompt. The language used for the second prompt on Microsoft Edge is identical to the language used for the prompt on Chrome. Samsung and Microsoft are both large companies, separate from Google, and Samsung Internet is the default web browser on the Samsung Galaxy Store.
4894 Now Epic seeks to incorporate the browser warning, where present, for downloading an executable file. But I agree with Google that this has nothing to do with its requirements for a new source. It is a standard requirement of many browsers and is in accordance with the recommendations of relevant standards.
4895 Now Epic says that browser warnings form part of the context for evaluating the sideloading flow. But as Google points out, browser warnings perform a different role to unknown source warnings and installation prompts. They alert the user that they are about to download an APK, which by its nature is risky as it allows the execution of arbitrary code, and provides the user with the opportunity to confirm their choice to download an app.
4896 At the point of download, neither the browser nor the operating system know whether or not a file is safe.
Default text of warning and the setting screen
4897 Let me turn to another topic being that the default text of the unknown source warning and the unknown source setting screen can be modified.
4898 Now the precise text that the user sees in an unknown source warning and at the unknown source setting screen can vary between OEMs. But in any event Epic says that the default text is confusing and unclear.
4899 Now the default language for the unknown source warning and the unknown source setting is based on the Android open source software. And I agree with Epic that there is certainly room for improvement in the default language.
4900 But Google does not insist on that default language, and does not require OEMs to configure GMS devices with that default language. No change in the MADAs, the CDD or the GMS requirements will make a change in the default language more or less likely because OEMs can already make that change.
4901 There is nothing stopping OEMs from choosing different language for the unknown source warning or the unknown source setting screen.
4902 Two have altered the default language for the unknown source setting screen, including Samsung which accounts for the largest share of Australian Android devices.
4903 Samsung’s modifications change depending on the method by which the user arrives at the unknown source setting screen.
4904 Where a user arrives at the screen via an unknown source warning, Samsung has shortened the text on the unknown source setting screen to “[i]nstalling apps from this source may put your phone and data at risk”. This is shown in the screenshot below:
4905 Where a user arrives at the screen manually or directly from an app, but without an unknown source warning, Samsung has lengthened the text on the unknown source setting screen as shown in the following screenshot:
4906 Xiaomi has added an extra warning after the user toggles to allow apps to be installed from an unknown source in the unknown setting screen. Xiaomi’s additional warning shows that others are concerned to ensure that users understand the risk of installing apps from unknown sources.
4907 Further, the default text of the unknown source warning includes the name and icon of the app that is the install source, for example, Chrome, and then contains the default warning.
4908 The default text notifies a user that, for security reasons, the phone is not permitted to install apps from the source identified, Chrome, but that this can be permitted in the settings app. The warning informs users of a choice, being whether to give Chrome permission to install apps.
4909 The default text of the unknown source setting screen again includes the name and icon of the app that is the install source, for example, Chrome, and then contains the default warning.
4910 The unknown source setting screen interrupts the installation flow for a specific app, and asks the user to make the choice about which they were alerted by the unknown source warning, that is, to allow a particular source to install apps. The default text also warns the user that by using an unknown source they may be putting their device and data at risk.
Sideloading
4911 Let me turn to sideloading generally.
4912 As Google points out, attempts to sideload an app will not necessarily confront an unknown source warning. And Google does not require the presentation of an unknown source warning where sideloading occurs.
4913 Google provided the following description in terms that I largely agree with.
4914 Users of a GMS device may download and install an app from an unknown source without ever encountering an unknown source warning. There are two ways that the user may navigate or be led to the REQUEST_INSTALL_PACKAGES permission that do not involve this warning.
4915 First, on a GMS device, a user may manually grant the permission, in which case an unknown source warning will not appear if the user subsequently attempts to install an app from that source.
4916 Second, the developer of an unknown source can modify the sideloading notification flow such that the unknown source warning is not shown when a user seeks to download and install an app from that source on a GMS device or any device, and the developer sends the user to the unknown source setting screen for the app.
4917 The developer would do this by using the MANAGE_UNKNOWN_APP_SOURCES intent. On Android, “intents” are used by apps to request functionality from other Android apps on a device.
4918 The developer of an install source can send a user directly to the unknown source setting screen by a single tap, without the user seeing an unknown source warning. But this would mean that the user does not receive the benefit of a warning explaining what they need to do to allow the app to install other apps.
4919 A developer could also provide instructions or guidance to users concerning enabling the REQUEST_INSTALL_PACKAGES permission, before directing them to the unknown source setting screen in advance of any unknown source warning appearing.
4920 Let me say something more about the actual requirements and available modifications.
4921 As I have already explained above, to install an app from a new source, in practical terms, users only need to take two steps that are required by Google. This is for the following reasons, as Google has explained.
4922 The only requirement that Google imposes on OEMs is that they configure GMS devices so that an unknown source warning appears when a user attempts to install an app from an unknown source. Further, the device must be configured so that the user needs to grant a permission to that source to install other apps. Further, after that permission is granted, an installation prompt and dialogs for installation progress must appear for each app that a user attempts to install from an unknown source.
4923 As I have said above, an OEM is free to modify the text of the unknown source warning, any unknown source setting screen and the installation prompts and dialogs. An OEM can also modify the steps that a user takes to permit an app to install other apps, that is, to grant the REQUEST_INSTALL_ PACKAGES permission.
4924 The permission is granted through the unknown source setting screen in the settings app, but the OEM can modify the way the screen is presented and the manner in which the permission is granted at that screen.
4925 So, OEMs have a choice and the OEM with the largest share of Australian Android devices, Samsung, has exercised that choice, and has done so because of its own concerns about the security risk of sideloading.
4926 In addition, developers can modify the process for installing an app so as to bypass any unknown source warning, such that either a user never sees an unknown source warning, or else sees a different type of message, and is sent directly to the place on their device where they can grant the unknown source permission to install other apps.
4927 There is nothing stopping a developer, including the developer of a web browser, from modifying the process.
4928 Now as indicated in the first step above, before an unknown source can install other apps, the user must grant that source permission to do this. The unknown source setting enables the user to give that permission.
4929 As Google rightly points out, the permission is important because using an unknown source involves straying outside the protections offered by the Play Store and OEMs, and a user may wish to limit apps that can install other apps on their devices.
4930 The purpose of the unknown source step is to alert and warn users when they stray beyond the originally specified protections. This is analogous to erecting a warning sign at the boundary of a patrolled area.
4931 Now as indicated in the second step above, after an unknown source has been given permission to install apps, a user receives an installation prompt.
4932 An installation prompt is directed to a different purpose from the granting of the unknown source permission. It provides an opportunity for the user to indicate that they consent to the installation of a specific app and for that consent to be communicated to the OS.
4933 Without the installation prompt, an app may install itself without the user’s consent, and the operating system cannot determine whether the user has consented to that installation.
4934 Further, sideloaded apps are also scanned by GPP. They are subject to a scan [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] I have referred to this elsewhere as the legacy scan.
4935 Further, they are subject to the recently launched real-time scan depending on the country.
4936 Further, they are subject to a daily GPP scan of all apps installed on a user’s device.
4937 Now Epic has asserted that the installation prompt does not provide information to the user that could help them assess the potential risk of an app.
4938 Now the prompt is the means by which a user indicates their intent to the operating system to install a specific app. Without the user’s confirmation, the operating system does not know whether the app is being installed by accident or intentionally.
4939 I agree with Google that it is important that users have the option to confirm whether they wish to install a particular, identified app, including because malware on a website or other source can trick users so as to disguise that an app is being installed. Offering a clear choice to the user, which the installation prompt does, helps to protect the user.
4940 And I agree with Google that it is reasonable for the installation prompt to appear for every attempted app installation from an unknown source for the reasons that Google has enumerated.
4941 First, the installation prompt helps prevent “drive-by-downloads”, where malware is automatically and silently installed without the user’s awareness.
4942 Second, the installation prompt also helps prevent installations due to accidental clicks such as “fat fingering”, which occur due to the limitations imposed by mobile devices’ form factors.
4943 Third, the installation prompt helps to block users from tapping a benign looking but malicious link, which attempts to download and install an unwanted app.
4944 I would reject Epic’s complaints concerning the installation prompt.
4945 Further, Epic says that, as the unknown source warning is decoupled from the security scanning process and the app that a user is seeking to install, and is applied to all unknown sources indiscriminately, it is apt to result in disproportionate installation friction.
4946 But the role of unknown source warnings is not to evaluate the likelihood of an app being malicious. Rather, as Google points out, they are focused on the source of the app.
4947 The unknown source warning and the unknown source setting screen identify to users that despite being on a GMS device, they are stepping outside the area of relative safety offered by Google or by an OEM.
4948 In this sense, it is appropriate that the warnings and steps be source-based because they intend to inform the user that they are about to approve installation of an app from a source that is unknown to the OEM and hitherto unauthorised by the user, and to enable the user to make an informed decision about whether they wish to proceed regardless.
4949 This is not to say that everything outside the area of relative safety offered by Google or an OEM is dangerous. That is not what the unknown source warning and unknown source setting are intended to convey.
4950 As Google says, the unknown source warning and the unknown source setting screen assist the user in making that decision because they are directed to thinking about the places from where a user downloads and installs apps. They also recognise that in using an unknown source the burden of security decisions shifts to the user. They recognise that they are not protected in the way that they are on the Play Store.
4951 Ultimately there is a risk that comes from sideloading. And the user is being notified of the risk.
4952 The unknown source warning and the unknown source setting screen give the user the identity of the application that is actually trying to do the installation. They let the user know that this is not the source that they usually, by default, go to. So, if they wish to proceed, they will need to trust the application that is trying to do the installation.
4953 Further, a user would wish to be informed that they are about to install an app from a source outside of the Play Store.
4954 Finally, to the extent that Epic suggests that Google adopts an approach to security that makes the source of an app determinative, I reject that suggestion.
4955 As Google says in having warnings and steps related to decisions about from where to download and install apps, it is not the case that Google ignores the risks associated with the behaviour of specific apps. Rather, consistent with the principle of defence-in-depth, Google adopts multi-layered defences against malicious software and unauthorised use. No single layer of defence provides complete security for a system but the layers work together to achieve as high a degree of security as possible.
4956 In addition to the so-called technical restrictions and as I have discussed elsewhere, three additional layers of security have been the subject of evidence being OS-level protections, comprehensive scanning and review of apps available on the Play Store and some off-Play Store apps, and scanning of apps through GPP.
4957 So far, what I have said has largely been descriptive. Let me at this point before I proceed with more detailed analysis set out Google’s arguments on proportionality.
Google’s arguments – proportionality
4958 Now Epic says that the technical restrictions are neither necessary nor proportionate to the risks posed to users by sideloading. But Google says that the restrictions are appropriate on security grounds and not such as to amount to a substantial lessening of competition. Google makes the following points.
4959 First, Google says that a wide range of organisations including governments, security organisations, telecommunications bodies, and the OEMs themselves, do not recommend sideloading apps. The unsurprising consensus would appear to be that users should be cautious before using a new source to install apps. Installing apps outside pre-installed app stores involves greater risk.
4960 It says that it is important in that context for users to be informed that they are using or about to use a new source, and that this involves an additional element of risk. Being so informed, users can act rationally in their own interests, including by assessing for themselves whether they should trust that source.
4961 It says that government bodies and other entities have given advice concerning downloading and installing apps from unknown sources and from official app stores, like the Play Store. Government and industry guidelines making various recommendations have given reasonable security advice that users should always download and install apps from official app stores, and devices should not install from unknown sources and, where possible, disable installations from unknown sources. Google has referred to the following matters.
4962 The Australian Cyber Security Centre, which is part of the Australian Signals Directorate, provides cyber security advice, assistance and operational responses to prevent, detect and remediate cyber threats to Australia. On 18 January 2023, in a document published on the ACSC’s webpage called Secure Your Mobile Phone, the ACSC advises readers to “[f]ollow these steps to secure your phone and protect your information. Most of these steps are free and easy to do and can also be used to secure your tablet”. They are (a) “[c]heck that apps are made by a reputable company before downloading and installing on your phone. Only download apps from an official app store”. The Play Store is an “official app store”; and (b) [s]et your phone to require approval before apps are installed”.
4963 On 1 October 2021, the ACSC published a guide which recommended that when using apps and browser extensions on their devices, people should “[a]lways download apps and browser extensions from an official store such as Apple’s App Store or Google Play for Android”.
4964 Further, the Australian Mobile Telecommunications Association is the peak industry body representing Australia’s mobile telecommunications industry. Its members include mobile network operators and service providers, mobile phone and device manufacturers, retail outlets, network equipment suppliers and other suppliers to the industry. The AMTA maintains a webpage titled “Beware of scams” which outlines the AMTA’s “top tips” for users to protect themselves when using mobile devices. Users are advised to “[b]e careful what you install” and “not install apps or software on your mobile device unless they are from a trusted source such as Apple AppStore or Google Play”.
4965 Further, in May 2021, the US Federal Trade Commission published an article called How To Protect Your Privacy on Apps. This article recommended that users “download apps only from official app stores, such as your device’s manufacturer or operating system app store” to “reduce the risk of installing potentially harmful apps”.
4966 Further, in October 2020, the National Security Agency (US) published a document called Mobile Device Best Practices. This document “outlines steps the users can take to better protect personal devices and information” and recommends that users only install apps from “Official Stores” to prevent “Malicious Apps” and other threats and vulnerabilities.
4967 Second, Google points out that Professor Somayaji agreed that installing off Play Store involves greater risk.
4968 Professor Somayaji agreed that the recommendations from government agencies to install apps only from pre-installed app stores were sensible. He agreed that in light of those guidelines, users are likely to wish to be informed if they are about to install an app outside of the Play Store, that they are about to install an app, and the name of that app. He agreed that installing apps that have not been screened by the Play Store increases the risk for users. Further, he agreed that sources that do not have malware screening for all apps are more likely to infect users’ devices with PHAs. Further, he agreed that devices that enable unknown sources to install seem to have a higher rate of getting malware on the device.
4969 Third, Google says that the technical restrictions align with its security model. In particular, Google says that it has no way in advance to know which users may or may not be familiar with the risks presented by malware. In the absence of unknown source warnings and the unknown source setting screen, some users could remain unaware of the risks that installing apps from unknown sources pose, and could remain unaware that a particular app is installing other apps. It says that it would be a poor user experience if the user was infected by malware as a result of moving from a relatively protected area into a much riskier one, and exposed to malware without any suitable warning. The unknown source warnings assist to protect the experience of users and assist users to make informed decisions in their own interests.
4970 Further, Google says that the model recognises the need for special permissions, including in connection with installing packages, which users can only grant in the settings app and which are required to protect users. The default sideloading flow is consistent with this aspect of the model.
4971 Fourth, Google says that the unknown source warning and the unknown source setting screen conform with good design principles. The unknown source warning foreshadows the decision that the user will make, and the unknown source setting screen is an active form of notification, which interrupts the user by taking them away from installing a specific app and asks them to make an anterior decision as to whether they want to allow another app to install apps, including the app the subject of the installation flow.
4972 That decision need only be made once and can be completed quickly, but is still designed to make the user pause and think about their action, which involves potential risk.
4973 Now Epic says that this one-time permission is not conducive to security because, based on GPP warnings, sideloaded apps from Chrome are more likely to contain malware. But Google says that Epic confuses two different types of decisions. One decision is about sources. Another decision is about specific apps. Further, Google says that Epic disregards Google’s multi-layered approach to security which includes the installation prompt and then GPP as a last level layer.
4974 Further, Google says that the unknown source warning and the unknown source setting are reasonable and proportionate when considered against the backdrop of what is known about unknown sources and the layered approach to security on GMS devices.
4975 On GMS devices, users have flexibility as to the methods for obtaining apps, including the ability to download and install an app from various sources. The security risk posed by apps obtained from different sources varies, and the degree of oversight that Google and the OEMs have over these sources also varies.
4976 Accordingly, the measures used to address the security risk from each of these sources is tailored to these variances.
4977 As Google has access to more information about apps submitted to the Play Store than apps off-Play, apps on the Play Store are subjected to a comprehensive scan and review. Further, given that an app published on the Play Store may be found to be malicious after being published on the Play Store, apps installed from the Play Store are also subject to the daily GPP scan.
4978 Further, apps from preloaded third-party app stores are subject to any app review process of that store, the legacy scan, the real time scan depending on the country, and the daily GPP scan. The third-party app store must also be approved, which involves security checks. In choosing to preload a third-party app store, OEMs place their trust in that store, thereby assuming some responsibility for the security of those stores.
4979 For GMS devices, the OEM can decide whether an app store is to be pre-installed on the device, with a privileged install permission, subject to the security review by Google. That decision by the OEM in effect marks out the territory within which users can operate and install apps without granting any particular permission.
4980 But one of the features of Android, and indeed a point of differentiation with iOS, is that users have the freedom to download and install an app or an app store from any source they wish.
4981 Google says that it would be unsatisfactory if users could move outside the OEM-specified protected area without any barrier or warning whatsoever. Instead, the relevant devices contain a design structure whereby users are informed that they are seeking to use a new installation source not previously approved, and have to take a step to choose to do so.
Analysis
4982 Now it is convenient at this point to address a number of topics under various headings.
What did or does Google know as to the impact of the unknown source install flow?
4983 Now Epic says, and I agree, that Google has long recognised that the unknown source install flow is a meaningful hurdle which prevents or at least hinders Android device users from sideloading apps and switching to rival app stores. The following matters, which have been taken from the evidence before me, clearly demonstrate this.
4984 A May 2017 document titled Amazon Competitor Deep Dive concluded that the sideloading process represented a significant hurdle to switching to the Amazon app store. Google considered it to be a switching hurdle that was too high for most users.
4985 Google also discussed “creat[ing] more third party apk install friction” as a “[p]otential lever” that would “[m]ake it harder for users to switch stores”.
4986 Further, as Epic points out, evidence of the impact which installation frictions imposed by the technical restrictions have on developers’ ability to directly distribute Android apps can be found in Google’s response to Epic’s plan to launch Fortnite outside the Play Store.
4987 On 22 June 2018, Mr Sweeney sent an email to Google advising that Fortnite would be distributed on Android “via APK download from Fortnite.com rather than Google Play Store”. On the same day, Mr Rosenberg requested “some fleshed out thinking and talking points on: [c]ompromises/ [t]radeoffs with [Epic’s] approach”, including for “[u]ser experience”. The “approach” referred to was Epic’s stated plan to distribute Fortnite via sideloading. Mr Rosenberg also wanted to understand how it would work on versions of Android in relation to the unknown source install flow.
4988 Mr Gennai responded the same day, and said:
…
… it would be useful to get some data points on how many installs even the large players get when they choose to distribute off Play. The Amazon App Store would be a good example, and Venkatesh’s team … should be able to get numbers -- penetration of devices by country would be ideal. The website Amazon uses to help users install it is also a cautionary tale of how difficult it may be.
Also, would be good to get the latest numbers on how what % of devices have unknown sources turned off by country … Again, to highlight that there’ll be large hurdles for distribution, unless they were to get preloaded (which is a very long game). …
…
4989 The first paragraph reveals that Mr Gennai considered that distributing Fortnite via sideloading would be “difficult”, that data on how many installs the Amazon app store and other “large players” had achieved via direct distribution would be useful to demonstrate this, and that the website Amazon used to help users sideload its app store was “a cautionary tale of how difficult [distribution via sideloading] may be” for Epic.
4990 The second paragraph reveals that Mr Gennai regarded the unknown source install flow as presenting a “large hurdle” for distributing Fortnite via sideloading. His use of “again” confirms that that is also what he was saying in the first paragraph.
4991 Further, he considered pre-installation to be a “long game” and something that would take considerable time to organise at scale.
4992 Now under cross-examination Mr Gennai sought to disavow the plain meaning of his own words, but the document is to be understood as I have said. It confirms that Google has understood for many years that the unknown source install flow represents a significant hurdle for the successful distribution of Android apps via sideloading.
4993 Mr Gennai’s email also confirms that Google understood that Epic would encounter that same hurdle in seeking to distribute Fortnite outside the Play Store. As Mr Rosenberg observed in an email to Mr Lockheimer and others on 19 July 2018, the “Web install UX” that Epic was planning to use for direct distribution of Fortnite involved “17 screens (!) -- compared to the 2 screens to install via Play”.
4994 Ultimately, Mr Gennai conceded that Epic would be more successful if they distributed via the Play Store rather than by direct download, and that by changing the unknown source install flow in Android 8.0 to require users to approve unknown sources for every new source, Google in fact increased friction.
4995 Further, in a 2018 document titled Response to Epic that was prepared by Ms Kochikar, it is evident that Google considered that directly distributing Fortnite would significantly lower its Android reach compared to distribution through the Play Store, due to the fact that only about 20% of the devices that could run Fortnite “have unknown sources turned on”, and that proportion was lower in Fortnite’s top revenue markets. The reason it mattered that so few Android devices had “unknown sources turned on” was that everyone else would have to confront the unknown sources install flow.
4996 The following purple patch from Mr Garry Rich SC’s cross-examination of Ms Kochikar further made the point and supported Epic’s case:
MR RICH: And you felt the fact that only about 20 per cent of viable devices had unknown sources turned on would significantly lower Fortnite’s reach?
MS KOCHIKAR: Yes. That was our assessment.
Q: And you appreciated that meant that some 80 per cent of users would not be able to sideload Fortnite without going through the Unknown Sources install flow?
A: Yes, they would have to do more work.
Q: And you expected, didn’t you, that users would fall out during the install flow and not complete it?
A: Yes, that’s a distinct possibility.
Q: Well, you thought it was likely, didn’t you?
A: Yes.
Q: Because of the extra steps?
A: Yes.
Q: And you agree with me that users usually do fall out of the install flow if there are extra steps?
A: Yes.
Q: And the more steps, the higher the proportion of users will fall out; correct?
A: Yes.
4997 On 18 July 2018, Ms Kochikar drafted a script for a call with Mr Rein of Epic. That script included the following passage:
… Frankly, the experience of getting Fortnite on Android from the links Tim sent was frankly abysmal. Have you tried it? Do you feel good about the experience? Are you okay with millions of your users having an awful experience? Do you worry that most will not go through the 15+ steps? …
4998 Ms Kochikar said words to that effect to Mr Rein during their call shortly afterward. She had watched someone sideload Fortnite by that time and thought that the experience was abysmal. Her view was that most users would not complete the install flow.
4999 Now Ms Kochikar sought to blame the particular approach that Epic had taken, in that Epic was asking users to download an installer and then use the installer to install the app. But as she then conceded, that two stage process is what any third-party app store would need to implement if it was being distributed via sideloading. Further, at the time, using an installer was the only way that Epic could enable a sideloaded Fortnite app to be updated after it had been installed.
5000 Now the effect that the technical restrictions had on curtailing the growth in Fortnite’s users on Android outside the Play Store is clear from Epic’s evidence.
5001 Mr Weissinger, vice president of marketing for Epic, held concerns about the effect the frictions would have on Epic’s attempts to acquire a significant user base on Android, and Epic developed a strategy to address that friction and mitigate its effects.
5002 That strategy involved engaging with a third-party software and data analytics company specialising in app distribution on mobile devices. At the recommendation of that company, Epic implemented “scrollable tips” on its website to guide users through the scary warnings, in the hope that would increase conversion rates. Epic also invested in additional consumer support to respond to potential user concerns about the direct download process.
5003 But despite the investment in this strategy, the launch of Fortnite outside the Play Store was not a success. Mr Weissinger gave evidence that a significant proportion of users did not successfully directly download Fortnite onto their Android device because of friction in the install flow. His view was corroborated by statistical analysis of user drop-off rates at each stage of the Android install flow affected by the technical restrictions.
5004 One such analysis from around September 2019 found that, due to sideloading complexity, there was a 25% loss from players who went to Epic’s website, and that up to 34.5 million players had potentially been lost. This is further corroborated by an email from the director of marketing at Epic to Mr Weissinger on 7 January 2019, describing friction in the Android install flow as sideloading “pain” that was one of the three “negative vectors” affecting Epic’s ability to distribute Fortnite on Android outside of the Play Store.
5005 Mr Weissinger also gave evidence that Epic had supported several prominent marketing initiatives with OEMs such as Samsung to promote Fortnite on Android devices, but that the friction in the direct download install flow was one of the key factors for the poor performance of those campaigns targeted at acquiring Android device users.
5006 Generally, I agree with Epic that part of the cause of its failure to grow a significant user base is referable to the technical restrictions’ effect on the commercial viability of distributing Android apps outside of the Play Store. Indeed, after assessing the Fortnite usage statistics on Android, Mr Weissinger concluded that Epic was unable to acquire a significant user base by making the game available outside of the Google Play Store.
Security risks posed by apps versus install sources
5007 Now the technical restrictions cause a user, who is seeking to use a non-privileged installer to sideload an app, to encounter the unknown source install flow, unless and until they grant an installation permission to the relevant source.
5008 On devices running Android 8.0 and later, this flow involves users granting such a permission on a “per source” basis, by clicking through various steps including, typically, a browser warning where the installer is a web browser, the unknown source warning, the unknown source setting screen and the installation confirmation screen. This flow applies to installations from any non-privileged source, regardless of the nature of the relevant app that is being installed.
5009 As I have explained earlier, in this context the “source” or “install source” means the particular app on a device which is trying to install another app. So, for an app downloaded through a web browser, the install source is the web browser app and not the website from which the app has been downloaded.
5010 Now Professor Somayaji’s opinion was that an app poses a security risk for a user based on the contents of the app package and the behaviour of the app. He said that when installing an app, the danger a user may experience is determined by the app that is being installed, not by the source of the app which already exists on the device and which is being used to install the new app.
5011 Professor Somayaji also said that where the warning relates to the source app, that is, the app doing the installation, rather than the app being installed, the warning does not accurately reflect whether any particular installation is risky or not.
5012 When assessing and addressing security risks posed by an app, considering the install source might be relevant in determining whether the app could be malicious, but the install source does not define an app as malware.
5013 Mr Porst, who leads a team of engineering managers, gave evidence that his team takes an app-centric approach to security and that the characteristics and behaviour of individual apps are a key focus of that team’s work.
5014 Mr Cunningham agreed that the vulnerability of a device and its data to attack is principally a function of the specific app and its characteristics and not a function of its source, and the specific app will have the most bearing on that risk.
5015 During cross-examination, Professor Traynor gave evidence that assessing the functionality of an app’s code is important from the perspective of security analysis. Although he also considered that assessing the install source could be important, that was in the circumstance of a user installing an app that they never wanted in the first place. But in such circumstances it would remain the case that an unwanted app would only pose a security risk to the user if it were otherwise malicious.
5016 Now the distinction between an app and an install source, and the relevance of each in exposing a user to security risk, is important to the application of the technical restrictions.
5017 Google applies the technical restrictions based on install sources, not the contents of the app package or the behaviour of the app. Epic asserts that that approach has led to Google applying installation friction in a manner that is to some degree disconnected or decoupled from any actual risk. Now I should say here that even if I accept that to be so, this is all far away from anti-competitive conduct in purpose or effect that might infringe s 46.
Is the installation friction disproportionate to the security risk?
5018 Let me now turn to the installation friction itself and begin by setting out the friction faced by Android device users when sideloading apps.
5019 When downloading and installing apps otherwise than from the Play Store or a pre-installed installer with a privileged installation permission, the user of an Android device will typically confront the following installation friction.
5020 First, the browser warning, which appears when the user initiates the download of an APK file using Chrome.
5021 Second, the unknown source warning, which appears when the user tries to install an app using Chrome, or any other non-privileged installer, provided they have not previously conferred an installation permission on that installer.
5022 Third, the unknown source setting screen, which appears after the user taps “settings” in the unknown source warning, again subject to the proviso in the previous paragraph.
5023 Fourth, the installation confirmation.
5024 Now the technical restrictions imposed by Google are responsible for the installation friction caused by the second to fourth steps just described. But of course that installation friction falls to be evaluated within its context which includes the installation friction caused by the browser warning.
5025 I have discussed elsewhere the impact of those installation frictions on Android app distribution. That evidence is consistent with Professor Somayaji’s qualitative assessment of the typical unknown source install flow as giving rise to a high degree of friction, relative to the installation friction associated with installing an app from the Play Store or other privileged installer, which he considered to be minimal.
5026 Now in some cases the imposition of a high degree of friction in respect of the installation of an app will be appropriate and justifiable on grounds of device security. So, if an app is suspected or known to be malicious, it is appropriate that a device user encounters severe or even insuperable friction in seeking to install it.
5027 Indeed, GPP does that in the case of an app that has been scanned by [REDACTED] and determined to be a PHA. Depending on the severity of the PHA category, GPP might give the user a choice as to whether to install the app or it may prevent the installation entirely.
5028 Now what purpose does installation friction serve?
5029 In Professor Somayaji’s opinion, the purpose of installation friction, which can include warning screens, additional confirmation pages, or requirements that the user modify device settings before installing an app, is to discourage the downloading of potentially dangerous apps, or at least to make users aware of the risks associated with downloading a potentially dangerous app.
5030 As to the circumstances in which installation friction is appropriate and justified, it is only functional as a security mechanism, and will only improve security outcomes, if it is applied in proportion to the risk associated with downloading a given app.
5031 In Professor Somayaji’s opinion, the key factor in determining whether installation friction is applied proportionately in relation to security risk is whether the installation process helps a user discern between safe apps and malicious ones.
5032 If friction is applied proportionately, users are less likely to install risky apps and will be informed about risks associated with the app which may help them to exercise prudence when using the app after choosing to install it. By contrast, friction applied to apps that are known to be safe is disproportionate, does not serve a security purpose and can be detrimental to security, particularly where its overuse leads to users becoming desensitised to actual risks.
5033 I have accepted Professor Somayaji’s views given his expertise and reliability.
5034 Moreover, his opinions relevantly align with Google’s own evidence, most notably with R Mayrhofer et al, “The Android Platform Security Model” (2021) 24(3) ACM Transactions on Privacy and Security, which is an article authored by then-senior Google personnel including Mr Rene Mayrhofer (director of Android platform security) and Mr Nick Kralevich (technical lead of Android platform security).
5035 The document explains that the “guiding principles” core to Android security include that users should not be over-prompted as this can lead to prompt fatigue and blindness, and that users should be prompted in a way that is understandable, such that prompts and disclosures must be phrased in a way that non-technical users can understand the effects of their decision.
5036 Mr Porst agreed with the correctness of these principles and that users should be given accurate information about security threats because such information leads to users taking the information more seriously.
5037 Professor Somayaji accepted that it can be difficult to precisely calibrate friction to risk. But the uniform levels of severe friction in the unknown source install flow are, in his view, almost guaranteed to offer inappropriate amounts of friction in many situations and cannot be said to find their basis in legitimate security concerns.
5038 The friction caused by the unknown source install flow is more than is necessary to reasonably address the security risk posed to an Android device by an arbitrary app that a user might seek to sideload.
5039 Now in evaluating the proportionality of the installation friction caused by the unknown source install flow, Professor Somayaji referred to the fact that there were three different dimensions along which the friction that is imposed is misaligned with the security risks posed to a user who seeks to download and install an app to their Android device.
5040 As to the first dimension concerning subsequent installations using a non-privileged installer, Professor Somayaji gave evidence that the imposition of severe friction for a first installation using a particular installer, with minimal friction imposed for subsequent installations using that installer, is not conducive to security.
5041 Indeed, Mr Cunningham agreed that Google’s own documentation shows that users who have sideloaded using Chrome are more likely to receive GPP warnings for dangerous malware types. That is, Google is aware that a user who elects to sideload using Chrome, and who therefore confers an installation permission on Chrome, is more likely to be exposed to dangerous malware.
5042 Yet, on Android devices running Android 8.0 and higher, after a user confers an installation permission on a non-privileged installer such as Chrome, the OS will no longer present the unknown sources warning or setting screen to the user upon subsequent installations using that installer unless manually toggled off by the user.
5043 In that circumstance, installation friction is not applied proportionately in relation to security risk, and the installation process does not help the user discern between safe apps and malicious ones.
5044 As to the second dimension concerning privileged versus non-privileged installers, some non-privileged installers, for example, third-party app stores that are not pre-installed on devices, are, and are known by Google to be, safe, with low or zero rates of PHAs. Yet, as non-privileged installers, they cannot be used to install an app without first being granted an installation permission, typically via the unknown source installation flow.
5045 Contrastingly, some privileged installers are, and are known by Google to be, risky. Google knows that OEM preloaded installers can, and in many cases do, pose a much more significant security risk than non-privileged installers used for sideloading. Yet, by virtue of being privileged installers, those OEM pre-installed installers can install other apps with minimal installation friction, equivalent to that of the Play Store. Professor Somayaji rightly identified this contradiction as undermining Google’s claims regarding the effectiveness of its friction-based security measures.
5046 Ultimate control over whether an app store or other app can be pre-installed with a privileged installation permission rests with Google via the allow-listing process, which Google itself has recognised to be flimsy.
5047 Similarly, the Play Store has been, and continues to be, a source of malware. Further, malware on the Play Store has shown an increasing trend. That malware finds its way onto the Play Store is unsurprising, but notwithstanding these risks, the Play Store presents users with only trivial installation friction.
5048 As to the third dimension concerning special versus runtime permissions, Google configures GMS Android such that a user confers an installation permission on an app via a special permission, by navigating to the unknown source setting screen in the device’s settings app.
5049 But the consequence of conferring the permission is simply that the app is subsequently permitted to request to install apps via the installation confirmation. The app is not thereby permitted to install other apps without asking permission, in the manner of a privileged installer.
5050 Contrastingly, Google permits other permissions, such as camera or microphone access, which are of a kind that control sensitive resources on a device, to be granted via runtime permissions, which do not require the user to confer the permission in the settings app. The consequences of granting those permissions are immediate.
5051 Professor Somayaji expressed the view that requiring users to enable unknown sources in settings and not via a runtime permission contributes to the severe friction of the app installation process, with no clear security benefit.
5052 Now the final step of the unknown source install flow is the presentation to the user of an installation confirmation. That confirmation comprises two sequential messages.
5053 The installation confirmation is displayed during the installation process for all sideloaded apps, even if a user has, immediately before encountering that confirmation, indicated their assent to an app’s installation by having navigated through any browser warning, the unknown source warning and the unknown source setting screen.
5054 Professor Somayaji gave evidence that the installation confirmation is a further instance of Google applying friction that is disproportionate to the relevant risks.
5055 The installation confirmation introduces an additional measure of friction in the install flow. Further, it applies uniformly, and without regard to Google’s knowledge about the app. Further, it does not provide the user with any information that could help them assess the potential risk of the app being installed.
5056 It is convenient to make one other point here that is made by Epic concerning the unknown source install flow being indiscriminate or not sufficiently discriminating.
5057 Android devices will cause a user to encounter the unknown source warning and setting screen indiscriminately, regardless of the specific app the user is seeking to sideload, provided that a user has not first conferred an installation permission on the install source.
5058 That is because the unknown source install flow is triggered by the source not having an installation permission, which is a status disconnected from the app that the user is seeking to install.
5059 So, the unknown source install flow does not discriminate between apps on the basis of what Google or the OEM knows or does not know about the security implications of installing that app.
5060 The unknown source install flow will apply regardless of whether the app has been scanned by [REDACTED] and regardless of whether the app has been developed by Google, the OEM, or a reputable developer.
Is adequate, accurate and readily understandable information provided to users?
5061 Now although Google says that the various screens in the unknown source install flow are necessary to inform users about security threats to their device, as Professor Somayaji observed, the unknown source install flow does not provide any information about the specific app or the status of the developer, for example, their identity or their verification status, even where such information is available to Google.
5062 And as Mr Porst and Mr Cunningham rightly accepted, the default text in the unknown source warning and setting screen conveys no information to enable a user to assess the likelihood that the app they are seeking to install is malicious.
5063 Moreover, the default text of the unknown source setting screen states that “[y]our phone and personal data are more vulnerable to attack by unknown apps.”
5064 If “unknown app” is understood as an app that is being sideloaded, and the implicit comparator is apps installed by privileged install sources, the text is not accurate.
5065 Now to speak of text not being accurate is not to introduce notions of false, misleading or deceptive conduct or the like. It is merely to state that inaccurate information does not serve the ends of security, and may subvert them.
5066 In this instance, the default text is apt to subvert the ends of security by potentially guiding users to a relatively riskier channel of app distribution being a privileged installer, and away from a relatively safer channel being a non-privileged installer.
5067 Google knows that installing apps from pre-installed privileged installers is substantially riskier than sideloading. As stated in the September 2018 document titled AP-PS: Unknown Sources to which I have already referred, the “most worrying source of malicious PHAs are OEM preloads – not unknown sources”.
5068 Google also knows that installing apps from some third-party app stores that are not pre-installed on Android devices is substantially safer than installing apps from the Play Store, even if it does not know how many third-party app stores there are that fall into that category.
5069 Now in Professor Somayaji’s opinion, the default text of the unknown source warning and setting screen is likely to cause confusion even for technically proficient users. The evidence supports his opinion, which is against Google’s position that the various screens in the unknown source install flow are necessary to inform users about security threats to their device.
5070 Let me deal with the term “unknown sources”.
5071 On devices running versions of Android earlier than Android 8.0, the unknown source setting screen refers to apps or applications from “unknown sources”, and warns users about the greater vulnerability of the user’s phone and personal data “to attack” by such apps. On Android versions between Android 4.1 and Android 8.0, the unknown source warning also refers to “apps obtained from unknown sources”.
5072 Professor Somayaji considered the term “unknown source” to have both negative and confusing connotations in circumstances where a user installs an app using a web browser or alternative app store. In his view, both of those sources are more properly thought of as known, given that they would either be pre-installed on the user’s device or intentionally downloaded by the user.
5073 Further, Mr Cunningham characterised the term “unknown source” as largely a colloquialism within Google. So it is surprising that Professor Traynor described the term “unknown” as a “term of art”. Moreover, Professor Traynor could not point to where that “term of art” might be defined. Yet that was no obstacle to him asserting in his report that to say that sources other than the Play Store or a pre-installed OEM app store are “unknown” is a statement not only about who is responsible for an app’s safety but also about what app review process they have used.
5074 Professor Traynor speculated that Google had some level of oversight of the process by which pre-installed sources evaluate apps and that all other sources would be “unknown” because their processes are not known to Google. But that speculation is not supported by the evidence as to the circumstances in which Google will approve an OEM’s conferral of a privileged install permission on a pre-installed app.
5075 Google’s confused evidence on the meaning of the term rather makes the point that it would also confuse a lay user confronting Google’s warnings.
5076 Let me next deal with the term “unknown apps”.
5077 On devices running Android 8.0 and higher, the unknown source warning and the unknown source setting screen refer to “unknown apps”, and the setting screen warns users about the greater vulnerability of the user’s phone and personal data “to attack” by unknown apps.
5078 Professor Somayaji observed that the reference to “unknown apps” in the unknown source install flow has no substance, because the messages and actions presented to users do not give information or allow users to make decisions at the app level, as distinct from the install source level.
5079 Further, Mr Cunningham was unable clearly to explain what Google intends to convey by the term “unknown app”, and said that such apps could be “unknown” to the device, Chrome, Google, the OEM, or all of the above. Nor was he able to point to anywhere on an Android device where the term “unknown app” is defined, and was only able to vaguely point to the settings app as having some bearing on the term.
5080 This evidence is surprising given Mr Cunningham’s role as the product manager responsible within Google for the install flow. Professor Traynor similarly was unable to offer a definition for the term “unknown app”, and acknowledged that, given the default text would suggest that an app developed by Google is an “unknown app”, “perhaps the wording could be clarified there.”
5081 Let me say something about the term “source”.
5082 In Android 8.0, Google changed the reference to “apps obtained from unknown sources” in the unknown source warning to “unknown apps from this source”, and added the words “[b]y installing apps from this source” to the footer in the unknown source setting screen. But the term “source” is undefined.
5083 Professor Somayaji considered it to be unclear whether “source” refers to a developer, distributor, website, or other entity in a non-technical context. He pointed out that, in practice, Google uses it to mean “the app from which another app is installed”, rather than the origin or author of the app.
5084 But I agree with Epic that the term “source” can seemingly adopt different meanings, depending on its context.
5085 In cross-examination, Professor Traynor was questioned on the term “source” when used in a warning prompt displayed by the Samsung Internet app on an Android device. He remarked that the term “source” was used in that context to refer to the website from which the app was being downloaded, rather than the Samsung Internet app itself. But that is contrary to what the term appears to mean in the unknown source warning that is displayed when a user seeks to use Chrome to perform an app installation. Professor Traynor explained that, in that context, “source” refers to Chrome, not the website from which the app was downloaded.
5086 Now generally, and as Epic correctly observed, these various terms are not only confusing on their face, but such confusion cannot be resolved.
5087 There is nowhere that a user can navigate on an Android device to illuminate their meaning. And, if the responsible Google product manager, and a professor of computer science, were unable to provide me with clear and unambiguous explanations of what the default text in the unknown source install flow means, there can be little doubt that the warnings are in relevant respects uninformative and incomprehensible to ordinary users like the rest of us.
5088 And contrastingly, other aspects of the threatening verbiage that is presented to users in its default text are direct and unambiguous, even if inaccurate or apt to confuse.
5089 Language such as “[f]or your security”, “more vulnerable to attack” and “you agree that you are responsible for any damage to your phone or loss of data that may result from their use” was significant to Professor Somayaji’s characterisation of the friction caused by the unknown source install flow as severe.
What is the evidence of the efficacy of the technical restrictions in ensuring security?
5090 Now Google has said that the technical restrictions promote the safety of the Android ecosystem by alerting and warning users when they are exposed to greater risk and stray beyond Google’s protections.
5091 But as Epic points out, there is no evidence of any empirical analysis by Google of the effectiveness of the technical restrictions, either individually or cumulatively, at ensuring the security of Android devices, nor has Google pointed to any internal documents corroborating the assertions of its witnesses as to the efficacy of the technical restrictions.
5092 As Epic points out, Professor Traynor accepted that he had not seen any empirical data or metrics created by Google that measure the efficacy of the unknown source install flow from a security perspective. Nor was he aware of any empirical research as to the effectiveness of any of the browser warning, default unknown source warning or unknown source setting screen in promoting device security.
5093 Now Google says that the reason why there is no such data is that it would be challenging to add code to collect that type of data in an accurate manner on GMS devices. In re-examination, Mr Cunningham elaborated on these challenges, which generally speaking I accept.
5094 Further, Google in 2018 and using GPP collected data from devices running versions of the Android OS that preceded Android 8, which did not have the per source unknown source warning but which did have a GPP warning that was intended to perform a similar role. In the September 2018 presentation titled AP-PS: Unknown Sources it was noted that there was a “40% reduction in install attempts by hostile downloaders”.
5095 On devices running Android 8 and later versions of the Android OS, Google cannot use GPP to collect data about the unknown source warning because that warning is not generated by GPP.
5096 So, and in the absence of any meaningful data analysis, as Epic points out, the highest that Google is able to put its case in this regard is that the technical restrictions promote the safety of the Android ecosystem by guiding users to a single preferred source, which Professor Traynor considered is “a smart way to minimize potential harms to many users”.
5097 But Epic says that in circumstances where the technical restrictions are disproportionate for ensuring the security of Android devices, to guide users to a single preferred source of apps is not a reasonable security policy.
5098 Google also says that the technical restrictions are legitimate and proportionate to protect OEMs and applicable Google entities from liability for claims in relation to obtaining apps from outside the Play Store or other pre-installed app stores. In this regard, reference can be made to the default text in the footer of the unknown source setting screen, which states “[b]y installing apps from this source, you agree that you are responsible for any damage to your phone or loss of data that may result from their use”.
5099 But as Epic points out, Google has not sought to explain the basis on which “OEMs and applicable Google entities” might plausibly become liable in any jurisdiction, including Australia, by reason of a user sideloading an app and thereby causing “damage to [their] phone or loss of data”.
5100 Further, Google has not pointed me toward any similar user agreements or acknowledgements on any other computing platform that permits the installation of apps from elsewhere than a privileged or pre-installed install source, such as on PCs.
5101 As Epic points out, Mr Cunningham was asked a number of questions in cross-examination about the relevant default text in the setting screen. He did not know with whom it is that a user “agree[s]”, when they proceed to “instal[l] apps from this source”. He was unsure whether a user was entering any agreement at all. He also agreed that nowhere in Google’s default implementation of the unknown source install flow, or on Google’s website, did Google inform the user with or to whom they were making an agreement or acknowledgement.
5102 Now I should say here that I accept Epic’s case that the technical restrictions are disproportionate to the relevant risk, but to so accept does not take Epic far enough in terms of its s 46 case as I will discuss later.
Has Google made any real improvement to the unknown source install flow?
5103 Now as Epic correctly points out, Google has done little to improve the unknown source install flow during the relevant period. Epic made the following points with which I agree.
5104 The reason that Google has not done more is that it suits the Play Store for this alternative distribution method of the direct distribution of Android apps to be an ordinary experience, to say the least, for users.
5105 Such an experience, which Ms Kochikar described in an internal email as the pain of unknown sources, not only deters users from sideloading apps including app stores, but it deters developers from distributing apps outside the Play Store.
5106 This type of consideration and consequence was looked at by Google in February 2021 in connection with the introduction of Android 12.
5107 At that time, Google proposed to make certain changes to the unknown source install flow, including the default language of the unknown source warning, and to allow third-party app stores to update apps automatically.
5108 Mr Cunningham agreed that Epic’s litigation against Google in the United States was a factor that was “certainly very top of mind” in Google’s decision to invest and ultimately make those changes in Android 12. Similarly, Mr Cunningham gave evidence that he had Epic’s complaints about Google’s installation flow in mind when he was “brainstorming” for the Android 12 project.
5109 Such brainstorming included both the changes implemented, as well as a range of other proposed changes considered by Google for Android 12 which were ultimately not implemented.
5110 When considering the proposed changes to Android 12, Google conducted a project scoping exercise. The overarching question, which Mr Cunningham agreed was accurate with respect to the project, was according to a 2021 document titled App Stores in Android 12, “[w]hat is the business impact of implementing these changes in Android 12?” Further, Mr Cunningham agreed that another question that Google was to consider in accordance with the project scope was “[w]hat is the projected financial impact to Play of the proposed changes?”
5111 Ultimately, the changes proposed in connection with Android 12 were, according to a February 2021 presentation titled App Stores on Android 12, “assessed across two lenses”, namely, “Business/Ecosystem” and “Security”.
5112 The question asked in relation to the “Business/Ecosystem” lens was “[w]ould this change directly compel developers to invest in assets off-Play (e.g., 3P app store, etc.)?” Google undertook an assessment of the proposed changes applying that criterion and determined that the “[i]ncremental impact to Play is expected to be minimal as developer behaviour is likely to stay consistent with the proposed change”. Mr Cunningham agreed that one of the things being assessed through the “Business/Ecosystem” lens was whether reducing installation friction would result in developers increasing investment in third-party app stores that might compete with the Play Store. He said that “business considerations with respect to Play were front and centre” when Google evaluated the impact of the proposed changes to the unknown source install flow.
5113 When Google did eventually implement the changes to the unknown source install flow in Android 12, Mr Cunningham agreed that there were “elements of strategy” involved on the part of Google to present a narrative to the world that it was taking steps to make sideloading easier.
5114 Now this was all in the context of Epic’s litigation in the United States and Google’s expectation that the impact of the changes it was proposing upon the business of the Play Store would be minimal.
5115 Further, Google has not otherwise improved the unknown source install flow in the 6.5 years since the commencement of the relevant period.
5116 Further, Google has chosen not to otherwise improve the unknown source install flow, despite its knowledge of developer discontent with that flow.
5117 In May 2017, prior to the introduction of Android 8.0, Google received feedback from Facebook that the proposed per-source unknown source install flow was “scary” and that “the multiple steps required to go to settings, flip the toggle, and then go to installer dialogue feels laborious”.
5118 On 19 May 2017, in relation to a meeting with Facebook, Google recorded Facebook’s concerns that “additional friction of per app approval will inhibit users from sideloading” and that Facebook made suggestions which included consolidating the unknown sources approval, and installation permission, into a single screen.
5119 In my view, the evidence establishes that the frictions imposed by the technical restrictions are disproportionate to the risks that Google asserts.
Project Alley-oop
5120 Let me say something about Project Alley-oop, which was concerned with improving indirect app discovery of apps outside an app store, which typically involves links to apps within videos, tweets, advertisements and other materials posted online, by providing an “overlay install flow” that allows users to install apps from an external site, without needing to leave that host app, whilst the installation technically occurs via the Play Store.
5121 It would seem that the effect of this project was to reduce the steps and frictions involved in installing an app from outside the Play Store.
5122 When an overlay install, which is sometimes called an inline install, flow is occurring, users do not feel like they are leaving the place where they clicked install, for example, an advertisement for the app. The overlay install occurs and the user remains where they began.
5123 As part of Project Alley-oop, YouTube experimented with an overlay install flow and found that eliminating just one step in the install process increased its conversion rate by 72%.
5124 By 26 August 2016, according to a Google presentation titled BD Program Review: Google Play App Access Program (aka Alley-oop), Google had decided to “give the [Alley-oop] project a green light for both 1Ps as well as for selected 3Ps”. Google planned to tell developers that the overlay install flow was “an extension of the Play Store … bringing the Play Store directly to users post click”, and that Google wanted “to reduce app install and open friction, particularly for app discovery originating outside the Play Store; this is better for users and developers”.
5125 Google insisted, as a condition of providing the Alley-oop service to developers, that they must not distribute Android apps via any mechanism or platform other than the Play Store.
5126 In April 2018, Facebook offered to avoid using their capability to install third-party apps in exchange for “Alley-oop ASAP”. The advantage of Alley-oop ASAP was that it eliminated the need to click “install” twice. Instead, the app would start downloading immediately following one install click made outside the Play Store. Eliminating that one click was expected to improve the conversion rate dramatically.
5127 Subsequently, Google tested the Alley-oop product in real world scenarios and found that developers achieved more installs due to the reduced friction.
5128 Some of the data collected by Google and discussed in a presentation titled Last mile delivery: Alley Oop availability to 1P and 3P partners which appears to date from May 2022, demonstrated that Alley-oop vastly outperformed the alternative, with the top five apps promoted by Facebook experiencing conversion rates that were between 1.2 and 2.9 times higher when using Alley-oop.
5129 Let me deal with one other topic concerning statistics that Google sought to draw comfort from.
Obtaining apps off-Play, including sideloading an app — statistics
5130 Now Google pointed to the fact that from 2015 to 2018, it had compiled and published comparisons of the PHA rate on GMS devices that downloaded and installed apps from the Play Store only, and from the Play Store and other sources. The PHA rate on the latter was consistently higher.
5131 Further, Google says that the Google data analysed by its experts shows that GMS devices that have downloaded and installed apps from sources other than the Play Store are more likely to have a PHA than devices that only download and install apps from the Play Store or that have not downloaded apps from any source.
5132 It was found that from 2017 to 2020, devices that only used the Play Store had PHA rates of 0.08% to 0.12%, compared to PHA rates of 0.80% to 0.39% for devices that used other sources and the Play Store. And it was found that from 2017 to September 2022, in Australia devices that only installed apps from the Play Store were less likely to have a PHA than devices that had at least one app installed from off-Play.
5133 I will address the criticisms of some of this data and what has been sought to be drawn therefrom in a moment.
5134 Google says that a study relied on by Professor Traynor and Professor Somayaji, namely, P Kotzias et al, “How Did That Get In My Phone? Unwanted App Distribution on Android Devices” (2021) (Published at the 42nd IEEE Symposium on Security and Privacy, California) found that the Play Store installed more apps and more malware or potentially unwanted apps than other sources, but it had the lowest rate of installations of unwanted apps. As a proportion of all apps installed through the Play Store, only 0.6% were unwanted. In contrast, as a proportion of all apps installed using a web browser, 3.8% were unwanted. And, as a proportion of all apps installed from third-party app stores, 3.2% were unwanted.
5135 In general, Google says that the greater risk posed by sideloading an app justifies the requirement that OEMs configure GMS devices with an unknown source warning, and the permission-based approach to sideloading.
5136 Further, Google says that there is little doubt that obtaining apps off-Play, including by sideloading, involves a materially greater security risk than obtaining apps from the Play Store.
5137 Now Epic criticises Google for failing to bring forward more recent data concerning PHA rates on and off-Play, and invites me to draw an adverse inference. But Google says that no such inference should be drawn.
5138 Google says that it did produce more recent data for the purpose of this proceeding. It is plotted in Professor Asker’s report and covers the period until 30 September 2022. It shows that from 2017 to September 2022, in Australia, devices that only installed apps from the Play Store were less likely to have a PHA than devices that had at least one app installed from off-Play. But that data may under-represent the PHA rates on devices that had at least one app installed from off-Play.
5139 Now Epic says that the data that Google has produced shows a clear convergence in trends as between the relevant shares of Android devices with PHAs installed, but Google says that any apparent convergence is a product of the way data was being recorded by Google. The evidence shows that from 2020 there is a good chance that PHAs off-Play were undercounted. It would be unsafe to conclude that there was convergence in 2020 or that there is likely to be convergence today.
5140 Further, Mr Porst explained that as Google scans each application on the Play Store it has a very good baseline for how many apps are malware and how many are not. But for outside the Play Store, Mr Porst said that “we don’t do that. We scan as many apps as we can, but we don’t have as many human reviewers, so there’s a lot of … apps that we don’t review”.
5141 Mr Porst also said:
… that very much influences the statistics. And these statistics … are very much biased by how many applications outside of Google Play we review. The more we review, the more malware we find, and so we can – we can drive up that multiplier, and the less we review, the less malware we find, and we drive down the multiplier. … So I don’t accept the proposition of a linear change here. This … is an artefact of how we review applications, rather than of the … overall security. You can … use it as a starting point, but not as a scientific argument.
5142 Further, an 11 October 2019 internal document titled Temporary Removal of Off-market PHA Install Rate corroborates Mr Porst’s evidence.
5143 It records the decision to “no longer include the off-market malware install rate charts from Q1 2020”, explaining that
… off-market app review coverage has consistently not met the target rate (80%+) in the past 12 months due to resource constraints (i.e. we now have one reviewer for the off-market review queue as opposed to 4-5 reviewers in 2018), and we believe there might be some uncertainties associated with this set of metrics, potentially misleading information.
…
For instance, our app review coverage rate has been consistently maintained over 99% for Google Play. On the other hand, the off-market app review coverage rate has been consistently below 80% over the past 12 months. In other words, the downward trend … could mean that we are simply covering a smaller subset of the actual badness. This implies that the PHA rate in reality could be much higher than what we show. Given this, we are less confident about the PHA install rate metric as reported …
5144 Further, Professor Traynor when questioned about convergence explained that:
… security … is not a monotonic process. I don’t expect that just because it has come down means it’s always going to come down. It can go back up on either side.
5145 So, malware is not static. When anti-malware tools begin detecting and preventing a certain type of malware, malware rates could go down temporarily but then malware may adapt.
5146 Further, Epic criticises figure 6 in Professor Traynor’s report, saying that it should be given minimal weight. But Google says that for context, figure 6 compares the PHA rates on devices that obtained apps using off-Play sources and the Play Store, and devices that obtained apps using the Play Store only or that did not install any apps. The key differentiator between the two PHA data points is that one includes devices that install apps outside of the Play Store and the other does not, and the PHA rate on the latter is significantly lower.
5147 Now Google says that the overall picture that emerges is that, over time as a general matter, off-Play apps are riskier than the Play Store apps, as noted by Professor Traynor and accepted by Professor Somayaji.
5148 Now Epic says that many third-party app stores have low PHA rates, but Google says that there is no dispute that some third-party app stores have low PHA rates. Google says that this goes nowhere because the evidence including from Professor Somayaji shows that, more generally, downloading and installing apps from outside the Play Store is likely to lead to more malware, and Google has no oversight over those app stores and the apps they distribute.
5149 Now Epic says that apps from other preloaded privileged installers have much higher rates of malware than sideloaded apps, that is, than apps installed from unknown sources, but Google says that this point is a distraction and has no bearing on the purpose or effect of unknown source warnings.
5150 Further, Epic bases its submission on data referred to in a September 2018 presentation titled AP-PS: Unknown Sources. But Google says that the slide deck states that the number of devices installing a new app from a non-Play preloaded installer is undercounting. Accordingly, it says that the PHA rate for preloaded installers in that slide deck may be inflated.
Analysis
5151 Now Google has relied on certain statistics comparing PHA installation rates, and in particular the statistics in figure 6 of Professor Traynor’s first report. But in its developer documentation, Google defines PHAs as apps “that could put users, user data, or devices at risk” and notes that PHAs “are often generically referred to as malware”. But not all PHAs are malware or present a security risk to a user, as Epic points out.
5152 First, Mr Porst gave evidence that the word “potentially” in PHA denotes that malicious apps function differently depending on a number of variables, so an app that is harmful to one Android device might not pose a risk at all to another Android device.
5153 Second, both Mr Cunningham and Professor Traynor agreed that PHAs comprise apps that a user might desire and would not necessarily consider to be malware. In the September 2018 internal Google presentation titled AP-PS: Unknown Sources, which I have already referred to, it was indicated that more than 76% of the total PHAs installed from sideloading in the relevant period were “user-desired” for “[r]ooting-style apps”.
5154 So, the PHA statistics on which Google relies do not accurately represent the security risk posed to Android device users and their devices by sideloading, and convey an exaggerated picture of that risk.
5155 Now Professor Traynor used figure 6 to support his contention that distribution channels other than the Play Store are “similarly risky” to direct downloading, when considered at a device level. But as Epic says, figure 6 is unreliable and potentially apt to convey an exaggerated picture of the risk of sideloading, whether one talks of relative or absolute risk, including from third-party app stores. Epic made the following points with which I would agree.
5156 First, as Epic says, Professor Traynor labelled the figure “Share of GMS Devices with PHAs Installed”, and based the statistics that he presented on a Google internal spreadsheet. In that figure, Professor Traynor purported to represent the relevant shares by reference to “[d]evices that installed from the Google Play Store only” and “[d]evices that installed from sources other than the Google Play Store”.
5157 Professor Traynor mischaracterised the data on which he based figure 6. The category labelled “[d]evices that installed from sources other than the Google Play Store” includes devices that installed apps from the Play Store as well as from other sources. As such, some proportion of the PHAs installed on the devices in that category could have originated from the Play Store, yet figure 6 does not disclose that fact or the relevant proportion. Indeed, the underlying data is not broken down in a way that would reveal the relevant proportion.
5158 Second, as Epic says, the category labelled “[d]evices that installed from the Google Play Store only” includes devices that did not install any app at all. So, figure 6 is likely to under-represent the extent to which downloading from the Play Store gives rise to the risk of installing a PHA.
5159 The dataset underlying figure 6 was obtained on Professor Traynor’s instruction from the database of documents discovered in the Epic v Google proceeding in the United States, without any instructions from Google as to the meaning of that data. But the data in the database that Professor Traynor characterised as pertaining to “[d]evices that installed from the Google Play Store only” bore precisely the same label as data in a separate Google spreadsheet titled “Potentially Harmful Apps in United Kingdom”, which Mr Cunningham explained pertained to devices that installed from the Google Play Store only and devices that did not install any app at all.
5160 Further, the datafield glossary agreed between the parties defines the category “play_only_device” and its PHA subcategory, “play_only_device (PHA)”, in the spreadsheet underlying Professor Traynor’s figure 6 as referring in each case to “devices that have downloaded only from Google Play, or have not downloaded from any source”. The “play_only_device” and “play_only_device (PHA)” data variables form the basis for Professor Traynor’s calculation of PHA rates in respect of “[d]evices that installed from the Google Play Store only”.
5161 Third, as Epic says, the data underlying figure 6 ended in 2020. Nevertheless, Professor Traynor failed to request up-to-date data, despite his acceptance that more recent data would be important to his analysis.
5162 Professor Traynor sought to justify his failure to request more up-to-date data by reference to his reliance on unspecified statements in Google’s lay evidence that Google was not tracking off-Play installations after 2020.
5163 Professor Traynor ought to have made further inquiries. Mr Cunningham understood that Google had more up-to-date relevant data, which Google obtains from Google Play Protect. Indeed, Mr Cunningham’s affidavit, with which Professor Traynor was briefed, exhibited more recent data of that kind for the UK and Australia. Further, Mr Cunningham agreed that globalised data would likely have been available.
5164 Fourth, as Epic says, Google’s reliance on figure 6’s outdated data presents a difficulty when the data itself suggests a clear convergence in trends as between the relevant shares of Android devices with PHAs installed.
5165 Professor Traynor refused to accept the proposition evident on the face of figure 6, which was that the relevant trends were converging over the period from 2017 to 2020. That trend ought to have provoked Professor Traynor to request more recent data to ascertain whether the PHA rates were converging still more closely over time, or at least the reason for that apparent convergence.
5166 Google also relied on Mr Cunningham’s evidence that, in 2017, Android devices installing apps from outside the Play Store were “nine times more likely to be affected by PHAs”.
5167 Mr Cunningham agreed that this statistic involved a comparison with devices installing apps from the Play Store and also outside of the Play Store. Further, despite the availability of more recent data, and Mr Cunningham’s acknowledgement that more recent data shows a convergence in PHA rates, he nevertheless chose to refer in his evidence to data from 2017.
5168 Mr Cunningham’s statistic is defective in similar ways to figure 6 of Professor Traynor’s first report. It too should be given little weight.
5169 Further, and in any event, Mr Cunningham said on 4 June 2018 in an email to Ms Jenny Huang and others of Google that the same statistic:
… is not helpful when talking about specific stores (as any store can claim they are safer than Play, even if on average Play is safer than all other stores). And we actually have no idea how many stores are much safer than Play (or at least, we don’t have that data to hand).
5170 Further, I have given little weight to the contention by Google that there has been a more recent significant uptick in risk from off-Play sources. First, Google adduced that evidence through Professor Asker, who has no relevant expertise or direct knowledge on that topic. Second, and in any event, Professor Asker’s analysis showed an almost parallel “uptick” in PHA rates on the Play Store.
5171 Finally, as Epic correctly pointed out, many third-party app stores have low PHA rates.
5172 Professor Traynor agreed that third-party app stores can have low malware rates and, when taken to an undated internal Google document titled App stores in Android 12: Outlining a Possible Approach, he agreed with the statement that “[a]pp stores generally have relatively low malware install rates”. This included third-party app stores such as Café Bazaar and F-Droid, and the “Epic Store” with a “0%” malware install rate.
5173 Further, in a Google internal email chain on 9 May 2018, with reference to the safety of downloading Android apps from curated third-party app stores, Mr Kleidermacher said the following:
…
… 99.999% of malware is simply abuse of some form or another. And 99.999% of apps are not malware.
Now you go to 2,500 curated apps, and we’re really talking about something bordering on silly.
5174 Further, even if it be accepted that generally PHA installation rates are higher for installations outside the Play Store than from within the Play Store, the technical restrictions apply only to installations from non-privileged installers. Accordingly, as Epic says, it is essential also to consider data about PHA installation rates from privileged installers other than the Play Store.
5175 The evidence suggests that PHA rates are materially higher in respect of apps installed via OEM preloaded installers, which have privileged installation permissions, than is the case in respect of sideloaded apps. In his first report, Professor Traynor accepted that apps pre-installed by OEMs and carriers can also be a prominent source of PHAs.
5176 Further, the already identified Google document titled AP-PS: Unknown Sources shows that even after the introduction of the test requiring OEMs to apply to be allowed to preload installers with privileged installation permissions, Google viewed OEM preloads to be the primary source of malicious PHAs in August 2018.
5177 Mr Cunningham agreed that at the time, the PHA rate on devices that sideloaded was 5%, compared to 27% for devices that installed an app from a non-Play preloaded installer. As was stated in the presentation, the “most worrying source of malicious PHAs are OEM preloads – not unknown sources”, and, by contrast to sideloaded apps, the top PHAs from preloaded installers were “[m]ore malicious”, “[u]nwanted by users” and “[h]igher volume”. And he agreed that after removing “wanted” PHAs from the sideloading statistics, the actual PHA rate on devices that sideloaded was 1%.
5178 Accordingly, Google concluded that installing apps using a preloaded installer was 27 times more likely to result in the installation of a PHA than in the case of sideloading. Yet as Epic points out, the technical restrictions apply only in respect of the latter app distribution channel.
The technical restrictions — purpose of SLC
5179 Now I agree with Epic that the evidence makes clear that the technical restrictions result in a fairly ordinary experience to say the least when users are seeking to sideload Android apps, and download apps from app stores without privileged install permissions, with the consequence that they pose a significant impediment to the direct distribution of Android apps and rival app stores. This position was also fortified by the expert evidence before me in the field of behavioural economics; I have discussed this elsewhere in a separate section of my reasons.
5180 Moreover, the evidence is fairly clear that Google has long been aware that the unknown sources install flow is a painful experience, and one which presents a significant hurdle to successfully distributing Android apps via sideloading.
5181 But despite all of this, Google has done nothing to improve the unknown sources install flow, save for certain alterations that were made with the introduction of Android 12.
5182 Now Google has said that it imposes the technical restrictions for reasons of security. But I agree with Epic that the additional frictions are not proportionate to the risks posed by sideloading.
5183 But notwithstanding that observation, I do not agree with Epic that a purpose of Google of the technical restrictions is and always was to prevent or hinder the direct distribution of Android apps, including rival Android app stores and the subsequent download of apps from those stores.
5184 As Google points out, correctly in my view, Epic’s case on purpose ignores the documentary and affidavit evidence that shows that Google’s subjective purpose in introducing and maintaining the requirement that OEMs configure GMS devices with the unknown source warning and a screen where the user can grant the REQUEST_INSTALL_PACKAGES permission was security related.
5185 The unknown source warning and the unknown source setting screen have been constant features of the Android OS since its release in 2008. These features of the operating system were motivated by alerting users to the risks associated with sideloading, maintaining security on Android devices and maintaining trust in the Android OS.
5186 I agree with Google that it is problematic to assert that it sought to limit competition through these measures at the inception of the Android OS, when the operating system was small compared with rival operating systems and there was uncertainty as to its longevity.
5187 In 2017, with the release of Android 8, the REQUEST_INSTALL_PACKAGES permission changed from a global permission to a per source permission meaning.
5188 Until Android 8, once enabled, the permission applied to all unknown sources. Since Android 8, the permission needs to be enabled for each unknown source that a user wishes to use as an install source.
5189 Mr Cunningham, who worked on the change, explained that the purpose of the change included better security and control for users obtaining apps from unknown sources as they have the choice to grant permission on a per source basis at any time, rather than being required to adopt a one-size-fits-all setting. He said that this made it harder for an opportunistic “hostile downloader” to trick the user into inadvertently installing a malicious app. The user first needs to express an intention that they want to install apps from the particular source.
5190 Further, on 30 April 2017 in an internal email chain which concerned questions from Facebook about the change, Mr Cunningham provided the following response to the question “what is the reasoning behind the multiple prompts?”:
…
The user has to acknowledge explicitly, by means of granting a permission, that they want to be able to install APKs from a given source. They will continue to receive prompts for any attempt to open the Package Installer from sources that have not been granted this permission.
I imagine that Facebook’s question comes from a position of wondering that if the user has downloaded and installed Facebook from their website (using Chrome), why would the user see another prompt to enable ‘Install unknown apps’ when they subsequently try to install a newer version of the Facebook APK (downloaded by the installed Facebook app – eg. a self-update)?
Well the user has never acknowledged that they want Facebook to be able to prompt them to install APKs. Android will not allow Facebook (or any other app for that matter) to launch the Package Installer until they have been granted the ‘Install unknown apps’ permission. …
…
5191 Mr Cunningham, who had responsibility for sideloading on Android, gave evidence about the security related purpose of the unknown source warning. He said that the unknown source warning and setting flow serve an important security purpose to ensure that the user has a sufficient chance to acknowledge the significance of that decision.
5192 Mr Cunningham’s evidence was that the sideloading notification flow seeks to make clear the security consequence of installing apps from unknown sources and to give users pause, rather than to discourage users from downloading apps from unknown sources.
5193 Further, given that OEMs are able to change the language of the unknown source warning and the unknown source setting screen, this is some evidence that the warning and screen are not motivated by an anti-competitive purpose to deter competition to the Play Store. I agree with Google that if that was a genuine and substantial subjective purpose of Google, it is doubtful that Google would have relinquished control over the terms of the warning.
5194 Further, given that developers can take users directly to the unknown source setting screen, thereby avoiding a user encountering the unknown source warning, this is further evidence that the unknown source warning is not motivated by an anti-competitive purpose.
5195 Further, the matters relied on by Epic do not show the relevant anti-competitive purpose behind the technical restrictions.
5196 First, Epic refers to Ms Kochikar’s description in an internal email sent on 18 July 2018 of the sideloading flow for installing Fortnite as an “awful experience”. But that characterisation, and other negative comments about the flow, do not reveal an anti-competitive purpose.
5197 Ms Kochikar’s comment was made in the context of advocacy towards Epic in order to convince it to launch on the Play Store, and was in any event describing the particular install flow adopted by Epic for Fortnite.
5198 Second, in making the changes to Android 12, Google did consider their business impact and Epic’s litigation. As said by Mr Cunningham, “we were taking steps to make sideloading easier, and, as with lots of stuff we do, I’m sure there were some elements of strategy involved”.
5199 But the substantial purpose of those changes was to maintain security and improve the user experience of sideloading on Android OS. This is clear from the nature of the changes. A change was made so that the installation prompt appeared automatically on the device screen after a user had enabled the REQUEST_INSTALL_PACKAGES permission. Apps from non-preloaded sources were given the ability to update automatically, if they met certain security related criteria to enable auto-updates. These changes improved sideloading while maintaining security.
5200 Further, given that Mr Cunningham, who was security focused, was involved in discussions about changes to the sideloading flow, this would indicate that security considerations were a genuine concern in the relevant decisions.
5201 Further, the security related purpose of the changes is also apparent from the content of Google’s scoping document and a presentation. These documents indicate that the relevant changes were made in Android 12 to enable users to more easily use other app stores on their device without compromising security measures, and to make downloading and sideloading individual APKs easier without compromising on security.
5202 The scoping document was an undated document titled New Project Scope: App Stores in Android 12. It stated that “[t]he Android Product team is contemplating making user-journey-flow changes to enable users to more easily use other app stores on their device without compromising security measures Android has in place”. It also made clear that the security implications of any change had to be assessed.
5203 The presentation was a February 2021 presentation titled App Stores on Android 12. It stated that “Google has always allowed for 3P app stores on Android devices and have helped to guide users to make sound decisions in order to decrease malware risks...” and “[w]e are considering if there are easier ways to continue supporting users choice to use alternative app stores on Android devices without compromising on user security & safety”. It also identified the question “[d]oes this change increase or decrease the security of Android devices?” as one of the lenses through which the proposed change was assessed.
5204 Third, the internal document in which Google allegedly described itself as engaged in “an arms race to prevent sideloading” is a February 2019 document titled Web Platform Product Strategy. But I agree with Google that it should not be read as the strategy for Android OS, which is separate to Chrome.
5205 Finally, Epic relies on an email chain from April and May 2008, which refers to Google convincing T-Mobile that 90% of users would be prevented from sideloading by the unknown source warning. Epic takes this line out of context.
5206 This email reveals internal debate about the warning, including that, according to an email sent on 23 April 2008 by Mr Hiroshi Lockheimer, the warning was intended to give the user “a moment of pause”. According to an email sent on 24 April 2008 by Mr Nick Sears, the warning was intended to “protect naïve customers from hurting themselves”.
5207 T-Mobile, a mobile carrier, would have understandably been concerned about the security risks that its customers could be exposed to both with a new operating system being Android and by exploring the “black hole” that was unknown sources, which was facilitated by that operating system.
5208 In summary, the unknown source warning and the unknown source setting screen have a security purpose. No anti-competitive purpose has been established.
5209 Now in some sense the technical restrictions in effect are disproportionate to addressing the relevant security risks that actually exist or are perceived by Google. But to so find does not entail that they were put in place or perpetuated for an anti-competitive purpose. Further, even though they are or were disproportionate in effect, I am not prepared to infer therefrom an anti-competitive purpose.
The technical restrictions — effect of SLC
5210 Now Epic’s case is that the technical restrictions hinder the installation of rival app stores on Android devices by way of direct downloading, and disadvantage rival app stores that lack privileged installation permissions when seeking to compete with an app store that has such permissions.
5211 Epic says that the installation frictions which result from the technical restrictions result in an “awful experience”, cause users to “fall out” during the install flow, and pose a significant impediment to the direct distribution of Android apps and rival app stores.
5212 Overall, the technical restrictions mean that any rival app store which is wholly or partly reliant upon direct downloading to get itself installed on Android devices must overcome a very poor initial user experience and one that is apt to dissuade a large proportion of users from completing the installation process, such that they will never become users of the rival app store.
5213 Further, the technical restrictions operate at the very point of distribution. In other words, they hinder a rival app store’s ability to acquire new users before those users have even tried the rival’s product. Competition is thus prevented from working.
5214 There is no chance for a rival Android app store to impress new users with their offering and entice them away from the incumbent if the user gives up during the install flow, due to warnings about “unknown apps” and the “harm” they might do to the user’s device.
5215 In summary, Epic says that the technical restrictions have an effect or likely effect of substantially lessening competition. And it says that the counterfactual would or might involve informative and proportionate technical requirements.
5216 Now Epic says that there are various alternative arrangements that Google might adopt in place of the technical restrictions that would serve as minimum requirements for installation friction applied to sideloading.
5217 Epic says that it is technically feasible for Google to apply install frictions to downloads from non-privileged install sources that are more appropriately tailored and proportionate to security risks than the technical restrictions. I will elaborate on these in a moment.
5218 Further, Epic says that in the counterfactual, Google would not likely require OEMs that wish to distribute devices with GMS to comply with the technical restrictions as they currently stand or to impose installation frictions as severe as those currently imposed by the technical restrictions.
5219 It says that there is a real commercial likelihood that Google would set different minimum technical requirements which involve less friction than the current implementation of the unknown source install flow and are sufficiently informative and proportionate to the actual risks posed to users of Android devices.
5220 Now OEMs could choose to add additional warnings or steps beyond the different minimum technical requirements set by Google. But the evidence is that OEMs typically follow the minimum requirements set by Google.
5221 Mr Cunningham’s evidence was that OEMs do not generally change the default sideloading notification flow provided by Google, except for making cosmetic changes to their Settings app.
5222 Epic says that one can infer that this is so because Google is the de-facto leader in the Android ecosystem and it sets standards or best practices for security. Accordingly, most OEMs would likely follow the revised minimum technical requirements set by Google in the counterfactual.
5223 Further, Epic says that if technical restrictions impose frictions that are disproportionate to the risk, it is difficult to accept that any OEM, let alone all of them, would continue to deploy those restrictions if they did not have to do so.
5224 As for the idea that they would deploy them in a more severe fashion, Epic says that this makes no sense. If OEMs do not do so today, why, Epic poses the question, would they do so in the counterfactual?
5225 Accordingly, Epic says that there is at least a real commercial chance that in the future without the technical restrictions, rival app stores would be distributed to Android devices by direct downloading with materially less friction than currently. And it says that this would materially improve the distribution options available to rival Android app stores, which would be less dependent on pre-installation deals with OEMs. It would also enhance their ability to compete with the Play Store, by increasing their reach, and hence their attractiveness as a distribution service for developers.
5226 Now Ms Kochikar referred, if I might say so unsympathetically, to “the pain” of the unknown sources install flow as a reason why she did not believe developers would distribute apps outside the Play Store. But if that pain were to cease or reduce, Epic says that the likelihood of developers being prepared to distribute their apps outside the Play Store through rival app stores is likely to increase.
5227 And as to Professor Asker’s analysis of the download flow, Epic says that he mischaracterised the extent to which Google’s conduct is responsible for the technical restrictions and associated friction. Google dictates the steps involved in the sideloading process, including the requirement that users change their settings, which adds further steps to the process.
5228 Further, it says that Professor Asker ignored the cumulative effect of the browser warning in combination with the rest of the installation flow. The indiscriminate imposition of Google Chrome’s browser warning contributes to the install friction and forms part of the context in which the additional install friction imposed by the unknown sources install flow falls to be evaluated.
5229 Further, whether or not the particular messages were controlled by Google, Epic says that they still affect the likelihood of the user continuing with the download or not, in circumstances where none of the steps are required for the Play Store.
5230 Further, Epic says that Professor Asker ignored the fact that Google provides default language for the unknown sources warning and unknown sources setting screen and OEMs rarely modify the text.
5231 Further, Professor Asker emphasised that consumers do not encounter security warnings imposed by Google when sideloading the app store itself unless they have never sideloaded before using that web browser. He said that consumers do not encounter security warnings when installing an app from a sideloaded app store, except for the first and only time that they install an app from that app store.
5232 But Epic says that the fact that a user would not see subsequent warnings is irrelevant if the user is deterred from direct downloading on their first attempt. Moreover, a user encountering the steps in the direct download process for the first time may interpret those steps and warnings as a recommendation against future sideloading, whether or not they decide to go ahead with the particular download. Users may anticipate that the frictions will exist during subsequent direct downloads from the same source.
5233 Now Epic says that once it is appreciated that the technical restrictions impose unnecessary and disproportionate friction that may in fact be detrimental to Android security, and that there is a real commercial likelihood that Google would set different minimum technical requirements for the direct download flow in the counterfactual, which are sufficiently informative and proportionate to the actual risks posed to users of Android devices, any pro-competitive justifications for the technical restrictions fall away.
5234 Epic says that the technical restrictions cannot be said to be necessary to mitigate negative security externalities in circumstances where a world without the technical restrictions would involve Google imposing minimum technical requirements which adequately respond to the actual risks posed to users of Android devices.
5235 Let me now say something about the counterfactual and whether it would or might involve commercially realistic alternative security measures.
5236 Epic says that there are various alternative technical measures that Google could implement which would in fact improve the security of Android devices. So, the technical restrictions are unnecessary for protecting users against malicious or unsafe files.
5237 Epic made two points. First, the availability of these alternatives supports Epic’s case that the current measures are disproportionate to addressing the security risk. Second, these alternatives are relevant to considering the counterfactual question.
5238 It says that Professor Somayaji proposed that in place of the severe installation frictions caused by the technical restrictions, Google could extend [REDACTED] malware detection capability platform-wide and also let Android device users know, at install time, whether a directly downloaded app has or has not been scanned by [REDACTED] and thereby provide the user with proportionate, and app-specific, warnings and prompts.
5239 Now as to extending [REDACTED] malware detection capability platform-wide, Epic says that it is already the case that Google scans each and every app that is submitted for publication on the Play Store with [REDACTED] It is also already the case that Google scans each and every Android app that is uploaded, by the public, to the virustotal.com website.
5240 It says that it would be technically feasible for Google to implement a mechanism that would permit developers, and the operators of third-party app stores, to upload apps, app updates, and associated developer metadata, to [REDACTED]to scan an app prior to its distribution via channels other than the Play Store. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
5241 It says that Mr Porst accepted that ultimately it is a commercial decision for Google as to whether it expands the analytical power of [REDACTED] beyond scanning only on-Play apps and apps that it presently obtains from various other channels.
5242 Further, it says that in the past Google has proposed implementing substantially equivalent technical mechanisms. Further, that evidence establishes that Google perceives that implementing such mechanisms would promote security on Android.
5243 Epic says that according to an undated document titled 3rd Party Web App Scanning Service – PRD, based on a review undertaken in the course of 2015 to 2016 by an anti-malware team at Google, senior figures working on Android security at Google prepared a proposal to “offer our scanning services to vetted partners and devs”. The proposal was identified as having “[b]enefits to the Android Ecosystem” as well as “[b]enefits to Android”.
5244 As to the former, one of the identified benefits was as follows:
It allows 3rd parties to leverage Android Security’s vast malware intelligence graph, without forcing them to distribute their apps through the Play Store. However, by submitting the apps to [REDACTED], all users will benefit from a similar vetting process to Play users
5245 The caveat in the second sentence was elaborated in a section of the document titled “Security Considerations and Risks”, where one of the identified risks was “[w]e could improve the state of non-Play stores to such an extent that they are just as good as Play”.
5246 Epic says that each of the other identified security risks associated with the proposal was matched with an identified means of mitigation.
5247 Similarly, it says that according to a document first created on 12 December 2018 titled WhistlePig: Cloud-based App Scanning & Threat Sharing Service, there was a project in late 2018 called “Whistlepig”, which involved [REDACTED] performing scans of off-Play Store apps, with the aim of [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED][REDACTED][REDACTED][REDACTED][REDACTED][REDACTED] Mr Porst stated that [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
5248 Epic says that the reason why Google has not previously implemented a technical measure of the kind described above is suggested in an email chain in August 2017 between Google employees with responsibility for Android security.
5249 In that email, sent on 24 August 2017, Mr Ludwig said that “[m]y recollection is that the primary concern raised in the past is that Google’s investment in security of Google Play is part of the competitive advantage that Play has relative to other 3rd party stores.”
5250 But Mr Ludwig and Mr Woloz also identified that Google could meet that concern by charging third-party app stores and others for access to [REDACTED], which would offset the concern about the competitive advantage that [REDACTED] confers on the Play Store, “while also improving Android security”.
5251 Epic says that consistent with Mr Ludwig’s view as to the positive security outcomes of such a measure, Mr Porst agreed that improved security would come from permitting developers to upload their apps to [REDACTED] prior to distribution.
5252 Let me say something about the configuration of GPP to provide app-specific install friction.
5253 Epic says that it would be technically feasible for Google to apply, via GPP, warnings and frictions based on its knowledge of whether an app has been previously scanned by [REDACTED] and whether [REDACTED] or GPP has identified that the app contains malware. It would also be technically feasible for GPP to apply installation frictions that are appropriately tailored and proportionate to the security risks involved in installing a particular app.
5254 Moreover, it says that configuring GPP in that way would improve security on Android devices. Such a system could improve security, depending on how the information was conveyed to the user. GMS Android security would be improved by a system of informing a user as to what, if any, scanning had been performed on an app and the status of that app.
5255 Further, it says that if Google implemented alternative technical measures of the kind discussed, there would also be indirect improvements to the security of Android devices.
5256 Epic says that absent Google’s imposition of the technical restrictions, third-party app stores could be incentivised to compete with each other and Google on non-price metrics, such as security and user privacy. Such a possibility is demonstrated by the security record of third-party app stores that are available for direct download on Android today but which cannot effectively compete with Google as a result of its anti-competitive conduct. Third parties could perform more rigorous developer vetting than that currently undertaken by Google for apps distributed via the Play Store. Vetting by third parties that specialise in a particular genre of apps would be advantageous.
5257 Further, Epic says that even if, absent Google’s technical restrictions, some third-party app stores were to distribute malware, the overall security of the GMS Android ecosystem would not be degraded in circumstances where, regardless of the source from which an app is installed, GPP were configured by Google to impose install frictions that are appropriately tailored and proportionate to the security risks involved in installing a particular app.
5258 Moreover, Epic says that GPP has and would retain the technical capability of remotely uninstalling, and thereby neutralising the risk of, any malicious apps downloaded from a third-party app store of which [REDACTED] is or becomes aware. And Google might also remove any malicious apps after they have been distributed, including by third-party app stores or apps downloaded from those stores, by rescinding their cryptographic certificates.
5259 Further, Epic says that Google has the technical ability to make changes to the default implementation of GMS Android and thereby adjust the steps, language and presentation of the unknown source install flow.
5260 Epic referred to the prospect of different text in the unknown source install flow and made the following points.
5261 Internal notes in relation to a meeting between Google and Facebook in a 19 May 2017 document titled Facebook noted concerns raised by Facebook about the install flow inhibiting users from sideloading or updating their app.
5262 In relation to those concerns, Google considered ways to soften the language in certain of the installation dialogues. In cross-examination, Mr Cunningham was taken to a comment bubble in that document that suggested the language of the unknown source warning could be changed to “[f]or your security, your phone needs your permission to install apps from this source.”
5263 Epic says that Mr Cunningham resisted commenting on its accuracy compared to the current formulation and that all he could offer was to agree that it contained words the user was likely to know, and that it was shorter and easy to read. Although claiming that it was hard for him to say whether it was clearer than the existing default text, he did not suggest that there would be any adverse security outcomes if the default text were modified in the manner that was proposed in the document.
5264 Further, Epic referred to a Google presentation titled App Stores in Android 12: 24 March 2020 review, which was authored by Mr Cunningham, shows Google further considering the simplification of the default language in the unknown source warning by removing the term “unknown apps”. The proposed text read “[f]or your security, your phone currently isn’t allowed to install apps from Chrome. You can change this in Settings”. Mr Cunningham agreed that whilst not ultimately implemented in Android, he could have drafted this proposal because he considered the term “unknown app” potentially confusing to users.
5265 Let me turn to Epic’s position concerning the question of a one-tap install flow.
5266 Clearly, as Epic says, Google considered a proposal to collapse the unknown source warning and setting screen into a single prompt. Changes were proposed in response to feedback from developers on how Google could make the user experience for installing another app store on their device even better. Mr Cunningham accepted that the developers in question likely included Epic, and that the proposed changes may have been in response to the proceeding commenced by Epic against Google in the United States.
5267 As Epic says, there was a proposal put forward by Mr Cunningham to merge the existing unknown source warning and unknown source setting screen into a “1 tap” flow. When cross-examined on it, Mr Cunningham agreed with the following propositions, as Epic says.
5268 First, it would be technically possible to configure Android so that the user could confer an installation permission with one tap, and that this was a straightforward flow, and alternatively the toggle could be placed on the unknown source warning.
5269 Second, the implementation would be very straightforward from a usability perspective.
5270 Third, the proposal would mirror a pattern that exists for some other permissions in Android with which users are familiar.
5271 Further, Mr Porst agreed that, while he was unaware of any relevant study within Google, he thought it was possible that there would be no adverse effect if the three instances of friction imposed by the unknown source warning, unknown source setting screen and the installation confirmation were instead collapsed into one step.
5272 Moreover, in particular versions of Android and in particular circumstances, Google has already imposed a “one-tap” style of unknown source prompt.
5273 In Android 8.0 and higher, Google replaced the global unknown sources setting with a per-source unknown source setting. That change was made in 2017. The consequence of the change is that users of Android devices running Android 7.x or lower are able to enable unknown sources globally.
5274 Finally, let me turn to Epic’s position concerning the Android brand gating proposal.
5275 As Epic says, internal Google documents indicate that it had also considered proposals for alternative forms of installation friction that would put approved and trusted developers who directly distribute their apps on an equivalent footing, with respect to installation friction, as privileged installers.
5276 In a 29 June 2018 email from Mr Kleidermacher, a senior Google executive with responsibility for security on, inter-alia, Android and the Play Store, set out his proposal for “Android Brand Gating” – a system that would permit “top gamer developers” like Epic to offer their apps via direct download from websites authorised with Google.
5277 As Epic says, although the proposal was never implemented, Ms Kochikar and Mr Porst both agreed that Mr Kleidermacher considered the proposal to be technically feasible, and Mr Porst himself also considered it technically feasible.
5278 Epic says that despite having the technical means to verify and authorise trusted developers to directly distribute apps, Google nevertheless continues to cause the installation frictions associated with the unknown source install flow to be imposed uniformly on any sideloaded app.
5279 Let me address one other topic concerning the AFAs and the ACCs.
5280 Now Epic does not contend that all of the compatibility standards imposed on OEMs via the AFAs and ACCs are anti-competitive and unlawful.
5281 Epic impugns a single aspect of the compatibility standards, namely, that aspect which forms part of the technical restrictions. Epic otherwise relies on the AFAs and ACCs as elements of Google’s power in the mobile OS licensing market.
5282 So, Epic does not suggest that the entire AFAs/ACCs should or would fall away in the future without the impugned conduct. Rather, the AFAs/ACCs and the incorporated CDD would continue, except insofar as they contain requirements imposing the technical restrictions.
5283 Now Professor Asker’s analysis was based on the premise that the AFAs and ACCs are necessary so that Google can address the coordinated adoption problem, prevent device fragmentation and ensure a consistent out of the box experience.
5284 But Epic says that other than in respect of the technical restrictions, there would be no change to the AFAs or ACCs in the counterfactual. Accordingly there would be no difference in Google’s ability to address device fragmentation, any coordinated adoption problem or to ensure a consistent out of the box experience.
Analysis
5285 Epic’s case is that the real-world impact of the technical restrictions show that they hinder the installation of rival app stores on GMS devices by way of direct downloading and disadvantage rival app stores without a privileged installation permission.
5286 Epic says that 20% of users abandon installation during the sideloading flow. But even if correct, there is no evidence that the technical restrictions cause users to abandon installation, nor is there evidence about the extent to which any drop-off can be attributed to the technical restrictions. There are many reasons that a user might not complete an installation. I agree with Google that some might be related to the unknown source warnings, some might not.
5287 So, in August 2019, 75% of sideloaded installations of Fortnite were successful. But as Google says, that is not to say that the remaining 25% of people were dissuaded from sideloading Fortnite because of the unknown source warning, the unknown source setting screen or the installation prompt. People may have discontinued for reasons unrelated to these steps, for example, because they changed their mind or became distracted, or because the internet dropped out. One does not know how many people discontinued for reasons unrelated to sideloading, or for reasons related to sideloading.
5288 Further, even if 25% of people discontinued an installation because of the unknown source warning, the unknown source setting screen or the installation prompt, and even if these steps are disproportionate to the security risk associated with sideloading, some users would legitimately not wish to take the sideloading risk given an appropriate warning.
5289 So as Google points out, the real question is what proportion of the 25% was the result of any excessiveness in the sideloading steps? No one has sought to answer such a question.
5290 Further, Epic has measured the real-world impact of the unknown source warning by reference to the proportion of devices that sideloaded an app. But the data that Epic refers to does not show that users have not sideloaded an app because of the sideloading steps. As Google says, there are many reasons unrelated to those steps as to why a user may have decided not to sideload. It could be easier for them to download and install an app from a preloaded app store like the Play Store, which has millions of apps conveniently in one place.
5291 If anything, the data relied on by Epic and other data shows that users were not inhibited from sideloading by the unknown source warnings and associated steps.
5292 So, from July 2021 to mid-June 2022, the majority of Android devices worldwide had enabled the REQUEST_INSTALL_PACKAGES permission. In Australia, 20% to 30% of Android devices in Australia had enabled this permission. Clearly there is a willingness on the part of consumers to permit unknown sources to install apps.
5293 Professor Asker said that the numbers were notable, considering that the choice the user is making is about whether or not to use comprehensive app stores, like the Play Store and the Samsung Galaxy Store. But even then, 20 to 30% of users still find it worthwhile to go through and turn off the permissions.
5294 Now Epic says that the pain of unknown sources deter developers from distributing apps by direct downloading. But as Google says, developers already distribute apps by way of direct downloading. Six of the top 50 apps by consumer spending in Australia in 2021 were offered by means of direct downloading from the developer’s website. Other major non-gaming apps are also available from a developer’s website. Epic itself is launching an online app store to be directly downloaded from the web.
5295 I agree with Google that Epic has not established that the existing sideloading flow has such a disproportionate chilling effect on sideloading on GMS devices so as to amount to a substantial lessening of competition.
5296 Let me now say something more concerning the counterfactual. Epic says that its counterfactual without the technical restrictions involves minimum technical requirements set by Google. So, those minimum technical requirements are assumed to involve less friction than the current implementation of the unknown source install flow and be sufficiently informative and proportionate to the actual risks posed by users of Android devices. Epic says that Google could adopt various alternative arrangements in place of the technical restrictions that would serve as minimum requirements for installation friction applied to sideloading.
5297 In my view and largely for the reasons that Google has given, Epic’s claim regarding the technical restrictions fails for the following reasons.
5298 First, as Google says, Epic assumes that any alternative minimum technical requirements would be more appropriately tailored and proportionate to security risks than the technical restrictions. But Epic does not identify the minimum technical requirements that it proposes to impose on OEMs but just raises some possibilities. Moreover, as Googe has said, Epic has not established that any of them have a commercially realistic chance of being adopted by Google.
5299 Second, I agree with Google that Epic has not addressed how competition would be different in a future without the technical restrictions. Nor has it sought to prove, or proved, that there is or at any relevant time was a real commercial likelihood of any greater competition absent the technical restrictions but with some other proposed minimum technical requirements, such that one could conclude that the technical restrictions had the effect or likely effect of lessening competition in a manner meaningful or relevant to the competitive process.
5300 Third, it has been put that absent the technical restrictions, OEMs could decide whether to provide warnings to Android smart mobile device users, the precise nature of any warnings, and the steps that these users must go through before downloading apps. But as Google says, the possibility of OEM choice does not establish that there is a commercially realistic chance that OEMs would exercise that choice in a way that would substantially increase competition relative to the status quo. Moreover, strictly, the possibility of OEMs making a different choice does not of itself amount to any different level of competition. That would only occur if OEMs made a different choice or there was a credible risk of them doing so.
5301 Fourth, as Google points out, Epic assumes that OEMs would likely follow the alternative minimum technical requirements because they do not generally change the default sideloading notification flow provided by Google. But when faced with a choice, as Google says, OEMs would likely configure devices in a way that is not dissimilar to the current default sideloading flow for GMS devices and add warnings to that flow, rather than exercise a different choice.
5302 I agree with Google that OEMs have no obvious incentive to make their devices more susceptible to malware by removing unknown source warnings, the unknown source setting screen and installation prompts.
5303 Samsung, which manufactures most GMS devices in Australia, has made its intention clear in this respect. As Google points out, Samsung has published two blog posts, recognising the dangers of sideloading and it has advertised that Samsung devices already block sideloaded apps.
5304 Further, there is evidence that OEMs add additional warnings and steps to the sideloading flow required for GMS devices. Xiaomi, which manufactures GMS devices, has modified the unknown source setting screen by adding an additional warning screen. There is no reason to doubt that Xiaomi would likely continue to do this in a counterfactual. Other OEMs may also add warnings and steps similar to the technical restrictions to their devices, even if not mandated by Google.
5305 Further, as Google points out, OEMs that do not manufacture GMS devices, and are therefore not subject to the technical requirements, use unknown source warnings, the unknown source setting screen and installation prompts of their own volition.
5306 And I agree with Google that there is no evidence to suggest that they or indeed any other OEM would display different warnings and provide for different steps in a but for world.
5307 Further, Mr Cunningham said that OEMs do not generally change the default flow. But the default flow that he was referring to was the one currently required for GMS devices by Google and the subject of Epic’s claim. This evidence does not say anything about whether OEMs would configure devices with unknown source warnings, unknown source setting screens and installation prompts, if given a choice.
5308 Finally, I agree with Google that consideration of OEM behaviour in the counterfactual is relevant because OEMs are the entities that would execute any alternative minimum technical requirements and any additional specifications that they consider appropriate.
5309 The evidence shows that, having regard to their behaviour and incentives, the world with and without the technical restrictions is likely to be substantially the same. At the least, as Google says, Epic has not established that there is likely to be a relevant difference.
5310 Let me turn to another topic. Epic has set out various alternative arrangements that Google might adopt in place of the technical restrictions that would serve as minimum requirements for installation friction applied to sideloading. The alternative arrangements involve the incurring of unspecified additional cost, which has not been modelled or assessed by Epic, as Google points out.
5311 Further, I agree with Google that Epic has not established that they involve less friction or that they are more appropriately tailored and proportionate to security risks than the technical restrictions.
5312 Now Epic says that all off-Play apps, including apps distributed by third party app stores, should receive a full scan by Google’s backend scanning and review infrastructure before distribution.
5313 But, as Google says, there are a number of problems with this proposal. Google has made the following points which I agree with.
5314 First, there are resource limitations, particularly where the number of new apps and app updates is nearly limitless.
5315 Google’s backend scanning and review process [REDACTED] [REDACTED] [REDACTED] [REDACTED]. If Epic’s proposal to scan all apps was implemented [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
5316 Second, as Google says, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]
5317 Third, off-Play apps that are updated would need to be resubmitted for review each time a new update is released. As Google says, Epic has not explained how its proposal of Google scanning all apps would accommodate this. Even if all updates were scanned by [REDACTED] there would be no way for users to know whether they are sideloading the most recent version of an app, which may give them a false sense of security when in fact they could be installing a superseded version of the app that had vulnerabilities which the update was designed to patch.
5318 Fourth, there is a [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] I agree with Google that Epic’s proposal does not provide any evidence on how it proposes to address the absence of such an advantage.
5319 Fifth, as Google says, Epic does not address the practicalities of requiring Google to scan all apps. This would require the cooperation of all developers and all third party app stores. Third party app stores would be required to provide information about apps and developers to Google, which could raise privacy concerns. It would also require third parties and app developers to agree with Google’s assessment of an app, which they may not.
5320 Sixth, as Google says, the automated scanning of apps is only one security measure. As the evidence reveals, app scanning is not a perfect protection against malware. It is capable of identifying whether an app is malware but not positively that an app is not malware. Further, malware scanning is good at detecting threats similar to ones previously encountered but unreliable at detecting new threats.
5321 Seventh, Epic says that Google has proposed implementing this mechanism in the past. But as Google has said, Epic has overlooked aspects of the papers containing the alleged proposals, including that the undated document titled “3rd Party Web App Scanning Service – PRD”, based on a review undertaken in the course of 2015 to 2016 by an anti-malware team at Google, envisaged an invitation-only system, with preference given to developers with their own security teams and potentially raising “competition law issues”.
5322 Let me turn to another topic concerning the configuration of GPP to provide app-specific install friction. Epic says that GPP could be used to apply warnings and frictions based on its knowledge of whether an app has been previously scanned by [REDACTED] and whether [REDACTED] or GPP has identified that the app contains malware.
5323 Now in one sense, as Google says, Epic appears to be proposing that Google implement something like the legacy scan and the real time scan, which already exist and provide an important layer of protection for GMS devices. But they are not sufficient on their own to keep users safe. As Google described it, the legacy scan and the real time scan are last-ditch efforts to protect users after other layers of security protections have failed. If malware developers get past other layers of security, GPP might be the last means of defence. But the legacy scan and the real time scan have limitations.
5324 Moreover, the legacy scan and the real time scan serve a different role to the so-called technical restrictions. Asking the user whether they want to allow an app to install other apps through the unknown source warning and the unknown source setting screen is a useful question. The user may not wish a particular app to install other apps, and the unknown source warning and unknown source setting enable a user to stop that from happening. As Google says, removing those steps removes the ability of the user to stop apps from acting as an install source.
5325 Further, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] As it points out, to distribute an app off-Play, a developer does not need to register with Google or provide Google with any other information.
One-tap install flow
5326 Now Epic suggested that the sideloading flow, namely, the unknown source warning, the granting of the REQUEST_INSTALL_PACKAGES permission in the Settings app and the installation prompt, could be reduced to one step.
5327 But I agree with Google that this suggestion is problematic because it collapses two different decisions about two different apps, being, first, granting permission to an app to act as an install source and, second, confirming the installation of another app, into one.
5328 The suggestion was rejected as unsatisfactory by Mr Porst, Mr Cunningham and Professor Traynor. I agree with the following summary of the evidence given by Google.
5329 Mr Porst explained that the collapse of multiple steps into one step would likely increase risk because it gives users less of a chance to reconsider what is going on and to follow Google’s warnings.
5330 Mr Cunningham said that the removal of the installation screen would carry a significant security risk because in the absence of an explicit confirmation about the app being installed, the user would have no opportunity of being told by the operating system which app specifically they were actually installing.
5331 Professor Traynor explained that having the user reason about different parts of what may happen is important because the user is being asked to make a couple of security decisions and it is important to make sure that one actually captures their intended actions in respect of each of those decisions.
5332 Further, as Google said, a single dialogue box that pops up to capture a user’s permission to install other apps would not capture that consent as well as the unknown source warning and the unknown source setting screen.
Brandgating
5333 Epic made the point that Google has considered proposals for alternative forms of installation friction that would put approved and trusted developers who directly distribute their apps on an equivalent footing, with respect to installation, to privileged installers. This argument is based on an email sent on 29 June 2018 from Android’s Head of Security, Mr David Kleidermacher, in which he raised the idea of “Android Brand Gating”. It is said that this indicates that the unknown source warning is unnecessary.
5334 Now Mr Kleidermacher’s idea was that top game developers would specify authorised download sources, for example, the Play Store or the Amazon Appstore. To do so, the developer would need to be on the Play Store because they would action this from the “Play dev console”, that is, the Google Play Console. But the email contained no assessment of the idea’s feasibility, and it appeared to be largely an undeveloped idea.
5335 But even if Mr Kleidermacher’s idea were technically feasible, it did not contemplate a removal of sideloading friction for “trusted” sources. As Google says, Mr Kleidermacher’s email does not suggest that sideloading the authorised version of the app would not be subject to the unknown sources installation flow.
5336 In summary, in my view Epic’s case on the relevant counterfactual is flimsy in the sense that in the counterfactual world most of the relevant technical restrictions are likely to exist in some shape or form in any event.
5337 Now Epic says that the technical restrictions would be replaced by other minimum technical requirements set by Google. But I agree with Google that Epic has not clearly identified what these minimum requirements would be.
5338 Further, as Google says, Epic has provided no analysis of what effect any alternative minimum requirements would have on sideloading, or why they would have any meaningfully different impact on competition.
5339 In any event, I tend to agree with Google that any change to the technical restrictions by removing them and introducing new minimum requirements for OEMs is not likely to lead to any change in behaviour by OEMs because OEMs could still configure their devices in a way that is not dissimilar to the technical restrictions. And as Google says, OEMs would have no interest in not doing so.
5340 So, Epic has not established that if the technical restrictions were removed and if some other minimum restrictions were introduced, as is proposed in Epic’s counterfactual, OEMs would take a materially different approach from those in the technical restrictions.
5341 In summary, in terms of the technical restrictions relating to install flows and frictions, I have concluded the following.
5342 First, in my view such technical restrictions caused or imposed by Google are disproportionate to the security risks that Google has sought to protect against.
5343 Second and notwithstanding the first point, in my view such technical restrictions were not imposed by Google or sought to be maintained by Google for the purpose of substantially lessening competition.
5344 Third, such restrictions do not separately have any actual or likely effect of substantially lessening competition.
5345 Fourth, I have also considered these restrictions in combination with other restrictive conduct that Epic has alleged. But in my view no anti-competitive purpose or effect has been shown by the combination.
5346 Fifth, although I have found no statutory contravention concerning the technical restrictions, the fact is that they and their consequences exist and are part of the relevant factual matrix that I have taken into account in assessing other impugned conduct and its consequences.
Epic’s s 46 case – Android in-app payment solutions
5347 In this introductory section it is convenient to lay out in some detail the elements of Epic’s case before I turn to the relevant contracts and the precise mechanisms.
5348 Epic’s case is that there is an Android in-app payment solutions market, which is a market for the supply of services to app developers for the facilitation of payments for the purchase of digital content within Android apps.
5349 Epic says that through clause 4.1 of the DDA and the payments policy, Google imposes the payments tie, namely, it requires app developers that sell digital content in apps downloaded from the Play Store to use Google Play Billing as their payment solution for all in-app purchases of digital content within those apps.
5350 But Epic says that Google’s payments tie does not dictate that a service for facilitating in-app payments is not a separate product from app distribution services. From an economic perspective, two products are distinct if it is technically feasible for them to be supplied separately, and in the absence of tying, there would be distinct demands for each of them, as customers are prepared to acquire each product without the other attached.
5351 Epic has also made the following points.
5352 Google Play Billing can be, and is, provided separately from Android app distribution services. The following may be noted.
5353 Google Play Billing is not available in 15 countries where the Play Store operates. In those countries, app developers can and do distribute apps through the Play Store but use a payment solution other than Google Play Billing.
5354 Until about 2021, when Google amended its payments policy to prevent it, at least 90 different developers distributed apps through the Play Store using a payment solution other than Google Play Billing for in-app purchases of digital content.
5355 Under the UCB and DOB programs, developers are permitted to use a payment solution for in-app purchases other than Google Play Billing, and various developers have sought to do so.
5356 Between November 2021 and October 2022, approximately 103 app developers in South Korea sought to integrate an alternative payment solution into their apps.
5357 Between September 2022 and October 2022, approximately 19 developers of non-gaming apps sought to integrate an alternative payment solution into their apps, pursuant to the UCB pilot program.
5358 And between 19 July 2022 and October 2022, 29 app developers applied to Google to use a payment solution other than Google Play Billing, pursuant to the DOB program.
5359 Various other developers of Android apps have sought to use, or expressed interest in using, a payment solution for in-app purchases of digital content other than Google Play Billing, including Epic, Parship Group and customers of Paddle.
5360 App developers who sell non-digital content within Play Store apps do not use Google Play Billing. Instead, they acquire payment solutions from third parties separately from the distribution services supplied by Google.
5361 For these reasons, Epic says that it is appropriate to treat services for the facilitation of in-app payments as a distinct product.
5362 The next question that arises is whether there are close substitutes to Google Play Billing for the supply of services to app developers for facilitating in-app payments for digital content within Android apps.
5363 Out-of-app payment solutions connote at least two requirements, namely, a requirement for the developer to build or acquire a solution that facilitates out-of-app payments, and a further requirement for the user to leave the app to effect a purchase elsewhere, for example, on a website using an out-of-app solution which the developer has built or acquired.
5364 Epic says that out-of-app payment solutions are not a viable substitute for Google Play Billing for the following reasons.
5365 First, Google’s anti-steering rule prohibits apps from “leading users to other payment methods”. The result is that developers cannot create links to out-of-app payment solutions within their Play Store apps or even tell their users about the out-of-app solution via in-app promotions or user-interface flows. Rather, out-of-app payment solutions can only be implemented separately from the app. Very few developers have taken this option.
5366 Second, developers would not substitute in-app payment solutions with out-of-app solutions because the latter are a worse experience for users, who are more likely to complete the transaction within the app than if they must exit the app. Leaving the app can be disruptive to users, takes more time, and is often frustrating. App developers will prefer the payment solution that leads to more, not fewer, completed purchases.
5367 Further, Epic’s case is that the geographic dimension of the Android in-app payment solutions market includes at least Australia and is likely global, excluding China and possibly other territories where competitive conditions began to differ towards the end of the relevant period.
5368 It is convenient to say now that I have substantially accepted Epic’s market definition over Google’s protestations to the contrary. I will discuss this in much more detail later.
5369 Now Epic says that Google has a substantial degree of power in the Android in-app payment solutions market. It has made the following points.
5370 If the market is confined to payment solutions for in-app purchases within Play Store apps, then Google is a virtual monopolist.
5371 The in-app payment solutions restrictive conduct means that Google Play Billing is the only payment solution permitted for facilitating payments for in-app purchases of digital content within Play Store apps, save for apps distributed in the 15 countries where Google Play Billing is not offered, and apps that take advantage of the UCB or DOB programs. The take up of those programs has been relatively low.
5372 The in-app payment solutions restrictive conduct also prevents new entry by competing payment solution providers. The barriers to entry with the conduct are insurmountable outside of the limited exceptions and app developers have no effective countervailing power.
5373 Even within the exceptions, the scope for competitive constraint is very limited.
5374 Under the UCB program, developers must still offer Google Play Billing alongside an alternative, and, save in South Korea, developers are not allowed to quote a lower price for using the alternative solution.
5375 Further, the DOB and the UCB pilot programs are only available to “non-gaming” app developers, and the UCB pilot program precludes app developers from using a payment solution provider that operates as a “merchant of record”.
5376 Alternative providers are thereby precluded from competing with Google Play Billing on equal terms, given that Google does act as merchant of record.
5377 If the market also includes payment solutions for in-app purchases of digital content within Android apps more generally, the conclusion is the same.
5378 The Play Store accounts for 98% of new app downloads from Android app stores in Australia and 91% of such downloads globally, and Google Play Billing is the payment solution for almost all in-app purchases of digital content that occur in those apps.
5379 It is convenient to say now that I have substantially accepted Epic’s market power arguments.
5380 Further, Epic says that a purpose of the in-app payment solutions restrictive conduct has been to substantially lessen competition in that market.
5381 It is said that Google’s anti-competitive purpose ought to be inferred from the in-app payment solutions restrictive conduct itself.
5382 Epic says that, notably, even when Google has been forced to allow developers to offer alternatives to Google Play Billing, it has done so in ways that force developers to continue offering Google Play Billing whether they want to or not, that disincentivise the use of any alternative solution, or that prohibit developers charging their customers a lower price for the alternative.
5383 Epic says that none of this is aimed at protecting user security or privacy. It is aimed at hindering competition and maximising Google’s profits.
5384 Further, it says that Google’s internal business records demonstrate that a substantial purpose of the in-app payment solutions restrictive conduct was to prevent or hinder competition.
5385 It is convenient to say now that I have rejected this aspect of Epic’s case. Let me turn to the effect or likely effect of Google’s conduct.
5386 As to the state of competition in this market with Google’s conduct, Epic says that there is next to no competition at all. Epic makes the following points.
5387 Epic says that in the counterfactual, without the in-app payment solutions restrictive conduct, Google Play Billing would be likely to face significant competition.
5388 There would be demand from app developers for Android payment solutions other than Google Play Billing, just as there was in the past and is currently.
5389 There would also be suppliers with the incentive and ability to meet that demand. Several providers already supply payment solutions for in-app purchases of physical goods within Android apps. It would not be difficult for these providers to supply an in-app payment solution for purchases of digital content within Play Store apps. As a result, one would expect entry by those suppliers into the market if Google’s in-app payment solutions restrictive conduct ceased.
5390 At least one payment solution provider, namely, Paddle, has already expressed a desire to enter the market and compete with Google Play Billing.
5391 For these reasons, Epic says that the in-app payment solutions restrictive conduct has the effect, or likely effect, of substantially lessening competition in the Android in-app payment solutions market.
5392 It is convenient to say now that I have accepted this aspect of Epic’s case in terms of the effect or likely effect during and over the relevant period.
Android in-app payment solutions – relevant contracts and mechanisms
5393 Now the following matters concerning the relevant contracts and mechanisms, which Epic has pointed to, do not seem to be contentious. Let me set out some of the detail.
5394 Under the DDA, developers have to contract with a payment processor (as defined), pay a service fee and abide by Google’s payments policy.
5395 Clause 3.2 provides that the DDA covers both products that users can access for free and products that users pay a fee to access. If the developer wishes to charge a fee for products distributed via the Play Store, the developer must have a valid payments profile under a separate agreement with a payments processor.
5396 A payments profile is defined to mean a financial service account or profile provided by a payment processor to a developer that enables a payment processor to collect and remit payments to the developer on the developer’s behalf for products sold via the Play Store.
5397 A payment processor is defined to mean a Google-affiliated entity providing services that enable developers to receive payments for products sold via the Play Store. According to the DDA, it is the payment processor which supplies those services.
5398 So, under the DDA, services for the collection and remission of payments for products sold via the Play Store are supplied directly to the developer by a separate entity being the payment processor, and not by one of the three Google entities that are parties to the DDA.
5399 Further, the payment processor supplies those services on the developer’s behalf, and not on behalf of the three Google entities that are party to the DDA.
5400 In other words, there is a partition between the services that are supplied to developers under the DDA and the three Google entities that supply those services on the one hand, and the services that enable developers to receive payments for products sold via the Play Store and the payment processor that supplies those services on the other hand.
5401 Clause 3.4 provides that, acting as the developer’s agent, and with the developer acting as principal, Google is the merchant of record for products sold or made available to users in specified countries or territories. The clause then stipulates that the developer is the merchant of record for products it sells or makes available via the Play Store to all other users.
5402 The countries and territories for which Google is the merchant of record pursuant to clause 3.4 are identified in a linked document as comprising countries and territories located predominantly in Europe. These overlap with countries and territories for which Google Commerce Limited is appointed as agent pursuant to clauses 2.1 and 3.1.
5403 Clauses 2.1 and 3.1 appoint Google LLC as “agent” of the developer to make its products available in the Play Store to users in countries and territories predominantly located in North and South America.
5404 These clauses appoint Google Commerce Limited as “agent” of the developer in countries and territories predominantly located in Europe, the Middle East and Africa.
5405 And these clauses appoint Google Asia Pacific Pte Ltd as “marketplace service provider” of the developer in countries and territories predominantly located in Asia and the Pacific, including Australia.
5406 Those appointments are expressly made on the basis that the purchase and sale of the developer’s products is governed by a contract of sale directly between the developer and users, save where Google Commerce Limited is the merchant of record.
5407 Now there are separate payment processing contracts.
5408 In Australia, the payment processor with whom developers must enter into a separate agreement pursuant to clause 3.2 is Google Payment Australia Pty Ltd. The terms of the agreement which developers must make with Google Payment Australia Pty Ltd are set out in a product disclosure statement (PDS), which sets out the rights and obligations of users and developers when using the “Google Payments Service”. That service is an online payment processing service that is designed to facilitate the processing of payments between purchasers (buyers) and participating merchants (sellers).
5409 On registering to use the Google Payments Service, buyers and sellers become bound by the PDS and the relevant terms of service.
5410 The seller terms of service form a legal agreement between Google Payment Australia Pty Ltd and the relevant seller, being the developer.
5411 They provide that the “Seller’s sales of Products are transactions between Seller and Buyer and not with GPAL, Google or any of GPAL affiliates”.
5412 They provide that “GPAL is a third-party service provider facilitating Payment Transactions on behalf of the Seller and is not party to any Payment Transaction”.
5413 They provide that “GPAL is not a Buyer or a Seller in connection with any Payment Transaction”.
5414 And they provide that “[w]hen a Buyer seeks to make a purchase … the [Google Payment] Service will process the payment on behalf of Seller”.
5415 In turn, Google Payment Australia Pty Ltd has its own agreement with Google Asia Pacific Pte Ltd, known as the payment processing services agreement.
5416 That agreement provides that when providing services in connection with payment processing functions and services, Google Payment Australia Pty Ltd does not act as agent for or on behalf of Google Asia Pacific Pte Ltd but as an independent contractor.
5417 In the United States, the payment processor with whom developers must enter into a “separate agreement” pursuant to clause 3.2 of the DDA is Google Payment Corp. That agreement governs the provision of a service that facilitates the processing of payment transactions on behalf of a seller to complete a payment for a purchase between a seller and buyer.
5418 Its terms stipulate that the seller’s sales of products are transactions between seller and buyer and not “with GPC or any of GPC’s affiliates”. Its terms provide that Google Payment Corp is a third-party service provider facilitating payment transactions for the seller and provide that GPC does not act for the buyer in payment transactions. Its terms provide that “GPC is not a Buyer or Seller in connection with any Payment Transaction”. And its terms provide that “[w]hen a Buyer seeks to make a purchase with a Payment Account, the Service will process the Payment Transaction on behalf of Seller”.
5419 Google uses the same model in each country. So, a single Google entity provides a payment service as a third-party service provider facilitating payment transactions on behalf of developers.
5420 So, the services which facilitate the processing of payments for in-app purchases made within Play Store apps are provided under separate contracts, and by entities different from those that supply distribution services to developers under the DDA.
5421 Further, the payment processors do not provide those services as agent for the developer, nor as agent for the Google entities that are party to the DDA, but as independent contractors directly engaged by the developer.
Google Play Billing — the DDA and the payments policy
5422 The following matters are also not contentious, unless I state otherwise.
5423 Now Google Play Billing is the payment solution that Google requires app developers and consumers to use, and is the only payment solution that Google permits app developers and consumers to use, for accepting and processing payments for Play Store in-app purchases.
5424 Google Play Billing, as a payment solution, provides for and facilitates the acceptance and processing of payments from Android smart mobile device users for apps or in-app purchases.
5425 It does this by, among other things, providing for the acceptance and collection of payments from Android smart mobile device users, all necessary engagements with credit providers, payment processors and financial institutions, the deduction and payment of any relevant fees or commissions, and the payment of the remaining balance to the app developer.
5426 Google Play Billing is charged by Google Payment Australia Pty Ltd, or alternatively by Google LLC, Google Asia Pacific Pte Ltd and/or Google Payment Australia Pty Ltd, at a 30% commission to app developers for Play Store in-app purchases or, in some limited circumstances, 15%.
5427 Clause 4.1 of the DDA provides that the developer must adhere to the developer program policies, which include Google’s payments policy.
5428 The payments policy provides that developers charging for app downloads from the Play Store must use Google Play Billing.
5429 The payments policy provides that Play Store-distributed apps requiring or accepting payment for access to in-app features or services, including any app functionality, digital content or goods, must use Google Play Billing unless section 3 or section 8 of the payments policy applies.
5430 Section 3 stipulates that Google Play Billing must not be used where the payment deals with any of the following items or matters.
5431 First, it must not be used where the payment is primarily for the purchase or rental of physical goods, for the purchase of physical services or a remittance in respect of a credit card bill or utility bill.
5432 Second, it must not be used where the payment includes peer-to-peer payments, online auctions or tax exempt donations.
5433 Third, it must not be used where the payment is for content or services that facilitate online gambling.
5434 Fourth, it must not be used where the payment is in respect of any product category deemed unacceptable under Google’s payments centre content policies.
5435 Section 8 was first added to the payments policy in late 2021. The provision was initially limited to in-app purchases effected by users in South Korea, but its scope was enlarged with the subsequent introduction of inter-alia the UCB pilot and the DOB program.
5436 These programs permit developers to offer users an alternative billing system in countries where UCB or DOB are available, but only if they comply with requirements prescribed by Google.
5437 In summary then, except where developers are participating in UCB or DOB, the payments policy relevantly requires developers to exclusively use Google Play Billing for in-app purchases of digital content within apps distributed via the Play Store. The parties before me referred to this as the payments tie.
5438 And as I have said, the payments policy does not require the use of Google Play Billing for in-app purchases of physical goods or services. In fact it prohibits such use.
5439 And since the service fee is only payable on apps and in-app products sold through Google Play Billing or an alternative billing system, no service fee is payable on in-app purchases of physical goods or services. And nor is a service fee payable in respect of apps which are distributed without charge and without charging for in-app purchases, even if the developer monetises the app in a different way, for example, with paid advertising.
5440 There is also an exemption from the requirement to use Google Play Billing in around 15 countries where Google Play Billing is not offered. Developers can use their own billing systems for purchases made in those countries.
The external consumption exception
5441 Now it is convenient at this point to say something about the external consumption exception, aspects of which were contentious.
5442 Between August 2013 and 20 January 2021, the payments policy contained another exception, whereby developers offering additional content, services or functionality within a non-gaming app downloaded from the Play Store were not required to use Google Play Billing where the payment was for digital content or goods that may be consumed outside of the application itself. The parties have referred to this as the external consumption exception.
5443 With effect from 20 January 2021, Google removed the external consumption exception from the payments policy. Now Google described this as a clarification, but this was an unsatisfactory description. The change was a unilateral change to the contractual obligations of developers which required them to use Google Play Billing and to pay a service fee on in-app purchases of digital content that, until then, had been exempt from these requirements.
5444 Existing apps that used an alternative payment solution were given until 30 September 2021 to comply with the amended payments policy. Google announced that from 1 June 2022, any app developer that was non-compliant with the amended payments policy would be removed from the Play Store.
5445 Before Google removed the external consumption exemption from its payments policy in January 2021, around 5,000 developers had chosen to use a payment solution other than Google Play Billing to facilitate in-app purchases of digital content within Play Store apps. Google expected more to follow.
5446 Google expected contagion or a domino effect, with an increasing number of developers having recourse to alternative payment solutions.
5447 The external consumption exemption was “clear cut”, as Mr Feng conceded, but he said that it was “the example” which gave rise to confusion. Mr Feng blamed the example for the fact that the exemption was “inconsistently enforced”.
5448 I agree with Epic that the only one confused by the language of the payments policy was Google itself.
5449 As Epic says, the external consumption exemption was clear. Where the payment was for digital content that could be consumed outside of the app, the developer was not obliged to use Google Play Billing. And the only issue to which that exemption could give rise was a factual one: could the digital content be used outside the app? If so, the developer was not obliged to use Google Play Billing for in-app purchases of that content.
5450 I agree with Epic that if the payments policy was enforced inconsistently, that was because Google enforced it in cases where it did not apply. It would seem that Google was treating the external consumption exemption as non-existent and treating any purchase of digital content without use of Google Play Billing as a violation. One example of this is Spotify.
5451 Now Ms Kochikar conceded that the digital content available within the Spotify Android app, purchased by way of subscription, can be consumed outside that app. But she insisted that Spotify was in violation of the payments policy.
5452 Now in March 2017, a recommendation was made to remove the external consumption exemption. It was said this would be better for users, developers and revenues. Now as Epic said, there is no doubt that it would be better for Google’s revenue to amend the payments policy so that more developers were obliged to pay the service fee and others were prevented from de-integrating, but the idea that this would be better for developers is unconvincing.
5453 Mr Gennai said that this change was made in response to developer feedback, but as Epic said, he could not name a single developer that asked for the change to be made.
5454 At all events, I do not need to linger on the detail of all of this.
5455 By January 2019, the external consumption exemption had still not been removed, but Google had warned, suspended, or rejected some 5,908 apps for not using Google Play Billing.
5456 Now as Epic says, by this time, regulatory concerns had arisen for Google in the context of the so-called “P2B regulations”, whose introduction was anticipated in the European Union. It is apparent that the recommendation to remove the external consumption exemption was connected with these pending regulations.
5457 Mr Feng conceded that there was certainly regulatory pressure building in the period immediately before Google decided to remove the exemption in late 2020, and “one of the goals was to forestall the regulation or to, you know, avoid the need for it.”
5458 As Epic says, Google was concerned that the proposed P2B regulations would require Google to make Google Play Billing optional. It would appear that Google was concerned that regulation might intervene to break the payments tie, such that it would have to compete with rival payment solutions.
5459 Now as Epic says, Mr Feng sought to maintain in cross-examination that the reason for removing the exemption was for “core ecosystem reasons” and “the regulatory changes slowed us down because we had to assess the impact that it would have on our ability to make the change”. But he agreed that potential regulatory reactions to the removal were a strong consideration.
5460 The decision to remove the exemption was made public in September 2020.
5461 Now many developers affected by the removal of the external consumption exception preferred to use an alternative payment solution and did not want to use Google Play Billing.
5462 Google has suggested that this is explained by a desire to avoid paying the service fee. But I agree with Epic that many developers considered Google Play Billing to be a deficient product that was harmful to their business.
5463 As Epic says, the evidence shows that many developers wanted to use an alternative payment solution because the relevant alternative better suited their business and payment solution needs. Developers wanted better forms of payment (FOP) coverage, better involuntary churn rates, and the ability to maintain a direct relationship with their customers, including the ability to respond to questions and complaints. Developers wanted to use the same payment solution for in-app purchases of both digital and physical products and to use the same payment solution across more than one distribution channel. Developers wanted better access to data about their users and the ability to bill customers at the time they chose and for a price they chose. And developers wanted the ability to adjust the payment solution features that they acquired from one country to the next, based on local market conditions.
5464 And even YouTube, a subsidiary of Google, did not want to use Google Play Billing as the evidence revealed.
5465 Mr Feng problematically sought to downplay this by suggesting that YouTube was concerned only about the work involved in switching from its payment solution to Google Play Billing.
5466 YouTube identified a range of features besides the upfront effort to migrate to Google Play Billing that it was concerned about, including the need to use Google Play Billing rather than YouTube branding, the lack of fine grained data or control of buy/fix flow based on that data, the limited pricing models, and the lack of “non-linear upgrade/downgrade…ability to pause subscriptions etc”.
5467 YouTube considered that using Google Play Billing would significantly limit its ability to innovate and would most likely result in feature regression.
5468 According to YouTube’s CEO, using Google Play Billing would be “damaging for our business against our competitors” and would leave YouTube “stuck with a lot of larger prioritizations decisions that might be right for play billing but bad for YouTube”.
5469 In the evidence before me, and as correctly described by Epic, there were other examples of developers that were dissatisfied with the features and performance of Google Play Billing.
5470 Spotify considered Google Play Billing to have various deficiencies, including the lack of freedom to communicate with its customers, the limited payment choice for users, the limited access to data about its customers, the lack of ability to respond to unique local market preferences, the lack of access to granular conversion data and the lack of product and pricing control.
5471 Netflix tested Google Play Billing and observed higher “churn” than when using its own payments platform, such that users were only 58% as valuable for Netflix when they were acquired through the Play Store as compared to other channels. Netflix after testing concluded that Google Play Billing did not perform well enough to warrant using it.
5472 Match Group considered that Google Play Billing had feature gaps such as the inability to support partial refunds that would result in “lower conversion” and “hurt user experience and revenue”. Match had tested Google Play Billing with poor results and had its own robust billing backend.
Possible changes to the business model and removing the payments tie
5473 Now as Epic points out, and as I have discussed in more detail elsewhere, the service fee has been repeatedly described within Google’s own documents as “arbitrary”. Indeed it is not contentious that the 30% fee bears no discernible relationship to Google’s costs.
5474 In an August 2018 memorandum, Ms Kochikar’s subordinate described Google’s then service fee of 30% for all as “Status quo. It’s what Apple does” and said it had “No rationale. Unfeasible for many business models”.
5475 Similarly, in its March 2019 presentation titled Exploring New Business Models, Google observed that the 30% rate has “No rationale, other than copying Apple” and is “untenable for many apps/games developers”.
5476 Now Project Magical Bridge considered alternative business models that included charging developers separately for different services, including for payment solutions. And Google engaged in a lengthy examination of billing optionality, whereby developers would have the opportunity to acquire their own payment solution.
5477 But as Epic says, there was never any dispute about whether it was technically possible to separate the billing system from other aspects of Google Play Billing. From the launch of the Play Store until 29 March 2011, Google did not offer a payment solution for in-app purchases and developers adopted their own payment solutions during that period. And in the 15 or so countries where Google Play Billing is not offered, developers incorporate alternative payment solutions into their apps.
5478 Further, Google has separated the billing system in South Korea. In jurisdictions where UCB is available, the alternative billing system is a separate and distinct service.
5479 Further, in January 2021, as part of Project Runway, Google explored the implications of partial unbundling. And as Epic says, its assessment was that given the choice, most developers would continue to use Google Play Billing if there was only a two percentage points reduction in the service fee for unbundling but some larger developers would still consider unbundling, and that any app developer would consider unbundling if the service fee reduction was 15 percentage points. If the reduction were 10 percentage points, Google felt that most would see benefit from unbundling.
5480 Further, in a March 2021 presentation titled Project Basecamp – Optionality, the “objectives with the biz model change” are to “[g]ive developers choice in billing” in order to “[a]ddress the ‘lack of choice’ narrative while preserving Play’s margins”, and then to “[r]etain the optionality to reinvest the margins and create conditions for developers to choose Play billing (vs policy enforcement) via structural incentives…”. So, the strategy was to address a narrative only, whilst preserving Google’s existing profit margins and using those profits to preserve the status quo.
5481 As Epic says, Mr Feng could not give a satisfactory explanation for why, if Google thinks that it provides a payment solution that is attractive to developers, it does not simply compete on the merits with alternative payment solution providers and give developers a choice as to whether to use Google’s payment solution. As Epic expressed it, he hid behind the façade that “[w]e don’t offer a payment service”.
5482 But as Epic points out, Mr Feng conceded that it is possible that many developers would choose their own billing system but for the condition that Google imposes on them. He also conceded that there are multiple third-party providers of payment systems who would like to offer payment systems to Android developers. Indeed, Mr Feng said he thought that there would be entry by suppliers of payment solutions such as Stripe, Adyen, PayPal, and others if Google did not require developers to use Google Play Billing, and that there would be competition in this space.
5483 He also agreed that if alternative payment solutions were permitted, third-party suppliers could provoke Google to innovate in relation to its own billing system.
The anti-steering prohibition
5484 On 20 January 2021, Google amended the payments policy to prohibit apps that were required to use Google Play Billing from leading users to a payment method other than the Play Store’s billing system.
5485 This prohibition expressly extends to leading users to other payment methods via an app’s listing in the Play Store, in-app promotions related to purchasable content, in-app webviews, buttons, links, messaging, advertisements or other calls to action, and in-app user interface flows, including account creation or sign-up flows.
5486 The parties before me referred to this prohibition as the anti-steering rule, which Google has enforced.
Alternative billing methods
5487 Let me at this point discuss the alternative billing methods involved with what is known as user choice billing (UCB) and what is known as developer only billing (DOB). I will begin with Epic’s description of UCB which for the most part does not seem to be contentious.
The development and elements of UCB
5488 Since late 2021 in South Korea, and since early 2023 in India, Google has permitted app developers to offer users an alternative in-app payment solution alongside Google Play Billing under the UCB program.
5489 That permission was only granted in response to legislation in South Korea and a decision of the Competition Commission of India.
5490 Under the UCB program, if a developer wishes to offer users an alternative payment solution, it must do the following.
5491 It must comply with user experience requirements prescribed by Google. Initially, those requirements were set out in the interim guidelines. Presently, they are set out in an alternative billing APIs document.
5492 The interim guidelines stipulated requirements that included the following matters.
5493 First, the first time the user initiated a purchase, they had to be shown an information screen whose text and context had to be exactly as prescribed by Google, including a statement that “Only purchases through Google Play are secured by Google”.
5494 Second, a billing choice screen had to be shown to the user before every purchase.
5495 Third, the purchase price had to be shown to the user before they were shown either the information screen or the billing choice screen.
5496 Fourth, the buttons for the alternative payment solution and Google Play Billing had to be represented in a fair and equal manner on the billing choice screen, and all components of that screen had to contain the exact text and elements prescribed by Google.
5497 The alternative billing APIs document explained that once a developer integrates with Google’s alternative billing APIs, as participating developers are now required to do, then the Play Store renders and manages the applicable information and user choice screens, such that the user experience is dictated by Google. That user experience is not materially different from that required under the interim UX guidelines.
5498 The developer must also report the amount of all paid transactions to Google. Initially, such reporting was required monthly, but now that participating developers have implemented the alternative billing APIs, reporting is required within 24 hours of each transaction. The alternative billing APIs have automated the reporting to Google of every transaction made through an alternative billing system.
5499 Now under the UCB program developers are compelled to offer Google Play Billing alongside their preferred alternative payment solution. As Epic says, this is unattractive for developers. App developers prefer all payments to be facilitated by a single payment solution so that the developers are only dealing with one payment solution provider and can consolidate transaction data from a single source.
5500 Further, the billing choice screen introduces additional friction into the payment flow.
5501 In addition, in India, the developer is required to contract directly with users for transactions effected using the alternative billing solution, and is responsible for issuing all mandatory disclosures, invoices and receipts. The developer is also obliged to inform users that the developer is solely responsible for any transaction taxes.
5502 Further, Google’s terms of service state that when a user selects an alternative payment solution under UCB, Google will charge a service fee that is 4 percentage points below the fee it would charge the developer for that transaction had the user selected Google Play Billing.
5503 So, where UCB is deployed and the user selects an alternative payment solution, the service fee is said to be typically 26% or 11%, rather than 30% or 15%. As Epic says, it follows that the developer is financially worse off under UCB unless it can implement an alternative payment solution at a cost of 4% or less of transaction revenues.
5504 I will say something more about the costing elements and service fee aspects of UCB a little later.
5505 Now since 1 September 2022, Google has allowed non-gaming app developers only to join its UCB pilot program and offer an alternative payment solution alongside Google Play Billing in Australia, India, the European Economic Area (EEA), Indonesia, and Japan.
5506 On 10 November 2022, the pilot was extended to the United States, Brazil and South Africa. In the EEA, gaming apps were excluded from the UCB pilot for about 2 years, but they have not been excluded since the Digital Markets Act became binding.
5507 If a non-gaming app developer wishes to offer an alternative in-app payment solution alongside Google Play Billing pursuant to the UCB pilot program, it must comply with essentially the same requirements and pay the same service fees as in relation to South Korea and India.
5508 Let me make some more general points.
5509 But putting pricing to one side, the only choice afforded by the UCB program is to offer an alternative payment solution alongside Google Play Billing. There is no choice to replace Google Play Billing altogether.
5510 Further, to participate in the UCB program developers must agree to follow user experience requirements prescribed by Google some of which I have already summarised.
5511 Further, and apart from in the EEA where the Digital Markets Act applies, the UCB program is not available for gaming apps.
5512 Now Mr Feng explained the exclusion of gaming apps as being “because of a concern within Google that UCB for gaming apps entails a greater safety and security risk than non-gaming apps”. But the documentary evidence does not bear this out, as Epic has pointed out.
5513 A July 2021 presentation titled Project Everest – Options for evolving Play’s Business Model identified three options “for how aggressively to make changes to our business model”, with billing optionality for apps and games labelled the most “radical”. The adverse revenue impact of each option was highlighted, with the largest impact being attributed to the apps and games option. As Epic says, there was no reference to safety or security in this paper. The primary focus was the revenue impact and the extent to which each option addressed agitation from regulators or developers.
5514 Further, an August 2021 presentation titled Project Everest – Update on Options considered both an “Apps Only” and an “Apps and Games” approach to billing optionality. But as Epic says, none of the concerns listed with respect to the latter approach had anything to do with safety or security risks. The “Apps Only” approach mentions reasons why “Games are different”, including “safety features eg budgeting, family link”, but these were not expressed as concerns which would preclude billing optionality for games.
5515 Moreover, as Epic points out, in a presentation shortly thereafter titled Project Everest – Options for evolving Play’s Business Model, “Apps and Games” remained a live option. That presentation showed that the negative revenue impact on Google of including games in a UCB model was higher than if games were excluded. Mr Feng conceded that the revenue impact of including games was considered by Google.
5516 Further, in a 29 March 2022 presentation titled Project Everest – User Choice Pilot, “Apps and Games” were still included as an option for the UCB pilot. But one week afterwards, in a 5 April 2022 presentation titled Project Everest – User Choice Pilot Proposal, games were excluded.
5517 When asked about this change, Mr Feng could not identify anything that had happened within that week to cause games to be excluded. Indeed he said that they were always contemplating that games would eventually be included. So, it would seem that there was no fundamental safety or security impediment to their inclusion. Mr Feng then gave the following evidence:
MR YOUNG: By that stage, nobody had said within Google, “Gee, we shouldn’t have games in the pilot” because of some safety or security-type concerns?
MR FENG: Right. Yes. That’s – that’s right. And just to be super clear, concerns that would require a substantial amount of work to alleviate, right, or to at least to validate whether or not they were actually a concern. So we wanted to stage the pilot. It was a question of timing.
5518 When re-examined on this answer, Mr Feng said:
I don’t think I would agree that there was no one raised the question of whether or not there were reasons, including user safety, that we should not include games in the first phase of the pilot. I think, in fact, it’s almost certainly what happened is that there was a discussion between those two presentations where there was … where the question of whether games should be included in the first phase of the pilot happened, and we decided for the reasons that I stated, that it was likely that it made sense not to include games in that first phase, again, in the first phase, not at all.
5519 As Epic says, the latter evidence was not based on an actual memory of events and was speculative. It also relied on the concept of the pilot having “phases”. That is not borne out by the contemporaneous documents or by subsequent events.
5520 I reject Mr Feng’s evidence on this issue. I agree with Epic that games were excluded and continue to be excluded from the UCB pilot so that Google would not lose too much revenue.
5521 Now before turning to costing elements and service fee aspects of UCB, let me say something more about another model known as developer only billing, which I have referred to as DOB. Again, for the most part, it is convenient to rely on Epic’s description.
Developer only billing
5522 Now since 19 July 2022 in the EEA only and as a response to the passage of the Digital Markets Act, Google has allowed non-gaming app developers to use an alternative in-app payment solution, without also having to integrate Google Play Billing alongside it. This program is known as developer only billing (DOB). The DOB program was extended to gaming apps on about 5 March 2024.
5523 As Epic says, the user experience guidelines applicable to DOB are different from those that apply to UCB. There is no requirement to offer Google Play Billing alongside the alternative in-app payment solution. Indeed, Google Play Billing cannot be offered if DOB is used.
5524 And as Epic says, the different guidelines include a requirement to display an information screen during the user’s first purchase stating that the app does not use the Play Store’s billing system, that the developer will be the seller of all in-app purchases and manage all aspects of the user’s purchases, and that certain Play Store features will not be available.
5525 The terms applicable to the DOB program are otherwise materially the same as those in respect of the UCB pilot, save that when an in-app purchase is made using an alternative payment solution under DOB, Google charges a service fee that is 3 percentage points lower than the fee that Google would charge had the transaction occurred using Google Play Billing.
The service fee discount under UCB and DOB
5526 Now Google says that the service fee discount fairly represents the additional costs that developers could incur in not using Google Play Billing, and maintains a charge for the other value that the Play Store provides.
5527 And Google says that in cross-examination, Mr Feng explained that Google reduced the service fee to reflect what it thought is “the reasonable cost that the developer would incur”. He added:
… What we wanted to do was to make it neutral, so that the developer wouldn’t switch payment systems simply to get an additional few per cent discount. And that was really critical for us because we really felt – and continue to feel – that Play Billing is an integral part of the Play experience. So we didn’t want to artificially kind of cause … developers to choose alternate billing just to get a little extra discount on top of payment processing.
5528 Google says that Mr Feng’s reference to the risk of “artificially” causing developers to choose alternative billing is important.
5529 Google says that what Mr Feng was saying is that Google did not want to create an artificial incentive for developers to choose alternative billing as a means to, in effect, obtain a discount on the non-payment aspects of the service fee, as opposed to the portion of the service fee attributable to the payments solution that developers could obtain elsewhere.
5530 It says that the discount for UCB reflects this. The discount is tailored to reflect the cost of those forms of payment that Google considered to be contestable by third-party payments providers. Cards are the most dominant form of payments for in-app purchases in Australia.
5531 Because of its dominance as a form of payment, the fundamental requirement for a payment solution for in-app purchases in Australia is an ability to accept and process payment cards. Further, app developers will not necessarily need to replicate all the forms of payment that the Play Store offers to provide a viable in-app payment solution in Australia.
5532 Now Epic notes that the cost of certain forms of payment, namely, direct carrier billing, is higher than 4%, and so UCB is not a genuine alternative. Google says that it may be accepted that the 4% discount on the service fee does not account for the cost of direct carrier billing, but it says that it is an expensive form of payment that requires significant effort and more than cards to set up. It says that implementing direct carrier billing requires direct bilateral negotiations with carriers, which is a costly endeavour. Developers would not generally undertake this process.
5533 Google says that the unattractiveness of setting up direct carrier billing can also be inferred from the fact that payment providers, like Stripe and Adyen, do not even offer direct carrier billing. It says that it fairly considered that it was unlikely that developers would implement this form of payment themselves or obtain it from third parties. Moreover, under UCB, a developer could have the best of both worlds by offering users the cheaper forms of payment on its own payments system, with more expensive forms of payment available via Google Play Billing, with Google bearing the higher cost.
5534 Further, Google says that Epic’s point that the 4% discount is insufficient to permit developers to viably adopt UCB depends in large part on the assumption that, in addition to payment processing costs, developers would face meaningful additional incremental costs to obtain an alternative billing system. But Google says that this assumption is unsound.
5535 It says that the developers most interested in alternative billing were larger developers with considerable scale. And such developers generally already operate stores on the web or other platforms, and so may have no incremental costs.
5536 Google says that Epic assumes that developers would be starting from scratch, but it says that the evidence is to the contrary and that was not Google’s assumption.
5537 So, Google says that I ought not to conclude that it set the UCB discount at 4% with a view to making that option unviable for developers to use. It says that it is clear from Mr Feng’s evidence that Google’s subjective view was that the discount was sufficient to make the program viable for the developers who were likely to want their own payment solutions, without creating artificial demand such as would occur if UCB became a de facto discount on the non-payment portion of the service fee.
5538 Analogous points were made by Google concerning DOB and the relevant discount.
5539 But I do not accept Google’s position.
5540 Now under the UCB and DOB programs, Google still charges a service fee of 26% and 27% respectively for each in-app purchase of digital content that is facilitated by an alternative payment solution. But, as Epic says, unless developers can engage another payment solution supplier at a total cost of 3 to 4% or less, they will be worse off financially by offering a payment solution other than Google Play Billing.
5541 Indeed, Google’s own costs of supplying Google Play Billing are greater than 4%. Its costs of payment processing alone exceed 4%. Epic provided the following figures that did not seem to be contentious.
5542 For a limited range of FOPs, namely credit cards and e-Wallets, Google’s estimates of its payment processing costs vary from 3.5% to 3.8%. If direct carrier billing is included, Google’s payment processing costs increase to between 5.7 and 5.8%.
5543 If all of the FOPs that Google offers as part of Google Play Billing are included, Google’s payment processing costs are between six and 6.2%.
5544 Accordingly, Google’s costs of payment processing alone are at least 6%.
5545 Now I agree with Epic that Mr Feng problematically sought to justify the fact that Google reduces its service fee for UCB and DOB by less than its own payment processing costs on the basis that direct carrier billing is an expensive FOP which can be ignored because few developers want to offer direct carrier billing to their customers.
5546 As Epic points out, direct carrier billing is used for 25% of Google Play Billing transactions undertaken by the Play Store’s top 100 global sellers. Direct carrier billing is a widely used and popular form of payment, which many developers would want to offer to their users. Indeed, Google regards direct carrier billing as an important part of its offering to customers, and that in certain countries direct carrier billing is an important payment mechanism.
5547 I agree with Epic that for any developer whose users might prefer to use direct carrier billing, the UCB and DOB programs are not genuine alternatives.
5548 Indeed, Mr Feng said that Google “felt that, in a lot of cases, the developer would just – or the user would just choose Google Play Billing in those cases” where direct carrier billing was important to them. Mr Feng then agreed that for the developer for whom direct carrier billing is important, UCB did not really offer a genuine option.
5549 Moreover, as Epic says, payment processing is only a part of the service that Google Play Billing provides. Google Play Billing has more functions and offers a broader range of services than just payment processing, none of which is costless. As Epic says, taking those matters into account, Google’s costs of supplying Google Play Billing are above 6%.
5550 And as Epic points out, Google has grouped the additional costs that it incurs for matters besides payment processing into two categories, being (a) “Other costs ~1-2% (mostly customer support)” and (b) “Infrastructure cost (largely fixed) depending on the complexity of the billing operations”.
5551 The first category appears to comprise variable costs, which suggests that Google’s variable costs of offering Google Play Billing are around 7 to 8%. Google would seek to recover all of those costs in a competitive market.
5552 The second category appears to comprise mostly fixed costs. Google would expect a contribution to its fixed costs in a competitive market.
5553 So, the costs of Google Play Billing that it incurs, and would expect to recover in a competitive market, are likely to be 8% or more.
5554 I reject Google’s contention that the price reductions applied under the UCB and DOB programs reflect the costs saved by Google when Google Play Billing is not used.
5555 I agree with Epic that on the evidence, the price reductions which Google applied under the UCB and DOB programs were calculated to limit the take-up of alternative payment solutions and to maintain the payments tie in practice, whilst pretending to offer choice to developers.
5556 So, and as Epic said, in arriving at its 4% reduction, Google relied on estimates of its payment processing costs, not its costs of supplying other aspects of Google Play Billing. And even then, Google limited its estimates to the cost of processing the cheapest FOPs, that is, credit cards, e-wallets, and bank transfers, notwithstanding the more expensive FOPs that are offered by Google Play Billing and are regarded as an important aspect of that offering.
5557 I agree with Epic that Google well understood that its actual payment processing costs were at least 6%, and that payment processing was just one aspect of the costs that would be incurred by developers opting for an alternative to Google Play Billing.
5558 Further, as Epic says, the document which Mr Feng presented titled Project Everest – Options for evolving Play’s Business Model recommended that Google reduce the service fee by five percentage points, which was described as “cost of payment processing”. But the same page showed that the actual figures are “Cost of payment ~6% including 1P FOPs (DCB and Giftcard), ~4% excluding”. Further, it said that costs “vary by geo. Ranging from 3%-10%, largely driven by FOP mix.” So, six percentage points (not five) was a more accurate reflection of the cost of payment processing incurred by Google.
5559 Further, it was also apparent to Google that developers with a large proportion of users in higher cost countries would incur payment processing costs well above the global average. So, the same document shows that Google’s payment processing costs in South Korea, for all FOPs, was 6.5%. But even so, Google ultimately applied a uniform reduction of four percentage points under UCB and three percentage points under DOB.
5560 Further, Mr Feng’s speaking notes for the document include the statement that a:
… key principle is that we don’t want to encourage devs to not use Play billing. Thus, a key element of this optionality proposal is we don’t want to give any artificial reasons to incent devs to switch off play billing…our proposal is to price the service fee for devs not using GPB at 5% less than those using GPB – essentially replacement value.
5561 Now whilst Mr Feng sought to explain his statement as meaning that Google wanted to “make it neutral, so that the developer wouldn’t switch payment systems simply to get an additional few percent discount”, as Epic says, the fact is that the 5% was not “replacement value”, as Google well knew. And even if it were, Google subsequently adopted reductions of 4% under UCB and 3% under DOB, rather than 5%.
5562 And as Epic said, Google also estimated the costs likely to be payable by developers to alternative payment solutions providers, based on Adyen’s published rates, at 6% on average with a median cost of 8%, and based on Stripe’s published rates, at 6% on average with a median cost of 14%. Google also sought to estimate the payment costs of the Top 100 developers based on the published rates of Adyen and Stripe. That estimate indicated that most of those developers would incur costs of 5% or more.
5563 Further, Google’s internal recommendation that the service fee be reduced by four percentage points records the rationale as “in order to preserve the current value proposition of offering a bundle of fully integrated services and defend our service fee”.
5564 In my view, based upon what I have said above and for the reasons given by Epic, Google did not genuinely believe that a four percentage point reduction was a fair reflection, either of its own costs of supplying Google Play Billing to developers, or of the costs developers were likely to incur if they switched to an alternative provider that offered them anything more than processing e-wallet, credit card, and bank transactions.
5565 I agree with Epic that the reality is that Google set the reduced fee at a level that ensured developers could not obtain an alternative payment solution with comparable functionality to Google Play Billing without paying more, in total, than they would otherwise have had to pay Google.
5566 As Epic correctly characterised the reality, Google ensured that a developer switching to an alternative solution under UCB or DOB would be worse off financially, or worse off qualitatively if the developer opted for a payment solution with minimal functionality.
5567 Now before proceeding into the question of market definition, market power and the other competition questions, it is necessary to divert into a discussion of some technical evidence.
In-app payments – some technical evidence
5568 Let me start by setting out some of Professor Somayaji’s evidence, most of which was not contentious. I confess now that there is some overlap in the following discussion with what I have said in my reasons in the Apple proceeding, but not too much.
5569 Many apps across a variety of digital platforms, including Android devices, require that users be able to purchase goods and services from within the app. These goods and services can come in physical or digital forms. For example, the Amazon shopping app for Android offers users the ability to purchase physical goods from the app, which are then shipped by Amazon to their doors. Spotify offers users the ability to purchase digital goods, namely streaming subscription plans.
5570 In-app purchases allow developers to sell goods, services, and subscriptions to users through an app after it has been installed.
5571 Now accepting and processing payments for in-app purchases relies on digital payment solutions. Digital payment solutions are a suite of services facilitating online payments via financial institutions that users already have relationships with. So, digital payment solutions allow customers with existing digital payment methods such as a credit card to make purchases from merchants with existing payment repositories such as a checking account.
5572 The role of the digital payment solution is to enable users to make purchases from within apps, resulting in money moving from the customer’s payment method to the merchant’s financial account. Digital payment solutions commonly include a payment gateway, a fraud management system, and a checkout interface. I have explained these in my reasons in the Apple proceeding.
5573 Google Play Billing is an example of a digital payment solution, offering an integrated third-party payment gateway, a custom checkout interface, and a custom fraud management system.
5574 Google Play Billing’s fraud management system and checkout interface are both custom-built Google services. During the checkout process, Google Play Billing relies on payment information stored on file through the customer’s Google account rather than requiring the customer to input payment information during the transaction.
5575 Unlike many other digital payment solutions, Google Play Billing integrates with a third-party payment gateway such as Worldpay in Australia, rather than offering its own custom built payment gateway. From the perspective of both the developer and the end user, however, this difference does not change the experience of using Google Play Billing.
5576 For developers, Google Play Billing is provided as a library that can be integrated into Android app code. This library uses APIs to enable apps to communicate with the Play Store, which hosts digital products and is responsible for confirming purchases. After developers successfully sell products using Google Play Billing, Google acts as the mediator of funds between the buyer and the developer, accepting payment from the buyer’s bank and remitting those funds back to the developer.
5577 In general, for Android apps that use Google Play Billing, Google charges a commission on revenue generated through in-app purchases.
5578 Now all apps distributed through the Play Store that offer in-app purchases are required to use Google Play Billing and so are subject to the commission. But certain conditions exempt some categories of apps from the Google Play Billing requirement. So, an exception is given for in-app purchases of non-digital goods and services. This exception applies to apps like Uber, where in-person services are arranged digitally, but the services are fulfilled physically.
5579 Now to better understand how Google Play Billing works and how it compares to similar functionality provided by other digital payment solutions, Professor Somayaji explained the technical details of in-app purchases in two parts. First, one has digital payment processing, which is the primary system by which in-app purchases of digital goods are processed, encompassing the payment gateway, fraud management system, and checkout interface. Second, one has digital inventory management, which is a supporting system of receipts that enable record keeping and accurate distribution of digital goods. I have dealt with both of these concepts in detail in my reasons in the Apple proceeding.
5580 He also explained how the technology underlying each of these components is commoditized and can be replicated by third parties, preserving the same, if not greater, level of functionality and security as Google currently offers with Google Play Billing.
5581 Let me say something more about digital payment processing.
Digital payment processing with APIs
5582 Digital payment processing describes the system by which money gets transferred between a buyer and seller over the internet and the core system by which in-app digital purchases of goods are processed. I have discussed this in my reasons in the Apple proceeding.
5583 Google Play Billing generally follows a payment processing flow that is similar to the diagram set out in my reasons in the Apple proceeding.
5584 In Google’s case, the payment solution’s acquirer is WorldPay, a third-party payment gateway used by Google in Australia. Additionally, the digital payment solution includes Google’s integration with Worldpay.
5585 Now as I have said in the Apple proceeding, for payment requests to be made through a digital payment solution, application programming interfaces (APIs) are used.
5586 APIs are ubiquitous on the internet as they govern much of the functionality for information sharing. So, when booking a flight through a third-party travel site, an API enables the communication between the airlines and the travel provider. This same idea applies for digital payment processing, which rely on APIs to communicate between apps, payment gateways, and the banks. And companies such as Square, Stripe, Adyen and Braintree specialise in developing digital payment solutions and offer them as a service to other companies. They are alternatives to Google Play Billing that offer the same level of functionality and security.
5587 Digital payment processing also involves the movement of funds from the buyer’s bank to the seller’s bank. In the case of in-app purchases, the digital payment solution acts as the mediator that collects these funds and disburses it to the seller.
5588 Though APIs provide the foundation for digital transactions between multiple parties, modern digital payment solutions incorporate other technologies to ensure that transactions are executed securely and legitimately. In particular, digital payment solutions generally incorporate data protection processes to keep sensitive data from becoming exposed and include fraud management systems to help detect and resolve cases of payment fraud. In addition, digital payment solutions offer integration with a variety of different payment methods to be supported.
5589 The use of digital payment solutions in this manner is not unique to the Android platform, or even to mobile devices. Game console platforms such as PlayStation, Xbox and Nintendo rely on integrated online services and digital payment solutions to facilitate digital payments for games, downloadable content, and in-app purchases.
5590 To make payments, users typically link a payment method, such as a credit card, debit card, or PayPal, to their gaming account. When users proceed with a purchase, their transaction is managed by a digital payment solution just as it would be on mobile devices. As with mobile devices, upon successful payment processing, the purchased content is added to the user’s account library, from which it can be downloaded to the game console.
5591 As I have discussed in the Apple proceeding, modern payment processing implementations must serve two key functions being to provide core services to facilitate error-free transactions, and to protect against malicious behaviour, either in the form of data breaches or attempts at payment fraud.
5592 The technology underlying transaction facilitation is the digital payment solution’s APIs, which allow merchants and customers to interact with the payment service. In particular, APIs enable two of the key features of a digital payment solution discussed: the payment gateway and the checkout interface.
5593 In terms of protecting against malicious behaviour, fraud detection algorithms and chargeback handling system power the third key feature of a digital payment solution being the fraud management system.
5594 Finally, data breaches and compromises throughout the digital payment solution are protected against by compliance with data protection standards.
5595 Now in terms of APIs I have also discussed this matter in my reasons in the Apple proceeding.
5596 Professor Somayaji’s table 27, which I have set out below, compares the five digital payment solutions across a number of key payment API features. As the table shows, Google Play Billing’s and peer platform’s APIs implement many of the same key features. From a feature or security standpoint, there is no fundamental functional advantage that Google Play Billing’s API offers over third-party APIs.
5597 As shown by table 27, although the API features differ at the margins, the functionality afforded by APIs from third-party digital payment solutions is similar to Google Play Billing. A number of common features which are supported by third-party digital payment solutions, such as third-party platform integration, payment tokenization, and merchant verification, are not supported by Google Play Billing.
5598 Since the APIs are ultimately used to process the transaction, third-party digital payment solutions process a transaction in much the same way as Google Play Billing.
5599 Now as discussed in the Apple proceeding, data protection is ensured using established industry standards, which in the case of digital payment solutions, is the Payment Card Industry Data Security Standard. PCI DSS level 1 certification demonstrates the highest and most reliable level of compliance and is held by many popular payment solutions, including Stripe, Square, Braintree, Adyen, Shopify, PayPal and WePay.
5600 In order to maintain compliance, payment information with Google Play Billing is encrypted information and stored in a specialized database, which also stores the relevant payment information from the merchant. Similar to other payment solutions, this payments center is also Level 1 PCI DSS compliant.
5601 Let me say something about fraud management which I have discussed in the Apple proceeding. Let me add the following.
5602 Google Play Billing provides a basic chargeback protection to all merchants that use Google Play Billing. When Google receives a chargeback request, the resolution can take one of two options. For some transactions, Google will dispute the chargeback on behalf of the merchant. The final authority for such decisions is the issuing bank of the buyer. For other transactions, Google offers a refund to the user and deducts the amount from the merchant’s account.
5603 Unlike the other payment solutions, there is no dedicated API that can be used to supply evidence or dispute other chargebacks, which are not disputed by Google. In this case, Google becomes the final authority as the merchant cannot dispute the transactions that are refunded by Google. This is summarised in Professor Somayaji’s table 29 below.
5604 There is no complex technology required for chargeback management; the chargeback process is one that comes from card companies rather than technology companies. The key difference between Google Play Billing and other payment services is that for transactions not disputed by Google, Google Play Billing defers to a Google-run chargeback system, and treating them as a refund where Google is the decision making authority, as opposed to allowing the banks to handle chargeback requests, as other providers do.
5605 But from a device integrity or data security perspective there is no meaningful advantage to having an independent chargeback process. This difference is primarily one of payment-solution-level policy on the part of the digital payment solution provider. According to Professor Somayaji, Google Play Billing’s approach to chargeback management does not afford users any unique benefits in terms of technical security; I have no good reason to doubt that evidence.
5606 Let me say something about anomaly detection, although I have discussed this in some detail in the Apple proceeding.
5607 Based on various data inputs, anomaly detection mechanisms will assess the likelihood that a given transaction is fraudulent, and either permit it or void it on that basis. More information on the anomaly detection tools used by Google Play Billing, Stripe, Square, Adyen and Braintree is provided in Professor Somayaji’s table 31 below.
5608 Stripe and Google Play Billing both claim to have saved their merchants hundreds of millions of dollars through their fraud detection systems. Of course, exact implementation details of each fraud detection algorithm are not publicly disclosed. But there is no technical reason why Google Play Billing would be substantially better at fraud detection than other major digital payment solutions.
5609 Machine learning algorithms like the ones used in fraud detection tend to get better with more data, but there is no reason to believe third-party providers have a deficiency of data points. Braintree, for instance, processes more than 4 billion transactions annually on its platform. In 2017, Adyen reportedly processed 3.7 billion transactions.
5610 Further, additional data is available to digital payment solutions beyond just payments they have transacted. Stripe, for instance, claims to intake data from financial partners Visa, Mastercard, and American Express to help tune their fraud detection models. Braintree incorporates data from PayPal transactions when making fraud detection decisions.
5611 Further, as I have said in the Apple proceeding, 3D Secure (3DS) is a standard protocol developed by Visa and is now in use by most card providers. 3DS essentially adds another layer of security by adding a “challenge” layer to the processing of the payments. If enabled, the payment gateway alerts the cardholder’s bank if the transaction requires additional authentication. The bank then sends a one-time code that needs to be entered to verify and complete the transaction. Square and Stripe offer 3DS integration.
5612 3DS2, offered by Stripe, is a successor to 3DS that enables a more frictionless experience for the client. This is achieved using additional data points to assess the risk level of the transaction. On the basis of the risk level, the bank takes a decision to either allow the transaction or challenge the transaction and require additional input from the customer. This in turn prevents any client losses that can happen from having multiple redirections from the client.
5613 Further, Google Play Billing is not immune to security weaknesses, and has had its fraud system exploited in the past.
5614 An additional consideration for digital payment solution providers and merchants is that there can be costs of anti-fraud measures in terms of cart abandonment. Additional checkout screens and verification steps can reduce customers’ willingness to complete the transaction.
5615 From a technical security perspective, it is Professor Somayaji’s opinion that Google Play Billing’s anomaly detection features do not offer a demonstrable security benefit to merchants and end users over offerings from major payment solutions peers. I have no reason to substantially doubt that evidence.
Payment method support
5616 In the case of Google Play Billing, payments are charged through the payment method associated with the user’s Google ID if stored or the system allows them to input a new payment method at checkout. Third-party digital payment solutions like Stripe and Square support a number of different payment methods at the point of checkout, from manual card entry to alternative methods. A table comparing available payment methods in Australia for Google Play Billing, Stripe, and Square, Braintree and Adyen is shown in Professor Somayaji’s table 32:
5617 As can be seen from table 32 above, all of the above accept a wide range of payment options.
5618 Let me now say something more concerning digital inventory management.
Digital inventory management with databases
5619 As I have said in the Apple proceeding, in the world of physical goods, managing inventory entails a multitude of considerations, including how much product has been received from suppliers, how inventory is distributed across physical locations, and how much product has been purchased or otherwise removed from inventory at each physical location. In the world of digital goods, the problem of managing inventory is much simpler.
5620 Digital products such as magazine subscriptions and songs have infinite inventory in the sense that they can be copied and delivered to consumers as many times as the merchant wants without draining a stockpile of supply. The only constraint on delivering digital goods is to restrict access only to customers who have purchased them. So, digital inventory management boils down to the maintenance of records associated with a customer regarding what they have and have not purchased.
5621 Whilst developers today use a wide variety of programming languages, SQL is the dominant language for updating and querying databases, whether they are small, moderately sized or very large. Similar to databases, SQL was developed decades ago in the 1970s.
5622 Database technology is ubiquitous and a commodity. Whilst many web resources are stored and distributed as files, most modern websites generate web pages dynamically using data stored in a database. Whether it is a blog, a wiki, a news site, social media service or a web-based word processor, the core data that is displayed to a user is normally stored in a database. Databases are also used to keep track of purchases of digital content.
5623 Google Play Billing stores relevant information about transactions through the Play Store. Optionally, if the developer enables the use of an additional server, this information through the Play Store can be used to validate transactions more securely. The primary method to use this functionality is through what is known as a purchase token which is a unique combination of the user ID and the product purchased. This implementation of digital inventory management is similar to a receipt-based inventory management system used by the other digital payment solutions.
5624 The goal of digital inventory management is to maintain records associated with a customer regarding what they have and have not purchased. This functionality is separate from but complementary to core payment processing functionality which allows merchants to accept payments in-app.
5625 Google Play Billing, Stripe, Square and Braintree all provide digital purchase receipts containing information related to past transactions, which can be accessed through their respective API endpoints. Adyen also provides receipt like objects for the merchant to maintain their own record keeping.
5626 There are immaterial variations in the manner in which each digital payment solution handles digital inventory management around subscriptions invoicing and billing, but the basic flow of requesting a digital payment receipt is that the merchant app contacts the digital payment solution via its API to request payment history information, and that information is provided directly back to the app by the digital payment solution.
5627 For Google Play Billing, the digital inventory management integration is handled by the Play Store as part of the Play Developer API.
5628 Whenever a purchase is made, either of an app or a digital product within the app, the Play Store creates a purchase object, being “ProductPurchase” for one-time product purchases and “SubscriptionPurchase” for subscriptions, that is stored within the Play Store. From a technical perspective, this object is similar to a receipt in that it contains information pertaining to purchases made by the user such as a record of the product purchased or date of purchase.
5629 These records are used to determine what content should be provided to a user. The system determines a user’s entitlements and the delivery of those entitlements is left to the developer.
5630 Using the purchase object, the developer can identify the user, using the ID the developer provided during the initial processing stages, and the products successfully purchased by them. Once retrieved, these purchase objects can be used by the developer’s app to know what content to show the user based on what the user has paid for.
5631 Unlike other digital payment solutions, an additional step for developers using Google Play Billing is to “acknowledge”. This final step is required to indicate to the Play Store that a user’s entitlements are successfully provided by the developer. Any transactions not acknowledged by the developer are automatically refunded by Google.
5632 This system for inventory management used by Google Play Billing is in substance a receipt maintenance system and provides the same capabilities to developers as inventory management systems offered by other peers.
5633 Square and Stripe maintain payment receipts which serve as records of past purchases, much in the way that the Play Store does for Google Play Billing.
5634 For Square, whenever a transaction is sent to Square API, it is returned with a “Payment” object, which serves as a receipt for that transaction. Square also allows the merchant to access a list of these payments that contain all the information associated with purchases made.
5635 For Stripe, once a payment is initiated, Stripe issues its own “PaymentIntent” object which is updated during the processing of the transaction. Every such transaction is associated with a unique ID, which in turn is linked to the merchant specific key issued by Stripe. In this way, a merchant can retrieve all the information about a particular order stored in the PaymentIntent using the merchant’s specific key.
5636 For Adyen, the transaction is set up using an API call to initiate a payment session. Unlike Stripe and Square, the payment session is only to get a confirmation on completion of the transaction. Additional data such as the receipt of the transaction is sent to the merchant as a separate API for record keeping and inventory management.
5637 Braintree provides similar APIs to those of Stripe and Square. To process a payment, the merchant creates a “Transaction” object which contains the status of the payment process, as well as the relevant information about the transaction.
5638 A full account of the transaction information stored by each platform’s inventory management system is provided in Professor Somayaji’s table 33 below. As the table shows, digital inventory management functionality is quite similar across the five platforms. The functionality provided by Google Play Billing’s inventory management integration is similar to that of third-party solutions.
Technical and security feasibility of allowing third-party digital payment solutions
5639 Now Professor Somayaji considered the technical and security feasibility of allowing third-party payment services for in-app purchases of digital goods for apps distributed through the Play Store. He expressed the following views with which in substance I agree.
5640 Let me begin with the technical feasibility of enabling third-party digital payment solutions.
5641 I agree with Professor Somayaji’s view that the fact that the purchase of digital goods on the Play Store today is exclusively handled by Google Play Billing is a matter of policy restriction rather than technical limitation.
5642 In Google’s payments policy, Google expressly forbids the use of any alternative payment mechanisms for the sale of digital, in-app content within apps distributed through the Play Store.
5643 Android apps selling physical goods or services, such as Uber and Amazon, routinely use third-party digital payment solutions to seamlessly transact sales. From a technical standpoint, there is no difference between the mechanisms required to process payments for physical goods and for digital goods.
5644 Differences arise in how orders are fulfilled after payment, that is, whether the good is shipped from a physical fulfillment center or delivered digitally, but processing the actual payment for the product, for example, charging the cardholder a given amount, is independent of the nature of the product.
5645 At the margin, fraud detection mechanisms may vary between physical and digital goods. For instance, a shipping address in a different country from the payment address may be used to detect potentially fraudulent activity for physical goods.
5646 But on balance, implementation differences for fraud detection systems will not lead to meaningfully different security outcomes for users.
5647 Additionally, apps distributed outside the Play Store necessarily use third-party digital payment solutions for digital goods.
5648 From a technical standpoint, there is no difference between the mechanisms required to process payments for digital goods inside the Play Store and outside the Play Store.
5649 Further, before 2020, Google policy contained an exception that allowed developers to use alternative payment solutions for digital goods that could be consumed outside their apps, such as music that could be played on an external media player. This exception allowed popular app developers like Spotify, Hulu, and even the Google-owned YouTube to offer other payment solutions for in-app digital goods sales.
5650 Now although Google revised its guidelines in 2020 to eliminate this exception, the past use of alternative payment solutions by Spotify and Hulu highlights the technical viability of using different billing systems for Play Store apps.
5651 In fact, major digital payment solutions provide pre-built development kits to Android developers to help integrate their selected third-party digital payment solutions into Android apps. Stripe’s SDK, for instance, is documented with step-by-step instructions for installing, integrating, and deploying Stripe payments in Kotlin, which is a programming language for native Android apps. A screen from Stripe’s documentation on integrating with Android apps is shown in Professor Somayaji’s figure 35 below.
5652 From a technical compatibility perspective, there is no reason why Android developers would not be able to use third-party payment technologies to support in-app purchases of digital goods.
5653 Let me discuss the feasibility of collecting commissions with third-party digital payment solutions.
5654 Additionally, Professor Somayaji considered the extent to which applicable Google entities would be able to securely, reliably, and efficiently collect service fees from app developers using third-party digital payment solutions.
5655 In his opinion, with which I agree, there are a number of technical and contractual mechanisms that would allow Google to collect a commission even through a third-party digital payment solution.
5656 First, many third-party digital payment solutions have a specific feature to allow funds from digital payments to be distributed between multiple parties. So, Stripe’s “multiparty payments” feature allows payees to define logic by which a portion of payments they receive are distributed to other merchant accounts.
5657 In theory, either Google or the app developer could act as the primary merchant. If Google was the primary merchant, it would use multiparty payments to give the appropriate portion to the developer. If the developer was the primary merchant, it could use multiparty payments to give the appropriate portion to Google. Similar features are offered by Adyen and Braintree.
5658 Even without using any explicitly provided payment splitting feature, Google could implement a contractual system by which app developers are required to report in-app sales to Google and pay out proportionate commissions on a regular basis.
5659 In fact, for some countries and eligible developers that participate in the user-choice billing pilot, this model is already enacted by Google in some countries.
5660 Google’s implementation requires app developers to manually report all transactions completed for an in-app purchase using an alternative digital payment solution on a monthly basis. These transactions are used to calculate the fee owed to Google from commissions, which is charged to the merchant.
5661 A similar system is used by Apple in the Netherlands, where developers of dating apps are permitted to use third-party payment solutions as long as they report their transactions on a weekly basis and pay to Apple the agreed upon commission fee amount.
5662 Google has also developed a modular version of the Google Play Billing library, enabling developers to replace some of its modules with their own custom components. So, a developer could create a custom checkout screen and integrate it into the payment processing workflow for Play Store apps. With this modular library, developers can provide customers with a choice of payment processors and charge the corresponding commission. Such a modular library demonstrates Google’s technical capability to support alternative payment solutions on Android.
5663 Further, because Google already has an established model for collecting the requisite fees, it was Professor Somayaji’s opinion that either their existing contractual model or a technical model utilizing the payment splitting features available with many digital payment solutions could be used to reliably collect commissions on payments transacted with third-party digital payment solutions.
5664 Again, I accept Professor Somayaji’s views.
5665 Let me say something about security considerations with enabling third-party digital payment solutions.
5666 Stripe, Square, Braintree and Adyen are major software firms with developer security features as part of their payment software.
5667 Major payment services including Google Play Billing implement a standard set of technologies, including APIs to process the in-app purchases of digital goods, and supporting systems such as fraud management systems and digital inventory management systems to ensure safe delivery of the purchased goods.
5668 The earlier comparisons show that these features and services operate on similar tools with similar security technologies across platforms. For services that interact with sensitive card data, industry standards like PCI DSS ensure that the data is handled with rigorous security protocols in place.
5669 In general, payment fraud detection benefits from scale. The more transactions that can be analysed, the more easily fraudulent patterns of behaviour can be observed.
5670 Allowing third-party digital payment solutions would reduce Google Play Billing’s transaction volume. But it would increase the volume of other payment providers that already operate at a significant scale and process a wider variety of transactions.
5671 Third-party digital payment solutions may process digital payments on other platforms, such as iOS, web apps, and desktop applications, as well as in physical storefronts.
5672 For these reasons, it is Professor Somayaji’s opinion that the data security maintained by Stripe, Square, Braintree, Adyen, and similar services is comparable to the data security maintained by Google Play Billing. Again, Google has not put before me any sufficient reason as to why I should not accept Professor Somayaji’s evidence.
5673 Further, there are no technical barriers to using third-party digital payment solutions to process digital goods the same way third-party providers are already used to transact physical goods. The only restriction is one of policy, as seen through real-world examples.
5674 In addition to the previously described example of the policy exception that allowed Spotify and Hulu to utilize alternative billing systems up until 2020, Professor Somayaji considered further case studies.
5675 First, let me say something about YouTube. When Google began proposing the mandatory Google Play Billing policy on the Play Store, YouTube resisted migrating to Google Play Billing because it preferred its original payment method.
5676 When Google proposed to enforce a policy that would require all apps in the Play Store to use Google Play Billing by the end of 2018, developers and regulators complained that YouTube, which is Google’s first-party app, did not comply with that policy. Consequently, Google tried to convince YouTube to change from a custom payment solution to Google Play Billing. But YouTube resisted not only because migration to Google Play Billing would be costly for YouTube, but it would also limit YouTube’s freedom to innovate and adopt payment initiatives that better fit their business model.
5677 In fact, one of the solutions recommended in 2018 was for YouTube to remain on their existing payment solution but “match UX” to Google Play Billing.
5678 Similarly, a “mirroring option” was another potential solution in discussion which would have involved making YouTube’s payment flow “look and behave as a subset of Play’s buy-flow (as much as policy risk requires)” such that “3rd parties could not reasonably look at both flows and point to a difference that could be interpreted as an advantage for YouTube.” YouTube eventually migrated to Google Play Billing in 2022.
5679 Second, jurisdictions today have required Google to allow third-party digital payment solutions so that developers can use alternatives to Google Play Billing to accept payment for digital goods.
5680 In South Korea, to maintain compliance with regional regulations, Google has recently allowed third-party digital payment solutions for in-app purchases within apps on the Play Store.
5681 In South Korea, the Telecommunications Business Act prohibits digital platform owners from restricting developers from using alternative payment methods to transact mobile content. As a result, Google has allowed developers to offer alternative digital payment solutions alongside Google Play Billing for apps in South Korea. At checkout, users can choose whether their payment is handled by Google Play Billing or a third-party solution.
5682 To support this functionality, Google has provided mechanisms allowing developers to seamlessly integrate third-party digital payment solutions into their Play Store apps, demonstrating the technical feasibility of using third-party alternatives to Google Play Billing.
5683 Third, Google is now running a pilot program in which enrolled developers can use alternative digital payment solutions.
5684 In addition to jurisdiction-specific policies, Google has recently opened a billing pilot to select app developers allowing them to offer an additional billing system alongside Google Play Billing for Play Store apps.
5685 As the first developer to make use of the pilot, Google has a deal with Spotify wherein they can use alternative payment solutions alongside an option for the user to use Google Play Billing as well.
5686 Google has since expanded the pilot to more than 35 countries, including Australia.
5687 Like with South Korea, Google has created technical mechanisms for pilot members to allow users to select alternative digital payment solutions at checkout, and plans to further develop these mechanisms with automated APIs to facilitate third-party billing systems.
Android in-app payment solutions — market definition
5688 Google imposes and enforces a contractual stipulation that all developers must use Google Play Billing to facilitate in-app purchases of digital content within Play Store apps, which the parties have referred to as the payments tie.
5689 Google also imposes a contractual prohibition on Play Store apps from leading users to any payment method other than Google Play Billing, which the parties have referred to as the anti-steering rule.
5690 So, the effect of this conduct is that Google prevents developers from acquiring services other than Google Play Billing for the facilitation of payments for the purchase of digital content within Play Store apps.
5691 Now in summary I have found that Google has engaged in such conduct with the effect or likely effect of substantially lessening competition in the Android in-app payment solutions market.
5692 Now I agree with Epic that the market definition which best assists an assessment of that conduct is the market for the supply of services to app developers for the facilitation of payments for the purchase of digital content within Android apps. I will refer to this as the Android in-app payment solutions market.
5693 But if that market definition is too broad then, as Epic posits, in my view there is a narrower market for the supply of services to app developers for the facilitation of payments for the purchase of digital content within Play Store apps only. But having regard to the significant position of the Play Store, the Android in-app payment solutions market would be only marginally wider than such an alternative market and the difference does not meaningfully alter the market power analysis or the likely effects on competition of Google’s conduct in terms of imposing the payments tie and the anti-steering rule.
5694 For convenience, I will refer only to the Android in-app payment solutions market, although those references should be taken to include the narrower alternative market.
5695 Now before proceeding further I should note that there was some expert evidence relevant to the question of market definition and alternative payment solutions. I have already said something about Professor Asker and Ms Edwards-Warren. Let me say something about two other experts who were not economists but had expertise and experience in payments solutions.
5696 Mr Pascal Burg, a director of Edgar, Dunn & Co, a firm specialising in payments and digital financial services, had expertise in payment related topics and gave expert evidence for Google. He addressed Google Play Billing and responded to Mr Lance Blockley’s evidence.
5697 He also participated in a joint expert report with Mr Blockley and a separate joint expert report with Professor Somayaji.
5698 He was cross-examined by Mr Rich SC for Epic. Unsurprisingly, he was both unfamiliar with and incorrect about the relevant contractual matrix and the position of Google Payment Australia Pty Ltd. His characterisation of the relevant structure was incorrect.
5699 But there is no doubting the expertise and reliability of his evidence. But it is convenient to note here that some of his views were not fully consistent with an Edgar, Dunn & Co publication “Optimizing online payments to boost profitability” that was published around 2017 or 2018. He was a member of the team responsible for this publication.
5700 The report says:
As the world becomes more digital and borderless, payment is an increasingly important success factor for merchants. It is one of the key elements that can directly impact conversion rates. For example, consumers often abandon their purchases if the payment process is too cumbersome or their preferred payment methods are not available. Merchants need to have a robust payment strategy in place and be quick to leverage payment innovation to stay ahead of competitors. Today, with the emergence of new payment instruments and methods, consumers have no shortage of options. Merchants need to understand what this means to their business and how they can optimize their approach to payments, both to control costs and to drive incremental sales.
5701 So clearly flexibility and tailored solutions were considered to be desirable features.
5702 The report says:
In partnership with Adyen, Edgar, Dunn & Company (EDC), a global strategy consulting firm specializing in payments, has identified five best practices to increase overall profitability based on merchant and subject matter expert interviews and on quantitative analysis.
…
These five best practices include:
* Optimizing mobile payment experience to increase checkout conversion
* Localizing payment method selection to unlock customer segments
* Implementing a global acquiring strategy with a local approach
* Leveraging payment data insights to increase conversion rate and reduce cost of acceptance
* Using intelligent data-based approach to minimize risk and maximize revenue
5703 The report says:
When it comes to the payment flow, consumers in many markets prefer the ease and simplicity of a “1-click” or “1-touch” model, wherein they enter their payment details once, during sign-up or at the time of their first transaction. That information is then stored securely within the app, and for subsequent purchases, they simply press the pay button to complete the transaction. This allows consumers to focus on the shopping process rather than on checkout.
…
In the mobile world, merchants cannot afford more than one click. Consider the Uber experience, where the entire checkout process is “invisible.”
…
Establishing behavioral trends for individual users is a popular theme for advertisers, fraud-fighters, and user experience designers. But it is also a source of tremendous value in a merchant’s approach to payments. For example, an online food delivery marketplace knows what a user ordered at the same time last month, and can therefore confidently offer a 1-click flow for the same order made today. Holding onto and understanding customer preferences, and using that insight to continuously improve the checkout experience, is the kind of payments innovation that sets merchants apart and turns customers into promoters and brand loyalists.
5704 The report set out the following quote from the vice president of marketing at BlaBlaCar:
With Adyen, BlaBlaCar can provide a consistent experience across any device. Whether the user is paying in the native app, or via a mobile browser, the checkout has been designed to delight the user and drive conversions on any screen size. And, as all payments feed into the same system, BlaBlaCar can see transactions across all devices in a single view.
5705 Clearly that is not the case for Google Play Billing which cannot see across all devices.
5706 The report says:
Furthermore, Chinese payment method Alipay, with a reported 520 million active users worldwide in 2017, accounts for almost half of the $500 billion e-commerce market in China and has become extremely popular in markets where Chinese tourism thrives. In today’s world, where mobile devices play a central role in virtually any traveler’s journey, Chinese travelers are used to easily checking into their flights, reserving hotel rooms and shopping overseas, all from within the comfort of their mobile apps. For merchants looking to expand into China or to better serve the growing crowd of Chinese tourists in other markets, Alipay is a must-have payment option, along with other local payment methods such as WeChat Pay.
5707 Of course, Google Play Billing does not offer Alipay.
5708 The report says:
As mobile usage continues to grow, it is crucial for merchants to create a native in-app payment experience to increase conversion rates. This includes offering popular locally relevant payment methods and simplifying the checkout process with 1-click payment in friction-averse markets. Merchants also need to consider the impact to risk management and customer service practices that a mobile-first strategy may create.
…
… [It] is worth emphasizing that as merchants (regardless of size or industry) grow their businesses internationally, they need a payment acceptance approach tailored to each country to increase market reach.
…
Merchants need to take local habits into account as customer payment preferences may differ significantly from one country or region to another.
…
While keeping customer preferences in mind, merchants should consider their own business model when evaluating payment methods.
5709 Of course, Google Play Billing does not consider or permit this.
5710 The report says:
Depending on their size, merchants may have different objectives. For instance, the key focus for a large merchant in the U.S. may be on customer experience (e.g. checkout look and feel). Since Europe and Asia Pacific are more diverse, market reach and acquiring strategy tend to be more important to merchants in those markets. Small and mid-sized merchants may be more concerned about speed to market via a quick and seamless integration across different countries, where a larger enterprise may prioritize an efficient entity structure for tax purposes.
…
Local forms of payment are essential to unlocking customer segments and generating incremental sales in large e-commerce markets such as China, Brazil, Germany and the Netherlands. Still, merchants need a payment acceptance approach tailored to each country in which they operate. “One size fits all” does not apply to payments: offering too many payment methods or unused payment methods will clutter the user experience and most likely decrease conversion rates. In addition, merchants might consider A/B testing to fine-tune the relevant payment acceptance policy for their business.
5711 Clearly, being locked into Google Play Billing impedes the optionality and flexibility being discussed in the report for both developers and users. Further, it would seem that there is significant demand for optional and flexible payment solutions from both developers and users.
5712 And such observations, albeit with some adjustment, can also be made concerning Apple and IAP.
5713 Mr Lance Blockley, a management consultant since October 1988 with expertise in payments related assignments and payment solutions, gave expert evidence for Epic in both the Apple proceeding and the Google proceeding.
5714 In the Apple proceeding he focused on IAP and in the Google proceeding he focused on Google Play Billing. In the Google proceeding he also responded to Mr Burg’s evidence.
5715 In the Apple proceeding he was cross-examined by Mr Free SC and in the Google proceeding he was cross-examined by Mr Yezerski SC. He gave cautious and careful evidence. And he participated in a joint expert report with Mr Burg.
5716 I should note that it was common ground between the experts that Google Play Billing was more than just a payments solution, which is to state the obvious. Google Play Billing has structurally different customised features, including non-payment related functions, to say Adyen or Stripe.
5717 Further, it was not in doubt that some small developers may prefer to use Google Play Billing as a “one stop shop” in preference to some payment solution providers who may not offer the full suite of services and functionality desired.
Google’s arguments
5718 Now as Google correctly identified, the first issue in dispute with respect to Epic’s pleaded Android in-app payments solution market is whether it is appropriate to view in-app payment solutions as a separate product so that such a market can exist, and if so, the second issue in dispute is whether that market should include out-of-app payment solutions as a close competitive constraint. Let me deal with the first issue at this point.
5719 As to the first issue, Ms Edwards-Warren proposed two criteria for determining whether in-app payment solutions are a product that is separate and distinct from the services that the Play Store provides. The first criterion is whether it would be technically possible to supply the product separately. The second criterion is whether there would be demand to acquire that product separately.
5720 But Professor Asker proposed an additional criterion, namely:
Is it more efficient (i.e., output expanding) to supply the components of the bundle as a pure bundle absent the challenged conduct at but-for prices? This question asks whether production efficiencies exist because of, e.g., reductions in transaction costs or production costs via bundling regardless of the price charged.
5721 Ms Edwards-Warren did not accept that Professor Asker’s efficiency criterion was a relevant criterion for assessing whether there is a single product or separate products.
5722 So, the dispute on this issue reduces to whether the efficiency criterion is relevant to the analysis and if so what flows from it, and whether the evidence shows that the demand criterion is met.
5723 Google says that the efficiency criterion is relevant and that it shows that the relevant question is whether there would be meaningful demand under the conditions on which app stores would rationally unbundle their app store services. Google also says that there is no evidence that such meaningful demand exists. As such, the pleaded Android in-app payment solutions market does not exist.
5724 Google says that Professor Asker’s efficiency criterion is both grounded in economics literature and consistent with orthodox economics. It made the following five points.
5725 First, Professor Asker cited two articles from the published literature on bundling for his efficiency criterion.
5726 The first article was M Salinger, “A Graphical Analysis of Bundling” (1995) 68(1) Journal of Business 85 from which Professor Asker drew the proposition that bundling left and right shoes presumably conserves on packaging and inventory costs, which is part of the explanation for why left and right shoes are sold as a bundle.
5727 The second article was D Evans and M Salinger, “The Role of Cost in Determining When Firms Offer Bundles” (2008) 56(1) The Journal of Industrial Economics 143 from which Professor Asker drew the proposition that bundling lowers marginal costs and can avoid the fixed costs of distinct product offerings. In other words, there are typically production and distribution efficiencies associated with supplying products as a bundle.
5728 So, Google says that given that principles of economics assume rational firms, it is economically sound to consider what efficiencies bundling entails, and what efficiencies would be lost by unbundling, because they may affect whether firms would unbundle.
5729 Second, Professor Asker referred to the ACCC merger guidelines as supportive of his efficiency criterion. Google says that paragraphs [4.41] and [4.44] of the guidelines are consistent with the efficiency criterion for bundling. Paragraph [4.41] introduces the possibility that the purposive nature of market definition can require a market that extends beyond what can be substituted for products of the merger parties to “other products that are typically purchased or supplied together with those of the merger parties”. Paragraph [4.44] states that in determining whether there should be separate disaggregated markets or one aggregated market for a product that is generally purchased or supplied together, the ACCC considers among other things “the costs involved in purchasing or supplying the product separately”.
5730 In other words, it is said that it is relevant to consider cost efficiency when deciding whether to define separate markets, or an aggregated market, for products that are typically supplied as a bundle.
5731 Third, Professor Asker explained the economic logic of his efficiency criterion. His report provides three examples which identify how production efficiencies can explain why certain products are supplied as a bundle. It also provides an explanation of the economic logic, that is, if components are close complements and give rise to sufficient product and distribution efficiencies, they would nearly always be supplied as a bundle.
5732 Professor Asker explained that an economist needs to look at both the demand-side and supply-side to assess what the likely market outcome would be. And in order to assess what the market equilibrium would be, that is, where supply and demand meet, one obviously needs to understand the nature of the supply curve as well as the demand curve.
5733 Fourth, Google says that the reason why it is necessary to focus on what app stores like the Play Store would do if they were to unbundle their payment solution is because the developer still would need to acquire the distribution part of the app store service even if it were to acquire a third-party payment solution. So, it is necessary to understand the price at which the unbundled distribution part of the app store service would be supplied, and whether at that price there would be any material demand for acquiring a separate payment service from a third-party. If not, there would be no separate supply.
5734 And Google points out that Professor Asker said “[t]he question is in a – in a competitive – competitively anodyne market, what would the offering of the app stores be?”. He went on to explain:
… the issue is whether the payment system is properly part of the services provided by the app store, and it goes to the question of whether an app store in a position of considerable competitive pressure would offer the payment system separately, which – you know, for instance in a way that facilitates mixed bundling so that it would offer the opportunity for a – another payment system to – to come in …
5735 In other words, would the app store set a price for the unbundled distribution part of the service that would entice sufficient developers to acquire a third-party payment solution such that a supplier of third-party payment solutions would enter?
5736 Fifth, Google says that most significant app stores, both on mobile and other platforms, self-supply their billing system and do not unbundle it, that is, they do not permit the use of third-party payment solutions. Professor Asker considered this to be evidence of significant supply-side efficiencies associated with Google Play Billing being supplied as part of a bundled product and that this tells against Google Play Billing being a separate product.
5737 Finally, it is said that the fact that supply-side efficiency is relevant to whether the hypothetical monopolist app store would unbundle their payment solution means that it is important to consider on what commercial basis Google would be prepared to unbundle Google Play Billing from the Play Store. That is, how would the hypothetical monopolist continue to monetise the unbundled distribution part of app store service? There would need to be significant demand under those conditions before it could be said that the payment solution, that is, Google Play Billing, can be viewed as a separate product. Google says that Epic has provided no evidence that this is the case.
5738 Let me turn to another question and Google’s argument that there is no separate demand for the payment solutions product.
5739 Epic says that there was a wide body of evidence that developers do have demand to acquire a payment solution separately, and it emphasised the fact that there were 5,000 developers who were using another payment solution before Google amended its payments policy to make it clear that they were required to use Google Play Billing.
5740 But Google says that this is misconceived. It says that the relevant question is not whether there would be demand for a separate payment solution under any conditions, but rather whether there would be meaningful, separate demand under the conditions in which app stores would in fact unbundle the component parts of their service.
5741 And Google goes so far as to say that none of the evidence on which Epic relies establishes any meaningful demand in the relevant sense. It made the following points.
5742 First, Google says that the evidence of demand to which Epic points mostly entails developers wanting to use, or in fact using, a separate payment solution with the Play Store in circumstances whereby doing so they avoid paying the service fee altogether.
5743 It is said that this is not evidence of meaningful, separate demand, because it does not reflect the conditions on which Google, or any economically rational app store, would be prepared to unbundle their service.
5744 The demand which exists only if developers receive a very large discount does not reflect what demand would exist if developers received a smaller discount for using a separate payment solution. So, even with evidence of demand when the service fee can be avoided, there potentially would be different or no demand when only a smaller discount is offered.
5745 Now Google says that the 5,000 developers who used a payment solution other than Google Play Billing prior to Google amending its payments policy in January 2021 were doing so in circumstances where they did not have to pay the service fee. And it says that there is no evidence that those developers would have demanded the option of using an alternative payment solution if they still had to pay the service fee or a large proportion of it. It says that the evidence of the take-up of UCB suggests the opposite.
5746 Likewise, the 5,908 Play Store apps that Google warned developers about, suspended or rejected prior to clarifying its payments policy in January 2021 are examples of what app developers did when they could avoid the service fee altogether by using an alternative payment solution. Google says that it is not evidence of meaningful, separate demand under commercially realistic conditions.
5747 Further, Google says that developers demanding or using an alternative payment solution in circumstances where they could avoid paying the service fee is not evidence of meaningful, separate demand under commercially realistic conditions. It says that the examples where developers could avoid the service fee merely reflect what happens when developers, in effect, can take up the option of a separate payment solution at a large negative price relative to what they pay when using the bundled app store service. That is, they are better off to the amount of 15% or 30%, less whatever cost they incur in obtaining the separate payment solution.
5748 But Google says that this is not commercial reality, because the economically rational app store still would need to monetise the unbundled remaining part of their service, and would need to charge developers for using it.
5749 Second, Google says that Epic’s reliance on the fact that developers use separate payment solutions when they offer in-app purchases of physical goods and services is also beside the point. This is a situation where the Play Store offers no mechanism at all for dealing with payments for these types of goods and services, because Google Play Billing is a feature of the Play Store that cannot be used for in-app purchases of physical goods or services. So, Google says that it is not evidence of demand by developers in a situation when Google Play Billing can be used. This is particularly so, because it is also another situation where demand exists when the developer is not paying the service fee. Developers might choose Google Play Billing if it were available.
5750 Third, Google says that the same position follows in relation to the 15 or so countries where Google does not offer Google Play Billing at all. The fact that developers in those countries use a different payment solution is because they cannot use Google Play Billing. It does not demonstrate that such demand would exist if Google Play Billing was integrated in the service provided by the Play Store in these countries.
5751 Fourth, Google says that as to Epic’s reliance on the fact that the ONE Store and Samsung Galaxy Store offer their app store services without requiring developers to use their in-app payment solution as evidence that the payment solution is a separate service, ONE Store and the Samsung Galaxy Store are both operated by Korean firms and Korea has legislated to require platforms to unbundle payment solutions.
5752 Further, Google says that Epic has not pointed to any evidence of the extent to which developers have taken up the option of using an alternative payment solution on the ONE Store and that Epic has provided no evidence of any meaningfully separate demand for alternative payment solutions.
5753 Fifth, Epic has relied on Google’s experience with its UCB and DOB programs, and Epic’s own experience with allowing developers to use their own payment solution on the Epic Games Store, as evidence of meaningful, separate demand. But Google has made the following points.
5754 As to the Epic experience, developers who use the Epic Games Store pay a commission of 12% on in-app purchases of digital content and have the option of avoiding that commission altogether by using an alternative payment solution. But Google says that notwithstanding this incentive to fully avoid paying the commission, the majority of developers have not taken up this option to date. Of the approximately 1,100 third-party developers who distribute games on the Epic Games Store, less than 50 use an alternative payment solution. Google says that in other words, even when there is the opportunity to avoid a 12% commission, the overwhelming majority of developers do not take up the option.
5755 As to Google’s experience, developers who use alternative billing under UCB pay the service fee discounted by 4%, and developers who use alternative billing under DOB pay the service fee discounted by 3%.
5756 As at 11 October 2022, 103 app developers have applied to use an alternative payment solution under UCB in South Korea, 29 non-gaming app developers have applied to use an alternative payment solution in the EEA under DOB, and 19 app developers have applied to use an alternative payment solution under UCB in the EEA, Australia, India, Indonesia and Japan.
5757 Google says that this is not evidence of any meaningful demand for alternative billing compared to Google’s competitive offering when, as at 31 October 2022, there were over one million developers who publish approximately 3.2 million apps on the Play Store in Australia, of which hundreds of thousands monetise via the sale of in-app digital content.
5758 Google says that the fact that there is some take-up of UCB and DOB shows that the 3% and 4% discounts are not prohibitively low, but the magnitude of the take-up demonstrates that there is no meaningful demand for alternative payment solutions.
5759 Sixth, Google says that as to the evidence from Mr Owens of Paddle to the effect that he has received requests from customers to use Paddle’s payment platform for sales of digital content within apps published via the Play Store, during cross-examination Mr Owens conceded that a single-digit percentage of enquiries convert into paying customers and the examples he exhibited to his affidavit were not examples of current or meaningful demand for Paddle to provide payment or billing services for in-app purchases in the Play Store.
5760 Accordingly and in summary, Google says that Epic has not established that there is meaningful, separate demand for separate payment solutions under any commercially realistic scenario in which app stores like the Play Store would unbundle the payment solution from the rest of the services which they supply.
5761 Google says that the demand-based bundling condition for defining a separate product market is therefore not satisfied, and the pleaded Android in-app payment solutions market does not exist.
Analysis – separate product
5762 Now generally speaking I agree with Epic that because the alleged contraventions concern contractual requirements to use Google Play Billing to facilitate payments for in-app purchases of digital content, and contractual prohibitions on offering or leading users to alternatives to Google Play Billing, it is appropriate to begin with a product market which incorporates Google Play Billing.
5763 Now because Google only supplies Google Play Billing as part of a bundle and Google denies that Google Play Billing is a separate product, it is necessary to begin by discussing the criteria for identifying a separate product.
5764 Now I should say upfront that I agree with Epic that from an economic perspective, two products are separate if two conditions are satisfied.
5765 First, it must be technically feasible for them to be supplied separately.
5766 Second, there must be distinct demand for each product in the absence of tying, such that some customers would acquire each product without the other attached.
5767 Now Professor Asker posited a third criterion, namely, whether it is more efficient in terms of being output expanding to supply the components of the bundle as a pure bundle absent the challenged conduct at but for prices. If it is more efficient to supply the components of the bundle as a bundle, he said that those components should be treated as a single product.
5768 But I agree with Epic that this so-called bundled products additional criterion is not an accepted economic principle for conducting a competition assessment. Moreover, the academic literature that Professor Asker cited in support of the criterion mention cost savings due to bundling but do not claim, or support the argument, that such cost savings imply that the components of the bundle cannot be distinct products.
5769 Nor is there any competition or anti-trust regulator in any jurisdiction that applies his bundled products additional criterion.
5770 And Professor Asker has never given a coherent explanation for why his bundled products additional criterion should be applied.
5771 In the joint expert report, Professor Asker said this criterion operationalised an approach which asked what would arise in a competitive equilibrium, that is, market outcomes in the but for world. He added that if in a competitive equilibrium firms would continue to primarily supply components as a single bundled product, then it makes sense to view the bundle as a single product.
5772 Yet the only firms Professor Asker had in mind were app stores. He did not squarely address whether alternative suppliers of payment solutions such as Adyen or Stripe would be prepared to supply payment solutions to developers absent the payments tie.
5773 Instead, he framed the relevant supply side inquiry as one focused on what the app stores are likely to do absent the relevant conduct. When pressed as to why he was examining the issue from the perspective of one type of supplier, Professor Asker had no persuasive answer.
5774 A reason why I have rejected Professor Asker’s approach is that the buyer of a payment solution is the developer. Professor Asker accepted this.
5775 It follows that whether it is more efficient for Google, or for any other app store, to supply a payment solution as part of a bundle with its distribution services tells one nothing about whether there would be separate demand from developers for a payment solution.
5776 There is no reason to assume that what is efficient for Google, or another app store, is necessarily efficient for an individual developer choosing between payment solutions. Nor will the many payment solution providers who are not app stores make decisions as to whether to supply Android developers based on what is efficient for Google, or any other app store.
5777 I reject Professor Asker’s bundled products additional criterion.
5778 Further, it is not in doubt that it is technically feasible for Google Play Billing and alternative payment solutions to be supplied separately from the distribution services that are supplied through the Play Store.
5779 Not only is that feasible, but it already occurs. Some 97% of developers distribute their Play Store apps without Google Play Billing, and 95% of Play Store apps do not use Google Play Billing. These are free apps or apps that sell physical goods and services. The latter are prohibited from using Google Play Billing and use alternative payment solutions.
5780 Additionally, distribution services are supplied via the Play Store in respect of apps that use alternative payment solutions in the context of the UCB and DOB programs, and in the 15 or so countries in which the Play Store distributes apps but Google Play Billing is not offered.
5781 Let me now deal with the separate topic as to whether there is distinct demand for a payment solution. I should say upfront that as to whether there is distinct demand for a payment solution, such that some customers would acquire each product without the other attached, in my view this is well-established by the evidence. Epic made ten points which I largely agree with.
5782 First, even now, developers of Play Store apps acquire app distribution services from different Google entities than those from whom they acquire services that facilitate payments for in-app purchases of digital content within Play Store apps. They do so under separate contracts whereby the supplier of services that facilitate payments for in-app purchases of digital content acts as an independent contractor, and not as agent of either the supplier of app distribution services or of the developer.
5783 The way Google has constructed its own contractual arrangements is inconsistent with the proposition that app distribution services and Google Play Billing are one product.
5784 Second, developers that offer in-app purchases of physical goods or services within apps distributed through the Play Store have always acquired and continue to acquire app distribution services from Google, whilst acquiring a payment solution separately from a third-party supplier or suppliers or developing their own payment solution, including by acquiring components from third-party suppliers.
5785 In that context, app distribution services and services that facilitate in-app purchases of physical goods and services are plainly separate products. Moreover, payment solutions that facilitate payments for digital products are largely the same as those that facilitate payments for physical products.
5786 So, there is no sound basis for asserting, as Google does, that Android app distribution services and in-app payment solutions are separate products where the payments being facilitated are for physical goods or services, but are not separate products where the payments being facilitated are for digital goods or services. In each case, the putative products are largely the same. Google’s argument is commercially counter-intuitive.
5787 Third, before Google removed the external consumption exemption from its payments policy in January 2021, around 5,000 developers had chosen to use a payment solution other than Google Play Billing to facilitate in-app purchases of digital content within Play Store apps. Google expected more to follow, with an increasing number of developers “actively de-integrating” and using alternative payment solutions.
5788 Google seeks to dismiss this historical demand on the basis that it only existed because developers wanted to avoid the service fee. It is not easy to understand why demand becomes irrelevant if it is driven by a desire to pay a lower price to an alternative supplier. But in any event, Google’s documents show that many developers considered Google Play Billing to be a deficient product, unsuited to their own businesses and strategic needs.
5789 Indeed, some large developers were so keen to use an alternative payment solution that they were prepared to do so even if there was no reduction at all in Google’s service fee.
5790 Fourth, under the UCB and DOB programs, developers can and do acquire app distribution services from Google and acquire services for the facilitation of in-app payments from alternative suppliers.
5791 Between November 2021 and October 2022, 103 app developers in South Korea sought to integrate an alternative payment solution into their apps.
5792 Between 1 September 2022 and October 2022, 19 developers of non-gaming apps sought to integrate an alternative payment solution into their apps pursuant to the UCB pilot program.
5793 Between 19 July 2022 and October 2022, 29 app developers applied to Google to use a payment solution other than Google Play Billing, pursuant to the DOB program.
5794 Google has sought to make something of the relatively low take-up of these alternative solutions. But having regard to the pricing and other characteristics of the UCB and DOB programs, it is remarkable that some developers have nonetheless sought out alternative sources of supply.
5795 Moreover, regardless of numbers, the services that developers are acquiring from alternative suppliers of payment solutions for use in the UCB and DOB programs are separate from the app distribution services supplied by Google through the Play Store.
5796 Fifth, ONE Store, a mobile app store available on Android, and the Samsung Galaxy Store both offer Android app distribution services and an in-app payment solution for sales of digital content without requiring developers to use the latter service.
5797 The app distribution services which they supply are separate and distinct from their respective in-app payment solutions. If those services are separate when supplied to Android app developers by ONE Store and Samsung, they are separate when supplied by Google.
5798 Sixth, developers that distribute PC apps through the Epic Games Store can use payment solutions other than EDP to facilitate payments for in-app purchases of digital content. Various large game developers do so.
5799 Since around August 2021, developers that distribute PC apps through Microsoft’s Windows Store have also been able to use their own or a third-party payment solution for in-app purchases of digital content.
5800 There is no reason to think that these developers and others would not similarly use alternative payment solutions within their apps distributed through the Play Store.
5801 Now a relatively small portion of developers on the Epic Games Store have chosen to use a third-party payment solution. But the point is that various developers have made that choice. The experience of the Epic Games Store demonstrates the existence of relevant demand. Further, those developers are all large developers, who are likely to account for a relatively large proportion of transactions and revenue that competing payment solutions might seek to attract.
5802 Seventh, Paddle has already received requests from customers to use the Paddle platform to support the sale of digital goods and services within Play Store apps. This is evidence of distinct demand for a payment solution to facilitate the purchase of digital goods and services within Play Store apps.
5803 Further, if Google were to permit developers to choose their own payment solution for in-app purchases of digital content within Play Store apps, Paddle would invest in developing its product for use within such apps.
5804 Further, a range of other entities besides Paddle including PayPal, Stripe, Adyen, and Braintree could and would provide payment solutions to compete with Google Play Billing if they were permitted to do so. I have discussed the detail of this elsewhere. Additionally, there was no reason why other suppliers of end-to-end solutions, such as FastSpring, Digital River, and 2checkout, which currently offer payment solutions on web-apps and native PC apps, could not also develop solutions to support payments for in-app purchases of digital content within Play Store apps.
5805 I am satisfied that there would be willing suppliers of alternative payment solutions to satisfy developers’ demand.
5806 Eighth, Google recognises that developers want the ability to choose their preferred payment solution. Google’s examination of billing optionality is predicated on the existence of demand amongst developers for choice in payment solutions.
5807 And it seems apparent on the evidence that many developers would choose their own billing system but for the compulsory condition that Google imposes on them.
5808 Further, there are multiple third-party providers of payment systems who likely desire to offer payment systems to Android developers.
5809 Indeed, there would likely be entry by suppliers of payment solutions such as Stripe, Adyen, PayPal, and others if Google did not require developers to use Google Play Billing. There would be competition within the space.
5810 Ninth, the existence of the payments tie and Google’s conduct in enforcing that tie and removing the external consumption exemption show that services for the facilitation of payments for in-app purchases of digital goods are indeed distinct from the app distribution services supplied by the Play Store.
5811 By January 2019, when the external consumption exemption still existed, Google had warned, suspended, or rejected some 5,908 Play Store apps for not using Google Play Billing. If Google Play Billing were not a separate product from the distribution services which Google supplies through the Play Store, Google would not need to mandate and enforce the use of Google Play Billing within Play Store apps, let alone warn, suspend, or reject almost 6,000 apps for using an alternative payment solution.
5812 Tenth, for businesses that monetise their products and services online, optimising payments is essential for growth and to stay ahead of competitors.
5813 Merchants need to ensure their payment systems take the characteristics of their business model and their customers into account when evaluating payment solutions. “One size fits all” does not apply to payments. Yet Google Play Billing is a one-size-fits-all product.
5814 Google Play Billing has not been designed or optimised to meet the needs of any individual developer’s business, apart from Google’s business. But what is optimal for Google Play Billing, or the entire set of developers distributing apps via Google Play Billing, may not be optimal for many of them taken individually. This makes it likely that there will be demand for alternatives to Google Play Billing.
5815 For many developers, Google Play Billing is not the optimal payment solution. It has features that some developers do not want or need, and lacks features that some developers desire.
5816 Many developers wish to have and maintain a direct relationship with their customers, including the ability to respond to questions and complaints and administer refunds directly. Google Play Billing does not offer this, but other payment solutions do.
5817 Further, many developers make their apps available in different channels and want a consistent user experience across those channels, as well as the ability to obtain analytics services in respect of their sales across those channels. Google Play Billing does not offer this, but other payment solutions do.
5818 Further, many developers wish to receive the proceeds of the sales of their products promptly after the sale occurs. Google Play Billing does not offer this. It retains the full amount of the purchase price until the fifteenth day of the following month for the previous month’s sales. But other payment solutions do offer this.
5819 Further, some developers want payment methods that Google Play Billing does not offer, such as Alipay, which is extremely popular in markets where Chinese tourism thrives. Google Play Billing does not offer Alipay, but other payment solutions do.
5820 Let me deal with some miscellaneous points raised by Professor Asker.
5821 Professor Asker advanced other contentions relating to the product dimension of the Android in-app payment solutions market that have no merit.
5822 First, he said that Google Play Billing does not meet the definition of a payment solution, because Google acquires some components of the product as inputs rather than developing and supplying them in-house.
5823 But I agree with Epic that whether Google outsources elements of Google Play Billing is irrelevant to the product dimension of the market. In any event, Google Play Billing includes multiple components of a payment solution and Google Play Billing provides a payment solution.
5824 Further, it is the essence of a payment solution that a firm connects a number of services provided by different suppliers and puts them into a coherent whole. It is not necessary for suppliers to develop or supply all components of their payment solutions in-house for their products to be a payment solution.
5825 Professor Asker also said that Google Play Billing does not meet the definition of a payment solution because it has features that other payment solutions lack. But the reality is that many of the services which Professor Asker said are unique to Google Play Billing are offered by alternative payment solutions.
5826 Further, as Epic points out, products do not need to be identical to be substitutable or closely competitive with one another. The fact that some have features that others do not indicates that there is product differentiation, which is a feature of most markets.
5827 There is no feature that only Google Play Billing could offer that is more attractive than what could be offered by another payment solution, beyond the fact that it is tied to the Play Store.
5828 Second, Professor Asker said that analysis of whether the Android in-app payment solutions market exists is aided by an analogy of transactions that occur, say, within Myer Melbourne, located as it would say in the fashion capital of Australia. He said that Myer Melbourne operates like the Play Store. Areas within Myer Melbourne in which certain branded products are shown operate like app developers. And the cash registers that Myer Melbourne operates are akin to Google Play Billing.
5829 But when consumers purchase products from Myer stores, they do so within the confines of a physical store that is owned or leased by Myer. In contrast, in-app purchases occur within the developer’s app. From a user’s perspective, the in-app transaction begins and is concluded inside the developer’s app, without visiting or otherwise engaging with the app store.
5830 When consumers purchase products from Myer stores, they acquire title to those products pursuant to a contract with Myer. When users of Play Store apps make in-app purchases, they acquire digital content from the developer pursuant to a contract with the developer.
5831 When consumers purchase products in Myer Melbourne, according to Professor Asker, they always use Myer’s payment solution. When users of Play Store apps make in-app purchases they do not use Google Play Billing when acquiring physical goods. They do not use Google Play Billing when acquiring digital products in 15 countries. And they have the option to use alternative payment solutions where the UCB and DOB programs apply.
5832 Third, Professor Asker referred to the hotfix episode that he said showed an absence of distinct demand for services for the facilitation of payments for in-app purchases, namely, the decrease in Play Store users’ spending in Fortnite that occurred when EDP was used following the hotfix, compared to before the hotfix when Google Play Billing was used.
5833 But I agree with Epic that that decrease in spending has no probative value for assessing whether there is distinct demand for Android in-app payment services because of the following matters. Epic rightly made the following points.
5834 The expenditure to which Professor Asker referred was expenditure by users. Demand for payment solutions comes from developers, not users.
5835 Further, the hotfix was an isolated event relating to one app. Any changes in user expenditure that occurred by reason of that event may be idiosyncratic and cannot be extrapolated so as to conclude that there is no demand from developers of other apps for alternative payment solutions.
5836 Further, changes in expenditure may not have been caused by the hotfix. Various factors may have caused or contributed to that change, including Fortnite’s removal from the Play Store and the Fortnite summer events that caused user numbers to spike in the period leading up to the hotfix.
5837 Further, when the hotfix occurred, users’ expenditure was already rapidly declining. And in-app expenditure increased immediately following the hotfix, rather than decreased.
5838 For the above reasons, in my view Google Play Billing is a separate product. But the next question that arises is whether there are any close substitutes. Let me turn to this issue.
Are there any close substitutes for Google Play Billing?
5839 Now Google says that even if Google Play Billing is a separate product, out-of-app payment solutions are a meaningful substitute for in-app payment solutions, and should be included within the separate market. Google makes the following points.
5840 First, Google says that the suggestion that the anti-steering rule or the cost of building an out-of-app payment function prevents developers from using this option is inconsistent with the evidence of developer practice. Many prominent developers, who account for significant spending on the Play Store, do in fact use an out-of-app payment mechanism.
5841 There are many apps including game apps which offer out-of-app purchases on websites, such as web stores and consumption-only apps like video streaming apps such as Netflix, Stan and Binge, for which the Play Store receives no service fee revenue when users subscribe outside the app.
5842 Second, Google says that the suggestion that the developer may need to incur some costs to set up an out-of-app payment mechanism on a website ignores the relevant cost-benefit analysis, namely that they would avoid the service fee when users make purchases via that channel.
5843 In around December 2020, Epic made Fortnite V-Bucks available for purchase on its website. Apple does not earn any commissions when a user purchases V-Bucks from Epic’s website on their iPhone and would not earn commissions from this transaction method if Fortnite were still on the App Store. The same would apply to the Play Store and other app stores like those on gaming consoles. So, the cost of making this payment mechanism available was no barrier to Epic doing so.
5844 In the Android ecosystem there are some out-of-app transactions on Android for which the Play Store does not earn a commission. In other words, leaving aside UCB and DOB, where the Play Store still collects its service fee less a discount, developers can set up an out-of-app transaction venue on a website and avoid paying the service fee. It is unlikely that the cost of doing so would be an obstacle when the service fee can be avoided.
5845 Third, Google says that the so-called frictions associated with out-of-app purchases to which Epic refers would need to be quantified and compared with the purchase frictions within apps.
5846 Google says that Epic has provided no evidence of any quantification of such frictions and how they compare to the frictions when making a purchase within an app. For example, in the case of Fortnite, users cannot purchase V-Bucks during game play, and in fact must exit to the Fortnite lobby to make the purchase. That is, there is friction either way when making a purchase of digital content, whether it is in-app or out-of-app.
5847 Now in my view out-of-app payment solutions are not a close substitute for in-app payment solutions because the anti-steering rule prevents them from being used, there are additional costs to build the solutions, and there are frictions for the user. Let me make the following points by way of elaboration.
5848 First, the anti-steering rule prohibits apps from leading users to other payment methods. The result is that developers cannot create convenient links to out-of-app payment solutions within their Play Store apps or even tell their users about the out-of-app solution via in-app promotions or user-interface flows. Rather, out-of-app payment solutions can only be implemented separately from the app. Consequently, to make an out-of-app payment, users will always face an additional cost of user discoverability and a requirement to navigate to an external link, at a minimum.
5849 Second, to offer an out-of-app payment solution, developers must build or acquire a solution that facilitates out-of-app payments. They may need to build a website and set up the supporting infrastructure for that website in order to accept out-of-app payments. This adds costs and complexity for the developer.
5850 Third, out-of-app payment solutions require the user to leave the app to make a purchase elsewhere. That creates a worse experience for users, who are more likely to complete the transaction within the app than if they must exit the app.
5851 Now it would seem from the evidence that it is generally accepted that the more clicks there are, the more likely a user is to abandon a flow. As Epic points out, leaving the app can be disruptive to users, takes more time and is often frustrating. And users prefer to stay in one environment when shopping in-app and online, and have concerns when new screens or environments appear. Each additional step reduces the likelihood of an out-of-app purchase.
5852 Notably, Apple has introduced biometric features on its iPhones, for example, thumbprint scanning and facial recognition to avoid these kinds of frictions. And there has been a material increase in the number of transactions undertaken by iOS users with iPhones that had those biometric features.
5853 Now Professor Asker said that some developers employ steering tools to direct consumer spending to webstores, but there is no substance to that assertion. Its only basis is a handful of examples of developers offering lower prices for a product on a website than a Play Store or App Store app. Professor Asker did not assess the extent to which users make purchases on those websites, let alone whether users treat them as substitutes for in-app purchases in Play Store or App Store apps. They would not.
5854 Professor Asker also said that developers can facilitate substitution from in-app purchases on Android devices to in-app purchases on non-Android devices by providing cross-platform functionality. This contention has no substance and I reject it.
5855 Let me deal with some other points.
5856 Professor Asker said that for Epic’s alleged markets to be sound, they would need to exist absent the impugned conduct.
5857 But this suggests that, in his view, an assessment of whether there are close substitutes to Google Play Billing for the supply of services for facilitating in-app payments for digital content should be conducted on the footing that the payments tie and anti-steering rule do not exist. But I agree with Epic that this view is incorrect.
5858 The commercial reality is the factual, being the real world in which the payments tie and anti-steering rule exist and constrain developers. As Epic says, to assume them away would be to define a market in which developers have alternatives that they do not actually have.
5859 It would be a hypothetical market in which developers and suppliers could behave entirely differently from how they can and do behave in the real world.
5860 Assuming away the payments tie and anti-steering rule would also assume away the competition problem that I am seeking to analyse. But as Ms Edwards-Warren cogently explained, if one were to assume the payments tie away, one would be conflating the market definition exercise with the effects analysis. This is because one would be attempting to establish what would have happened absent the payments tie during the market definition step, instead of defining the counterfactual during the effects analysis. Assuming away exclusionary conduct when defining markets in a tying case would cause a paradox. If one assumes away the tie and posits that there would be competition in the market, a monopolist would be found not to have market power, and so the tie could not be found to harm competition.
5861 Finally, given that the product dimension of the market is the supply of services to app developers for the facilitation of payments for digital content within Android apps, there is no dispute about the geographic dimension of the market. It includes at least Australia and is likely global, excluding China, and possibly also excluding territories where competitive conditions began to differ towards the end of the relevant period. In any event, for present purposes the precise limits of the geographic dimension do not make a material difference.
5862 Let me turn to the question of market power.
Android in-app payment solutions — market power
5863 Given what I have already said and how I have defined the relevant market, the reader should be unsurprised that I agree with Epic that Google has a substantial degree of power in the Android in-app payment solutions market.
5864 If the market is confined to payment solutions for in-app purchases within Play Store apps, then Google is a virtual monopolist.
5865 By reason of Google’s conduct in imposing and enforcing the payments tie and the anti-steering rule, Google Play Billing is the only payment solution that developers are permitted to use to facilitate payments for in-app purchases of digital content within Play Store apps, save for purchases made in the 15 countries where Google Play Billing is not offered, and for purchases made within apps that are participating in the UCB or DOB programs.
5866 The scope for competition within the confines of the UCB and DOB programs is very limited, and neither program provides developers with a real choice of alternative payment solutions, for the reasons discussed elsewhere.
5867 Google’s contravening conduct prevents or hinders new entry by competing payment solution providers. The barriers to entry are contractual in nature and are insurmountable by potential competitors, outside of the limited and constrained exceptions mentioned above.
5868 App developers have no effective countervailing power. To the contrary, they are dependent on Google for access to the pre-eminent Android app store and are required to accept the payments tie and the anti-steering rule as a condition of receiving the distribution services which the Play Store offers.
5869 Moreover, if the market also includes payment solutions for in-app purchases of digital content within Android apps distributed outside the Play Store, the conclusion is the same.
5870 The Play Store accounts for 98% of new app downloads from Android app stores in Australia and 91% of such downloads globally in 2021, and Google Play Billing is the payment solution for almost all in-app purchases of digital content that occur in those apps.
5871 So, on the market definition that I have found, Google has a substantial degree of power in that market.
5872 In summary to this point, I have accepted Epic’s market definition in terms of the relevant product and the existence of market power. Let me then assess Google’s conduct in more detail and whether it had the impugned purpose or effect or likely effect in terms of Epic’s s 46 case.
Was there a purpose of substantially lessening competition?
5873 Epic says that the payments tie, which requires developers to use Google Play Billing for purchases of in-app features or services, including any app functionality, digital content or digital goods and to use Google Play Billing in the case of paid app downloads from the Play Store, has the purpose, effect or likely effect of preventing alternative payment solutions from accepting and processing payments for in-app purchases of digital content within apps downloaded and installed from the Play Store, decreasing quality, innovation and choice of payment solutions, inflating prices for such payment solutions, and decreasing quality, innovation and choice for app developers and users of Android apps.
5874 Epic says that the payments tie has the purpose, effect or likely effect of substantially lessening competition in both the Android app distribution market and in the in-app payment solutions market.
5875 But Google says that even assuming Epic’s defined markets, Epic’s case with respect to payment solutions must fail.
5876 As to Epic’s purpose case, Google says that the true purpose of the payments tie is to ensure that the Play Store remains attractive to users and developers by offering a safe, secure, consistent, seamless and easy to use way to make in-app purchases, and that is competitive with other digital content distribution platforms, and to ensure that Google has an efficient means of collecting the service fee. It says that this is not a proscribed purpose.
5877 Google also denies Epic’s effects case to which I will return later.
5878 I should say in summary at this point that I have rejected Epic’s purpose case on this aspect but have accepted its effects case.
5879 Now before proceeding further it is convenient to identify Google’s so-called pro-competitive arguments that it has advanced concerning the relevant requirements and restrictions.
Google’s so-called pro-competitive arguments
5880 Now Google says that key features of the payments policy have a pro-competitive nature; clause 4.1 of the DDA requires developers to comply with the developer program policies, which include the payments policy.
5881 The current version of the payments policy has three key features. First, developers charging for app downloads or in-app purchases must use Google Play Billing as the method of payment for those transactions, but not for transactions relating to physical goods or services or on other specifically excluded transactions such as tax-exempt donations or online gambling. Second, apps must not lead users to alternative payment methods other than Google Play Billing. Third, developers requiring or accepting payment from users in India or South Korea may offer users an alternative billing system alongside the Play Store’s billing system for in-app purchases.
5882 Now Google says that the payments tie is motivated by two key objectives.
5883 First, the payments tie is about ensuring that the user experience of purchasing digital content through the Play Store is safe, secure, consistent and seamless, and requiring use of Google Play Billing, in contrast to other payment solutions over which Google has no control, achieves this. This is important to maintaining the competitiveness of the Play Store, because consumers expect the Play Store to offer an efficient billing system that they can trust.
5884 Second, the payments tie is about ensuring that Google has a reliable and efficient means of collecting its service fee.
5885 Google says that in economic terms, this requirement has two key pro-competitive benefits.
5886 First, Google says that it has the benefit of ensuring that app and in-app transactions on the Play Store are safe, trustworthy and efficient, which mitigates asymmetric information problems faced by users and developers alike, and therefore reduces counterparty risk. Google says that consumers benefit when Google resolves issues associated with refunds, cancellations and fraud. Further, fraud checks on users and developers are important to both. Further, consumers value reduced risk to their financial information as it is only shared with one party (Google). Further, developers value efficient and reliable payment for their digital content. So, Google says that because managing counterparty risk increases the attractiveness of the Play Store for users and developers, Google mitigates the coordination problem.
5887 Second, Google says that it has the benefit of providing a reliable means of collecting the service fee, so that Google Play Billing lowers Google’s costs and increases efficiency. Google says that it would be far less reliable and efficient if Google had to separately and manually collect its fee, as its experience with user choice billing demonstrates.
5888 Further, as to the anti-steering rule, Google says that this mitigates two economic challenges.
5889 First, Google says that it limits opportunities for free riding by preventing developers from advertising, via in-app links or otherwise inside the app, alternative payment methods outside the app that bypass paying the service fee.
5890 Second, Google says that it mitigates the agency problem arising from increased security threats potentially associated with links or online venues outside the Play Store, by preventing developers from encouraging users within their app to use those external sources. If this threat were not managed properly, it could significantly reduce the attractiveness of the Play Store via network effects and feedback loops, and thereby reduce its competitiveness.
5891 Further, Google says that in any event, app developers have numerous means by which they can, and do, steer transactions to alternative transaction venues and platforms outside of apps. These include offering lower prices in their preferred transaction venues, offering better conversion or redemption value on virtual currency on their preferred transaction values, offering exclusive content on particular transaction venues, promoting preferred transaction venues, and offering exclusive content through preferred transaction venues.
5892 Obviously, Google says that by reason of the foregoing it did not have an anti-competitive purpose or focus in terms of the relevant restrictions.
5893 Let me turn then to Epic’s arguments.
The purpose of the payments tie – Epic’s arguments
5894 Now Epic says that a substantial purpose of Google’s conduct in imposing and enforcing the payments tie and the anti-steering rule has been to substantially lessen competition in the Android in-app payment solutions market.
5895 First, Epic says that Google’s anti-competitive purpose should be inferred from the conduct itself. The manifest effect of contractual terms may be the clearest indication of their purpose. That is the case here.
5896 The manifest effect of the payments tie is to ensure that Google Play Billing is the only payment solution that can be used to facilitate in-app purchases of digital content within Play Store apps. It is an exclusive dealing provision which precludes developers from acquiring services from a competing supplier of payment solutions. That is a clear indication that a substantial purpose of the payments tie is to hinder or prevent competition for the supply of services for facilitating the purchase of digital content within Android apps.
5897 The manifest effect of the anti-steering rule is to strengthen and protect the payments tie by preventing developers who are required to use Google Play Billing from leading users to a payment method other than Google Play Billing. That is a clear indication that a substantial purpose of the anti-steering rule is to hinder or prevent competition for the supply of services for facilitating the purchase of digital content within Android apps.
5898 Second, Epic says that Google’s conduct in removing the external consumption exception with effect from January 2021 shows that the purpose of the payments tie and anti-steering rule is to prevent developers from acquiring services from competing suppliers of payment solutions.
5899 The removal occurred in a context where around 5,000 developers had chosen to use a payment solution other than Google Play Billing to facilitate in-app purchases of digital content within Play Store apps. App developers were “actively de-integrating”, and the impact of this on Google’s revenue was exacerbated by “contagion risk”. As Google said, de-integration not only impacts revenue, but causes a domino effect with other developers.
5900 It was not a question of clarifying the existing payments policy.
5901 Google did nothing to clarify the limits or terms of the exception. It removed the exception altogether, such that developers that sold digital content which could be consumed outside a Play Store app were, for the first time, prohibited from using any payment solution other than Google Play Billing to facilitate such sales.
5902 Nor did the removal of the exception have anything to do with user security or the user experience. Google was losing considerable amounts of revenue due to developers not using Google Play Billing. It was anticipating a burgeoning business opportunity in subscriptions but knew it would only be able to participate if it could drive developers who were using an alternative payment solution to use Google Play Billing instead.
5903 Epic says that when the regulatory developments in the European Union in 2019 threatened to break the tie between payments and distribution, Google decided to act. It considered that “Play’s lack of clarity and exceptions makes it hard to defend that Billing is an integral part of the product risking regulation that makes billing optional for all [developers]”.
5904 So, what Google was concerned about was that the proposed regulations would ultimately require Google to make Google Play Billing optional for developers. If that happened, the de-integration would continue, Google would lose considerable revenues, and Google would have to compete to supply services for the facilitation of payments for in-app purchases within Play Store apps.
5905 Epic says that in removing the external content exception, Google sought to prevent developers from having the choice of using an alternative payment solution to facilitate the purchase of digital content that could be consumed outside a Play Store app. It was also seeking to forestall regulatory developments that it feared would make Google Play Billing optional for all purchases of digital content within Play Store apps. That is a purpose of substantially lessening competition.
5906 Third, Epic says that Google has long recognised that it would face a material degree of competition were it not for the payments tie.
5907 For instance, in March 2019 Google observed that if Google Play Billing became non-exclusive, it would likely begin to compete on price/services for business across digital and non-digital transactions, that this would promote competition, that Apple could offer a billing alternative on Android, and that there could be a race to the bottom on pricing versus Stripe and competitors.
5908 The effect of the payments tie in preventing competition was recognised by Google who not only continued to enforce the tie but strengthened and protected it via the anti-steering rule and expanded its scope by removing the external conduct exception. Google was seeking to ensure that competition did not occur in the Android in-app payment solutions market.
5909 Fourth, Epic says that Google’s anti-competitive purpose is evident from the way it responded to regulatory developments requiring it to offer UCB and DOB.
5910 Even when forced to allow alternatives to Google Play Billing, and when rolling out a pilot UCB program to forestall similar regulation elsewhere, Google has contrived means of ensuring that effective competition does not occur.
5911 Google deliberately set the service fee payable by participants in UCB and DOB at a level that ensured developers could not obtain an alternative payment solution with comparable functionality to Google Play Billing without paying more, in total, than they would otherwise have to pay Google.
5912 Google ensured that a developer switching to an alternative solution under UCB or DOB would be worse off financially, or worse off qualitatively if it opted for a payment solution with minimal functionality.
5913 In addition, Google imposed additional restrictions on the UCB program that were apt to deter most developers from participating.
5914 Further, Epic says that I should reject Google’s assertion that the purpose of the payments tie is, instead, to ensure user security.
5915 Epic says that the assertion is irreconcilable with the fact that Google permits, and indeed requires, alternative payment solutions to be used for in-app purchases of physical products.
5916 There is no security risk associated with the use of alternative payment solutions for in-app purchases of digital products that does not already exist in the case of in-app purchases of physical products.
5917 Mr Porst accepted this, and it also aligns with the opinion of Professor Somayaji.
5918 Yet Google imposes no restrictions on the payment solutions that developers can use for purchases of physical products. It does not require them to have any security features or to meet any security standards. As far as Google is concerned, they can have no anti-fraud capability at all. Nor does it conduct any review of them. Google has oversight of all of the payment solutions that developers incorporate into their apps, including the associated APIs, yet Google does nothing at all to review or approve them, or to ensure that they are provided by a reputable, certified supplier.
5919 Further, Epic says that Google requires alternative payment solutions to be used for in-app purchases of digital products in 15 countries. The only relevant difference between those 15 countries, and countries in which Google imposes the payments tie, is that they are relatively small and the cost of offering Google Play Billing in them is high, so the margins that Google would generate by imposing the payments tie is lower.
5920 It says that this shows that Google’s decision as to whether and when to impose the payments tie has nothing to do with security considerations. It is a commercial decision directed at securing the highest margin revenue stream.
5921 Third, Epic says that UCB was introduced in South Korea in August 2021, but Google has not led evidence of any security problem with the ability of users to use alternative payment solutions under UCB in that period. Indeed, Google voluntarily extended the UCB program to many countries. It introduced the UCB pilot in Australia, India, EEA countries, Indonesia and Japan on 1 September 2021, then extended it further to the United States, Brazil and South Africa on 10 November 2022.
5922 Epic says that Google did everything that it considered was reasonably necessary to ensure user safety and security when it did so. And there is no evidence of it having identified any security problem at all. Nor did Mr Porst have any recollection of having been consulted in relation to the security risks posed by UCB around the time it was introduced in South Korea or since.
5923 Fourth, Epic says that other payment solutions may be more secure than Google Play Billing.
5924 It says that Google has led no empirical evidence that Google Play Billing is better at detecting fraud than other digital payment solutions. Payment solutions such as Stripe and Braintree, for example, handle a much broader range of transactions than Google Play Billing and so have a more diverse and comprehensive dataset on which their algorithms can train. As Professor Somayaji said, having access to a more diverse and comprehensive set of data may ultimately lead to more accurate and efficient fraud prevention measures.
5925 It is said that I should infer that third-party payment solutions with such access, including, for example, Stripe and Braintree, are likely to be better at preventing fraud than Google Play Billing. The payments tie prevents the use of payment solutions with superior security features, rather than ensures it.
5926 Epic says that Google’s assertions that the purpose of the payments tie is to ensure a seamless and consistent user experience are contrived. Alternative payment solutions are used to purchase physical goods and services within Play Store apps. There is no evidence that this adversely affects the user experience.
5927 It is in each developer’s interests to ensure a seamless experience for its users and one would expect them to select a payment solution that achieves that goal, if given the choice.
5928 Epic says that the idea that a “consistent” user experience is important is belied by the reality that users routinely make online purchases from a range of merchants, using a range of payment solutions, both in-app and on websites. Users are habituated to using a variety of payment solutions utilised by the different merchants whose online stores they frequent. Google’s own policy ensures that Play Store users experience a variety of payment solutions when making in-app purchases of physical products within Play Store apps.
5929 In truth, Epic says that the requirement to use Google Play Billing is apt to prevent users from having a consistent experience. It ensures that the experience of making in-app purchases of digital content in Play Store apps is different from all other online purchasing experiences. Absent that requirement, developers could use the same payment solution for digital content purchases on both their PC and Play Store apps and ensure users have a consistent experience on their PC and Play Store apps. Currently, that is impossible.
5930 Further, Epic says that there is no substance to Google’s assertions that the purpose of the payments tie is to provide an efficient means of recovering its service fees.
5931 Since March 2024, Google has required developers to integrate alternative billing APIs when using alternative billing systems under the UCB and DOB programs. These APIs report every transaction made through an alternative billing system to Google, including refunds. Those APIs ensure that Google has knowledge of transactions that have occurred through any alternative billing system.
5932 All that Google needs to do to recover its fees is to issue invoices, the cost of which is negligible, and enforce any debts, like most businesses must do.
5933 Epic says that there is no evidence or reason to think Google could not have designed the alternative billing APIs years ago, and solved the supposed problem of keeping track of the service fees owing to it.
Analysis
5934 I agree with Google that the evidence does not demonstrate that the payments tie has a proscribed purpose. The purpose of this requirement is twofold, as Google explained.
5935 First, one purpose is to ensure that the Play Store remains attractive to users and competitive with other digital content distribution platforms. It achieves this by requiring the use of Google Play Billing to ensure that the user experience of purchasing digital content through the Play Store is safe, secure, consistent, seamless and easily managed through the Play Store. Users expect the Play Store to offer an efficient billing system that they can trust. Creating a positive user experience attracts more users, which attracts more developers.
5936 Second, the other purpose is to ensure that Google has a reliable and efficient means of collecting the service fee.
5937 That purpose does not involve or reflect any subjective intention to harm the competitive process in any of Epic’s pleaded markets.
5938 I agree with Google that its subjective assessment is that it competes with rival app stores and platforms, not payment solutions providers. I accept Mr Feng’s evidence on this aspect.
5939 As stated by Mr Feng, Google has never considered that it offers a billing system as a separate product and does not sell a Google Play Billing product. It does not compete in the payment solutions space, but it does compete with other app distribution platforms that have their own payment system, including the iOS App Store.
5940 Mr Feng said that in the past, Google has avoid unbundling because Google did not think that unbundling was the right thing for the product, for the ecosystem, or for users.
5941 Indeed, as Google points out, that evidence as to Google’s state of mind is corroborated by the fact that many other app stores and platforms impose the same requirement, including app stores that occupy different market positions to the Play Store. As stated by Mr Feng, that is an industry standard and exists in many places across software.
5942 For Android apps, the Amazon Appstore, Aptoide and Huawei AppGallery all require the use of their own integrated billing system. Further, whilst Samsung has offered alternative billing within apps distributed via the Samsung Galaxy Store since late 2021, it still recommends that developers use its in-house payment system on the Galaxy Store.
5943 Outside Android apps, other app stores, including the Epic Games Store for PC, offer an integrated billing system. At least six of these stores, including Steam and console stores, have an equivalent to the payments tie. Many two-sided marketplaces, such as Airbnb and Uber, also require the use of their integrated billing system.
5944 As Google says, such a requirement mitigates counterparty risk for developers and users by ensuring that app and in-app transactions are safe, trustworthy and efficient, thereby attracting users and developers to the platform. Through Google Play Billing, the Play Store offers a billing system that users and developers can trust.
5945 Google pointed out that users benefit from the ease with which they can make the Play Store in-app purchases using Google Play Billing, including access to many forms of payment, and from Google resolving issues associated with refunds, cancellations and fraud. Developers value the extent of market reach, and the efficient and reliable payment for their digital content, all of which are offered by the Play Store. They also value low decline rates for card purchases and not having to manage chargebacks, which Google handles for developers through Google Play Billing. Fraud checks, which are also offered by the Play Store, are important to both users and developers. This is why the payments tie serves the interests of competition, by improving the attractiveness of the Play Store relative to its rivals.
5946 I agree with Google that although Epic has advanced a number of arguments in support of the proposition that the payments tie has an unlawful purpose, those arguments are problematic.
5947 First, as Google says, although a consequence of the payments tie, where it applies, is that a developer may not acquire billing services for the Play Store in-app purchases from anyone other than Google, that does not imply that a substantial purpose of the payments tie is to lessen competition. As Google points out, the payments tie has been around since at least 2012, and there is no basis to conclude that it was introduced to hinder or prevent competition. Further, given that other platforms offer an integrated billing system, it is unlikely that the payments tie was designed to harm the competitive process rather than to implement a system that Google thought was in the best interests of the platform and users.
5948 Second, as Google says, the amendment to the payments policy in January 2021 does not show that the purpose of the payments tie is to prevent developers from acquiring services from an alternative payment solution. And it remains the case that developers can use alternative payment solutions for digital content which is solely consumable outside of the app.
5949 Third, Epic says that the security justification for the payments tie is contrived because Google requires alternative payment solutions to be used for physical goods, Google does not support Google Play Billing in 15 countries and there is no evidence of security problems with UCB. Moreover, it says that other payment solutions may be more secure than Google Play Billing.
5950 But I agree with Google that none of those matters suggest that Google’s subjective purpose in maintaining the payments tie is other than to ensure that the Play Store remains attractive to users, including by ensuring their safety.
5951 Fourth, Epic says that the payments tie cannot be justified by Google Play Billing providing a seamless and consistent user experience. But as Google says, the Play Store is a marketplace for apps. To make itself attractive to users and developers, Google presents a consistent and seamless experience within the Play Store.
5952 Fifth, Epic says that there is no substance to the service fee-recovery purpose because, since March 2024, Google has required developers to integrate alternative billing APIs which reduce the relevant burden. But I agree with Google that the introduction of an API in March 2024 does not undermine Google’s purpose in introducing the payments tie more than a decade ago. Even with the new APIs, service fee collection is still easier and more convenient through Google Play Billing.
5953 Sixth, it is a stretch for Epic to say that a proscribed purpose concerning Google Play Billing can be inferred from UCB.
5954 Let me turn to one other matter concerning the different treatment as to payment between physical goods and digital goods.
5955 Now Epic makes much of the fact that Google Play Billing cannot be used for in-app purchases of physical goods and services, arguing that there is no distinction between payment solutions for physical and digital products such that it can be inferred that Google’s purpose for the payments tie is contrived.
5956 I disagree with Epic largely for the reasons that Google has given.
5957 As Google points out, in-app purchases of physical goods and in-app purchases of digital goods involve meaningfully different types of commerce.
5958 Indeed, apart from Google, other integrated app stores make this distinction, including the Amazon Appstore. So, the integrated billing service on these other app stores cannot be used for in-app purchases of physical goods but must be used for in-app purchases of digital goods. Paddle also makes this distinction. It supports the purchase of digital products but not the purchase of physical products, including because the latter would involve injecting greater complexity into its business model.
5959 I agree with Google that the nature of transactions involving physical goods is different to the nature of transactions involving digital goods. Google made the following points with which I agree.
5960 First, Mr Feng and Mr Owens said that the sale and delivery of physical goods involves more complexity than the sale and delivery of digital goods. Mr Owens referred to the additional complexity associated with the payment of local taxes and additional compliance risk with the purchase of physical goods.
5961 Second, Mr Burg and Mr Blockley also identified differences in the nature of Google Play Billing transactions and generic e-commerce or retail purchases. Google Play Billing transactions involve real-time delivery, but physical goods do not. Digital goods have a lower average transaction value than physical goods. Further, there is a higher percentage of cross-border purchases for digital goods than physical goods. Further, digital goods have a heightened fraud risk profile in comparison to generic e-commerce or retail purchases.
5962 Third, in-app purchases of digital goods are more tightly integrated into the Play Store than purchases of physical goods. All apps available on the Play Store, including in-app digital content that forms part of an app’s code, are comprehensively scanned and reviewed prior to being distributed. Their availability on the Play Store means that Google has not found them to contain malware, that they comply with Google’s content policies, and that they work as expected. Delivery and consumption of in-app digital content is part of the digital experience offered by the Play Store. It is immediate and can be managed by the subscriptions and in-app purchases API offered by the Play Store.
5963 Fourth, Google does not vouch for any physical goods available as in-app purchases, nor does it dispatch those goods or have any oversight over the payment solutions provider used for the sale. Google does not provide any of the services offered by Google Play Billing for the in-app purchase of physical goods, such as payment and content controls for in-app purchases, fraud checks, user and developer access to information in a single place, financial reports for developers, customer and refund support.
5964 For these reasons, I agree with Google that no proscribed purpose can properly be inferred from the fact that the payments tie applies to in-app purchases of digital goods, but not physical goods.
5965 Finally, in terms of Epic’s purpose case concerning the anti-steering rule, I would note the following. The payments policy embodies the anti-steering rule which provides that apps, other than those to which the payments tie does not apply, may not lead users to a payment method other than the Play Store’s billing system. Epic made a similar claim about the anti-steering rule as it does for the payments tie. My comments above also apply to the anti-steering rule in terms of purpose.
Was there an effect or likely effect of substantially lessening competition?
5966 Google denies Epic’s effects case. In summary it has made the following points.
5967 First, it is said that Epic’s case depends upon a lack of precision or close attention to what constitutes a payment solution. Moreover, Google says that Google Play Billing itself is not a payment solution, but rather incorporates a payment solution. So, Google says that what Epic says Google must unbundle is, in reality, a component of Google Play Billing, which itself is a component of the integrated service that is the Play Store.
5968 Second, Google says that there is no evidence to suggest that there would, in fact, be any material demand for alternative payment solutions to Google Play Billing.
5969 Third, Google says that Epic has not adduced evidence that there would be meaningful supply of alternative payments solutions at a competitive price.
5970 Let me identify Google’s points in more detail.
5971 Google says that any proper counterfactual analysis in respect of the payments tie first requires the precise identification of what, if anything, would change in the counterfactual.
5972 Google says that Epic’s analysis in this regard is deficient, including because of its imprecision in the way it uses the term “payment solution” and the incongruence between that term and the set of features and functions that constitute Google Play Billing.
5973 In its pleading, Epic defines a “payment solution” as being something that “provides for, and facilitates, the acceptance and processing of payments from device users for apps or in-app purchases”.
5974 Epic’s in-app payment solutions markets are pleaded as markets for the supply of services to app developers accepting and processing payments.
5975 But Google says that it was common ground between the experts that Google Play Billing was not simply a payments solution in this sense, because it comprised features and functions that were not in the payments domain. Those features and functions include such things as family sharing, parental controls, the loyalty points system, the functionality of accepting promotional codes, local support, sales tax reporting and other developer tools and services.
5976 Google says that the short point is that Google Play Billing is a product that is larger than the “payment solutions” product that Epic says defines the relevant market. The unanimous view of the experts was that Google Play Billing, including both its payment and non-payment features, is tightly integrated with the Play Store.
5977 Google says that this disconformity between the boundaries of the product that defines Epic’s market and the boundaries of Google Play Billing creates analytical difficulties when it comes to the counterfactual.
5978 Epic’s case is that in the future without the payments tie, developers could choose whether or not to use Google Play Billing.
5979 But Google says that that proposition obscures the problem that it is not immediately obvious what it would mean for a developer to forgo Google Play Billing in circumstances where it is a tightly integrated aspect of the Play Store, comprising both payment processing aspects and non-payment processing aspects.
5980 So, Google posed the question on Epic’s counterfactual, does one assume that developers who choose not to use Google Play Billing still obtain the benefits that it provides in terms of family sharing and parental controls?
5981 Google says that any assessment of competition in the counterfactual must identify the commercially realistic likelihoods. Those likelihoods cannot be identified, and the question of competitive effects assessed, without some attention to the aspects of the Play Store’s current product that would be unbundled in the counterfactual, including because that will affect the assessment of whether there would, in fact, be material demand from developers to obtain an alternative to Google Play Billing.
5982 It says that one reason there would likely be no material demand from developers for a payment solution other than Google Play Billing in the counterfactual is because developers could not otherwise obtain the full suite of features and functions that Google Play Billing provides.
5983 But the problem is one that the payment experts identified in their joint report:
When compared with providers of payment solutions, such as Adyen or Stripe, GPB is structurally different and provides customised features (including certain non-payment related functions) not offered by these providers…
5984 Google says that one consequence of this is that any developer who chooses to forgo Google Play Billing would likely need to acquire a whole range of services in addition to payment solutions from different suppliers. Even then, developers would likely be unable to replicate all the features and functions that they obtain from Google Play Billing, which would affect their willingness to obtain a payment solution other than Google Play Billing.
5985 It says that Epic’s case does not face up to these matters or to the reality that detailed evidence is needed in relation to these matters to draw any reliable conclusions as to competitive effects.
5986 Let me turn to another question concerning demand.
5987 Google says that Epic has not demonstrated that there is or at any relevant time was a real commercial likelihood that there would be material demand for alternative in-app payment solutions in a future without the payments tie.
5988 Google has made the following points.
5989 First, it says that Epic’s own experience demonstrates that there is no material demand on the part of developers for separate payment solutions for in-app purchases, even at substantial discounts. Developers who use the Epic Games Store pay a commission of 12% on in-app purchases of digital content and have the option of avoiding that commission altogether by using an alternative payment solution.
5990 Notwithstanding this incentive to fully avoid paying the commission, the overwhelming majority of developers have not taken up this option to date. Of the approximately 1,100 third-party developers who distribute games on the Epic Games Store, less than 50 use an alternative payment solution. So, even when there is the opportunity to avoid a 12% commission, most developers do not take it up.
5991 Second, it says that the evidence of demand on which Epic relies is not evidence of demand for alternative payment solutions for the Play Store in-app purchases because it is evidence of developers avoiding paying the service fee altogether, rather than genuinely seeking to obtain separate supply of a payment solution, while otherwise paying a service fee to Google.
5992 It says that it is not to the point that some developers have justified their desire to use alternative payment solutions by reference to apparent quality concerns with Google Play Billing, because those justifications were deployed in aid of a position that would have seen the relevant developers avoid Google’s service fee.
5993 The fact that some developers chose to use their own payment solution at a time when doing so allowed them to avoid the Play Store’s service fee is not evidence of demand for a separate payment solution in circumstances where adopting such a solution would not avoid the service fee.
5994 It says that the analysis above applies to various developers who were dissatisfied with the features and performance of Google Play Billing.
5995 Spotify had never paid the service fee and so for it to change its billing system to Google Play Billing, it would have meant exposure to the service fee for the first time. Accordingly, the example of Spotify does not provide evidence of demand for an alternative payment solution separate from demand to avoid the service fee.
5996 Similarly, it says that most of the other listed developers were on the “holdouts tracker” and are therefore examples of app developers who were avoiding paying a service fee at the time. Again, that is not a circumstance from which it can be inferred that there would be demand for separate payment systems in the counterfactual. This is because, in that counterfactual, developers would still be required to pay a service fee to Google in respect of those aspects of the Play Store’s service other than Google Play Billing.
5997 Third, Google points out that Epic relies on YouTube’s preference for its own payment system over Google Play Billing as evidence of demand. But Google says that it is not.
5998 Mr Feng explained why YouTube was not using Google Play Billing prior to January 2021. Whilst he acknowledged that YouTube had some complaints about Google Play Billing, he said that these complaints were not the reason that YouTube was not using Google Play Billing. Mr Feng explained that YouTube “didn’t want to do the work to switch to [Google Play Billing]” and was “mostly concerned about the level of investment that they would have to make in order to switch to [Google Play Billing]”. This evidence was not seriously challenged and should be accepted.
5999 Fourth, Google says that although Epic asserts that developers desire alternative payment solutions suited to their business needs or business models, the evidence shows that most developers would continue to use Google Play Billing.
6000 Mr Allison said that most developers are not interested in running their own system, which would involve onboarding payments, running that service, being responsible for customer support and fraud, and managing refunds.
6001 Mr Allison noted that it was a particularly sophisticated and mature developer that has some scale, like Riot Games or Epic, who is interested in doing this. The developers that Epic identified as having taken up payment solutions other than EDP are all large developers.
6002 Google says that Mr Allison’s evidence is consistent with the expert evidence from Mr Blockley and Mr Burg, who agreed that small developers are more likely to prefer to use Google Play Billing as a one-stop shop.
6003 Most developers who earn revenues through the Play Store are small developers. In Australia, about 95.6% of developers, with non-negative transactions through Google Play Billing, made less than USD 50,000 in 2021.
6004 Fifth, Google says that although Epic asserts that demand would be driven by several features offered by payment solutions providers that are not offered by Google Play Billing but that may be desired by individual developers, Epic makes a false comparison. Google says that Google Play Billing is more than a payment solution. Its features and services are different from the features and services of payment solution providers.
6005 Google says that Epic has not demonstrated, and it is not self-evident, that the features listed by Epic, for example, remittance times or a developer’s ability to handle refunds, are features of payment solutions that would, in reality, be sufficient to cause developers to switch away from Google Play Billing, and to forgo its benefits, if given a choice to do so.
6006 It says that the evidence does not suggest that the Play Store’s payment terms are unattractive relative to other app stores with comparable billing systems. So, the Play Store’s settlement terms are shorter than those of the Amazon Appstore and the Epic Games Store.
6007 In any case, it says that Google Play Billing offers many of the services that Epic says it does not offer. For example, if a developer wishes to have and maintain a direct relationship with their customers, they can. The Play Store facilitates this. A developer needs to provide an email address and phone number that can be shown on the Play Store so that users can contact developers directly, including in response to questions and complaints. Developers can issue refunds directly to users when using the Play Store. Google provides other tools for enhancing developers’ engagement with users, such as tools for pre-registration, which enables users to register their interest in a new app that is being released in the future, in addition to other marketing capabilities.
6008 Sixth, Epic says that Google’s own consideration of billing optionality is evidence of demand amongst developers for choice in payment solutions. But Google says that this consideration including the introduction of UCB and DOB was precipitated by regulatory pressure, not developer demand.
6009 Let me turn to another topic concerning whether there would be competitive supply in the counterfactual.
6010 Google says that there is no evidence that any alternative provider would supply “payment solutions” in the counterfactual at a competitive price.
6011 Epic points to the fact that there is evidence that at least one payment solution provider (Paddle) has already expressed an intention to enter the market and compete with Google Play Billing.
6012 Mr Owens, the founder and then-CEO of Paddle, said that if Google was to remove the payments tie, he would cause Paddle to develop an in-app payment product for Android, with a 10% transaction fee for transactions below $10. The evidence suggests that that price would not be competitive.
6013 But Google says that even on Epic’s account, the global all-in cost, that is, both variable and fixed costs, of Google Play Billing is estimated to be around 8%. Whilst Google rejects the proposition that this is an appropriate estimate, it says that it may be assumed in Epic’s favour for the purpose of this analysis. Epic’s 8% estimate is based on the assumption that Google’s costs of payment processing globally for all forms of payment is 6%. In Australia, the true position is that Google’s payment processing costs for all forms of payment is substantially lower at 2.9%, and as low as 2.0% if limited to credit cards and e-wallets.
6014 So, staying with Epic’s assumptions as to the costs of Google Play Billing to Google either in Australia or globally, and even assuming the relevant analysis is by reference to all forms of payment, Google says that Paddle’s proposed fee of 10% is likely to be well above a price Google could charge while covering all costs and earning a margin on those costs. In other words, Paddle would not be price competitive at 10% per transaction.
6015 Google says that the analysis becomes clearer still when one factors in quality. Unlike the Play Store, for example, Paddle does not offer direct carrier billing or branded gift cards. It also offers a smaller range of currencies than the Play Store. So, when one factors in quality, Paddle’s price is higher still.
6016 Google says that it follows that Paddle, which is the only putative competitor said to have an avowed interest in entering the relevant markets, would likely be uncompetitive with the Play Store. That being the case, entry by Paddle would not meaningfully increase competition in the counterfactual.
6017 Epic points to other payment providers that it says might enter such as Adyen and Stripe.
6018 But Google says that there is no evidence that they would do so, or evidence as to the terms that they would offer if they did. The evidence does not establish that such competitors, if they did enter, would meaningfully compete with the Play Store on price or quality.
6019 Google says that notably neither Adyen nor Stripe offer direct carrier billing in Australia. Moreover, because neither Adyen nor Stripe offers the package of non-payment services offered by Google Play Billing, Google says that developers likely would need to acquire services from additional suppliers to replicate the service they obtained from Google Play Billing and at a cost of doing so which is unclear.
6020 Ultimately, Google says that there is no reliable evidence that would permit me to conclude that, in a world without the payments tie, competition would be increased. Certainly, competitors such as Paddle may seek to enter, but whether that would result in increased competition is speculative. It says that that is because Epic has not proved that suppliers could offer the range of services that developers would need to acquire without Google Play Billing at a quality-adjusted price that would be competitive.
6021 Finally, let me say something about the anti-steering rule. Google says that I should reject Epic’s claim concerning the anti-steering rule in terms of effect for the following reasons.
6022 First, it says that the anti-steering rule does not hinder or prevent competition in the Australian Android in-app payment solutions market because developers have numerous means by which they can, and do, steer transactions to alternative transaction venues and platforms outside of the Play Store.
6023 It says that these include offering lower prices in their preferred transaction venues, offering better conversion or redemption value on virtual currency in their preferred transaction venues, offering exclusive content in particular transaction venues, and promoting preferred transaction venues.
6024 It says that developers can also directly contact their customers and promote alternatives to purchasing on the Play Store through those communications. Google’s frequently asked questions page for developers make this clear:
Q: Can I communicate with my users about alternate ways to pay?
A: Yes. Outside of your app you are free to communicate with them about alternative purchase options. You can use email marketing and other channels outside of the app to provide subscription offers and even special pricing.
Q: Can I communicate with my users about promotions on other platforms?
A: Of course. We're an app developer too, and we know how important it is not to restrict your ability to communicate with your users. You can email them or otherwise communicate outside of the app information about your offerings, even if they are different on Google Play than in other places.
Q: Can I have different app features, prices and experience depending on the platform?
A: Yes. It is your service and business, it is up to you. We do not require parity across platforms. You can create different versions of your app to support different platforms, features and pricing models.
6025 Developers have multiple ways to connect with their customers.
6026 It says that Mr Weissinger, Epic’s former vice president of marketing, said that Fortnite users are required to sign-up to an account with Epic to use Fortnite, and must provide an email address as part of that process. Mr Weissinger said Epic routinely emailed its users to communicate about Fortnite, including to notify them about the launches of new seasons.
6027 Further, Fortnite has a social media presence of about 100 million followers, with over 26 million followers on Instagram and 18 million followers on X. Epic uses those social media accounts to market new content to users, such as the availability of new items in the in-game “item shop”.
6028 In short, Google says that developers like Epic have many ways to reach and steer their customers towards their preferred transaction venues, and outside the Play Store version of the app itself. The anti-steering rule does not prevent this. Having regard to the alternatives available to developers, Epic has not demonstrated that the anti-steering rule has any proscribed effect or likely effect.
6029 Second, Google says that the anti-steering rule prevents free-riding. Absent the anti-steering rule, developers could try to bypass paying the service fee by steering users outside of the app to make their purchases, yet still enjoy the benefit of the service supplied by the Play Store.
6030 It says that it is not anti-competitive for Google to prevent developers from promoting alternative payment methods directly in app when that is the venue through which the Play Store monetises its service to developers.
6031 It says that it is not anti-competitive, for example, for Myer to prohibit its in-store merchants from re-directing customers to leave Myer Melbourne and instead shop at the merchant’s store, say, in suburban Camberwell.
6032 By efficiently preventing free-riding, the anti-steering rule preserves Google’s incentives to invest in, and grow, the Play Store. That serves the interests of competition. For that reason, a purpose of preventing free riding is not a proscribed purpose.
6033 Third, Google says that whilst Epic says that I should infer that the anti-steering rule has a proscribed purpose because of its “manifest effect”, there is in fact no evidence that the anti-steering rule has any such effect. There is therefore no proscribed effect from which an anticompetitive purpose could be inferred. Moreover, insofar as the effect or likely effect of the anti-steering rule is to prevent free riding, that is not a proscribed effect.
Analysis
6034 Now as Epic correctly points out, the state of competition in this market in the factual, that is, with Google’s conduct, is clear. There is next to no competition. But contrastingly, in the counterfactual, without the payments tie and the anti-steering rule, it seems relatively clear on the evidence that Google Play Billing would likely face a significant degree of competition on price and quality from multiple new entrants.
6035 There would be demand from app developers for Android payment solutions other than Google Play Billing, just as there has been in the past, for the reasons expressed elsewhere.
6036 As the evidence also establishes, there would also be suppliers with the incentive and ability to meet that demand. At least one payment solution provider, that is, Paddle, has already expressed an intention to enter the market and compete with Google Play Billing. Barriers to entry would be low. Various suppliers, including Stripe, Square, PayPal, Adyen and Braintree, already have payment solutions for in-app purchases of physical goods within the Play Store. As Epic says, it would not be difficult for these providers to supply an in-app payment solution for purchases of digital content within Play Store apps. Entry by those suppliers into the market is likely.
6037 Now Mr Feng acknowledged that there would be entry by suppliers of payment solutions such as Stripe, Adyen, PayPal, and others if Google did not require developers to use Google Play Billing, and that there would be competition in this space. He also agreed that if alternative payment solutions were permitted, third-party suppliers could provoke Google to innovate in relation to its own billing system.
6038 I agree with Epic that the state of competition in the future without the payments tie and the anti-steering rule is likely to be robust, with each developer choosing the payment solution which offers the price-product-service package for its business and payment solution needs. There is a wide variety of app developers that require payment solutions to facilitate in-app purchases. Their businesses and payment solution needs vary in many ways, including their size and financial resources, their technical and management capabilities, the products they sell, the geographic regions they serve and the age and other characteristics of their customers.
6039 There is also a wide variety of payment solutions from which developers could choose. Suppliers of payment solutions seek to differentiate their products and compete based on matters such as the FOPs and currencies they accept, whether they act as a “merchant of record”, the seamlessness and quality of the user experience that they provide, the ability to be used across multiple channels, and their conversion and authorisation rates. They also seek to differentiate based upon the tools they offer to facilitate risk management and fraud prevention, their analytics and customer insights services, whether their payment flows are customisable, their pricing options, their features for resolving disputes between buyers and sellers, their trustworthiness including years of experience, number of active customers, markets in which they operate, and number of merchants, and their rates.
6040 I have set out the evidence of all of this elsewhere.
6041 This would lead to a range of payment solutions being used, just as a range of payment solutions are used for in-app purchases of physical products. Google Play Billing would compete amongst the many options from which developers could choose.
6042 I also agree with Epic that it is also likely that there would be a reasonably high propensity to switch or consider switching between payment solution providers in the future without the payments tie.
6043 The survey of small to medium merchants on which Mr Burg relied, being the most up to date and reliable survey of its kind that he could identify, showed the following.
6044 First, 45% of merchants surveyed had either switched or considered switching providers in the previous two years. The figures rises to over 50% if merchants that had just started their business were excluded.
6045 Second, 35% of the merchants that sold products online only, and 49% of the merchants that supplied products in multiple channels, had either switched or considered switching in the last two years. The figures are higher if new businesses are excluded.
6046 Third, 39% of merchants surveyed would consider switching in response to an increase in prices charged by their provider and 32% would consider switching to pay a lower price.
6047 Fourth, when choosing a provider, 74% of the merchants that had been with a provider for more than two years considered price, 48% considered available payment methods and 44% considered settlement times.
6048 Fifth, almost three-quarters of merchants surveyed had shopped around for providers when they considered switching in the last two years and 98% of them considered price when doing so.
6049 Sixth, 59% of new merchants shopped around before choosing a provider, 82% of them considered the price of card acquisition services and 81% considered settlement times.
6050 As Mr Burg accepted, the survey indicates that pricing is critical to the decision of a merchant as to which payment solution provider to choose. It also shows that a large majority of merchants would shop around for their payment solution if given the choice.
6051 For all these reasons, in my view Google’s conduct in imposing and enforcing the payments tie and the anti-steering rule has the effect or likely effect of substantially lessening competition in the Android in-app payment solutions market.
Summary
6052 I have found that there is a market of the type defined by Epic concerning payment solutions. Further, Google had and has substantial market power in such a market.
6053 Moreover, the relevant restrictions had the effect or likely effect of substantially lessening competition. In terms of the Google Play Billing restrictions being the payments tie provision and the anti-steering provision, I have found that they were imposed or have been maintained at the start of the relevant period with the effect or likely effect of substantially lessening competition in the payment solutions market.
Cross-effects
6054 Finally, I should say something about the cross-effect (if any) of conduct in the mobile OS licensing market and in the Android mobile app distribution market.
6055 I agree with Epic that there is an important nexus between Google’s OEM restrictive conduct and app developer restrictive conduct, and competition in the Android in-app payment solutions market.
6056 Apart from the payments tie and the anti-steering rule, and as Epic fairly summarises the matter, Google’s conduct with respect to OEMs and app developers ensures that app developers who wish to reach most Android device users have no choice but to distribute their apps through the Play Store and accept the DDA terms.
6057 And such conduct also facilitates the anti-competitive conduct which Google engages in within the Android in-app payment solutions market, because it ensures that developers are in practical terms required to accept the payments tie and the anti-steering rule. Indeed, as Epic says both the payments tie and the anti-steering rule form part of the DDA terms, and as such are an integral part of Google’s conduct vis-à-vis app developers.
The overall purpose of Google’s conduct – Android mobile app distribution
6058 Now Epic says that in respect of each aspect of its impugned conduct, Google was acting for the purpose of substantially lessening competition in the Android mobile app distribution market. But Epic says that Google’s conduct must also be considered as a whole in relation to considering Google’s anti-competitive purpose.
6059 Epic says that Google has so acted in the following ways for an anti-competitive purpose.
6060 First, Epic says that Google has done so through the MADAs, which maintain the Play Store’s position as the pre-eminent distributor of Android apps by ensuring it is the only Android app store with global reach excluding China and by maximising the prospect that Android device users will continue to choose the Play Store, rather than any alternative Android app store. But I have not so found any anti-competitive purpose.
6061 Second, Epic says that Google has done so through the technical restrictions, which prevent or hinder the direct distribution of Android apps, including rival Android app stores and the subsequent download of apps from those stores. But I have not so found any anti-competitive purpose.
6062 Third, Epic says that Google has done so through the RSA3s which prevent or hinder the distribution of rival Android app stores by disincentivising the pre-installation of any such rivals and investment by OEMs in their own app stores. I have so found an anti-competitive purpose.
6063 Fourth, Epic says that Google has done so through clause 4.5 of the DDA, which prevents or hinders the Play Store’s competitors from being distributed to Android device users efficiently and at scale. But I have not so found an anti-competitive purpose.
6064 Fifth, Epic says that Google has done so through Project Hug, the GVP agreements and the AVP agreements, which prevented or hindered the development of rival Android app stores by making it impossible for them to offer differentiated content from the participating Hug developers. I have so found an anti-competitive purpose.
6065 Epic says that together, Google’s conduct demonstrates a clear purpose being to secure and prevent any rival from threatening the Play Store’s predominant position in Android app distribution.
6066 Epic says that Google’s OEM restrictive conduct and the app developer restrictive conduct, was engaged in for the purpose of substantially lessening competition in the Android mobile app distribution market.
6067 Epic says that when the impugned conduct is viewed as a whole, it is apparent that Google has sought to stifle competition in Android app distribution and to prevent or hinder potential rivals from threatening the Play Store’s position as the pre-eminent distributor of Android apps.
6068 Epic says that Google has ensured that the Play Store is and remains the predominant supplier of services for distributing Android apps by preventing or hindering competition from rival suppliers of Android app distribution services.
6069 Further, Epic says that Google has ensured that Google Play Billing is and remains the sole supplier of services for facilitating payments for in app purchases of digital content within apps downloaded from the Play Store, by prohibiting developers from using alternative suppliers of payment solutions. But I have not so found an anti-competitive purpose in this respect.
Did Google have a general anti-competitive plan?
6070 Epic says that in evaluating Google’s conduct and ascertaining its purpose, I should be cognisant that, according to a May 2019 Google document titled “Android 101”, “Android was built to help secure more users for Google’s services”, including the Play Store.
6071 Epic says that consistently with that reality is the fact that, according to a 12 October 2010 presentation titled “OC Quarterly Review – Q4 2010”, Google has long sought to “retain control” of the Android ecosystem and “ensure [Google] get[s] to benefit from it”.
6072 Further, as Epic pointed out, in October 2010, according to a presentation titled “Android: Answers to strategy questions for BOD”, Google’s board of directors, which then included Google’s founders, Mr Page and Mr Brin, along with its then CEO, Mr Schmidt, wanted to hear “the longer term vision for how we make money on Android” and were “worried about dis-intermediation of Android”. Examples of such “disintermediation” were cited, namely “Verizon app store” and “Bing search on Android”.
6073 Epic says that, evidently, the board was worried that Google could lose its role as an intermediary between participants in the Android ecosystem, if those participants instead established direct relationships with one another which did not depend on Google or its services.
6074 But Epic says that Google’s executives had no intention of losing control of the Android ecosystem and detailed their plan to ensure that Google would benefit from it.
6075 It says that according to the presentation, a key question addressed by that plan was “[h]ow do we retain control of something we gave away?”, with that “something” being the Android OS. Another key question which the plan addressed was “[i]f we gave it away, how can we ensure we get to benefit from it?”, with “we” meaning Google. Answers to the latter question were then set out. They included “[o]wn the ecosystem we enabled”.
6076 Now Mr Gennai denied that “the ecosystem” referred to is the Android ecosystem and said it was limited to “the application ecosystem in Android Market” or “the ecosystem of developers that are making up the Android Market ecosystem”.
6077 But Epic says that that is not an accurate reading and makes little sense. It says that it is plain from the presentation as a whole that “the ecosystem we enabled” is not limited to a single app store, already owned by Google, but instead refers to the Android ecosystem. It says that the mechanisms by which Google would “own” that ecosystem were described in subsequent pages. They included a suite of agreements with OEMs that were explicitly intended to “[stop] our partners and competitors from forking Android and going alone”, to “define the standard and shape the ecosystem”, and to serve as a “Poison Pill”.
6078 In addition, Epic says that Google planned to “[e]volve the app store. Set the rules. Define developer monetization opportunity. Train developers on our APIs. Give developers one place where they get wide distribution.”
6079 Epic says that another aspect of the plan laid down in October 2010, according to the presentation, was to “[h]elp developers get distribution via revshare with [carriers]”, but then “Change The Rules / Get A Better Deal” which would “Increase Google Net Rev. on Apps”.
6080 And it says that this is what happened. The Play Store’s business model “evolved” from one in which carriers and/or OEMs were incentivised to pre-install Android Market/the Play Store by a 25% share of revenues generated from paid apps and in-app purchases, while Google took 5%, to a model whereby Google typically took 30% while carriers and OEMs typically shared none of the Play Store’s revenues.
6081 In short, Epic says that the plan which Google’s executives articulated in October 2010 and implemented thereafter was successful. Android has secured more users for Google’s services, Google has retained control of the Android ecosystem, and Google has continued to benefit from that ecosystem.
6082 Now I do not doubt that Google had some of the general strategies and plans that Epic has referred to and that this is relevant context which I have borne in mind in dealing with specific aspects of Epic’s case.
6083 Let me deal with another general topic raised by Epic.
Dominant supply position
6084 As Epic points out, the Play Store has been the dominant supplier of Android app distribution services throughout the relevant period, that is, since November 2017; I am using the word “dominant” here in an informal sense and not in any technical economic sense.
6085 Epic has referred to the following statistics which were not contentious.
6086 From December 2017 to September 2022, the Play Store was pre-installed on between 97.7 and 99.6% of active Android devices in Australia, and between 97.2 and 99.2% of active Android devices worldwide excluding China.
6087 Its closest rival on this measure is the Galaxy Store, which was pre-installed on about 66% of Android devices shipped in Australia and about 40% globally excluding China.
6088 No other app store has been pre-installed on more than 5% of Android devices shipped in Australia, or more than about 13% globally excluding China, since 2016.
6089 In 2020, some 97.9% of new app downloads to Android devices in Australia that occurred through an app store were undertaken via the Play Store, while globally excluding China some 91.4% of new app downloads from an app store occurred via the Play Store.
6090 Its closest rival in Australia being the Galaxy Store had a share of only 1.5%. Its closest rival globally being the Oppo Store had a share of only 2.5% and the Galaxy Store’s global share was 1.5%. The Play Store’s share of app downloads was also very similar in 2019 and 2021.
6091 Further, even Samsung users spend substantially more of their time within the Play Store than they do within the Galaxy Store.
6092 Google calculated that globally about 83% of all Samsung monthly active users (MAUs) visit the Play Store for more than 10 seconds per month, while only about 19% visit the Galaxy Store for more than 10 seconds per month.
6093 It calculated that about 77% of all Samsung MAUs visit the Play Store for more than 10 seconds two or more times per month, while only about 12% visit the Galaxy Store for more than 10 seconds two or more times per month.
6094 And it calculated that those MAUs who do visit the Galaxy Store for more than 10 seconds two or more times per month only stay within the Galaxy Store for a fraction (about 2%) of the time that they stay within the Play Store.
6095 Google concluded, in a July 2019 presentation titled “Samsung Update”, that “the cannibalization of Play store revenue due to Galaxy store is none to minimal”; that the Galaxy Store was likely “operating under net loss”; and “[i]n [the] absence of ‘exclusive hit-titles’ on Galaxy store, the projected trajectory is in red as well”.
6096 Data compiled by Google in 2017 indicated the following. In Japan, the Amazon App Store’s MAUs were 1.4% of the Play Store’s MAUs, whilst Amazon’s app installs were only 0.02% of the Play Store’s app installs. In Korea, OneStore’s MAUs were 20.8% of the Play Store’s MAU, whilst OneStore’s app installs were only 0.7% of the Play Store’s app installs. In India, 9Apps’ MAUs were 16.4% of the Play Store’s MAUs, whilst 9Apps’ app installs were only 3.6% of the Play Store’s app installs. Globally, Samsung’s MAUs were 13% of the Play Store’s MAUs, whilst Samsung’s app installs were only 0.2% of the Play Store’s app installs. In the US, UK and Germany, the Amazon App Store’s MAUs were 15.1% of the Play Store’s MAUs, whilst Amazon’s app installs were only 0.01% of the Play Store’s app installs.
6097 Further, an analysis prepared by Google on 31 October 2019 titled OEM App Store Share Analysis: Android Ecosystem Analytics revealed the following matters.
6098 First, the Play Store was “installed on ~100 percent of 28DA devices in each region”, whilst no other OEM app store was installed on more than 50% of devices globally or in Southeast Asia.
6099 Second, of the OEM app stores, the Galaxy Store was installed on 41% of devices globally, with the next highest install shares being Xiaomi Market at 7%, Oppo Apps at 4%, and Vivo App Store at 3%.
6100 Third it was observed that “[f]or each region, the majority (>90%) of all app store visits in a month are to the Play Store”. Globally, that figure was 94%. Further, “[f]or each region, the majority (>92%) of monthly app store time spent is in Play Store”. Globally, that figure was 96%.
6101 Fourth, globally, only 2% of all app store visits in a month were to the Galaxy Store, whilst 1% were to Xiaomi Market, 2% were to Oppo Apps, and 1% were to the Vivo App Store. Further, globally, only 2% of monthly app store time spent was in the Galaxy Store, whilst 1% was in Xiaomi Market, 1% was in Oppo Apps, and 1% was in the Vivo App Store.
6102 Fifth, “[d]espite users with Chinese OEM app stores being MAU, the visits in a month make up only a tiny fraction of the regions total app store visits (<3% of Play Store total visits)”.
6103 Further, the shares of new app downloads from various sources is also instructive.
6104 In 2020, the Play Store accounted for 73% of new app downloads in both Australia and globally. OEM and third party app stores accounted for 2% of new app downloads in Australia and 7% globally. Direct downloading or downloads from directly downloaded app stores accounted for 3% of new app downloads in Australia and 12% globally.
6105 Relative to the Play Store, the market shares of other Android app stores are very modest indeed.
General
6106 Epic says that the purpose of Google’s contravening conduct is to ensure and to maintain the position of the Play Store as the dominant supplier of services for the distribution of Android apps, by preventing or hindering rival sources of distribution.
6107 Further, Epic says that Google compels developers to use its own payment solution, Google Play Billing, as the sole supplier of services for facilitating payments for in-app purchases of digital content within apps downloaded from the Play Store.
6108 Generally, Epic says that Google’s contravening conduct should not be viewed separately or in isolation, but as a coherent whole.
6109 And Epic says that each aspect contributes toward securing more users for the Play Store and Google Play Billing and hindering rival Android app stores or payment solution providers from competing with the Play Store and Google Play Billing respectively.
6110 Now I appreciate Epic’s points and have taken into account all of these matters as part of the relevant context and setting during my consideration of specific circumstances and conduct.
6111 Moreover, I have considered the impugned conduct in the aggregate and considered whether in its totality there was an overall anti-competitive purpose. But I am not convinced that there was.
6112 Further, I should also say that I have considered whether in relation to a particular aspect of impugned conduct, which I have found was not specifically engaged in for an anti-competitive purpose, nevertheless looked at in the totality of all of the other conduct and the above matters it is appropriate to nevertheless infer an anti-competitive purpose from the total context, not just the specific circumstances or episodes. But I am not so convinced to do so.
The overall anti-competitive effect of Google’s conduct – Android mobile app distribution
6113 What is the cumulative effect of Google’s restrictive conditions? How would matters change if all of the restrictions which Epic challenges were removed? Epic’s case is that the OEM restrictive conduct and app developer restrictive conduct work and have worked in conjunction to frustrate the main routes to market for rival Android app stores.
6114 In summary, Epic says that Google’s conduct has had or has the following anti-competitive effect or likely effect.
6115 First, by way of the MADA provisions, Epic says that Google’s conduct makes the Play Store a default choice, and often the only app store choice, on virtually every Android device in the world. It does this by ensuring that no other Android app store can ever be the only app store pre-installed, let alone the only app store pre-installed on the DHS, of an Android device. The best any rival can hope to achieve is to be pre-installed together with and alongside the Play Store. But I have rejected Epic’s competition breaches case on this aspect.
6116 Second, by way of the technical restrictions, Epic says that Google’s conduct hinders the installation of rival app stores on Android devices by way of direct downloading, and disadvantages rival app stores that lack privileged installation permissions. As such, rival Android app stores wholly or partially reliant on this route to market need to overcome a very poor initial user experience which is apt to dissuade a large proportion of users from completing the installation process and becoming users of the rival app store. But I have rejected Epic’s competition breaches case on this aspect.
6117 Third, during the relevant period that the relevant RSA3s and MIAs were on foot, Epic says that Google’s conduct disincentivised OEMs from spending effort or money investing in their own app stores by sharing Play Store revenues and cut off another avenue for competition with the Play Store, through prohibitions on pre-installing rival Android app stores or apps which are not also on the Play Store. I have accepted in large part Epic’s competition breaches case on the question of purpose on this aspect. But I have rejected Epic’s effects case.
6118 Fourth, Epic says that by way of clause 4.5 of the DDA, Google’s conduct hinders the ability of rival Android app stores to emerge or expand by preventing developers from distributing an alternative app store via the Play Store. But again I have rejected Epic’s competition breaches case on this aspect.
6119 Fifth, Epic says that by way of Project Hug, the GVP agreements and the AVP agreements, Google’s conduct prevents or hinders the development or expansion of rival Android app stores, by making it impossible for them to offer differentiated content from the participating Project Hug developers which Google recognised as beacons of the Android ecosystem. Without such differentiated content, rival Android app stores were never likely to succeed at scale, and users were unlikely to switch from the Play Store to rival Android app stores. I have accepted in large part Epic’s competition breaches case on the question of purpose, but only likely effect concerning Project Hug and the GVP agreements.
6120 Now Epic says that each of these matters maximises or has maximised the prospect that Android device users will continue to choose the Play Store, rather than any alternative Android app store. And it presumably would say that also in terms of just the third and fifth points which I have found.
6121 Now I do not consider it to be useful to discuss the overall effects case further given that I have only found for Epic on some of the grounds. And where counterfactuals needed to be discussed, I have addressed them specifically in particular contexts.
Cross-effect of conduct in the mobile OS licensing and Android mobile app distribution markets
6122 Now Epic also says that there is an important nexus between Google’s OEM restrictive conduct and its app developer restrictive conduct, and competition in the Android in-app payment solutions market. It has made the following points.
6123 It says that apart from the in-app payment solutions restrictive conduct, Google’s conduct with respect to OEMs and app developers ensures that app developers who wish to reach most Android device users have no real choice but to distribute their apps through the Play Store and accept the DDA terms.
6124 But it says that that conduct facilitates and supports the anti-competitive conduct in which Google engages in the Android in-app payment solutions market, because it ensures that developers are, in practical terms, required to accept the payments tie and the anti-steering rule.
6125 Indeed, it says that both the payments tie and the anti-steering rule form part of the DDA terms, and as such, are an integral part of Google’s conduct vis-à-vis app developers.
6126 So, Epic says that the effect and likely effect of the conduct referred to is not limited to the Android mobile app distribution market. It also substantially lessens competition in the Android in-app payment solutions market.
6127 I accept that this is so, although I am not sure how far this takes Epic given that I have found only that in the Android mobile app distribution market the conduct concerning Project Hug and the GVP agreements involved a likely effect of substantially lessening competition.
6128 Finally and for completeness I should say that the anti-competitive conduct in effect or likely effect that I have found has occurred in the Android in app payment solutions market can also be treated as conduct in the Android mobile app distribution market with analogous albeit lesser anti-competitive effect or likely effect , but still reaching the threshold of substantial.
Has Epic been significantly affected by Google’s conduct or policies?
6129 Epic’s case proceeded on the premise that it has been prevented from launching a mobile app store on Android because of Google’s impugned policies and conduct. But such a premise was problematic as Google pointed out in the following terms which I accept.
6130 First, Epic was not prevented from launching its own mobile app store in the current Android environment. Epic had also made clear that it expects the mobile Epic Games Store to be a success whatever the market conditions, and notwithstanding the fact that it will not be distributed through the Play Store and that it will be sideloaded onto Android devices.
6131 Second, in order to obtain a market share from a powerful incumbent, it is not necessary that a market entrant must have access to the incumbent’s user base and, in the present context, by being distributed through the incumbent’s app store. As Google points out, the success of the Epic Games Store on PC illustrates the point. Epic was able to obtain market share from Steam by relying on its own quality first-party titles and investing in exclusive, quality third-party content and offering minimum guarantees to developers. It was not necessary for the Epic Games Store on PC to be distributed through Steam in order for the Epic Games Store to be successful.
6132 Third, and generally, a market entrant can solve the “chicken and egg” problem if it is willing to invest in developers and users in order to build its app store.
6133 Fourth, Epic is not the only anticipated new entrant in the mobile app store market. On 9 May 2024, Microsoft announced its intention to launch a mobile store relying on its first-party titles initially before expanding to third-party titles in order to offer users a cross-platform gaming centric mobile experience.
6134 Now there are a number of dimensions that it is necessary to consider and it is convenient to address four matters in some detail.
6135 The first matter is that Epic claims that Fortnite underperformed after it launched on Android because it chose not to launch on the Play Store, which Epic alleges caused it to experience install frictions from sideloading and a lack of discoverability. But I agree with Google that Fortnite seems to have underperformed on Android for reasons within Epic’s control and unrelated to Google. Let me delve into some background, which Google has elaborated on in terms that I agree with.
6136 In early 2018, Epic and Google began discussing Epic’s plan to roll out Fortnite on Android. Epic wanted Fortnite to be playable on a mobile device in exactly the same way as it was playable on a game console and PC. This challenged the technical capabilities of Android devices, and also meant that only high-end devices would be able to support Fortnite as Epic intended. Google’s Android OS and graphics team assisted Epic to optimise Fortnite including ironing out wrinkles and bugs, working with Epic’s engineers on improvements to the game and running testing.
6137 In June 2018, Epic told Google that it would not be launching Fortnite on the Play Store. Epic told Google in June 2018 despite having decided by at least February 2018 that it would not be launching Fortnite on the Play Store because it did not want to pay Google’s service fee.
6138 But Google continued to work towards bringing Fortnite to the Play Store including by offering initiatives to respond to Epic’s contention that the Play Store did not add value to Epic commensurate with its service fee.
6139 On 9 August 2018, Epic launched the Fortnite installer app on Android by making the installer available on the Samsung Galaxy Store and for direct download from Epic’s website, and by the pre-installation of a stub, being a small file that links to an internet location from which the full app can be downloaded, of the Fortnite installer app on certain Samsung devices pursuant to the Samsung collaboration agreement.
6140 Now the launch of Fortnite on Android in August 2018 was a success. In the first month, there were 4.2 million average monthly active Android users. None of these users came from the Play Store. All users came from the Samsung Galaxy Store or from Epic’s website or by the stub on certain Samsung devices.
6141 Now in relation to pre-installation, upon launching on Android in August 2018, a stub of the Fortnite installer app was pre-installed on certain Samsung devices. In 2019 Epic also entered into pre-installation agreements with Huawei, Sony and LG. By February 2020, Samsung had pre-installed the Fortnite installer app on more than 29 million Android devices. Further, by February 2021, the Fortnite installer app or Epic Games Installer app had been downloaded from Epic’s website more than 93 million times.
6142 Now despite its initial success, ultimately Fortnite did not perform on Android as Epic had hoped.
6143 I largely agree with Google that the reasons for the underperformance of Fortnite on Android seem to have been mostly unrelated to Google’s impugned policies and conduct. Google explained the reasons in the following terms which are in substance accurate in my view.
6144 Fortnite had and has high minimum specification requirements which meant that it could not be run on most Android devices. At the time of Fortnite’s launch in August 2018, only about 10% of Android devices were Fortnite compatible, approximately 75% of which could install Fortnite from the Samsung Galaxy Store. Moreover, Epic was aware of the impact that Fortnite’s high minimum specification requirements had on its ability to reach Android users.
6145 In May 2019, Mr Sweeney identified the minimum specification issue to the Epic board as one of two things that were limiting Fortnite on Android. The other limitation that he identified was losing traffic from users who were not core Fortnite players because they were not finding Fortnite when looking for a game to play on the Play Store. So, it was perceived that Fortnite was missing out on the Play Store’s discoverability benefits.
6146 Now in November 2019, Epic launched a lower minimum specification game called Battle Breakers, which it used as a natural experiment on the extent to which sideloading and minimum specification issues caused attrition during the installation process for Fortnite.
6147 A slide deck titled Epic Mobile Update dated 27 November 2019 compared the drop-off funnels for Fortnite and Battle Breakers and recorded a 26% drop-off for sideloading complexity and a 26% drop-off at what was described as the minimum specification check, being a reference to the fact that a user’s device is not capable of installing Fortnite.
6148 Contrastingly, for Battle Breakers the drop-off for sideloading complexity was only 15% and the drop-off at the minimum specification check was only 2%. The lower drop-off for Battle Breakers with lower minimum specifications confirmed that Fortnite was losing a significant number of users due to its high minimum specification requirements.
6149 By 2020, as Google points out, Fortnite’s Android coverage had not materially improved.
6150 Further, Fortnite’s long download time on Android seriously limited its take-up, particularly during the period when Fortnite could not be downloaded in the background. Fortnite’s 20-minute Android download time was longer than on iOS, and significantly longer than competing Android game apps. This put Fortnite at a competitive disadvantage to other competing Android games by virtue of its own inherent features.
6151 Further, some of the drop off in users during the sideloading phase was due to Epic’s two apps strategy of using a launcher that later could be turned into the Epic Games Store, as opposed to allowing Fortnite to be directly sideloaded. Consequently, the installation process for Fortnite involved additional steps.
6152 Now as Google says, some senior Epic executives queried the two apps approach. Mr Sargent, who was responsible for the client-side software that implements the Epic Games Store, thought that it was technically possible to merge the two apps.
6153 Now it would seem that Epic did not need to use a launcher that could launch other apps. But apparently the two apps approach was important to Epic’s strategy for the Epic Games Store.
6154 Further, I agree with Google that Epic faced challenges inherent to Fortnite that had nothing to do with Google’s impugned policies or conduct.
6155 In a presentation titled Epic Mobile Update dated 19 May 2020, Epic recorded being faced with challenges such as user content fatigue, long load times after game updates, regular and lengthy game updates, the fact that Fortnite was a large file, poor game performance, the high minimum specification requirements, and the lack of a mobile centric game experience.
6156 Further, even among users who were able to play Fortnite on Android and were not deterred by the various challenges, the levels of retention and monetisation on Android were lower than what Epic anticipated, and lower than on every other platform on which Fortnite could be played. This caused Epic to limit its marketing spend to promote Fortnite on Android, which in turn further limited its success. So in other words a negative feed-back loop arose.
6157 Now Epic found that Android users typically spent less on Fortnite than users on console, PC and iOS. The average revenue per daily active user (ARPDAU) of Fortnite on Android was lower than that on any other platform. And despite Fortnite having the same number of installations on Android as on PC, Android had fewer daily active users (DAU) and much less revenue.
6158 Generally, it would seem that users who installed Fortnite on Android had much lower levels of engagement and spending than users on other platforms. Further, players that were first seen on Android were more likely to spend on various other platforms than Android, in particular on consoles.
6159 Now Epic had assumed that at least 10% of users who installed the Fortnite app would open it within 120 days. But in fact the retention rate was much lower. Only 2% of users who downloaded Fortnite on Android opened it by day 120 after installation and the retention rate for Android was significantly lower than iOS and all other platforms. Moreover, the lower retention correlated with lower revenue.
6160 Now Epic had also assumed that the net cumulative revenue per install (CRPI) of Fortnite on day 120 after installation would be $5.65, and $5.84 on day 180. But the actual CRPI on day 180 of Fortnite’s launch on Android was $1.13 and the Android CRPI was lowest for all platforms. And irrespective of whether $1.13 was gross or net, the amount was significantly lower than was modelled.
6161 Now because the revenue generated from Fortnite on Android was so low that it did not cover Epic’s costs, Epic could not realistically spend more than $1 million dollars in marketing Fortnite on Android. And given that Epic had to reduce its marketing spend to acquire new users for Fortnite on Android, Epic was less able to attract new users than it had or could reasonably have anticipated.
6162 Further, users complained about the performance of Fortnite on Android and in general preferred to play on any other platform than Android.
6163 In summary, I agree with Google that Fortnite’s lack of success on Android had little to do with Google’s impugned policies or conduct.
6164 The second matter is that Epic says that in order for its mobile store on Android to be very successful it needed to be distributed through the Play Store such that it would be more discoverable and overcome friction associated with sideloading. Now I agree with Epic that all of that may have some truth to it.
6165 But as Google has said, Epic’s success with the Epic Games Store on PC in winning market share from Steam demonstrates that it is not necessary for an app store to be distributed through another app store in order to succeed at least to some substantial extent. Google pointed to the following matters which I accept.
6166 In 2014, Epic launched the Epic Games Launcher on its website for PC users and to distribute its PC apps. In December 2018, Epic began to distribute other developers’ apps for PC through the Epic Games Store. Until that time, Steam had been the dominant player in the distribution of PC apps.
6167 Now at the time that Epic entered the market, Steam had a large user base and a competitive advantage attractive to developers. So as a new entrant app store, the Epic Games Store on PC had to overcome Steam’s competitive advantage by gaining a critical mass of users so that developers would be sufficiently attracted to the store.
6168 In order to do so, Epic deployed a range of strategies including offering differentiated features to compete with Steam such as a lower commission rate, providing users with access to Epic’s highly popular first-party titles, and attracting developers of high quality third-party titles to the Epic Games Store on PC by offering them minimum guarantees to mitigate the perceived risk amongst developers of distributing games exclusively on the Epic Games Store rather than Steam.
6169 As of January 2020, Epic had offered [REDACTED] of cumulative minimum guarantees to developers on PC. And by underwriting its effort to develop a games store on PC, Epic quickly acquired a material portion of Steam’s market share.
6170 The Epic Games Store on PC achieved significant success. And as Google points out, the key to Epic’s success with the Epic Games Store on PC was its willingness to invest. So, Epic did not obtain and nor did it need to have access to Steam’s large user base.
6171 Now the third matter that Google correctly points to concerns Mr Sweeney’s change of strategy in or around September 2019 that involved putting Fortnite on the Play Store in a Trojan-like tactic and knowingly in breach of the DDA as part of his litigation strategy. As I have explained elsewhere, Mr Sweeney’s strategy culminated in the removal of Fortnite from the Play Store because Epic breached the DDA and the payments policy by introducing EDP via a hotfix.
6172 As Google says, this in part explains why Epic did not formulate a concrete strategy or plan to launch the Epic Games Store on Android, which had little to do with Google’s alleged policies or conduct.
6173 Let me go back in time a little, adopting some of the chronology of events that Google has provided to me.
6174 In 2018 Epic’s focus was on developing the Epic Games Store for PC which launched in December 2018. But Epic’s plan at the time was also to put the Epic Games Store on Android in 2019, with Mr Sweeney being aware that Android is an open platform which makes this possible.
6175 Now notwithstanding that Epic’s initial plan was to launch Fortnite on Android with the Fortnite installer app that later could be upgraded to the Epic Games Store on mobile, Epic did not have the bandwidth to focus on developing both a store for PC and a store for mobile.
6176 Indeed in August 2018, Mr Allison expressed concern that a mobile store would be potentially distracting to his team which was working towards launching an app store on PC. He thought that it would be better to wait until the PC store was “stood up” and when the “publishing process for android is really truly ‘push a button to publish’”. And even by late 2019, Mr Allison was still focused on the PC store and was not planning to devote any significant effort to a mobile store.
6177 Further, for some time, Mr Allison was concerned that the differences between the PC games environment and the mobile games environment made it difficult to find a viable revenue model for a store on Android.
6178 Mr Allison identified in his email of 4 August 2018 a concern that game revenue on mobile was concentrated amongst the top titles. He also identified the need to operate at scale and queried how that could be done on mobile. Mr Allison suggested conducting further analysis as to which mobile games make money and how they make money before starting to think about an app store for mobile.
6179 Now since 2018, these concerns and differences from PC have either abated or been alleviated sufficiently for Epic to now progress its plans to launch a mobile store. Notably, several of the differences between mobile and PC that Mr Allison once perceived have either narrowed or disappeared. Further, Epic now has sufficient scale to be able to launch a successful Epic Games Store on mobile. Indeed, Epic recognised that scaling to mobile was easier than previous generations. Compared to 2018 when Epic had zero users beyond Fortnite, it now has 75 million MAUs.
6180 But by September 2019, Mr Sweeney had de-prioritised his plans to launch a mobile store on Android in favour of putting Fortnite on the Play Store. Mr Sweeney changed his plans in order to replace Epic’s commercial strategy with a litigation strategy against both Apple and Google, which plan became known as Project Liberty. This was a coordinated effort to challenge certain policies relating to the App Store and the Play Store. Epic wanted to challenge the requirement to use Apple’s IAP, and to use Google Play Billing, for in-app purchases and the requirement that neither a native iOS app nor a native Android app on the Play Store operate as a store within a store.
6181 Epic’s plan as to Google was to submit a version of Fortnite to the Play Store that contained a hotfix that would allow for payment using EDP in breach of the DDA and Google’s payments policy.
6182 As I say, by September 2019 Mr Sweeney had decided to put Fortnite on the Play Store instead with EDP.
6183 On 24 September 2019, Mr Sweeney announced this to the Epic Games Store team in a meeting. This change of direction by Mr Sweeney caused the launch of the Epic Games Store on Android to be deferred.
6184 Now although Mr Sweeney sought to deny it, I agree with Google that Mr Sweeney’s sudden change of direction was not because he had suddenly realised that Google’s policies made it unviable to launch the Epic Games Store on Android. Rather, he wanted to start a litigation strategy that was directed at pressuring Google and Apple to allow developers to use alternative billing systems on the App Store and the Play Store, rather than a commercial strategy of competing with the Play Store through the Epic Games Store, which Epic had contemplated as being feasible.
6185 Now prior to Mr Sweeney’s announcement, Epic’s strategy was to not ship Fortnite on the Play Store, notwithstanding that the strategy may have affected growth of Epic’s user base via pre-registrations and visibility on the Play Store.
6186 I agree with Google that by legitimate abductive reasoning, the sudden change in strategy is best explained by Mr Sweeney’s determination to pursue litigation to pressure Google to enable the use of alternative billing systems on the Play Store.
6187 Now in an email sent shortly after Mr Sweeney announced his change of direction, Mr Hasseb Malik said to various senior people within Epic:
Now we are going another route and the goal is draw Google into a legal battle over anti-trust. Once we are ready to submit, Epic will announce publicly that we are going to Google Play. If we are rejected for only offering Epic’s payment solution. The battle begins. It’s going to be fun!
6188 Mr Malik was at the 24 September 2019 meeting and obtained his understanding from Mr Sweeney.
6189 Now in the chat the next day between Mr Calentino and Mr Shobin there was no suggestion that the change of direction was because Mr Sweeney thought putting the Epic Games Store on Android was unviable. On the contrary, Mr Calentino understood that it pushed off the conversation of the need for the Epic Games Store to a time when the question might not matter anymore.
6190 I agree with Google that it would seem that the litigation strategy and the Epic Games Store on mobile were seen as alternatives to achieving the same end, which was the distribution of apps on Android without having to pay Google the 30% service fee.
6191 Now when Epic submitted to Google in December 2019 a version of Fortnite that used Epic’s payment system rather than Google Play Billing, the contemporaneous documents show that Mr Sweeney already had litigation with Google in mind.
6192 On 5 December 2019, Mr Sweeney’s email to Google communicated that Epic was considering litigation if Google did not allow it to use its own billing system.
6193 On 13 December 2019, in an internal email that Mr Sweeney sent concerning a revised version of Fortnite that fixed all issues apart from its inclusion of Epic Direct Pay rather than Google Play Billing, he said:
We aren’t going to address issue #2. Google’s in the wrong on this, so we’ll resubmit with Epic payment still enabled as usual. We need to get to the point where this is the only issue where Fortnite doesn’t fit with Google’s guidelines.
6194 On 14 December 2019, Mr Sweeney confirmed this in a tweet:
Our intention is to adhere to all Google Play guidelines except for the Google payment processing / 30% tax guideline. We’re working on an update for resubmission early next week.
6195 Now it would seem that Mr Sweeney wanted to crystallise a refusal by Google to accept Epic’s payment processing solution because it could provide evidence that would be necessary if Epic decided to litigate against Google. He also thought at the time that there was a reasonably high likelihood that Google would reject this version of Fortnite under its payments policy.
6196 Further, as Google points out, even Mr Sweeney’s version of events supports the fact that Epic merely put off launching a mobile store on Android so that it could explore a litigation strategy. The launch was not put off because Epic dismissed it as unviable.
6197 Further, Mr Sweeney also conceded that by September 2019 he had in mind challenging the Apple App store policies. As Google points out, he conceded that he had started to form the view that if he were to challenge Apple, Epic would need to take a symmetric approach to Apple and Google. He conceded that he knew it would not have been a symmetric approach to Apple and Google had Epic launched the Epic Games Store on Android. And he conceded that he felt that before litigating against Google, Epic had to clear the way to ascertain whether Google would refuse to allow Epic to use its own billing system in Fortnite on the Play Store.
6198 So it would seem that by around September 2019, Mr Sweeney had at least decided to suspend the mobile store work so he could explore crystallising a rejection by Google as a precursor to potentially provoking an antitrust battle with Apple and Google. But he was by no means ruling out launching a mobile store on Android.
6199 Now clearly Mr Sweeney’s change of direction in September 2019 postponed the launch of an Epic Games Store on Android because the decision to put Fortnite on the Play Store meant that Epic could no longer rely on Fortnite as an exclusive game title to anchor its store on Android.
6200 But even if there was no then strategy for a mobile store on Android as of October 2019, this did not mean that Epic thought it could not launch a store on Android. It just meant that due to Mr Sweeney’s strategic shift in relation to Fortnite, more work had to be done on the strategy before it could do so.
6201 Now as Google has said, the launch of a mobile store took a backseat to Epic’s litigation strategy against Google at least until the removal of Fortnite from the Play Store.
6202 On 26 March 2020, after receiving an email from Mr Donald Harrison regarding the need for Epic to comply with Google’s policies, including the use of Google Play Billing, Mr Sweeney decided to list Fortnite on the Play Store using Google Play Billing. But he accepted in cross-examination that he was considering undertaking the hotfix strategy, and it was on the table by the time Epic submitted a compliant version of Fortnite to the Play Store. So, Epic’s decision to launch on the Play Store was tied to its litigation strategy.
6203 On 9 April 2020, Mr Ed Zobrist emailed senior Google executives informing them that Epic would submit an updated Fortnite build that fully complied with Google’s policies. This included integrating Google Play Billing and removing all other payment platforms.
6204 When Google probed Epic about the reason for the change in approach, Mr Sweeney said to Google that “you had said that Google would be happy to have Fortnite on Android under its existing terms, so here we are.” Yet at the same time, Epic was considering a plan to undermine this by implementing the hotfix strategy.
6205 Moreover, at no point did Epic convey to Google that it only intended to comply with Google’s policies in the short term and that it intended to change its process later. Meanwhile, Epic continued to receive technical assistance from Google at no charge in the lead up to the launch of Fortnite on the Play Store.
6206 On 21 April 2020, Fortnite launched on the Play Store.
6207 On 23 April 2020, Mr Sweeney directed Mr Zobrist to set up a meeting for the purpose of starting to explore the hotfix strategy. This was a product of Mr Sweeney’s litigation strategy which he had adopted back in 2019. This is reinforced by Mr Sweeney’s 29 April 2020 email in which he encouraged his team to focus on “executing” the plan, not backtracking on it.
6208 In a slide deck titled Mobile Payments Sync dated 30 April 2020, the rollout plan for the hotfix indicated that it would involve “submit[ting] with Epic Payment Option disabled (hidden). Hotfix on afterwards” with the “likely outcome” being that “neither platform would be able to detect this flow until we hotfix it on.”
6209 Now Epic expected that Fortnite would be removed from the app store as a result of the breach. Indeed, Mr Sweeney indicated internally that if Google was to remove the app from the Play Store, “it will trigger Epic filing injunctions in numerous jurisdictions to stop them, and creates a VERY precarious situation for them where they could be forced to abandon their policy in some geographies.”
6210 Further, the fact that the hotfix was part of Mr Sweeney’s litigation strategy is evidenced by the fact that Epic would be financially worse off in all reasonable scenarios by pursuing it. This was because it involved a 20% price drop for V-Bucks across all platforms apart from the App Store and the Play Store. Epic estimated that the mega drop would cause 50% of mobile revenue to transfer to other platforms.
6211 On 13 August 2020, Google removed Fortnite from the Play Store because Epic breached the DDA and the payments policy by introducing Epic Direct Pay via a hotfix.
6212 After the removal of Fortnite from the Play Store, Epic marketed to consumers that it was challenging Apple and Google, and that they could continue playing and spending on Fortnite on other platforms.
6213 In summary, and as Google points out in essence, over 2019 and 2020 Epic de-prioritised the development of a mobile store on Android not because of Google’s alleged policies or conduct, but because of its focus on a litigation strategy against both Apple and Google and a desire to take a symmetrical approach to its strategy on Android whose openness would have allowed Epic to launch the Epic Games Store on mobile at any time, and its strategy concerning iOS whose closed ecosystem did not.
6214 Further, another reason for de-prioritising the Android mobile store around the time that Epic was pursuing its litigation strategy was that there were concerns within Epic as to the viability of a store on Android if it allowed third-party developers to use alternative billing.
6215 On 3 December 2019, Mr Allison sent an email to Mr Sweeney and other Epic executives querying how an Android store could be viable if it permitted alternative billing when more than 95% of in-app game revenue comes from 1% of games, and in circumstances where those developers are likely to be utilising other billing solutions.
6216 Later that same day, Mr Allison sent a further email querying why large developers would be attracted to an Android store and expressed serious concern about “running at this and sputtering”.
6217 Now at this time Mr Allison was attempting to work out the fundamentals of a viable business model for the Epic Games Store on Android, including the basis for attracting third-party developers and driving sufficient audience scale, which were key matters that needed to be resolved before an Android store could be launched. These concerns were sparked by Epic’s billing policy, and the concentrated nature of in-app game revenue on mobile devices.
6218 Now since 2019, these concerns had been alleviated from Epic’s perspective as Epic considered itself able to launch the Epic Games Store on Android.
6219 Further, Mr Allison was unable to devote substantial resources to developing a strategy for an Epic Games Store on Android until he had approval from Mr Sweeney. He did not have that approval from Mr Sweeney in October 2019 and nor did he have it in January 2020. Mr Allison did not advance Epic’s plans for launching an app store on Android at that time given that it was not then a priority for Mr Sweeney.
6220 In summary, I agree with Google that Epic de-prioritised and delayed the development of a mobile store on Android not because it thought that a mobile store on Android would be rendered unviable by reason of Google’s impugned policies and conduct. Rather, Epic chose to focus its efforts on other strategies and projects, including its litigation strategy against Apple and Google.
6221 The fourth matter that Google referred to is that on 20 March 2024, Epic announced at the Games Developers Conference that it would launch its mobile Epic Games Store on both iOS and Android by the end of 2024. But I do not consider it necessary to discuss what has followed or what may follow from all of this. I will need to be updated in due course as to the events that have occurred since the trial concluded and any future proposals for the purposes of any hearing on remedy.
Epic’s claims for contraventions of ss 45, 46 and 47
6222 Let me address a preliminary matter before dealing with each of the specific contraventions.
The territorial reach of Part IV
6223 In its closing submissions Google abandoned any contention to the effect that the CCA does not relevantly apply to the matters raised in these proceedings. Further, there is now no issue as to the operation of s 5(1)(g) of the CCA concerning whether Google LLC or Google Asia Pacific Pte Ltd carry on business in Australia. They clearly do, and so the s 5(1)(g) extension applies.
6224 But in any event insofar as the impugned conduct of Google LLC and Google Asia Pacific Pte Ltd was engaged in within Australia, it is unnecessary to rely on s 5(1)(g) to extend the application of the CCA or the ACL to that conduct. And in this respect the following may be noted.
6225 First, each of Epic’s claims against Google LLC and Google Asia Pacific Pte Ltd under ss 45, 46 and 47 alleges a purpose or effect of substantially lessening competition in one or more markets whose geographic dimension is either confined to Australia or includes Australia.
6226 Second, the contravening conduct relied upon for each of Epic’s claims against Google LLC and Google Asia Pacific Pte Ltd under ss 45, 46 and 47 of the CCA includes the imposition and enforcement of the OEM restrictive terms, the app developer restrictive terms and the technical restrictions, both in Australia and overseas.
6227 Third, the contravening conduct relied upon for Epic’s claims against Google Asia Pacific Pte Ltd under s 75B of the CCA includes Google Asia Pacific Pte Ltd’s involvement in Google LLC’s imposition and enforcement of the OEM restrictive terms, the app developer restrictive terms and the technical restrictions, both in Australia and overseas.
6228 Fourth, Epic’s unconscionable conduct claim under s 21 of the ACL also relies on Google LLC’s and Google Asia Pacific Pte Ltd’s imposition and enforcement of the OEM restrictive terms, the app developer restrictive terms and the technical restrictions both in Australia and overseas.
6229 Clearly the conduct which Epic alleges amounts to a contravention of the CCA and the ACL was engaged in by Google LLC and Google Asia Pacific Pte Ltd within Australia. The CCA and the ACL apply to that conduct, whether or not Google LLC and Google Asia Pacific Pte Ltd carry on business within Australia.
6230 Further, the jurisdictional reach of s 47 of the CCA is further extended by s 5(2). The latter provision extends the operation of s 47 to “the engaging in conduct outside Australia by any persons in relation to the supply by those persons of goods or services to persons within Australia”.
6231 So, insofar as Google LLC and Google Asia Pacific Pte Ltd engaged in conduct outside Australia “in relation to” their supply to app developers within Australia of services for the distribution of Android apps, s 5(2) ensures that s 47 applies to that overseas conduct.
Section 46 claims
6232 Now each of Google LLC and Google Asia Pacific Pte Ltd has contravened s 46(1) throughout the relevant period for the reasons that I have previously discussed.
6233 But in my view, Google Payment Australia Pty Ltd did not also contravene s 46(1) throughout the relevant period.
6234 Let it be accepted that Google Payment Australia Pty Ltd has substantial market power in the mobile OS licensing market, the Android mobile app distribution market and the Android in-app payment solutions market by reason of the operation of s 46(3).
6235 I agree with Google that Google Payment Australia Pty Ltd did not contravene s 46(1).
6236 The only conduct to which Epic points on Google Payment Australia Pty Ltd’s part is the making of the PDS with developers and giving effect to its terms. And Epic does not suggest that this conduct, without more, contravenes s 46.
6237 Rather Epic’s case seems to be that Google Payment Australia Pty Ltd nevertheless somehow imposes the requirement on developers to use Google Play Billing. But I agree with Google that this is incorrect.
6238 It is the payments policy together with section 4.1 of the DDA, to which Google Payment Australia Pty Ltd is not a party, that imposes this requirement.
6239 Further, all that Google Payment Australia Pty Ltd does vis-à-vis developers is collect the service fee, which they have contracted with another entity to pay, and accept and facilitate payments under the PDS.
6240 Further, as to Epic’s suggestion that Google LLC engaged in the practical enforcement of the app developer restrictive terms on behalf of Google Payment Australia Pty Ltd, there is no evidence.
6241 So, the s 46 claim against Google Payment Australia Pty Ltd is not made out.
6242 Further, Epic’s accessorial claims invoking s 75B are made out against Google Asia Pacific Pte Ltd, if it is not already liable as a principal. But in my view it has not made out such claims against Google Payment Australia Pty Ltd.
6243 As Google has said, Epic has not established that Google Payment Australia Pty Ltd had the relevant practical connection to Google LLC’s conduct.
6244 The fact that Google Payment Australia Pty Ltd is the “payment processor” in Australia under the DDA, and provides a payment processing service to users and developers under the PDS, does not mean that it has a relevant practical connection to all of Google LLC’s conduct under the OEM agreements or developer agreements.
6245 Google Payment Australia Pty Ltd is not a party to those agreements and has nothing to do with them.
6246 Further, Epic has not proven that Google Payment Australia Pty Ltd had actual knowledge of all the essential facts or matters that constitute the alleged s 46 contravention by Google LLC or for that matter Google Asia Pacific Pte Ltd.
6247 To demonstrate the relevant state of mind, Epic would need to have shown that a director, employee or agent of Google Payment Australia Pty Ltd engaged in the conduct, that is, the conduct with a practical connection to Google LLC’s conduct or Google Asia Pacific Pte Ltd’s conduct within the scope of their actual or apparent authority, and had the requisite state of mind.
6248 But Epic has not identified any relevant director, employee or agent who had the requisite state of mind, let alone identified the evidence that proves this individual or individuals had this state of mind.
6249 I would reject Epic’s accessorial liability claim against Google Payment Australia Pty Ltd whatever form or permutation it takes.
Section 47 claims
6250 Let me make a preliminary point. Both ss 45 and s 47 apply irrespective of whether or not Google possesses substantial market power in the alleged markets.
6251 Now ss 45 and 47 are strict alternatives. Section 45 does not apply to conduct that would constitute a contravention of s 47 (see ss 45(5A) and (6)). Accordingly, it is appropriate to address s 47 before s 45.
6252 Section 47 prohibits exclusive dealing where it has the purpose, effect or likely effect of substantially lessening competition.
6253 Section 47(2) defines exclusive dealing as, relevantly, supplying or offering to supply goods or services on the condition that the person to whom the supply or offer is made will not, or will not except to a limited extent, acquire services of a particular kind or description from a competitor or competitor of a related body corporate.
6254 Now Epic says that throughout the relevant period, Google LLC and Google Asia Pacific Pte Ltd supplied and offered to supply to app developers services for the distribution of Android apps to Android device users via the Play Store, on condition that those developers would not acquire services for the facilitation of payments for in-app purchases of digital content in Android apps distributed via the Play Store from any person other than Google LLC or Google Asia Pacific Pte Ltd.
6255 Epic says that that conduct constituted exclusive dealing within the meaning of s 47(1).
6256 Further, Epic says that the substantial purpose and/or the effect or likely effect of that conduct was to substantially lessen competition in the Android in-app payment solutions market.
6257 In the alternative, Epic says that Google Asia Pacific Pte Ltd aided, abetted, counselled or procured, alternatively was knowingly concerned in, or conspired to effect, Google LLC’s contravention of s 47.
6258 And it is said that Google Payment Australia Pty Ltd is similarly liable on an accessorial basis.
Section 45 claims
6259 Section 45 prohibits corporations from making a contract or arrangement, or arriving at an understanding, which has a provision with the purpose, effect or likely effect of substantially lessening competition. Section 45 also prohibits corporations from giving effect to such provisions.
6260 Section 45 applies to competition in any market in which Google supplies or acquires goods or services (s 45(3)). And in assessing anti-competitive effects, one must aggregate the relevant contractual provisions with those of any other contract, arrangement or understanding to which Google is a party (s 45(4)).
6261 Now Google LLC and Google Asia Pacific Pte Ltd are parties to numerous agreements. In the case of Google LLC, it is a party to the MADAs, ACCs, and RSAs with OEMs, DDAs with app developers, and the GVP and AVP agreements with larger app developers. In the case of Google Asia Pacific Pte Ltd, it is a party to all of those agreements other than the MADAs and ACCs.
6262 Epic says that individually and cumulatively the provisions of these agreements have the purpose, effect or likely effect of substantially lessening competition in the pleaded markets.
6263 Accordingly, Epic says that by entering into, and giving effect to, the various contracts with the various OEMs and app developers, Google LLC and Google Asia Pacific Pte Ltd have contravened s 45. Now Epic made reference to Google Payment Australia Pty Ltd and the PDS, but the point was hopeless.
6264 In the alternative, Epic says that each of Google Asia Pacific Pte Ltd and Google Payment Australia Pty Ltd aided, abetted, counselled or procured, alternatively was knowingly concerned in, or conspired to effect, Google LLC’s or Google Asia Pacific Pte Ltd’s contravention of s 45.
Analysis
6265 Now Epic’s allegations under s 45 and s 47 should be rejected for several reasons.
6266 First, Epic’s s 47 claim relies on proving that the requirement to use Google Play Billing is a condition of supplying services for the distribution of Android apps to users via the Play Store to the effect that developers will not acquire goods or services from a competitor of Google (s 47(2)(d)). In my view it fails on the condition aspect and the competitor aspect. If the parties require from me additional reasons on these questions I will provide them.
6267 Second, s 45(1)(a) focuses relevantly on the making of a contract containing a provision that has the requisite purpose or effect, and s 45(1)(b) focuses on giving effect to a provision of a contract where that provision has the requisite purpose or effect.
6268 But as Google points out, Epic does not rely upon any individual contract entered into with a developer or any individual contract entered into with an OEM, but seeks to show the proscribed purpose or effect when all OEM contracts and developer contracts are aggregated, relying on s 45(4) for this purpose. But as Google says, there is a significant temporal difficulty with this aggregation approach. And it correctly makes the following points.
6269 First, as to the “making” allegations, the purpose and effect of the impugned provision must be determined at the time the contract was made.
6270 Second, as for the “giving effect” allegations, the effect of the impugned provision must be determined at the time of giving effect, but the purpose still must be determined at the time the contract was made, since it relies upon the end sought to be achieved when the provision was included.
6271 So, what needs to be determined is the relevant purpose or effect at the time that each particular contract was made, or the effect at the time the provision was given effect to.
6272 So, as Google says, it is the case that for each individual contract with an OEM or developer, I would need to have regard to the other contracts in existence at that time, but not contracts that were made subsequently or contracts that had already ceased.
6273 So, for example, the purpose and effect of the first GVP agreement with a developer would need to be assessed having regard to whichever other OEM and developer agreements were in place at that time, but not agreements made subsequently or that had ceased.
6274 In other words, there may be different circumstances and levels of aggregation for each individual contract that would need to be considered separately before it could be determined whether any individual contract has the requisite purpose or effect.
6275 Now as Google correctly points out, Epic has not performed any of this type of analysis.
6276 In those circumstances, I cannot be satisfied that any particular contract had the requisite purpose or effect at the time it was made, or effect at the time it was given effect.
6277 Now given that there are no primary contraventions of either s 47 or s 45, there therefore can be no accessorial liability.
Epic’s claims concerning unconscionable conduct
6278 Epic says that Google’s OEM restrictive conduct and app developer restrictive conduct contravened s 21 of the ACL.
6279 Epic’s unconscionability claim rests on substantially the same evidentiary foundations as the Pt IV claims. And the question that arises here in respect of those shared fact patterns and conduct is whether they support an evaluative conclusion that the totality of the relevant conduct is unconscionable. I accept that the context in which that question is to be answered is informed by the analysis under the Pt IV regime, which is exogenous to the ACL, but relevant to the conduct in question.
6280 Now I have said elsewhere that the evaluation of the impugned conduct in all the circumstances requires close identification and consideration of the facts, and a properly articulated factual matrix addressed to each of the subject matters in s 22(1) which are relevant to the analysis.
6281 I have already outlined the principles governing the application of s 21(1) of the ACL in my Epic v Apple reasons.
6282 Now given that much of the conduct is found in contractual restrictions, I have to consider the specific terms of the relevant contracts in considering the question of unconscionability.
6283 Let me deal with the various elements of Epic’s claim.
6284 First, Epic says that Google is in a superior bargaining position to app developers, including Epic. And it maintains this position through the OEM restrictive conduct and the app developer restrictive conduct. Epic says that Google then unconscionably deploys that market power against app developers through the DDA and its subordinate policies.
6285 Now Google says that its conduct is required to address the acute economic challenges it faces. But Epic says that the evidence establishes that the conduct has the purpose and effect of substantially lessening competition. It is not pro-competitive. It hinders competition and facilitates the Play Store’s generation of supra-competitive profits.
6286 Now Google says that app developers and users have viable alternative platforms for Android app distribution, but Epic says that Google’s conduct has effectively neutered each alternative as a competitive threat.
6287 Epic says that there are no viable alternatives to the Play Store. And to the extent that there could be, through alternative Android stores and direct distribution, Google’s unconscionable conduct has undermined this potential competition.
6288 Second, Epic says that the terms of the DDA are not a reasonable protection of legitimate interests.
6289 Developers who wish to distribute apps on the Play Store must enter into and abide by all terms of the DDA. Google does not negotiate the terms of the DDA.
6290 Now the fact that the DDA is a non-negotiable, standard-form contract does not mean that Google’s conduct is necessarily unconscionable. But Epic says that in circumstances where GMS Android is the only commercially viable licensable mobile OS in the market, and the Play Store is the pre-eminent app store, Google is in a position to, and does, exert significant commercial pressure upon developers.
6291 Further, Epic says that the terms and conditions of the DDA are unbalanced.
6292 Epic says that Google forcibly and unnecessarily inserts itself between app developers and their customers. The forced “agency” or “marketplace service provider” relationship lacks the normal attributes of an agency or services contract and is heavily weighted in Google’s favour.
6293 Clause 4.9 prohibits developers from using the information of their customers to distribute Android apps and digital content outside the Play Store.
6294 Further, clause 3.8 authorises Google to decide whether to issue refunds and deduct these amounts from the developers’ revenue. Accordingly, developers are at the mercy of decisions made unilaterally by Google that directly impact their financial position and profitability.
6295 Further, clause 4.1 requires developers to comply with the Developer Program Policies, which preclude developers from updating their apps other than through the Play Store. This creates a situation where an app distributed by the Play Store is forever tied to the Play Store. Epic says that Google’s removal of an app from the Play Store or termination of the DDA makes it impossible for the developer to update apps previously downloaded from the Play Store, and precludes the developer from continuing to serve its users.
6296 Further, through the DDA, Google also maintains expansive control over Android app distribution. Epic says that the following clauses, in tandem, contribute to a system of conduct that is unconscionable.
6297 Clause 8.3 allows Google, at its discretion, to remove apps from the Play Store immediately if Google considers that they violate its policies or may “have an adverse impact” on Google. The meaning of “adverse impact” is undefined and far-reaching; it encompasses “economic, reputational or security-related impact”.
6298 Epic says that developers do not have a standard against which they can measure whether their app is “adverse” to Google. This reinforces the superior bargaining power that Google has over app developers.
6299 Further, clause 10.3 allows Google to unilaterally terminate the DDA with a developer “for any reason” on 30 days’ notice. Users of a terminated app will no longer be able to access in-app purchases or billing features. Further, when exercised, this clause effectively terminates a developer’s relationship with Play Store customers, as they will lose access to and revenue from those customers. Clause 10.3 provides Google with very large leverage in its dealings with developers.
6300 Further, clauses 3.4 and 15.1 give Google unilateral rights to make changes to the DDA, Developer Program Policies, and the service fee charged to developers at any time. This renders the commercial working relationship between app developers and Google unpredictable. All the bargaining power rests with Google.
6301 Further, Epic says that the restrictions that developers face, and the subsequent benefits that Google derives, do not arise in any ordinary agent/principal or commercial relationships. They are precipitated by Google’s substantial degree of market power, the superior bargaining power it has, and the commercial pressure it may exert where Android and the Play Store are the only viable means of distribution.
6302 Epic says that developers have no choice but to acquiesce to Google’s demands through the DDA.
6303 Now Google says that the terms of the DDA are reasonably necessary to protect Google’s interests, and that the DDA is pro-competitive. In particular, Google says that the terms of the DDA are necessary to prevent developers from “free riding” on Google’s investment in the Play Store, and that the DDA confers security protections upon Play Store users. But Epic says that these arguments are not maintainable.
6304 Epic says that pursuing the most restrictive and exclusionary methods of security protection, where less restrictive but equally effective means are available, is not a legitimate interest.
6305 Further, Epic says that extracting 30 percent of developers’ revenue cannot be considered within the scope of a legitimate entitlement to obtain a return on investment. Google’s documents acknowledge that a 30 percent commission is arbitrary and well above the figure necessary to receive a return on investment. And where Google has amended this figure, it has usually been in response to regulatory pressure rather than to competition.
6306 Third, Epic says that Google has engaged in a sustained effort to suppress competitive threats and squash rivalry. It says that Google has engaged in serious, prolonged and systemic contraventions of the CCA, which amount to a pattern of behaviour or a system of conduct that is unconscionable. And it says that the contravening conduct has caused harm to thousands of app developers globally, including Epic.
6307 Generally, Epic says that Google’s conduct is deliberate, sustained, and designed to entrench its substantial market power in the Android app distribution market and the Android in-app payment solutions market.
6308 Epic says that considering the factors at s 22 of the ACL, the Google parties’ conduct is unconscionable within the meaning of s 21(1) of the ACL.
Analysis
6309 Now I agree with Google that Epic’s unconscionable conduct case amounts to little more than a recitation of Epic’s Part IV allegations without the requisite articulation of how those matters amount to a contravention of s 21 of the ACL.
6310 Now as Google correctly characterises the matter, Epic’s unconscionable conduct case reduces to four allegations.
6311 First, Epic says that Google is in a vastly superior bargaining position to app developers, including Epic, and exerts significant commercial pressure upon developers.
6312 Second, Epic says that developers who wish to develop apps on the Play Store must enter into the DDA, and Google does not negotiate the terms of the DDA.
6313 Third, Epic says that three clauses of the DDA being clauses 3.8, 4.1 and 4.9 are unbalanced, and four other clauses being clauses 3.4, 8.3, 10.3 and 15.1 contribute to a system of conduct that is unconscionable.
6314 Fourth, Epic says that Google has engaged in the impugned conduct for a prolonged period, notwithstanding unspecified regulatory scrutiny in other jurisdictions.
6315 But Epic’s unconscionable conduct claim is not made out for the reasons largely advanced by Google.
6316 First, it is contradicted by the reality that the impugned terms of the DDA are commonplace in the industry, and equivalents are found in the developer contracts used by the Samsung Galaxy Store, Amazon Appstore, Microsoft Store and the Epic Games Store.
6317 Second, it assumes that Google would exercise certain contractual powers capriciously, notwithstanding that there is no evidence that it has ever done so.
6318 Third, it relies on unspecified instances of foreign regulatory scrutiny, without even attempting an analysis of whether such scrutiny was in respect of matters that bear upon the conduct now said to be unconscionable.
6319 Now Epic says that Google is in a superior bargaining position to app developers, including Epic. I accept that to be so. I agree with Epic that there is an inequality of bargaining position between developers including Epic and Google.
6320 But notwithstanding this, I tend to agree with Google that the impugned provisions of the DDA reflect industry practice and are not unconscionable.
6321 In assessing whether the impugned provisions of the DDA amount to unconscionable conduct, it is relevant to consider their purpose, the manner in which they have been exercised and industry practice.
6322 As to industry practice, it is apparent that when one considers the developer terms offered by other app stores, including the Samsung Galaxy Store, Epic Games Store, Amazon Appstore and Microsoft Store, almost all of the impugned terms of the DDA find substantial equivalence in the terms of other app stores.
6323 The table annexed to these reasons sets out the clauses of the DDA dated 5 February 2024, unless otherwise indicated, which Epic has referred to in relation to its unconscionable conduct claim against Google, and the position in each of: (a) the Samsung Galaxy Store terms & conditions dated 21 July 2023; (b) the Amazon developer services agreement dated 19 April 2023; (c) the Epic Games Store distribution agreement dated 30 March 2020 (EGSDA 1) and the Epic Games Store distribution agreement dated 4 August 2023 (EGSDA 2); and (d) the Microsoft Store app developer agreement dated 16 June 2022. The Play Store column (Google Play) extracts provisions from the DDA dated 5 February 2024. Now because Epic has cited the DDA dated 3 October 2022, where the relevant clauses cited by Epic have changed in subsequent versions of the DDA, any subsequent insertions or deletions to the DDA dated 3 October 2022 are shown in track. Where there are no changes shown in track, the relevant clause has not changed since 3 October 2022.
6324 Now as Google has done, it is appropriate to address the specific terms of the DDA in turn that Epic has made reference to. I should say that I agree with the responses that Google has made with respect to each of these provisions.
6325 First, clause 3.4 provides that Google may change the service fee with notice to the developer. But since the introduction of the service fee, Google has only ever decreased the fee, such as the 15% fee tier for the first $1 million earned annually which was done so that the Play Store would remain price competitive with the iOS App Store. And a developer who is not satisfied with a change to the service fee does have a right under clause 15.3 to terminate the DDA. The Amazon Appstore has a clause in similar terms to clause 3.4, and both the Samsung Galaxy Store and Microsoft Store have terms that provide general unilateral rights of variation, which would include rights to vary their service fees.
6326 Second, clause 3.8 provides that developers authorise Google to issue refunds to users and then deduct refunds paid from the payments that Google makes to developers.
6327 It has the effect that users can generally avoid engaging with individual developers for refunds, which removes a potential barrier to the customer obtaining a refund, and enhances the experience of using the Play Store. In any case, the Play Store’s billing system also provides tools for developers to manage refunds. Further, Google does not retain the service fee in the event of a refund, and it avoids refund duplication.
6328 The Epic Games Store has an equivalent term in its distribution agreement, as does Paddle, the Samsung Galaxy Store, Amazon Appstore and Microsoft Store.
6329 Further, far from acting as a barrier between the developer and customer relationship, the DDA states that users are to contact developers in relation to any defects or performance issues, and requires that developers respond to customer support inquiries within a set timeframe.
6330 Third, clause 4.1 requires developers to adhere to the developer program policies, which in turn require that an app distributed via the Play Store may not modify, replace, or update itself using any method other than the Play Store’s update mechanism.
6331 As Google says, the clause is related to its legitimate interest in ensuring the security of apps distributed by the Play Store, and ensures that updates are legitimate and do not introduce security vulnerabilities, such as malware, to a user’s mobile device.
6332 The Epic Games Store has a similar clause in its distribution agreement, which requires that app developers promptly provide app updates to the Epic Games Store, as does the Amazon Appstore.
6333 Fourth, clause 4.5 provides that developers must not use the Play Store to distribute or make available any app that has a purpose that facilitates the distribution of software applications and games for use on Android devices outside of the Play Store. It serves a legitimate commercial purpose. The Samsung Galaxy Store and Amazon Appstore have equivalent terms in their developer agreements.
6334 Fifth, clause 4.9 had relevantly provided that developers could not use user information obtained via the Play Store to sell or distribute products outside of the Play Store. But the prohibition has been removed from the DDA effective 29 August 2023. In any event, it did not prevent developers from using customer information obtained through apps to communicate with their customers. Further, Epic has not challenged Google’s proposition that it always accepted that developers may use customer information obtained via their apps to communicate with them outside of their app about matters such as alternative purchase options and promotions.
6335 Sixth, clause 8.3 provides that Google may remove, suspend, limit visibility, or reclassify any app distributed on the Play Store if it determines that the app breaches any applicable laws, violates the DDA, any applicable policies or terms of service, contravenes distribution agreements with OEMs or creates potential liability for Google or certain third-party payment processors.
6336 As Google says, this is an appropriate clause for the effective management and regulation of app content on the Play Store. There is no evidence that Google has ever exercised this right in a capricious or bad faith manner and developers are referred to an appeal process if their app is removed or suspended.
6337 The Samsung Galaxy Store and Amazon Appstore have equivalent terms in their developer agreements.
6338 Seventh, clause 10.3 provides that Google may terminate the DDA immediately or with 30 days’ written notice (if required by law) where a developer breaches the DDA or certain other agreements, where Google must do so by law, where a developer is no longer authorised or of good standing, or where a developer poses economic, reputational, or security-related risks to Google, users, or other third-party partners.
6339 It is another conventional clause aimed at dealing with non-compliant developers and there is no evidence that Google has exercised powers under this clause in a capricious or bad faith manner. To the contrary, Google’s practice is to work with developers to rectify minor breaches and may only suspend an app from being available while the developer remedies its non-compliance.
6340 Each of the Samsung Galaxy Store, Amazon Appstore, Epic Games Store and Microsoft Store have equivalent terms in their developer agreements.
6341 Eighth, clause 15.1 provides that Google may make changes to the DDA at any time on notice to a developer, and upon giving the developer an opportunity to decline further use of the Play Store. Where a developer does not agree to any variations, it has the right under clause 15.3 to terminate the DDA.
6342 This is yet another conventional clause. Google must have the ability to deal with changing circumstances without needing to individually renegotiate its terms with over a million developers. There is no evidence that Google has ever exercised this right in a capricious or bad faith manner. Moreover, many changes to the DDA and developer program policies are driven by developer feedback.
6343 So, I agree with Google that the impugned provisions of the DDA do not, either individually or cumulatively, amount to unconscionable conduct. I accept that in large part they are sensible commercial terms given the nature and size of the Play Store’s business, and serve the legitimate interests of Google in operating the platform.
6344 And as Google has pointed out, such a conclusion is well demonstrated by the circumstance that other app stores, including the Epic Games Store, have equivalent terms.
6345 So, Epic has not made out its unconscionable conduct claims. And given that there is no primary contravention or liability it also follows that the accessorial claims are not made out.
The relief that Epic seeks
6346 The relief Epic seeks is directed at opening up Android app distribution and payment services to competition from third parties.
6347 The relief Epic seeks in relation to the Android mobile app distribution market principally includes the following remedies.
6348 Declarations are sought to the effect that Google has engaged in anticompetitive conduct in contravention of the CCA. Further, the following types of orders are sought.
6349 First, orders are sought restraining Google from engaging in that anticompetitive conduct.
6350 Second, orders are sought declaring void or excising from Epic’s contracts with Google some or all of the terms underpinning the OEM restrictive conduct and the app developer restrictive conduct.
6351 Third, orders are sought restraining Google from making it a condition of distributing Android apps through the Play Store that, among other things, those apps cannot be app stores.
6352 Fourth, orders are sought requiring Google to permit app developers to submit and distribute app stores through the Play Store.
6353 Fifth, orders are sought varying Epic’s contracts with Google by inserting a provision which permits developers to submit and display on the Play Store an app store.
6354 The relief Epic seeks in respect of the Android in-app payment solutions market principally includes the following remedies.
6355 First, various declarations and orders are sought relevantly declaring the payments tie and the anti-steering rule to be unlawful and restraining Google from giving effect to them.
6356 Second, orders are sought requiring Google to reinstate Fortnite to the Play Store with EDP.
6357 Third, orders are sought declaring void or excising from Epic’s contracts the payments tie and anti-steering rule.
6358 Fourth, orders are sought restraining Google from making compliance with the payments tie a condition of distributing Android apps through the Play Store.
6359 Now at this stage it is not productive to say anything further on relief. Clearly I will need to hear further from counsel as to the relief sought.
6360 The sensible course at this stage is simply to stand over questions of relief until another date. The parties will need to fine tune their submissions on relief and tailor them to the contraventions that I have now found.
Conclusion
6361 In summary, I have made the following key findings.
6362 First, I have found in favour of Epic concerning its three posited markets being, first, the mobile OS licensing market, second, the Android mobile app distribution market and, third, the Android in app payment solutions market.
6363 And relevant to the question of substitution concerning the second posited market, in my view other Android app stores do provide a competitive constraint on the Play Store such as to be a substitute. Further, there is some substitutability between sideloading of apps and Android app distribution services, but it is not a close constraint, and users and developers do not consider it to be a close substitute. Further, the pre-installation of apps is not a close substitute for Android app distribution services. Further, there is some competition with PC and console operators and mobile app stores, but there is not close substitution. Further, out of app payments say little about the question of substitution for distribution services and in any event would not constrain the hypothetical monopolist of Android app distribution services.
6364 Now I should note that the fact that I have found that various other products and services are not close constraints and therefore are not part of the relevant product dimension of market definition does not entail that the availability of such products and services do not provide some form of competitive constraint. In my view they do provide a competitive constraint to some extent although not such as to deny the market definition that I have found or Google’s substantial market power in such a market.
6365 Second, I have found in favour of Epic to the effect that at all relevant times Google has and had a substantial degree of power in each market.
6366 Third, I have found that contrary to s 46 of the CCA, Google engaged in conduct in the latter two of the three posited markets that has had or is likely to have the effect of substantially lessening competition in such markets being conduct that prevents or prohibits developers and users from using alternative payment methods to Google Play Billing for purchasing digital in app content.
6367 In terms of the Google Play Billing restrictions being the payments tie provision and the anti-steering provision, I have found that they were imposed or have been maintained at the start of the relevant period with the effect or likely effect of substantially lessening competition in the payment solutions market.
6368 Fourth, I am satisfied that Google engaged in conduct concerning Project Hug, the GVP agreements, the AVP agreements and the RSA3s that had the purpose of substantially lessening competition in the Android mobile app distribution market and so contravened s 46. Further, in relation to the conduct constituted by Project Hug and the GVP agreements, I am satisfied that such conduct had a likely effect of substantially lessening competition in that market; I am using “likely” here in terms of a real chance.
6369 In all other respects I have not accepted Epic’s case against Google concerning the other alleged contraventions of Part IV of the CCA or its unconscionable conduct case. And to be clear, I have not accepted Epic’s case concerning the technical restrictions or its case concerning clause 4.5 of the DDA.
6370 I will hear further from counsel concerning the further steps to be taken in this matter.
I certify that the preceding six thousand, three hundred and seventy (6370) numbered paragraphs are a true copy of the Reasons for Judgment of the Honourable Justice Beach. |
Associate:
Dated: 12 August 2025
Schedule of some abbreviations and acronyms
(provided pursuant to my orders of 13 December 2023 but modified by me)
Term | Definition |
3P | Third party. |
AAB | Android App Bundle, being the publishing format, which includes an app’s compiled code and resources, for apps submitted to the Play Store/Google Play. |
ACC | Android Compatibility Commitment, being a form of agreement between Google and an OEM that details the baseline hardware and software requirements that an OEM or ODM must comply with when manufacturing Android Compatible Devices. |
ACCC | Australian Competition and Consumer Commission. |
ACL | Australian Consumer Law. |
ACM | Authority for Consumers and Markets (Netherlands). |
AFA | Anti-Fragmentation Agreement, being the precursor to the ACC (Android Compatibility Commitment), which details the baseline hardware and software requirements that an OEM or ODM must comply with when manufacturing Android Compatible devices. |
AFSL | Australian Financial Services Licence. |
Amazon Appstore | App store operated by Amazon for Android, BlackBerry and Windows-based devices. |
AMP | Apple Media Products. |
Android apps | Native apps written for Android OS. |
Android Compatible Device | A mobile device that complies with the CDD (Android Compatibility Definition Document) and passes the CTS (Android Compatibility Test Suite). |
Android Device | An Android Compatible Device with GMS preinstalled. They are also referred to as GMS Devices. |
Android fork devices | Mobile devices that use AOSP in some way but are not CTS-compliant. |
Android Market | The former name of the Play Store/Google Play. |
Android OS | The Android Operating System. |
Android Smart Mobile Devices | Smart Mobile Devices which run on the Android OS (Android Operating System) whether or not they comply with the CDD. |
AOSP | Android Open-Source Project. Google makes the Android OS available to OEMs for free under an open-source license through the AOSP. |
Apple Class Applicants | The applicants in the David Anthony & Anor v Apple Inc & Anor (VID341/2022) proceedings. |
API | Application programming interface, being a set of definitions and protocols which allows app developers to program their apps to access and make use of Mobile OS-provided functionality. APIs allow programs to interact with the OS, the hardware of the device, or with other applications running on the device. |
APK | Android Package Kit files, being standard app files on Android. Once downloaded, an APK file can be installed and run directly by the Android OS. |
App | A software application. Apps may be Native apps (including Android apps and iOS apps) or Web apps. Each of those expressions is described in this glossary. |
Apple | Apple Inc (First Respondent in NSD1236/2020). |
Apple Australia | Apple Pty Limited (Second Respondent in NSD1236/2020). |
Apple Respondents | Apple and Apple Australia (collectively). |
App Review | Process of automated and human review of all apps submitted for distribution to Apple devices through their respective App Store. |
App store | A type of app that allows users to identify and download other apps. |
App Store | Apple’s proprietary iOS app which is pre-installed on iOS Devices and is used to distribute native iOS apps. |
App Store Review Guidelines | Guidelines with which all apps distributed on the App Store are required to comply. |
ARPU | Average Revenue per User. |
ARPDAU | Average Revenue per Daily Active User, a term used to describe the total revenue generated from an app divided by the number of Daily Active Users. |
ARPPAU | Average Revenue per Paying User, a term used to describe the total revenue generated from an app divided by the number of paying users. |
ASIC | Australian Securities and Investments Commission. |
AVP | Apps Velocity Program (also known as the Apps Accelerator Program), being the name for the extension of the Games Velocity Program to a limited number of non-gaming app developers. |
AVP Agreement | Apps Velocity Program Agreement, being a form of agreement between Google and certain non-gaming app developers as part of the Apps Velocity Program by which Google agreed to provide a range of services in exchange for the app developers agreeing to certain obligations including the exclusive use of GPB as the sole payment solution in relation to their Android apps, and other obligations in respect of the content and promotion of those apps. |
CAT | Competition Appeal Tribunal (UK). |
Carrier | A mobile service provider that supplies cellular connectivity services to mobile phone and tablet subscribers. Prominent examples of Australian Carriers include Optus, Telstra and Vodafone. |
CCA | Competition and Consumer Act 2010 (Cth). |
CCI | Competition Commission of India. |
CDD | Android Compatibility Definition Document, being a document published by Google that details minimum device compatibility requirements for Android Smart Mobile Devices. |
Cloud gaming | Type of gaming that runs video games on remote servers and streams them by means of the internet directly to a user's device. It contrasts with traditional means of computer gaming, where a local copy of the game runs on a user's video game console, personal computer, or mobile device. |
Cloud based game streaming platforms | Platforms accessible through software with internet or network access (including, for example, a web browser such as Safari or a MacOS application or an app on a device) which allow consumers to play games directly on the platform rather than downloading a local copy of the game to a particular device. Examples include Google Stadia, Nvidia GeForce Now, PlayStation Now, Microsoft Xbox Cloud Gaming, and Amazon's Luna. |
CMA | Competition and Markets Authority (UK). |
COS or COGS | Cost of sales, or Cost of goods sold. |
CPI | Cost per Install, a term used to describe the total advertising spend divided by the number of installations of an app directly tied to the advertising campaign. |
CRPI | Customer Revenue per Install or Cumulative Revenue per Install, a term used to describe the average amount of revenue generated per installation of an app. |
CPU | Central processing unit. |
Cross-platform play | Describes the ability of a player to access a single player account on a number of platforms thereby allowing the player to play the same game across different video game hardware and to play with players who are using different platforms simultaneously. |
Cross-progression | Game progress synchronised across platforms. |
Cross-wallet functionality | Allows for purchases made on one platform to be used on another. |
CTS | Android Compatibility Test Suite, being an automated testing program to test devices for compliance with the Android Compatibility Definition Document. |
DAU | Daily Active User, a term used to describe the total number of people who open an app on a given day. |
DDA | Developer Distribution Agreement, being a form of agreement between Google LLC and an app developer that wishes to distribute an Android app through Google Play. The DDA contains terms and conditions that apply to the distribution of Android apps through the Play Store/Google Play. |
Direct download | A term used to describe the process of downloading and installing an app onto a device from the internet. Sometimes described as sideloading. |
DMA | Digital Markets Act (Regulation (EU) 2022/1925). |
DOB | Developer Only Billing, whereby app developers are permitted to offer an alternative in-app payment solution within their Android apps to the exclusion of GPB. Developer Only Billing is currently only available for non-gaming apps distributed in the European Economic Area. |
DPLA | Developer Program License Agreement, being a form of agreement between Apple and an app developer who wishes to develop an iOS app and distribute it to iOS Device users through the App Store. The DPLA is a licence to Apple's technology and tools which prescribes the terms and conditions that apply to the use of the same, including distribution of iOS Apps through the App Store. |
DRM | Digital rights management, being the management of access to digital content to avoid piracy and protect copyrighted works. |
EBIT | Earnings before interest and tax; a further related measure is earnings before interest, tax, depreciation and amortization (EBITDA). |
EC | European Commission. |
ECPR | Efficient Component Pricing Rule. |
EDP | Epic Direct Payment, being Epic's in-app payment solution for accepting and facilitating purchases of paid apps and in-app payments. |
EEA | European Economic Area. |
EGS | Epic Games Store, an app store which is currently available on PCs. |
EMADA | The version of the MADA which applies in the European Economic Area. |
EOS | Epic Online Services, being a modular set of online services which Epic makes available for free to other developers to use in multiplayer games. EOS offers a variety of social features to game users, including the ability to make connections with other users and track their gameplay and performance. |
Epic | Epic Games, Inc., Epic Games International S.à r.l. and Epic Games Entertainment International GmbH. |
Epic Android Apps | Android apps developed by Epic, including Fortnite, the Epic Games App, the Fortnite Installer and the Fortnite Launcher. |
Epic Entertainment | Epic Games Entertainment International GmbH (Third Applicant). |
Epic Games | Epic Games, Inc. (First Applicant). |
Epic Games App | An app that is available for download on Android Smart Mobile Devices from Epic's website or from the Samsung Galaxy Store through which a limited number of Epic Android Apps, including Fortnite, can be downloaded and launched by Android Smart Mobile Device users. |
Epic Games Store | App store operated by Epic for PCs. |
Epic International | Epic Games International S.à r.l. (Second Applicant). |
EU | European Union. |
EULA | End User Licence Agreement. |
Form 10-K | Annual filing required by the Securities and Exchange Commission (US) for certain companies. |
Fortnite | An Epic games app. |
Fortnite Installer | An app that facilitated the installation and subsequent updating of Fortnite. Later became known as the Epic Games App. |
Free model | A monetisation model chosen by developers by which users do not pay to download or use the app. |
Freemium model | A monetisation model chosen by developers by which users pay nothing to download the app and are offered optional in-app purchase for premium features, additional content, subscriptions or digital goods. Fortnite is an example of a Freemium app. |
FY | Financial year or fiscal year. |
Galaxy Store | Samsung Galaxy Store, an app store which is available on phones manufactured by Samsung. |
Game streaming | See cloud gaming. |
GDAF | Google Distribution on Android Framework. Pursuant to the GDAF, Google developed a three-tiered framework for its RSAs. |
GMS | Google Mobile Services, being a suite of software owned by Google LLC which includes Google Play, Google Search, Google Chrome, Google Maps, Gmail, YouTube and certain SDKs and APIs. |
GMV | Gross merchandise value, being the total monetary value of merchandise sold through a distributor over a set period. |
Google LLC, Google Asia Pacific and Google Australia. | |
Google Asia Pacific | Google Asia Pacific Pte. Ltd. (Second Respondent in NSD190/2021). |
Google Australia | Google Payment Australia Pty. Ltd. (Third Respondent in NSD190/2021). |
Google Class Applicants | The applicants in the Brett McDonald & Anor v Google LLC & Ors (VID342/2022) proceedings. |
Google Play | Google’s app store, which is also referred to as the Play Store (my preferred description). Occasionally I have used “Google Play” to refer to one of Google’s business divisions in the accounting context. |
GPB | Google Play Billing, a billing system integrated into the Play Store/Google Play which accepts and facilitates payments for purchases of paid apps and in-app purchases of digital content (including by way of subscriptions) within Android Apps downloaded via the Play Store/Google Play. |
GPP | Google Play Protect. |
GPU | Graphics Processing Unit. |
GSA | Google Search application. |
GTS | GMS Test Suite, being the tests run on Android mobile devices for compliance with a range of GMS requirements. |
GVP | Games Velocity Program, known internally as Project Hug, which applied to a select number of gaming app developers. |
GVP Agreement | Games Velocity Program Agreement, being a form of agreement between Google and certain games app developers by which Google agreed to provide a range of services in exchange for the games app developers agreeing to Sim-ship requirements and other obligations, including in respect of the content, quality and promotion of their Android apps. |
HMT | Hypothetical Monopolist Test. |
HTML | HyperText Markup Language. |
HVU | High Value User, a term used within Google meaning a user who spends $250 or more on apps downloaded on the Play Store/Google Play per month. |
IAP | Apple's in-app purchase system. |
IDE | Integrated Development Environment, being a software application to assist programmers to develop software code. |
In-app purchases | Purchases of digital content (including by way of subscriptions) within apps. |
Install unknown apps permission | In the Android OS, the “REQUEST_INSTALL_PACKAGES” permission, which controls the ability for an app to act as an install source for direct downloading. |
iOS | Apple's Mobile OS for the iPhone and iPadOS. |
iOS apps | Native apps written for iOS. |
iPad apps | Native apps written for iPadOS. |
iPad Devices | Apple iPad devices. |
iPadOS | Apple's Mobile OS for the iPad. |
ISA | Information Services Agreement, being an agreement between Google and Apple which contains the terms under which Apple agreed to make certain Google services, including Google Search, available on Apple Smart Mobile Devices. |
Jailbreaking | Modifying the operating system or file system of an electronic device to enable the installation and operation of unauthorised software, including the use of private or otherwise restricted APIs or the removal of software restrictions. |
Kernel | Essential core program of an operating system which controls hardware and processes of the computer. |
LTR | Long term revenue |
LTV | Lifetime values of Android Devices |
Macs | Personal computers running macOS. |
macOS | Apple's OS for Macs. |
MADA | Mobile Application Distribution Agreement, being a form of agreement between Google and an OEM by which Google grants the OEM a non-exclusive licence to distribute devices with Google Mobile Services and to use the Android and Google trademark, subject to certain conditions. |
MAU | Monthly Active User, a term used to describe the total number of people who open an app at least once in a given month. |
Microsoft | Microsoft Corporation Inc., the developer of various apps (including games apps) and the manufacturer of Xbox games consoles. |
Microsoft Store for Xbox | App store operated by Microsoft for the Xbox game console. |
MIA | Mobile Incentive Agreement, being a form of agreement between Google and an OEM which enables the OEM to share certain revenues derived from the OEM's devices if those devices comply with certain requirements. |
MG | Minimum guarantee, referring to the commercial arrangement by which Epic would pay select third-party developers a guaranteed minimum amount, independent of revenue generated from a game, in exchange for exclusive distribution rights for a fixed period. |
Mobile OS | Operating system for smartphones and tablets. |
MUwS | Mobile unwanted software. |
Nintendo | Nintendo Co., Ltd, a games developer and manufacturer of the Nintendo Switch games console. |
Nintendo eShop | App store operated by Nintendo for game apps on the Nintendo Switch game console. |
OCOGS | Other cost of goods sold. |
ODM | Original design manufacturer, which contracts with OEMs to produce devices sold under the OEM brand. |
OEM | Original equipment manufacturer, which produces mobile devices and tablets sold under their own branding (e.g. Samsung). |
OPEX | Operating expenses. |
OS | Operating system. |
Paid model | A monetisation model chosen by developers by which users pay once initially to download the app and use all of its functionality, with no additional charges subsequent to initial download. |
Paymium model | A monetisation model chosen by developers by which users pay initially to download the app and have the option to buy additional features, content, or services through in-app purchases subsequent to initial download. |
PC | Personal computer. |
PCI-DSS | Payment Card Industry Data Security Standard. |
PHA | Potentially Harmful App. |
PlayStation Store | App store operated by Sony for PlayStation game consoles. |
Play Store | This is Google’s app store, which is sometimes referred to as Google Play. |
Premier Device | A device configured by an OEM in accordance with the relevant terms and conditions of the Premier Device RSAs. |
Premier Device Program Requirements | The document setting out the requirements pertaining to all Premier Devices released under an RSA. |
Premier Device RSA | Premier Device Revenue Sharing Agreement, being an agreement entered into by Google and an OEM which entitles that OEM to increased revenue share on certain terms and conditions including that the device complies with Premier Device Program Requirements. |
Privileged install permission | In the Android OS, the “INSTALL_PACKAGES” permission, which controls whether an app can install other apps. |
Project Banyan | A Google strategy and project concerning its dealings with Samsung that was never consummated. |
Project Hug | A Google strategy and project concerning developers, originally known as Project Bear Hug, and ultimately known as the Games Velocity Program. Its consummation produced GVP agreements. |
Project Liberty | The term used internally by Epic to describe its strategy to challenge Apple’s and Google’s policies in relation to the distribution of apps through their respective app stores. |
PWA | Progressive Web App, an app which looks and functions similar to a native app but which operates on, and is accessed from, a website. |
PvE | Player vs environment: a game where a player plays against a computer-controlled environment or characters. |
PvP | Player vs player: a game between human players. |
P&L | Profit and Loss statement. |
RAM | Random Access Memory. |
Relevant Period | 6 November 2017 to 20 June 2022. |
ROA | Return on assets. |
ROCE | Return on capital employed. |
ROGP | Return on gross profit. |
ROS | Return on sales. |
RSA | Revenue Sharing Agreement, being a form of agreement between Google and an OEM which enables the OEM to share certain revenues derived from the OEM's devices if those devices comply with certain requirements. |
RSA3 | The third iteration of the RSA. Some RSA3s contain a “Premier Tier” of revenue sharing, allowing OEMs to earn an increased revenue share for Premier Devices. These RSAs are known as Premier Device RSAs. |
Samsung | Samsung Electronics Co. Ltd and affiliated companies. It is an OEM and inter-alia a manufacturer of Samsung smartphones and tablet devices. It is the operator of the Samsung Galaxy Store. It uses, inter-alia, a version of the Android OS. |
Samsung Galaxy Store | App store operated by Samsung for Samsung smartphone and tablet devices. |
Samsung IAP | Samsung's in-app purchasing platform. |
Sandboxing | The process of isolating apps from critical system resources on a device as well as from other apps. This prevents an app from making changes to the device and from accessing files stored by other apps unless, where permissible, authorised to do so by the user. |
Service Fee | The fee charged by Google on paid app downloads and in-app purchases made on apps distributed on the Play Store/Google Play. |
SDK | Software development kit. SDKs generally include information concerning APIs that app developers use to create apps for a particular OS. |
SEC | Securities and Exchange Commission (US). |
Sideloading | In the case of mobile devices, commonly used to describe the installation of a native app from a source other than the app store provided by the mobile device’s manufacturer and/or operating system provider. |
Sim-ship | Simultaneous launch / title release parity: the concept that when a game (or other app) is released, it is to be released on the same date for all types of device to which any Sim ship obligation applies. |
SKU | Stock keeping unit. |
Small Business Program | Program made available by Apple since January 2021, under which a 15% commission is payable by developers with annual revenue less than USD 1 million. |
Smart Mobile Devices | Smartphones and tablets. |
Sony | Sony Corporation, a games developer and the manufacturer of PlayStation games consoles. Sony is also a shareholder of Epic. |
SSNIP | Small but significant non-transitory increase in price. |
Steam | App store and cloud game streaming service for PCs, Macs, iOS and Android devices. |
Subscription model | A monetisation model chosen by developers by which users can buy for renewing or non-renewing durations access to content, services, and experiences. Popular subscription apps include Netflix, Disney+, Microsoft Xbox Games Pass. |
Team ID ‘84 Account | Epic Games, Inc.’s Apple Developer Program account. |
Tencent | Tencent Holdings Ltd, a games developer and a company which has a subsidiary which is a shareholder of Epic. |
TestFlight | Software provided by Apple that allows developers to conduct beta testing of their apps prior to launch. |
TMADA | The version of the MADA which applies in Turkey. |
TTM | “Trailing 12 months”, meaning the past 12 consecutive months used for reporting financial figures. |
UA | User acquisition. |
UI | User interface. |
UCB | User Choice Billing, whereby app developers are permitted to offer an alternative in-app payment solution within their Android apps in addition to GPB. |
Unknown source | Sources of apps which are not granted privileged install permissions by an OEM on an Android device. |
Unreal Engine | Software suite, including a graphics engine, that allows app developers to create realistic three-dimensional and immersive digital content for various industries. |
UX | User experience. |
Valve | Valve Corporation, a game developer and the operator of an online PC app distribution service called Steam. |
V-Bucks | Virtual currency used to redeem digital content for use in Fortnite. |
WACC | Weighted average cost of capital. |
Xcode | IDE provided by Apple to help developers build, debug and test their apps. |
Dramatis personae – witnesses and other individuals
(provided pursuant to my orders of 13 December 2023)
Some roles at the time of trial are shown in italics.
A. EPIC GAMES
Surname | Given Names | Position/s within Epic Games |
Allison | Steven Matthew | Vice-President and General Manager, Epic Games Store (2018 – trial) |
Grant | Andrew James | Senior Director, Engineering (2022 – trial) Engineering Fellow (2021 – 2022) Technical Director, Engineering (2019 – 2021) Lead Programmer (2015 – 2019) |
Hutcheson | Marc | Marketing Director (2017 – 2020) |
Rein | Mark | Vice-President Business Development and Co-founder (1991 – trial) |
Sargent | Justin | Senior Director, Engineering (2022 – trial) Director, Store Engineering (2021 – 2022) Director, Engineering (2019 – 2021) Technical Lead (2016 – 2019) Senior Software Engineer (2012 – 2016) |
Seavers | Michael Paul | Vice-President of Development (2021 – 2023) |
Shin | Kwangsub | Business Development Director, Enterprise (2023 – trial) Senior Business Development Lead, Enterprise (2022 – 2023) Engine Business Lead (2021 – 2022) Developer Relations Lead (2019 – 2021) |
Stolfus | Hans Josef | Brand Success Director (2023 – trial) Strategic Partnerships Director (2021 – 2023) Partnerships Lead, Mobile (2020 – 2021) Senior Marketing Manager for Mobile (2019 – 2020) |
Surname | Given Names | Position/s within Epic Games |
Sweeney | Timothy Dean | Chief Executive Officer (1991 – trial) Chairman of the Board of Directors Controlling shareholder |
Weissinger | Matthew Reid | Vice-President of Marketing (2021 – 2023) Head of Marketing (2019 – 2021) Director of Marketing (2016 – 2019) |
Zobrist | Ed | Retired Head of Publishing (2016 – 2021) |
B. APPLE
Surname | Given Names | Position within Apple |
Casey | Saori Takahashi | Former Vice-President, Corporate Financial Planning |
Federighi | Craig Michael | Senior Vice-President, Software Engineering |
Harlow | Jacqueline Tatjana | Principal Counsel and Senior Manager, IP Transactions |
Schiller | Philip | Apple Fellow |
Wong | Stella | Business Lead, App Store, Australia and New Zealand |
C. GOOGLE
Surname | Given Names | Position/s within Google |
Andreatta | Robert Ernest | Vice President, Finance, Google LLC (2016 – trial) |
Byers | Richard | Principal Software Developer, Chrome, Google LLC (2022 – trial) Engineering Director, Chrome (2019 – 2022) Software Developer, Chrome (2010 – 2019) |
Cramer | Christian | Finance Director, Google Play, Google LLC (2020 – trial) Finance Director, Platforms and Ecosystems (2017 – 2020) Finance Director, Corporate Finance (2016 – 2017) Finance Director, Google Cloud (2016) Finance Director, Enterprise, Search and GEO (2014 – 2016) Sales Finance Manager, then Sales Finance Director (2008 – 2014) Finance Manager (2007 – 2008) |
Cunningham | Edward John | Director, Product Management, Google UK Limited (2023 – trial) Product Manager, Android (2015 – 2023) Associate Product Manager (2013 – 2015) |
Feng | Paul | Vice President of Product Management, Google LLC (2022 – trial) Product Management Director, Play Store/Google Play (2016 – 2022) Product Manager, Google Ads (2011 – 2016) Product Manager, Mobile Advertising (2008 –2011) |
Gennai | Paul Nicholas | Product Management Vice President, Google LLC (2022 – trial) Product Management Director, Office of the CEO (2020 – 2022) Various product management, strategy and analytics roles in Android and Play Store/Google Play teams (including Product Manager, Group Product Manager, Senior Product Manager and Product Management Director) (2010 – 2020) Business Operations and Strategy Associate (2008 – 2010) |
Surname | Given Names | Position/s within Google |
Kochikar | Purnima Pai | Vice President of Play Partnerships, Google LLC (2020 – trial) Director of Play Store/Google Play Apps and Games (2012 – 2020) |
Porst | Sebastian Johannes | Security Engineering Manager, Android Application Security Research, Google Germany GmbH (2017 – trial) Senior Software Engineer, then Software Engineering Manager, Android Security team (2013 – 2017) Malware Researcher and Software Engineer, Android Security team (2011 – 2013) |
Rawles | Lee Warner | Managing Director, Global Games, Play Partnerships, Google LLC (2022 – trial) |
D. OTHER
Surname | Given Names | Relevant position/s |
Dubey | Sharmistha | Board Director and Advisor, Match Group (2022 – trial) CEO, Match Group (2020 – 2022) President, Match Group (2018 – 2020) |
Ek | Daniel | CEO, Spotify (2006 – trial) |
Gass | Eric | Global Strategic Partnerships Lead, OPPO + OnePlus (2020 – trial) Global Partnerships Lead, OnePlus (2019 – 2020) Senior Product Partnerships Manager, OnePlus (2018 – 2019) Assistant to CEO, OnePlus (2018 – 2019) |
Hassey | Erin | Senior Director, User Acquisition, Calm (2019 – trial) Director, User Acquisition, Calm (2018 – 2019) |
Hastings | Reed | CEO, Netflix (1998 – 2023) |
Koh | Dong-Jin | CEO, Samsung (2015 – 2020) |
Surname | Given Names | Relevant position/s |
Nadella | Satya | CEO, Microsoft (2014 – trial) Executive Chairman, Microsoft (2021 – trial) |
Owens | Christian | Executive Chairman, Paddle (2023 – trial) CEO, Paddle (2012 – 2023) |
Ringrose | Ashley | CEO, SMG Studio (2018 – trial) Co-Founder, SMG Studios (2013 – 2018) Co-Founder, Soap Creative (2002 – 2013) |
Steingrimsson | Daniel | Business Development, Global Business Alliances, Sony Electronics (2019 – trial) Business Development, Strategic Partnerships, Sony Mobile Communications (2017 – 2019) |
Zerza | Armin | Chief Financial Officer, Activision Blizzard King (2021 – trial) Chief Commercial Officer, Activision Blizzard (2019 –2021) |
E. INDEPENDENT EXPERT WITNESSES
Surname | Given Names | Relevant position/s | Role in Proceedings |
Asker | John | Armen A. Alchian Chair in Economic Theory and Professor of Economics, University of California, Los Angeles | Economist – called by Google |
Blockley | Lance Sinclair | Managing Director, The Initiatives Group | Payments Expert – called by Epic |
Burg | Pascal | Director, Edgar, Dunn & Company | Payments Expert – called by Google |
Davila | Antonio | Professor of Accounting and Control, Faculty of Business and Economics and the University of Lausanne | Accountant – called by Epic |
Surname | Given Names | Relevant position/s | Role in Proceedings |
Dhar | Ravi | George Rogers Clark Professor of Management and Marketing, Yale School of Management Director, Yale Center for Customer Insights, School of Management, Yale University Professor of Psychology, Department of Psychology, Yale University | Survey Expert – called by Epic |
Easton | Peter Douglas | Notre Dame Alumni Professor of Accountancy and Director, Center for Accounting Research and Education, Mendoza College of Business, University of Notre Dame | Accountant – called by Google |
Edwards-Warren | Kirsten | Co-Head (Europe, the Middle East and Africa), Compass Lexecon | Economist – called by Epic |
Gneezy | Uri | Epstein/Atkinson Chair in Management Leadership and Professor of Economics and Strategy, Rady School of Management, University of California San Diego | Behavioural Economist – called by Google |
Goldfarb | Avi | Rotman Chair in Artificial Intelligence and Heathcare, Rotman School of Management, University of Toronto Chief Data Scientist, Creative Destruction Lab, Vector Institution and Swartz-Reisman Institute for Technology and Society Research Associate, National Bureau of Economic Research | Economist – called by Epic |
Hitt | Lorin | Zhang Jindong Professor of Operations, Information and Decisions, Wharton School of the University of Pennsylvania | Economist – called by Apple |
Surname | Given Names | Relevant position/s | Role in Proceedings |
Holt | Derek | Managing Director, AlixPartners UK LLP | Economist – called by Class Applicants |
Houston | Greg | Founding Partner, HoustonKemp Economists | Economist – called by Apple |
Keller | Kevin | E. B. Osborn Professor of Marketing, Tuck School of Business, Dartmouth College | Survey Expert – called by Google |
Luca | Michael | Lee J. Styslinger III Associate Professor of Business Administration, Harvard Business School at the time of trial, but now a Professor at John Hopkins University | Behavioural Economist – called by Epic |
Majumdar | Adrian | Managing Partner, RBB Economics | Economist – called by Apple |
Rubin | Aviel D. | Founder & Chief Scientist, Harbor Labs. Previously a Professor of Computer Science at John Hopkins University, but still holding the emeritus title | Technology and Security Expert – called by Apple |
Samuel | Tony | Managing Director, Sapere Research Group Limited Head of Sapere Forensic | Accountant – called by Apple |
Somayaji | Anil | Associate Professor, School of Computer Science, Carleton University | Technology and Security Expert – called by Epic |
Traynor | Patrick Gerard | Associate Chair for Research, John and Mary Lou Dasburgh Preeminent Chair in Engineering, Department of Computer and Information Sciences and Engineering (CISE), University of Florida | Technology and Security Expert – called by Google |
Wright | Julian | Lim Chong Yah Professor, Department of Economics, National University of Singapore | Economist – called by Epic |
The Parties’ Aides Memoire – Play Store
Google’s aide memoire
Epic’s aide memoire