Firebase Dynamic LinksからElidoへの移行

Firebase Dynamic Linksは2025-08-25に終了しました。すべてのFDLリンクは現在404を返します。インストールアトリビューション、遅延ディープリンク、または特定の画面へのインストール後ルーティングにFDLを使用していた場合、それらのフローは今この瞬間も本番環境で壊れています。Branch.ioはFDLが無料で提供していたことを置き換えるティアで月199ドルからはじまります。Elidoのディープリンクルーティングは同じパターンをはるかに安価でカバーし、EUのデータレジデンシーが標準で組み込まれています。

これは壊れたFDLリンクから動作するユニバーサルリンクとAndroidアプリリンクへの最短経路です。

要約

• Firebase Dynamic Linksは2025年8月25日に終了しました。Firebase Dynamic Links廃止FAQによると、その日付以降すべての*.page.link URLはHTTP 404を返します
• まだ移行していない場合、アプリのインストールアトリビューション、インストール後のルーティング、遅延ディープリンクは壊れています
• 移行はDNSの変更、2つのJSONファイル(Apple用とGoogle用)、リンクの書き換えです - コードの書き直しではありません
• このユースケースに対するBranch.ioのエントリーレベルティアは月199ドルです。Elido Proはリンク単位の従量制なしで実質的に低コストで同じルーティングをカバーします
• SwiftやKotlinの既存のディープリンク処理コードを変更する必要はありません - OS レベルのユニバーサルリンク/アプリリンクのハンドオフは、どのサービスがルーティングをホストしているかに関わらず同じように機能します

Firebase Dynamic Linksが実際に何をしていたか

FDLは通常のHTTPSリンク単独では解決できない3つの問題に対するGoogleの答えでした。

遅延ディープリンク。 あなたのアプリが入っていないデバイスのユーザーがリンクをクリックします。OSがApp StoreまたはPlay Storeを開きます。ユーザーがアプリをインストールします。アプリは汎用のホーム画面に開き、ユーザーが特定のコンテンツにアクセスしようとしていたことをまったく知りません。FDLは意図した目的地を保存し、インストールギャップを越えてそれを渡しました - アプリは初回起動時にFDL SDKをクエリして、ユーザーを正しい画面にルーティングできました。

インストールアトリビューション。 FDLリンクはインストールを生き延びるキャンペーンパラメータ(utm_source、utm_medium、?st=と?si=経由のカスタムパラメータ)を持っていました。これはサードパーティMMPなしに、特定のメールキャンペーン、有料ソーシャルクリエイティブ、またはインフルエンサーリンクにインストールを帰属させるメカニズムでした。

プラットフォーム対応のルーティング。 1つのリンク、3つの目的地: iOSユーザーはApp Storeに(またはインストール済みならアプリの深部に)、AndroidユーザーはPlay Storeに(またはアプリに)、デスクトップブラウザは設定可能なフォールバックURLを受け取りました。ルーティングはアプリコードではなく、Googleのエッジでサーバーサイドに行われました。

FDLが終了したとき、これら3つの機能がすべて同時に404になりました。アプリにFDL SDKを使用していた場合、存在しなくなったエンドポイントを呼び出しています。

Elidoの同等機能

Elidoはリダイレクトエッジでのプラットフォーム検出と標準OSディープリンクメカニズムを通じて、同じ3つの動作を再現します。

エッジでのプラットフォーム検出。 Elidoのショートリンクはリダイレクト時にUser-Agentヘッダーを調べ、プラットフォームに基づいて異なる目的地にルーティングします: iOS → App Store URL(またはアプリのユニバーサルリンク)、Android → Play Store URL(またはアプリリンクインテント)、デスクトップ → ウェブフォールバック。これはリダイレクトプレーンで5ms未満で行われます。SDK呼び出しなし、別のアトリビューションサービスへの往復なし。

iOSユニバーサルリンク。 デバイスにアプリがインストールされている場合、iOSはブラウザが開く前にHTTPSリンクをインターセプトします。これにはカスタムドメインのwell-knownパスからApple App Site Association(apple-app-site-association)ファイルを提供する必要があります。Elidoはディープリンクルーティングを有効にしてカスタムドメインを設定すると、このファイルをあなたに代わってホストします。結果はFDLが提供していたものと同じです: アプリがリンクされた画面に直接開きます。

Androidアプリリンク。 Android上での同じメカニズム、異なるファイル形式。Googleのassetlinks.jsonファイルはドメインの/.well-known/assetlinks.jsonにあります。アプリのパッケージ名とSHA-256証明書フィンガープリントを提供すると、Elidoがこのファイルを生成して提供します。Androidアプリリンクはブラウザのインタースティシャルなしにアプリを直接開きます。

遅延ディープリンクパススルー。 インストールギャップのケース(ユーザーがまだアプリを持っていない)では、Elidoは意図したディープリンクターゲットをショートURLに対して保存し、軽量なクエリエンドポイント経由で公開します。アプリは初回起動時にインストール元のショートURL(AndroidのInstall Referrer(INSTALL_REFERRER)とiOSのApp Storeアトリビューション APIから回復可能)でこのエンドポイントを呼び出し、元のディープリンクパスを取得します。FDL SDKなし、独自のハンドシェイクなし。ディープリンクガイドにクエリエンドポイントの仕様があります。

完全な機能ページは/features/deep-linksにあります。

ステップバイステップの移行

ProまたはElidoそれ以上のElidoアカウントと、あなたが管理するカスタムドメインがあることを前提とします。単純な移行に30分かかります。FDLリンクのボリュームが大きく一括書き換えスクリプトが必要な場合はバッファを追加してください。

ステップ1: ElidoにカスタムドメインをI追加する

Elidoダッシュボードで、ワークスペース → カスタムドメイン → ドメインを追加に移動します。意図したブランドドメイン(例: links.yourapp.com)を入力します。ElidoがCNAMEレコードを表示します。

DNSレジストラで、CNAMEを追加します:

links.yourapp.com.  CNAME  cname.elido.me.

TTLの推奨: 現在3600秒以上の場合は、この作業の数時間前に300秒に下げてください。TLSプロビジョニングはCaddy on-demand TLSを通じて自動的に行われ、DNS伝播後数分で完了します。

ステップ2: iOSユニバーサルリンクを設定する(AASAファイル)

ドメイン設定で、ディープリンクルーティングを有効にし、以下を提供します:

• iOSバンドル識別子(例: com.yourcompany.yourapp)
• アプリを開くURLパスパターン(例: すべてのショートリンクに/l/*、または特定のパス)

Elidoはhttps://links.yourapp.com/.well-known/apple-app-site-associationでAASAファイルを生成して提供します。次に進む前に正しく解決されることを確認します:

curl -s https://links.yourapp.com/.well-known/apple-app-site-association | python3 -m json.tool

レスポンスにapplinks.details配列にバンドルIDが含まれているはずです。iOSはAASAファイルのキャッシュコピーをアプリインストール時とその後定期的に更新します。テスト中に強制更新するには、iOS設定の開発者 → リセットを通じてデバイスのAASAキャッシュをリセットするか、アプリを新規インストールしてください。

アプリのInfo.plistは関連ドメインを宣言している必要があります。FDLドメインに対してすでに宣言している場合、オーバーラップ期間中に既存のものと一緒に新しいドメインを追加します:

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:links.yourapp.com</string>
  <!-- 必要に応じてオーバーラップ期間中はFDLドメインも保持 -->
</array>

ステップ3: Androidアプリリンクを設定する(assetlinks.json)

同じディープリンク設定パネルで、以下を提供します:

• アプリのパッケージ名(例: com.yourcompany.yourapp)
• リリース署名証明書のSHA-256フィンガープリント

キャッシュされていない場合はフィンガープリントを取得します:

keytool -list -v -keystore release.keystore -alias your-alias | grep SHA256

Elidoはhttps://links.yourapp.com/.well-known/assetlinks.jsonでファイルを生成して提供します。確認します:

curl -s https://links.yourapp.com/.well-known/assetlinks.json | python3 -m json.tool

AndroidManifest.xmlのインテントフィルターは、Android SDKの自動検証機能を使用してFDLを使用していた場合、すでにアプリリンク用に設定されているはずです。そうでない場合は、ディープリンクのインテントフィルターにandroid:autoVerify="true"属性を追加して、新しいドメインを指すようにします。

ステップ4: 既存のFDLリンクを書き換える

FDLリンクの形式はhttps://yourapp.page.link/SLUGまたはhttps://yourapp.page.link/?link=https%3A%2F%2F...&...です。どちらのパターンも機能し続けません - page.linkドメインは死んでいます。

少数のFDLリンク(数百未満)を作成した場合は、Elidoダッシュボードで手動で書き換えます。数千を作成した場合(メールキャンペーンやQRコード印刷物でよくある)は、Elido一括インポートAPIを使用します:

curl -X POST https://api.elido.app/v1/links/bulk \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "links": [
      {
        "slug": "welcome",
        "destination": "https://yourapp.com/welcome",
        "routing": {
          "ios": "https://apps.apple.com/app/id12345678",
          "android": "https://play.google.com/store/apps/details?id=com.yourcompany.yourapp",
          "fallback": "https://yourapp.com/welcome"
        }
      }
    ]
  }'

物理的な素材(パッケージ、ポスター、名刺)にすでに印刷されているリンクについては、URL自体を更新できません - ただし、印刷されたURLがあなたが管理するドメインを指すカスタムドメインのFDLリンクだった場合は、そのドメインのCNAMEをElidoに向け直すことができ、印刷されたリンクが新しいルーティング設定で再び機能するようになります。

ステップ5: アプリの初回起動遅延ディープリンククエリを更新する

FDLアプリは初回起動時にFirebaseDynamicLinks.dynamicLinks().handleUniversalLink(url)または同等のSDKメソッドを呼び出します。それを削除します。Elidoの遅延ディープリンクエンドポイントへの呼び出しに置き換えます:

// iOS - インストール後の初回起動時
let installURL = "https://links.yourapp.com/welcome" // StoreKitアトリビューションから回復
let endpoint = URL(string: "https://api.elido.app/v1/deferred?url=\(installURL.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)!)")!
URLSession.shared.dataTask(with: endpoint) { data, _, _ in
    guard let data, let result = try? JSONDecoder().decode(DeferredLink.self, from: data) else { return }
    DispatchQueue.main.async { self.navigate(to: result.deepLink) }
}.resume()

AndroidのエクイバレントはPlay Install Referrer APIを使用してショートURLを回復し、同じエンドポイントを呼び出します。ディープリンクガイドに両プラットフォームのフルコードサンプルがあります。

ステップ6: エンドツーエンドのテスト

切り替える前に、3つのケースをテストします:

1. アプリインストール済み、デバイス上でリンクをクリック - Safari/ChromeでショートリンクをタップしI、ブラウザのインタースティシャルなしにアプリが正しい画面に直接開くことを確認します。
2. アプリ未インストール、リンクをクリック - リンクをタップし、正しいApp Store / Play Storeページにルーティングされることを確認します。
3. リンクをクリック後にストアからアプリをインストール - アプリを新規インストールし、初回起動時(遅延ディープリンクパス)に意図した画面に開くことを確認します。

ユニバーサルリンクは実機でテストしてください。iOSシミュレーターはAASAハンドオフを確実に実行しません。

エッジケース

アプリ内で読み取っていたFDLパラメータ。 開いた後にFDLリンクからパラメータを読み取るためにDynamicLink.dynamicLink().urlを呼び出していた場合、そのパラメータは今はありません。Elidoのショートリンクの目的地URLにクエリパラメータとして同じ情報をエンコードし、iOSまたはAndroidがアプリに渡すディープリンクURLからそれらを読み取る必要があります。パラメータのエンコードは同じです - ?screen=onboarding&ref=email_april - ただしFDLの独自のlink=ラッパーから目的地URL自体に移動しています。

アトリビューションの喪失。 FDLのアトリビューションは自己完結していました: GoogleがキャンペーンパラメータをI保存してSDKに返しました。Elidoは当社の分析ストアにクリックイベントデータ(タイムスタンプ、プラットフォーム、国、リファラー)を保存し、分析APIを通じて公開しますが、MMP(モバイル測定パートナー)ではありません。規模でのプロバビリスティックまたはデターミニスティックなインストールアトリビューションが必要な場合(コホート分析、獲得ソース別のLTV、SKAdNetworkのスティッチング)、MMP(Adjust、AppsFlyer)またはElidoのクリックウェブフックを自分のアナリティクスパイプラインに組み込む必要があります。「ユーザーを正しい画面にルーティングする」ためだけにFDLを使っていたほとんどのインディーアプリや初期段階のチームにとっては、Elidoの分析で十分です。マルチチャネルアトリビューションを実行している有料獲得チームは、次のセクションを参照してください。

アプリバイナリに埋め込まれた既存のpage.linkショートURL。 アプリコードにFDLショートURLをハードコードしていた場合(クライアントサイドで生成されるプッシュ通知ペイロード、アプリからミントされる紹介リンク)、それらの文字列は死んだドメインを参照しています。強制的なアプリアップデートか、オンデマンドで新しいショートURLを生成するサーバーサイドエンドポイントが必要です。page.linkをリダイレクトする方法はありません - Googleがドメインを完全にシャットダウンしました。

エンコードされたパラメータを持つ長いFDL URL。 FDLはhttps://yourapp.page.link/?link=https%3A%2F%2F...&ibi=com.yourapp&ifl=...&afl=...のような長形式のURLをサポートしていました。これらのパラメータ(ibi、ifl、afl、isi)はFDL固有です。Elidoのルーティングフィールドにマッピングします: ifl(iOSフォールバック) → routing.ios、afl(Androidフォールバック) → routing.android、ibi(iOSバンドルID)はElidoのドメインレベルですでに設定されています。linkパラメータが目的地URLになります。

EUデータレジデンシー。 アプリがEUで運営されていてEUユーザーデータを処理している場合、リダイレクトイベント(IPアドレスとUser-Agent文字列を含む)はGDPR上の個人データです。FDLはUS処理のあるGoogleのグローバルインフラにホストされていました。ElidoはデフォルトでEUリージョンにホストされています。EUのクリックイベントはEU内に留まります。トラストページとコンプライアンス概要に、契約上の詳細があります。

実際にBranch.ioが必要な場合

Elidoはスクリーンルーティングと基本的なインストールアトリビューションにFDLを使用していたほとんどのアプリに適した選択肢です。以下に依存している場合は適切ではありません:

有料UAのためのプロバビリスティックアトリビューション。 Branchはポストバックを通じて広告ネットワーク(Meta、Google、TikTok、Snap)と統合し、決定論的なフィンガープリントが利用できない場合(例: ATTに同意していないiOS 14.5+)にプロバビリスティックにインストールを帰属させることができます。Elidoはプロバビリスティックアトリビューションを行いません。グロースチームが有料UAを実施していて、コホートレベルで広告費に対してインストールを照合する必要がある場合、BranchまたはMMP(Adjust、AppsFlyer)がその特定の問題に適切なツールです。

SDKレベルのフィンガープリンティングとデバイスマッチング。 BranchのSDKはデバイスシグナル(画面解像度、IP、言語、タイムゾーン)を収集して、インストールリファラーに依存せずにインストールギャップをまたいでデバイスをフィンガープリントします。リファラーのみのマッチングは、リファラーが削除される環境では劣化します - 遅延ディープリンクのヒット率が約80%を超える必要がある場合、SDKレベルのアプローチの方がパフォーマンスが良いです。

特定の広告ネットワークとの深い統合。 BranchにはMeta CAPI、Googleのコンバージョントラッキング、TikTokのイベントAPIとの専用統合があり、Elidoのサーバーサイドコンバージョンフォワーディングがカバーする範囲を超えています。アトリビューションスタックがそれらのネットワークの1つと密接に結合している場合、切り替える前にBranchの特定の統合ドキュメントを評価してください。

実践的なテスト: インストール後にユーザーを正しい画面にルーティングするために主にFDLを使用していて、アトリビューションのニーズがアナリティクスツールのUTMパラメータでカバーされている場合、Elidoは低コストでFDLを置き換えます。パフォーマンスマーケティングを規模で実施していて、アトリビューションの精度が予算の決定を左右する場合、それがBranchの実際の価値提案であり、月199ドルがそのための実際のインフラを購入します。

よくある質問

アプリのプッシュ通知ペイロードにFDLショートリンクが含まれています - ユーザーがタップするとどうなりますか?

リンクはpage.linkを指しており、404を返します。OSのリンク処理が404をブラウザまたはアプリのユニバーサルリンクハンドラーに返し、失敗します。プッシュ通知サービスを更新してElidoショートリンクを生成するようにする必要があります。サーバーサイドでプッシュペイロードを生成している場合(正しいアプローチ)、FDL APIの代わりにElido APIを呼び出すための1行の変更です。ペイロードがハードコードされたテンプレートからクライアントサイドで生成されている場合は、アプリのアップデートが必要です。

移行を完了するためにアプリのアップデートをリリースする必要がありますか?

遅延ディープリンククエリ(インストールギャップルーティング)については、はい - FDL SDKの呼び出しをElidoエンドポイントの呼び出しに置き換える必要があり、アプリのアップデートが必要です。すでにインストールされているアプリへのユニバーサルリンクとAndroidアプリリンクについては、DNSとAASA/assetlinks.jsonファイルが設置されれば、アプリのアップデートは不要です - OSはアプリバイナリではなくサーバーからこれらのファイルをクエリします。例外: Info.plist / AndroidManifest.xmlがまだ新しいドメインを関連ドメインとして宣言していない場合、アプリのアップデートが必要です。

移行完了後、古いFDLリンクへのクリックはどうなりますか?

古いリンクがpage.linkドメインにある場合: 何も起きません - そのドメインは死んでおり、それらのリンクは回復不可能です。FDLにカスタムドメインを使用していた場合(一般的ではありませんがサポートされていました)、ドメインのCNAMEをElidoに向け直し、同等のルーティングルールを設定してください。古いURLが再び解決するようになります。

ElidoにSDKはありますか?

ElidoはユニバーサルリンクやアプリリンクにSDKを必要としません - それらはOS固有のメカニズムです。遅延ディープリンククエリエンドポイントには標準のHTTPS呼び出しを行います。SDKの依存関係は不要です。型付きクライアントが必要な場合、Elido Go SDK、TypeScript SDK、Python SDKはすべてディープリンクAPIをラップしていますが、iOS/Android SDKはなく、必要もありません。これは設計上の決定です - 本番アプリにサードパーティSDKが少ないほど良いです。

AASA / assetlinks.jsonの伝播にはどのくらいかかりますか?

DNSが伝播すると(TTLによって数分から1時間)、AASAとassetlinks.jsonファイルはElidoのエッジからすぐに利用できます。iOSはアプリインストール時とその後定期的にAASAファイルのキャッシュコピーを更新します。テスト中に気づく遅延はElidoの配信レイテンシではなく、iOSのキャッシュの古さです。クリーンなテストのために、DNS変更が伝播した後にアプリを新規インストールしてください。

---

広範なディープリンク機能セットを検討している場合、/features/deep-linksページにプラットフォームサポートマトリクスとルーティングルールの深さが記載されています。EUユーザーデータを収集するモバイルアプリに関連するEUデータレジデンシーの詳細については、コンプライアンス概要にプライバシーチームが求めるDPAとサブプロセッサーリストがあります。

ブログの関連記事

• SDKなしのディープリンク: ユニバーサルリンクとアプリリンクの実際の仕組み
• マーケティングツールのEUデータレジデンシー: DPOが実際に尋ねること
• スマートリンク解説: デバイス、ジオ、時間帯、リファラールーティング
• リンクを壊さずにBitlyから移行する: 失敗モードのプレイブック