الحدث قرار اتخذته، لا شيء وقع
كل منتج يُصدر عددًا غير محدود من الأشياء التي تقع: نقرات، وتمريرات، ومرور مؤشر، وتغيّر مسارات. أما الحدث فهو تلك المجموعة الجزئية الصغيرة التي قررت أنها تستحق اسمًا، لأنها تخبرك بشيء ستتصرف بناءً عليه. هذا القرار، لا التهيئة التقنية، هو العمل كله.
والنتيجة العملية أن خطة القياس وثيقة منتج قبل أن تكون وثيقة هندسة. فإذا لم تستطع أن تقول ما الذي ستفعله على نحو مختلف تبعًا لإطلاق حدث من عدمه، فهو لا يحتاج إلى الوجود بعد.
سمِّ الأحداث بحسب النتائج لا بحسب الواجهات
يتوقف clicked_blue_button عن كونه صحيحًا لحظة إطلاق التصميم لنسخة جديدة. أما report_exported فينجو، لأنه يسمّي ما أنجزه المستخدم لا ما لمسه.
اختر اصطلاحًا واحدًا والتزم به: الكائن أولًا، والفعل في الماضي، بأحرف صغيرة وشرطات سفلية — invite_sent وproject_created وpayment_failed. الاتساق أهم من الاصطلاح الذي اخترته، لأن الأسماء غير المتسقة هي ما يجعل كتالوج الأحداث غير قابل للبحث بعد ربعين.
اصطلاح تسمية يمكنك نسخه
لا تحتاج معظم الفرق إلى ابتكار اصطلاح، بل إلى تدوينه فقط. هذا الاصطلاح قصير بما يكفي ليُحفظ وصارم بما يكفي ليُبقي الكتالوج قابلاً للبحث:
| القاعدة | افعل | لا تفعل |
|---|---|---|
| الكائن أولاً ثم الفعل | invite_sent | sent_invite |
| بصيغة الماضي، لأنه حدث بالفعل | project_created | create_project |
| أحرف صغيرة مع شرطات سفلية | plan_upgraded | PlanUpgraded، plan-upgraded |
| سمِّ النتيجة لا عنصر التحكم | report_exported | export_button_clicked |
| التنويعات تذهب في الخصائص | report_exported مع format: csv | report_exported_csv |
| لا بيانات شخصية في الأسماء أو القيم | plan: team | email: ana@acme.com |
ضع الاصطلاح في أعلى خطة التتبّع وراجع الأحداث الجديدة وفقه كما تراجع الشيفرة وفق دليل أسلوب. الاسم السيئ يُدفع ثمنه في كل مرة يبحث فيها أحدهم عن الحدث فلا يجده.
من عشرة إلى عشرين حدثًا، لا مئتين
الإخفاق الشائع هو تتبّع كل شيء بحجة أن البيانات قد تفيد لاحقًا. وما تحصل عليه كتالوج لا يستطيع أحد التنقّل فيه، وثلاثة أحداث تعني الشيء نفسه تقريبًا، ولا اتفاق على أيها المرجع.
انطلق من الأسئلة التي تطرحها فعلًا في المراجعات — هل ينجح الناس في الإعداد، هل يعودون، أين يستسلمون — ولا تقس إلا ما يجيب عنها. خطة القياس التي تسع شاشة واحدة تبقى مصانة، أما التي تملأ جدول بيانات فلا.
مثال عملي: خطة تتبّع لتطبيق SaaS بين الشركات
إليك شكل اثني عشر حدثاً لمنتج SaaS نموذجي قائم على الفرق. كل حدث موجود لأنه يجيب عن سؤال يطرحه أحدهم بالفعل في مراجعة أسبوعية.
| الحدث | يُطلق عندما | الخصائص الأساسية | السؤال الذي يجيب عنه |
|---|---|---|---|
signup_completed | يصبح الحساب موجوداً، لا عند إرسال النموذج | source | أي القنوات تجلب أشخاصاً يُكملون فعلاً؟ |
workspace_created | تُحفظ أول مساحة عمل | team_size | كم من المسجّلين يصلون إلى مرحلة الإعداد؟ |
teammate_invited | تُرسل دعوة | role | هل ينتشر الحساب إلى ما بعد شخص واحد؟ |
invite_accepted | ينضم الشخص المدعو | role | هل تتحول الدعوات إلى زملاء؟ |
integration_connected | ينجح اتصال | integration | ما التكاملات التي تستخدمها الفرق التي تبقى؟ |
project_created | يُحفظ مشروع | template | هل يُنشأ الكائن الأساسي أصلاً؟ |
report_viewed | يكتمل عرض تقرير | report_type | ما الذي يعود الناس للاطلاع عليه؟ |
report_exported | يُنشأ الملف | format | هل تخرج المخرجات من المنتج؟ |
plan_upgraded | تؤكد الفوترة التغيير | from_plan، to_plan | ماذا يحدث مباشرةً قبل أن يدفع الناس أكثر؟ |
payment_failed | يبلّغ مزوّد الفوترة عن فشل | reason | كم من فقدان العملاء غير إرادي؟ |
subscription_cancelled | يسري الإلغاء | reason | لماذا تغادر الفرق؟ |
feedback_submitted | يُرسل نموذج الملاحظات | category | ماذا يطلب المستخدمون، بكلماتهم هم؟ |
أمران يستحقان الانتباه. معظم هذه الأحداث تُطلق عند نتيجة لا عند نقرة: يمكن النقر على دعوة ثم تفشل مع ذلك. وأحداث الفوترة لا تقع في المتصفح أصلاً. إنها تصل من خطافات الويب (webhooks) لدى مزوّد الفوترة، فالتحليلات التي تعتمد على المتصفح وحده لن تراها أبداً. ولا بأس في ذلك ما دام أحد لا يعامل النقر على «ترقية» كأنه إيراد.
التفعيل عادةً مزيج من هذه الأحداث لا حدث واحد منها، كأن تُنشأ مساحة عمل ويُدعى زميل خلال الأسبوع الأول. اختر هذا التعريف عن قصد؛ ويشرح معايير مسار التفعيل كيفية ذلك.
الخصائص تحمل التفاصيل، والحدث يحمل الفعل
قاوم إنشاء حدث لكل صيغة. ينبغي أن يكون report_exported_csv وreport_exported_pdf وreport_exported_xlsx حدثًا واحدًا هو report_exported مع خاصية format. والقاعدة العملية: إن كنت قد ترغب يومًا في رؤية الأرقام مجموعة معًا، فهو حدث واحد بخاصية.
أبقِ قيم الخصائص منخفضة التعدد ومستقرة. فالخاصية التي تحمل رابطًا خامًا أو نصًا حرًا هي عمود لا يمكنك التجميع بحسبه، وهذا يجعلها زينة لا بيانات.
أخطاء في تتبّع الأحداث تُفسد التقارير بصمت
- الإطلاق عند النقر بدلاً من النتيجة. النقر على «تصدير» ليس تصديراً. إذا فشل الطلب، يكون الحدث قد كذب بالفعل. أرسل أحداث النتائج بعد نجاح العملية.
- الإطلاق المزدوج في تطبيقات الصفحة الواحدة. المكوّن الذي يُعاد عرضه أو المسار الذي يُركَّب مرتين قد يرسل الحدث نفسه مرتين. افحص بعض الجلسات يدوياً قبل أن تثق بأي عدد.
- بيانات شخصية في الخصائص. عناوين البريد والأسماء وعناوين URL التي تحمل رموزاً في سلسلة الاستعلام تنتهي في كل تقرير وكل عملية تصدير. أرسل معرّفاً أو فئة بدلاً منها.
- التتبّع قبل الموافقة. حيث ينطبق GDPR، لا ينبغي أن تبدأ التحليلات قبل أن يوافق الزائر. هذه خاصية في إعدادك لا في كل حدث، فعالجها مرة واحدة عبر مدير الموافقة على ملفات الارتباط يوقف التتبّع حتى ذلك الحين.
- تغيير معنى الحدث دون إعادة تسميته. إذا بدأ
project_createdيحتسب المشاريع المكرّرة، تختلف كل الرسوم البيانية قبل التغيير وبعده ولا يعرف أحد السبب. المعنى الجديد يستحق اسماً جديداً، أو خاصية تميّز بين الحالتين. - أحداث بلا مسؤول. كل حدث في الخطة يحتاج إلى شخص يلاحظ حين يتوقف عن الإطلاق. الأحداث بلا مسؤول هي أول ما يتدهور وآخر ما يُشكّ فيه.
الالتقاط التلقائي والأحداث الصريحة يجيبان عن سؤالين مختلفين
يسجّل الالتقاط التلقائي تفاعلات الواجهة دون أن يطلب منك التخطيط، وهو مفيد حقًا في البداية: فبيانات سؤال لم يخطر لك بعد تكون موجودة سلفًا، ويخرج النشر من الحلقة. لكنه لا يستطيع معرفة مجالك. لا شيء في تدفق النقرات يعرف أن اشتراكًا قد تمت ترقيته.
الترتيب العملي هو الاثنان معًا: الالتقاط التلقائي للاستكشاف وللأسئلة التي لم تطرحها بعد، وقائمة قصيرة من أحداث المجال الصريحة حسنة التسمية للأرقام التي ترفع عنها تقاريرك وتضع لها أهدافًا.
تعريف الأحداث بعد وقوعها
يغيّر الالتقاط التلقائي السؤال من «هل تذكّرنا أن نجهّز تتبّع هذا؟» إلى «هل يمكننا العثور عليه فيما جرى التقاطه؟». يسجّل PulsePanda كل نقرة مع id العنصر وأصنافه ونصه الظاهر ووسمه وموضعه في الصفحة، فيمكن تعريف حدث لاحقاً انطلاقاً منها، وينطبق التعريف على النقرات الملتقطة قبل وجوده. سؤال يُطرح يوم الخميس يمكن الإجابة عنه ببيانات يوم الاثنين.
ما يجعل ذلك موثوقاً هو نقطة ارتكاز ثابتة في الشيفرة. تتغير الأصناف مع كل إعادة تصميم، ويتغير النص الظاهر مع كل تعديل في الصياغة وكل ترجمة. أما id على عناصر التحكم القليلة المهمة فلا يتغير إلا حين يقرر أحدهم ذلك:
<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/ar/billing">Upgrade</a>الحدث المعرَّف بأنه النقرات على #export-report يصمد أمام إعادة التصميم، والنقر على الأيقونة أو التسمية داخل الزر يظل محتسباً، لأن المسار المسجَّل يصعد حتى أقرب عنصر يحمل id.
الحدث المعرَّف يظل نقرة، مع القيد الموصوف أعلاه: يخبرك أن أحدهم حاول، لا أن المحاولة نجحت. وللنتائج، تكون الإشارة الأصدق غالباً هي الصفحة التي يقود إليها النجاح. خطوة مسار «وصل إلى /onboarding» بعد «وصل إلى /signup» تحتسب التسجيلات المكتملة دون أي حدث على الإطلاق.
كيف تتحقق من حدث قبل أن تثق به
- أطلقه بنفسك وابحث عن جلستك. يجب أن يظهر الحدث مرة واحدة، مع تعبئة كل خصائصه.
- قارن العدد بمصدر موثوق. إذا قالت قاعدة البيانات إن 140 مشروعاً أُنشئت الأسبوع الماضي وقالت التحليلات 95، فابحث عن سبب الفجوة قبل أن يبني أحد رسماً بيانياً عليها. أدوات حجب الإعلانات والموافقة والطلبات الفاشلة كلها تجعل أعداد المتصفح أقل من أعداد الخادم. يجب أن تكون الفجوة ثابتة، لا مفاجئة.
- شاهد إعادة تشغيل جلسة أُطلق فيها الحدث. الرقم يخبرك أنه حدث؛ والتسجيل يخبرك أنه حدث حين تظن أنه حدث.
- ضعه في مسار. الحدث الذي يظهر دون الخطوة التي يجب أن تسبقه يُطلق من المكان الخطأ.
من أين تبدأ هذا الأسبوع
اكتب اللحظات الخمس الأهم في منتجك، وسمِّها وفق الاصطلاح أعلاه، ولا تقس سواها. ثم تحقق بعد أسبوع من أن كل واحد منها يُطلق حين تتوقع، ومن أن خصائصه مملوءة — فالحدث الذي يُطلق في مسار شيفرة لا يسلكه أحد أسوأ من غياب الحدث، لأنه سيُوثَق به.
وإذا أردت أن ترى سلوك الأحداث التي ترسلها بالفعل قبل إضافة المزيد، فإن تتبّع الأحداث في PulsePanda يعرض كل حدث وحجمه وخصائصه في مكان واحد، ويغذّي البيانات نفسها مباشرةً في المسارات ورحلات التنقّل.