ماذا يحدث لرابط تطبيق يُفتح داخل Instagram وTikTok: قياس 74,000 عملية إعادة توجيه

تأتي هذه الأرقام من سجلات إعادة التوجيه لخدمة روابط ذكية: رابط واحد يرسل الهاتف إلى App Store أو Google Play. في كل مرة يُفتح فيها رابط داخل تطبيق اجتماعي، نقدّم صفحة صغيرة تسلّم الزائر إلى المتجر، وتُبلغ تلك الصفحة بما حدث بعد ذلك. في ما يلي ما تقوله هذه البلاغات، وكيف قسناها، وأين يتوقف القياس.

البيانات

أمران يبرزان قبل أي تحليل. تطبيقات 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 الخاصة بنا، فسُجّلت الزيارة. لكن أحدًا لم ينظر إليها قط.

تحققنا من المعيار مقابل جلسات بشرية بوضوح: 0 من 17,606 جلسة فُتح فيها المتجر بعد 2–3 ثوانٍ من التسليم طابقته، و0 من 244 جلسة نقر فيها أحدهم زر المتجر طابقته.

تتغير النسبة من أسبوع لآخر: 6.8% في الأسبوع الأخير من تلك الفترة، ثم 8.8% و10.6% و10.0% في الأسابيع السابقة. كما تتركز حيث تعمل حملات Instagram المدفوعة: 72% من التحميلات المسبقة في الفترة جاءت من رابط واحد وراء حملة Instagram كبيرة.

منذ 16 أكتوبر، تصنّف الصفحة ذلك بنفسها أثناء التشغيل: تُبلغ عن تحميل مسبق بدل خروج حين تنتهي بعد 20 ثانية على الأقل دون أن تُعرض قط. هذا ما رصدته منذ ذلك الحين:

هذا العدد أثناء التشغيل حدٌّ أدنى. فالتحميل المسبق الذي ينتهي دون تشغيل أي شيفرة لا يترك أي إشارة، وقاعدة التشغيل أكثر صرامة من إعادة البناء التاريخية.

لماذا يهم ذلك. إن كنت تعدّ النقرات عند إعادة التوجيه، فإن «نقرة» واحدة تقريبًا من كل 13 على Instagram في Android لم يرها إنسان قط. تبدو نسبة النقر إلى التثبيت لهذه القناة أسوأ مما هي عليه، ولوحة حملات مبنية على زيارات إعادة التوجيه الخام تبالغ في تقدير الوصول بالقدر نفسه تقريبًا.

النتيجة 2: TikTok يرفض فتح Play Store بحسب المتصفح المدمج الذي يستخدمه

داخل TikTok على Android، لا يغادر جزء من الزوار الصفحة أبدًا: يُطلق التسليم فيعرض TikTok نافذته الخاصة («The action cannot be completed» — «تعذّر إكمال الإجراء»). لا يحدث ذلك مع كل رابط، وظل لأسابيع يبدو وكأنه يتوقف على الرابط. ليس كذلك. إنه يتوقف على المتصفح المدمج الذي يستخدمه TikTok لذلك الزائر، والذي يكشفه User-Agent الخاص به:

تُعدّ الجلسة نجاحًا حين يُطلق التسليم وتصبح الصفحة مخفية، وإخفاقًا حين تظهر البطاقة الاحتياطية. المعدل = نجاح / (نجاح + إخفاق)، لكل جهاز ويوم:

المقارنة الحاسمة تثبّت الرابط واليوم، لأن مزيج الصيغ يتغير من أسبوع لآخر:

الرابط نفسه، وشيفرة إعادة التوجيه نفسها، واليوم نفسه: متصفح مدمج يسمح بفتح المتجر والآخر لا يسمح في الغالب. لم تُحدث النطاقات المخصصة أي فرق في بيانات الـ 90 يومًا. لا يوثّق TikTok هذه النافذة، ولا ما يطلقها، ولا أي المستخدمين يحصل على أي متصفح، لذا فإن التقسيم حسب User-Agent هو كل ما لدينا.

لماذا يهم ذلك. لا توجد صيغة رابط تحل هذا: الخروج عبر intent:// ورابط https://play.google.com العادي يلقيان الرفض نفسه. ما يمكنك فعله هو ألا تخفي المخرج: داخل TikTok، اعرض تعليمات «الفتح في المتصفح» وزر النسخ فورًا، بدل عرضها بعد مهلة.

النتيجة 3: على iOS، يُفتح App Store فوق المتصفح المدمج

على Android، بعد التسليم، تصبح الصفحة مخفية في معظم الجلسات، عادةً بعد 1 إلى 3 ثوانٍ. أما على iOS داخل Instagram وFacebook فغالبًا لا يحدث ذلك، رغم أن التسليم أُطلق في كل الجلسات تقريبًا:

لو كان ثلثا زوار iOS عالقين فعلًا أمام بطاقة احتياطية ظاهرة فيها زر «افتح App Store»، لنقر عليه عدد كبير منهم. لكنهم لا يفعلون: 0.9% من تحميلات صفحة Instagram على iOS و0.4% من تحميلات Facebook على iOS تنقر الزر. ولا يوجد إصدار من iOS «ينجح» فيه الأمر:

التفسير الذي يتسق مع البيانات هو أن App Store، داخل Instagram وFacebook على iOS، يظهر فوق المتصفح المدمج دون أن يرسله إلى الخلفية. تبقى الصفحة «ظاهرة» طوال الوقت، فلا يُطلق visibilitychange ولا pagehide أبدًا، رغم أن الزائر ينظر إلى App Store.

لماذا يهم ذلك. أي مقياس يستنتج فتح المتجر من مغادرة الصفحة للشاشة خاطئ على iOS. كنا نعرض للعملاء نسبة «وصول إلى المتجر» مبنية بهذه الطريقة بالضبط، وقد أخبرت 10 من أصل 12 عميلًا يدفعون أن روابط تعمل كانت معطلة. فأزلناها. على iOS، إشارة التثبيت الموثوقة موجودة في جانب المتجر: تقارير الحملات في App Store Connect، مع رمز المزوّد (pt) ورمز الحملة (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% من الزوار لم يصلوا إلى المتجر قط.

المنهجية

• المصدر. تُكتب كل زيارة إلى رابط ذكي وكل إشارة من صفحة التسليم في 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 لا ترسل أي إشارة، وبعضها على الأرجح تحميلات مسبقة أيضًا.

ماذا تفعل حيال ذلك

1. ابدأ التسليم عند التحميل. الصفحة التي تنتظر نقرة تخسر معظم زوار التطبيقات. أبقِ الزر اليدوي احتياطيًا، لا يظهر إلا إذا فشل التسليم بشكل واضح.
2. على Android، استخدم `intent://` مع `S.browser_fallback_url`. رابط https://play.google.com داخل متصفح مدمج يفتح موقع Play Store على الويب، الذي لا يستطيع تثبيت أي شيء دون تسجيل الدخول.
3. امنح المتجر البطيء وقتًا. انتظر 3 ثوانٍ على الأقل قبل أن تحكم بفشل التسليم، واستمر في احتساب الخروج المتأخر.
4. داخل TikTok، اعرض المخرج فورًا: «··· → الفتح في المتصفح» وزر نسخ الرابط. لا يوجد تغيير في الرابط يزيل رفض TikTok.
5. لا تحتسب تحميلات Meta المسبقة نقرات. إن كنت تُبلغ عن النقرات من إعادة التوجيه، فتوقّع أن تكون 2–9% من زيارات Instagram وFacebook على Android صفحاتٍ لم يرها أحد.
6. قِس التثبيتات عند المتجر، بروابط حملات App Store Connect (pt + ct) على iOS وPlay Install Referrer على Android، لا بأحداث الصفحة.

نحن نبني onestore.link، الذي يطبّق هذه الست كلها افتراضيًا على كل رابط، والبيانات أعلاه مأخوذة من سجلات إعادة التوجيه الخاصة به.

أسئلة وأجوبة