これまで、アプリのインストールはプラットフォーム固有のアプリのコンテキストでのみ可能でした。現在の最新のウェブアプリは、プラットフォーム固有のアプリと同じレベルの統合と信頼性を提供する、インストール可能なエクスペリエンスを提供しています。
これにはさまざまな方法があります。
さまざまな配信チャネルを持つことは、幅広いユーザーにリーチできる強力な方法ですが、PWA のインストールを促す適切な戦略を選択するのは難しい場合があります。
このガイドでは、さまざまなインストール オプションを組み合わせてインストール率を高め、プラットフォームの競合やカニバリゼーションを回避するためのベスト プラクティスについて説明します。対象となるインストール サービスには、ブラウザと App Store の両方からインストールされた PWA と、プラットフォーム固有のアプリが含まれます。
ウェブアプリをインストール可能にする理由
インストール済みのプログレッシブ ウェブアプリは、ブラウザタブではなくスタンドアロン ウィンドウで実行されます。ユーザーのホーム画面、ホルダー、タスクバー、シェルフから起動できます。デバイスでアプリを検索し、アプリ スイッチャーを使用してアプリ間を行き来できるため、インストールされているデバイスの一部であるかのように感じられます。
しかし、インストール可能なウェブアプリとプラットフォーム固有のアプリの両方が存在すると、ユーザーが混乱する可能性があります。ユーザーによってはプラットフォーム固有のアプリが最適な選択になる場合もありますが、デメリットもあります。
- ストレージの制約: 新しいアプリをインストールする場合は、他のユーザーを削除するか、貴重なコンテンツを削除して空き容量を増やす必要があります。これは、ローエンド デバイスのユーザーには特に不利です。
- 利用可能な帯域幅: アプリのダウンロードは高コストで時間のかかるプロセスになる可能性があります。接続速度が遅いユーザーやデータプランが高額なユーザーにとっては、なおさらです。
- 煩わしさ: ウェブサイトから離れ、アプリをダウンロードするためにストアに移動すると、さらなる摩擦が発生し、ウェブで直接実行できるユーザー アクションが遅れます。
- アップデート サイクル: プラットフォーム固有のアプリに変更を加えるには、アプリの審査プロセスが必要になる場合があり、変更やテスト（A/B テストなど）に時間がかかる可能性があります。
特定のプラットフォーム固有のアプリをダウンロードしないユーザーの割合が高い場合もあります。たとえば、アプリを頻繁には使用しないと考える人、数メガバイトの保存容量やデータを消費することを正当化できないユーザーなどです。このセグメントのサイズは、「モバイルウェブのみ」のユーザーの割合をトラッキングする分析設定など、いくつかの方法で特定できます。
このセグメントのサイズがかなり大きい場合は、エクスペリエンスをインストールする別の方法を提供する必要があることを示しています。
ブラウザを通じて PWA のインストールを促進する
高品質の PWA がある場合は、プラットフォーム固有のアプリよりもインストールを促すことをおすすめします。たとえば、プラットフォーム固有のアプリに PWA が提供する機能がない場合や、しばらく更新されていない場合などです。プラットフォーム固有のアプリが ChromeOS などの大画面向けに最適化されていない場合にも、PWA のインストールを促進するのに役立つ可能性があります。
アプリによっては、プラットフォーム固有のアプリのインストールを促進することがビジネスモデルの重要な部分を占めます。この場合、プラットフォーム固有のアプリのインストールを促進することはビジネスにとって理にかなっています。ただし、ユーザーによっては、ウェブにとどまる方がよい場合もあります。そのセグメントを識別できる場合は、そのセグメントにのみ 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"）。 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 を WebView のようなコンポーネントにラップするため、生成されるアプリのサイズは通常、数メガバイトに留まります。
インドの大手サービス会社である Oyo は、Lite 版のアプリを作成し、TWA を使用して Google Play ストアで公開しました。この記事を執筆した時点で、Oyo アプリのサイズはわずか 850 KB で、Android アプリの 7% にすぎません。インストールすると、Android アプリと見分けがつかなくなります。
Oyo は、ユーザーに選択肢を提供するために、主力アプリと「ライト」アプリの両方をストアに保持しました。
軽量のウェブ エクスペリエンスを提供する
直感で言うと、ローエンド デバイスのユーザーはハイエンド スマートフォンのユーザーよりも軽量版のアプリをダウンロードする傾向があります。そのため、ユーザーのデバイスを識別できる場合は、プラットフォーム固有のアプリ バージョンよりも軽量なアプリ インストール バナーを優先できます。
ウェブでは、デバイスのシグナルを取得して、デバイス カテゴリ（「高」、「中」、「低」など）に大まかにマッピングできます。この情報は、JavaScript API または Client Hints のいずれかを使用して、さまざまな方法で取得できます。
JavaScript の使用
navigator.hardwareConcurrency、navigator.deviceMemory、navigator.connection などの JavaScript プロパティを使用すると、それぞれデバイスの CPU、メモリ、ネットワークのステータスに関する情報を取得できます。次に例を示します。
const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';`
クライアント ヒントの使用
デバイス シグナルは、Client Hints を使用して 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 を追加したりできます。