מחקר מקורי

מה קורה לקישור לאפליקציה שנפתח בתוך Instagram ו-TikTok: מדדנו 74,000 הפניות

טעינות מוקדמות שאף אחד לא רואה, webview של TikTok שמסרב לפתוח את החנות, ו-App Store שנפתח מעל הדף: מה שיומני ההפניות שלנו מראים.

פורסם ב-2026-10-27 · Adrien De Coster

התשובה הקצרה

מתוך 74,713 כניסות ב-Android מדפדפנים בתוך אפליקציות במשך 30 יום, 9.1% היו דפים ש-Instagram או Facebook טענו ברקע וזרקו כ-30 שניות מאוחר יותר בלי שאיש ראה אותם. בתוך TikTok ב-Android, השאלה אם Play Store נפתח תלויה ב-webview ש-TikTok משתמש בו: פורמט User-Agent אחד הגיע לחנות ב-85% מהסשנים, ושניים אחרים ב-12–14%, על אותם קישורים ובאותם ימים. ב-iOS, Instagram ו-Facebook פותחים את App Store מעל הדפדפן הפנימי, כך שהדף אף פעם לא עובר לרקע, ושיעור פתיחת החנות שנמדד מתוך הדף עומד על 13–56% גם כשההעברה עבדה.

המספרים האלה מגיעים מיומני ההפניות של שירות קישורים חכמים: כתובת אחת ששולחת טלפון ל-App Store או ל-Google Play. בכל פעם שקישור נפתח בתוך אפליקציה חברתית, אנחנו מגישים דף קטן שמעביר את המבקר לחנות, והדף הזה מדווח מה קרה אחר כך. להלן מה הדיווחים האלה אומרים, איך מדדנו אותם, ואיפה המדידה נעצרת.

הנתונים

חלון זמן	מה	היקף
30 יום עד 2026-10-12	כניסות 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
90 יום עד 2026-10-15, ואז 30 יום עד 2026-10-26	TikTok ב-Android, סשנים לפי פורמט ה-webview	73 + 1,247

טעינות דף בתוך אפליקציות, 30 יום עד 2026-10-26
דפדפן בתוך אפליקציה	Android	iOS
Instagram	50,161	16,675
Facebook	27,911	9,441
TikTok	3,755	1,219
דפדפן רגיל (302 פשוט, להשוואה)	24,185	24,627

שני דברים בולטים עוד לפני כל ניתוח. האפליקציות של Meta שולחות הרבה יותר תנועה מ-TikTok. וב-Android, יותר משלושה רבעים מכל הכניסות מגיעות דרך דפדפן בתוך אפליקציה, לא דרך Chrome.

איך הדף מדווח מה קרה

כשקישור נפתח בתוך דפדפן של אפליקציה, הדף עושה שלושה דברים ושולח beacon על כל אחד מהם:

auto: הוא מתחיל את ההעברה לחנות בזמן הטעינה (iOS: location.replace לכתובת ה-App Store; Android: כתובת intent:// שפותחת את אפליקציית Play Store המקורית).
exit: הדף הופך למוסתר (Page Visibility API). זה האות הטוב ביותר שיש לדף אינטרנט לכך שמשהו, כנראה החנות, השתלט על המסך.
stuck: הדף עדיין גלוי 2.2 שניות אחרי ההעברה, ולכן הוא חושף כרטיס גיבוי עם כפתור לחנות, רמז “פתחו בדפדפן שלכם” וכפתור להעתקת הקישור.

דף אינטרנט לא יכול לראות את App Store או את Play Store. כל מה שבהמשך מוסק משלושת האותות האלה, ופרק המגבלות מסביר איפה ההסקה הזאת נשברת.

ממצא 1: בערך 1 מכל 11 כניסות Android מ-Meta הוא טעינה מוקדמת שאף אחד לא ראה

במשך 30 הימים עד 12 באוקטובר, קבוצה ברורה של סשנים ב-Android התנהגה כפי ששום ביקור אנושי לא יכול: הדף נטען, טיימר ההעברה מעולם לא רץ, והדף הושמד 29 עד 31 שניות לאחר מכן. בלי auto, בלי stuck, בלי הקשה. ב-iOS לא נראה שום דבר דומה.

זו החתימה של הדפדפן הפנימי של Instagram ו-Facebook שטוען מראש קישור שנמצא בפיד, שומר אותו מוסתר וזורק אותו כשהמשתמש ממשיך לגלול. הדף הריץ את ה-JavaScript שלנו, ולכן הכניסה נרשמה. אף אחד מעולם לא הסתכל עליה.

30 יום עד 2026-10-12
אוכלוסייה	כניסות	טעינות מוקדמות	שיעור
כל הכניסות, כל הפלטפורמות	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%

בדקנו את הקריטריון מול סשנים שהיו אנושיים בבירור: 0 מתוך 17,606 סשנים שבהם החנות נפתחה 2–3 שניות אחרי ההעברה תאמו לו, ו-0 מתוך 244 סשנים שבהם מישהו הקיש על כפתור החנות תאמו לו.

השיעור משתנה משבוע לשבוע: 6.8% בשבוע האחרון של החלון, ואז 8.8%, 10.6% ו-10.0% בשבועות שלפניו. הוא גם מתרכז במקומות שבהם רצים קמפיינים ממומנים של Instagram: 72% מהטעינות המוקדמות בחלון הגיעו מקישור אחד שמאחוריו קמפיין Instagram גדול.

מאז 16 באוקטובר, הדף מסווג זאת בעצמו בזמן ריצה: הוא מדווח על טעינה מוקדמת במקום על יציאה כשהוא מת אחרי 20 שניות לפחות בלי שהוצג אף פעם. זה מה שהוא תפס מאז:

2026-10-16 → 2026-10-26
דפדפן בתוך אפליקציה	טעינות דף	טעינות מוקדמות	שיעור
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%

הספירה בזמן ריצה היא רצפה. טעינה מוקדמת שמתה בלי להריץ שום סקריפט לא משאירה beacon, וכלל זמן הריצה מחמיר יותר מהשחזור ההיסטורי.

למה זה חשוב. אם אתם סופרים קליקים בנקודת ההפניה, בערך “קליק” אחד מכל 13 של Instagram ב-Android לא נראה מעולם על ידי אדם. יחס הקליקים להתקנות שלכם בערוץ הזה נראה גרוע ממה שהוא באמת, ולוח בקרה של קמפיינים שנבנה על כניסות הפניה גולמיות מגזים בחשיפה בערך באותו שיעור.

ממצא 2: TikTok מסרב לפתוח את Play Store בהתאם ל-webview שהוא משתמש בו

בתוך TikTok ב-Android, חלק מהמבקרים אף פעם לא עוזבים את הדף: ההעברה יוצאת לדרך ו-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/…`

סשן נספר כהצלחה כשההעברה יצאה לדרך והדף הפך למוסתר, וככישלון כשכרטיס הגיבוי נחשף. השיעור הוא הצלחה / (הצלחה + כישלון), לפי מכשיר ויום:

פורמט	90 יום עד 2026-10-15	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%)

ההשוואה שמכריעה את השאלה מקבעת את הקישור ואת היום, כי תמהיל הפורמטים משתנה משבוע לשבוע:

אותו קישור, אותם ימים (30 יום)
קישור	פורמט A	פורמט B
קישור 1	560 / 674 (83%)	32 / 192 (17%)
קישור 2	257 / 285 (90%)	2 / 47 (4%)

אותו קישור, אותו קוד הפניה, אותו יום: webview אחד מאפשר לחנות להיפתח והשני ברוב המקרים לא. דומיינים מותאמים אישית לא שינו דבר בנתוני 90 הימים. TikTok לא מתעד את החלון, מה מפעיל אותו, או איזה משתמש מקבל איזה webview, כך שהפיצול לפי User-Agent הוא כל מה שיש.

למה זה חשוב. שום צורת כתובת לא פותרת את זה: היציאה דרך intent:// וכתובת https://play.google.com רגילה מקבלות את אותו סירוב. מה שאפשר לעשות הוא לא להסתיר את הדרך החוצה: בתוך TikTok, הציגו מיד את ההוראות “לפתוח בדפדפן” וכפתור העתקה, במקום אחרי השהיה.

ממצא 3: ב-iOS, ה-App Store נפתח מעל הדפדפן הפנימי

ב-Android, אחרי ההעברה, הדף הופך למוסתר ברוב הסשנים, בדרך כלל 1 עד 3 שניות לאחר מכן. ב-iOS בתוך Instagram ו-Facebook זה לרוב לא קורה, אף שההעברה יצאה לדרך כמעט בכל סשן:

7 ימים, 2026-10-20 → 10-26. העמודות שאחרי “ההעברה יצאה לדרך” הן שיעורים מתוך הסשנים שבהם היא יצאה; סשן יכול להיות עדיין גלוי ב-2.2 שניות ולהפוך למוסתר מאוחר יותר.
דפדפן בתוך אפליקציה	טעינות דף	ההעברה יצאה לדרך	הפך למוסתר	…תוך 4 שניות	גלוי ב-2.2 שניות
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”, רבים מהם היו מקישים עליו. הם לא: 0.9% מטעינות הדף של Instagram ב-iOS ו-0.4% מטעינות Facebook ב-iOS מקישים על הכפתור. וגם אין גרסת iOS שבה זה “עובד”:

שלוש האפליקציות, 7 ימים
גרסה ראשית של iOS	סשנים עם העברה	הדף הפך למוסתר
16	127	24.4%
17	106	33.0%
18	958	33.3%
26	3,711	39.3%
27	1,249	34.3%

ההסבר שמתאים לנתונים הוא שבתוך Instagram ו-Facebook ב-iOS, ה-App Store עולה מעל הדפדפן הפנימי בלי לשלוח אותו לרקע. הדף נשאר “גלוי” כל הזמן, ולכן visibilitychange ו-pagehide אף פעם לא נורים, למרות שהמבקר מסתכל על ה-App Store.

למה זה חשוב. כל מדד שמסיק פתיחת חנות מכך שהדף עזב את המסך שגוי ב-iOS. נהגנו להציג ללקוחות אחוז “הגעה לחנות” שנבנה בדיוק כך, והוא אמר ל-10 מתוך 12 לקוחות משלמים שקישורים שעבדו היו שבורים. הסרנו אותו. ב-iOS, אות ההתקנה האמין נמצא בצד של החנות: דוחות הקמפיינים של App Store Connect, עם provider token (pt) ו-campaign token (ct) בכתובת ה-App Store.

דברים קטנים יותר שמדדנו בדרך

Play Store איטי להופיע ב-Android. בסשנים של Instagram ב-Android שבהם ההעברה יצאה לדרך, הדף הפך למוסתר 0–1 שניות אחרי הכניסה ב-1,061 סשנים, 2–3 שניות אחרי ב-2,596, ו-4–8 שניות אחרי ב-1,273 (7 ימים). טיימר של 2 שניות ל“האם זה עבד?” נורה לפני שהחנות מופיעה בחלק גדול מההצלחות האמיתיות. המשפך שלנו ספר אותן ככישלונות עד שאפשרנו ליציאה עד 8 שניות אחרי ההעברה להיספר בכל זאת.
שיעור הכישלון האמיתי קטן. ב-7,357 סשנים של Instagram ב-Android ששוחזרו על פני 3 ימים בתחילת אוקטובר, הדפוס “העברה, ואז כלום” היה 1.9% מהסשנים, ו-24.3% מהמבקרים האלה הקישו שוב על הקישור תוך 3 דקות. מבקרים שבסשן שלהם הוצג כרטיס הגיבוי הקישו שוב בשיעור של 5.4%, בערך כמו מבקרים שהחנות שלהם נפתחה (4.6%): רוב ה“כישלונות” האלה לא היו כישלונות.
דרישה להקשה עולה ברוב התנועה. לפני שהדף התחיל את ההעברה בזמן הטעינה, הוא הציג כרטיס עם כפתור לחנות. במשך 30 יום, 10,523 כניסות בתוך אפליקציות הניבו 2,119 הקשות: כ-80% מהמבקרים מעולם לא הגיעו לחנות.

שיטה

מקור. כל כניסה לקישור חכם וכל beacon מדף ההעברה נכתבים ל-Cloudflare Workers Analytics Engine עם הפלטפורמה, הדפדפן הפנימי (מתוך ה-User-Agent), סוג האירוע וחותמת זמן ברזולוציה של שנייה. מבקרים שה-User-Agent שלהם מצהיר על בוט, סורק או כלי לתצוגה מקדימה של קישורים נשמרים בנפרד ומוחרגים מכל נתון כאן.
סשנים. ל-Analytics Engine אין מזהה טעינת דף, ולכן סשנים משוחזרים על ידי חיבור כניסה ל-beacons שחולקים איתה את הקישור, המדינה, העיר, ה-User-Agent והדפדפן הפנימי בשעה שאחריה, עד הכניסה הבאה עם אותו מפתח. כ-98% מה-beacons מתחברים לכניסה.
טעינות מוקדמות (ממצא 1). קריטריון היסטורי: בלי העברה, בלי כרטיס גיבוי, בלי הקשה, ויציאה 20 שניות עד 15 דקות אחרי הכניסה. קריטריון זמן ריצה מאז 2026-10-16: הדף מדווח על טעינה מוקדמת כשהוא מת אחרי 20 שניות לפחות בלי שהוצג אף פעם וטיימר ההעברה שלו מעולם לא רץ (או שהוא נטען מוסתר). ה-beacon נושא טוקן חתום לשימוש חד-פעמי, כך שאי אפשר לשלוח אותו שוב כדי למחוק ביקור אמיתי.
TikTok (ממצא 2). סשנים לפי מפתח של קישור, דגם מכשיר, גרסת אפליקציית TikTok ויום. כלל הפורמט: גרסת musical_ly_ עם נקודות → A; אחרת JsSdk → B; אחרת C. מבקרים מרשתות אירוח נספרים בנפרד ונשארים מחוץ לטבלה. המדידה החוזרת של 30 יום משתמשת באותו סקריפט כמו הניתוח המקורי של 90 יום.
סכומים משתמשים במרווח הדגימה של Analytics Engine (2–4% מהשורות מייצגות יותר מאירוע אחד). טבלאות הסשנים סופרות שורות.

מגבלות

אנחנו אף פעם לא רואים את החנות. “הפך למוסתר” הוא קירוב ל“החנות נפתחה”. הוא נורה גם כשהמבקר עובר לאפליקציה אחרת או נועל את הטלפון.
חותמות הזמן הן ברזולוציה של שנייה, והסשנים הם שחזורים. שתי טעינות מהירות מאותו מכשיר עלולות להתמזג.
ריכוזיות. כמה קישורים גדולים שולטים בחלק מהחלונות: קמפיין Instagram אחד אחראי ל-72% מהטעינות המוקדמות של 30 הימים, ושני קישורים נושאים את רוב הסשנים של TikTok. בגלל זה קיימות הטבלאות של אותו קישור.
שום דבר כאן לא נבדק בטלפון פיזי. ההתנהגויות מוסקות ממה שהדפים מדווחים. ההסבר ל-iOS בממצא 3 הוא זה שמתאים לנתונים, לא משהו שראינו קורה.
התנועה היא שלנו. אלה המבקרים של האפליקציות שמשתמשות בקישורים שלנו, עם משקל כבד לקמפיינים של Instagram ו-Facebook בקומץ מדינות. תמהיל אחר ייתן אחוזים אחרים, אם כי המנגנונים אמורים להיות זהים.
טעינות מוקדמות שאף פעם לא מריצות JavaScript בלתי נראות. 12% מטעינות הדף של Instagram ב-Android לא שולחות שום beacon, וחלק מהן כנראה גם הן טעינות מוקדמות.

מה לעשות עם זה

התחילו את ההעברה בזמן הטעינה. דף שמחכה להקשה מאבד את רוב המבקרים מתוך אפליקציות. השאירו את הכפתור הידני כגיבוי, שנחשף רק אם ההעברה נכשלה באופן נראה לעין.
ב-Android, השתמשו ב-`intent://` עם `S.browser_fallback_url`. כתובת https://play.google.com בתוך webview פותחת את אתר Play Store, שלא יכול להתקין שום דבר בלי התחברות.
תנו לחנות איטית זמן. חכו לפחות 3 שניות לפני שאתם מחליטים שההעברה נכשלה, ועדיין ספרו יציאה מאוחרת.
בתוך TikTok, הציגו את הדרך החוצה מיד: “··· → פתיחה בדפדפן” וכפתור להעתקת הקישור. שום שינוי בכתובת לא מעלים את הסירוב של TikTok.
אל תספרו טעינות מוקדמות של Meta כקליקים. אם אתם מדווחים על קליקים מתוך הפניה, צפו ש-2–9% מהכניסות של Instagram ו-Facebook ב-Android יהיו דפים שאף אחד לא ראה.
מדדו התקנות בחנות, עם קישורי קמפיין של App Store Connect (pt + ct) ב-iOS ו-Play Install Referrer ב-Android, לא עם אירועי דף.

אנחנו בונים את onestore.link, שעושה את כל השישה כברירת מחדל לכל קישור, והנתונים שלמעלה מגיעים מיומני ההפניות שלו.

שאלות ותשובות

איזה אחוז מהקליקים על קישורים ב-Instagram ב-Android הם טעינות מוקדמות?

במשך 30 יום עד 2026-10-12, 9.1% מכניסות Android מדפדפנים בתוך אפליקציות (Instagram ו-Facebook) היו דפים שהאפליקציה טענה ברקע וזרקה כ-30 שניות מאוחר יותר, בלי שנראו. מאז 2026-10-16, הבדיקה של הדף עצמו בזמן ריצה תופסת 7.6% ב-Instagram ב-Android ו-2.4% ב-Facebook ב-Android, כרצפה. ב-iOS זה פחות מ-1%.

למה Play Store לא נפתח מהדפדפן הפנימי של TikTok?

אפליקציית TikTok ל-Android משתמשת בכמה דפדפנים פנימיים. באחד מהם (גרסת musical_ly_ עם נקודות ובלי Version/4.0 ב-User-Agent), 85% מהסשנים הגיעו ל-Play Store במשך 30 יום. בשניים אחרים (Version/4.0 עם JsSdk/BytedanceWebview, או עם AppName/musical_ly), רק 12–14% הגיעו, על אותם קישורים ובאותם ימים. TikTok עצמו מסרב להעברה, לא משנה מה צורת הכתובת.

אפשר לדעת מתוך דף אינטרנט שה-App Store נפתח ב-iOS?

לא בתוך Instagram או Facebook. ה-App Store נפתח מעל הדפדפן הפנימי, כך שהדף אף פעם לא הופך למוסתר ו-visibilitychange לא נורה. במשך 7 ימים, רק 13% (Facebook) עד 56% (Instagram) מההעברות ב-iOS לוו בהסתרת הדף, ופחות מ-1% מהמבקרים הקישו על כפתור הגיבוי. דוחות הקמפיינים של App Store Connect הם האות האמין.

כמה זמן לוקח ל-Play Store להיפתח מדפדפן בתוך אפליקציה?

ב-Android, הדף הופך למוסתר 2–3 שניות אחרי ההעברה ברוב הסשנים המוצלחים, ועד 8 שניות אחר כך בטלפונים איטיים יותר. כרטיס גיבוי שמוצג אחרי 2 שניות מופיע לפני החנות בהרבה סשנים שעמדו להצליח.

באיזו תדירות הפניה לחנות אפליקציות באמת נכשלת בתוך Instagram?

ב-7,357 סשנים משוחזרים של Instagram ב-Android, הדפוס של כישלון אמיתי (ההעברה יצאה לדרך, ואז כלום, והמבקר מקיש שוב על הקישור) היה 1.9%. רוב הכישלונות לכאורה בנתוני משפך גולמיים הם תוצרי מדידה: beacons שאבדו, חנות איטית או טעינות מוקדמות.

האם דומיין מותאם אישית משנה את היחס של TikTok לקישור?

לא. במשך 90 יום, קישורים עם ובלי דומיין מותאם אישית נדחו באותו אופן. מה שמכריע הוא הדפדפן הפנימי ש-TikTok משתמש בו עבור אותו מבקר.