ما هي مكونات بيانات الحدث؟

هذا هو الجزء الرابع من سلسلة مكونة من خمسة أجزاء حول بيانات العميل. فيما يلي الأجزاء الأول والثاني والثالث.

تتكون بيانات العميل من بيانات الأحداث وبيانات الكيان — أنت تعرف هذا بالفعل إذا كنت قد مررت بالجزء الأول (ما المقصود ببيانات العميل؟).

في هذا الدليل ، ستتعرف على مكونات بيانات الحدث ، واصطلاح التسمية المفضل لتعريف الأحداث ، وفئات بيانات الكيان ، والنوعين الرئيسيين من الكيانات.

بيانات الحدث

نظرًا لأنك ربما اشتريت أشياء عبر الإنترنت ، فلنبدأ بمثال للتجارة الإلكترونية.

عند التفاعل مع تطبيق التجارة الإلكترونية (الويب أو الهاتف المحمول) ، فإنك تشتري عادةً منتجًا عن طريق إضافته إلى عربة التسوق الخاصة بك ، والمتابعة إلى الخروج ، وإكمال الدفع - هذه هي الأحداث التي تقوم بها عندما تمر بعملية شراء عنصر على التطبيق.

ومع ذلك ، فإن رحلة المشتري ليست بهذه البساطة وهناك العديد من الأحداث الأخرى التي يمكن أن تحدث مثل:

• يتم عرض المنتج
• يتم عرض العربة
• تمت إزالة منتج من عربة التسوق
• يتم تطبيق قسيمة
• يتم اختيار العنوان
• يتم اختيار طريقة الدفع
• الطلب مكتمل

وهلم جرا.

تتبادر إلى الذهن الأحداث الشائعة مثل Add to Cart و Proceed to Checkout و Make Payment ، ولكن لفهم سلوك المستخدم ، يحتاج المرء أيضًا إلى تتبع الأحداث الأخرى مثل تلك المذكورة أعلاه.

يعد تحديد الأحداث التي يجب تتبعها وتسميتها باستخدام اصطلاح تسمية مناسب أول خطوتين في عملية جمع بيانات الحدث.

ما هي الخطوتين التاليتين؟

سعيد لأنك سألت!

كل حدث مصحوب بخصائص الحدث (أو سمات الحدث ) التي توفر مزيدًا من السياق حول الحدث. يعد تحديد الخصائص التي سيتم ربطها بحدث وتسمية تلك الخصائص هما الخطوتان التاليتان في عملية جمع بيانات الحدث.

ما في الاسم؟

عندما يتعلق الأمر بالبيانات ، كل شيء.

إن اصطلاح التسمية أو التصنيف المناسب هو ما يجعل البيانات الجيدة تبرز من البيانات السيئة وتمكن أصحاب المصلحة من فهم ما يبحثون عنه. من ناحية أخرى ، يعد عدم الحفاظ على تصنيف موحد أحد الأسباب الرئيسية لانحراف مجموعات البيانات أو تضخمها مع التكرار.

أيضًا ، عند العمل مع بيانات العميل ، فإن عدم الحفاظ على غلاف موحد عند تسمية الأحداث وخصائص الأحداث هو أحد أكبر الأخطاء التي يمكن أن ترتكبها - خطأ يمكن أن يكون له تداعيات طويلة المدى. يجب أن يكون اصطلاح التسمية الجيد دائمًا مصحوبًا بإرشادات غلاف صارمة.

هذا هو السبب:

إضافة إلى عربة التسوق ، added_to_cart ، product added ، add to cart ، added to cart ، Product added هي طرق مختلفة لتحديد نفس الحدث.

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

أصبح اصطلاح تسمية إجراء الكائن إلى حد كبير معيار الصناعة ولسبب وجيه - فهو يصف بوضوح الإجراء الذي تم بالفعل. المنتج المضاف يعني بالتأكيد أن الكائن (المنتج) يتبعه إجراء (مضاف).

تعرف على المزيد حول إعداد تصنيف متسق لأحداثك .

مكونات بيانات الحدث

هناك مكونان رئيسيان للحدث - كيان (واحد أو أكثر) وخصائص الحدث.

يوفر إقران بيانات الكيان مثل user_id بحدث معلومات حول المستخدم الذي أجرى الحدث.

في حالة عدم وجود معرف فريد مثل user_id ، ستظل بيانات الحدث مجهولة ولن تكون هناك طريقة لمعرفة من أجرى الحدث المذكور. وبالمثل ، في سياق B2B SaaS ، حيث يمكن أن يكون المستخدم جزءًا من مؤسسات متعددة ، يجب ربط معرف المنظمة بأحداث لمعرفة مكان وقوع الأحداث.

إلى جانب الكيانات ، هناك أجزاء أخرى من المعلومات يمكن جمعها لغرض التحليل والتجزئة عند وقوع الأحداث.

بالعودة إلى مثال التجارة الإلكترونية ، عند شراء منتج ما ، إلى جانب معرفة من قام بالشراء ، على الأقل ، تحتاج أيضًا إلى معرفة المنتج الذي تم شراؤه وبأي سعر ومتى .

يتم جمع هذه المعلومات الإضافية في شكل خصائص الحدث .

في الجزء الأول من هذه السلسلة ، تمت الإشارة إلى أن بيانات الحدث تشتمل على ثلاثة عناصر رئيسية:

• الفعل أو الحدث الذي وقع
• الطابع الزمني أو التاريخ الدقيق والوقت الذي وقع فيه الحدث
• الحالة أو جميع الخصائص الأخرى المرتبطة بالحدث (المعروفة باسم خصائص الحدث)

لنلقِ نظرة على الحدث تمت إضافة المنتج (الاسم في الحالة المناسبة وفقًا لإطار عمل الكائن للحدث إضافة إلى عربة التسوق ) ونفترض أنه تم إجراؤه بواسطة مستخدم في 1 يناير 2020 ، الساعة 10 صباحًا بالتوقيت العالمي المنسق. البيانات التي تم جمعها عند وقوع الحدث تشمل ما يلي:

• الإجراء: تمت إضافة المنتج
• الطابع الزمني: 1577872800 (الطابع الزمني لـ Unix في ABZ 7.99 ( الحالة: 0123 ABZ 7.99 ( وفقًا لهذا المثال ، الخصائص المرتبطة بالحدث " تمت إضافة المنتج " هي user_id و product_id والسعر والكمية ، وكل منها يوفر مزيدًا من المعلومات حول الحدث. الطابع الزمني مرتبط بالحدث لمعرفة وقت حدوثه.

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

  التصنيف الموصى به للطوابع الزمنية هو اسم الحدث متبوعًا بـ "at": product_added_at للحدث "تمت إضافة المنتج".

  ربما لاحظت بالفعل أن snake_case تُستخدم لتعريف خصائص الحدث مما يجعل من السهل تمييز أسماء الأحداث عن خصائص الحدث. ومع ذلك ، ضع في اعتبارك أنه لا توجد قواعد محددة مسبقًا هنا ويجب عليك اختيار ما يناسبك أنت وفريقك.

  فيما يلي نظرة أخيرة على الخصائص المرتبطة بالحدث "تمت إضافة المنتج" وأنواع البيانات لكل خاصية من هذه الخصائص:

  

  يضمن تحديد نوع البيانات لكل خاصية اتساق البيانات ويجعل عملية الأجهزة أسهل.

  

  ملاحظة جانبية: من الجيد أن تضع في اعتبارك أن يجب أن يكون واضحًا الآن أن جمع بيانات الحدث يشمل الخطوات التالية:

  • تحديد الأحداث التي يجب تتبعها
  • تسمية تلك الأحداث باستخدام اصطلاح تسمية مناسب
  • تحديد الخصائص التي سيتم ربطها بكل حدث
  • تسمية تلك الخصائص باستخدام اصطلاح تسمية مناسب

  يغطي الجزء التالي (والأخير) من هذه السلسلة عملية تحديد الأحداث التي يجب تتبعها والبيانات التي يجب جمعها.

  ومع ذلك ، يجب أن تكون لديك فكرة جيدة عما يمكن توقعه عند النظر إلى بيانات الحدث (سواء في خطة تتبع قبل استخدام الأجهزة أو داخل وجهة بيانات مثل أداة تحليلات المنتج).

  بعض الأحداث المشتركة وخصائصها

  قبل الانتقال ، ألق نظرة على بعض الأحداث والخصائص الشائعة التي تتبعها معظم المنتجات التقنية.

  

  أنواع الكيانات

  حان الوقت لإلقاء نظرة متعمقة على الكيانات المختلفة وخصائصها. إذا لم تكن قد قمت بذلك بالفعل ، فانتقل إلى هذا الدليل لفهم كيفية ارتباط بيانات الكيان ببيانات الحدث.

  في الجزء الأول من هذه السلسلة ، تم ذكر أن البيانات التي يشاركها المستخدمون تندرج تحت بيانات الكيان. في حين أن هذا صحيح ، لا يتم مشاركة جميع بيانات الكيان من قبل المستخدمين أنفسهم - يمكن أيضًا إنشاء بيانات الكيان.

  تشتمل بيانات الكيان على الخصائص المرتبطة بالكيان - إذا كان المستخدم هو الكيان ، فسيتم جمع جميع المعلومات حول المستخدم في شكل خصائص المستخدم.

  يتم إنشاء User_id لكل مستخدم بشكل افتراضي من أجل تحديد المستخدمين (ويعمل كمعرف للأحداث.)

  بعد قولي هذا ، في الوقت الحالي ، انسَ الأحداث وفكر في أجزاء مختلفة من المعلومات التي تتعلق حصريًا بالمستخدمين وتخبرك بسماتهم.

  أنواع بيانات الكيان

  يمكن تصنيف بيانات الكيان في المجموعات التالية (المذكورة أيضًا في الجزء 3 من هذه السلسلة):

  • معلومات التعريف الشخصية مثل الديموغرافيات مثل شخصية مثل التفضيلات مثل البيانات الخاصة بالمنتج مثل تقع أجزاء البيانات الموجودة ضمن كل مجموعة ضمن خصائص المستخدم. بمعنى آخر ، تخزن خصائص المستخدم تفاصيل وسمات مختلفة حول المستخدمين ، مما يتيح لك التعرف عليهم ومعرفة المزيد عنهم.

    بينما تأتي معظم المعلومات من المستخدم مباشرةً ، يتم إنشاء بعض خصائص المستخدم تلقائيًا بمرور الوقت نتيجة لاستخدام المنتج.

    ولكن ألا يتم إنشاء بيانات الأحداث أيضًا بسبب استخدام المنتج؟

    من المؤكد أن - خصائص المستخدم هي تفاصيل إضافية مرتبطة بحدث تم جمعه عند وقوع الحدث. دعنا نلقي نظرة على حدث التسجيل وخصائصه :

    

    كما ترى ، توفر جميع الخصائص المرتبطة بهذا الحدث تفاصيل حول المستخدمين — التفاصيل التي يشاركها المستخدمون أنفسهم ( الاسم_الأول ، الاسم_الأخير ، البريد الإلكتروني ، الهاتف ، الدولة ) أو التفاصيل التي يتم إنشاؤها تلقائيًا ( مُوقع_على_ت ، معرف_المستخدم ).

    من المفيد أن تضع في اعتبارك ما يلي:

    • يتم تنفيذ بعض الأحداث مثل التسجيل أو معظم خصائص المستخدم التي تمنع الطوابع الزمنية والمعرفات عرضة للتغيير. يمكن للمستخدم تغيير اسمه ، والبريد الإلكتروني ، والهاتف ، والموقع ، والصناعة ، والدور الوظيفي ، وما إلى ذلك. ولكن لا يمكن للمستخدم تغيير وقت التسجيل (sign_up_at) أو المعرف الفريد (user_id).

    خصائص المستخدم مقابل خصائص المؤسسة

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

    في سياق B2B SaaS ، يعتبر المستخدم والمنظمة الكيانان الرئيسيان ، وترتبط الأحداث المجمعة بمستخدم أو مؤسسة (أو كليهما).

    قد يكون هناك كيانات مجموعة أخرى مثل الفريق أو المشروع مع أجزاء معينة من البيانات مرتبطة بها ، كما هو الحال مع معظم أدوات الإنتاجية - عملية جمع بيانات المنظمة قابلة للتطبيق في مثل هذه الحالات أيضًا.

    دعنا نلقي نظرة على بعض خصائص المستخدم الشائعة ذات الصلة بمنتجات B2B SaaS:

    

    عندما يكون المستخدم جزءًا من مؤسسة ، يتم ربط العديد من المعلومات المهمة بالمنظمة وليس بالمستخدم.

    بعض خصائص المؤسسة العامة (يشار إليها أيضًا باسم خصائص المجموعة ) هي كما يلي:

    

    من المهم أن تضع في اعتبارك أن Organization_id يعمل أيضًا كمعرف ويجب أن يكون مرتبطًا بأحداث لمعرفة المنظمة التي تم بموجبها حدث معين.

    يمكن أن يساعد وضع العبارات التالية في الاعتبار على التمييز بين خصائص المستخدم وخصائص المؤسسة:

    • يتم تخزين كل جزء من المعلومات التي تساعد في تحديد مجموعات المستخدمين - من أين أتوا ، ومن هم ، وما هو هدفهم ، أو ما يفعلونه داخل منتج - كخاصية مستخدم .
    • يتم تخزين كل معلومة تساعد في تقسيم الحسابات أو المؤسسات - نوع الحساب ، أو الإيرادات التي يحققها ، أو المنتجات أو الميزات التي يستخدمها ، أو الموارد التي يستهلكها ، أو عدد المستخدمين الذين يشكلون جزءًا منها - كخاصية للمؤسسة ( أو خاصية المجموعة).

    بمجرد أن تتمكن من التمييز بين ما سبق ، يصبح من السهل إدخال كيانات جديدة (مثل الفرق أو المشاريع) في هذا المزيج.

    الخطوات التالية

    يجب أن يكون لديك الآن فهم واضح لكيفية تعريف الأحداث والخصائص المرتبطة بها ، وكذلك تحديد خصائص كل كيان (مستخدم ومؤسسة).

    لبدء تحديد الأحداث وتنظيم بياناتك اليوم ، ابدأ بحساب Amplitude مجاني.