پایش اینماد فروشندگان و شرکا: زمان‌بندی، دامنه و منطق تصمیم

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

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

ورودی: دامنه، نه نشانی کامل

سرویس یک دامنه می‌گیرد. ما پیش از ارسال، حروف را کوچک می‌کنیم، پروتکل و www را برمی‌داریم و هر چه بعد از اولین اسلش آمده را حذف می‌کنیم. پس https://www.Shop.example.ir/products?id=3 به shop.example.ir تبدیل می‌شود.

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

• دامنه‌ای که در پایگاه داده‌ی شما ذخیره می‌شود باید همان شکل نهایی باشد تا دو ورودی مختلف از یک فروشنده، دو رکورد نسازند.
• زیردامنه‌ها را خودتان مدیریت کنید. اگر فروشنده‌ای app.shop.example.ir را وارد کند، آیا نماد برای shop.example.ir صادر شده؟ این را نمی‌توانیم به جای شما حدس بزنیم. روی هر دو بپرسید و نتیجه‌ها را ببینید.

یک قاعدهٔ اعتبارسنجی هم داریم: نشانی باید دست‌کم یک نقطه داشته باشد و فقط حروف لاتین، رقم و خط‌تیره بپذیرد. دامنهٔ فارسی (IDN) را به‌صورت پیونی‌کد (xn--) بفرستید.

نتیجه را چطور نگه دارید

یک مدل داده‌ی ساده:

دو نکته. اول، تاریخ انقضا و نشانهٔ منقضی را هر دو نگه دارید و هر دو را بسنجید؛ در روزهای نزدیک به انقضا ممکن است با هم تفاوت داشته باشند. دوم، رشتهٔ خام رسته را حفظ کنید و تفکیک را در لایهٔ جداگانه انجام دهید تا بتوانید منطق را بعداً تغییر دهید.

زمان‌بندی پایش

به نظر من ساده‌ترین الگوی مفید این است:

• هنگام پذیرش فروشنده: یک بار.
• هر فروشنده‌ای که تاریخ انقضایش در ۶۰ روز آینده است: هفته‌ای یک بار.
• بقیه: ماهی یک بار.

این اعداد سلیقهٔ من است؛ شما بر اساس ریسک خود تنظیمشان کنید. اصل این است که فراوانی استعلام را به نزدیکی انقضا گره بزنید، نه یک بازهٔ ثابت برای همه. هر استعلام موفق هزینه دارد (جزئیات در تعرفه) و استعلام تکراری از نمادی که یک سال دیگر منقضی می‌شود، اطلاعات تازه‌ای نمی‌آورد.

سه نتیجه، سه رفتار

دارد و معتبر است. ذخیره کنید، زمان استعلام بعدی را تنظیم کنید.

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

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

جلوگیری از مثبت کاذب

برای هر هشدار «ندارد»، قبل از اینکه به انسان برسد، سه کنترل ارزان انجام دهید:

1. دامنه را با و بدون زیردامنه امتحان کنید.
2. مطمئن شوید رشته دامنه واقعاً در فهرست فروشنده یک غلط املایی ندارد.
3. اگر فروشنده چند دامنه دارد، همه را بررسی کنید.

این سه کار تعداد هشدارهای بی‌اساس را به‌شدت کم می‌کند.

خطاها و دوباره‌تلاشی

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

داده‌ی ناقص و نمایش

فیلدهایی مثل استان و شهر ممکن است برای بعضی نمادها خالی یا قدیمی باشند؛ تصمیم بر اساس آن‌ها نگیرید. برای نمایش، به‌جای نمایش خام، تاریخ‌ها را همان شمسیِ برگشتی نشان دهید و فقط در پایگاه داده‌ی تحلیلی به میلادی تبدیل کنید.

آنچه پایش اینماد نمی‌کند

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

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

یک مثال از قاعدهٔ هشدار

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

این تفکیک مهم است چون سه گروه مسئول متفاوت‌اند. اگر همه را در یک صف بریزید، تیم ریسک زیر خطاهای فنی دفن می‌شود و تیم فنی از مشکلات تجاری سردرگم.

استفاده از استعلام اینماد در لحظهٔ ثبت‌نام

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

چک‌لیست راه‌اندازی

پیش از روشن‌کردن پایش، این فهرست را مرور کنید: دامنه‌ها یکدست و بدون تکرار هستند؛ مدل داده سه وضعیت دارد (دارد، ندارد، نامشخص)؛ هشدارها به صف‌های جدا می‌روند؛ نتیجهٔ هر استعلام با تاریخ ذخیره می‌شود؛ و یک نفر مسئول بازبینی هشدارهاست. بدون مسئول مشخص، هشدارها در عمل خوانده نمی‌شوند و پایش به یک جدول بی‌استفاده تبدیل می‌شود.

در یک نگاه

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