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

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

これはさまざまな方法で実現できます。

さまざまな配信チャネルを持つことは幅広いユーザーにリーチするうえで効果的な方法ですが、PWA のインストールを促進するための適切な戦略を選ぶのは簡単なことではありません。

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

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

インストール済みのプログレッシブ ウェブアプリは、ブラウザタブではなくスタンドアロン ウィンドウで実行されます。ホーム画面、ドック、タスクバー、シェルフから起動できます。アプリ スイッチャーを使用すると、デバイス上でアプリを検索し、デバイス間を行き来できるため、アプリをインストールしているデバイスの一部であるかのように操作できます。

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

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

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

このセグメントのサイズが大きすぎる場合は、別の方法でウェブサイト エクスペリエンスを提供する必要があることを示しています。

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

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

一部のアプリでは、プラットフォーム固有のアプリのインストールを促進することがビジネスモデルの重要な要素です。その場合は、プラットフォーム固有のアプリのインストールを促進することがビジネス上の意味があります。ただし、ウェブを利用するのが快適であるユーザーもいます。そのセグメントが特定できた場合は、そのセグメントのユーザーに対してのみ PWA のプロンプトを表示できます(このプロンプトを「代替としての PWA」と呼びます)。

主要なインストール エクスペリエンスとしての PWA

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

<ph type="x-smartling-placeholder">
</ph> ミニ情報バーと呼ばれる Chrome の標準のインストール プロンプト <ph type="x-smartling-placeholder">
</ph> ミニ情報バー。

一部のエクスペリエンスではこれで十分かもしれませんが、PWA のインストールを促すことが目標の場合は、BeforeInstallPromptEvent をリッスンし、PWA のインストールを促進するためのパターンに従うことを強くおすすめします。

PWA がプラットフォーム固有のアプリのインストール率とカニバリゼーションを行うのを防ぐ

場合によっては、PWA ではなくプラットフォーム固有のアプリのインストールを促すこともできますが、その場合は、ユーザーが PWA をインストールできるメカニズムを用意することをおすすめします。このフォールバック オプションを使用すると、プラットフォーム固有のアプリをインストールできない、またはインストールしたくないユーザーが、同様のインストール エクスペリエンスを得ることが可能になります。

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

例: PWA ユーザーとは、プラットフォーム固有のアプリのインストール プロンプトが表示されたものの、プラットフォーム固有のアプリをインストールしていないユーザーです。5 回以上サイトに再度アクセスしたか、アプリバナーをクリックしたが、代わりにウェブサイトを使い続けている。

次に、ヒューリスティックを次のように実装します。

  1. プラットフォーム固有のアプリ インストール バナーを表示します。
  2. ユーザーがバナーを閉じた場合は、その情報を含む Cookie を設定します(例: document.cookie = "app-install-banner=dismissed")。
  3. 別の Cookie(例: document.cookie = "user-visits=1")を使用してサイトへのユーザーの訪問回数をトラッキングする。
  4. 以前に Cookie に保存された情報と getInstalledRelatedApps() API を使用して、ユーザーが「PWA ユーザー」とみなされるかどうかを判断する関数(isPWAUser() など)を作成します。
  5. ユーザーが意味のあるアクションを実行したら、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 は、同社のアプリのライト バージョンを作成し、TWA を使用して Google Play ストアで公開しました。この記事の作成時点で、Oyo アプリはわずか 850 KB で、Android アプリの 7% に過ぎませんでした。一度インストールすれば、Android アプリと見分けがつかなくなります。

<ph type="x-smartling-placeholder">
</ph> <ph type="x-smartling-placeholder">
OYO Lite の実例

Oyo はフラッグシップと「Lite」の両方を維持ユーザーに選択肢を提供します。

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

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

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

JavaScript を使用する

navigator.hardwareConcurrencynavigator.deviceMemorynavigator.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 をホーム画面に追加できるようにする、などです。