独自調査
Instagram と TikTok の中で開かれたアプリのリンクに何が起きているか：74,000 件のリダイレクトを計測
誰も見ないプリロード、ストアを拒否する TikTok の WebView、ページの上に開く App Store：リダイレクトログが示していること。
公開日 · Adrien De Coster
結論
30 日間にアプリ内ブラウザから来た 74,713 件の Android アクセスのうち、9.1% は Instagram や Facebook がバックグラウンドで読み込み、約 30 秒後に誰にも見られないまま破棄したページでした。Android の TikTok 内では、Play Store が開くかどうかは TikTok が使う WebView で決まります。ある user-agent 形式は 85% のセッションでストアに到達し、他の二つの形式は同じリンク・同じ日でも 12–14% にとどまりました。iOS では Instagram と Facebook が App Store をアプリ内ブラウザの上に開くため、ページがバックグラウンドに回ることはなく、ページ側で測ったストア起動率はハンドオフが成功していても 13–56% と出ます。
ここでの数字は、スマートリンクサービスのリダイレクトログから得たものです。スマートリンクとは、スマートフォンを App Store または Google Play に送る URL のことです。SNS アプリの中でリンクが開かれるたびに、訪問者をストアへ引き渡す小さなページを返し、そのページがその後に起きたことを報告します。以下は、その報告からわかったこと、計測の方法、そして計測の限界です。
データ
| 期間 | 対象 | 件数 |
|---|---|---|
| 2026-10-12 までの 30 日間 | アプリ内ブラウザからの Android アクセス、セッション単位で再構成 | 74,713 |
| 2026-09-27 → 2026-10-26 | アプリ内でのページ読み込み、全プラットフォーム | 109,253 |
| 2026-10-20 → 2026-10-26 | 同上、ファネル表のためにセッションへ再構成 | 30,535 |
| 2026-10-16 → 2026-10-26 | ページ自身が分類したプリロード | 1,679 |
| 2026-10-15 までの 90 日間、その後 2026-10-26 までの 30 日間 | Android の TikTok、WebView 形式別のセッション | 73 + 1,247 |
| アプリ内ブラウザ | Android | iOS |
|---|---|---|
| 50,161 | 16,675 | |
| 27,911 | 9,441 | |
| TikTok | 3,755 | 1,219 |
| 通常のブラウザ（単純な 302、比較用） | 24,185 | 24,627 |
分析の前から二つのことが目立ちます。Meta のアプリは TikTok よりはるかに多くのトラフィックを送っていること。そして Android では、全アクセスの四分の三以上が Chrome ではなくアプリ内ブラウザ経由だということです。
ページはどうやって結果を報告するか
アプリ内ブラウザでリンクが開かれると、ページは三つの動作を行い、それぞれについてビーコンを送ります。
auto：読み込みと同時にストアへのハンドオフを開始する（iOS：App Store の URL へlocation.replace。Android：ネイティブの Play Store アプリを開くintent://URL）。exit：ページが非表示になる（Page Visibility API）。何か、おそらくストアが画面を引き継いだことを示す、Web ページが得られる最良のシグナルです。stuck：ハンドオフから 2.2 秒たってもページが表示されたままなので、ストアボタン、「ブラウザで開く」の案内、リンクのコピーボタンを備えたフォールバックカードを表示する。
Web ページからは App Store も Play Store も見えません。以下はすべてこの三つのシグナルからの推定であり、その推定がどこで崩れるかは「限界」の節に書いています。
発見 1：Meta からの Android アクセスの約 11 件に 1 件は、誰も見ていないプリロード
十月12日までの 30 日間、ある Android セッションの群は人間の訪問ではありえない振る舞いをしていました。ページは読み込まれ、ハンドオフのタイマーは一度も動かず、29 〜 31 秒後にページが破棄される。auto も stuck もタップもない。iOS には同様のものは見られませんでした。
これは、Instagram と Facebook のアプリ内ブラウザがフィード上のリンクを先読みし、非表示のまま保持し、ユーザーがスクロールして通り過ぎると捨てる、という挙動の特徴です。ページは私たちの JavaScript を実行したのでアクセスは記録されましたが、誰もそれを見ていません。
| 対象 | アクセス | プリロード | 割合 |
|---|---|---|---|
| 全アクセス、全プラットフォーム | 139,199 | 6,790 | 4.9% |
| Android | 95,648 | 6,790 | 7.1% |
| Android のアプリ内 | 74,713 | 6,790 | 9.1% |
| Android のアプリ内、最大のリンクを除く | — | — | 4.9% |
| 最も影響を受けたリンク | 35,337 | 4,864 | 13.8% |
この基準を明らかに人間によるセッションと照合しました。ハンドオフの 2–3 s 後にストアが開いたセッションでは 17,606 件中 0 件、ストアボタンがタップされたセッションでは 244 件中 0 件 が該当しました。
この割合は週ごとに変動します。期間の最終週は 6.8%、その前の週は 8.8%、10.6%、10.0% でした。また、Instagram の有料キャンペーンが走っているところに集中します。期間中のプリロードの 72% は、大規模な Instagram キャンペーンを抱える一本のリンクから来ていました。
十月16日以降は、ページ自身が実行時にこれを分類しています。一度も表示されないまま少なくとも 20 s 後に破棄されたとき、exit の代わりにプリロードを報告します。それ以降に捕捉した結果は次のとおりです。
| アプリ内ブラウザ | ページ読み込み | プリロード | 割合 |
|---|---|---|---|
| Instagram、Android | 15,100 | 1,152 | 7.6% |
| Facebook、Android | 19,830 | 477 | 2.4% |
| TikTok、Android | 3,648 | 1 | 0.03% |
| Instagram、iOS | 5,965 | 45 | 0.8% |
| Facebook、iOS | 6,134 | 4 | 0.07% |
この実行時の件数は下限値です。スクリプトを一切実行せずに破棄されたプリロードはビーコンを残さず、実行時のルールは過去データの再構成より厳しくなっています。
なぜ重要か。 リダイレクトでクリックを数えているなら、Instagram Android の「クリック」のおよそ 13 回に一回は人の目に触れていません。そのチャネルのクリックからインストールへの比率は実際より悪く見え、生のリダイレクト数で作ったキャンペーンダッシュボードはリーチをほぼその分だけ過大に示します。
発見 2：TikTok は使う WebView によって Play Store を拒否する
Android の TikTok 内では、一部の訪問者がページから出られません。ハンドオフは発火するものの、TikTok が独自のダイアログ（「The action cannot be completed」＝「この操作は完了できません」）を表示するのです。すべてのリンクで起きるわけではなく、何週間もリンク次第に見えていました。しかし実際はそうではありません。TikTok がその訪問者に使うアプリ内ブラウザ次第であり、それは user-agent からわかります。
| 形式 | user-agent の形 |
|---|---|
| A | … Chrome/151 Mobile Safari/537.36 musical_ly_46.8.3 |
| B | Version/4.0 … musical_ly_2024509000 JsSdk/1.0 … BytedanceWebview |
| C | Version/4.0 … musical_ly_2024701040 AppName/musical_ly ByteLocale/… |
ハンドオフが発火してページが非表示になったセッションを成功、フォールバックカードが表示されたセッションを失敗とします。率は 成功 /（成功 + 失敗）で、端末・日ごとに集計しています。
| 形式 | 2026-10-15 までの 90 日間 | 30 日間、2026-09-27 → 10-26 |
|---|---|---|
| A | 23 / 26 (88%) | 827 / 969 (85%) |
| B | 0 / 17 (0%) | 34 / 245 (14%) |
| C | 5 / 30 (17%) | 4 / 33 (12%) |
決め手になる比較は、形式の構成比が週ごとに変わるため、リンクと日を固定したものです。
| リンク | 形式 A | 形式 B |
|---|---|---|
| リンク 1 | 560 / 674 (83%) | 32 / 192 (17%) |
| リンク 2 | 257 / 285 (90%) | 2 / 47 (4%) |
同じリンク、同じリダイレクトのコード、同じ日でも、ある WebView ではストアが開き、別の WebView ではほとんど開きません。90 日間のデータでは、カスタムドメインの有無による差はありませんでした。TikTok はこのダイアログについても、何が引き金になるのかも、どのユーザーにどの WebView が割り当てられるのかも公開していないので、user-agent による分類が手がかりのすべてです。
なぜ重要か。 URL の形式を変えても解決しません。intent:// による脱出も、普通の https://play.google.com の URL も同じように拒否されます。できるのは出口を隠さないことです。TikTok 内では、タイムアウトを待たずに「ブラウザで開く」の手順とコピーボタンをすぐに表示しましょう。
発見 3：iOS では App Store がアプリ内ブラウザの上に開く
Android ではハンドオフの後、ほとんどのセッションでページが非表示になり、通常は 1 〜 3 秒後です。iOS の Instagram と Facebook の中では、ほぼすべてのセッションでハンドオフが発火しているにもかかわらず、多くの場合そうなりません。
| アプリ内ブラウザ | ページ読み込み | ハンドオフ発火 | 非表示になった | …4 s 以内 | 2.2 s で表示中 |
|---|---|---|---|---|---|
| Instagram、Android | 7,190 | 77.5% | 90.0% | 75.9% | 47.6% |
| Facebook、Android | 13,600 | 72.4% | 73.8% | 39.6% | 77.8% |
| TikTok、Android | 2,920 | 47.1% | 85.2% | 79.5% | 7.6% |
| Instagram、iOS | 2,881 | 94.6% | 55.9% | 41.7% | 64.2% |
| Facebook、iOS | 3,078 | 87.0% | 13.1% | 7.9% | 65.6% |
| TikTok、iOS | 866 | 93.8% | 50.5% | 23.8% | 75.2% |
もし iOS の訪問者の三分の二が「App Store を開く」ボタン付きのフォールバックカードの前で本当に立ち往生しているなら、かなりの人がタップするはずです。ところが実際には、iOS の Instagram のページ読み込みの 0.9%、iOS の Facebook の読み込みの 0.4% しかボタンをタップしていません。また、「うまくいく」iOS のバージョンもありません。
| iOS メジャーバージョン | ハンドオフのあったセッション | ページが非表示になった |
|---|---|---|
| 16 | 127 | 24.4% |
| 17 | 106 | 33.0% |
| 18 | 958 | 33.3% |
| 26 | 3,711 | 39.3% |
| 27 | 1,249 | 34.3% |
データに合う説明は、iOS の Instagram と Facebook の中では、App Store がアプリ内ブラウザをバックグラウンドに送らずにその上に表示される、というものです。ページはその間ずっと「表示中」のままなので、訪問者が App Store を見ていても visibilitychange も pagehide も発火しません。
なぜ重要か。 ページが画面から消えたことでストアの起動を推定する指標は、iOS ではすべて誤りです。私たちはまさにその方法で算出した「ストア到達率」を顧客に表示していましたが、それは有料顧客 12 社中 10 社に対し、正常に動いているリンクが壊れていると伝えていました。そこで削除しました。iOS で信頼できるインストールのシグナルはストア側にあります。App Store の URL に provider token（pt）と campaign token（ct）を付けた、App Store Connect のキャンペーンレポートです。
その過程で計測した細かな事実
- Android では Play Store の表示が遅い。 ハンドオフが発火した Instagram Android のセッションで、アクセスから 0–1 s 後にページが非表示になったのは 1,061 件、2–3 s 後は 2,596 件、4–8 s 後は 1,273 件でした（7 日間）。2 秒の「成功したか？」タイマーは、実際に成功したケースの多くでストアが現れる前に発火します。私たち自身のファネルも、ハンドオフ後 8 s までの遅い exit を数えるようにするまで、それらを失敗として数えていました。
- 本当の失敗率は小さい。 十月上旬の 3 日間で再構成した 7,357 件の Instagram Android セッションのうち、「ハンドオフの後に何も起きない」パターンは 1.9% で、その訪問者の 24.3% は 3 分以内にリンクを再タップしました。フォールバックカードが表示されたセッションの訪問者の再タップ率は 5.4% で、ストアが開いた訪問者（4.6%）とほぼ同じでした。つまり、そうした「失敗」の大半は失敗ではなかったのです。
- タップを必須にするとトラフィックの大半を失う。 ページが読み込み時にハンドオフを始めるようになる前は、ストアボタン付きのカードを表示していました。30 日間で、アプリ内からの 10,523 件のアクセスから生まれたタップは 2,119 件。訪問者の約 80% はストアにたどり着けませんでした。
手法
- データソース。 スマートリンクへのすべてのアクセスと、ハンドオフページからのすべてのビーコンは、プラットフォーム、アプリ内ブラウザ（user-agent から判定）、イベント種別、秒単位のタイムスタンプとともに Cloudflare Workers Analytics Engine に書き込まれます。user-agent でボット、クローラー、リンクプレビューの取得元であると名乗る訪問者は分けて扱い、ここでの数字からはすべて除外しています。
- セッション。 Analytics Engine にはページ読み込みの ID がないため、アクセスと、その後一時間以内にリンク・国・都市・user-agent・アプリ内ブラウザが一致するビーコンを、同じキーの次のアクセスまで結び付けてセッションを再構成しています。ビーコンの約 98% がいずれかのアクセスに結び付きます。
- プリロード（発見 1）。 過去データの基準：ハンドオフなし、フォールバックカードなし、タップなし、かつアクセスから 20 s 〜 15 分後に exit。2026-10-16 以降の実行時の基準：一度も表示されないまま少なくとも 20 s 後に破棄され、ハンドオフのタイマーが一度も動かなかった（または非表示で読み込まれた）場合に、ページがプリロードを報告します。ビーコンには使い捨ての署名付きトークンが付くため、再送して実際の訪問を消すことはできません。
- TikTok（発見 2）。 セッションはリンク、端末モデル、TikTok アプリのバージョン、日をキーとしています。形式の判定ルール：ドット区切りの
musical_ly_バージョン → A、そうでなくJsSdkがあれば → B、それ以外は C。ホスティング事業者のネットワークからの訪問者は別に数え、表からは除いています。30 日間の再計測には、最初の 90 日間の分析と同じスクリプトを使っています。 - 合計値 は Analytics Engine のサンプリング間隔を考慮しています（行の 2–4% は複数のイベントを表します）。セッションの表は行数を数えています。
限界
- ストアそのものは見えていない。 「非表示になった」は「ストアが開いた」の代理指標です。訪問者がアプリを切り替えたり端末をロックしたりした場合にも発火します。
- タイムスタンプは秒単位 で、セッションは再構成したものです。同じ端末からの短時間の連続読み込みは一つにまとまることがあります。
- 集中。 一部の期間はいくつかの大きなリンクが大半を占めます。30 日間のプリロードの 72% は一つの Instagram キャンペーンによるもので、TikTok のセッションの大半は二本のリンクに集中しています。同一リンクでの表はそのために用意しています。
- 実機での確認は一切していない。 挙動はページからの報告に基づく推定です。発見 3 の iOS についての説明はデータに合う説明であって、実際に目で確かめたものではありません。
- トラフィックは私たちのもの。 対象は私たちのリンクを使うアプリの訪問者で、少数の国での Instagram と Facebook のキャンペーンに大きく偏っています。構成が違えば割合も変わりますが、仕組みは同じはずです。
- JavaScript を一度も実行しないプリロードは見えない。 Android の Instagram のページ読み込みの 12% はビーコンを一切送っておらず、その一部もおそらくプリロードです。
どうすべきか
- 読み込み時にハンドオフを開始する。 タップを待つページは、アプリ内からの訪問者の大半を失います。手動ボタンはフォールバックとして残し、ハンドオフが明らかに失敗したときだけ表示しましょう。
- Android では `intent://` と `S.browser_fallback_url` を使う。 WebView 内の
https://play.google.comの URL は Play Store の Web サイトを開くだけで、ログインしなければ何もインストールできません。 - 遅いストアには時間を与える。 ハンドオフが失敗したと判断する前に少なくとも 3 s 待ち、遅れて来た exit も数えましょう。
- TikTok 内では出口をすぐに見せる： 「··· → ブラウザで開く」とリンクのコピーボタン。URL をどう変えても TikTok の拒否はなくなりません。
- Meta のプリロードをクリックとして数えない。 リダイレクトからクリックを報告するなら、Android の Instagram と Facebook からのアクセスの 2–9% は誰も見ていないページだと考えてください。
- インストールはストア側で計測する。 ページのイベントではなく、iOS では App Store Connect のキャンペーンリンク（
pt+ct）、Android では Play Install Referrer を使いましょう。
私たちが開発している onestore.link は、この六つすべてをすべてのリンクにデフォルトで適用しており、上記のデータはそのリダイレクトログから得たものです。
よくある質問
Android の Instagram のリンククリックのうち、プリロードは何パーセント？
2026-10-12 までの 30 日間で、アプリ内ブラウザ（Instagram と Facebook）からの Android アクセスの 9.1% は、アプリがバックグラウンドで読み込み、約 30 秒後に誰にも見られないまま破棄したページでした。2026-10-16 以降、ページ自身の実行時チェックは下限値として Instagram Android で 7.6%、Facebook Android で 2.4% を捕捉しています。iOS では 1% 未満です。
TikTok のアプリ内ブラウザから Play Store が開かないのはなぜ？
Android の TikTok アプリは複数のアプリ内ブラウザを使っています。そのうちの一つ（ドット区切りの musical_ly_ バージョンがあり、user-agent に Version/4.0 がないもの）では、30 日間で 85% のセッションが Play Store に到達しました。他の二つ（Version/4.0 と JsSdk/BytedanceWebview、または AppName/musical_ly を含むもの）では、同じリンク・同じ日でも 12–14% にとどまりました。URL の形式に関係なく、TikTok 自身がハンドオフを拒否しています。
iOS で App Store が開いたことを Web ページから判断できる？
Instagram や Facebook の中ではできません。App Store はアプリ内ブラウザの上に開くため、ページが非表示になることはなく、visibilitychange も発火しません。7 日間で、iOS のハンドオフのうちページが非表示になったのは 13%（Facebook）から 56%（Instagram）にすぎず、フォールバックボタンをタップした訪問者は 1% 未満でした。信頼できるシグナルは App Store Connect のキャンペーンレポートです。
アプリ内ブラウザから Play Store が開くまでにどれくらいかかる？
Android では、成功したセッションの大半でハンドオフの 2–3 秒後にページが非表示になり、遅い端末では 8 秒後までかかります。2 秒後に表示するフォールバックは、成功しかけていた多くのセッションでストアより先に現れてしまいます。
Instagram の中でアプリストアへのリダイレクトが本当に失敗する頻度は？
再構成した 7,357 件の Instagram Android セッションでは、本当の失敗のパターン（ハンドオフが発火した後に何も起きず、訪問者がリンクを再タップする）は 1.9% でした。生のファネルデータに見える失敗の大半は、ビーコンの欠落、遅いストア、プリロードといった計測上のアーティファクトです。
カスタムドメインを使うと TikTok でのリンクの扱いは変わる？
変わりません。90 日間で、カスタムドメインのあるリンクもないリンクも同じように拒否されました。決め手は、TikTok がその訪問者に使うアプリ内ブラウザです。