ما هي الكيانات في سياق بيانات الحدث؟

هذا هو الجزء الثالث من السلسلة المكونة من خمسة أجزاء حول بيانات العميل. هنا الجزء الأول والثاني . يوصى بشدة بالاطلاع على الجزء الأول قبل قراءة هذا المنشور.

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

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

• كم عدد المستخدمين الفريدين الذين أجروا الحدث "تم إرسال الحملة" ؟
• من هم المستخدمون الذين قاموا بهذا الحدث؟
• ما هو متوسط ​​عدد الأحداث التي قامت بها شريحة المستخدم قبل تنفيذ الحدث "تم الإرسال " لأول مرة؟
• ما الأحداث التي تم تنفيذها بواسطة شريحة المستخدم قبل هذا الحدث؟

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

دعونا نحفر أعمق.

حدث واحد ، كيانات متعددة

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

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

• كم عدد الحسابات المفعلة؟
• ما هو متوسط ​​عدد المستخدمين للحسابات النشطة؟
• كم عدد الحسابات التي تحتوي على X أو أكثر من المستخدمين؟

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

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

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

على سبيل المثال ، إذا أنشأ المستخدم John Doe مشروعًا جديدًا داخل تطبيق إدارة مشروع تستخدمه مؤسسة Acme Corp مع 10 مستخدمين ، فسيتم إنشاء قسمين مهمين من المعلومات:

1. أنشأ John Doe مشروعًا جديدًا: أجرى John Doe الحدث Project Created
2. تم إنشاء مشروع جديد داخل منظمة Acme Corp: حدث المشروع الذي تم إنشاؤه داخل منظمة Acme Corp

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

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

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

مستخدم واحد ، حسابات متعددة

من الشائع جدًا أن يرتبط المستخدم بحسابات متعددة في سياق أدوات SaaS. Notion و ClickUp و Integromat هي بعض الأدوات الشائعة التي تسمح لمستخدم فريد بالانضمام أو إنشاء عدة مؤسسات أو مساحات عمل ، لكل منها اشتراك مميز.

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

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

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

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

ليس مجرد معرف

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

قد يكون من المفيد تصنيف بيانات الكيان في المجموعات التالية:

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

  المضي قدمًا مع الكيانات وبيانات الأحداث

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

  هل تطرح الأسئلة الصحيحة وتزود المستخدمين بالخيارات ذات الصلة؟ هل تحتاج إلى تعديل هذه الأسئلة أو طرح أسئلة جديدة لفهم شخصيات المستخدم بشكل أفضل؟ ماذا عن اصطلاح تسمية الخصائص أو نوع البيانات لكل خاصية؟

  في حين أنه قد يبدو من الصعب التفكير في كل تلك التفاصيل الدقيقة ، فمن المهم طرح هذه الأسئلة عاجلاً وليس آجلاً للتأكد من أنك تجمع بيانات نظيفة يسهل تحليلها والتصرف بناءً عليها.

  أنت تعرف الآن الدور الذي تلعبه بيانات الكيان في عملية جمع بيانات الحدث مما يعني أن الوقت مناسب لاستكشاف شكل بيانات الحدث في النظام الأساسي لتحليلات المنتج.