فهم عوامل درجة reCAPTCHA v3 في بيئات الاختبار المملوكة

السؤال الذي يبدأ به كثير من المطورين — «كيف أرفع درجة reCAPTCHA v3 إلى 0.9؟» — هو في الغالب السؤال الخطأ. الدرجة ليست رقمًا تتحكم فيه أنت، بل إشارة احتمالية يصدرها Google ويفسّرها مالك الموقع عند عتبة يحددها بنفسه. لذلك حين تملك الموقع أو بيئة staging الخاصة به، تتحوّل المهمة من مطاردة رقم مرتفع إلى تشخيص واضح: متى تنخفض الدرجة، وما الذي تغيّر في بيئة التشغيل، وهل انعكس ذلك على معدل القبول الفعلي عند عتبتك.

نطاق الاستخدام: هذا الدليل مخصص لقراءة درجات reCAPTCHA v3 وقرارات القبول داخل مواقع تملكها أو تختبرها بتفويض مباشر. لا يقدّم أساليب للتلاعب بالتقييم أو للعمل على مواقع طرف ثالث.

الدرجة إشارة سياقية لا حكمًا نهائيًا على الزائر

قيمة reCAPTCHA v3 لا تصف «مدى بشرية» الطلب بشكل مطلق؛ إنها تقدير احتمالي ضمن سياق صفحة ومسار محددين. من يقرر ماذا يفعل بها هو منطق موقعك أنت، وقد تختلف العتبة بين صفحة تسجيل الدخول ونموذج الاتصال وواجهة الـ API ومسار الدفع داخل التطبيق نفسه. لهذا تُقرأ البيانات التالية كمؤشرات مراقبة داخل منظومة تملكها، لا كتعليمات لتحسين درجات لا تملك ضوابطها.

تحقّق خلفي يسجّل النتيجة مع سياقها

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

import requests
from datetime import datetime


VERIFY_URL = "https://www.google.com/recaptcha/api/siteverify"


def verify_v3_token(secret_key, token, expected_action, remote_ip=None):
    payload = {
        "secret": secret_key,
        "response": token,
    }
    if remote_ip:
        payload["remoteip"] = remote_ip

    response = requests.post(VERIFY_URL, data=payload, timeout=30)
    response.raise_for_status()
    data = response.json()

    return {
        "timestamp": datetime.utcnow().isoformat() + "Z",
        "success": data.get("success", False),
        "score": data.get("score"),
        "action": data.get("action"),
        "hostname": data.get("hostname"),
        "expected_action": expected_action,
        "action_matches": data.get("action") == expected_action,
        "errors": data.get("error-codes", []),
    }


def classify_result(result, threshold):
    if not result["success"]:
        return "verify-error"
    if not result["action_matches"]:
        return "action-mismatch"
    if result["score"] is None:
        return "missing-score"
    if result["score"] >= threshold:
        return "accepted"
    return "step-up-or-review"

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

سيناريو من السوق: قبول ينخفض بعد نشر جديد

تخيّل فريقًا يدير متجرًا إلكترونيًا يخدم عملاء في القاهرة والرياض، ويحمي مسار الدفع بـ reCAPTCHA v3 عند عتبة 0.5. بعد نشر إصدار جديد لواجهة الدفع، قفزت فجأة نسبة العمليات التي تلقّت تحديًا إضافيًا، وبدأ العملاء يشتكون من خطوات زائدة عند إتمام الشراء. أظهر السجل التشخيصي الصورة كاملة:

• قيمة action المُرسَلة من الصفحة الجديدة أصبحت checkout_v2 بينما ظل التحقق الخلفي ينتظر checkout.
• توزّع score نفسه لم يتغيّر؛ بقي على مستواه قبل النشر تمامًا.
• انقلب القرار من «قبول» إلى «تحدٍّ إضافي» في كل طلب لا يطابق إجراؤه المتوقَّع.
• أعادت دالة classify_result القيمة action-mismatch لا step-up-or-review، فحدّدت السبب فورًا.

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

العوامل التي تستحق القياس داخل بيئتك

عوامل عدّة تؤثر في الدرجة أو في القرار المبني عليها، والطريق الصحيح هو قياسها ومقارنتها داخل النظام ذاته لا تخمينها:

1. اتساق البيئة: اختلاف إعدادات المتصفح أو زمن التحميل أو ترتيب الخطوات بين أجهزة المطورين وبيئة CI قد يزيح النتيجة.
2. صحة الإجراء: إذا استدعت الصفحة action=login بينما ينتظر الخلفي signup، فالخلل في الدمج لا في الدرجة.
3. الزمن بين التحميل والإرسال: النماذج التي تُرسَل قبل اكتمال عناصر الصفحة أو قبل تهيئة reCAPTCHA تُعطي نتائج غير مستقرة.
4. استمرارية الجلسة داخل التطبيق: إعادة استخدام جلسة مملوكة في بيئة الاختبار قد تُنتج سلوكًا مختلفًا عن جلسة جديدة، ويجب رصد ذلك بوضوح لا افتراضه «تحسنًا» عامًا.
5. القرار الخلفي عند العتبة: درجة 0.6 قد تُقبَل في مسار وتُرفَض في آخر حين تختلف العتبة.

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

قياس CaptchaAI بلا وعود بدرجة ثابتة

يدعم CaptchaAI حلّ reCAPTCHA v3 عبر الـ API، ويمكن إدراجه ضمن قياس التكامل في بيئة تملكها — بشرط صياغة النتائج على أنها تقديرات داخلية لا وعود عامة. الدرجة يمنحها Google لا أي مزوّد، فلا يصحّ لأحد أن يضمن قيمة ثابتة عبر كل موقع وكل وقت. بدل السؤال «كيف أحصل على 0.9 دائمًا؟» اطرح أسئلة قابلة للقياس:

• ما نسبة الطلبات التي قُبِلت عند عتبة 0.5 في staging خلال آخر 100 تشغيل؟
• هل تتغير النتائج بين تشغيل محلي وبيئة CI أو متصفح مستضاف؟
• هل يوجد فرق بين صفحة تسجيل الدخول ونموذج الدفع داخل التطبيق نفسه؟
• هل ظهر انحراف واضح بعد تحديث المتصفح أو إطار الاختبار؟

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

قائمة تحقّق قبل تثبيت العتبة

ما الذي يقع خارج نطاق هذا الدليل

لا يقدّم هذا الدليل إرشادات حول:

• استخدام عناوين IP أو ملفات تعريف ارتباط تابعة لطرف ثالث للتأثير على الدرجة
• محاكاة سلوك بشري اصطناعي لخداع أنظمة التقييم
• توجيه الطلبات إلى مواقع لا تملكها أو لا تختبرها بتفويض مباشر
• الوعد بأن مزوّدًا معينًا سيمنحك درجة ثابتة في كل موقع وكل وقت

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

أسئلة شائعة

لماذا تنخفض الدرجة في بيئة CI بينما ترتفع على جهاز المطوّر؟

غالبًا بسبب اختلاف بصمة المتصفح أو زمن التحميل أو غياب التفاعل الطبيعي في بيئة آلية. قِس المسار نفسه في البيئتين وسجّل الفروق قبل تعديل العتبة.

كيف أفرّق بين رفض سببه action ورفض سببه الدرجة؟

سجّل قيمة action المتوقعة والمُستلمة مع كل تحقق. إذا لم يتطابقا فالسبب هو الدمج بصرف النظر عن قيمة score؛ الدالة classify_result أعلاه تفصل الحالتين تلقائيًا.

كم عدد التشغيلات اللازمة قبل الحكم على انحراف الدرجة؟

عينة من عشرة طلبات لا تكفي عادة. اجمع عشرات التشغيلات على المسار والعتبة ذاتهما حتى يستقر التوزّع قبل أي استنتاج.

هل يضمن أي مزوّد درجة ثابتة عبر كل المواقع؟

لا. الدرجة يصدرها Google وفق سياق كل موقع، فلا يملك أي مزوّد — بما فيه CaptchaAI — ضمان قيمة موحّدة. الصياغة الصحيحة هي قياس معدل القبول داخل بيئتك ثم القرار.

أدلة ذات صلة

• الحفاظ على جلسة المتصفح في سير عمل اختبار CAPTCHA
• ابدأ سريعًا مع CaptchaAI وحلّ أول كابتشا في 5 دقائق

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