منطق اعتبارسنجی خود را بسازید

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

به طور کلی پاسخ API راه های زیر را تعیین می کند که سیستم شما باید یک آدرس را مدیریت کند:

  • Fix— آدرس کیفیت پایینی دارد. شما باید برای اطلاعات بیشتر درخواست کنید.
  • تأیید - آدرس با کیفیت بالا است، اما تغییراتی نسبت به آدرس ورودی دارد. ممکن است از شما درخواست تأیید کنید.
  • Accept را — آدرس با کیفیت است. می توانید آدرس ارائه شده را بپذیرید.

هدف کلیدی

این سند به شما کمک می کند تا سیستم خود را تغییر دهید تا پاسخ API را به بهترین شکل تجزیه و تحلیل کنید و اقدامات بعدی را با آدرس های ارائه شده تعیین کنید. شبه کد زیر یک جریان احتمالی را نشان می دهد.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

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

مروری بر گردش کار

جدول زیر دو عمل را برای سیستم شما خلاصه می کند:

  1. گردش کار برای استفاده بر اساس اصلاح، تأیید، پذیرش رفتار.
  2. اولین سیگنال هایی که باید از پاسخ بررسی شود . سیگنال هایی که در اینجا توضیح داده می شوند از ویژگی verdict می آیند و تنها سیگنال هایی نیستند که باید بررسی شوند، بلکه نشانگر اولیه کیفیت آدرس را ارائه می دهند. هر نوع رفتار مربوط به بخشی در این سند است که سیگنال‌های بیشتری را که ممکن است نیاز به بررسی داشته باشید را توصیف می‌کند.
رفتار سیستم شما
آدرس رو درست کن

پاسخ verdict حاکی از اطلاعات گمشده مهمی است که باید ارائه شود. آدرس بازگردانده شده توسط Address Validation API ممکن است کیفیت قابل تحویل نداشته باشد.

گردش کار

  1. در صورت لزوم اجزای آدرس را بررسی کنید.
  2. از مشتری بخواهید تا مشکلات را برطرف کند.
  3. درخواست تأیید اعتبار برای آدرس به روز شده.
  4. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
  5. با آدرس ادامه دهید

سیگنال های حکم

هر یک از موارد زیر اعمال می شود:

آدرس را تایید کنید

پاسخ از verdict نشانی یک آدرس قابل تحویل را نشان می دهد، اما تغییراتی را در ورودی اصلی ایجاد کرده است: استنباط داده هایی که یا املای تصحیح شده اند یا داده هایی که می توانند تأیید شوند.

گردش کار

  1. اصلاحات مورد نیاز:
    1. در صورت لزوم اجزای آدرس را بررسی کنید.
    2. درخواست تأیید اعتبار برای آدرس به روز شده.
    3. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
    4. با آدرس ادامه دهید
  2. بدون نیاز به اصلاح:
    1. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
    2. با آدرس ادامه دهید

سیگنال های حکم

همه موارد زیر اعمال می شود:

  • validationGranularity حاوی ROUTE یا بهتر است. مقادیر دانه بندی را ببینید.
  • addressComplete true است.
  • فیلد hasInferredComponents true است یا قسمت hasReplacedComponents true است.
Accept the address

پاسخ Address Validation API نشان دهنده یک آدرس با کیفیت عالی است.

گردش کار

با آدرس برگشتی ادامه دهید.

سیگنال های حکم

همه موارد زیر اعمال می شود:

  • validationGranularity شامل PREMISE یا بهتر است. مقادیر دانه بندی را ببینید.
  • addressComplete true است.
  • هیچ جزء استنباط شده یا جایگزینی وجود ندارد.

راهنمای اجرا

هنگام طراحی نحوه پاسخگویی سیستم شما به سیگنال‌های Address Validation API، توصیه‌های زیر می‌تواند به شما در ایجاد یک مدل پاسخ مؤثرتر کمک کند. با این حال، اینها فقط توصیه هایی هستند، بنابراین به خاطر داشته باشید که اجرای شما باید با مدل کسب و کار شما مطابقت داشته باشد.

راهنمایی جزئیات
سطح ریسک

هنگام ایجاد تعادل بین درخواست اصلاحات و پذیرش آدرس درج شده، سطح تحمل را برای موقعیت خود در نظر بگیرید.

Address Validation API سیگنال‌های مختلفی را برمی‌گرداند که می‌توانید با سطح ریسک خود برای بهینه‌سازی فرآیند اعتبارسنجی خود ترکیب کنید.

به عنوان مثال، اگر آدرسی دارای شماره خیابان تایید نشده باشد، همچنان می توانید آن را بپذیرید. از سوی دیگر، اگر عملیات تجاری شما به دقت آدرس بیشتری نیاز دارد، ممکن است از کاربر خود درخواست کنید. برای مثالی که می‌تواند در هر یک از دسته‌ها قرار گیرد، شماره خیابان تأیید نشده غیرآمریکایی را در آدرس پذیرش - نمونه‌ها ببینید.

آدرس ها را بپذیرید

اگر مشتری به درخواست‌ها پاسخ ندهد، این روش خوبی است که به سیستم خود اجازه دهید ورودی اصلی را بپذیرد.

در این موارد، مشتری ممکن است آدرسی را وارد کرده باشد که در سیستم نیست، مثلاً برای ساخت و ساز جدید.

بازخورد ارائه دهید

هنگامی که درخواست تأیید اعتبار آدرس را مجدداً صادر می کنید، می توانید درخواستی را به نقطه پایانی provideValidationFeedback نیز ارسال کنید.

این به Google اجازه می‌دهد بداند که در نهایت چگونه با پاسخ نهایی برخورد کرده‌اید. به آدرس های به روز شده رسیدگی کنید .

یک آدرس را درست کنید

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

سیگنال ها را برطرف کنید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید اصلاح شود یا خیر.

1. اعتبار سنجی و اجزای گمشده

این دو سیگنال بهترین نشانه از یک آدرس مشکل ساز را ارائه می دهند:

  • هر زمان که فیلد validationGranularity OTHER باشد، سیستم شما باید سیگنال های جزء آدرس را بررسی کند تا درباره محل وقوع خطا و نحوه رفع آن اطلاعات بیشتری کسب کند.
  • هر زمان که شی address پس از پردازش، یک قسمت missingComponentTypes را برمی گرداند، سیستم شما باید آن جزء را بررسی کند. اجزای از دست رفته نیز آدرس را ناقص و غیر قابل تحویل نشان می دهد.

2. سیگنال های دیگر

Address Validation API همچنین سیگنال های دیگری را برای کمک به تشخیص مشکلات خاص ارائه می دهد:

اجزای مشکوک وقتی شماره سطح تأیید برای یک مؤلفه UNCOMFIRMED_AND_SUSPICIOUS باشد، احتمالاً مؤلفه نادرست است.
جزء حل نشده UnresolvedToken بخشی از ورودی است که به عنوان بخشی معتبر از یک آدرس شناخته نمی شود.

3. سیگنال های آدرس ایالات متحده

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

dpvConfirmation یا N ، D ، یا خالی.

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

رفع نمونه آدرس

یک آدرس را تایید کنید

زمانی که حکم نشان می‌دهد که Address Validation API استنباط کرده یا تغییراتی در اجزای آدرس به منظور تولید یک آدرس معتبر ایجاد کرده است، یک آدرس را تأیید می‌کنید. در این موارد، شما یک آدرس قابل تحویل دارید، اما ترجیح می‌دهید اطمینان بیشتری داشته باشید که نشانی به‌دست‌آمده همان آدرسی است که مشتری در نظر گرفته است.

برای ارائه درخواست صحیح به مشتری، منطق شما مؤلفه‌های پرچم‌گذاری‌شده توسط سرویس را شناسایی می‌کند تا مشخص کند کدام عملکرد یا پرچم API روی مؤلفه اعمال می‌شود، مانند inferred ، replaced یا spellCorrected . AddressComponent را در مرجع ببینید.

سیگنال ها را تایید کنید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید تأیید شود.

1. اعتبار سنجی دانه بندی

validationGranularity ROUTE یا بهتر قابل قبول است، اما PREMISE یا SUBPREMISE سیگنال قوی تری از قابلیت تحویل ارائه می دهد.

2. سیگنال های دیگر

هنگام تصمیم گیری برای تأیید ورود آدرس با مشتری، حکم موارد زیر را نیز برای تعیین اینکه چه مؤلفه هایی باید بررسی شود ارائه می دهد:

داده های استنباط شده وقتی فیلد hasInferredComponents true باشد، می‌دانید که API اطلاعاتی را که از سایر اجزای آدرس جمع‌آوری کرده بود، پر کرده است.
داده ها جایگزین شد وقتی فیلد hasReplacedComponents true باشد، API داده‌های وارد شده را با داده‌هایی که به نظر می‌رسد آدرس را معتبر می‌سازد جایگزین می‌کند.

3. سیگنال های آدرس ایالات متحده

برخی از فیلدهای قابل اعمال فقط برای آدرس های ایالات متحده نشان می دهد که منطق شما باید جزئیات را با مشتری تأیید کند. هر یک از موارد زیر اعمال می شود:

dpvConfirmation S

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

پاسخ آدرس حاوی قسمت missingComponentType با مقدار subpremise است.

نمونه های آدرس را تأیید کنید

یک آدرس بپذیرید

زمانی آدرسی را می‌پذیرید که حکم، اطمینان بالایی از قابل‌تحویل بودن آدرس ارائه می‌کند و می‌تواند بدون تعامل بیشتر با مشتری در فرآیند پایین‌دستی مورد استفاده قرار گیرد.

سیگنال ها را بپذیرید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید تأیید شود.

1. اعتبار سنجی دانه بندی

validationGranularity PREMISE یا بهتر قابل قبول است، اما در برخی موارد، ROUTE همچنان یک آدرس قابل تحویل را نشان می دهد.

2. سیگنال های دیگر

یک حکم برای یک آدرس با کیفیت بالا باید موارد زیر را نیز ارائه دهد:

  • داده ای جایگزین نشده است . در این مورد، hasReplacedComponents: FALSE .
  • هیچ جزء استنباط شده ای وجود ندارد . در این مورد، hasInferredComponents: FALSE .

3. سیگنال های آدرس ایالات متحده

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

dpvConfirmation Y

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

نمونه های آدرس را بپذیرید

،

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

به طور کلی پاسخ API راه های زیر را تعیین می کند که سیستم شما باید یک آدرس را مدیریت کند:

  • Fix— آدرس کیفیت پایینی دارد. شما باید برای اطلاعات بیشتر درخواست کنید.
  • تأیید - آدرس با کیفیت بالا است، اما تغییراتی نسبت به آدرس ورودی دارد. ممکن است از شما درخواست تأیید کنید.
  • Accept را — آدرس با کیفیت است. می توانید آدرس ارائه شده را بپذیرید.

هدف کلیدی

این سند به شما کمک می کند تا سیستم خود را تغییر دهید تا پاسخ API را به بهترین شکل تجزیه و تحلیل کنید و اقدامات بعدی را با آدرس های ارائه شده تعیین کنید. شبه کد زیر یک جریان احتمالی را نشان می دهد.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

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

مروری بر گردش کار

جدول زیر دو عمل را برای سیستم شما خلاصه می کند:

  1. گردش کار برای استفاده بر اساس اصلاح، تأیید، پذیرش رفتار.
  2. اولین سیگنال هایی که باید از پاسخ بررسی شود . سیگنال هایی که در اینجا توضیح داده می شوند از ویژگی verdict می آیند و تنها سیگنال هایی نیستند که باید بررسی شوند، بلکه نشانگر اولیه کیفیت آدرس را ارائه می دهند. هر نوع رفتار مربوط به بخشی در این سند است که سیگنال‌های بیشتری را که ممکن است نیاز به بررسی داشته باشید را توصیف می‌کند.
رفتار سیستم شما
آدرس رو درست کن

پاسخ verdict حاکی از اطلاعات گمشده مهمی است که باید ارائه شود. آدرس بازگردانده شده توسط Address Validation API ممکن است کیفیت قابل تحویل نداشته باشد.

گردش کار

  1. در صورت لزوم اجزای آدرس را بررسی کنید.
  2. از مشتری بخواهید تا مشکلات را برطرف کند.
  3. درخواست تأیید اعتبار برای آدرس به روز شده.
  4. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
  5. با آدرس ادامه دهید

سیگنال های حکم

هر یک از موارد زیر اعمال می شود:

آدرس را تایید کنید

پاسخ از verdict نشانی یک آدرس قابل تحویل را نشان می دهد، اما تغییراتی را در ورودی اصلی ایجاد کرده است: استنباط داده هایی که یا املای تصحیح شده اند یا داده هایی که می توانند تأیید شوند.

گردش کار

  1. اصلاحات مورد نیاز:
    1. در صورت لزوم اجزای آدرس را بررسی کنید.
    2. درخواست تأیید اعتبار برای آدرس به روز شده.
    3. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
    4. با آدرس ادامه دهید
  2. بدون نیاز به اصلاح:
    1. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
    2. با آدرس ادامه دهید

سیگنال های حکم

همه موارد زیر اعمال می شود:

  • validationGranularity حاوی ROUTE یا بهتر است. مقادیر دانه بندی را ببینید.
  • addressComplete true است.
  • فیلد hasInferredComponents true است یا قسمت hasReplacedComponents true است.
Accept the address

پاسخ Address Validation API نشان دهنده یک آدرس با کیفیت عالی است.

گردش کار

با آدرس برگشتی ادامه دهید.

سیگنال های حکم

همه موارد زیر اعمال می شود:

  • validationGranularity شامل PREMISE یا بهتر است. مقادیر دانه بندی را ببینید.
  • addressComplete true است.
  • هیچ جزء استنباط شده یا جایگزینی وجود ندارد.

راهنمای اجرا

هنگام طراحی نحوه پاسخگویی سیستم شما به سیگنال‌های Address Validation API، توصیه‌های زیر می‌تواند به شما در ایجاد یک مدل پاسخ مؤثرتر کمک کند. با این حال، اینها فقط توصیه هایی هستند، بنابراین به خاطر داشته باشید که اجرای شما باید با مدل کسب و کار شما مطابقت داشته باشد.

راهنمایی جزئیات
سطح ریسک

هنگام ایجاد تعادل بین درخواست اصلاحات و پذیرش آدرس درج شده، سطح تحمل را برای موقعیت خود در نظر بگیرید.

Address Validation API سیگنال‌های مختلفی را برمی‌گرداند که می‌توانید با سطح ریسک خود برای بهینه‌سازی فرآیند اعتبارسنجی خود ترکیب کنید.

به عنوان مثال، اگر آدرسی دارای شماره خیابان تایید نشده باشد، همچنان می توانید آن را بپذیرید. از سوی دیگر، اگر عملیات تجاری شما به دقت آدرس بیشتری نیاز دارد، ممکن است از کاربر خود درخواست کنید. برای مثالی که می‌تواند در هر یک از دسته‌ها قرار گیرد، شماره خیابان تأیید نشده غیرآمریکایی را در آدرس پذیرش - نمونه‌ها ببینید.

آدرس ها را بپذیرید

اگر مشتری به درخواست‌ها پاسخ ندهد، این روش خوبی است که به سیستم خود اجازه دهید ورودی اصلی را بپذیرد.

در این موارد، مشتری ممکن است آدرسی را وارد کرده باشد که در سیستم نیست، مثلاً برای ساخت و ساز جدید.

بازخورد ارائه دهید

هنگامی که درخواست تأیید اعتبار آدرس را مجدداً صادر می کنید، می توانید درخواستی را به نقطه پایانی provideValidationFeedback نیز ارسال کنید.

این به Google اجازه می‌دهد بداند که در نهایت چگونه با پاسخ نهایی برخورد کرده‌اید. به آدرس های به روز شده رسیدگی کنید .

یک آدرس را درست کنید

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

سیگنال ها را برطرف کنید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید اصلاح شود یا خیر.

1. اعتبار سنجی و اجزای گمشده

این دو سیگنال بهترین نشانه از یک آدرس مشکل ساز را ارائه می دهند:

  • هر زمان که فیلد validationGranularity OTHER باشد، سیستم شما باید سیگنال های جزء آدرس را بررسی کند تا درباره محل وقوع خطا و نحوه رفع آن اطلاعات بیشتری کسب کند.
  • هر زمان که شی address پس از پردازش، یک قسمت missingComponentTypes را برمی گرداند، سیستم شما باید آن جزء را بررسی کند. اجزای از دست رفته نیز آدرس را ناقص و غیر قابل تحویل نشان می دهد.

2. سیگنال های دیگر

Address Validation API همچنین سیگنال های دیگری را برای کمک به تشخیص مشکلات خاص ارائه می دهد:

اجزای مشکوک وقتی شماره سطح تأیید برای یک مؤلفه UNCOMFIRMED_AND_SUSPICIOUS باشد، احتمالاً مؤلفه نادرست است.
جزء حل نشده UnresolvedToken بخشی از ورودی است که به عنوان بخشی معتبر از یک آدرس شناخته نمی شود.

3. سیگنال های آدرس ایالات متحده

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

dpvConfirmation یا N ، D ، یا خالی.

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

رفع نمونه آدرس

یک آدرس را تایید کنید

زمانی که حکم نشان می‌دهد که Address Validation API استنباط کرده یا تغییراتی در اجزای آدرس به منظور تولید یک آدرس معتبر ایجاد کرده است، یک آدرس را تأیید می‌کنید. در این موارد، شما یک آدرس قابل تحویل دارید، اما ترجیح می‌دهید اطمینان بیشتری داشته باشید که نشانی به‌دست‌آمده همان آدرسی است که مشتری در نظر گرفته است.

برای ارائه درخواست صحیح به مشتری، منطق شما مؤلفه‌های پرچم‌گذاری‌شده توسط سرویس را شناسایی می‌کند تا مشخص کند کدام عملکرد یا پرچم API روی مؤلفه اعمال می‌شود، مانند inferred ، replaced یا spellCorrected . AddressComponent را در مرجع ببینید.

سیگنال ها را تایید کنید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید تأیید شود.

1. اعتبار سنجی دانه بندی

validationGranularity ROUTE یا بهتر قابل قبول است، اما PREMISE یا SUBPREMISE سیگنال قوی تری از قابلیت تحویل ارائه می دهد.

2. سیگنال های دیگر

هنگام تصمیم گیری برای تأیید ورود آدرس با مشتری، حکم موارد زیر را نیز برای تعیین اینکه چه مؤلفه هایی باید بررسی شود ارائه می دهد:

داده های استنباط شده وقتی فیلد hasInferredComponents true باشد، می‌دانید که API اطلاعاتی را که از سایر اجزای آدرس جمع‌آوری کرده بود، پر کرده است.
داده ها جایگزین شد وقتی فیلد hasReplacedComponents true باشد، API داده‌های وارد شده را با داده‌هایی که به نظر می‌رسد آدرس را معتبر می‌سازد جایگزین می‌کند.

3. سیگنال های آدرس ایالات متحده

برخی از فیلدهای قابل اعمال فقط برای آدرس های ایالات متحده نشان می دهد که منطق شما باید جزئیات را با مشتری تأیید کند. هر یک از موارد زیر اعمال می شود:

dpvConfirmation S

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

پاسخ آدرس حاوی قسمت missingComponentType با مقدار subpremise است.

نمونه های آدرس را تأیید کنید

یک آدرس بپذیرید

زمانی آدرسی را می‌پذیرید که حکم، اطمینان بالایی از قابل‌تحویل بودن آدرس ارائه می‌کند و می‌تواند بدون تعامل بیشتر با مشتری در فرآیند پایین‌دستی مورد استفاده قرار گیرد.

سیگنال ها را بپذیرید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید تأیید شود.

1. اعتبار سنجی دانه بندی

validationGranularity PREMISE یا بهتر قابل قبول است، اما در برخی موارد، ROUTE همچنان یک آدرس قابل تحویل را نشان می دهد.

2. سیگنال های دیگر

یک حکم برای یک آدرس با کیفیت بالا باید موارد زیر را نیز ارائه دهد:

  • داده ای جایگزین نشده است . در این مورد، hasReplacedComponents: FALSE .
  • هیچ جزء استنباط شده ای وجود ندارد . در این مورد، hasInferredComponents: FALSE .

3. سیگنال های آدرس ایالات متحده

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

dpvConfirmation Y

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

نمونه های آدرس را بپذیرید

،

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

به طور کلی پاسخ API راه های زیر را تعیین می کند که سیستم شما باید یک آدرس را مدیریت کند:

  • Fix— آدرس کیفیت پایینی دارد. شما باید برای اطلاعات بیشتر درخواست کنید.
  • تأیید - آدرس با کیفیت بالا است، اما تغییراتی نسبت به آدرس ورودی دارد. ممکن است از شما درخواست تأیید کنید.
  • Accept را — آدرس با کیفیت است. می توانید آدرس ارائه شده را بپذیرید.

هدف کلیدی

این سند به شما کمک می کند تا سیستم خود را تغییر دهید تا پاسخ API را به بهترین شکل تجزیه و تحلیل کنید و اقدامات بعدی را با آدرس های ارائه شده تعیین کنید. شبه کد زیر یک جریان احتمالی را نشان می دهد.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

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

مروری بر گردش کار

جدول زیر دو عمل را برای سیستم شما خلاصه می کند:

  1. گردش کار برای استفاده بر اساس اصلاح، تأیید، پذیرش رفتار.
  2. اولین سیگنال هایی که باید از پاسخ بررسی شود . سیگنال هایی که در اینجا توضیح داده می شوند از ویژگی verdict می آیند و تنها سیگنال هایی نیستند که باید بررسی شوند، بلکه نشانگر اولیه کیفیت آدرس را ارائه می دهند. هر نوع رفتار مربوط به بخشی در این سند است که سیگنال‌های بیشتری را که ممکن است نیاز به بررسی داشته باشید را توصیف می‌کند.
رفتار سیستم شما
آدرس رو درست کن

پاسخ verdict حاکی از اطلاعات گمشده مهمی است که باید ارائه شود. آدرس بازگردانده شده توسط Address Validation API ممکن است کیفیت قابل تحویل نداشته باشد.

گردش کار

  1. در صورت لزوم اجزای آدرس را بررسی کنید.
  2. از مشتری بخواهید تا مشکلات را برطرف کند.
  3. درخواست تأیید اعتبار برای آدرس به روز شده.
  4. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
  5. با آدرس ادامه دهید

سیگنال های حکم

هر یک از موارد زیر اعمال می شود:

آدرس را تایید کنید

پاسخ از verdict نشانی یک آدرس قابل تحویل را نشان می دهد، اما تغییراتی را در ورودی اصلی ایجاد کرده است: استنباط داده هایی که یا املای تصحیح شده اند یا داده هایی که می توانند تأیید شوند.

گردش کار

  1. اصلاحات مورد نیاز:
    1. در صورت لزوم اجزای آدرس را بررسی کنید.
    2. درخواست تأیید اعتبار برای آدرس به روز شده.
    3. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
    4. با آدرس ادامه دهید
  2. بدون نیاز به اصلاح:
    1. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید .
    2. با آدرس ادامه دهید

سیگنال های حکم

همه موارد زیر اعمال می شود:

  • validationGranularity حاوی ROUTE یا بهتر است. مقادیر دانه بندی را ببینید.
  • addressComplete true است.
  • فیلد hasInferredComponents true است یا قسمت hasReplacedComponents true است.
Accept the address

پاسخ Address Validation API نشان دهنده یک آدرس با کیفیت عالی است.

گردش کار

با آدرس برگشتی ادامه دهید.

سیگنال های حکم

همه موارد زیر اعمال می شود:

  • validationGranularity شامل PREMISE یا بهتر است. مقادیر دانه بندی را ببینید.
  • addressComplete true است.
  • هیچ جزء استنباط شده یا جایگزینی وجود ندارد.

راهنمای اجرا

هنگام طراحی نحوه پاسخگویی سیستم شما به سیگنال‌های Address Validation API، توصیه‌های زیر می‌تواند به شما در ایجاد یک مدل پاسخ مؤثرتر کمک کند. با این حال، اینها فقط توصیه هایی هستند، بنابراین به خاطر داشته باشید که اجرای شما باید با مدل کسب و کار شما مطابقت داشته باشد.

راهنمایی جزئیات
سطح ریسک

هنگام ایجاد تعادل بین درخواست اصلاحات و پذیرش آدرس درج شده، سطح تحمل را برای موقعیت خود در نظر بگیرید.

Address Validation API سیگنال‌های مختلفی را برمی‌گرداند که می‌توانید با سطح ریسک خود برای بهینه‌سازی فرآیند اعتبارسنجی خود ترکیب کنید.

به عنوان مثال، اگر آدرسی دارای شماره خیابان تایید نشده باشد، همچنان می توانید آن را بپذیرید. از سوی دیگر، اگر عملیات تجاری شما به دقت آدرس بیشتری نیاز دارد، ممکن است از کاربر خود درخواست کنید. برای مثالی که می‌تواند در هر یک از دسته‌ها قرار گیرد، شماره خیابان تأیید نشده غیرآمریکایی را در آدرس پذیرش - نمونه‌ها ببینید.

آدرس ها را بپذیرید

اگر مشتری به درخواست‌ها پاسخ ندهد، این روش خوبی است که به سیستم خود اجازه دهید ورودی اصلی را بپذیرد.

در این موارد، مشتری ممکن است آدرسی را وارد کرده باشد که در سیستم نیست، مثلاً برای ساخت و ساز جدید.

بازخورد ارائه دهید

هنگامی که درخواست تأیید اعتبار آدرس را مجدداً صادر می کنید، می توانید درخواستی را به نقطه پایانی provideValidationFeedback نیز ارسال کنید.

این به Google اجازه می‌دهد بداند که در نهایت چگونه با پاسخ نهایی برخورد کرده‌اید. به آدرس های به روز شده رسیدگی کنید .

یک آدرس را درست کنید

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

سیگنال ها را برطرف کنید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید اصلاح شود یا خیر.

1. اعتبار سنجی و اجزای گمشده

این دو سیگنال بهترین نشانه از یک آدرس مشکل ساز را ارائه می دهند:

  • هر زمان که فیلد validationGranularity OTHER باشد، سیستم شما باید سیگنال های جزء آدرس را بررسی کند تا درباره محل وقوع خطا و نحوه رفع آن اطلاعات بیشتری کسب کند.
  • هر زمان که شی address پس از پردازش، یک قسمت missingComponentTypes را برمی گرداند، سیستم شما باید آن جزء را بررسی کند. اجزای از دست رفته نیز آدرس را ناقص و غیر قابل تحویل نشان می دهد.

2. سیگنال های دیگر

Address Validation API همچنین سیگنال های دیگری را برای کمک به تشخیص مشکلات خاص ارائه می دهد:

اجزای مشکوک وقتی شماره سطح تأیید برای یک مؤلفه UNCOMFIRMED_AND_SUSPICIOUS باشد، احتمالاً مؤلفه نادرست است.
جزء حل نشده UnresolvedToken بخشی از ورودی است که به عنوان بخشی معتبر از یک آدرس شناخته نمی شود.

3. سیگنال های آدرس ایالات متحده

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

dpvConfirmation یا N ، D ، یا خالی.

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

رفع نمونه آدرس

یک آدرس را تایید کنید

زمانی که حکم نشان می‌دهد که Address Validation API استنباط کرده یا تغییراتی در اجزای آدرس به منظور تولید یک آدرس معتبر ایجاد کرده است، یک آدرس را تأیید می‌کنید. در این موارد، شما یک آدرس قابل تحویل دارید، اما ترجیح می‌دهید اطمینان بیشتری داشته باشید که نشانی به‌دست‌آمده همان آدرسی است که مشتری در نظر گرفته است.

برای ارائه درخواست صحیح به مشتری، منطق شما مؤلفه‌های پرچم‌گذاری‌شده توسط سرویس را شناسایی می‌کند تا مشخص کند کدام عملکرد یا پرچم API روی مؤلفه اعمال می‌شود، مانند inferred ، replaced یا spellCorrected . AddressComponent را در مرجع ببینید.

سیگنال ها را تایید کنید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید تأیید شود.

1. اعتبار سنجی دانه بندی

validationGranularity ROUTE یا بهتر قابل قبول است، اما PREMISE یا SUBPREMISE سیگنال قوی تری از قابلیت تحویل ارائه می دهد.

2. سیگنال های دیگر

هنگام تصمیم گیری برای تأیید ورود آدرس با مشتری، حکم موارد زیر را نیز برای تعیین اینکه چه مؤلفه هایی باید بررسی شود ارائه می دهد:

داده های استنباط شده وقتی فیلد hasInferredComponents true باشد، می‌دانید که API اطلاعاتی را که از سایر اجزای آدرس جمع‌آوری کرده بود، پر کرده است.
داده ها جایگزین شد وقتی فیلد hasReplacedComponents true باشد، API داده‌های وارد شده را با داده‌هایی که به نظر می‌رسد آدرس را معتبر می‌سازد جایگزین می‌کند.

3. سیگنال های آدرس ایالات متحده

برخی از فیلدهای قابل اعمال فقط برای آدرس های ایالات متحده نشان می دهد که منطق شما باید جزئیات را با مشتری تأیید کند. هر یک از موارد زیر اعمال می شود:

dpvConfirmation S

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

پاسخ آدرس حاوی قسمت missingComponentType با مقدار subpremise است.

نمونه های آدرس را تأیید کنید

یک آدرس بپذیرید

زمانی آدرسی را می‌پذیرید که حکم، اطمینان بالایی از قابل‌تحویل بودن آدرس ارائه می‌کند و می‌تواند بدون تعامل بیشتر با مشتری در فرآیند پایین‌دستی مورد استفاده قرار گیرد.

سیگنال ها را بپذیرید

Address Validation API تعدادی سیگنال ارائه می دهد تا به شما اطلاع دهد که آیا یک آدرس باید تأیید شود.

1. اعتبار سنجی دانه بندی

validationGranularity PREMISE یا بهتر قابل قبول است، اما در برخی موارد، ROUTE همچنان یک آدرس قابل تحویل را نشان می دهد.

2. سیگنال های دیگر

یک حکم برای یک آدرس با کیفیت بالا باید موارد زیر را نیز ارائه دهد:

  • داده ای جایگزین نشده است . در این مورد، hasReplacedComponents: FALSE .
  • هیچ جزء استنباط شده ای وجود ندارد . در این مورد، hasInferredComponents: FALSE .

3. سیگنال های آدرس ایالات متحده

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

dpvConfirmation Y

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

نمونه های آدرس را بپذیرید

،

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

به طور کلی پاسخ API راه های زیر را تعیین می کند که سیستم شما باید یک آدرس را مدیریت کند:

  • Fix— آدرس کیفیت پایینی دارد. شما باید برای اطلاعات بیشتر درخواست کنید.
  • تأیید - آدرس با کیفیت بالا است، اما تغییراتی نسبت به آدرس ورودی دارد. ممکن است از شما درخواست تأیید کنید.
  • Accept را — آدرس با کیفیت است. می توانید آدرس ارائه شده را بپذیرید.

هدف کلیدی

این سند به شما کمک می کند تا سیستم خود را تغییر دهید تا پاسخ API را به بهترین شکل تجزیه و تحلیل کنید و اقدامات بعدی را با آدرس های ارائه شده تعیین کنید. شبه کد زیر یک جریان احتمالی را نشان می دهد.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

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

مروری بر گردش کار

جدول زیر دو عمل را برای سیستم شما خلاصه می کند:

  1. گردش کار برای استفاده بر اساس اصلاح، تأیید، پذیرش رفتار.
  2. اولین سیگنال هایی که باید از پاسخ بررسی شود . سیگنال هایی که در اینجا توضیح داده می شوند از ویژگی verdict می آیند و تنها سیگنال هایی نیستند که باید بررسی شوند، بلکه نشانگر اولیه کیفیت آدرس را ارائه می دهند. هر نوع رفتار مربوط به بخشی در این سند است که سیگنال‌های بیشتری را که ممکن است نیاز به بررسی داشته باشید را توصیف می‌کند.
رفتار سیستم شما
آدرس رو درست کن

پاسخ verdict حاکی از اطلاعات گمشده مهمی است که باید ارائه شود. آدرس بازگردانده شده توسط Address Validation API ممکن است کیفیت قابل تحویل نداشته باشد.

گردش کار

  1. در صورت لزوم اجزای آدرس را بررسی کنید.
  2. از مشتری بخواهید تا مشکلات را برطرف کند.
  3. درخواست تأیید اعتبار برای آدرس به روز شده.
  4. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. آدرس های به روز شده را مشاهده کنید.
  5. با آدرس ادامه دهید.

سیگنال های حکم

هر یک از موارد زیر اعمال می شود:

آدرس را ویرایش کنید

پاسخ از این verdict نشانگر یک آدرس قابل تحویل است ، اما تغییراتی در ورودی اصلی ایجاد کرده است: داده های استنباط که یا طلسم اصلاح شده است ، یا داده هایی که قابل تأیید هستند.

گردش کار

  1. اصلاحات مورد نیاز:
    1. در صورت لزوم در مورد مؤلفه های آدرس تحقیق کنید.
    2. اعتبار سنجی را برای آدرس به روز شده درخواست کنید.
    3. (اختیاری) درخواست را به نقطه پایانی بازخورد برای API ارسال کنید. آدرس های به روز شده را مشاهده کنید.
    4. با آدرس ادامه دهید.
  2. هیچ تصحیحی لازم نیست:
    1. (اختیاری) درخواست را به نقطه پایانی بازخورد برای API ارسال کنید. آدرس های به روز شده را مشاهده کنید.
    2. با آدرس ادامه دهید.

سیگنال های حکم

همه موارد زیر اعمال می شود:

  • validationGranularity شامل ROUTE یا بهتر است. مقادیر دانه بندی را ببینید.
  • addressComplete true است.
  • زمینه hasInferredComponents true است یا قسمت hasReplacedComponents true است.
بررسی آدرس را

پاسخ API اعتبارسنجی آدرس یک آدرس با کیفیت عالی را نشان می دهد.

گردش کار

با آدرس برگشتی ادامه دهید.

سیگنال های حکم

همه موارد زیر اعمال می شود:

  • validationGranularity شامل PREMISE یا بهتر است. مقادیر دانه بندی را ببینید.
  • addressComplete true است.
  • بدون اجزای استنباط یا جایگزین.

راهنمای اجرا

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

راهنمایی جزئیات
سطح ریسک

هنگام تعادل بین درخواست اصلاح و پذیرش آدرس به عنوان وارد شده ، میزان تحمل وضعیت خود را در نظر بگیرید.

API اعتبارسنجی آدرس انواع سیگنالهایی را که می توانید با سطح ریسک خود در نظر بگیرید ، برای بهینه سازی فرایند اعتبار سنجی خود باز می گرداند.

به عنوان مثال ، اگر یک آدرس دارای شماره خیابان تأیید نشده باشد ، هنوز هم می توانید آن را بپذیرید. از طرف دیگر ، اگر عملیات تجاری شما به دقت آدرس بیشتری نیاز داشته باشد ، ممکن است کاربر خود را فوری کنید. برای نمونه ای که می تواند در هر گروه قرار بگیرد ، به شماره خیابان غیر تأیید نشده در آدرس پذیرش مراجعه کنید - مثالها .

آدرس ها را بپذیرید

این یک عمل خوب است که در صورت عدم پاسخ مشتری به درخواست ، به سیستم خود اجازه می دهد تا ورودی اصلی را بپذیرد.

در این موارد ، مشتری ممکن است آدرس نه در سیستم ، مانند ساخت و سازهای جدید وارد کرده باشد.

بازخورد ارائه دهید

هنگامی که مجدداً درخواست اعتبارسنجی آدرس را صادر می کنید ، می توانید یک درخواست را به نقطه پایانی provideValidationFeedback ارائه دهید.

این به Google اجازه می دهد تا بداند که چگونه شما در نهایت پاسخ نهایی را اداره کردید. آدرس های به روز شده را مشاهده کنید.

آدرس را برطرف کنید

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

سیگنال ها را برطرف کنید

API اعتبارسنجی آدرس تعدادی سیگنال را ارائه می دهد تا به شما اطلاع دهد که آیا آدرس باید برطرف شود.

1. اعتبار سنجی و مؤلفه های گمشده

این دو سیگنال بهترین نشانگر یک آدرس مشکل ساز را ارائه می دهند:

  • هر زمان که زمینه validationGranularity OTHER باشد ، سیستم شما باید سیگنال های مؤلفه آدرس را بررسی کند تا اطلاعات بیشتری در مورد اینکه در آن خطا رخ داده است و نحوه رفع آن بیشتر بدانید.
  • هر زمان که شیء address پس از پردازش یک قسمت missingComponentTypes را برمی گرداند ، سیستم شما باید آن مؤلفه را بررسی کند. مؤلفه های گمشده همچنین آدرس را ناقص و غیر قابل تفریحی می کنند.

2 سیگنال های دیگر

API اعتبارسنجی آدرس همچنین سیگنال های دیگری را برای کمک به تشخیص مسائل خاص ارائه می دهد:

اجزای مشکوک هنگامی که Enum سطح تأیید برای یک مؤلفه UNCOMFIRMED_AND_SUSPICIOUS ، این احتمال وجود دارد که این مؤلفه نادرست باشد.
مؤلفه حل نشده یک حل نشده بخشی از ورودی است که به عنوان بخشی معتبر از یک آدرس شناخته نمی شود.

3. ما سیگنال ها را خطاب می کنیم

برخی از زمینه های قابل استفاده فقط در آدرس های ایالات متحده ، سیگنال مفیدی را ارائه می دهند که آدرس قابل تحویل نیست و باید برطرف شود. برای آدرس که نیاز به رفع دارد ، باید موارد زیر را مشاهده کنید:

dpvConfirmation یا N ، D یا خالی.

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده مراجعه کنید.

نمونه های آدرس را برطرف کنید

آدرس را تأیید کنید

شما یک آدرس را تأیید می کنید که حکم نشان می دهد که API اعتبارسنجی آدرس یا استنباط شده است یا برای ایجاد یک آدرس معتبر ، تغییراتی را برای آدرس دهی ایجاد کرده است. در این موارد ، شما یک آدرس قابل تحویل دارید ، اما اعتماد به نفس بیشتری را ترجیح می دهید که آدرس حاصل از آن باشد که توسط مشتری در نظر گرفته شده است.

برای ارائه سریع صحیح مشتری ، منطق شما مؤلفه هایی را که توسط این سرویس پرچم گذاری شده است شناسایی می کند تا مشخص شود که کدام عمل یا پرچم API را برای مؤلفه اعمال می کند ، مانند inferred ، replaced یا spellCorrected . آدرس آدرس را در مرجع مشاهده کنید.

سیگنال ها را تأیید کنید

API اعتبارسنجی آدرس تعدادی سیگنال را ارائه می دهد تا به شما اطلاع دهد که آیا آدرس باید تأیید شود.

1. دانه اعتبار سنجی

validationGranularity ROUTE یا بهتر قابل قبول است ، اما یا فرضیه یا زیرمجموعه سیگنال قوی تری از قابلیت تحویل را فراهم می کند.

2 سیگنال های دیگر

هنگام تصمیم گیری برای تأیید ورود آدرس با مشتری ، این حکم همچنین موارد زیر را برای تعیین اینکه چه مؤلفه هایی برای بررسی وجود دارد ، ارائه می دهد:

داده های استنباط شده هنگامی که قسمت hasInferredComponents true است ، می دانید که API اطلاعاتی را که از سایر مؤلفه های آدرس جمع آوری کرده است ، پر کرده است.
داده های جایگزین هنگامی که قسمت hasReplacedComponents true است ، API جایگزین داده های وارد شده با داده هایی که به نظر می رسد آدرس معتبر است.

3. ما سیگنال ها را خطاب می کنیم

برخی از زمینه های قابل استفاده فقط در مورد آدرس های ما نشان می دهد که منطق شما باید جزئیات را با مشتری تأیید کند. هر یک از موارد زیر اعمال می شود:

dpvConfirmation S

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده مراجعه کنید.

پاسخ آدرس حاوی قسمت missingComponentType با مقدار subpremise است.

نمونه های آدرس را تأیید کنید

آدرس را بپذیرید

شما یک آدرس را می پذیرید که حکم اعتماد به نفس بالایی را ارائه دهد که آدرس قابل تحویل است و می تواند بدون تعامل بیشتر مشتری در فرآیند پایین دست استفاده شود.

سیگنال ها را بپذیرید

API اعتبارسنجی آدرس تعدادی سیگنال را ارائه می دهد تا به شما اطلاع دهد که آیا آدرس باید تأیید شود.

1. دانه اعتبار سنجی

validationGranularity PREMISE یا بهتر قابل قبول است ، اما در برخی موارد ، ROUTE هنوز نشانگر آدرس قابل تحویل است.

2 سیگنال های دیگر

حکم برای آدرس با کیفیت بالا نیز باید موارد زیر را ارائه دهد:

  • بدون داده های جایگزین در این حالت ، hasReplacedComponents: FALSE .
  • بدون مؤلفه های استنباط شده . در این حالت ، hasInferredComponents: FALSE .

3. ما سیگنال ها را خطاب می کنیم

برخی از زمینه های قابل استفاده فقط در آدرس های ایالات متحده ، آدرس با کیفیت بالایی را نشان می دهد که می تواند به آن تحویل داده شود. برای یک آدرس قابل قبول ایالات متحده ، باید موارد زیر را مشاهده کنید:

dpvConfirmation Y

برای جزئیات بیشتر در مورد dpvConfirmation ، به آدرس های ایالات متحده مراجعه کنید.

نمونه های آدرس را بپذیرید

قبلی
یک پاسخ اساسی را درک کنید