الفصل 2 / 9
نموذج البيانات: أربع لبنات أساسية
كل مخطط في Amplitude مبني على أربعة مفاهيم: الحدث (event)، وخاصية الحدث (event property)، وخاصية المستخدم (user property)، والمجموعة (group). إذا فصلتها بشكل صحيح تبقى كل الأسئلة اللاحقة ممكنة؛ وإذا فصلتها بشكل خاطئ تصبح بعض الأسئلة مستحيلة.
- ستقرأ أجزاء سجلّ الـ event ووظيفة كل جزء.
- ستقرّر ما إذا كانت المعلومة event property أم user property.
- ستفهم كيف يؤثّر سلوك "القيمة في تلك اللحظة" لخصائص المستخدم على التحليل.
أربعة مفاهيم
| المفهوم | المعنى | مثال | أقرب ما يقابله في Adjust |
|---|---|---|---|
| Event | فعل واحد قام به المستخدم، مع طابع زمني | Product Viewed، Checkout Completed | Event معرَّف بـ event token |
| Event property | سياق ذلك الفعل في تلك اللحظة | category = headphones، price = 49.9 | معاملات callback / partner |
| User property | صفة دائمة للمستخدم؛ تنتقل قيمتها الأخيرة إلى الـ events اللاحقة | plan = premium، orders_count = 3 | لا يوجد مقابل مباشر؛ حقول الـ attribution هي الأقرب |
| Group | الحساب أو المؤسسة التي ينتمي إليها المستخدم | company_id = 8812 | لا يوجد |
تشريح الـ event
كل event يُرسل إلى Amplitude هو سجلّ يشبه المثال أدناه. تملأ الـ SDKs معظم هذه الحقول تلقائيًا؛ عادةً تقدّم أنت فقط اسم الـ event والخصائص.
{
"event_type": "Checkout Completed", // what they did
"time": 1762243200000, // when (ms)
"user_id": "cust_88231", // who (ID in your system)
"device_id": "8F3A2C1E-…", // which device
"platform": "iOS", // filled by the SDK
"country": "Saudi Arabia", // derived from IP
"event_properties": { // context of this action
"order_id": "ORD-5521",
"revenue": 129.5,
"currency": "SAR",
"items_count": 3,
"payment_method": "apple_pay"
},
"user_properties": { // user state at this moment
"plan": "premium",
"orders_count": 4,
"acquisition_network": "Meta" // example: source from an integration
}
}اقرأ هذا السجلّ كجملة: في 4 نوفمبر، على iOS، وبينما كان على خطة premium وقد جاء عبر Meta، أكمل cust_88231 طلبًا من 3 منتجات بقيمة 129.5 ريال باستخدام Apple Pay. كل مخططات Amplitude هي عدّ هذه الجمل بطرق مختلفة.
acquisition_network اسم مختلَق للمثال. الأسماء الفعلية للحقول التي يرسلها تكامل Adjust إلى Amplitude موجودة في توثيق التكامل (الفصل 7).
Event property أم user property؟
القاعدة بسيطة: هل المعلومة تخصّ ذلك الفعل أم تخصّ ذلك الشخص؟ مبلغ الطلب يخصّ الطلب، فهو event property. خطة الاشتراك تخصّ الشخص وتسري على كل فعل لاحق، فهي user property.
| المعلومة | المكان الصحيح | السبب |
|---|---|---|
| فئة المنتج المعروض | Event property | تختلف في كل مشاهدة |
| مبلغ الطلب | Event property | خاص بذلك الطلب |
| خطة الاشتراك | User property | حالة الشخص حتى تتغيّر |
| إجمالي عدد الطلبات | User property (بالزيادة) | حالة الشخص التراكمية |
| قناة الاكتساب (من Adjust) | User property | تُنسب للشخص مرة واحدة وتقسّم كل سلوكه |
| طريقة الدفع | Event property (ويمكن أيضًا user property باسم "آخر طريقة دفع") | قد تتغيّر في كل طلب |
| لغة التطبيق | User property (غالبًا تجمعها الـ SDK تلقائيًا) | إعداد الجهاز/الشخص |
كيف تتصرّف خصائص المستخدم عبر الزمن؟
بمجرد تعيين user property، تُختم قيمتها على كل event لاحق حتى تتغيّر. والقيمة المختومة على الـ event هي قيمتها لحظة وقوعه. لهذا يُجاب بشكل صحيح عن سؤال "هل اشترى وهو على premium أم على free؟".
تعيين الـ user property بعد الـ event. إذا أرسلت Subscription Started أولًا ثم تحديث الخطة عند الترقية، فإن ذلك الـ event نفسه سيبقى يحمل plan = free. اكتب الترتيب صراحةً في خطة التتبّع.
طرق تغيير الـ user property
توفّر الـ SDKs عدة عمليات لخصائص المستخدم. العملية التي تختارها تحدّد كيف تتراكم القيمة عبر الزمن.
| العملية | ماذا تفعل | متى تُستخدم |
|---|---|---|
set | تستبدل القيمة | الخطة، اللغة، آخر طريقة دفع |
setOnce | تعيّن في المرة الأولى فقط وتتجاهل ما بعدها | تاريخ التسجيل الأول، قناة الاكتساب الأولى |
add | تزيد/تنقص قيمة رقمية | عدد الطلبات، إجمالي الإنفاق |
append / prepend | تضيف عنصرًا إلى مصفوفة | الفئات التي يهتم بها |
unset | تحذف الخاصية | معلومة لم تعد صالحة |
لماذا يهمّ نوع الخاصية؟
يتيح Amplitude العمليات على الخاصية حسب نوع قيمتها. القيمة المرسلة كرقم يمكن حساب مجموعها ومتوسطها وتوزيعها. إذا أُرسلت القيمة نفسها كنص، فيمكنك فقط التصفية بالتساوي والتجميع.
يقيّد التحليل
"price": "49.9"نص، لا يمكن حساب المتوسط"is_first_order": "yes"يُرسل في أماكن مختلفة كـ "Yes" و "true" و "1""category": "Headphones"في منصة، و"headphones"في أخرى
مفتوح للتحليل
"price": 49.9رقم، يمكن حساب المجموع والمتوسط"is_first_order": trueنوع boolean واحد"category": "headphones"بأحرف صغيرة في كل مكان، وقائمة ثابتة
المعلومات التي تُجمع تلقائيًا
تضيف الـ SDKs مجموعة من الحقول إلى كل event تلقائيًا: المنصة، نظام التشغيل وإصداره، طراز الجهاز، إصدار التطبيق، اللغة، والدولة والمدينة المشتقّتان من الـ IP. لا تحتاج إلى إرسالها كخصائص. ويمكن للـ SDKs الأحدث أيضًا التقاط بعض الـ events تلقائيًا مثل بدء الجلسة أو مشاهدة الصفحة (autocapture).
الحقول والـ events التي تُجمع تلقائيًا تعتمد على الـ SDK وإصداره وإعداداته. للعملاء الذين لديهم متطلبات خصوصية (مثل عدم جمع الـ IP أو المدينة)، راجع توثيق الـ SDK لمعرفة كيفية إيقافها.
Group: التحليل على مستوى الحساب
في منتجات B2B يكون السؤال غالبًا "أي شركة" لا "أي مستخدم". الـ group تربط المستخدمين بحساب وتسمح للمخططات بعدّ الحسابات بدل المستخدمين: "كم شركة أنشأت تقريرًا هذا الأسبوع؟"
قد يُباع التحليل على مستوى الحساب كإضافة منفصلة في Amplitude. تحقّق مما إذا كانت خطة العميل تشمله. تطبيقات Ryze الاستهلاكية النموذجية على الهاتف غالبًا لا تحتاج إليه.
مثال: نموذج صغير لتجارة إلكترونية
| Event | Event properties | User property يُحدَّث مع هذا الـ event |
|---|---|---|
Signup Completed | method (email، apple، google) | signup_date (setOnce) |
Product Viewed | product_id، category، price | – |
Product Added to Cart | product_id، category، price، quantity | – |
Checkout Started | cart_value، items_count | – |
Checkout Completed | order_id، revenue، currency، payment_method | orders_count (add 1)، last_order_date (set) |
خمسة events تكفي للـ funnel والـ retention وتحليل السلة ومقارنة الطلب الأول بالطلبات المتكررة. لاحظ أنه بدل event لكل فئة، استُخدم event واحد مع خاصية category.
خذ قائمة الـ event tokens لأحد العملاء في Adjust. قرّر لكل event: هل يبقى بالاسم نفسه في Amplitude، أم يجب دمج عدة events من Adjust في event واحد مع خاصية (مثلًا purchase_tier1 و purchase_tier2 ← Purchase + tier)، وأي معلومة تخصّ الشخص فيجب أن تكون user property.