13 مايو 2025·8 دقيقة
بناء تطبيق ويب لتتبع تبنّي المنتج حسب شريحة الحساب
تعلّم كيفية تصميم البيانات، الأحداث، ولوحات المعلومات لقياس تبنّي المنتج عبر شرائح الحسابات، واتخاذ إجراءات بناءً على الرؤى باستخدام التنبيهات والأتمتة.
تعلّم كيفية تصميم البيانات، الأحداث، ولوحات المعلومات لقياس تبنّي المنتج عبر شرائح الحسابات، واتخاذ إجراءات بناءً على الرؤى باستخدام التنبيهات والأتمتة.
قبل أن تبني لوحات المعلومات أو تضع قياس الأحداث، حدد بوضوح ما غرض التطبيق، من هم المستخدمون، وكيف تُعرّف الشرائح. أغلب مشاريع "تتبع التبنّي" تفشل لأنها تبدأ بالبيانات وتنتهي بالخلافات.
قاعدة عملية: إن لم يستطع فريقان تعريف "التبنّي" في نفس الجملة، فلن يثقوا باللوحة لاحقًا.
سجّل الجماهير الأساسية وما يحتاج كل منهم فعله بعد الاطلاع على البيانات:
اختبار ليتمس مفيد: يجب أن يستطيع كل جمهور الإجابة على "ما النتيجة؟" في أقل من دقيقة.
التبنّي ليس مقياسًا واحدًا. اكتب تعريفًا يتفق عليه فريقك — عادة كسلسلة:
اجعلها متجذرة في قيمة العميل: ما هي الإجراءات التي تشير إلى أنهم يحققون مخرجات، لا مجرد الاستكشاف.
سجّل شرائحك واجعل التعيين حتميًا. الشرائح الشائعة تتضمن SMB / Mid-Market / Enterprise، مجاني / تجريبي / مدفوع، أو برونزي / فضي / ذهبي.
وثّق القواعد بلغة بسيطة (ومن ثم في الكود):
اكتب القرارات التي يجب أن يمكّن التطبيق منها. مثال:
استخدمها كمعايير قبول:
شرائح الحساب تتصرف بشكل مختلف، لذا مقياس "التبنّي" الواحد سيعاقب العملاء الصغار أو يخفي مخاطر العملاء الأكبر. ابدأ بتعريف ما يعني النجاح لكل شريحة، ثم اختَر مقاييس تعكس تلك الحقيقة.
اختر نتيجة أساسية تمثل قيمة حقيقية مُسَلَّمَة:
يجب أن تكون شجرة الشمال قابلة للعد، مُجزَّأة حسب الشريحة، وصعبة التلاعب.
اكتب قمع التبنّي كمراحل مع قواعد صريحة—حتى لا تعتمد إجابات اللوحة على التفسير.
أمثلة على المراحل:
تختلف متطلبات الشرائح: قد تتطلب "التفعيل" لدى Enterprise إجراء مشرف و إجراء مستخدم نهائي.
استخدم المؤشرات الرائدة لاكتشاف الزخم المبكر:
استخدم المؤشرات المتأخرة لتأكيد التبنّي الدائم:
ينبغي أن تعكس الأهداف وقت الوصول المتوقع للقيمة وتعقيد التنظيم. مثلاً، قد تستهدف SMB التفعيل خلال 7 أيام؛ بينما تستهدف Enterprise التكامل خلال 30–60 يومًا.
دوّن الأهداف حتى تبقى التنبيهات وبطاقات النتائج متسقة عبر الفرق.
نموذج بيانات واضح يمنع "حسابات غامضة" لاحقًا. تريد أن تجيب على أسئلة بسيطة—من استخدم ماذا، وفي أي حساب، وتحت أي شريحة، في أي وقت—دون لصق منطق مخصّص في كل لوحة معلومات.
ابدأ بمجموعة صغيرة من الكيانات التي تتوافق مع طريقة شراء واستخدام العملاء لمنتجك:
account_id)، الاسم، الحالة، وحقول دورة الحياة (created_at, churned_at).user_id, نطاق البريد الإلكتروني (مفيد للمطابقة), created_at, last_seen_at.workspace_id ومفتاح أجنبي إلى account_id.كن صريحًا بشأن "الحبيبة" التحليلية:
الإفتراضي العملي هو تتبّع الأحداث على مستوى المستخدم (مع إرفاق account_id)، ثم التجميع لمقاييس مستوى الحساب. تجنّب أحداثًا خاصة بالحساب فقط ما لم يكن لا وجود لمستخدم (مثل استيراد نظامي).
الأحداث تخبرك ما الذي حدث؛ اللقطات تخبرك ما الذي كان صحيحًا.
لا تمحُ "الشريحة الحالية" وتفقد السياق. أنشئ جدول account_tier_history:
account_id, tier_idvalid_from, valid_to (قابل للترك لـالحالي)source (الفوترة، تجاوز مبيعات)هذا يمكّنك من حساب التبنّي بينما كان الحساب في شريحة Team حتى لو ترقّى لاحقًا.
اكتب التعريفات مرة واحدة واعتبرها متطلبات المنتج: ما الذي يحسب كمستخدم "نشط"، كيف تنسب الأحداث إلى الحسابات، وكيف تتعامل مع تغيّر الشريحة منتصف الشهر. هذا يمنع ظهور لوحتين تظهران حقيقتين مختلفتين.
تحليلات التبنّي لن تكون أفضل من الأحداث التي تجمعها. ابدأ بتخطيط مجموعة صغيرة من أفعال "المسار الحرج" التي تشير إلى تقدم حقيقي لكل شريحة، ثم نفّذها بثبات عبر الويب، الموبايل، والباكند.
ركّز على الأحداث التي تمثل خطوات ذات معنى—ليس كل نقرة. مجموعة بداية عملية:
signup_completed (تم إنشاء الحساب)user_invited و invite_accepted (نمو الفريق)first_value_received (لحظة الـ"آها"؛ عرّفها صراحة)key_feature_used (فعل قيمة متكرر؛ قد يكون هناك أحداث متعددة لكل ميزة)integration_connected (إن كانت التكاملات تُحسّن الالتصاق)ينبغي أن يحتوي كل حدث على سياق كافٍ للتقطيع حسب الشريحة والدور:
account_id (مطلوب)user_id (مطلوب عند وجود شخص)tier (التقاط وقت الحدث)plan (بند/SKU إن كان ذا صلة)role (مثلاً owner/admin/member)workspace_id, feature_name, source (web/mobile/api), timestampاستخدم مخططًا متوقعًا حتى لا تتحول اللوحات إلى مشروع معجم:
report_exported, dashboard_shared)account_id, ليس acctId)invoice_sent) أو حدث واحد مع feature_name; اختر نهجًا واحدًا والتزم به.ادعم كلًّا من النشاط المجهول والمصادق:
anonymous_id عند الزيارة الأولى، ثم اربطه بـ user_id عند تسجيل الدخول.workspace_id واربطه بـ account_id عبر الخادم لتجنب أخطاء العميل.نفّذ أحداث النظام على الباكند حتى لا تعتمد المقاييس الأساسية على المتصفحات أو مانعات الإعلانات. أمثلة: subscription_started, payment_failed, seat_limit_reached, audit_log_exported.
هذه الأحداث الخادمية أيضًا مثالية لتشغيل التنبيهات وسير العمل.
هنا يتحول التتبع إلى نظام: تأتي الأحداث من تطبيقك، تُنقّح، تُخزّن بأمان، وتتحول إلى مقاييس يمكن للفريق استخدامها بالفعل.
تستخدم معظم الفرق مزيجًا من الطرق:
مهما اخترت، اعتبر الاستيعاب كعقد: إن لم يكن الحدث قابلًا للفهم، يجب عزله — لا قبوله بصمت.
عند الاستيعاب، نمطّن الحقول القليلة التي تجعل التقارير اللاحقة موثوقة:
account_id, user_id, و (إن لزم) workspace_id.event_name, tier, plan, feature_key) وأضف قيم افتراضية فقط عندما تكون صريحة.قرّر أين تعيش الأحداث الخام بناءً على التكلفة وأنماط الاستعلام:
ابنِ وظائف تجميع يومية/ساعة تنتج جداول مثل:
اجعل التجميعات حتمية حتى تتمكن من إعادة تشغيلها عند تغيير تعريفات الشرائح أو إجراء backfill.
حدد قواعد حفظ واضحة لـ:
تعطي درجة التبنّي للفرق رقمًا واحدًا لمراقبته، لكنها تعمل فقط إن بقيت بسيطة وقابلة للشرح. اهدف إلى درجة 0–100 تعكس سلوكيات ذات معنى (وليس نشاطًا باطنيًا) ويمكن تفكيكها إلى "لماذا تحرّكت".
ابدأ بقائمة مرجّحة من السلوكيات، مقصورة على 100 نقطة. اجعل الأوزان ثابتة لربع على الأقل حتى تبقى الاتجاهات قابلة للمقارنة.
مثال للأوزان (عدّل حسب منتجك):
يجب أن يُطابق كل سلوك قاعدة حدث واضحة (مثلاً "استخدام الميزة الأساسية" = core_action على 3 أيام منفصلة). عند تغيّر الدرجة، خزّن العوامل المساهمة حتى تتمكن من عرض: "+15 لأنك دعوت مستخدمين" أو "-10 لأن الاستخدام الأساسي انخفض".
احسب الدرجة لكل حساب (لقطة يومية أو أسبوعية)، ثم اجمعها حسب الشريحة باستخدام التوزيعات، ليس المتوسطات فقط:
تابع التغير الأسبوعي والتغير خلال 30 يومًا لكل شريحة، لكن تجنّب خلط أحجام الشرائح:
هذا يجعل الشرائح الصغيرة قابلة للقراءة دون أن تهيمن الشرائح الكبيرة على السرد.
يجب أن تتيح لوحة نظرة عامة على الشريحة للمدير التنفيذي الإجابة على سؤال واحد في أقل من دقيقة: "أي الشرائح تتحسّن، أيها تتراجع، ولماذا؟" اعتبرها شاشة قرار، لا كشك تقارير.
قمع الشريحة (الوعي → التفعيل → العادة): "أين تتعثر الحسابات حسب الشريحة؟" احتفظ بالخطوات متسقة مع منتجك (مثلاً "مستخدمون مدعوون" → "أكملوا الفعل المفتاحي الأول" → "نشطون أسبوعيًا").
معدل التفعيل حسب الشريحة: "هل الحسابات الجديدة أو المعاد تفعيلها تصل للقيمة الأولى؟" قدم المعدل مع المقام (الحسابات المؤهلة) حتى يمكن للقادة تمييز الإشارة من ضجيج العينات الصغيرة.
الاحتفاظ حسب الشريحة (مثلاً، 7/28/90 يوم): "هل تستمر الحسابات في الاستخدام بعد الفوز الأول؟" عرض خط بسيط لكل شريحة؛ تجنّب التجزئة المفرطة في النظرة العامة.
عمق الاستخدام (اتساع الميزات): "هل يتبنّون عدة مجالات منتجية أم يبقون سطحيين؟" شريط مكدس لكل شريحة يعمل جيدًا: % يستخدم مجالًا واحدًا، 2–3 مجالات، 4+ مجالات.
أضف مقارنةً دومًا في كل مكان:
استخدم دلّات متسقة (تغيير نقاط النسبة المطلقة) حتى يستطيع التنفيذيون المسح بسرعة.
حافظ على مرشحات محدودة، عالمية وثابتة:
إن كان مرشح يغيّر تعريف المقياس، لا تتيحه هنا—حوّله لعرض حفر تفصيلي.
ضمّن لوحة صغيرة لكل شريحة: "ما المرتبط بارتفاع التبنّي هذا الفترة؟" أمثلة:
اجعلها قابلة للفهم: فضّل "الحسابات التي أعدّت X خلال 3 أيام تحتفظ بنسبة 18 نقطة مئوية أعلى" على نتائج نموذجية غامضة.
ضع بطاقات KPI للشريحة في الأعلى (التفعيل، الاحتفاظ، العمق)، صفحة واحدة من مخططات الاتجاه في المنتصف، والمحركات + الإجراءات التالية في الأسفل. يجب أن يجيب كل ويدجت سؤالًا واحدًا—أو لا مكان له في الملخص التنفيذي.
لوحة الشريحة مفيدة للتحديد، لكن العمل الحقيقي يحدث عندما يمكنك النقر لتعرف لماذا تحركت الشريحة ومن يحتاج اهتمامًا. صمّم المشاهد التفصيلية كمسار موجه: شريحة → قطاع → حساب → مستخدم.
ابدأ بجدول نظرة عامة على الشريحة، ثم دع المستخدمين يقسمونه إلى قطاعات ذات معنى دون بناء تقارير مخصّصة. مرشحات القطاع الشائعة:
يجب أن يجيب كل صفحة قطاع: "أي الحسابات تدفع درجة التبنّي لهذه الشريحة صعودًا أو هبوطًا؟" أدرج قائمة مرتبة بالحسابات مع تغير الدرجة عبر الزمن والأكثر مساهمة من الميزات.
يجب أن يشعر ملف الحساب كملف حالة:
اجعلها قابلة للمسح: عرض التغيرات ("+12 هذا الأسبوع") وعلّم القفزات بعنونة الحدث/الميزة المسببة لها.
من صفحة الحساب، أدرج المستخدمين حسب النشاط الأخير والدور. النقر على مستخدم يظهر استخدامه للميزات وسياق آخر ظهور.
أضف عروضًا للمجموعات لشرح الأنماط: شهر التسجيل، برنامج التهيئة، والشريحة عند التسجيل. هذا يساعد CS على مقارنة المماثل بالمماثل بدل خلط حسابات جديدة مع ناضجة.
ضمّن "من يستخدم ماذا" لكل شريحة: معدل التبنّي، التواتر، واتجاهات الميزات، مع قائمة قابلة للنقر للحسابات التي تستخدم (أو لا تستخدم) كل ميزة.
لـ CS والمبيعات، أضف خيارات تصدير/مشاركة: تصدير CSV، طرق عرض محفوظة، وروابط داخلية قابلة للمشاركة (مثلاً /accounts/{id}) تفتح مع المرشحات المطبقة.
اللوحات رائعة للفهم، لكن الفرق تتخذ إجراءات عندما تُدفع تنبيهات في اللحظة المناسبة. يجب ربط التنبيهات بشريحة الحساب حتى لا يطمر CS وSales بضجيج منخفض القيمة—أو بطبيعة أسوأ، يفوتوا قضايا حرجة في حساباتك الأعلى قيمة.
ابدأ بمجموعة صغيرة من إشارات "هناك خطأ ما":
اجعل هذه الإشارات واعية للشرائح. مثلاً، قد تنبه Enterprise عند انخفاض 15% أسبوعًا بعد أسبوع في سير عمل رئيسي، بينما يحتاج SMB إلى انخفاض 40% لتجنّب ضجيج من الاستخدام المتقطع.
يجب أن تبرز تنبيهات التوسع الحسابات التي تنمو نحو مزيد من القيمة:
مرة أخرى، تختلف العتبات حسب الشريحة: مستخدم نشط واحد قد يعني كثيرًا لـ SMB، بينما يجب أن يتطلب توسع Enterprise اعتماد فرق متعددة.
وجّه التنبيهات إلى حيث يُنجَز العمل:
اجعل حمولة التنبيه قابلة للتنفيذ: اسم الحساب، الشريحة، ما تغيّر، نافذة المقارنة، ورابط للحفر التفصيلي (مثلاً /accounts/{account_id}).
كل تنبيه يحتاج إلى مالك وكتيب مختصر: من يرد، أول 2–3 فحوصات (نضارة البيانات، الإصدارات الأخيرة، تغييرات المسؤول)، والتواصل الموصى به أو الإرشاد داخل التطبيق.
وثّق كتيبات العمليات بجانب تعريفات المقاييس حتى تبقى الاستجابات متسقة وتظل التنبيهات موثوقة.
إذا كانت مقاييس التبنّي تحرّك قرارات حسب الشريحة (استجابة CS، محادثات التسعير، رهانات خارطة الطريق)، فالبيانات التي تغذّيها تحتاج حواجز حماية. مجموعة صغيرة من الفحوصات وعادات الحوكمة ستمنع "هبوطات غامضة" في اللوحات وتحافظ على اتساق الفرق حول معنى الأرقام.
تحقّق من الأحداث مبكرًا قدر الإمكان (SDK العميل، بوابة الـAPI، أو عامل الاستيعاب). ارفض أو عزّل الأحداث التي لا يمكن الوثوق بها.
نفّذ فحوصات مثل:
account_id أو user_id (أو قيم لا وجود لها في جدول الحسابات)احتفظ بجدول عزل لتفحص الأحداث السيئة دون تلويث التحليلات.
تتبع التبنّي حساس للوقت؛ الأحداث المتأخرة تشوّه النشاط الأسبوعي وتجميعات الشريحة. راقب:
وجّه المراقبات إلى قناة منوب عنها، لا إلى الجميع.
الـRetries تحدث (شبكات الموبايل، إعادة تسليم الويبهوك، إعادة تشغيل الدُفعات). اجعل الاستيعاب آمنًا لإعادة التشغيل باستخدام idempotency_key أو event_id ثابت، وادْمج الإزالة المزدوجة ضمن نافذة زمنية.
يجب أن تكون تجميعاتك قابلة لإعادة التشغيل دون احتساب مزدوج.
انشئ مسردًا يعرّف كل مقياس (المدخلات، المرشحات، النافذة الزمنية، قواعد نسب الشريحة) واعتبره المصدر الوحيد للحقيقة. اربط اللوحات والوثائق بهذا المسرد (مثلاً /docs/metrics).
أضف سجلات تدقيق لتغييرات تعريفات المقاييس ودرجات التبنّي—من غيّر ماذا ومتى ولماذا—حتى يمكن تفسير التغيرات في الاتجاهات بسرعة.
تحليلات التبنّي مفيدة فقط إذا وثق الناس بها. النهج الأكثر أمانًا هو تصميم تطبيق التتبع ليجيب عن أسئلة التبنّي مع جمع أقل قدر ممكن من البيانات الحساسة، ولجعل "من يرى ماذا" ميزة أساسية.
ابدأ بالمعرّفات الكافية لتحقيق رؤى التبنّي: account_id, user_id (أو معرف مستعار)، الطابع الزمني، الميزة، ومجموعة صغيرة من خصائص السلوك (الخطة، الشريحة، المنصة). تجنّب التقاط الأسماء، عناوين البريد الإلكتروني، المدخلات النصية الحرة، أو أي شيء قد يحتوي على أسرار بطريق الخطأ.
إن احتجت لتحليل على مستوى المستخدم، خزّن معرفات المستخدم منفصلة عن PII واربطها فقط عند الضرورة. عامل عناوين IP ومعرفات الأجهزة كحساسة؛ إن لم تكن بحاجة إليها للتسجيل، لا تحتفظ بها.
عرّف أدوار وصول واضحة:
اجعل الافتراضي هو العروض المجمعة. اجعل الحفر على مستوى المستخدم إذنًا صريحًا، وأخفِ الحقول الحساسة (إيميلات، أسماء كاملة، معرفات خارجية) ما لم يتطلب الدور ذلك حقًا.
ادعم طلبات الحذف بقدرة على إزالة سجل حدث المستخدم (أو تجريده) وحذف بيانات الحساب عند نهاية العقد.
نفّذ قواعد الاحتفاظ (مثلاً، احتفظ بالأحداث الخام لـ N يومًا، والملخّصات أطول) ووثّقها في سياساتك. سجّل الموافقة ومسؤوليات معالجة البيانات حيث ينطبق.
أسرع طريق لتحقيق قيمة هو اختيار معمارية تتوافق مع مكان وجود بياناتك حاليًا. يمكنك تطويرها لاحقًا—ما يهم هو وضع رؤى موثوقة حسب الشريحة في أيدي الناس.
تحليلات مرتكزة على المستودع: تتدفّق الأحداث إلى مستودع (مثل BigQuery/Snowflake/Postgres)، ثم تحسب مقاييس التبنّي وتقدّمها إلى تطبيق ويب خفيف. هذا مثالي إن كنتم تعتمدون SQL بالفعل، لديكم محللين، أو تريدون مصدر حقيقة مشترك مع تقارير أخرى.
تحليلات مرتكزة على التطبيق: يكتب تطبيقك الأحداث إلى قاعدة بياناته ويحسب المقاييس داخل التطبيق. يمكن أن يكون أسرع لمنتج صغير، لكنه أسهل في النفاد عند ارتفاع حجم الأحداث وحاجة إعادة المعالجة التاريخية.
الإفتراضي العملي لمعظم فرق SaaS هو النهج المرتكز على المستودع مع قاعدة تشغيلية صغيرة لإعداد التطبيق (الشرائح، تعريفات المقاييس، قواعد التنبيه).
اطلق إصدارًا أوليًا به:
أضف دوائر تغذية راجعة مبكرة: دع Sales/CS يُعلِّمون "هذا يبدو خاطئًا" مباشرة من اللوحة. version تعريفات المقاييس حتى تستطيع تغيير الصيغ دون إعادة كتابة التاريخ بصمت.
طرَح تدريجيًا (فريق واحد → المنظمة كلها) واحتفظ بسجل تغييرات تعريف المقاييس داخل التطبيق (مثلاً /docs/metrics) حتى يعرف أصحاب المصلحة دائمًا ما ينظرون إليه.
إن أردت الانتقال من "مخطط" إلى تطبيق داخلي عامل بسرعة، فإن نهج الـvibe-coding يمكن أن يساعد—خصوصًا لمرحلة MVP حيث تتحقق من التعريفات، لا تُحسّن البنية التحتية.
مع Koder.ai، يمكن للفرق نمذجة تطبيق تحليلات تبنّي داخلي عبر واجهة محادثة مع توليد كود حقيقي وقابل للتحرير. هذا مناسب لأن نطاق المشروع عريض (واجهة React، طبقة API، نموذج بيانات PostgreSQL، وتجميعات مجدولة) ويتطوّر سريعًا مع تقارب أصحاب المصلحة على التعريفات.
سير عمل شائع:
بما أن Koder.ai يدعم النشر/الاستضافة والنطاقات المخصصة وتصدير الكود، فهو طريقة عملية للوصول إلى MVP داخلي مع إبقاء خيارات البنية بعيد المدى (مستودع-أول مقابل تطبيق-أول) مفتوحة.
ابدأ بتعريف مشترك للتبنّي كسلسلة من المراحل:
ثم اجعل التعريف واعيًا للشرائح (مثلاً: تفعيل SMB خلال 7 أيام مقابل تفعيل Enterprise الذي قد يتطلب إجراء من المسؤول + إجراءات من المستخدم النهائي).
لأن الشرائح تتصرف بشكل مختلف. مقياس واحد يمكن أن:
التقسيم حسب الشريحة يمكّنك من وضع أهداف واقعية، اختيار مقياس شمالي ملائم لكل شريحة، وإطلاق التنبيهات المناسبة للحسابات عالية القيمة.
استخدم مجموعة قواعد حتمية وموثقة:
account_tier_history مع valid_from / valid_to.هذا يمنع تغير معاني التقارير عندما يرقّي أو يُخفض الحساب مستوى شريحته.
اختر مخرجًا أساسيًا واحدًا لكل شريحة يعكس قيمة حقيقية:
اجعل المقياس قابلًا للعد، صعب التلاعب، ومربوطًا بنتائج العملاء لا بالنقرات.
عرّف مراحل واضحة وقواعد تأهل صريحة حتى لا يتغير التفسير مع الوقت. مثال:
عدّل متطلبات المراحل حسب الشريحة (قد يتطلب تفعيل Enterprise إجراء مشرف ومستخدم نهائي معًا).
ركّز على مجموعة صغيرة من أحداث المسار الحرج:
signup_completeduser_invited, invite_acceptedfirst_value_received (عرّف لحظة الـ"آها" بدقة)ضمّن خصائص تجعل التقطيع والنسب موثوقين:
استخدم كليهما:
اللقطات عادةً تخزن المستخدمين النشطين، عدد استخدام الميزات الرئيسية، مكونات درجة التبنّي، والشريحة لذلك اليوم—حتى لا تُعاد كتابة التقارير التاريخية عند تغيير الشريحة.
اجعلها بسيطة، قابلة للشرح، وثابتة:
core_action في 3 أيام منفصلة خلال 14 يومًا).اجمع حسب الشريحة باستخدام توزيعات (الوسيط، النسب المئوية 25/75، % فوق عتبة)، لا مجرد المتوسطات.
اجعل التنبيهات خاصة بالشرائح وقابلة للتنفيذ:
وجّه التنبيهات إلى الأماكن التي يُنجز فيها العمل (Slack/email للطارئ، ملخّصات أسبوعية للأقل استعجالًا)، وتضمّن عناصر أساسية: ما تغيّر، نافذة المقارنة، ورابط للحفر التفصيلي مثل /accounts/{account_id}.
key_feature_used (أو أحداث لكل ميزة)integration_connectedأعط الأولوية للأحداث التي تمثل تقدّمًا نحو النتائج، لا لكل تفاعل واجهة.
account_id (مطلوب)user_id (مطلوب عند وجود شخص)tier (التقاط وقت الحدث)plan / SKU (إذا لزم الأمر)role (owner/admin/member)workspace_id, feature_name, source, timestampحافظ على تسمية متسقة (snake_case) حتى لا تتحول الاستعلامات إلى مشروع ترجمة.