تتبع الأحداث في تطبيقات الجوال: ما هو، أنواع الأحداث وكيفية الإعداد

ما هو Event Tracking؟

Event Tracking هو عملية جمع، تخزين وتحليل إجراءات المستخدم المنفصلة داخل التطبيق. يتكون كل حدث من اسم (event_name) ومجموعة من المعلمات (event_params). على سبيل المثال، حدث purchase يحتوي على المعلمات price، currency، product_id، quantity.

على عكس Screen View، الذي يسجل فقط فتح الشاشة، فإن Event Tracking يصف ما يفعله المستخدم بالضبط على تلك الشاشة: نقر زر “شراء”، فتح سلة التسوق، تطبيق كود ترويجي. بدون الأحداث، من المستحيل فهم دوافع المستخدم وسياق إجراءاته.

هيكل الحدث

كل Analytics Event يحتوي على حقول إلزامية واختيارية. الحقول الإلزامية: event_name، event_timestamp، user_id (أو device_id). الحقول الاختيارية: معلمات تصف السياق.

معلمة revenue مهمة بشكل خاص — يتم إرسالها إلى منصات MMP للحساب التلقائي لـ ROAS و LTV.

أنواع الأحداث في التحليلات الجوالة

تصنف الأحداث حسب المصدر والغرض. يساعد هذا التقسيم في تنظيم هيكل البيانات وتحديد حقوق الوصول للفرق المختلفة.

الأحداث التلقائية (SDK)

تقوم SDK المنصات التحليلية بجمع الأحداث الأساسية تلقائيًا: app_install، app_remove، session_start، screen_view. يولد Firebase Analytics حوالي 20 حدثًا تلقائيًا دون سطر واحد من الكود. تغطي هذه الأحداث المقاييس الأساسية، ولكنها لا توفر فهمًا لمنطق الأعمال.

الأحداث المخصصة

الأحداث المخصصة هي ما يجعل Event Tracking قيميًا. هي تصف إجراءات الأعمال: add_to_cart، start_subscription، level_complete، share_content، search_performed. تتطلب الأحداث المخصصة إرسالًا صريحًا من كود التطبيق.

// إرسال حدث مخصص إلى Firebase
val bundle = Bundle().apply {
    putString(AnalyticsParam.ITEM_ID, "prod_789")
    putString(AnalyticsParam.ITEM_NAME, "Premium Subscription")
    putString(AnalyticsParam.CURRENCY, "USD")
    putDouble(AnalyticsParam.PRICE, 29.99)
    putString(AnalyticsParam.SOURCE, "onboarding_screen")
}
FirebaseAnalytics.getInstance(this)
    .logEvent("subscribe_premium", bundle)

في المثال، يحتوي حدث subscribe_premium على أربع معلمات سياق. تسمح معلمة source بمعرفة الشاشة التي اشترك المستخدم منها — الإقلاع، الإعدادات أو paywall.

User Properties و Super Properties

بالإضافة إلى الأحداث، يشمل Event Tracking User Properties — سمات مرتبطة بالمستخدم: مستوى الاشتراك، الدولة، إصدار التطبيق. يتم إرسال User Property مرة واحدة وتنطبق على جميع أحداث الجلسة اللاحقة. يسمح هذا بتجزئة التحليلات دون إضافة معلمات إلى كل حدث.

Super Properties (Amplitude) أو Global Properties (Mixpanel) — سمات مرتبطة بالجلسة، ليست بالمستخدم. تستخدم لاختبارات A/B: variant_id كـ Super Property يضاف إلى جميع أحداث الجلسة، ويستطيع المحلل معرفة المجموعة التي ينتمي إليها المستخدم.

أحداث الإيرادات

أحداث الإيرادات هي فئة منفصلة لتسجيل المعاملات. تحتوي على المبلغ، العملة ونوع الشراء (اشتراك، شراء لمرة واحدة، استعادة). تتطلب منصات MMP (AppsFlyer، Adjust) أحداث الإيرادات لحساب ROAS.

وفقًا لـ Branch (2024)، التطبيقات التي تنقل أحداث الإيرادات بشكل صحيح إلى MMP تحصل على بيانات إسناد أكثر دقة بنسبة 25%، ويمكنها تحسين الحملات بناءً على LTV بدلاً من CPI.

كيفية إعداد Event Tracking؟

تتم إعداد Event Tracking عبر ثلاث مراحل: تخطيط مخطط الأحداث، دمج SDK والتحقق من صحة البيانات.

المرحلة 1: تصميم مخطط الأحداث

قم بإنشاء Event Taxonomy — وثيقة تصف كل حدث: الاسم، المعلمات، محفز الإرسال، المالك. مثال للتجارة الإلكترونية: order_completed → المعلمات: order_id، total_price، items_count، payment_method، shipping_city.

• كل حدث يجيب على السؤال: ماذا فعل المستخدم؟
• كل معلمة تجيب على السؤال: في أي سياق؟
• تجنب الأحداث دون معلمات — فهي غير مفيدة للتحليل

المرحلة 2: دمج SDK

قم بدمج SDK التحليلات في المشروع. Firebase Analytics، Amplitude، Mixpanel — أي SDK يتطلب التهيئة في Application.onCreate(). مثال لـ Flutter:

import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsService {
  final _analytics = FirebaseAnalytics.instance();

  Future<void> logPurchase({
    required String productId,
    required double price,
    required String currency,
  }) async {
    await _analytics.logEvent(
      name: 'purchase_completed',
      parameters: {
        'product_id': productId,
        'price': price,
        'currency': currency,
        'timestamp': DateTime.now().millisecondsSinceEpoch,
      },
    );
  }
}

تقوم فئة AnalyticsService بتركيز إرسال جميع الأحداث. كل طريقة تتوافق مع إجراء أعمال. يبسط هذا العثور على المصدر — إذا لم يصل حدث، تبحث باسم الطريقة في الكود. عند توسع المشروع، قد يصل عدد الطرق إلى 50–100، ولكن يبقى الهيكل قابلًا للقراءة بفضل التجميع حسب الوظيفة.

المرحلة 3: التحقق من الصحة عبر DebugView

يتيح Firebase DebugView رؤية الأحداث في الوقت الفعلي على جهاز المطور. قم بتفعيله: adb shell setprop debug.firebase.analytics.app your.package. ستظهر جميع الأحداث في وحدة تحكم Firebase بتأخير أقل من 5 ثوان.

بعد تفعيل DebugView، افتح التطبيق ونفذ سيناريو اختباري — تسجيل، شراء، تصفح الكاتالوج. في وحدة التحكم، تحقق: هل تم إرسال جميع الأحداث، هل تم نقل المعلمات الصحيحة، هل هناك تكرار. تقدم Amplitude أداة مماثلة — Amplitude Debugger لـ iOS و Android.

التحقق الآلي عبر CI/CD هو المستوى التالي من الجودة. أضف نصًا برمجيًا في خط التجميع يتحقق من أن كل حدث من المخطط تم إرساله مرة واحدة على الأقل أثناء تشغيل الاختبار. يمنع هذا نشر الإصدارات بأحداث مفقودة ويوفر وقت مهندسي QA.

أفضل ممارسات تسمية الأحداث

تسمية الأحداث هي الجانب الأكثر إهمالًا في Event Tracking. الاسم غير الصحيح يجعل التحليلات غير مفيدة عندما يحتوي المشروع على أكثر من 50 حدثًا.

معيار كائن + إجراء

استخدم نمط object_action (أحرف صغيرة، snake_case): product_added، cart_opened، payment_failed، subscription_cancelled. الكائن هو الكيان، الإجراء هو الفعل في الماضي. يقرأ كالجملة: “تمت إضافة المنتج”، “تم فتح السلة.”

• product_viewed، ليس “tap_on_product_card” (الحدث نتيجة، ليس إجراء)
• order_completed، ليس “successful_payment_transaction” (قصير وواضح)
• level_started، ليس “begin_level_with_parameters” (دون كلمات زائدة)

الأنماط المحظورة

لا تستخدم المسافات (“Add to Cart”)، CamelCase (“AddToCart”)، النقاط (“add.to.cart”)، أو الشرطات (“add-to-cart”). توصي معظم SDK باستخدام snake_case. لا تستخدم أسماء عناصر واجهة المستخدم (“btn_submit_clicked”) — يجب أن يكون الحدث تجاريًا، ليس تقنيًا.

بالنسبة لـ البوادئ، أضف اسم الوظيفة أو الشاشة: onboarding_step_completed، checkout_payment_selected. يسمح هذا بتصفية الأحداث حسب الوظيفة في التقارير.

أنواع معلمات الأحداث

تنقسم المعلمات إلى ثلاثة أنواع: string (قيمة)، number (رقم للتجميع)، boolean (علامة). تحتوي معلمات string على بيانات فئوية: الدولة، مصدر الزيارة، اسم المنتج. تخدم معلمات number للمقاييس: السعر، الكمية، المدة. تشير معلمات boolean إلى الحالة: is_trial، is_promo_applied.

تجنب نقل الكائنات أو المصفوفات في معلمة واحدة — لا تستطيع المنصات التحليلية تحليلها. بدلاً من سلسلة JSON في حقل واحد، قم بنقل عدة معلمات منفصلة. على سبيل المثال، بدلاً من items_count_total، قم بنقل items_count و total_price بشكل منفصل.

المنصات لتتبع الأحداث

يعتمد اختيار منصة Event Tracking على حجم المشروع والفريق. لننظر إلى ثلاث خيارات من مستويات مختلفة.

Firebase Analytics (مجاني، حتى 500 حدث)

Firebase هو الخيار القياسي للشركات الناشئة. الحد المجاني — 500 event_name مختلف، عدد غير محدود من المعلمات. التكامل مع BigQuery للتحليلات المخصصة. السلبيات: تجزئة محدودة، عدم وجود ربط تلقائي للأحداث داخل الجلسات.

Amplitude (Pro من $1,000/شهر)

Amplitude هي منصة لتحليلات المنتج. تدعم المجموعات السلوكية، تحليل المسار، Pathfinder. تسمح بإنشاء أحداث افتراضية من مجموعات الأحداث الحقيقية. تتكامل مع أكثر من 50 أداة عبر Segment.

Segment (من $120/شهر)

Segment هو وسيط لإدارة الأحداث. ترسل الأحداث إلى Segment، وهو يوزعها على أكثر من 300 أداة. مفيد في البيئات المؤسسية حيث تستخدم Firebase، Amplitude، Mixpanel، Braze و Salesforce معًا.

PostHog (بديل open-source)

PostHog هي منصة تحليلات منتج مفتوحة المصدر مع Event Tracking الخاص بها. تدعم الالتقاط التلقائي للأحداث، تسجيل الجلسات و feature flags. تنشر على خادم خاص، وهو أمر حاسم للمشاريع التي تتعلق بـ GDPR أو البيانات السرية. توفر API متوافقًا مع Python لخطوط أنابيب ETL.

بالنسبة لمشاريع Flutter، يوصى باستخدام flutterfire_analytics + Amplitude عبر الإضافة amplitude_flutter. وبالنسبة لـ React Native — react-native-firebase + mixpanel-react-native.