ディファードディープリンク
ディファードディープリンクの実装とプラットフォーム差異
ディファードディープリンクを実現するには、リンククリック時からアプリ初回起動までの間に情報を保持して受け渡す仕組みが必要です。これは標準機能だけでは完結しないことが多く、モバイル計測サービスや独自サーバの力を借ります。
Androidの場合: Google Play経由でのインストールには「インストールリファラー」という仕組みがあります。広告URLやPlayストアのリンクに計測用パラメータを付与すると、インストール後にアプリ側でその値を受け取れるものです(Play Install Referrer API)。例えばリンククリック→Playストアにリダイレクトする際に商品ID等を埋め込んでおき、インストール後アプリがそのIDを受け取り対応ページを表示する、といったことが可能です。また、BranchやAdjust等のSDKは独自に一時的なブラウザクッキーやデバイスIDマッチングを用いて、ストア遷移を挟んでもユーザーとリンク情報を突き合わせるソリューションを提供しています。Androidは比較的オープンなため、Chromeカスタムタブや中間サーバを使ってインストール完了を検知し、アプリ起動時にREST APIでリンク情報を取りに行く…といった実装も見られます。公式にはFirebase Dynamic Linksがその役割を担ってきましたが、前述の通り2025年にサービス終了予定のため、今後は他サービスや独自実装への移行が必要です。いずれにせよAndroidではリンク→ストア→アプリの流れを比較的スムーズに繋げる手段が整っています。
iOSの場合: iOSはセキュリティ上、インストール経路の把握やパラメータ受け渡しが制限されています。App Store経由で任意のデータを受け渡す手段は(Apple公式では)提供されていません。そのため、サードパーティ各社はリダイレクトや端末識別情報を駆使した間接的方法で対応してきました。典型的なのは、リンククリック時に一度Safariで中間ページを開き、そこでJavaScript経由でlocalStorageやクッキーにリンクパラメータを保存しておきます。ユーザーがアプリをインストールして起動した際に、アプリ内で同じドメインのWeb Viewを開きそのクッキーを読みに行くことで、元リンク情報を取得する手法です。Branch.ioなどはこの方式を用いており、比較的確実にディファードディープリンクを実現できます。またAppleはiOS 15からApp Store経由のSafariリダイレクト後、自動的にアプリを再起動する「ウェブ→Appの連携」機能をサポートしました(SKAdNetworkの改善の一環)が、限定的かつ広告計測用途であり汎用の深いリンク情報受け渡しには使われません。したがってiOSでは専ら外部サービスや高度な実装でディファードディープリンクを補完しているのが現状です。公式機能としてはユニバーサルリンク+Web Banner程度なので、Androidに比べ手間がかかりますが、その分計測各社が工夫を凝らしたSDKを提供しています。