これまで、アプリのインストールはプラットフォーム固有のアプリのコンテキストでのみ可能でした。最新のウェブアプリは、プラットフォーム固有のアプリと同じレベルの統合と信頼性を備えた、インストール可能なエクスペリエンスを提供します。
これを行うには、次の方法があります。
さまざまな配信チャネルを持つことは幅広いユーザーにリーチするうえで効果的な方法ですが、PWA のインストールを促進するための適切な戦略を選ぶのは簡単なことではありません。
このガイドでは、さまざまなインストール オプションを組み合わせてインストール率を高め、プラットフォーム間の競争やカニバリゼーションを回避するためのベスト プラクティスについて説明します。対象となるインストール オファーには、ブラウザと App Store の両方からインストールされる PWA や、プラットフォーム固有のアプリが含まれます。
ウェブアプリをインストール可能にする理由
インストール済みのプログレッシブ ウェブアプリは、ブラウザタブではなくスタンドアロン ウィンドウで実行されます。ユーザーのホーム画面、ホルダー、タスクバー、セクションから起動できます。デバイスで検索したり、アプリ切り替え機能で切り替えたりできるため、インストールされているデバイスの一部のように感じられます。
しかし、インストール可能なウェブアプリとプラットフォーム固有のアプリの両方が存在すると、ユーザーの混乱を招く可能性があります。ユーザーによっては、プラットフォーム固有のアプリが最適な選択になるかもしれませんが、次のようなデメリットが生じる場合もあります。
- ストレージの制約: 新しいアプリをインストールすると、他のアプリを削除したり、貴重なコンテンツを削除して空き容量を増やしたりすることがあります。これは、ローエンド デバイスのユーザーには特に不利です。
- 利用可能な帯域幅: アプリのダウンロードは、費用と時間のかかるプロセスになる可能性があります。特に、接続速度が遅く、データプランの料金が高いユーザーにとっては、その傾向が強くなります。
- 手間: ウェブサイトからストアに移動してアプリをダウンロードすると、手間が増え、ウェブで直接実行できるユーザー アクションが遅延します。
- 更新サイクル: プラットフォーム固有のアプリに変更を加える場合は、アプリの審査プロセスが必要になることがあります。このため、変更やテスト（A/B テストなど）の進行が遅れる可能性があります。
プラットフォーム固有のアプリをダウンロードしないユーザーの割合が大きい場合もあります。たとえば、アプリを頻繁に使用しないと思われるユーザーや、数メガバイトのストレージやデータを消費することを正当化できないユーザーなどです。このセグメントのサイズは、アナリティクス設定を使用して「モバイルウェブのみ」のユーザーの割合をトラッキングするなど、いくつかの方法で決定できます。
このセグメントのサイズがかなり大きい場合は、エクスペリエンスをインストールする代替の方法を提供する必要があることを示しています。
ブラウザを介した PWA のインストールを促進する
高品質の PWA がある場合は、プラットフォーム固有のアプリよりも PWA のインストールを促進することをおすすめします。たとえば、プラットフォーム固有のアプリに PWA が提供する機能が不足している場合や、長い間更新されていない場合などです。また、プラットフォーム固有のアプリが ChromeOS などの大画面向けに最適化されていない場合は、PWA のインストールを促すこともできます。
一部のアプリでは、プラットフォーム固有のアプリのインストールを促進することがビジネスモデルの重要な要素となっています。その場合は、プラットフォーム固有のアプリのインストールを促進することがビジネス上理にかなっています。ただし、ウェブ上での利用を好むユーザーもいるかもしれません。そのセグメントが特定できた場合は、そのセグメントのユーザーに対してのみ PWA のプロンプトを表示できます（このプロンプトを「代替としての PWA」と呼びます）。
主要なインストール エクスペリエンスとしての PWA
ほとんどのブラウザでは、PWA がインストール要件を満たすとインストール可能と表示されます。たとえば、パソコンの Chrome ではアドレスバーにインストール可能アイコンが表示され、モバイルではミニ情報バーが表示されます。
一部のエクスペリエンスではこれで十分かもしれませんが、PWA のインストールを促すことが目標の場合は、BeforeInstallPromptEvent をリッスンし、PWA のインストールを促進するためのパターンに従うことを強くおすすめします。
PWA がプラットフォーム固有のアプリのインストール率とカニバリゼーションを行うのを防ぐ
場合によっては、PWA ではなくプラットフォーム固有のアプリのインストールを促すこともできますが、その場合は、ユーザーが PWA をインストールできるメカニズムを用意することをおすすめします。このフォールバック オプションを使用すると、プラットフォーム固有のアプリをインストールできない、またはインストールしたくないユーザーが、同様のインストール エクスペリエンスを得ることが可能になります。
この戦略を実装する最初のステップは、PWA のインストール プロモーションをユーザーに表示するタイミングに関するヒューリスティックを定義することです。
例: PWA ユーザーとは、プラットフォーム固有のアプリのインストール プロンプトを見たものの、プラットフォーム固有のアプリをインストールしていないユーザーです。サイトに 5 回以上アクセスしたか、アプリバナーをクリックしたが、代わりにウェブサイトを引き続き使用していたユーザーです。
次に、ヒューリスティックを次のように実装します。
- プラットフォーム固有のアプリ インストール バナーを表示します。
- ユーザーがバナーを閉じた場合は、その情報を含む Cookie を設定します（例:
document.cookie = "app-install-banner=dismissed"）。 - 別の 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）を使用して Google Play ストアでアプリの軽量版を提供しています。TWA は、PWA をウェブビューのようなコンポーネントでラップします。その結果、アプリのサイズは通常数メガバイト程度になります。
インドの大手サービス会社である Oyo は、同社のアプリのライト版を作成し、TWA を使用して Google Play ストアで公開しました。この記事の執筆時点で、Oyo アプリのサイズはわずか 850 KB で、Android アプリのサイズの 7% に過ぎません。インストールすると、Android アプリと見分けがつきません。
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 をホーム画面に追加できるようにする、などです。