الفصل 6 / 9
خطة التتبّع والحوكمة
يقبل Amplitude كل ما ترسله. فبينما يرفض Adjust أي token غير معرَّف، ينشئ Amplitude بصمت event جديدًا من اسم مكتوب بشكل خاطئ. الضمان الوحيد لجودة البيانات هو خطة تتبّع تُكتب قبل التكامل وتُصان بعده.
- ستعرف الحقول التي يجب أن يتضمّنها صف خطة التتبّع.
- ستضع قاعدة تسمية متّسقة.
- ستبني دورة تتحقق من الخطة قبل الإطلاق وتحميها بعده.
لماذا تأتي الخطة أولًا؟
في المشاريع غير المنضبطة يزداد عدد أسماء الـ events مع الوقت، بينما لا يزداد عدد الأسئلة. يصل الفعل نفسه بثلاثة أسماء، ويظهر كل منها منفصلًا في المخططات، ولا أحد يعرف أيّها الصحيح.
دورة الخطة
ماذا يتضمّن صف الخطة؟
| الحقل | مثال | لماذا هو ضروري |
|---|---|---|
| اسم الـ event | Checkout Completed | اسم واحد في كل المنصات |
| لحظة الإطلاق | عند ظهور شاشة تأكيد الدفع لأول مرة، مرة واحدة لكل طلب | ليقصد المطوّر والمحلّل اللحظة نفسها |
| المصدر | الخادم (HTTP API)، بعد تحقّق الـ backend من الدفع | يمنع العدّ المزدوج |
| Event properties | order_id نص، revenue رقم، currency نص (ISO 4217) | تثبيت النوع والصيغة |
| User properties المحدّثة | orders_count add 1 | يمنع أخطاء الترتيب |
| المنصات | iOS، Android، الويب | تظهر المنصة الناقصة |
| السؤال الذي يخدمه | التحويل من السلة إلى الدفع، تحليل الإيرادات | تُستبعد الـ events غير الضرورية |
| المقابل في Adjust | Event token abc123 (S2S) | يُتابَع الاتساق بين الأداتين |
قاعدة التسمية
القاعدة التي تختارها أقل أهمية من اختيار قاعدة واحدة. خيار شائع وواضح: أسماء الـ events بصيغة الكائن + فعل ماضٍ بأحرف Title Case (Product Viewed)، وأسماء الخصائص بصيغة snake_case (product_id).
فعل واحد، ثلاثة events
product_view(Android)ProductView(iOS)viewed product(الويب)Product Viewed - Shoes،Product Viewed - Bags(الفئة داخل الاسم)
Event واحد، خصائص غنية
Product Viewedفي كل المنصاتcategory: "shoes"كخاصية- قائمة قيم ثابتة:
shoes،bags،accessories - المنصة تأتي تلقائيًا من الـ SDK ولا تُكرَّر في الاسم
مبدأ "events قليلة وخصائص غنية" يسهّل بناء المخططات أيضًا: "مشاهدات المنتجات حسب الفئة" تقسيم واحد في مخطط واحد. أما مع event لكل فئة، فكل فئة جديدة تعني تعديلًا في الكود ومخططًا جديدًا.
مثال على خطة: تطبيق تجارة إلكترونية
| Event | لحظة الإطلاق | المصدر | Event properties | أثره على user property |
|---|---|---|---|---|
Onboarding Step Viewed | عند ظهور كل شاشة onboarding | SDK | step_number رقم، step_name نص | – |
Signup Completed | عند إنشاء الحساب | SDK | method نص | signup_date setOnce |
Search Performed | عند عرض نتائج البحث | SDK | query_length رقم، results_count رقم | – |
Product Viewed | عند فتح شاشة تفاصيل المنتج | SDK | product_id، category، price رقم، source نص | – |
Product Added to Cart | عند نجاح الإضافة إلى السلة | SDK | product_id، category، price، quantity | – |
Checkout Started | عند فتح شاشة الدفع | SDK | cart_value رقم، items_count رقم | – |
Checkout Completed | عند التحقق من الدفع في الـ backend | HTTP API | order_id، revenue، currency، payment_method | orders_count add 1 |
Push Opened | عند النقر على الإشعار | SDK | campaign_id نص | – |
Subscription Started | عند التحقق من أول اشتراك | HTTP API | plan، period، revenue | plan set (قبل الـ event) |
Subscription Renewed | عند وصول إشعار التجديد من المتجر | HTTP API | plan، period، revenue | – |
خصائص مثل source (من أين وصل المستخدم إلى المنتج: البحث، الصفحة الرئيسية، الإشعار) تقوّي تحليل الـ funnel والمسارات كثيرًا. السؤال الذي يجب طرحه أثناء كتابة الخطة: "وفق أي أبعاد سأرغب في تقسيم هذا الـ event؟"
قائمة التحقق
قبل كل إصدار جديد، تُجرى هذه الفحوص في المشروع التجريبي:
- اسم الـ event مطابق تمامًا لما في الخطة (بما في ذلك حالة الأحرف والمسافات).
- كل الخصائص تصل وبأنواعها الصحيحة (الأرقام كأرقام، والـ boolean كـ boolean).
- يُطلق الـ event في اللحظة المكتوبة في الخطة وبالعدد المتوقع (طلب واحد، event واحد).
- تحديث الـ user property يحدث قبل الـ event أو بعده كما في الخطة.
user_idصحيح بعد تسجيل الدخول ويُعاد تعيينه بعد الخروج.- events الخادم ترتبط بالمستخدم الصحيح ولا تُعدّ مرتين عند إعادة الإرسال.
- build الإنتاج يستخدم مفتاح الإنتاج، و build الاختبار يستخدم مفتاح الاختبار.
- المقابل في Adjust للـ event نفسه يُطلق أيضًا (عند الحاجة).
تُمسح هذه المربعات عند إعادة تحميل الصفحة؛ انسخها إلى قائمتك الخاصة.
بعد الإطلاق: الحوكمة
ستصل بيانات خارج الخطة رغم ذلك: إصدارات قديمة، events تجريبية منسيّة، أخطاء إملائية. تتيح لك أدوات إدارة البيانات في Amplitude أربعة إجراءات:
| الإجراء | ماذا يفعل | متى |
|---|---|---|
| الإخفاء | يُخفي الـ event في الواجهة؛ وتبقى البيانات | events لم تعد مستخدمة لكن يجب حفظ تاريخها |
| الحظر | يوقف معالجة هذا الـ event مستقبلًا | events تجريبية أو معطوبة |
| الدمج / التحويل | يعرض أسماء مختلفة كـ event واحد في التحليل | اختلافات إملائية تاريخية مثل product_view و Product Viewed |
| التحقق مقابل الخطة | يعلّم الـ events والخصائص الخارجة عن الخطة | مراقبة الجودة المستمرة |
الأسماء الحالية لهذه الإجراءات في Amplitude، وأيّها يُطبَّق بأثر رجعي، وفي أي خطة تتوفر، قد تتغيّر. تحقّق خصوصًا مما إذا كان "الحظر" يمسّ البيانات التاريخية قبل إخبار العميل.
في Adjust، قائمة الـ event tokens هي أصلًا خطة تتبّع طبيعية: لا يمكنك إرسال event بدون token. في Amplitude عليك أن تحافظ على هذه القائمة بنفسك. الطريقة الأكثر عملية هي حفظ events الأداتين في الجدول نفسه: عمود لاسم Amplitude وخصائصه، وعمود لـ token في Adjust ومعاملاته. بهذا يظهر فورًا أي event أُضيف في أداة ونُسي في الأخرى.
انطلاقًا من قائمة events الحالية لأحد العملاء في Adjust، اكتب مسودة خطة تتبّع بالقالب أعلاه. املأ عمود "السؤال الذي يخدمه" لكل event. الـ events التي لا تستطيع ملء هذا العمود لها قد لا تستحق النقل إلى Amplitude.