モバイルディープリンクについて知っておくべきことすべて
公開: 2017-02-14目次
ディープリンクに関しては、それが何であるかを知っている人は多くありません。 それはテクノロジーの世界の陰のヒーローです。 それでも、人々はその存在に気付かずに毎日それを使用します、あるいはそれが名前を持っていることを知らないかもしれません。 この投稿では、ディープリンクとは何か、モバイルでどのように適用されるかについての基本的なアイデアをいくつか紹介します。
ディープリンクとは何ですか？
ディープリンクは、リンクを介してネイティブモバイルアプリケーションを起動するための方法論です。
ディープリンクは、まさにその内容を実行します。リンクを使用して、ユーザーをWebサイト/アプリケーションの奥深くに誘導します。 デスクトップでは、ディープリンクとは、Webサイトのホームページ（「http：/」など）ではなく、Webサイト内の特定のコンテンツ（「http://example.com/path/page」など）にリンクするハイパーリンクを使用することです。 /example.com/”）。 モバイルでは、ディープリンクは、アプリを起動するだけでなく、モバイルアプリ内の特定の場所にリンクするURI（Uniform Resource Identifier）を使用します。 このシリーズでは、モバイルディープリンクのみに焦点を当てます。
だからあなたはあなたの携帯電話でインターネットを閲覧しています。 Googleで「Facebook」を検索すると、最初の結果がFacebookのホームページを指します。 そのリンクをタップすると、Facebookのホームページにリダイレクトされる代わりに、携帯電話のFacebookアプリが開きます。 これが基本的にモバイルディープリンクの仕組みです。
モバイルアプリケーションのディープリンクを有効にすると、ウェブサイトの場合と同じように、アプリを開いて、ホームページ、製品ページ、ショッピングカートなど、アプリ内で特定の定義済み画面を起動するディープリンクを呼び出すことができます。
ディープリンクは、ウェブサイトやiOS AppStoreやGooglePlayのアプリのリストに移動するのではなく、リンクがクリックされたときにアプリを開くことができるため、プロモーション活動に特に役立ちます。
3種類のディープリンク
1.従来のディープリンク
従来のディープリンクでは、リンクを開いたときにアプリが既にインストールされている限り、ユーザーをアプリのコンテンツにルーティングできます。 つまり、ユーザーがアプリを持っていない場合、従来のディープリンクは機能せず、エラーまたはフォールバックページが表示されます。
2.遅延ディープリンク
遅延ディープリンクは、リンクが開かれたときにアプリがインストールされていない場合でも、ユーザーをコンテンツにルーティングできます。 リンクは最初にAppStoreまたはPlayストアにリダイレクトしてアプリをダウンロードし、最初の起動直後にユーザーを特定の「延期された」コンテンツに移動します。
3.コンテキストディープリンク
コンテキストディープリンクには、遅延ディープリンクのすべての機能に加えて、さらに多くの機能があります。 コンテキストディープリンクには、ユーザーが行きたい場所、リンクがクリックされた場所、最初にリンクを共有したユーザー、およびほぼ無制限の量のカスタムデータに関する情報が格納されます。
コンテキストリンクは、アプリ開発者とユーザーの両方に価値をもたらします。 アプリ開発者は、パーソナライズされたウェルカム（友達がアイテムを共有している場合にアプリで友達のおすすめを確認できる）や紹介プログラムなど、単純なコンテンツリンクだけでなく強力な機能を構築できます。 アプリはより良いエクスペリエンスとより関連性の高い情報を提供できるため、アプリユーザーにはメリットがあります。
URIスキーム
カスタムURIスキームは、モバイルアプリのディープリンクの元の形式でした。 これらは、 myapp：// path / to / contentのようなリンクを使用して、アプリの「プライベートインターネット」を作成するようなものです。 カスタムURIスキームの利点は、セットアップが簡単で、ほとんどのアプリにすでに1つあることです。 欠点は、対応するアプリがすでにインストールされている場合にのみ、ユーザーのデバイスがこの「プライベートインターネット」について認識し、デフォルトで適切なフォールバックオプションがないことです。
URIスキームとのディープリンクへの回避策には、従来のhttp：//リンクを使用してWebブラウザーを起動することが含まれます。 このリンクには、アプリを起動するためにWebブラウザーによって実行されるカスタムURIスキームへのJavaScriptリダイレクトが含まれています。 アプリがインストールされていないためにリダイレクトの試行が失敗した場合、JavaScriptはユーザーをAppStoreまたはPlayストアに誘導します。
これは依然としてAndroidでのディープリンクへの主要なアプローチですが、 Appleは2015年にUniversalLinksのリリースでiOSでこのアプローチをブロックし始めました。
AppleiOSユニバーサルリンク
Appleは、カスタムURIスキームのディープリンクに適切なフォールバック機能がないことの解決策として、iOS9にユニバーサルリンクを導入しました。 ユニバーサルリンクは、アプリ内のWebページとコンテンツの両方を指す標準のWebリンク（http://mydomain.com）です。 ユニバーサルリンクを開くと、iOSはインストールされているデバイスがそのドメインに登録されているかどうかを確認します。 その場合、アプリはWebページをロードせずにすぐに起動します。 そうでない場合は、Web URL（App Storeへの単純なリダイレクトの場合があります）がSafariに読み込まれます。
Branchプラットフォーム上の何千ものアプリを調査したところ、Universal Linksによってオープンへのコンバージョンが40％増加したことがわかりました。
Androidリンク
GoogleはiOSユニバーサルリンクと同等のAndroidとしてアプリリンクを構築しました。これらは非常によく似た方法で動作します。アプリ内のウェブページとコンテンツの両方を指す標準のウェブリンクです。 これにより、ユーザーエクスペリエンスがスムーズになりますが、カスタムURIスキームはAndroidのすべてのバージョンで引き続き完全にサポートされているため、AppLinksの採用は非常に少なくなっています。
Facebookアプリのリンク
Facebookは、URIスキームのディープリンクの制限を解決するためのオープンスタンダードとして2014年にアプリリンクを作成しました。 アプリリンクには2つの主要なコンポーネントがあります。
- 標準のhttp：//リンクのWebページの宛先に追加するメタタグのセット。 これらのタグは、ネイティブアプリ内の対応するコンテンツのカスタムURIスキームの場所と、アプリがインストールされていない場合に発生する動作を指定します。
- リンクを開くことをサポートするアプリ内で使用するためのルーティングエンジン。 このエンジンは、App Linksタグを開く前にリンク先URLをチェックしてから、対応するアプリを起動するか、指定されたフォールバック動作を実行します。
http://applinks.org/documentation/
App Links標準には重大な欠陥があります。それは、起点と宛先の両方のアプリによる作業を必要とします。 メタタグコンポーネントは広く採用されましたが、ルーティングエンジンの主要な実装は、コアのFacebookアプリとMessengerアプリのみでした。
Facebookは現在、ユーザーをプラットフォーム内に留めることを好み、メインのAndroidアプリを除くすべての場所からAppLinksルーティングエンジンを削除しました。 FacebookはiOSユニバーサルリンクもブロックするため、これはiOS上のFacebookまたはMessengerからサードパーティのアプリを開くための信頼できる方法を残しません。 Branchは、これらの制限を回避するのに役立つソリューションを実装しました。
ディープリンク構造
ディープリンクは、Webページ上の従来のハイパーリンクのように機能します。 これは、URI（Uniform Resource Identifier）と呼ばれるものを構成する個別の要素で構成されています。 URIには、呼び出されたときに特定の画面でモバイルアプリケーションを起動するすべての情報が含まれています。
ディープリンク構造について考えるときのベストプラクティスは、アプリで実行するカスタムアクションを表す一意のスキーム名とルーティングパラメーター（パスとクエリ文字列）を使用してURLを実装することです。 非常に具体的なニーズがない限り、以下の例に示すような単純なURL構造を使用することをお勧めします。
mobiledeeplinkingprojectdemo：// path？query_string
mobiledeeplinkingprojectdemoはスキーム名であり、パスとクエリ文字列は、ユーザーをアプリの特定のエクスペリエンスにさらにルーティングするために使用されるルーティングパラメーターです。
スキーム名の場合：
- スキーム名を選択するときは、異なるアプリケーション間でスキームが競合しないように、ブランドに固有の名前を選択することが不可欠です。
- 現在、スキーム名との競合を管理する中央機関はありません。
- ベストプラクティスは、スキーム名にブランドを参照させることです（例：mobiledeeplinkingprojectdemo）。 スキーム名のもう1つの推奨パターンは、逆ドメイン名表記（org.mobiledeeplinkingなど）を使用することですが、これは広く採用されていません。
ルーティングパラメータ（パスとクエリ文字列）の場合：
- ルーティングパラメータはオプションですが、強くお勧めします。 ルーティングパラメータを使用すると、ユーザーをアプリケーションの特定の画面にルーティングしたり、追加のパラメータを渡したりするための詳細な制御が可能になります。
- クエリ文字列はオプションであり、製品IDなどの特定のパラメータを渡す必要がある場合に使用される可能性があります
- サードパーティがルーティングパラメータに追加のメタデータを追加する可能性があるため、アプリがこのユースケースを処理できることが重要です（パート2で説明したiOSおよびAndroidライブラリがこれを説明しています）
- モバイルアプリに対応するウェブサイトがある場合、モバイルアプリのルーティングパラメーター構文はウェブサイトのURL構造と一致することをお勧めします
iOSで人気のあるアプリのディープリンクの例をいくつか示します。
| デベロッパー | ディープリンク–例 | 目的 |
|---|---|---|
| ツイッター | twitter：// timeline | Twitterアプリを開き、ユーザーのタイムラインにリンクします |
| フェイスブック | fb：// profile | Facebookアプリを開き、ユーザーのプロファイルにリンクします |
| Yelp | yelp：// | Yelpアプリを開きます（注：この例にはルーティングパラメーターは含まれていません） |
ディープリンクの実装
MobileDeepLinkingライブラリを使用するかどうかに関係なく、ディープリンクを実装するには次のことが必要です。
- 使用するURIスキームを選択し、アプリのマニフェストで宣言します（以下で詳しく説明します）。 パート1で説明したように、スキーム名はアプリに固有である必要があります。そうでない場合、他のアプリとの競合が発生する可能性があります
- ディープリンクを使用して、起動するアクションを定義します。 これらのアクションが、選択したURI構文に従っていることを確認してください。 パート1で述べたように、URL構文の使用を強くお勧めします（例：
schemename://path?query_string）
それが完了したら、URLのパスとクエリ文字列セクションを処理するコードの実装を開始して、目的のアクションを起動できます。
MobileDeepLinkingライブラリを利用することをお勧めしますが、モバイルディープリンクを直接実装する場合、高レベルのプロセスは次のとおりです。
iOS
iOSアプリは自己完結型のエンティティです。 アプリには、AppDelegateという1つのエントリポイントしかありません。 アプリへのディープリンクが開始されると、ディープリンクメタデータを使用してAppDelegateが呼び出されます。
目的のエクスペリエンスを提供しながら、アプリで一貫した状態を維持することが重要です。 ディープリンクは、アプリの状態に関係なくいつでも起動される可能性があり、アプリを安定した状態に保つのはユーザーの責任です。
たとえば、これは、ユーザーがアプリのメイン画面に戻ることを許可することを意味する場合があります。 これを実現するには、適切なビューコントローラーをプッシュして、正しいビュー階層を維持しながら、ユーザーをアプリの目的の部分に移動させる必要があります。
アプリを開くと、起動に使用したURLを復元し、必要に応じて処理できます。
AppDelegateのリファレンスドキュメントはここにあります。
アンドロイド
Androidアプリは、一連のアクティビティで構成されています。 これらの各アクティビティは、そのように構成されている場合、他のアプリから呼び出すことができます。 アプリとディープリンクの構造に応じて、1つの中央エンドポイントまたは複数の中央エンドポイントを使用することを選択できます。
目的のエクスペリエンスを提供しながら、アプリで一貫した状態を維持することが重要です。 Androidアクティビティは現在のコンテキストの上で起動し、適切なビュー階層が維持されていることを確認するのはユーザーの責任です。 さらに、ユーザーがロードするときに、アクティビティに必要なデータを用意しておくことが重要です。
アプリを開くと、起動に使用したURLを復元し、必要に応じて処理できます。
Androidのディープリンクに関するリファレンスドキュメントはこちらにあります。
ユースケース
1.Webユーザーをアプリユーザーに変換する
美しいネイティブアプリに加えて優れたモバイルウェブサイトを構築するのに苦労したが、コンバージョン率がウェブよりもネイティブアプリの方が優れていることに気付いた場合はどうでしょうか。 この場合、モバイルWebユーザーを変換してアプリをダウンロードすると、ビジネスが後押しされる可能性があります。 それらを一方から他方に移動するのは難しい場合がありますが、ディープリンクを使用すると簡単になります。 モバイルディープリンクを使用すると、ユーザーをモバイルWebサイトからアプリ内の同等のコンテンツにシームレスに移行できます。 また、リンクはアプリのインストールプロセス後も存続するため、新しいユーザーでも、モバイルサイトで中断したところから再開できます。
2.ソーシャル、電子メール、およびSMSキャンペーン
任意のプラットフォームで機能するリンクを使用してプロモーションオファーを送信します。 現在および将来のユーザーは、iOS、Android、またはWebブラウザーを使用しているかどうか、およびアプリが既にインストールされているかどうかに関係なく、オファーを利用できます。
3.ユーザー間の共有
新しいユーザーにアプリをインストールさせる最も効果的な方法の1つは、ユーザーがアプリのコンテンツを友達と共有できるようにすることです。 モバイルディープリンクを使用すると、優れたユーザー間共有エクスペリエンスを作成できます。友達からコンテンツの推奨を受け取ったユーザーは、リンクをクリックして、アプリの共有コンテンツに直接移動できます。アプリを最初にインストールするには、AppStoreまたはGooglePlayストアを使用します。
4.実際のアプリのプロモーション
物理ディスプレイのディープリンクをエンコードするQRコードまたはバーコードを使用して、イベントや会場でアプリを宣伝します。 ユーザーは携帯電話のカメラを使用してQRコード/バーコードをスキャンし、アプリ内のターゲットコンテンツにリダイレクトするか、インストールしていない場合は最初にアプリをインストールするように求められます。
上記の4つのユースケースは、マーケティング担当者の観点から、ディープリンクがビジネスにどのように役立つかを示すほんの一例です。 アプリでモバイルディープリンクを使用して売り上げとエンゲージメントを高める方法は他にもたくさんあります。
結論
ディープリンクは、ユーザーを識別し、アドレスを指定して、アプリ内の特定のコンテンツに移動するための単なる方法です。 便利（そして必要）ですが、それほど革新的でもエキサイティングでもありません。 ディープリンクの将来の価値は、私たちがそれらをどのように使用するか、つまり、それらの上に何が構築されているか、そしてそれらが可能にする新しい消費者体験にあります。
これには、所有しているアプリのディープリンクを検出する新しい方法、ディープリンク可能な関連コンテンツとサービスを介した新しいアプリの検出、リンク自体を介したより多くのインテリジェンスの転送が含まれます。 ハイパーリンクのように、それは世界を変えるメカニズムではなく、それらを使用してWebを接続する方法です。