تحليلات كميزة: معالجة البيانات Plesk

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

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

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


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

1. العديد من الأحداث ، كميات كبيرة من الاستخدام. إذا تحدثنا فقط عن تتبع إجراءات المستخدم في اللوحة ، وفقًا لتقديراتنا ، فهذا يمثل 60 مليون حدث شهريًا ، ومن المؤسف أن نقدم 150 ألف دولار لبرنامج Google Analytics المتقدم. هناك صعوبة أخرى وهي أنه للعمل مع GA ، يجب التعامل مع كل إجراء مخصص بشكل صريح ، لكننا أردنا الحصول على آلية موحدة لا تتطلب ترميز الأحداث أو الإجراءات يدويًا لكل ميزة جديدة.
2. نظرًا لحجم الصندوق وتنسيقه (يستغرق تنفيذ أي تغييرات وقتًا) ، يتعذر على التحليلات القيام بالوقت الفعلي. يجلس المستخدمون على 8 إصدارات مختلفة من المنتج ، مع 4 منهم بالفعل EOLed. حتى على أحدث الإصدارات ، 60٪ فقط من المستخدمين يدخلون تغييرات جديدة في الأسبوعين الأولين بعد الإصدار.
   
3. منتج معقد. يدعم Plesk 14 نظام تشغيل لعائلة Linux ، و 4 OC Windows ، ومكون من 150 جهة خارجية ، والعديد من خوادم الويب ، وخوادم البريد ، وعملاء البريد الإلكتروني ، ومتخيلي الإحصاءات ، وحلول مكافحة الفيروسات ، إلخ. يؤثر عدد كبير من التكوينات المحتملة بشكل أساسي على تعقيد وحجم الاختبار ويجعل من المستحيل تقريبًا استخدام اختبارات A / B.
   
4. B2B2C التفاصيل. صانع القرار لا يساوي دائمًا "المستخدم الحقيقي للوحة".
   
5. الناتج القومي الإجمالي - تتطلب الحاجة إلى الامتثال لنص القانون بذل جهود إضافية لإخفاء هوية البيانات وتعقيد مهام تجزئة المستخدم ، كما تحرمنا من القدرة على الاتصال بسهولة وبسرعة مع العملاء باستخدام معلومات الاتصال الخاصة بهم.
   

سنتحدث عن آلام العملية بمزيد من التفاصيل. حتى وقت قريب ، كانت عملية جمع التحليلات معنا منفصلة تمامًا عن عملية التطوير - لقد تذكرنا التتبع والمقاييس في النهاية ، وقمنا بإيجاد حل لمرة واحدة ، وهكذا حتى الميزة التالية. بالإضافة إلى ذلك ، على مر السنين ، جمعت Plesk مجموعة من مصادر البيانات - والتي تستلزم تكاليف الحفاظ على تناسق البيانات وأهميتها ، والحاجة إلى أن تضع في الاعتبار من أين تأتي ، وتحت أي ظروف تصل إلى قاعدة البيانات ولماذا نفس المقاييس في أماكن مختلفة تختلف (على سبيل المثال ، عدد مفاتيح الترخيص والتركيبات المادية). تمت كتابة الكثير من المعلومات على هذه المصادر (التخفيضات الشهرية من قاعدة بيانات مؤلفة من 270 ألف مفتاح وتقارير تصل مرتين في كثير من الأحيان من 300 ألف خادم) ، ولكن عددًا قليلًا فقط من الأشخاص تمكنوا من التعامل مع هذه البيانات والوقت الذي تم العثور عليه. جئت إلى Plesk في عام 2015 ، وكانت أول مهامي هي الحصول على إحصائيات غير متجانسة من مكعب OLAP وقاعدة بيانات MongoDB. كانت "كيفية" قاعدة البيانات هذه عبارة عن صفحة بها اسم مستخدم وكلمة مرور من المضيف وملف نصي به نص js من آخر طلب شائع.

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



ماذا فعلنا؟

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

فرضية

يبدأ كل شيء في مرحلة تخطيط الميزة: يصوغ PM فرضية تستند إلى تحديد المقياس في الخطوة التالية. على سبيل المثال: لدى Plesk نظام توصية Advisor يساعد المستخدم على تحسين حالة الخادم عن طريق اتباع الخطوات المقترحة (إضافة شهادة ssl ، وتمكين التحديثات ، وتحديث إصدار PHP ، وما إلى ذلك). من خلال تحرير Advisor ، نفترض أن المستخدم سيتبع التوصيات ، وسيزداد تصنيف "الصحة" للخادم ، وبفضل "الإنجازات" المبهمة ، سيشارك المستخدم في التفاعل مع Advisor على أساس مستمر.

متري

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

تطبيق

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

اختبار ومعاينات

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

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

ميزة الحياة

عندما يتم إطلاق ميزة في إصدار ، يبدأ الجزء الأكثر إثارة للاهتمام - "عمرها" في المنتج. لا مزيد من الإلقاء: "هل تعرف معرفة أي حقل في قاعدة بياناتنا يخزن معلومات حول عرض التوصيات؟ لا؟ بلين ... ". لا يتلقى محلل البيانات رسائل في فترة الركود: "هل يمكنك الاعتماد مرة أخرى على عدد مرات الظهور في الإصدار الأخير؟" - لهذا ، توجد مخططات على لوحات المعلومات مع تنبيهات مكونة ترسل رسائل إذا انخفضت القيمة المراقبة بشكل حاد / تم زيادة / تغيير / عدم وجود سجلات في قاعدة البيانات. لكن هذا ليس كل شيء. إن فهم أن العداد قد زاد أو انخفض بنسبة n٪ لا يكفي دائمًا ليقول بثقة إن هذا تغيير كبير ، وليس قفزة موسمية أو تذبذب ضمن هامش الخطأ. يقوم أحد أعضاء فريقنا بتطوير إطار لقياس الأهمية الإحصائية للتغييرات المترية. باستخدام جهاز الإحصاء الرياضي ، يقوم بحساب العينة الدنيا (عدد المستخدمين / المنشآت / الأحداث) اللازمة لتقييم أهمية التغييرات وتحديد القطاعات التي يمكنك مقارنة وتحديد الفاصل الزمني للثقة الذي يحتمل أن يحتوي على القيمة الحقيقية لقياس الاهتمام بالنسبة لنا. لقد تم اختبار هذا الإطار بالفعل وأعطاه نتائج مثيرة للاهتمام في الأسبوع الماضي فقط: اكتشفنا أنه بعد أن بدأنا عرض الأسعار في كتالوج الإضافات داخل لوحة Plesk ، بدأ الناس في شراء مفاتيح ترخيص سنوية أقل وأكثر شهريًا لهذه المنتجات. في الوقت الحالي ، يقوم زملاؤنا بحساب توقعات LTV ، وبعد ذلك سيتضح أن هذه التغييرات هي بالنسبة لنا على المدى الطويل وما الخيار الذي يجب أن نشجعه في منطق عرض الأسعار.

إنهاء الدعم

إن نتيجة حياة أي منتج أو ميزة هي إنهاء دعمه في الحالة عندما يكون ذلك بسبب نقص الطلب أو لأسباب أخرى (على سبيل المثال ، اعتبارات الأمان في حالة إنهاء دعم نظام تشغيل قديم أو إصدار PHP). هنا ، تأتي أيضًا التحليلات في مساعدتنا: على سبيل المثال ، عندما قررنا تشجيع المستخدمين على التبديل إلى إصدارات جديدة من PHP ، فإن أول شيء فعلناه هو جمع إحصائيات استخدام الإصدار بين مستخدمي Plesk. لقد تعلمنا أن النسبة المئوية باستخدام PHP 7 تصل إلى 20٪ فقط من المستخدمين وأدركنا أن التكاليف المحتملة للتبديل القسري في شكل ملايين المواقع المعطلة تفوق مخاطر نقاط الضعف المحتملة للإصدارات القديمة. نتيجةً لذلك ، قررنا اتخاذ تدابير أكثر اعتدالًا للتأثير وبدأنا بإشعار حول استحسان إجراء ترقية في اللوحة. مثال آخر يمكن أن يكون العديد من القصص مع وقف دعم أنظمة التشغيل - في حالة اكتشافنا أن أحد أكبر العملاء الذين لديهم عشرات الآلاف من عمليات تثبيت Plesk يستخدم نظام تشغيل معين ، فإننا نتواصل بشكل مستهدف مع هذا الشريك ، وفي حالة استحالة الانتقال السريع ، قدمنا ​​له ما يسمى بإسقاط الكسل - إنهاء دعم التثبيتات الجديدة والقدرة على مواصلة العمل على المنشآت الموجودة بعد الترقية إلى أحدث إصدار من Plesk.

استنتاج

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



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