هذه المقالة هي الأخيرة في سلسلة متعددة الأجزاء تشارك مجموعة واسعة من أعمال هندسة التحليلات في Netflix، والتي تم تقديمها مؤخرًا كجزء من مؤتمرنا السنوي الداخلي لهندسة التحليلات. هل تحتاج إلى اللحاق بالركب؟ الدفع الجزء 1، والتي توضح بالتفصيل كيفية تمكين Netflix من إنتاج وتقديم رؤى تحليلية عالية الجودة وقابلة للتنفيذ بكفاءة عبر الشركة و الجزء 2، والتي تطرقت إلى عدد قليل من تطبيقات الأعمال المثيرة للاهتمام في مجال هندسة التحليلات. سوف يتناول هذا المنشور جوانب الحرفة الفنية.
رينا تشانغ، سوزي لو
ما هو التصميم، ولماذا يهم؟ غالبًا ما يعتقد الناس أن التصميم يدور حول كيفية ظهور الأشياء، لكن التصميم في الواقع يتعلق بكيفية عمل الأشياء. كل شيء مصمم، لأننا جميعًا نتخذ خيارات بشأن كيفية عمل الأشياء، ولكن ليس كل شيء مصممًا بشكل جيد. التصميم الجيد لا يضيع الوقت أو الطاقة العقلية؛ وبدلاً من ذلك، فهو يساعد المستخدم على تحقيق أهدافه.
عند تطبيق ذلك على تطبيق لوحة المعلومات، فإن أسهل طريقة لاستخدام التصميم بفعالية هي الاستفادة من الأنماط الموجودة. (على سبيل المثال، تعلم الأشخاص أن النص الذي تحته خط باللون الأزرق على موقع ويب يعني أنه رابط قابل للنقر عليه.) لذا فإن معرفة ترسانة الأنماط المتاحة وما تشير إليه ضمنًا يعد أمرًا مفيدًا عند اختيار وقت استخدام أي نمط.
أولاً، لتصميم لوحة المعلومات بشكل جيد، عليك أن تفهم المستخدم الخاص بك.
- تحدث إلى المستخدمين طوال دورة حياة المنتج بأكملها. تحدث معهم في وقت مبكر وفي كثير من الأحيان، من خلال أي وسيلة ممكنة.
- افهم احتياجاتهم، واسأل لماذا، ثم اسأل لماذا مرة أخرى. فصل الأعراض عن المشاكل عن الحلول.
- تحديد الأولويات والتوضيح – الأقل هو الأكثر! قم بتقطير ما يمكنك بناءه بشكل مميز ويوفر أكبر قيمة للمستخدم.
فيما يلي إطار عمل للتفكير فيما يحاول المستخدمون تحقيقه. أين يقع مستخدموك على هذه المحاور؟ لا تقم بالحل لمواضع متعددة عبر هذه المحاور في طريقة عرض معينة؛ إذا كان ذلك موجودًا، فقم بإنشاء طرق عرض مختلفة أو لوحات معلومات مختلفة محتملة.
ثانيًا، سيسمح لك فهم النماذج العقلية لمستخدميك باختيار كيفية تنظيم تطبيقك ليتناسب. تتضمن بعض الأسئلة التي يجب أن تطرحها على نفسك عند النظر في بنية المعلومات لتطبيقك ما يلي:
- هل لديك مجموعات مستخدمين مختلفة تحاول إنجاز أشياء مختلفة؟ قم بتقسيمها إلى تطبيقات مختلفة أو طرق عرض مختلفة.
- ما الذي يجب أن يجتمع معًا في صفحة واحدة؟ جميع المعلومات اللازمة لنوع مستخدم واحد لإنجاز “وظيفته”. إذا كانت هناك مهام متعددة يجب القيام بها، قم بتقسيم كل منها على صفحتها الخاصة.
- ما الذي يجب أن يتم دمجه معًا في قسم واحد في الصفحة؟ جميع المعلومات اللازمة للإجابة على سؤال واحد.
- هل تشعر بصعوبة استخدام لوحة القيادة الخاصة بك؟ ربما لديك الكثير من المعلومات! عندما تكون في شك، يبقيه بسيطا. إذا لزم الأمر، قم بإخفاء التعقيد ضمن قسم “متقدم”.
فيما يلي بعض الإرشادات العامة لتخطيطات الصفحة:
- اختر التمرير اللانهائي مقابل النقر عبر صفحات متعددة اعتمادًا على الخيار الذي يناسب توقعات المستخدمين بشكل أفضل
- ابدأ بالمعلومات الأكثر استخدامًا أولاً، في الجزء المرئي من الصفحة
- أنشئ علامات تشير إلى مكان تواجد المستخدم من خلال تصنيف الصفحات والأقسام والروابط
- استخدم البطاقات أو الحدود لتجميع العناصر ذات الصلة معًا بشكل مرئي
- استفد من التداخل لإنشاء “نطاقات تحكم” مفهومة جيدًا. على وجه التحديد، يتوقع المستخدمون أن يؤثر كائن وحدة التحكم على الأطفال إما: أسفله (إذا كان أفقيًا) أو على يمينه (إذا كان رأسيًا)
ثالثًا، يمكن أن تساعدك بعض النصائح والحيل في التعامل بسهولة أكبر مع تحديات التصميم الفريدة التي تأتي مع إنشاء مخططات تفاعلية.
- العناوين: تأكد من تمثيل عوامل التصفية في العنوان أو العنوان الفرعي للمخطط لسهولة المسح الضوئي وإمكانية التقاط لقطة الشاشة.
- تلميحات الأدوات: يجب أن تكون التفاصيل الأساسية موجودة على الصفحة، بينما يكون السياق الموجود في تلميح الأداة مخصصًا للحصول على معلومات أعمق. قم بإضافة تعليقات توضيحية إلى نقاط متعددة عندما لا يكون هناك سوى عدد قليل من الخطوط.
- التعليقات التوضيحية: قم بتوفير التعليقات التوضيحية على المخططات لشرح التحولات في القيم حتى يتمكن جميع المستخدمين من الوصول إلى هذا السياق.
- اللون: حدد عدد الألوان التي تستخدمها. كن متسقًا في كيفية استخدام الألوان. وإلا فإن الألوان تفقد معناها.
- الإعداد: قم بفصل الإعداد إلى لوحة التحكم الخاصة بك عن الاستخدام الروتيني.
أخيرًا، من المهم ملاحظة أن هذه إرشادات عامة، ولكن هناك دائمًا مجال للتفسير و/أو استخدام الحكم الجيد لتكييفها لتناسب منتجك وحالات الاستخدام. في نهاية المطاف، الشيء الأكثر أهمية هو أن المستخدم يمكنه الاستفادة من رؤى البيانات التي توفرها لوحة التحكم الخاصة بك لأداء عمله، والتصميم الجيد هو وسيلة لتحقيق هذه الغاية.
ديفين كارولو
في Netflix Studio، نعمل عند تقاطع الفن والعلم. البيانات هي أداة تعزز عملية صنع القرار، وتكمل الخبرة العميقة والمعرفة الصناعية للمتخصصين المبدعين لدينا.
أحد الأمثلة على ذلك هو ميزانية الإنتاج – أي تحديد المبلغ الذي يجب أن ننفقه لإنتاج عرض أو فيلم معين. على الرغم من وجود عملية بالفعل لإنشاء ومقارنة ميزانيات الإنتاجات الجديدة مع المشاريع السابقة المماثلة، إلا أنها كانت يدوية للغاية. لقد قمنا بتطوير أداة تقوم تلقائيًا باختيار منتجات Netflix المماثلة ومقارنتها، مع الإشارة إلى أي حالات شاذة لكي يقوم تمويل الإنتاج بمراجعتها.
ولضمان النجاح، كان من الضروري تحقيق النتائج في الوقت الحقيقي ودمجها بسلاسة في الأدوات الحالية. يتطلب هذا تعاونًا وثيقًا بين فرق المنتجات وDSE ومطوري الواجهة الأمامية والخلفية. لقد قمنا بتطوير نقطة نهاية GraphQL باستخدام Metaflow، ودمجها في منتج الميزانية الحالي. وقد مكّن هذا الحل من استخدام البيانات بشكل أكثر فعالية لاتخاذ القرار في الوقت الفعلي.
لقد أطلقنا مؤخرًا MVP الخاص بنا ونواصل تكرار المنتج. وبالنظر إلى رحلتنا، كان الطريق إلى الإطلاق معقدًا ومليئًا بالتحديات غير المتوقعة. باعتباري مهندس تحليلات معتادًا على صياغة حلول سريعة، فقد قللت من تقدير الجهد المطلوب لنشر واجهة برمجة تطبيقات التحليلات على مستوى الإنتاج.
وبعد فوات الأوان، فيما يلي الدروس الأساسية التي تعلمتها.
قياس التأثير وضرورة النتائج في الوقت الحقيقي
قبل تنفيذ التحليلات في الوقت الفعلي، قم بتقييم ما إذا كانت النتائج في الوقت الفعلي ضرورية حقًا لحالة الاستخدام الخاصة بك. يمكن أن يؤثر هذا بشكل كبير على تعقيد وتكلفة الحل الخاص بك. قد توفر بيانات المعالجة المجمعة تأثيرًا مماثلاً وتستغرق وقتًا أقل بكثير. إنه أسهل في التطوير والصيانة، ويميل إلى أن يكون أكثر دراية لمهندسي التحليلات وعلماء البيانات ومهندسي البيانات.
بالإضافة إلى ذلك، إذا كنت تقوم بتطوير إثبات للمفهوم، فقد لا يكون الاستثمار الأولي يستحق ذلك. غالبًا ما تكون الحلول المتقطعة هي الخيار الأفضل للعمل التحليلي.
استكشف جميع الحلول المتاحة
في Netflix، كانت هناك طرق متعددة لإنشاء واجهة برمجة التطبيقات (API)، لكن لم يكن أي منها مناسبًا تمامًا لحالة الاستخدام المحددة لدينا. Metaflow، وهي أداة تم تطويرها في Netflix لمشاريع علوم البيانات، تدعم بالفعل واجهات برمجة تطبيقات REST. ومع ذلك، لم يتوافق هذا النهج مع سير العمل المفضل لشركائنا الهندسيين. على الرغم من إمكانية التكامل مع نقاط نهاية REST، إلا أن هذا الحل يمثل قيودًا متأصلة. أدت أحجام الاستجابة الكبيرة إلى جعل تكامل واجهة برمجة التطبيقات/الواجهة الأمامية غير موثوق به، مما يستلزم إضافة معلمات عامل التصفية لتقليل حجم الاستجابة.
بالإضافة إلى ذلك، كان المنتج الذي كنا ندمجه يستخدم GraphQL، ولم يكن الانحراف عن هذا النهج الهندسي الراسخ مثاليًا. أخيرًا، نظرًا لهدفنا المتمثل في تراكب النتائج في جميع أنحاء المنتج، أثبتت ميزات GraphQL، مثل الاتحاد، أنها مفيدة بشكل خاص.
بعد أن أدركنا عدم وجود حل موجود في Netflix لنشر نقاط نهاية python مع GraphQL، عملنا مع فريق Metaflow لبناء هذه الميزة. سمح لنا هذا بمواصلة التطوير عبر Metaflow وسمح لشركائنا الهندسيين بالبقاء على طريقهم الممهد.
التوافق مع توقعات الأداء
كان التحدي الرئيسي أثناء التطوير هو إدارة زمن استجابة واجهة برمجة التطبيقات (API). وكان من الممكن التخفيف من قدر كبير من هذا من خلال المواءمة مع توقعات الأداء منذ البداية. في البداية، عملنا وفقًا لافتراضاتنا حول ما يشكل وقت استجابة مقبولًا، والذي يختلف بشكل كبير عن الاحتياجات الفعلية لمستخدمينا وشركائنا الهندسيين.
يعد فهم توقعات المستخدم أمرًا أساسيًا لتصميم حل فعال. أدت منهجيتنا إلى إجراء تحليل كامل للميزانية يستغرق، في المتوسط، 7 ثوانٍ. كان المستخدمون على استعداد لانتظار التحليل عندما يقومون بتعديل الميزانية، ولكن ليس في كل مرة يصلون فيها. لمعالجة هذه المشكلة، قمنا بتنفيذ التخزين المؤقت باستخدام Metaflow، مما أدى إلى تقليل وقت استجابة واجهة برمجة التطبيقات (API) إلى ثانية واحدة تقريبًا للنتائج المخزنة مؤقتًا. بالإضافة إلى ذلك، قمنا بإعداد مهمة دفعة ليلية للتخزين المؤقت للنتائج مسبقًا.
بينما كان المستخدمون موافقين بشكل عام على انتظار التحليل أثناء التغييرات، كان علينا أن نضع في اعتبارنا حد GraphQL البالغ 30 ثانية. وقد سلط هذا الضوء على أهمية المراقبة المستمرة لتأثير التغييرات على أوقات الاستجابة، مما يقودنا إلى التعلم الرئيسي التالي: الاختبار الصارم.
يتطلب التحليل في الوقت الحقيقي اختبارات صارمة
اختبار التحميل: لقد استفدنا من Locust لقياس وقت استجابة نقطة النهاية لدينا وتقييم كيفية استجابة نقطة النهاية للأحمال المعقولة والمرتفعة. تمكنا من استخدام FullStory، الذي تم استخدامه بالفعل في المنتج، لتقدير المكالمات المتوقعة في الدقيقة.
اختبارات الوحدة واختبارات التكامل: يعد اختبار الكود دائمًا فكرة جيدة، ولكن غالبًا ما يتم تجاهله في التحليلات. وهذا مهم بشكل خاص عندما تقوم بتقديم تحليل مباشر للتحايل على المستخدمين النهائيين بحيث لا يكونوا أول من يرى خطأ أو معلومات غير صحيحة. لقد قمنا بتنفيذ اختبار الوحدة واختبارات التكامل الكامل، مما يضمن أن تحليلنا سيعود بالنتائج الصحيحة.
أهمية مواءمة سير العمل والتعاون
يمثل هذا المشروع المرة الأولى التي يتعاون فيها فريقنا بشكل مباشر مع شركائنا الهندسيين لدمج واجهة برمجة تطبيقات DSE في منتجهم. طوال هذه العملية، اكتشفنا فجوات كبيرة في فهمنا لسير عمل بعضنا البعض. أدت الافتراضات حول معرفة وعمليات بعضهم البعض إلى سوء الفهم والتأخير.
مسارات النشر: اتبع شركاؤنا الهندسيون مسار نشر صارمًا، في حين كان نهجنا في جانب DSE أكثر مرونة. لقد اختبرنا عادةً عملنا على فروع الميزات باستخدام مشاريع Metaflow ثم دفعنا النتائج إلى الإنتاج. ومع ذلك، أدى هذا النقص في التحكم إلى حدوث مشكلات، مثل نشر التغييرات على الإنتاج عن غير قصد قبل أن تصبح تحديثات المنتج المقابلة جاهزة وصعوبات في إدارة نقطة نهاية الاختبار. في النهاية، لجأنا إلى شركائنا الهندسيين لإنشاء مسار نشر وتعاوننا مع فريق Metaflow ومهندسي البيانات لتنفيذه بفعالية.
تخطيط العمل: بينما كان الفريق الهندسي يعمل على سباقات السرعة، كان فريق DSE لدينا يخطط على أساس ربع سنوي. ويشكل هذا الاختلال في دورات التخطيط تحديًا مستمرًا نعمل بنشاط على حله.
وبالنظر إلى المستقبل، فإن فريقنا ملتزم بمواصلة هذه الشراكة مع زملائنا المهندسين. لقد استثمر كلا الفريقين وقتًا كبيرًا في بناء هذه العلاقة، ونحن متفائلون بأنها ستحقق فوائد كبيرة في المشاريع المستقبلية.
بالإضافة إلى العروض التقديمية المذكورة أعلاه، بدأنا قمة التحليلات بكلمة رئيسية من بن ستانسيل، مؤسس شركة Mode Analytics. قام بن باستعراض تاريخ مجموعة البيانات الحديثة، وناقشت المجموعة أفكارًا حول مستقبل التحليلات.
اكتشاف المزيد من هيدب فيديو
اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.
