はじめに
2025年8月25日以降、Firebase Dynamic Links（以下、FDL）が停止されますが、代替サービスへの移行はお進みでしょうか。
『NEWT（ニュート）』でも、いたるところで FDL を利用しており、代替サービスの導入だけでなく、既存リンクの置き換えについても検討が必要となったため、アプリエンジニアの hossy と、Web エンジニアの yamatsum で移行プロジェクトを発足しました。
一筋縄ではいきませんでしたが、ようやく移行の目処が立ってきたので、移行先・既存リンクの置き換えについて検討したプロセスをお伝えできればと思います。
FDL の利用箇所・ケースの調査
移行プロジェクトの第一歩として、FDL がどこで、どのように使われているかを調査しました。その結果、利用箇所は大きく 2つに分類でき、
- NEWT システムのソースコード内で管理されている箇所での利用
- Web のアプリ導線、システムメール内のリンク、アプリ内から招待リンクの発行など
- ソースコード内では管理されない箇所での利用
- セールの LP やマガジン記事、メルマガなど
といった状況だと分かりました。
前者は数も多くなくコードを修正するだけなので問題はなかったのですが、後者はFirebase Console 上で確認できるだけで約1,400のリンクと、パラメータを組み合わせて手動で作ったリンクが無数に存在したため、どこで使われてるかを洗い出すことが実質不可能でした。
そのため次のステップとして、代替サービスとなる移行先とFDL リンクの置き換え方法を並行して検討しはじめました。
代替サービスの検討
代替サービスの選定のため、まずは必要となる機能要件の洗い出しを行いました。
先述のとおり、既存の FDL すべての利用ケースを把握することは難しかったため、主要な既存リンクの確認および、社内で FDL を作成しているメンバーにヒアリングを行い、以下のとおり要件を定めました。
必須
- アプリの特定の画面へのディープリンク
- アプリストアへのリダイレクト
- パラメータを組み合わせた静的なリンク（Long Link）の生成
なるべく必要
- ディファードディープリンク
- 独自ドメインの付与
- アプリから動的に Short Link 生成
- リンクに OGP の指定
なくても OK
- リンクの分析
- クリックやアプリ起動は Google Analytics のイベントで計測する運用
これを元に、代替サービスの候補として、Firebase 公式で提示されていた以下から検討することにしました。（現在、Airbridge も追加されていますが、検討時に含まれてなかったので候補外）
- Adjust
- AppsFlyer
- Bitly
- Branch
- Kochava
サービスの決定
結果として、 AppsFlyer の OneLink に移行 することを決めました。
調査した結果、概ねどのサービスでも要件を満たす (全てを満たさないサービスもあり) ことができそうなことが分かり、最後はコスト面から決定しました。
AppsFlyer は、今回の要件であるクロスプラットフォームなリンクとしての利用であれば、無償の範囲で利用できそうであり、アトリビューションや MAU などで従量課金となる他サービスと比較して機能的にも十分でした。
（コストは弊社調査によるものなので、実際には各サービスにお問い合わせください）
アプリの OneLink サポート
アプリで OneLink からディープリンクできるように、 AppsFlyer SDK を導入しました。
今回は、AppsFlyer の計測機能を利用しないため、アプリではやることはそれほど多くなく、開発ドキュメントに沿って、以下の対応をする程度でした。
- OneLink からアプリを起動し、ディープリンクできるようにする
- アプリから招待用のリンクを OneLink に置き換える
- カスタムドメインの設定
また、アプリが OneLink をサポートしたとしても、既存 FDL リンクの OneLink 置き換えまでに間が空きそうだったため、以下のようなステップで慎重に対応を進めました。
- アプリで OneLink をサポートしつつ、FDL のサポートも残すよう実装
- アプリリリース後、強制アップデートによって、OneLink をサポートしたアプリの浸透を促進
- 一部リンクを OneLink で作成・運用することで、アプリ側で問題がないことを確認
- FDL から OneLink のリンクへの置き換えができる状態に
FDL から OneLink への移行
OneLink 運用の開始
OneLink への移行を進めている最中であっても、FDL の運用は続いており、置き換え対象のリンクが増え続けていました。そのため、移行の 1st ステップとして、社内での FDL での新規リンク発行を停止し、OneLink の運用を開始しました。
もともと FDL の運用が定まっていないことで管理しきれない状態になっていたこと、非エンジニアのメンバーも利用することをふまえ、OneLink については運用を整理・マニュアル化し、展開しました。
また、FDL 運用時に、「手動でリンクを作成したけど想定したとおりの動作にならない・・」という問い合わせが定期的にあったため、運用上必要となる OneLink のパラメータの説明等、リンク作成も明確化しています。
リダイレクトプロキシでの既存リンクの置き換え
先述のとおり、既存の FDL を使用している箇所を把握することが難しく、CMS で作成した大量ページなどでも使用されているケースがあり、実際に使われている箇所で 1つずつ手動で置き換えるのは現実的ではありませんでした。
そこで、以下の対応をすることで、FDL のリンクの URL にアクセスした時、OneLink の URL にリダイレクトさせるプロキシを構築し、自動的に FDL → OneLink の置換させることを考えました。
- FDL のパラメータから OneLink のパラメータに変換しつつリダイレクトするプロキシを構築
- FDL で元々使用していたカスタムドメインをプロキシに付け替える
このためにはまず、FDL で設定されていた各リンクごとのメタデータを export して、FDL のメタデータに対応する OneLink のパラメータをマッピングする必要があります。
パラメータのマッピングは OneLink の「Firebase Dynamic LinksからAppsFlyerへの移行」ドキュメントを参考にしました。
この時に例外として2二つの問題が発生しました。
- OneLink はデスクトップで開いたときのリダイレクト先を常に指定する必要がある
- リダイレクト時に不要な他のパラメータを引き継いでしまう
前者は、FDL がデフォルトで、ディープリンク先のパラメータである link の URL がデスクトップのリダイレクトに使われる仕様であったためで、OneLink ではこれを明示的に指定する必要がありました。これは、デスクトップユーザーを Web ページにリダイレクトさせるためのパラメータである af_web_dp を付与することで解決しました。
後者については、計測用のパラメータをリダイレクトされたページに転送するためのパラメータである af_param_forwarding を false にすることで解決しました。（計測用途で OneLink を使用しないため、転送不要として判断）
以上の対応で、リダイレクトのためのプロキシと OneLink によって、FDL と同様の挙動を実現することができました。本記事執筆時点では、まだプロキシの運用は始めておりませんが、運用後記事をアップデート予定です。
まとめ
以上、NEWT における、FDL から OneLink への移行プロセスについてでした。
移行プロジェクト開始当初、現行 FDL の運用がさっぱり分からず何から手をつけたらよいか分からず途方に暮れましたが、社内ヒアリングなどを通じて、一つずつ紐解いていくことでなんとか移行の目処を立てることができました。
既存リンクの置換については、リダイレクトプロキシの構築によって実施の目処が立ったのが大きかったです。
プロダクトの既存の FDL の運用や利用状況によって、最適な代替サービスや移行方法はさまざまかと思いますが、本記事が移行の参考になれば幸いです。
また、この記事を読んで会社やプロダクトについて興味を持ってくれた方は、ぜひご連絡お待ちしています！
フランクに話だけでも聞きたいという方は、カジュアル面談も実施できますので、お気軽にお声がけください！
令和トラベルのTech Blogです。 「あたらしい旅行を、デザインする。」をミッションに、海外旅行におけるあたらしい体験や、あたらしい社会価値の提供を目指すデジタルトラベルエージェンシーです。海外ツアー・ホテル予約アプリ「NEWT（ニュート）」を提供しています。（NEWT：newt.net/）
Discussion