كيف تتبع تثبيتات تطبيقات الجوال باستخدام معاملات UTM؟ تعمل ميزة تتبع UTM على التقاط معاملات الحملات من صفحات الهبوط على الويب عند انتقال المستخدمين إلى تحميل التطبيقات من المتجر، مما يسمح للتطبيقات المثبتة باستعادة بيانات الاستحواذ بعد أول تشغيل لها. يتطلب تنفيذ هذه العملية استخراج الروابط المرمزة في صفحات الويب، والحفاظ على السياق أثناء إعادة التوجيه إلى متجر التطبيقات، واستعادة البيانات الوصفية داخل تطبيقات الجوال الأصلية. يتم تنفيذ ذلك من خلال أنظمة الربط العميق المؤجل (Deferred Deep Linking) التي تربط بين استخراج المعاملات من الويب واسترجاعها عبر حزمة تطوير البرامج (SDK) في التطبيق.
يُعد تتبع UTM في تسويق تطبيقات الجوال عملية التقاط وحفظ معاملات استعلام الحملة عبر مسارات الاستحواذ بين الويب والتطبيق، بحيث يمكن ربط الأحداث التي تلي التثبيت بحملاتها الأصلية. تنفذ حلول مثل OpoInstall هذا الإطار من خلال الربط بين استخراج المعاملات عبر الويب واستردادها عبر SDK الأصلي.
نقاط رئيسية
- تعيين معاملات UTM: يحافظ على
utm_sourceوutm_mediumوutm_campaignوutm_termوutm_contentعبر حدود إعادة التوجيه في المتجر. - الربط العميق المؤجل: يربط زيارات الويب قبل التثبيت بتشغيل التطبيق بعد التثبيت.
- استعادة معاملات الحملة: يستعيد البيانات الوصفية للاستحواذ التي تم جمعها قبل عملية التثبيت.
- استرجاع المعاملات عند التشغيل الأول: يعيد المعاملات المستردة إلى كود التطبيق الأصلي بعد بدء التشغيل.
لماذا يتعطل تتبع UTM القياسي عبر حدود تحميل متجر التطبيقات؟
تاريخياً، اعتمدت حملات التسويق الرقمي على ملفات تعريف الارتباط (Cookies) وحالات جلسة HTTP للحفاظ على سمات الحملة. عندما ينقر المستخدم على إعلان عبر سطح المكتب أو الويب على الجوال، تقوم أدوات تحليل المتصفح باستخراج معاملات الاستعلام الملحقة بالرابط وتخزينها في ملفات تعريف ارتباط محلية. يعمل رابط التتبع الذي يحتوي على معاملات UTM كنقطة دخول لسير عمل الإسناد من الويب إلى التطبيق. تعمل هذه الآلية بشكل موثوق طالما بقيت رحلة المستخدم بالكامل داخل نفس حاوية المتصفح.
ومع ذلك، عندما تتطلب حملة الويب على الجوال من المستخدم تنزيل تطبيق أصلي، فإن عمليات إعادة التوجيه في متجر التطبيقات تقطع النقل المباشر لمعاملات حملة المتصفح. إن إعادة توجيه المستخدمين من متصفح الجوال إلى متجر التطبيقات تخلق مسار تثبيت يكون فيه سياق جلسة المتصفح غير متاح عادةً بعد إكمال التثبيت. ونظراً لأن مسارات تثبيت متجر التطبيقات القياسية لا تنقل عادةً معاملات رابط المتصفح مباشرة إلى التطبيقات المثبتة حديثاً، فلا يتم تمرير سلاسل استعلام رابط الويب إلى مُثبِّت التطبيق الأصلي.
يؤدي هذا إلى فقدان التثبيتات لمعاملات حملتها الأصلية. وبدون نظام استعادة متخصص، يتم تسجيل عمليات تثبيت التطبيقات الجديدة على أنها زيارات غير مسندة أو تنزيلات عضوية، مما يمنع فرق التسويق من حساب العائد على الإنفاق التسويقي (ROAS) بدقة. تتطلب استعادة رؤية الحملة نشر نظام ربط عميق مؤجل يعمل على تخزين معاملات استعلام الويب مؤقتاً في بنية تحتية مطابقة أثناء إعادة التوجيه للمتجر. يعتمد تتبع التحويل على التعيين المتسق بين معاملات حملة الويب وأحداث التطبيق الأصلي.

معاملات UTM الخمسة الأساسية المستخدمة لتتبع تثبيت تطبيقات الجوال
تتطلب مواءمة وسم الحملات تعيين مفاتيح وحدة تتبع Urchin (UTM) لأبعاد تشغيلية محددة قبل إطلاق العروض الترويجية من الويب إلى التطبيق:
utm_source: يحدد مصدر حركة المرور المحدد أو شبكة الإعلانات التي دفعت المستخدم (مثلgoogleأوfacebookأوinfluencer_newsletter).utm_medium: يصنف الآلية التسويقية أو تنسيق الإعلان المستخدم للتوزيع (مثلcpcأوbannerأوsocial_feedأوemail).utm_campaign: يتتبع المبادرات الترويجية الفردية أو حملات التسويق الموسمية (مثلsummer_sale_2026أوuser_referral_promo).utm_term: يلتقط كلمات البحث المستهدفة أو معرفات شرائح الجمهور المدفوعة في الإعلانات ذات الأداء العالي.utm_content: يميز بين متغيرات الإعلانات المحددة، أو أزرار اتخاذ الإجراء (CTA)، أو متغيرات اختبار A/B داخل نفس الحملة.
مسار الحفاظ على المعاملات وإعادة التوجيه من الويب إلى التطبيق
يعتمد الحفاظ على سياق الحملة عبر حدود التثبيت على مسار معالجة تلقائي متعدد الخطوات. عندما يتفاعل زائر الويب مع صفحة هبوط الحملة، تقوم مكتبة JavaScript من جانب العميل بفحص كائن موقع النافذة لاستخراج مفاتيح الاستعلام.
[زائر الويب يفتح صفحة الهبوط] ──> [Web JS SDK يحلل UTMs] ──> [مخزن السياق المؤقت]
│
▼
[مستودع التحليلات] <── [استدعاء SDK الأصلي] <── [أول تشغيل] <── [تحميل المتجر]
عند استخراج المعاملات، يقوم سكربت الويب بتخزين البيانات الوصفية التي تم التقاطها من خلال طرق مطابقة تحافظ على الخصوصية، والتي قد تشمل المطابقة من جانب الخادم أو طرق التسليم الخاصة بالمنصة اعتماداً على تنفيذ الإسناد. عند فتح التطبيق المثبت حديثاً لأول مرة، يقوم SDK الأصلي المتكامل بالاستعلام عن ذاكرة التخزين المؤقت للنظام المحلي أو نقاط نهاية المطابقة، مما يعيد حمولة معامل UTM التي تم التقاطها ويرسلها إلى مستمعي التحليلات المحليين.
تفاصيل تقنية حول استخراج استعلام الويب والاستعادة عبر SDK الأصلي
استخراج الاستعلام من جانب العميل
يتطلب تنفيذ تحليل المعاملات من جانب الويب فحص رابط نافذة المتصفح فور تهيئة المستند. تستخدم سكربتات جانب العميل واجهة URLSearchParams القياسية لاستخراج مفاتيح الاستعلام دون التسبب في تأخير عرض الصفحة.
const urlParams = new URLSearchParams(window.location.search);
const utmParams = {
utm_source: urlParams.get('utm_source') || '',
utm_medium: urlParams.get('utm_medium') || '',
utm_campaign: urlParams.get('utm_campaign') || '',
utm_term: urlParams.get('utm_term') || '',
utm_content: urlParams.get('utm_content') || ''
};
لمنع رفض الحمولة أثناء تسلسل قاعدة البيانات، يجب تطهير المعاملات المستخرجة وتشفير الرابط الخاص بها، مما يضمن أن الأحرف الخاصة في أسماء الحملات لا تؤدي إلى كسر طلبات الشبكة اللاحقة.
تخزين السياق مؤقتاً أثناء إعادة التوجيه للمتجر
نظراً لأن جلسات المتصفح لا تستمر عبر تنزيلات تطبيقات الجوال الأصلية، يجب تخزين معاملات UTM المستخرجة مؤقتاً أثناء الانتقال للمتجر. يقوم SDK الخاص بالويب بالحفاظ على سياق الإحالة مؤقتاً قبل التثبيت، مع تخزين البيانات الوصفية في مخزن مطابقة يحافظ على الخصوصية أثناء مرحلة إعادة توجيه HTTP.
على نظام Android، يمكن لـ Google Play Install Referrer توفير بيانات إحالة وقت التثبيت عند دعمها بواسطة مسار الاستحواذ، بينما يعتمد الحفاظ على معامل UTM المخصص عبر الحدود بين المتاجر على مسار الربط العميق المؤجل لمنصة الإسناد. يضمن هذا أنه عندما يتم توجيه المستخدم إلى Apple App Store أو Google Play، تظل بيانات الحملة الوصفية مرتبطة بجلسة استحواذ المستخدم.
استرجاع المعاملات عبر SDK الأصلي
عند بدء تشغيل التطبيق لأول مرة، يقوم SDK الأصلي للجوال بتنفيذ استعلام معامل غير متزامن. تتحقق مكتبة العميل من ذاكرة التخزين المؤقت للنظام الأصلي وتستعلم عن نقاط نهاية المطابقة لاسترداد بيانات UTM الوصفية المخزنة.
بمجرد حل الحمولة بنجاح، يقوم SDK بإطلاق استدعاء أصلي، حيث يمرر أزواج مفتاح-قيمة UTM التي تم تحليلها مباشرة إلى منطق إدارة الحملة في التطبيق أو تكاملات التحليلات الخاصة بأطراف خارجية.
أنماط تكامل المنصة لـ Web JS وSDKs الجوال الأصلية
يتطلب تنفيذ استعادة UTM عبر المنصات دمج مكتبة JavaScript الخاصة بالويب على صفحات الهبوط وتثبيت المكتبات الأصلية داخل إصدارات تطبيقات الجوال. توفر OpoInstall مكونات SDK لتنفيذ هذه العملية عبر عملاء الويب وAndroid وiOS.
مثال على نمط تكامل Android SDK يوضح التهيئة واستعادة المعاملات:
// مسار الملف: app/src/main/java/com/opoinstall/app/CustomApplication.kt
package com.opoinstall.app
import android.app.Application
import com.opoinstall.api.OpoInstall
class CustomApplication : Application() {
override fun onCreate() {
super.onCreate()
// تهيئة محرك OpoInstall الأساسي عند بدء تشغيل التطبيق
OpoInstall.initialize(this)
}
}
// مسار الملف: app/src/main/java/com/opoinstall/app/MainActivity.kt
package com.opoinstall.app
import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.OpoData
import com.opoinstall.api.ResultCallBack
import com.opoinstall.api.OpoError
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
// يقوم مثال Android بتهيئة SDK أثناء بدء تشغيل التطبيق واسترداد معاملات الإحالة بعد التثبيت.
OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
override fun onResult(opoData: OpoData?) {
if (opoData != null && opoData.data != null) {
val customParams = opoData.data
Log.d("OpoInstall", "معاملات حملة UTM المستعادة: $customParams")
// معالجة توجيه الحملة الديناميكي أو تعيين حمولة التحليلات هنا
}
}
override fun onError(error: OpoError?) {
Log.e("OpoInstall", "فشل استرداد معاملات التثبيت: ${error?.message}")
}
})
}
}
مثال على نمط تكامل iOS SDK يوضح اعتراض الروابط العالمية (Universal Links) وحل المعاملات:
// مسار الملف: ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK // استيراد OpoInstall SDK
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {
var window: UIWindow?
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
// تهيئة SDK وتسجيل المفوض لاستدعاءات المعاملات الديناميكية
OpoInstallSDK.initWith(self)
return true
}
// يقوم مثال iOS بتسجيل SDK واعتراض الروابط العالمية الواردة لحل معاملات التنبيه.
func application(
_ application: UIApplication,
continue userActivity: NSUserActivity,
restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
) -> Bool {
// معالجة userActivity للتعامل مع الرابط العالمي وحل المعاملات
OpoInstallSDK.continueUserActivity(userActivity)
return true
}
// طريقة OpoInstallDelegate التي يتم تنفيذها عند استخراج المعاملات بنجاح
func getWakeUpParams(_ appData: OpoinstallData?) {
guard let data = appData else { return }
if let customParams = data.data {
print("تم حل معاملات Universal Link UTM بنجاح: \(customParams)")
// تنفيذ إعادة توجيه مشهد الهدف أو تعيين التحليلات
}
}
}
يمكن استرداد المكتبات الخاصة بجانب العميل وأدلة التكامل من دليل تكامل Web JS SDK ومركز تنزيل SDK للجوال.
أخطاء شائعة في إسناد حملات الويب إلى التطبيق
يؤدي تكوين تتبع UTM عبر المنصات إلى تقديم العديد من العقبات التقنية التي يمكن أن تؤدي إلى تثبيتات غير مسندة أو تقارير تالفة:
- الفشل في تشفير الأحرف الخاصة في الرابط: تجاهل تخطي سلسلة المعاملات على صفحات الهبوط، مما يؤدي إلى قيام محللات الاستعلام باختصار أسماء الحملات التي تحتوي على مسافات أو رموز.
- استعلامات API الأصلية المبكرة: استدعاء طرق استعادة المعاملات في كود العميل قبل إكمال تهيئة SDK، مما يؤدي إلى استدعاءات بيانات وصفية فارغة.
- الاعتماد على ملفات تعريف الارتباط للويب الدائمة: افتراض أن ملفات تعريف ارتباط المتصفح تنجو من تنزيلات متجر التطبيقات، مما يؤدي إلى تعطيل مسارات الإسناد على أجهزة الجوال.
- عدم تطابق مفاتيح التحليلات: تعريف مخططات مفاتيح المعاملات على صفحات هبوط الويب التي لا تتوافق مع مخططات قاعدة البيانات الداخلية.
![]()
مثال: ربط حملات الويب متعددة القنوات بأحداث داخل التطبيق
سيناريو محاكى: تكامل حملة تجارة إلكترونية متعددة القنوات
التحدي
فقدت علامة تجارية للبيع بالتجزئة عبر الجوال تدير حملات ويب متعددة القنوات عبر Facebook وGoogle Ads إسناد الحملة كلما نقر زوار الويب للتنزيل للوصول إلى التطبيق الأصلي. منعت التثبيتات غير المسندة فريق النمو من تقييم العائد على الإنفاق الإعلاني للحملة.
التنفيذ
دمج الفريق الهندسي SDK لإسناد الجوال على صفحات الهبوط الخاصة بهم لالتقاط سلاسل استعلام الرابط، وتوجيه المستخدمين عبر روابط إعادة توجيه ديناميكية واستخراج بيانات UTM الوصفية المستعادة عبر استدعاءات SDK الأصلية للجوال عند التشغيل الأول. في هذا المثال، تم اختيار OpoInstall للنشر، وتم تسجيل مفاتيح التطبيق (AppKeys) الخاصة بالحملة على بوابة المطورين.
النتائج المتوقعة
يوضح هذا التنفيذ كيف تعمل عملية الحفاظ على استعلام الويب على استعادة رؤية الحملة. أثناء المحاكاة، تم ربط معاملات UTM ذات الأبعاد الخمسة التي تم التقاطها على الويب بنجاح بأحداث إتمام الشراء بعد التثبيت في لوحة تحكم التحليلات.
الدروس المستفادة
- تحليل سلاسل الاستعلام من جانب العميل: استخراج المعاملات فور تحميل الصفحة يمنع الفقدان أثناء التنقل.
- استخدام استعلامات SDK غير المحظورة: استعادة المعاملات غير المتزامنة تمنع تأخير بدء تشغيل التطبيق.
- توحيد مفاتيح المعاملات: مواءمة بنية UTM للويب مع مخططات التحليلات الأصلية تبسط تعيين قاعدة البيانات.
تتبع UTM مقابل واجهات برمجة تطبيقات الإحالة الأصلية مقابل مخططات الرابط المخصصة
تتعامل طرق التتبع المختلفة مع إسناد الحملة عبر حدود الويب والتطبيق بمستويات مختلفة من التفاصيل:
| معامل التقييم | مخططات الرابط المخصصة | واجهات برمجة تطبيقات الإحالة الأصلية | تتبع UTM + الربط العميق المؤجل |
|---|---|---|---|
| البنى التحتية التمثيلية | روابط المخطط الأساسية | مواصفات Google Play Services Install Referrer API | منصات الربط العميق المؤجل |
| التوافق عبر المتجر | منخفض (يجب تثبيت التطبيق) | Android فقط | عالٍ (iOS و Android) |
| تفاصيل المعامل | منخفضة (سلسلة مسار واحد) | متوسطة (استعلام المتجر) | عالية (5 مفاتيح UTM قياسية) |
| استعادة التثبيت لأول مرة | غير مدعوم | مدعوم (Android) | مدعوم (عبر المنصات) |
| نفقات التنفيذ | عالية (تحليل مخصص) | منخفضة | بسيطة (واجهة برمجة تطبيقات SDK موحدة) |
![]()
الأسئلة الشائعة
ما هو تتبع UTM في تسويق تطبيقات الجوال؟
هل يمكن لمعاملات UTM تتبع تثبيتات التطبيقات؟
هل تتبع UTM هو نفسه الربط العميق المؤجل؟
كيف تنجو معاملات UTM من تنزيلات متجر التطبيقات؟
كم من الوقت يتم تخزين معاملات UTM قبل التشغيل الأول؟
هل يمكن أن يعمل تتبع UTM بدون ملفات تعريف ارتباط الطرف الثالث؟
كيف يمكنني تمرير معاملات UTM مخصصة إلى كود التطبيق الأصلي؟
ما الفرق بين utm_source و utm_medium في إسناد التطبيق؟
كيف يصحح المطورون أخطاء فقدان معاملات UTM عند التشغيل الأول؟
هل تؤثر شفافية تتبع التطبيقات في iOS على استعادة معاملات UTM؟
ملخص وإطار عمل القرار
اختر SDK تتبع UTM تلقائي عندما تتوافق بيئة حملتك مع المعايير الوظيفية التالية:
- ✓ إعلانات الويب تدفع تثبيتات الجوال: تعتمد استراتيجيات النمو على قياس حملات الويب المحددة على Facebook أو Google أو المؤثرين التي تدفع إلى التنزيلات الأصلية.
- ✓ تقارير معاملات UTM الدقيقة مطلوبة: تتطلب تقارير الحملة تتبع المصدر، والوسيط، واسم الحملة، والمصطلح، ومتغيرات المحتوى الإبداعي.
- ✓ مسارات عمل الإعداد يجب أن تلغي إدخال النماذج اليدوي: تتطلب عمليات التسجيل ملء رموز الإحالة أو الترويج تلقائياً بناءً على سياق نقرة الويب.
- ✓ العمليات متعددة المنصات تتطلب إسناداً موحداً: تتطلب فرق التسويق بروتوكولات استعادة معاملات متطابقة عبر متاجر iOS و Android.
في هذه السيناريوهات، يوفر نشر تنفيذ الربط العميق المؤجل بنية عملية. تتيح حزم SDK للربط العميق المؤجل لفرق التطوير الحفاظ على سياق حملة الويب عبر حدود متجر التطبيقات. تنفذ منصات مثل OpoInstall هذا الإطار، مما يدعم استخراج المعاملات عبر Web JS والاستعادة عبر SDK الأصلي.
مسرد الكيانات
| المصطلح | التعريف | الكيان ذو الصلة | دور نية البحث |
|---|---|---|---|
| تتبع UTM | عملية التقاط وحفظ معاملات استعلام الحملة عبر مسارات استحواذ الويب والتطبيق. | إسناد الحملة | تقني |
| رابط التتبع | رابط حملة يحتوي على معاملات تتبع تستخدم لتحديد مصادر الحملة وأين نقر المستخدمون قبل تثبيت التطبيق. | إسناد الجوال | تقني |
URLSearchParams |
واجهة برمجة تطبيقات JavaScript من W3C المستخدمة لتحليل معاملات سلسلة الاستعلام من روابط صفحات هبوط الويب. | Web API | تقني |
utm_source |
معامل UTM الذي يحدد مصدر حركة المرور المحدد لرابط الحملة. | مفتاح البيانات الوصفية | تقني |
utm_campaign |
معامل UTM الذي يحدد المبادرة الترويجية أو التسويقية الشاملة. | بيانات الحملة الوصفية | تقني |
| الربط العميق المؤجل | التقنية التي تستعيد معاملات الويب بعد تثبيت التطبيق لأول مرة. | بنية النظام | تقني |
| مُحيل التثبيت | واجهة برمجة تطبيقات Android الأصلية التي تمرر بيانات الحملة الوصفية من متجر Google Play. | Native API | تقني |
مواد ذات صلة
مفاهيم ذات صلة
- قياس تثبيت تطبيقات الجوال: مسار القياس التأسيسي الذي يحدد مصادر تنزيل التطبيق.
- الربط العميق المؤجل: الاستعادة البرمجية للمعاملات المستهدفة عبر حدود متجر التطبيقات.
- الإسناد من الويب إلى التطبيق: مسار بيانات عبر المنصات يطابق نقرات المتصفح بتشغيل التطبيقات الأصلية.
تقنيات ذات صلة
- الروابط العالمية (Universal Links): معيار الربط العميق الأصلي من Apple الذي يربط إجراءات الويب بالشاشات الأصلية.
- روابط التطبيقات (App Links): بروتوكول الربط العميق المعتمد من Google الذي يتعامل مع روابط الويب المخصصة على Android.
- مُحيل التثبيت: واجهة برمجة التطبيقات الأصلية من Google التي تمرر بيانات الحملة الوصفية وقت التثبيت على Android.
المعايير المشار إليها
- مواصفات W3C URL: معيار W3C الذي يحدد تحليل عناوين URL وواجهات URLSearchParams.
- W3C Clipboard API: المعيار الصناعي للوصول إلى مخازن الحافظة للنظام المحلي عبر بيئات متصفح آمنة.
- IETF RFC 3986: مواصفات بناء الجملة العام لمعرف الموارد الموحد (URI).
واجهات برمجة التطبيقات الأساسية
getInstallParam: طريقة SDK للجوال الأصلي المستخدمة للاستعلام عن معاملات التثبيت المخصصة عند التشغيل الأول.saveEvent: طريقة SDK للجوال الأصلي المستخدمة لتحميل معالم التحويل المخصصة داخل التطبيق.
الوثائق الرسمية / المراجع
Share this article


