アプリは入っている。それでもリンクはWebサイトを開く。

まずアプリ、次にストア、最後にWeb

モバイルリンクは、プラットフォームごとに3つの答えを持ちます。アプリを開くアドレス、フォールバック先のストアの掲載ページ、そしてそれ以外のすべてに向けたWebページです。リダイレクトは、あなたが決めた待ち時間を挟みながらこの順に試します。アプリが入っているかどうかを確かめる唯一の確実な方法は、開こうとしてみて、その後もページがまだそこにあるかを見ることだからです。

AppleもGoogleも、目に見える中間ページなしにドメインからアプリを直接開ける、検証済みの関連付けファイルに対応しています。プラットフォームはそのファイルをあなたのリダイレクトドメインから配信し、内容の種別が違う、パスが違う、フィンガープリントがないといった問題を診断します。関連付けファイルの打ち間違いは黙って失敗し、誰もがリンクのせいにするからです。

• ✓プラットフォームごとのアプリスキームまたはユニバーサルリンク
• ✓iOSとAndroid向けのストアフォールバック
• ✓デスクトップと非対応プラットフォーム向けのWebフォールバック
• ✓あなた自身のドメインで配信し、診断まで行う関連付けファイル
• ✓設定できる試行の待ち時間
• ✓タブレットに対する明示的な挙動

難しいのはアプリ内ブラウザー、だから明示的に扱う

モバイルのトラフィックの多くは、別のアプリのブラウザーの中から届きます。SNSのフィード、メッセンジャー、メールクライアントなどです。そうした環境はアプリを開こうとする試みを一貫しない形で妨げるので、Safariでは正しく動くリンクが、フィードの中ではまったく何も起こさないことがあります。

そのためアプリ内ブラウザーの扱いは、偶然任せではなく設定です。それでもアプリを試す、Webページへ直行する、あるいはシステムのブラウザーで開くよう短い案内を表示する、から選べます。挙動はリンクごとに決められ、プラットフォームは主要なアプリ内ブラウザーを、普通のブラウザーのふりをさせずに認識します。

文脈はインストールを越えて生き残る

ある人が特定の商品へのリンクをタップし、アプリを持っていなかったのでインストールし——たどり着いたのは汎用のホーム画面。遅延ディープリンクの文脈は、まさにこれを解決します。キャンペーンと目的地が保持され、初回起動時にアプリへ引き渡されるので、その人はアプリの既定の場所ではなく、リンクが指していた場所に着きます。

この文脈は、個人を特定するものではなくデバイスのシグネチャで突き合わせられ、短時間で失効します。存在する目的は、1回のインストールを橋渡しすることであって、プロファイルを作ることではありません。

ブランドもあなたのまま、分析もあなたのまま

中間ページは——そもそも必要になったときだけですが——ドメインに紐づいたロゴ、色、サポート用アドレスを使ってエッジが描画します。土台になっているプラットフォームへの言及はなく、経路に第三者のホストも入りません。

クリックは、アプリを開こうとする試みの前、リダイレクトが起きた時点で記録されます。訪問は実際に起きたのであり、その後デバイスが何をしたかは外からは観測できません。これによってクリック数は正直に保たれ、モバイルのトラフィックを黙って少なく報告することがなくなります。