ما يخسره الباحثون عندما تصبح التحليلات فكرة لاحقة

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

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

المشكلة بعبارات واضحة

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

في تلك المرحلة، تحتوي المنصة على بيانات، لكن الفريق ليس لديه أدلة بعد. يعد تعريف SoLAR لعام 2025 مفيدًا هنا لأنه يتعامل مع تحليلات التعلم على أنها جمع وتحليل وتفسير وتواصل في خدمة الرؤية ذات الصلة من الناحية النظرية والقابلة للتنفيذ.[1] تصل قواعد الممارسة الخاصة بشركة Jisc إلى نتيجة ذات صلة من خلال الصلاحية والشفافية والإشراف.[2]

كيف يبدو نمط التفكير اللاحق

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

ينتج عن ذلك عادةً ثلاثة أنماط: يقوم النظام بتسجيل كل ما يكشفه بالفعل، ويتم تقديم المعايير بعد فوات الأوان لتشكيل الأجهزة، ويصبح إعداد التقارير منفصلاً عن غرض البحث. تشير كل من xAPI، وProfiles Work، وCaliper، و1EdTech إلى نفس الدرس العملي: يجب تحديد التصنيف ومعنى الحدث قبل القياس.[3][4][5][6]

ما يضيع

1. أصبح تعريف الحدث غير متناسق

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

2. يتم تجريد السياق من البيانات

نادرًا ما تحتاج فرق البحث إلى معرفة حدوث شيء ما فقط. كما يحتاجون أيضًا إلى معرفة ما إذا كان الفعل قد حدث في حالة تدخل أو سيطرة، وما إذا كان مُيسرًا أم ذاتيًا، وإلى أي مرحلة من الدراسة ينتمي. تعمل تحليلات FAIR وCaliper وPractable Learning Analytics على تعزيز الارتباط بين البيانات الوصفية والمصدر والتفسير اللاحق.[7][5][8]

3. إمكانية المقارنة عبر الدراسات معرضة للخطر

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

4. طبقة التقارير تجيب على الأسئلة الخاطئة

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

5. تصبح إدارة البيانات تفاعلية

عندما يتطور التقاط البيانات بشكل انتهازي، يمكن أن ينتهي الأمر بالمؤسسات إلى جمع بيانات شخصية أكثر مما تحتاج إليه، أو الاحتفاظ بها لفترة أطول من اللازم، أو النضال من أجل شرح ما يتم جمعه ولماذا يتم جمعه بوضوح. يشير إطار عمل DELICATE وCormack وتوجيهات ICO الحالية إلى نفس النتيجة: يجب تصميم الحوكمة في ممارسة التحليلات، وليس إلحاقها لاحقًا.[11][12][13][14]

قرارات التصميم المهمة مبكرًا

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

1. حدد نموذج الحدث قبل أن تصبح الواجهة نهائية.
2. حدد بيانات التعريف السياقية إلى جانب الأحداث الأساسية.
3. مراقبة العمليات بشكل منفصل عن متطلبات الأدلة.
4. بناء إمكانية المقارنة في المواصفات.
5. الإشراف على التصميم في الهندسة المعمارية.

التصميم المدرك للتحليلات ليس ساحرًا. ويعني ذلك عادةً تحديد الأمور مبكرًا، وتوثيقها بعناية أكبر، ومقاومة إغراء التعامل مع لوحات المعلومات كبديل لهندسة البيانات.

ماذا يعني هذا عمليا

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

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

بالنسبة لفرق التكنولوجيا المؤسسية، الدرس المقابل بسيط: لا تعامل "لديه تحليلات" كمطلب مناسب. اسأل عما إذا كانت متطلبات التحليلات قد تم تحديدها قبل الانتهاء من بنية النظام، وكيف يتم إصدار تغييرات الأجهزة، وما إذا كانت مقاييس لوحة المعلومات تتوافق مع أسئلة البحث بدلاً من مجرد الراحة التشغيلية.[2][6]

إغلاق

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

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