---
url: 'https://www.corbado.com/ar/blog/authentication-process-mining'
title: 'التنقيب في عمليات المصادقة: التخصص القادم في CIAM'
description: 'يحول التنقيب في عمليات المصادقة سجلات أحداث مفاتيح المرور إلى رحلات تسجيل دخول محسنة. تعرف على تخصص قابلية المراقبة في CIAM وراء المصادقة المتصاعدة والتحليلات.'
lang: 'ar'
author: 'Vincent Delitz'
date: '2026-05-19T14:50:47.106Z'
lastModified: '2026-05-20T06:04:06.401Z'
keywords: 'التنقيب في عمليات المصادقة، مصادقة رحلة المستخدم، قابلية المراقبة في CIAM، المصادقة المتصاعدة، تحسين رحلة المصادقة'
category: 'Passkeys Strategy'
---

# التنقيب في عمليات المصادقة: التخصص القادم في CIAM

## Key Facts

- يطبق **التنقيب في عمليات المصادقة** **إعادة بناء سجل الأحداث** على غرار **Celonis**،
    والذي أضفى عليه الطابع الرسمي **IEEE Task Force on Process Mining** لسير عمل **ERP**
    في **العقد الأول من القرن الحادي والعشرين**، على مراسم تسجيل الدخول باستخدام مفتاح
    المرور. - يتطلب ذلك **طبقة قابلية مراقبة من جهة العميل**. تسجل **سجلات IDP**
    **المحاولة** و**النجاح** و**الفشل** من جهة الخادم، وتفتقد **Conditional UI**،
    والمطالبات البيومترية، واختيار **مدير بيانات الاعتماد (credential manager)**، والتخلي
    الصامت. - في عمليات النشر المراقبة، يتبع حوالي **30%** فقط من المستخدمين المؤهلين
    **المسار السعيد المصمم لمفتاح المرور**، وعادةً ما يخفي **معدل النجاح الإجمالي البالغ
    92%** **معدل تخلٍ يبلغ 40%** على مسار مفتاح المرور وحده. - تمثل **أهم خمسة متغيرات
    للانحراف** عادةً **85%** من جميع الانحرافات، لذا فإن الإصلاحات المستهدفة تدفع التبني
    بشكل أكبر من أي اختبار A/B على المسار السعيد. - يحتاج نموذج الحدث إلى **3 أنواع بدء**
    (`text-field`، `one-tap`، `cui`)، و**6 فئات للنتائج**، و**مخزون بيانات اعتماد** مقسم
    حسب **النقل** والمصادق (**Apple**، و**Google Password Manager**، و**iCloud Keychain**،
    و**Windows Hello**، و**YubiKey**). - تحول بيانات التنقيب في العمليات **المصادقة
    المتصاعدة (step-up authentication)** من قاعدة OTP فظة - احتكاك بنسبة **95%** من حركة
    المرور المشروعة للقبض على **5%** مشبوهة - إلى **قرار مستمر مقيّم بالمخاطر**. - لا يوجد
    **IDP** يوفر هذا بشكل أصلي: تمتلك **Okta** و**Ping** و**ForgeRock** و**Auth0** **مستوى
    التحكم**، بينما يعد التنقيب في العمليات **تخصصاً في مستوى البيانات**، مما يجعل **تحليل
    المتغيرات** و**اكتشاف انحراف المجموعة** و**التحقق من المطابقة** أمراً إلزامياً لفرق
    تحليلات CIAM بحلول عام **2027**.

## 1. المقدمة

تدفع مفاتيح المرور (passkeys) مجال CIAM إلى الأمام. بدأت الفرق الأفضل في فئتها في أداة
رحلة تسجيل الدخول من البداية إلى النهاية، وتصنيف الأخطاء التي لم تقم بتسجيلها من قبل،
وإلقاء نظرة على القياس عن بُعد من جهة العميل لأول مرة. الغالبية العظمى من فرق الهوية لم
تصل إلى هذا الحد بعد: لا توجد طبقة حقيقية لقابلية مراقبة المصادقة، ولا يوجد رسم بياني
للأحداث لكل جلسة، ولا توجد بيانات مراسم من جهة العميل. لا تزال محاولة جهة الخادم والنجاح
والفشل تشكل الصورة الكاملة.

التنقيب في عمليات المصادقة هو الخطوة المنطقية التالية ولكن فقط بمجرد وجود بيانات الحدث
الأساسية هذه. بدون طبقة قابلية المراقبة، لا يوجد شيء للتنقيب فيه. بوجودها، يصبح هناك تخصص
جديد متاحاً. إنه يستعير مباشرة من التنقيب في العمليات التجارية، والذي حوّل سجلات أحداث ERP
الخام إلى سير عمل محسّن في العقد الأول من القرن الحادي والعشرين. عند تطبيقه على الهوية،
فإنه يقارن رحلة تسجيل الدخول المصممة بالرحلة الفعلية، ويظهر مسارات الانحراف ثم يسد الفجوة
باستخدام المصادقة المتصاعدة (step-up authentication) الدقيقة، أو قواعد المنع، أو تغييرات
تجربة المستخدم التي يتم قياسها من البداية إلى النهاية.

يعيد هذا المقال تأطير ما يجب أن تبنيه فرق CIAM فوق طبقة قابلية مراقبة المصادقة.

### 1.1 أسئلة يجيب عليها هذا المقال

نتناول في هذا المقال الأسئلة التالية:

1. ماذا فعل التنقيب في العمليات لـ BPM، وما هو الموازي المباشر للمصادقة؟
2. لماذا أبرزت عمليات نشر مفاتيح المرور هذه الفجوة، ولماذا لم تكن سجلات المصادقة كافية
   بمفردها أبداً؟
3. كيف يبدو نموذج حدث التنقيب في عمليات المصادقة فعلياً من البداية إلى النهاية؟
4. كيف يرتبط التنقيب في العمليات بـ المصادقة المتصاعدة الدقيقة والتفويض؟
5. ماذا يعني هذا لمشهد بائعي CIAM ولفرق الهوية التي تمتلك بالفعل IDP؟

## 2. ماذا فعل التنقيب في العمليات لـ BPM

### 2.1 من سجلات الأحداث إلى العمليات المحسنة

ظهر التنقيب في العمليات التجارية من إدراك أن كل نظام ERP أو CRM أو نظام تذاكر يكتب سجلات
أحداث والتي، عند إعادة بنائها، تكشف عن سير العمل الفعلي، وليس ذلك الموجود على ويكي. طلب
الشراء الذي كان من المفترض أن يمر عبر ثلاثة معتمدين، تبين أنه يتم توجيهه حول اثنين منهم في
40% من الوقت. تدفق المطالبات الذي تم توثيقه كخط مستقيم يلتف حول نفسه خمس مرات لـ 18% من
المطالبات. أدوات التنقيب في العمليات مثل تلك التي أشاعتها Celonis أعادت بناء تلك الرسوم
البيانية من الأحداث ذات الطوابع الزمنية وسمحت للمشغلين بطرح سؤال جديد: أين تنحرف العملية
الفعلية عن العملية المصممة، وما هي تكلفة هذا الانحراف؟

### 2.2 موازٍ في المصادقة

تمتلك المصادقة نفس الهيكل. كل تسجيل دخول هو تسلسل زمني للأحداث: تم تحميل الصفحة، وتم إدخال
المعرّف، وتم تحديد التحدي، وتمت المطالبة البيومترية، وتم إرجاع التأكيد (assertion).
التوازي الهيكلي دقيق. الفرق العملي هو أنه، على عكس ERP أو CRM، لا توجد بيانات الأحداث هذه
في سجلات IDP الخاصة بك - على الأقل ليس بالشكل الدقيق الذي يحتاجه التنقيب في العمليات. تسجل
معرفات IDP نتائج تسجيل الدخول والطريقة المستخدمة. إنها لا تسجل المراسم من جهة العميل
تحتها: استدعاء [Conditional UI](https://www.corbado.com/glossary/conditional-ui)، والمطالبات البيومترية، واختيار
مدير بيانات الاعتماد، والتخلي الصامت قبل أن يصل الطلب إلى الخادم. يجب تزويد طبقة ما قبل
التأكيد (assertion) بأدوات في طبقة حزمة SDK للواجهة الأمامية وإعادة تجميعها في رسم بياني
لكل جلسة قبل أن يتمكن التنقيب في العمليات من العمل عليها.

بمجرد وجود البيانات، يتم تطبيق نفس التقنيات: رحلة مفتاح المرور المصممة مقابل رحلة مفتاح
المرور الفعلية، وتدفق الاسترداد المصمم مقابل تدفق الاسترداد الفعلي، والتصاعد المصمم مقابل
التصاعد الفعلي. الانضباط الأكاديمي حول هذا العمل آخذ في النضج. نقطة الدخول المفيدة هي
[Process Mining Manifesto](https://www.tf-pm.org/resources/manifesto) من IEEE Task Force
on Process Mining، والذي يحدد التحقق من المطابقة، وتحليل المتغيرات، والتحسين باعتبارها
التقنيات الأساسية الثلاث. يتم تعيين كل منها بشكل فردي على المصادقة.

## 3. لماذا أبرزت عمليات نشر مفاتيح المرور الفجوة

### 3.1 مفاتيح المرور تجبر الفرق على إعادة التفكير في تسجيل الواجهة الأمامية

سجلت مصادقة كلمة المرور الكلاسيكية ثلاثة أشياء من جهة الخادم: المحاولة، والنجاح، والفشل.
هذا يكفي لتشغيل نظام كلمة المرور، لأن وضع الفشل بسيط: أخطأ المستخدم في كتابة سلسلة،
والمحاولة التالية إما نجحت أو لم تنجح. مع مفاتيح المرور، تنتقل اللحظات الحرجة إلى الواجهة
الأمامية: إطلاق [Conditional UI](https://www.corbado.com/glossary/conditional-ui)، وقرار المتصفح بشأن ما إذا كان
سيعرض مطالبة، واختيار مدير بيانات الاعتماد، ونجاح التحدي البيومتري أو رفضه. يحدث كل هذا
على جهاز المستهلك، قبل أن يصل التأكيد (assertion) إلى النهاية الخلفية.

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

### 3.2 الفجوة بين الرحلة المصممة والرحلة الفعلية

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

### 3.3 لماذا لم تكن سجلات المصادقة كافية أبداً

تخبرك سجلات المصادقة بمفردها بالنتائج. إنها لا تخبرك بالمسارات. يمكن لـ معدل نجاح تسجيل
الدخول البالغ 92% عبر جميع الطرق أن يخفي معدل تخلٍ يبلغ 40% على مسار مفتاح المرور ومعدل
تخلٍ يبلغ 15% على مسار كلمة المرور، مما ينتج عنه في النهاية "على ما يرام". يرفض التنقيب في
العمليات هذا المتوسط. ويصر على النظر في كل متغير على حدة ثم ترتيب المتغيرات حسب التكرار
والتكلفة ومعدل الفشل.

## 4. كيف يبدو التنقيب في عمليات المصادقة فعلياً

### 4.1 نموذج الحدث: العمليات والأحداث وتصنيف النتائج

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

**البيانات الوصفية للعملية.** تحتوي كل عملية على معرف عملية وطابع زمني. وهي مرتبطة بتطبيق
ونظام تشغيل ومتصفح وعلامة تجارية للجهاز. ويتم تمييزها بفئة زائر (مستخدم حقيقي، مُختبر
يدوي، مُختبر آلي، لم يُصنف بعد) بحيث يمكن فصل حركة المرور الآلية والروبوتات قبل حساب أي
مقياس. كما أنها تحمل درجة عملية وعدد أحداث، وهما أبسط إشارتين لـ "مدى تعقيد هذه الجلسة
بالذات".

**بدء تسجيل الدخول.** تسجل كل عملية كيفية بدء التدفق. أنواع البدء الرئيسية هي `text-field`
(كتب المستخدم معرّفه)، و `one-tap` (تمت إعادة استخدام معرّف مخزن) و `cui` (أظهر
[Conditional UI](https://www.corbado.com/glossary/conditional-ui) بيانات اعتماد بدون نقرة صريحة على الزر). يعد
البدء بُعداً وليس مقياساً: يمكن أن يبدو نفس النشر مختلفاً جداً في مجموعة `cui` عنه في
مجموعة `text-field`، والمتوسط بينهما يخفي بالضبط السلوك الذي يُقصد للتنقيب في العمليات
الكشف عنه.

**تصنيف النتيجة.** بدلاً من "النجاح" أو "الفشل"، تكون النتيجة واحدة من عدة فئات تُعين
سلوكاً مميزاً. ومثال على مفاتيح المرور هو التالي:

- `completed` - انتهت المراسم وتمت مصادقة المستخدم.
- `filtered-explicit-abort` - رأى المستخدم مطالبة وألغاها صراحةً.
- `filtered-implicit-abort` - ابتعد المستخدم أو انتهت المهلة دون اتخاذ قرار.
- `filtered-passkey-intel` - قمعت طبقة ذكاء جهة العميل مسار مفتاح المرور عن قصد، عادةً لأن
  مجموعة الجهاز/نظام التشغيل معروفة بوجود كسر بها.
- `filtered-no-start` - لم يتقدم التدفق أبداً بعد خطوة الإدخال.
- `not-loaded` - لم يكتمل تحميل واجهة المصادقة أبداً.

تمتلك مراسم الإلحاق (إنشاء بيانات الاعتماد) تصنيفاً موازياً، بما في ذلك حالة
`completed-exclude-credentials` عندما يكون لدى المستخدم بالفعل بيانات اعتماد.

**طبقات مسار التحويل والمخزون.** علاوة على العمليات، توجد طبقتان مجمعتان تهمان. تقوم
**طبقة مسار التحويل (funnel layer)** بتجميع العمليات بمرور الوقت حسب النتيجة، والبدء،
وحالة الاكتمال، ونظام التشغيل، والتطبيق، لكل من تسجيل الدخول والإلحاق. تقوم **طبقة مخزون
بيانات الاعتماد** بتجميع مفاتيح المرور الحالية حسب حالة المزامنة (متزامنة مقابل غير
متزامنة)، والنقل (`internal`، `hybrid`، `usb`، `nfc`، `ble`، `smart-card`)، والمصادق
(Apple، و[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)،
و[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)، و[Windows Hello](https://www.corbado.com/glossary/windows-hello)،
و[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)،
و[Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024)،
و[Dashlane](https://www.corbado.com/blog/dashlane-passkeys)، و[YubiKey](https://www.corbado.com/glossary/yubikey))، ونظام التشغيل
والمتصفح. بدون طبقة المخزون، من المستحيل السؤال عما إذا كان متغير انحراف معين يتركز على
مدير بيانات اعتماد معين أو حالة مزامنة.

هذا هو الحد الأدنى للشكل الذي يجعل التنقيب في العمليات قابلاً للتتبع. يحمل كل حدث ما يكفي
من البيانات الوصفية ليتم تجميعه وتصفيته وترتيبه. يمكن تتبع كل عملية بشكل فردي، وهو ما
يمكّن الأمثلة العملية أدناه.

### 4.2 المسار السعيد مقابل تحليل الانحراف

بمجرد تخزين الأحداث كرسم بياني موجه لكل جلسة، يمكنك طرح سؤال التنقيب في العمليات: ما هي
النسبة المئوية للجلسات التي تتبع المسار السعيد، وبالنسبة لتلك التي لا تتبعه، ما هي أهم
خمسة متغيرات للانحراف مرتبة حسب التكرار؟ في بيانات التحليلات الخاصة بنا، تمثل أهم خمسة
متغيرات عادةً 85% من جميع الانحرافات. عادةً ما يؤدي إصلاح اثنين منها إلى تحريك الأرقام
أكثر من أي اختبار A/B على المسار السعيد.

### 4.3 اكتشاف انحراف المجموعة

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

## 5. من التنقيب في العمليات إلى المصادقة المتصاعدة الدقيقة

### 5.1 لماذا تم استخدام المصادقة المتصاعدة بشكل غير كافٍ

وُجدت المصادقة المتصاعدة لأكثر من عقد من الزمان. تم استخدامها بشكل غير كافٍ لأن معظم الفرق
تقوم بالتصاعد بنفس الطريقة بغض النظر عن المخاطر: فرض
[OTP](https://www.corbado.com/ar/blog/بنوك-سنغافورة-passkeys-استبدال-otp) على كل معاملة أعلى من الحد الأدنى. هذه
قاعدة فظة، وليست قراراً مقيماً بالمخاطر. إنها تخلق احتكاكاً على 95% من المعاملات المشروعة
ذات القيمة العالية لإيقاف الـ 5% المشبوهة.

### 5.2 الرحلات المقيمة بالمخاطر

مع بيانات التنقيب في العمليات، يمكنك تسجيل جلسة باستمرار. سمعة الجهاز، ومعدل النجاح
الأساسي للمجموعة، والشذوذ في الوقت من اليوم، والانحراف عن المسار التاريخي للمستخدم نفسه،
وهوية مدير بيانات الاعتماد، وسمعة IP. ثم يدفع مقياس المخاطر قرار تصاعد دقيقاً: طلب عامل
ثانٍ فقط عندما تتجاوز درجة مخاطر الجلسة حد قيمة المعاملة. الجلسات منخفضة المخاطر للمعاملات
ذات القيمة العالية تمر. الجلسات عالية المخاطر للمعاملات ذات القيمة المنخفضة يتم تصعيدها.

## 6. ماذا يعني هذا لمشهد بائعي CIAM

### 6.1 تصميم الرحلة كتخصص دقيق

قامت صناعة الهوية تاريخياً بتجميع تصميم الرحلة داخل IDP. تتيح لك محركات التنسيق داخل Okta
وPing وForgeRock و[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) وغيرها تكوين التدفقات. ما لا
تفعله جيداً هو مراقبتها. هذا عدم التطابق هو ما يفتح المجال لطبقة تحليلات متخصصة.

### 6.2 لماذا لن يوفر أي IDP هذا بشكل أصلي

يعمل بائعو IDP على تحسين مستوى التحكم: من يمكنه تسجيل الدخول، وبأي بيانات اعتماد، وبموجب
أي سياسة. التنقيب في العمليات هو تخصص في مستوى البيانات: كل حدث، على نطاق واسع، تم تطبيعه
عبر مجموعات نظام التشغيل/المتصفح/مدير بيانات الاعتماد. حجم الحدث، والعددية، وخطوط الأساس
عبر العملاء كلها تعمل ضد بناء IDP أصلي. انظر الملاحظات الميدانية في دليل الشراء مقابل
البناء لمفاتيح المرور للحصول على نفس النمط المطبق على طبقة SDK.

### 6.3 طبقة التحليلات كفئة جديدة

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

## 7. كيف تساعد Corbado في التنقيب في عمليات المصادقة

توفر [Corbado](https://www.corbado.com/) طبقة القياس والتبني التي تجلس فوق معرّفات IDP
الحالية. تتكامل مع Okta و[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) وOry وForgeRock والحزم
المخصصة دون استبدالها. ما تضيفه هو تحديداً قدرة التنقيب في العمليات:

- **تصنيف الأحداث من البداية إلى النهاية.** تلتقط حزمة SDK من جهة العميل المراسم الكاملة
  من تحميل الصفحة إلى التأكيد (assertion)، بما في ذلك أحداث ما قبل المعرّف، واستدعاء
  Conditional UI واختيار مدير بيانات الاعتماد.
- **تحليل المتغيرات جاهز للاستخدام.** تقوم المنصة بإعادة بناء رسوم بيانية للرحلة لكل
  مجموعة وترتب متغيرات الانحراف حسب التكرار وفرصة الاسترداد والتكلفة.
- **تنبيه انحراف المجموعة.** عندما يتغير توزيع متغير لنظام تشغيل أو متصفح أو مدير بيانات
  اعتماد معين، فإن المنصة تحدده قبل أن يصبح مشكلة اليوم الثاني. انظر لماذا Corbado للتعرف
  على النهج الكامل.
- **خطوط الأساس عبر النشر.** نظراً لأن Corbado تقوم بتجميع بيانات مجهولة المصدر عبر بيئات
  العملاء، فإن الأخطاء أو التراجعات الجديدة التي تظهر في نشر واحد يتم تصنيفها وتوثيقها قبل
  أن تصل إليك.
- **التعليقات والملاحظات في التنسيق.** يمكن دفع قرارات التصاعد المقيمة بالمخاطر وقواعد
  المنع مرة أخرى إلى IDP أو معالجتها في طبقة التبني، بما في ذلك مفاتيح الإيقاف الديناميكية
  والتنبيهات الخاصة بالمجموعة.

## 8. الخاتمة

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

## الأسئلة الشائعة (FAQ)

### ما هو التنقيب في عمليات المصادقة؟

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

### كيف يختلف عن تحليلات المصادقة؟

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

### لماذا يجعل تبني مفتاح المرور هذا التخصص ضرورياً؟

عمليات نشر مفاتيح المرور هي السبب الأول الذي يجعل فرق CIAM تقوم بأدوات أحداث جهة العميل
على الإطلاق. بمجرد وجود هذه الأحداث، تخفي المقاييس الإجمالية الكثير: يمكن أن يخفي معدل
نجاح بنسبة 92% معدل تخلٍ بنسبة 40% على مسار مفتاح المرور. يرفض التنقيب في العمليات هذا
المتوسط ويجبر الفرق على النظر في المتغيرات بشكل منفصل.

### كيف يرتبط التنقيب في العمليات بالمصادقة المتصاعدة؟

تعمل المصادقة المتصاعدة (Step-up authentication) بشكل أفضل عندما تكون مقيمة بالمخاطر بدلاً
من أن تكون مبنية على قواعد. يوفر التنقيب في العمليات الأدلة على مستوى الجلسة (الأساس
للمجموعة، والانحراف عن المسار التاريخي للمستخدم، وسمعة الجهاز) التي تتيح لمحرك التصاعد
اتخاذ قرار دقيق بدلاً من قرار حدٍ فظ.

### هل سيوفر IDP الخاص بي هذا بشكل أصلي؟

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

### ما هو أول شيء يجب على فريق CIAM قياسه؟

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