Google I/O にご参加いただきありがとうございました。オンデマンドでコンテンツを視聴できます。

このページは Cloud Translation API によって翻訳されました。

インストール戦略を定義する方法

Demián Renzulli

Pete LePage

公開日: 2020 年 5 月 12 日

以前は、アプリのインストールはプラットフォーム固有のアプリケーションのコンテキストでのみ可能でした。現在、最新のウェブアプリは、プラットフォーム固有のアプリと同レベルの統合と信頼性を提供するインストール可能なエクスペリエンスを提供しています。

これにはさまざまな方法があります。

ブラウザから PWA をインストールする。
アプリストアから PWA をインストールする。

さまざまな配信チャネルを用意することは、幅広いユーザーにリーチするうえで非常に効果的です。ただし、PWA のインストールを促進するための適切な戦略を選択するのは難しい場合があります。

このガイドでは、インストール率を高め、プラットフォーム間の競合やカニバリゼーションを回避するために、さまざまなインストールオプションを組み合わせるためのベストプラクティスについて説明します。対象となるインストールオファリングには、ブラウザと App Store の両方からインストールされた PWA と、プラットフォーム固有のアプリが含まれます。

ウェブアプリをインストール可能にする理由

インストールされたプログレッシブウェブアプリは、ブラウザタブではなくスタンドアロンウィンドウで実行されます。ユーザーのホーム画面、ドック、タスクバー、シェルフから起動できます。デバイスで検索したり、アプリスイッチャーで切り替えたりできるため、インストール先のデバイスの一部のように感じられます。

しかし、インストール可能なウェブアプリとプラットフォーム固有のアプリの両方があると、ユーザーが混乱する可能性があります。一部のユーザーにとってはプラットフォーム固有のアプリが最適な選択肢となる可能性がありますが、次のようなデメリットもあります。

ストレージの制約: 新しいアプリをインストールするには、他のアプリを削除するか、貴重なコンテンツを削除して空き容量を増やす必要がある場合があります。これは、特にローエンドデバイスのユーザーにとって不利です。
利用可能な帯域幅: アプリのダウンロードは、低速の接続や高額なデータプランを利用しているユーザーにとっては、コストがかかり、時間がかかるプロセスになる可能性があります。
摩擦: ウェブサイトを離れてストアに移動し、アプリをダウンロードすると、摩擦が増し、ウェブで直接実行できるユーザーアクションが遅延します。
更新サイクル: プラットフォーム固有のアプリに変更を加えるには、アプリの審査プロセスを経る必要があるため、変更やテスト（A/B テストなど）の速度が遅くなる可能性があります。

プラットフォーム固有のアプリをダウンロードしないユーザーの割合が大きい場合もあります。たとえば、アプリをあまり使用しないと考えるユーザーや、数メガバイトのストレージやデータを費やすことを正当化できないユーザーなどです。このセグメントのサイズは、たとえば、アナリティクス設定を使用して「モバイルウェブのみ」のユーザーの割合をトラッキングするなど、いくつかの方法で判断できます。

このセグメントのサイズが大きい場合は、エクスペリエンスをインストールする代替手段を提供する必要があることを示しています。

ブラウザで PWA のインストールを促進する

高品質の PWA がある場合は、プラットフォーム固有のアプリよりも PWA のインストールを促進する方がよいかもしれません。たとえば、プラットフォーム固有のアプリに PWA が提供する機能が欠けている場合や、しばらく更新されていない場合などです。また、ChromeOS などで、プラットフォーム固有のアプリが大きな画面向けに最適化されていない場合は、PWA のインストールを促進することも有効です。

一部のアプリでは、プラットフォーム固有のアプリのインストールを促進することがビジネスモデルの重要な部分を占めています。そのような場合は、プラットフォーム固有のアプリのインストールを促進することがビジネス上理にかなっています。しかし、一部のユーザーはウェブの利用を好む可能性があります。そのセグメントを特定できる場合は、そのユーザーにのみ PWA プロンプトを表示できます。これを「フォールバックとしての PWA」と呼びます。

インストール可能なメインのエクスペリエンスとしての PWA

PWA がインストール可能の条件を満たすと、ほとんどのブラウザで PWA がインストール可能であることを示すインジケーターが表示されます。たとえば、パソコン版 Chrome ではアドレスバーにインストール可能なアイコンが表示され、モバイル版ではミニ情報バーが表示されます。

をご覧ください。

この方法で十分な場合もありますが、PWA のインストールを促進することが目標の場合は、BeforeInstallPromptEvent をリッスンし、PWA のインストールを促進するパターンに従うことを強くおすすめします。

PWA がプラットフォーム固有のアプリのインストール率をカニバリゼーションしないようにする

場合によっては、PWA よりもプラットフォーム固有のアプリのインストールを促進することを選択できます。ただし、ユーザーが PWA をインストールできるようにするメカニズムを提供することをおすすめします。このフォールバックオプションを使用すると、プラットフォーム固有のアプリをインストールできない（またはインストールしたくない）ユーザーも、同様のインストール済みエクスペリエンスを利用できます。

この戦略を実装する最初のステップは、PWA のインストールプロモーションをユーザーに表示するタイミングのヒューリスティックを定義することです。

たとえば、PWA ユーザーは、プラットフォーム固有のアプリのインストールプロンプトを表示したものの、インストールしていないユーザーである可能性があります。ユーザーはサイトに 5 回以上アクセスし、アプリバナーをクリックしたにもかかわらず、ウェブサイトを使い続けた可能性があります。

このヒューリスティックは次のように実装できます。

プラットフォーム固有のアプリインストールバナーを表示します。
ユーザーがバナーを閉じた場合は、その情報（document.cookie = "app-install-banner=dismissed" など）を含む Cookie を設定します。
別の Cookie を使用して、サイトへのユーザーのアクセス数をトラッキングします（document.cookie = "user-visits=1" など）。
以前に Cookie に保存された情報と getInstalledRelatedApps() API を使用して、ユーザーが PWA ユーザーと見なされるかどうかを判断する関数（isPWAUser() など）を作成します。
ユーザーが意味のあるアクションを実行したときに、isPWAUser() を呼び出します。関数が true を返し、PWA インストールプロンプトが以前に保存されている場合は、PWA インストールボタンを表示できます。

アプリストアで PWA のインストールを促進する

アプリストアのアプリは、PWA 手法など、さまざまなテクノロジーで構築できます。PWA をネイティブ環境にブレンドするでは、その目的で使用できるテクノロジーの概要を確認できます。

ストアのアプリは、次の 2 つのグループに分類できます。

プラットフォーム固有のアプリ: これらのアプリは、主にプラットフォーム固有のコードで構築されています。アプリのサイズはプラットフォームによって異なりますが、通常 Android では 10 MB 以上、iOS では 30 MB 以上です。PWA がない場合や、プラットフォーム固有のアプリがより完全な機能セットを提供している場合は、プラットフォーム固有のアプリを宣伝することをおすすめします。
軽量アプリ: これらのアプリはプラットフォーム固有のコードで構築することもできますが、通常はウェブテクノロジーで構築され、プラットフォーム固有のラッパーにパッケージ化されます。完全な PWA をストアにアップロードすることもできます。一部の企業は、これを「ライト」エクスペリエンスとして提供することを選択しています。また、このアプローチを主力（コア）アプリにも使用している企業もあります。

軽量アプリを宣伝する

Google Play の調査によると、APK のサイズが 6 MB 大きくなるごとに、インストールのコンバージョン率が 1% 下がります。つまり、10 MB のアプリのダウンロード完了率は、100 MB のアプリよりも約 30% 高くなる可能性があります。

この問題を解決するため、一部の企業は PWA を活用して、Trusted Web Activities（TWA）を使用して Play ストアでアプリの軽量版を提供しています。TWA は PWA を webview のようなコンポーネントでラップします。その結果、アプリのサイズは通常数メガバイト程度になります。

インド最大のホスピタリティ企業の一つである Oyo は、アプリのライトバージョンを構築し、TWA を使用して Google Play ストアで提供しています。2020 年 5 月時点で、Oyo アプリのサイズはわずか 850 KB で、Android アプリの 7% にすぎません。インストール後は、Android アプリと区別がつきません。

OYO Lite の動作。

Oyo は、フラッグシップアプリと「ライト」アプリの両方のバージョンをストアに維持し、ユーザーに選択肢を提供しました。

軽量なウェブエクスペリエンスを提供する

直感的に、ローエンドデバイスのユーザーは、ハイエンドスマートフォンのユーザーよりも軽量版のアプリをダウンロードする傾向が強いと考えられます。そのため、ユーザーのデバイスを特定できる場合は、軽量アプリのインストールバナーを、プラットフォーム固有の重いアプリバージョンよりも優先できます。

ウェブでは、デバイスシグナルを取得し、デバイスカテゴリ（「高」、「中」、「低」など）に大まかにマッピングできます。この情報は、JavaScript API またはクライアントヒントを使用して、さまざまな方法で取得できます。

JavaScript を使用する

navigator.hardwareConcurrency、navigator.deviceMemory、navigator.connection などの JavaScript プロパティを使用すると、デバイスの CPU、メモリ、ネットワークのステータスに関する情報をそれぞれ取得できます。次に例を示します。

const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';`

クライアントのヒントを使用する

デバイスシグナルは、クライアントヒントを介して HTTP リクエストヘッダーで推測することもできます。クライアントヒントを使用してデバイスのメモリに関する上記のコードを実装する方法は次のとおりです。

ファーストパーティリクエストの HTTP レスポンスのヘッダーで、デバイスメモリのヒントを受け取ることをブラウザに伝えます。
```
HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory
```
HTTP リクエストのリクエストヘッダーで Device-Memory 情報の受信が開始されます。
```
GET /main.js HTTP/1.1
Device-Memory: 0.5
```

この情報をバックエンドで使用して、ユーザーのデバイスのカテゴリを含む Cookie を保存します。

app.get('/route', (req, res) => {
  // Determine device category

const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';

  // Set cookie
  res.setCookie('Device-Category', deviceCategory);
  …
});

この情報をデバイスカテゴリにマッピングする独自のロジックを作成し、各ケースに対応するアプリのインストールプロンプトを表示します。
```
if (isDeviceMidOrLowEnd()) {
  // show "Lite app" install banner or PWA A2HS prompt
} else {
  // show "Core app" install banner
}
```

プラットフォームに関係なくユーザーがアプリをインストールできるようにする

ユーザーのホーム画面にアイコンを表示できることは、アプリの最も魅力的な機能の一つです。これまで、アプリストアからインストールされたアプリでのみ可能だったことを考えると、アプリストアのインストールバナーを表示するだけで、ユーザーにエクスペリエンスをインストールしてもらえると考える企業もあるかもしれません。

ユーザーがアプリをインストールできるようにするオプションは他にもあります。たとえば、ストアで軽量アプリエクスペリエンスを提供したり、ウェブサイトから直接 PWA をホーム画面に追加するようユーザーに促したりできます。