新アプリへの移行や複数アプリの統合の際にユーザーを維持して価値を高める

  • エンゲージメント
  • 開発
  • マーケティング

アプリが十分な数のユーザーを抱えていても、ビジネスを発展させてより多くの価値をユーザーに提供するために、新しいアプリへの移行や複数のアプリの統合が必要になることがあります。入念に計画されたシンプルな手順をいくつか実施することで、多くのユーザーを維持して、移行を希望するユーザーを確保することができます。

移行や統合が生じる理由

別のアプリへの移行や複数の既存アプリの統合を検討する理由はいくつかあります。ビジネスやユーザーに対するメリットは、変更の要因によって異なります。主な理由は次のとおりです。

  • ユニバーサル APK への移行。Wear、タブレット、スマートフォンなど複数の種類のデバイスをサポートしている場合に、それぞれのバージョンで独自のパッケージ名や Play ストアの掲載情報が使用されていることがあります。複数のコードベースに同一の機能を再実装している場合や、そうしたアプリを管理するチームが合併された場合などには、そうした複数の個別パッケージを維持する意味がもはやない可能性があります。
  • 機能の統合。自社の複数のアプリ間で機能が重複している場合があります。そうしたアプリを 1 つに統合して、統一されたメッセージをユーザーに明確に伝えられます。
  • 再デザインや機能のピボットを行う。別の機能セットによって幅広い影響を与えたい場合や、ユーザー数が多いにもかかわらずアプリの収益が期待どおりではない場合には、新たなアプリを作成してユーザーを移行させるほうが簡単なことがあります。特に、現行アプリと完全に決別するような変化の場合はこの方法が適しています。
  • アプリの署名鍵の変更。Play ストアと Android はいずれも、パッケージ名と署名鍵の組み合わせによってアプリを一意に識別します。秘密鍵がわからなくなった、より強力な署名鍵が必要になった、または、最悪のケースとして鍵が外部に流出したなどの場合には、新しいパッケージ名が必要になります。

おすすめの方法

  • 最初の段階で複数の個別アプリを作成しないようにします。通常、個別のアプリを複数作成する(たとえば、さまざまなデバイスの種類やユースケースごとに個別のアプリを作成する)と、メンテナンス作業が増加するほか、ユーザーが自分でアプリを見つけて管理するのが大変になり、アプリの品質や利用率の低下の原因となります。
  • インストール数の多いアプリか、最もニーズのある機能を備えたアプリを移行先のアプリとして選択します。複数あるアプリのうちのどれを、全ユーザーの最終的な移行先にするかを決めます。通常は、インストール数の多いアプリを移行先にするとユーザーの混乱を最小限に抑えられます。ただし、最終的に求められる機能を持つアプリを移行先にする方法もあります。
  • または、新たな統合アプリを 1 つ作成し、他はすべてサポートを終了します。他の各アプリの機能を統合した新しいアプリを 1 つ作成します。ただし、既存のアプリのうち 1 つを残してそこに移行させる場合と比べて、この方法はユーザーを失うリスクが高くなります。
  • 段階的な移行を計画します。段階的に移行することで、ユーザーの混乱や不満を最小限に抑えられ、ユーザー定着率への影響も限定的となります。
  • ユーザーが徐々に変化に対応できるよう、中間アップデートを行うことを検討します。移行先に選んだアプリをアップデートして新機能や統合機能を追加する際に、その機能によってアプリの現在のデザイン、雰囲気、動作が大幅に変わってしまう場合は、段階的なアプローチを取ることをおすすめします。そうすることで、ユーザーが新しいアプリをスムーズに受け入れられるようになります。
  • 新たな種類のデバイスのサポートを追加し、新しい機能やデバイスのサポートを Play ストアの掲載情報に正しく記載します。Play ストアでは、あらゆるデバイスに対応する単一の「ユニバーサル」APK を用意してすべての種類のデバイスで同じ APK をインストールして実行できるようにする方法と、デバイスの種類別に複数の APK を提供する方法の 2 つを利用できます。Play ストアの掲載情報が別々にならないようにするには、すべての APK で同じ(新しい)パッケージ名を使用している必要があります。
  • マーケティングや宣伝用の資料を変更して、新しいアプリのみを紹介するようにします。新規のユーザーが正しいアプリに誘導されるようにして、移行が必要なユーザーの数を最小限に抑えます。そのためには、新しいアプリとその Play ストアの掲載情報をリブランドします。 中間アップデートを行う場合は、その機会を利用して、近い将来に名前やブランドが変わることをユーザーに通知します。
  • 移行に関する情報を現在のユーザーに伝えます。バナー、インタースティシャル、プッシュ通知などのメッセージを使って、徐々に情報を発信します。新しいアプリについての情報と、移行すべき理由をユーザーに伝えます。ここで最も重要なのは、ユーザーに移行を促すことです。そのため、新しいアプリの利点や改善点などを必ず強調するようにします。当初は古いアプリがまだ機能しており、ユーザーは移行するかどうかを選択できるため、穏やかで控えめな、非表示にしても問題のないメッセージを使用します。 このメッセージの重要性を徐々に高めて、移行の必要性を強調していきます。
  • ユーザーの移行を促進するインセンティブの提供を検討します。たとえば、新しいアプリの無料定期購入や 1 回限りの割引を提供します。移行の終わりに近づいたら、ユーザーに新しいアプリへの移行を促す一方で機能を無効にするなどの、より強力なインセンティブの検討をおすすめします。
  • 移行に関するフィードバックを収集します。移行期間中に、なんらかの要素(ユーザーが気に入っていた機能の一部など)が欠けていることがわかったり、その他の理由でユーザーが変化に不満を感じたりする可能性があります。この手順は急いで終わらせないようにします。この期間を利用してフィードバックを分析し、必要に応じて修正を加えます。
  • 古いアプリで、ユーザーを新しいアプリへと自動的にリダイレクトするバージョンのリリースを検討します。この手順は古いアプリを非公開にする前に行って、残りのユーザーをできるだけ多く移行させます。
  • 古いアプリを非公開にしてサポートを終了します。ブランディングの混乱や、新規のユーザーがサポートを終了したアプリを誤ってインストールするのを避けるために、古いアプリを非公開にすることをおすすめします。すべてのユーザーを移行させることは不可能なので、ビジネス上の判断として、ユーザーの喪失をどこまで許容するかのしきい値を決定します。