پژوهش اصیل
چه بر سر پیوند برنامه‌ای می‌آید که درون Instagram و TikTok باز میشود: اندازه‌گیری 74,000 هدایت
پیش‌بارگذاری‌هایی که کسی نمی‌بیند، وب‌ویوی TikTok که فروشگاه را رد میکند، و App Store که روی صفحه باز میشود: آنچه لاگ‌های هدایت ما نشان می‌دهند.
منتشرشده در · Adrien De Coster
پاسخ کوتاه
از میان 74,713 ورود Android از مرورگرهای درونبرنامهای در 30 روز، 9.1% صفحه‌هایی بودند که Instagram یا Facebook در پس‌زمینه بارگذاری کرد و حدود 30 ثانیه بعد، بی‌آنکه کسی آن‌ها را ببیند، دور انداخت. درون TikTok روی Android، باز شدن Play Store به این بستگی دارد که TikTok از کدام وب‌ویو استفاده کند: یک قالب User-Agent در 85% از نشستها به فروشگاه رسید و دو قالب دیگر در 12–14%، روی همان پیوندها و در همان روزها. در iOS، Instagram و Facebook فروشگاه App Store را روی مرورگر درونبرنامهای باز می‌کنند، پس صفحه هرگز به پس‌زمینه نمی‌رود و نرخ باز شدن فروشگاه که از روی صفحه اندازه‌گیری شود، حتی وقتی تحویل موفق بوده، 13–56% خوانده میشود.
این اعداد از لاگ‌های هدایت یک سرویس پیوند هوشمند می‌آیند: یک URL که گوشی را به 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، نشستها بر اساس قالب وب‌ویو | 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.
صفحه چگونه گزارش می‌دهد که چه شد
وقتی پیوندی درون یک مرورگر درونبرنامهای باز میشود، صفحه سه کار انجام می‌دهد و برای هر کدام یک بیکن (beacon) می‌فرستد:
auto: هنگام بارگذاری، تحویل به فروشگاه را آغاز میکند (iOS:location.replaceبه URL فروشگاه App Store؛ Android: یک URL از نوع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 ما را اجرا کرد، پس ورود ثبت شد. هیچ‌کس هرگز آن را ندید.
| جمعیت | ورودها | پیشبارگذاریها | سهم |
|---|---|---|---|
| همهٔ ورودها، همهٔ سکوها | 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 ثانیه، بی‌آنکه هرگز نمایش داده شود، از بین برود، به جای خروج، پیش‌بارگذاری گزارش می‌دهد. این چیزی است که از آن زمان ثبت کرده است:
| مرورگر درونبرنامهای | بارگذاری‌های صفحه | پیشبارگذاریها | سهم |
|---|---|---|---|
| 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% |
این شمارش زمان اجرا یک کف است. پیش‌بارگذاری‌ای که بدون اجرای هیچ اسکریپتی از بین برود هیچ بیکنی به جا نمی‌گذارد، و قاعدهٔ زمان اجرا از بازسازی تاریخی سخت‌گیرانه‌تر است.
چرا مهم است. اگر کلیک‌ها را در نقطهٔ هدایت می‌شمارید، تقریباً یک «کلیک» از هر 13 کلیک Instagram در Android را هیچ انسانی ندیده است. نسبت کلیک به نصب شما برای این کانال بدتر از واقعیت به نظر می‌رسد، و داشبورد کمپینی که بر پایهٔ بازدیدهای خام هدایت ساخته شده، دسترسی را تقریباً به همین اندازه بیش از واقع نشان می‌دهد.
یافتهٔ 2: TikTok بسته به وب‌ویویی که به کار می‌برد Play Store را رد میکند
درون 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%) |
مقایسه‌ای که موضوع را روشن میکند پیوند و روز را ثابت نگه می‌دارد، چون ترکیب قالب‌ها هفته به هفته تغییر میکند:
| پیوند | قالب A | قالب B |
|---|---|---|
| پیوند 1 | 560 / 674 (83%) | 32 / 192 (17%) |
| پیوند 2 | 257 / 285 (90%) | 2 / 47 (4%) |
همان پیوند، همان کد هدایت، همان روز: یک وب‌ویو اجازه می‌دهد فروشگاه باز شود و دیگری عمدتاً نه. دامنه‌های سفارشی در دادههای 90 روزه هیچ تفاوتی ایجاد نکردند. TikTok نه این پنجره را مستند کرده، نه آنچه آن را فعال میکند، نه اینکه کدام کاربر کدام وب‌ویو را می‌گیرد؛ پس تفکیک بر اساس User-Agent تنها چیزی است که در دست داریم.
چرا مهم است. هیچ شکلی از URL این را حل نمی‌کند: خروج از طریق intent:// و یک URL سادهٔ https://play.google.com همان رد را دریافت می‌کنند. کاری که می‌توانید بکنید این است که راه خروج را پنهان نکنید: درون TikTok، دستورالعمل «باز کردن در مرورگر» و دکمهٔ کپی را همان ابتدا نشان دهید، نه پس از یک مهلت.
یافتهٔ 3: در iOS، App Store روی مرورگر درونبرنامهای باز میشود
در Android، پس از تحویل، صفحه در بیشتر نشستها پنهان میشود، معمولاً 1 تا 3 ثانیه بعد. در iOS درون Instagram و Facebook اغلب چنین نمیشود، با اینکه تحویل تقریباً در همهٔ نشستها اجرا شده است:
| مرورگر درونبرنامهای | بارگذاری‌های صفحه | تحویل اجرا شد | پنهان شد | …ظرف 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 هم نیست که در آن «کار کند»:
| نسخهٔ اصلی 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، با یک توکن ارائه‌دهنده (pt) و یک توکن کمپین (ct) روی URL فروشگاه App Store.
چیزهای کوچک‌تری که در طول راه اندازه گرفتیم
- Play Store در Android دیر نمایش داده میشود. در نشستهای Instagram در Android که تحویل اجرا شد، صفحه در 1,061 نشست 0–1 ثانیه پس از ورود پنهان شد، در 2,596 نشست 2–3 ثانیه بعد و در 1,273 نشست 4–8 ثانیه بعد (7 روز). یک زمان‌سنج 2 ثانیه‌ای برای «کار کرد؟» در بخش بزرگی از موفقیت‌های واقعی پیش از ظاهر شدن فروشگاه اجرا میشود. قیف خود ما این‌ها را شکست می‌شمرد تا وقتی که اجازه دادیم خروجی تا 8 ثانیه پس از تحویل همچنان شمرده شود.
- نرخ واقعی شکست کوچک است. در 7,357 نشست Instagram در Android که طی 3 روز در اوایل اکتبر بازسازی شدند، الگوی «تحویل، سپس هیچ» 1.9% از نشستها بود، و 24.3% از این بازدیدکنندگان ظرف 3 دقیقه دوباره پیوند را لمس کردند. بازدیدکنندگانی که نشستشان کارت جایگزین را نشان داد با نرخ 5.4% دوباره لمس کردند، تقریباً مانند بازدیدکنندگانی که فروشگاهشان باز شد (4.6%): بیشتر آن «شکست‌ها» شکست نبودند.
- الزام به لمس بیشتر ترافیک را از بین می‌برد. پیش از آنکه صفحه تحویل را هنگام بارگذاری آغاز کند، کارتی با دکمهٔ فروشگاه نشان می‌داد. در 30 روز، 10,523 ورود درونبرنامهای 2,119 لمس به همراه داشت: حدود 80% از بازدیدکنندگان هرگز به فروشگاه نرسیدند.
روش
- منبع. هر ورود به یک پیوند هوشمند و هر بیکن از صفحهٔ تحویل در Cloudflare Workers Analytics Engine ثبت میشود، همراه با سکو، مرورگر درونبرنامهای (از روی User-Agent)، نوع رویداد و مُهر زمانی با دقت ثانیه. بازدیدکنندگانی که User-Agent آن‌ها خود را ربات، خزنده یا واکشی‌کنندهٔ پیش‌نمایش پیوند معرفی میکند جدا نگه داشته شده و از همهٔ ارقام این صفحه کنار گذاشته شده‌اند.
- نشستها. Analytics Engine شناسه‌ای برای بارگذاری صفحه ندارد، پس نشستها با پیوند دادن یک ورود به بیکن‌هایی بازسازی می‌شوند که در ساعت بعدی می‌آیند و پیوند، کشور، شهر، User-Agent و مرورگر درونبرنامهای یکسانی با آن دارند، تا ورود بعدی با همان کلید. حدود 98% از بیکن‌ها به یک ورود متصل می‌شوند.
- پیشبارگذاریها (یافتهٔ 1). معیار تاریخی: بدون تحویل، بدون کارت جایگزین، بدون لمس، و خروجی 20 ثانیه تا 15 دقیقه پس از ورود. معیار زمان اجرا از 2026-10-16: صفحه وقتی پیش‌بارگذاری گزارش می‌دهد که پس از دست‌کم 20 ثانیه، بی‌آنکه هرگز نمایش داده شود، از بین برود و زمان‌سنج تحویلش هرگز اجرا نشده باشد (یا پنهان بارگذاری شده باشد). بیکن یک توکن امضاشدهٔ یک‌بارمصرف دارد، پس نمی‌توان آن را دوباره فرستاد تا یک بازدید واقعی پاک شود.
- 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 هیچ بیکنی نمی‌فرستند، و احتمالاً برخی از آن‌ها هم پیش‌بارگذاری‌اند.
چه باید کرد
- تحویل را هنگام بارگذاری آغاز کنید. صفحه‌ای که منتظر لمس می‌ماند بیشتر بازدیدکنندگان درونبرنامهای را از دست می‌دهد. دکمهٔ دستی را به عنوان جایگزین نگه دارید و فقط وقتی نمایانش کنید که تحویل آشکارا شکست خورده باشد.
- در Android، از `intent://` همراه با `S.browser_fallback_url` استفاده کنید. یک URL از نوع
https://play.google.comدرون وب‌ویو، وب‌سایت Play Store را باز میکند که بدون ورود به حساب نمی‌تواند چیزی نصب کند. - به فروشگاه کُند زمان بدهید. دست‌کم 3 ثانیه صبر کنید تا دربارهٔ شکست تحویل تصمیم بگیرید، و خروج دیرهنگام را همچنان بشمارید.
- درون TikTok، راه خروج را بی‌درنگ نشان دهید: «··· → باز کردن در مرورگر» و دکمهٔ کپی پیوند. هیچ تغییری در URL رد 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% از نشستها در 30 روز به Play Store رسیدند. در دو مرورگر دیگر (Version/4.0 همراه با JsSdk/BytedanceWebview، یا همراه با AppName/musical_ly)، فقط 12–14% رسیدند، روی همان پیوندها و در همان روزها. خود TikTok تحویل را رد میکند، صرفنظر از شکل URL.
آیا از روی یک صفحهٔ وب میتوان فهمید که 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% بود. بیشتر شکستهای ظاهری در دادههای خام قیف، خطاهای اندازهگیریاند: بیکنهای گمشده، فروشگاهی کُند یا پیشبارگذاریها.
آیا دامنهٔ سفارشی رفتار TikTok با یک پیوند را تغییر می‌دهد؟
نه. در 90 روز، پیوندهای دارای دامنهٔ سفارشی و بدون آن به یک شکل رد شدند. آنچه تعیین‌کننده است مرورگر درون‌برنامه‌ای‌ای است که TikTok برای آن بازدیدکننده به کار می‌برد.