آستانه شباهت نام را چطور تعیین کنیم؟ روش گام‌به‌گام

آستانهٔ شباهت نام را از روی حدس نمی‌گذارند؛ از روی نمونه‌ای از کاربران خودتان می‌گذارند. هر عددی که در یک نوشتهٔ اینترنتی ببینید، برای داده‌ای غیر از داده شما محاسبه شده است.

وقتی تطابق درصدی اطلاعات هویتی را در محصولتان می‌گذارید، چهار عدد می‌گیرید: شباهت نام، نام خانوادگی، نام کامل و نام پدر. این نوشته دربارهٔ کاری است که بعد از گرفتن آن چهار عدد باید بکنید: مرز قبول و رد را کجا بگذارید، و چطور بفهمید درست گذاشته‌اید.

دو خطایی که با یک آستانه جابه‌جا می‌شوند

هر آستانه دو نوع اشتباه می‌سازد.

• رد اشتباهی: کاربر درست رد می‌شود چون نامش را کمی متفاوت نوشته. هزینه‌اش تیکت پشتیبانی و کاربر از دست‌رفته است.
• قبول اشتباهی: کاربر نادرست رد نمی‌شود چون نامش به اندازهٔ کافی نزدیک بود. هزینه‌اش بسته به محصول شما از هیچ تا یک پرونده کلاهبرداری است.

بالا بردن آستانه اولی را زیاد و دومی را کم می‌کند، و پایین آوردنش برعکس. «آستانهٔ درست» یعنی نقطه‌ای که هزینهٔ این دو برای کسب‌وکار شما قابل تحمل است. این جمله را بپذیرید، چون بعد از آن بحث از «چه عددی» به «چه ریسکی» می‌رسد.

برای هر عدد یک آستانه جدا

چهار عدد یک رفتار ندارند. به نظر من این ترتیب سخت‌گیری منطقی است:

• نام خانوادگی: سخت‌ترین. غلط تایپی در آن کمتر رخ می‌دهد و تغییرش معنادارتر است.
• نام کامل: میانه. خلاصهٔ کلی شباهت است.
• نام: ملایم‌تر. «رضا» و «محمدرضا» اینجا فاصله می‌سازند بی‌آنکه چیزی مشکوک باشد.
• نام پدر: ملایم‌ترین. در فرم‌های واقعی این فیلد را بی‌دقت‌تر پر می‌کنند، و اگر ندهید اصلاً برنمی‌گردد.

این یک نقطهٔ شروع برای فکر کردن است، نه یک دستور. شاید در محصول شما نام پدر اصلاً لازم نباشد و بهتر است نفرستید.

سه ناحیه به‌جای دو

بیشتر تیم‌ها یک خط می‌کشند: بالا قبول، پایین رد. با چهار عدد می‌شود سه ناحیه ساخت.

1. قبول خودکار: همهٔ عددهای لازم بالای مرز بالا.
2. بررسی دستی یا اصلاح کاربر: عددی بین دو مرز.
3. رد: دست‌کم یکی از عددهای حیاتی زیر مرز پایین.

ناحیهٔ میانی مهم‌ترین بخش است. به‌جای رد خشک، به کاربر می‌گویید «نام را مطابق شناسنامه وارد کنید» و یک فرصت دیگر می‌دهید. آن‌ها که واقعاً غلط تایپ کرده بودند درست می‌شوند و بقیه خودشان را نشان می‌دهند. اگر در محصولتان بررسی دستی ممکن نیست، ناحیهٔ میانی همان بازگرداندن فرم برای اصلاح است.

برای این ناحیه کمکی هم هست: بسیاری از مغایرت‌ها اصلاً به عدد نمی‌رسند چون با یکدست‌سازی ساده حل می‌شوند. فهرستشان را در نوشتهٔ مغایرت نام آورده‌ایم.

چطور مرز را پیدا کنید

بدون عدد ساختگی، یک روش عملی:

مرحلهٔ اول: حالت سایه

چند هفته استعلام را بگیرید ولی هیچ تصمیمی بر اساسش نگیرید. عددها را در پایگاه خودتان ذخیره کنید (فقط عددها، نه نام خام) کنار نتیجه‌ای که فرایند فعلی شما داده است.

مرحلهٔ دوم: نمونهٔ برچسب‌خورده

از میان همین رکوردها نمونه‌ای بردارید و یک آدم، با مدرک در دست، برچسب بزند: درست یا نادرست. اگر هیچ برچسبی ندارید، حتی همان موارد رد شدهٔ فعلی و بررسی‌شدهٔ پشتیبانی شروع خوبی‌اند.

مرحلهٔ سوم: جدول

برای چند مرز مختلف بشمارید: چند کاربر درست رد می‌شدند و چند نادرست قبول. جدول ساده‌ای در یک اسپردشیت کافی است.

مرحلهٔ چهارم: انتخاب با هزینه

حالا مرزی را انتخاب کنید که هزینهٔ ترکیب دو خطا برای شما کمترین است. محصولی که اشتباه قبول کردن گران تمام می‌شود، مرز را بالاتر می‌برد و ناحیهٔ بررسی دستی را پهن‌تر می‌کند.

آستانه را در پیکربندی بگذارید

مرز در ماه‌های اول عوض می‌شود. اگر داخل کد باشد، هر تغییر یک استقرار است.

json { "similarity": { "lastName": { "accept": "?", "reject": "?" }, "fullName": { "accept": "?", "reject": "?" }, "firstName": { "accept": "?", "reject": "?" } } }

علامت‌های سؤال عمدی‌اند؛ اینجا عددی نمی‌دهیم چون عدد درست از داده شما می‌آید. هر تصمیم را همراه نسخهٔ پیکربندی لاگ کنید تا بعداً بدانید چرا کاربری رد شده بود.

آنچه این سرویس نمی‌کند

آستانه نمی‌گذارد و پیشنهاد هم نمی‌دهد؛ مسئولیت مرز با شماست. نام ثبت‌شده را هم برنمی‌گرداند. ورودی‌اش کد ملی و تاریخ تولد را اجباری می‌داند، و فقط در یک چیز انعطاف دارد: نام پدر اختیاری است. جزئیات را در صفحهٔ سرویس ببینید. هر پاسخ معتبر هزینه دارد، بنابراین حالت سایه را روی نمونه‌ای کوچک اجرا کنید، نه کل ترافیک؛ تعرفهٔ زنده را در صفحهٔ تعرفه می‌بینید.

نمونه‌ای از گزارش حالت سایه

بعد از چند هفته، جدولی شبیه این (با ستون‌های خودتان، بدون هیچ نام یا کد ملی) داشته باشید:

مقادیر عمداً کیفی‌اند. وقتی جدول واقعی شما پر شد، عددهایش را می‌بینید و می‌توانید بگویید: «تا اینجا بالا ببریم، رد اشتباهی از اینجا سرسام‌آور می‌شود.» اگر در نمونه، هر دو ستون برای همهٔ مرزها نزدیک صفر است، یعنی داده شما تمیز است و همان مرز میانه کافی است.

وقتی نمونه کم است

برای کسب‌وکار کوچک ممکن است در ماه فقط چند صد ثبت‌نام باشد و نمونهٔ برچسب‌خورده کم بماند. دو راه محتاط:

• مرز را سخت‌گیرانه‌تر بگذارید و ناحیهٔ بررسی دستی را عریض نگه دارید؛ هزینه‌اش وقت اپراتور است نه ریسک.
• هر تصمیم دستی را ثبت کنید. هر کدام یک نمونهٔ برچسب‌خورده است و بعد از دو سه ماه مرز را از روی آن‌ها اصلاح می‌کنید.

یک نکته دربارهٔ تفسیر عددها: دو رکورد با عدد یکسان از دو آدم متفاوت لزوماً هم‌ارز نیستند. اسم‌های کوتاه با یک حرف اختلاف، درصد خیلی بیشتری را از دست می‌دهند تا اسم‌های بلند. فرمول سرویس مرجع را نمی‌دانیم، پس هیچ فرضی دربارهٔ آن نکنید و فقط رفتارش را اندازه بگیرید.

وقتی داده با گذشت زمان عوض می‌شود

آستانه‌ای که امروز خوب است، سال دیگر ممکن است خوب نباشد. ترکیب کاربران شما عوض می‌شود: اگر کمپین جدیدی بیاورید، کاربران موبایلی بیشتر می‌شوند و غلط تایپی بیشتر می‌شود. هر سه ماه یک بار جدول حالت سایه را روی نمونهٔ تازه دوباره بسازید. اگر مرز قدیمی هنوز خوب جواب می‌دهد، دست نزنید.

پرسش‌های تیم محصول

«چرا یک عدد نمی‌دهید که فقط بگذاریم؟» چون هیچ عدد جهان‌شمولی وجود ندارد. تیمی که این عدد را از اینترنت کپی کند، یا کاربر درست را رد می‌کند یا نادرست را راه می‌دهد، و نمی‌داند کدام. «چه کسی مسئول مرز است؟» باید نامی داشته باشد. به نظر من مرز مثل یک سیاست ریسک است و مالک مشخص می‌خواهد، نه فقط یک مقدار در پیکربندی.

در یک نگاه

سه کار به ترتیب: مرزها را در پیکربندی بگذارید، حالت سایه را روی نمونه اجرا کنید، و ناحیهٔ میانی را به اصلاح کاربر وصل کنید. اگر فقط یک کار را می‌توانید بکنید، سومی را بکنید: بیشترین کاربر درست را نجات می‌دهد.