این سند فرآیندی را برای ساخت یک سیستم بررسی آدرس برای مدیریت پاسخ‌های متنوع از API اعتبارسنجی آدرس شرح می‌دهد. این سند نحوه تفسیر پاسخ API را به منظور تعیین زمان و نحوه درخواست اطلاعات بیشتر از مشتریان شما پوشش می‌دهد.
به طور کلی، پاسخ API روش‌های زیر را برای مدیریت یک آدرس توسط سیستم شما تعیین می‌کند:
- - آدرس ممکن است حاوی مشکلات قابل توجهی باشد.
در نظر داشته باشید که از مشتری خود بخواهید اطلاعات بیشتری ارائه دهد. - اضافه کردن زیرمحل‌ها — ممکن است آدرس فاقد یک زیرمحل باشد.
در نظر بگیرید که از مشتری خود بخواهید شماره واحد را اضافه کند. - تأیید — آدرس ممکن است دارای مشکلات جزئی باشد.
در نظر داشته باشید که از مشتری خود بخواهید صحت آدرس را تأیید کند. - قبول را — ممکن است آدرس مشکلی نداشته باشد.
استفاده از آدرس را بدون درخواست بیشتر، با مسئولیت خودتان در نظر بگیرید.
هدف کلیدی
این سند به شما کمک می‌کند تا سیستم خود را اصلاح کنید تا به بهترین شکل پاسخ API را تجزیه و تحلیل کرده و اقدامات بعدی را با آدرس‌های ارائه شده تعیین کنید. شبه‌کد زیر یک جریان ممکن را نشان می‌دهد.
if (verdict.possibleNextAction == FIX)
Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
Confirm with the user that the address is correct.
else
Continue with the address returned by the API.
منطق دقیق به موقعیت شما بستگی دارد - برای جزئیات بیشتر به سفارشی‌سازی منطق اعتبارسنجی خود مراجعه کنید.
نمونه گردش‌های کاری
جدول زیر خلاصه‌ای از گردش‌های کاری نمونه‌ای است که می‌توانید برای دریافت پاسخ از مشتری بر اساس API پیاده‌سازی کنید.
| رفتار سیستم شما | ||
|---|---|---|
| آدرس را اصلاح کنید | پاسخ از
| |
| اضافه کردن زیرمحل‌ها | پاسخ از طرف
| |
| آدرس را تأیید کنید | پاسخ از طرف
| |
| آدرس را | پاسخ از طرف
| |
منطق اعتبارسنجی خود را سفارشی کنید
در حالی که می‌توانید از نتایج فیلد verdict.possibleNextAction برای تعیین نحوه‌ی عملکرد سیستم خود در پاسخ API استفاده کنید، می‌توانید ساخت منطق سفارشی، مانند مواردی که نیازهای خاص کسب‌وکار را برآورده می‌کنند، را نیز در نظر بگیرید.
هدف این بخش نشان دادن این است که چگونه می‌توانید منطق سفارشی خود را برای تفسیر پاسخ API توسعه دهید تا مشخص شود که آیا می‌خواهید به مشتری خود اطلاع دهید یا خیر و چگونه. این بخش سطوح ریسک و سیگنال‌های پاسخ API اضافی را که باید برای سفارشی‌سازی خود در نظر بگیرید، پوشش می‌دهد.
با این اوصاف، حتی اگر برای تصمیم‌گیری در مورد مراحل بعدی خود صرفاً به verdict.possibleNextAction تکیه کنید، سیگنال‌های اضافی شرح داده شده در زیر همچنان می‌توانند به شما در درک جزئیات مربوط به مشکلات احتمالی آدرس کمک کنند.
تحمل ریسک
هنگام طراحی نحوه پاسخگویی سیستم شما به سیگنال‌های دریافتی از API اعتبارسنجی آدرس، توصیه‌های زیر می‌تواند به شما در ساخت یک مدل پاسخگویی مؤثرتر کمک کند. با این حال، اینها فقط توصیه هستند، بنابراین در نظر داشته باشید که پیاده‌سازی شما باید متناسب با مدل کسب‌وکارتان باشد.
| راهنمایی | جزئیات | |
|---|---|---|
| سطح ریسک | هنگام ایجاد تعادل بین درخواست اصلاحات و پذیرش آدرس وارد شده، سطح تحمل شرایط خود را در نظر بگیرید. | API اعتبارسنجی آدرس، سیگنال‌های متنوعی را برمی‌گرداند که می‌توانید آنها را با سطح ریسک خود ترکیب کنید تا فرآیند اعتبارسنجی خود را بهینه کنید. برای مثال، اگر یک آدرس دارای شماره خیابان تأیید نشده باشد، همچنان می‌توانید آن را بپذیرید. از سوی دیگر، اگر عملیات تجاری شما نیاز به دقت آدرس بیشتری دارد، می‌توانید از کاربر خود بخواهید که این کار را انجام دهد. برای مثالی که می‌تواند در هر دو دسته قرار گیرد، به بخش شماره خیابان تأیید نشده غیر آمریکایی در بخش پذیرش آدرس - مثال‌ها مراجعه کنید. |
| آدرس‌ها را بپذیرید | این یک روش خوب است که به سیستم خود اجازه دهید در صورت عدم پاسخ مشتری به درخواست‌ها، ورودی اصلی را بپذیرد. | در این موارد، ممکن است مشتری آدرسی را وارد کرده باشد که در سیستم وجود ندارد، مثلاً برای ساختمان نوساز. |
مثالی از جریان پرداخت ریسک‌گریز
اگر می‌خواهید خطر تحویل‌های ناموفق را کاهش دهید، می‌توانید منطق خود را طوری تنظیم کنید که مشتریانتان بیشتر از آن مطلع شوند. برای مثال، به جای استفاده از منطق شرح داده شده در بخش هدف کلیدی ، می‌توانید از منطق زیر استفاده کنید.
if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
مثالی از جریان پرداخت با اصطکاک کم
اگر می‌خواهید اصطکاک در جریان پرداخت خود را کاهش دهید، می‌توانید منطق خود را سفارشی کنید تا مشتریان خود را کمتر به این مرحله ترغیب کنید. به عنوان مثال، به جای استفاده از منطق شرح داده شده در بخش هدف کلیدی ، می‌توانید از منطق زیر استفاده کنید.
if (verdict.possibleNextAction == FIX)
Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
سیگنال‌های FIX
وقتی نتایج به وضوح نشان می‌دهد که آدرس ممکن است قابل تحویل نباشد، آدرس را اصلاح کنید. سیستم شما می‌تواند از مشتری بخواهد اطلاعات لازم را ارائه دهد، پس از آن شما گردش کار خود را دوباره صادر می‌کنید تا یک آدرس قابل تحویل دریافت کنید.
فیلدهای زیر از پاسخ API اعتبارسنجی آدرس می‌توانند علاوه بر verdict.possibleNextAction برای تعیین اینکه آیا یک آدرس مشکلات عمده‌ای دارد یا خیر و اینکه این مشکلات چه هستند، استفاده شوند.
| جزئیات اعتبارسنجی | وقتی مقدار validation granularity enum برای یک آدرس OTHER باشد، احتمالاً آدرس نادرست است. |
|---|---|
| اجزای گمشده | وقتی address.missingComponentTypes خالی نباشد، احتمالاً آدرس فاقد اطلاعات کلید است. |
| اجزای مشکوک | وقتی enum سطح تأیید برای یک کامپوننت UNCONFIRMED_AND_SUSPICIOUS باشد، احتمالاً آن کامپوننت نادرست است. |
| اجزای حل نشده | یک unresolvedToken بخشی از ورودی است که به عنوان بخش معتبری از یک آدرس شناخته نمی‌شود. |
| تأییدیه USPS DPV | وقتی uspsData.dpvConfirmation مقدار N دارد یا خالی است، ممکن است مشکلی در آدرس وجود داشته باشد. این فیلد فقط برای آدرس‌های ایالات متحده در دسترس است. برای جزئیات بیشتر در مورد uspsData.dpvConfirmation ، به بخش مدیریت آدرس‌های ایالات متحده مراجعه کنید. |
سیگنال‌های CONFIRM_ADD_SUBPREMISES (فقط آدرس‌های ایالات متحده)
شما از مشتری خود می‌خواهید که آدرس را بررسی کند و زمانی که پاسخ API اعتبارسنجی آدرس نشان می‌دهد که ممکن است آدرس فاقد یک زیرمحل باشد، شماره واحد را اضافه کند. در این موارد، آدرس ساختمان احتمالاً معتبر است، اما شما می‌خواهید اطمینان بیشتری داشته باشید که آدرس حاصل، همان آدرس مورد نظر مشتری است.
فیلدهای زیر از پاسخ API اعتبارسنجی آدرس می‌توانند علاوه بر verdict.possibleNextAction برای تعیین اینکه آیا یک آدرس احتمالاً فاقد یک زیرمحل است یا خیر، استفاده شوند.
Missing subpremise component | وقتی فیلد address.missingComponentTypes حاوی مقداری از subpremise باشد، نشان می‌دهد که شماره واحد در آدرس وجود ندارد. |
|---|---|
| تأییدیه USPS DPV | وقتی uspsData.dpvConfirmation برابر با S باشد، به این معنی است که شماره اصلی آدرس با یک آدرس در پایگاه داده USPS مطابقت داده شده است. با این حال، انتظار می‌رفت که آدرس حاوی یک شماره ثانویه نیز باشد. این فیلد فقط برای آدرس‌های ایالات متحده در دسترس است. برای جزئیات بیشتر در مورد uspsData.dpvConfirmation ، به بخش «مدیریت آدرس‌های ایالات متحده» مراجعه کنید. |
مثال‌های آدرس محل‌های فرعی را اضافه کنید
سیگنال‌های تایید
شما زمانی یک آدرس را تأیید می‌کنید که حکم نشان دهد API اعتبارسنجی آدرس، اجزای آدرس را استنباط کرده یا تغییراتی در آنها ایجاد کرده تا یک آدرس معتبر تولید کند. در این موارد، شما یک آدرس قابل تحویل دارید، اما اطمینان بیشتری را ترجیح می‌دهید که آدرس حاصل، همان آدرس مورد نظر مشتری باشد.
فیلدهای زیر از پاسخ API اعتبارسنجی آدرس می‌توانند علاوه بر verdict.possibleNextAction برای تعیین اینکه آیا یک آدرس مشکلات جزئی دارد یا خیر و اینکه این مشکلات چه هستند، استفاده شوند.
| جزئیات اعتبارسنجی | وقتی validationGranularity برای یک آدرس ROUTE یا PREMISE_PROXIMITY باشد، ممکن است آدرس نادرست باشد. |
|---|---|
| داده‌های استنباطی | وقتی فیلد hasInferredComponents true باشد، می‌دانید که API اطلاعاتی را که از سایر اجزای آدرس جمع‌آوری کرده است، پر کرده است. |
| داده‌های جایگزین شده | وقتی فیلد hasReplacedComponents برابر با true باشد، API داده‌های وارد شده را با داده‌هایی که آدرس را معتبر می‌دانند، جایگزین می‌کند. |
| اصلاحات املایی | وقتی فیلد hasSpellCorrectedComponents true باشد، API املای برخی از اجزای دارای غلط املایی را اصلاح می‌کند. |
سیگنال‌های پذیرش
شما ممکن است زمانی یک آدرس را بپذیرید که پاسخ API مربوط به اعتبارسنجی آدرس، درجه بالایی از اطمینان را ارائه دهد که آدرس قابل تحویل است و می‌توان بدون تعامل بیشتر با مشتری در فرآیند بعدی از آن استفاده کرد.
فیلدهای زیر از پاسخ API اعتبارسنجی آدرس می‌توانند علاوه بر verdict.possibleNextAction برای تعیین اینکه آیا یک آدرس از کیفیت قابل قبولی برخوردار است یا خیر، استفاده شوند.
| جزئیات اعتبارسنجی | validationGranularity PREMISE اغلب قابل قبول است، اگرچه مقدار ROUTE ممکن است همچنان نشان دهنده آدرس قابل تحویل باشد. |
|---|---|
| بدون داده استنباطی | وقتی فیلد hasInferredComponents برابر با false باشد، می‌دانید که هیچ کامپوننتی در خروجی استنباط نشده است. |
| بدون داده جایگزین شده | وقتی فیلد hasReplacedComponents برابر با false باشد، می‌دانید که هیچ داده ورودی جایگزین نشده است. |
| بدون اصلاح طلسم | وقتی فیلد hasSpellCorrectedComponents برابر با false باشد، می‌دانید که هیچ اصلاح املایی انجام نشده است. |
| تأییدیه USPS DPV | وقتی uspsData.dpvConfirmation برابر با Y باشد، به این معنی است که آدرس با آدرسی در پایگاه داده USPS مطابقت داده شده است. این فیلد فقط برای آدرس‌های ایالات متحده در دسترس است. برای جزئیات بیشتر در مورد uspsData.dpvConfirmation ، به بخش «مدیریت آدرس‌های ایالات متحده» مراجعه کنید. |