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

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

Demián Renzulli

Pete LePage

これまで、アプリのインストールはプラットフォーム固有のアプリのコンテキストでのみ可能でした。最新のウェブアプリは、プラットフォーム固有のアプリと同じレベルの統合と信頼性を備えた、インストール可能なエクスペリエンスを提供します。

これを行うには、次の方法があります。

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

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

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

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

インストールされた Progressive Web App は、ブラウザタブではなくスタンドアロンウィンドウで実行されます。ユーザーのホーム画面、ホルダー、タスクバー、セクションから起動できます。デバイスで検索したり、アプリ切り替え機能で切り替えたりできるため、インストールされているデバイスの一部のように感じられます。

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

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

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

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

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

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

一部のアプリでは、プラットフォーム固有のアプリのインストールを促進することがビジネスモデルの重要な要素となっています。その場合は、プラットフォーム固有のアプリのインストールを促進することがビジネス上理にかなっています。ただし、ウェブ上での利用を好むユーザーもいるかもしれません。そのセグメントを特定できる場合は、そのセグメントにのみ PWA プロンプトを表示できます（「PWA を代替手段として」）。

プライマリインストール可能エクスペリエンスとしての PWA

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

標準の Chrome インストールプロンプト（ミニ情報バー） — ミニ情報バー。

一部のケースではこれで十分ですが、PWA のインストールを促進することを目的としている場合は、BeforeInstallPromptEvent をリッスンし、PWA のインストールを促進するためのパターンに沿って対応することを強くおすすめします。

PWA がプラットフォーム固有のアプリのインストール率を食い尽くさないようにする

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

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

例: PWA ユーザーとは、プラットフォーム固有のアプリのインストールプロンプトが表示され、プラットフォーム固有のアプリをインストールしなかったユーザーです。サイトに 5 回以上アクセスしたユーザー、またはアプリのバナーをクリックしたユーザーで、ウェブサイトの使用を継続したユーザーです。

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

プラットフォーム固有のアプリインストールバナーを表示します。
ユーザーがバナーを閉じた場合は、その情報を含む Cookie を設定します（例: document.cookie = "app-install-banner=dismissed"）。
別の Cookie を使用して、サイトへのユーザーのアクセス数をトラッキングします（例: document.cookie = "user-visits=1"）。
isPWAUser() などの関数を作成します。この関数は、以前 Cookie に保存された情報と getInstalledRelatedApps() API を使用して、ユーザーが「PWA ユーザー」と見なされるかどうかを判断します。
ユーザーが有意なアクションを実行したら、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 Activity（TWA）を使用して、Google Play ストアでアプリの軽量バージョンを提供しています。TWA は、PWA をウェブビューのようなコンポーネントでラップします。その結果、アプリのサイズは通常数メガバイト程度になります。

インド最大級のホスピタリティ企業である Oyo は、アプリのライトバージョンを作成して、TWA を使用して Google Play ストアで公開しました。この記事の執筆時点で、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 を追加するようユーザーにプロンプトを表示したりできます。