Firebase Dynamic Linksの代替: アプリとキャンペーンリンク移行

Firebase Dynamic Linksの代替を探すときは、まず「本当に置き換える必要がある挙動」を分けてください。多くのチームに必要なのは、ブランド化されたHTTPSリンク、デバイス別ルーティング、デスクトップ/モバイルWebへの明示的なフォールバックです。完全な遅延ディープリンクやモバイルアトリビューションまで必要なケースは、別の設計になります。

公式 Firebase Dynamic Links FAQ では、Firebase Dynamic Links は非推奨となり、2025年8月25日に終了したと案内されています。広告、メール、QRコード、オンボーディングリンクがまだ Dynamic Links に依存しているなら、カスタムドメイン、HTTPリダイレクト、ネイティブアプリ関連付けファイル、フォールバックURLを軸にリンクレイヤーを組み直すのが現実的です。

ドメイン変更やサイト移行と同時に進める場合は、サイト移行前のリダイレクトチェックリストも並行して使ってください。Dynamic Linksの移行が失敗する理由は、サイト移行とよく似ています。既存リンクの棚卸し不足と、フォールバックルールの曖昧さです。

ほとんどのチームが実際に Firebase Dynamic Links を使用した目的

チームが「Firebase Dynamic Linksの代替が必要」と言うとき、実際には次のどれかを指していることが多いです。

iPhone ユーザーを App Store に送信し、Android ユーザーを Google Play に送信します。
デスクトップ訪問者をランディングページまたは QR ハンドオフページに送ります。
アプリストアの長いリンクを共有する代わりに、クリーンなブランド URL を維持します。
測定用のキャンペーンパラメータを維持します。
可能な場合は、ネイティブリンク処理でインストール済みアプリを開きます。

これらはすべて同じ問題ではありません。

例:

ストアのフォールバックとデバイスのルーティングは、ほとんどが HTTP リダイレクトの問題です。
インストールされているアプリを開くは通常、Android アプリリンクおよび Apple ユニバーサルリンクの問題です。
インストール後の遅延ディープリンクには、多くの場合、追加のアプリ側ロジックまたは専用のアトリビューションスタックが必要です。
キャンペーンパラメータを保持するのは、リダイレクト品質の問題です。特にその部分が重要なら、パスとUTMを保持してドメインを転送する方法を確認してください。

[!TIP] 最短の移行は、Firebaseの機能を丸ごと別サービスで置き換えることではありません。製品チームとマーケティングチームが実際に依存している挙動だけを先に置き換えることです。

最も単純な移行判断フロー

この経験則を使用してください。

必要なのはスマートルーティングだけです

目的が次のようなルーティングだけなら:

iOS -> App Store
アンドロイド -> Google Play
デスクトップ -> WebサイトまたはQRページ

多くの場合、スマートリダイレクトレイヤーで十分です。この用途は、UrlEdge Device Targeting のようなデバイス別ルーティングに向いています。

インストール済みアプリを開く必要があります

次の挙動が必要なら:

インストール済みの iOS アプリを直接開く
インストール済みの Android アプリを直接開く
インストールされていないユーザーはストアまたは Web にフォールバックします

この場合は、両方が必要です。

リンクルーティングレイヤー
アプリとドメインでのネイティブアプリリンクのセットアップ

これは、正しい AASA および assetlinks.json ファイルを配布し、さらにアプリが宛先パスを処理できることを確認することを意味します。

遅延ディープリンクまたはアトリビューションワークフローが必要です

成長チームが依存している場合:

インストール属性
特定の画面へのインストール後のルーティング
インストールフロー全体にわたるキャンペーンマッチング

では、汎用リダイレクトサービスだけで十分であると想定しないでください。その場合は、ブランドリンク制御にリダイレクトレイヤーを使用し、それをチームがすでに信頼しているモバイルアトリビューションまたはアプリリンクスタックと組み合わせます。

実用的な Firebase Dynamic Links の代替アーキテクチャ

多くのチームにとって、移行は次のようになります。

ブランド化されたスマートリンク、デバイスターゲティング、およびアプリストアのフォールバックルーティングを表すためにラップトップとスマートフォンを組み合わせて使用

smart.yourbrand.com/promo
  -> detect device at the edge
  -> iOS: App Store or Universal Link target
  -> Android: Google Play or App Link target
  -> Desktop: landing page, docs page, or QR handoff page

このアーキテクチャには、次のような利点があります。

自社ドメインを自社で管理できる
フォールバック動作は 明示的でテスト可能
マーケティングリンクは 1 つのモバイルベンダーに関連付けられていません
分析、地域ルール、または一時的なオーバーライドを後で追加できます

主にルーティングとフォールバックを必要とするチームにとって、モノリシックなディープリンクプラットフォームを再構築するよりも、この方が保守しやすいことがよくあります。

段階的な移行計画

ステップ 1: すべてのアクティブなダイナミックリンクのインベントリを作成する

むやみに移行しないでください。すべてのアクティブな URL を次からエクスポートします。

有料キャンペーン
ライフサイクルメール
ソーシャルバイオス
QRコード
パートナードキュメント
モバイルオンボーディングフロー
アプリ内紹介

少なくとも次の列を含むシートを作成します。

old_dynamic_link,owner,use_case,ios_destination,android_destination,desktop_destination,notes
https://xyz.page.link/sale,growth,app download,https://apps.apple.com/app/...,https://play.google.com/store/apps/...,https://yourbrand.com/sale,seasonal campaign

これにより、エンジニアリング部門が明白なリンクを移行し、マーケティング部門が欠落している QR または電子メールの宛先を 2 週間後に発見するという古典的な障害モードが防止されます。

このスプレッドシートは、サイト移行前のリダイレクトチェックリストで推奨しているURLマップとよく似ています。どちらのプロジェクトも、公開前に信頼できるリダイレクトマップを1つ持つことが重要だからです。

ステップ 2: チャネルではなく動作によってリンクを分類する

各リンクを次のバケットのいずれかにグループ化します。

ストアフォールバックのみ
Web フォールバックのみ
フォールバックを使用したネイティブアプリリンク
特別なキャンペーンまたは地域/デバイスロジック

この分類により、リダイレクトプラットフォームだけで十分なのか、それともアプリ側のネイティブリンク処理も必要なのかがわかります。

ステップ 3: ブランドリンクを管理するドメインに移動する

移行は、可能であれば外部サービス側の短縮ドメインへの依存をやめる良いタイミングです。独自のドメインを使用すると、次のことが可能になります。

SSL と DNS を自社で制御できる
長期的にリンクを所有できる
SEO とブランドの一貫性を保ちやすい
外部プラットフォームへのロックインを減らせる

開始点が必要な場合は、アプリのリンクをメインのマーケティングドメインに混ぜるよりも、go.yourbrand.com や links.yourbrand.com のようなルートを管理する方が簡単です。

ステップ 4: 各プラットフォームの明示的な宛先を定義する

「フォールバック」を抽象的な概念のままにしないでください。それを書き留めてください。

例:

iPhone -> App Store
Android スマートフォン -> Google Play
デスクトップ -> QR コード付きの製品ランディングページ
タブレット -> 製品に応じて、デスクトップ Web ストアまたはアプリストアのいずれか

プラットフォーム固有の動作が必要であることがすでにわかっている場合は、すべてを 1 つの汎用リダイレクトで強制するのではなく、デバイスベースのルーティングを使用してください。

ステップ 5: 実際に重要な場所にネイティブアプリリンクを設定する

インストールしたアプリを直接開く必要がある場合は、ネイティブ作業を完了します。

Android アプリリンクを設定します。
Apple Universal Linksを設定します。
アプリ内でパスの一致をテストします
アプリが新規インストールとリピーターの両方を処理していることを確認します

これは多くのチームが見落としやすい部分です。リダイレクトレイヤーはトラフィックを正しく送れますが、アプリ側のリンク処理まで自動で作ることはできません。

ステップ 6: 実際のデバイスとブラウザでテストする

少なくとも次のことをテストします。

iPhone サファリ
iPhone アプリ内ブラウザ
Android Chrome
Android アプリ内ブラウザ
デスクトップ Chrome
デスクトップ Safari

次の条件でもテストします。

アプリがインストールされています
アプリがインストールされていません
キャンペーンパラメータが存在します
デスクトップで生成されたページからの QR スキャン

デバッグの場合、リダイレクトチェックツールを使用すると、キャンペーンダッシュボードから推測するのではなく、実際のリダイレクト動作を検査できます。

よくある移行の間違い

すべてのリンク動作を 1 つの要件として扱う

ストアのフォールバック、インストール済みアプリの起動、遅延ディープリンクは別の要件です。ひとまとめに扱うと、必要以上のツールを買うか、本当に必要な要件を見落とします。

デスクトップの動作を忘れる

チームが iOS と Android のみに最適化しているため、多くのモバイルリンクプロジェクトはデスクトップでは機能しません。デスクトップのフォールバックは製品エクスペリエンスの一部であり、二次的な後付けではありません。

キャンペーン追跡の無視

古いリンクに utm_ パラメータまたはキャンペーン ID が含まれていた場合は、それらを意図的に維持してください。すべての置換パスがデフォルトでクエリ文字列を渡すとは想定しないでください。

公開後まで監視を待つ

可観測性のない移行は推測にすぎません。 analytics を使用して、クリック動作と失敗した宛先をすぐに検査できるようにしてください。

UrlEdge が適合する場所

UrlEdge が向いているのは、ルーティング制御を置き換えたいケースです。

ブランドのカスタムドメイン
App Store / Play ストアのフォールバック
デスクトップ Web フォールバック
デバイス対応ルール
地理認識ルール
リダイレクト検証
エッジサイド分析

これは、ルーティングレイヤーをアプリのリリースサイクルから独立させたい場合に特に便利です。

チームがインストール後の大量のアトリビューションや遅延ディープリンクも必要とする場合は、範囲を正直に保ちます。トラフィックルーティングレイヤーに UrlEdge を使用し、アトリビューションとアプリ状態ロジックを所有するモバイルスタックと組み合わせます。

よくある質問

すべてのデバイスに 1 つのリンクを保持できますか?

はい。これは、最も一般的な移行パターンの 1 つです。 1 つのブランド URL で、iOS を App Store に、Android を Google Play に、デスクトップを Web サイトまたは QR ハンドオフページにルーティングできます。

ユニバーサルリンクまたはアプリリンクはまだ必要ですか?

はい。インストール済みアプリを直接開きたい場合は必要です。HTTP リダイレクトとネイティブアプリの関連付けは、別々のレイヤーを担当します。

アプリのダウンロードページに Firebase Dynamic Links のみを使用した場合はどうなりますか?

そうすると、移行は通常、思っているよりもはるかに簡単になります。多くの場合、必要なのは、デバイス対応のスマートリンク、明示的なストアフォールバック、およびキャンペーンに安全なクエリ処理だけです。

古いリンクを 1 つずつ移行する必要がありますか?

回避できる場合は手動ではありません。インベントリから開始し、リンクの動作を分類し、宛先を一括定義します。これは、その場限りの置き換えよりもはるかに安全です。

コアルーティング

スマートルール

セキュリティ＆モニター

ユーティリティとチェッカー

無料で構築を開始

会社とコミュニティ

法務とコンプライアンス

ドキュメント

Firebase Dynamic Linksの代替: アプリとキャンペーンリンク移行

ほとんどのチームが実際に Firebase Dynamic Links を使用した目的