از Address Validation API برای پردازش آدرس ها با حجم بالا استفاده کنید

هدف، واقعگرایانه

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

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

موارد استفاده کنید

حال بیایید موارد استفاده را که در آن اعتبارسنجی آدرس با حجم بالا مفید است، درک کنیم.

آزمایش کردن

شما اغلب می خواهید Address Validation API را با اجرای هزاران آدرس آزمایش کنید. ممکن است آدرس‌ها را در یک فایل مقدار جدا شده با کاما داشته باشید و بخواهید کیفیت آدرس‌ها را تأیید کنید.

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

هنگام ورود به Address Validation API، می‌خواهید پایگاه داده آدرس موجود خود را در مقابل پایگاه داده کاربر تأیید کنید.

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

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

  • ممکن است کارهایی را برای اعتبارسنجی آدرس ها برای جزئیات ثبت شده در طول روز برنامه ریزی کرده باشید، به عنوان مثال، از ثبت نام مشتری، جزئیات سفارش، برنامه های تحویل.
  • ممکن است داده‌هایی حاوی آدرس‌هایی از بخش‌های مختلف به عنوان مثال از فروش تا بازاریابی دریافت کنید. بخش جدیدی که آدرس ها را دریافت می کند اغلب می خواهد قبل از استفاده آنها را تأیید کند.
  • ممکن است آدرس ها را در طول نظرسنجی ها یا تبلیغات مختلف و بعداً در به روز رسانی در سیستم آنلاین جمع آوری کنید. شما می‌خواهید در حین وارد کردن آدرس‌ها در سیستم، صحت آدرس‌ها را تأیید کنید.

شیرجه عمیق فنی

برای اهداف این سند، ما فرض می کنیم که:

  • شما در حال فراخوانی Address Validation API با آدرس هایی از پایگاه داده مشتری (یعنی پایگاه داده با جزئیات مشتری) هستید.
  • شما می توانید پرچم های اعتبار را در برابر آدرس های فردی در پایگاه داده خود ذخیره کنید.
  • پرچم‌های اعتبار زمانی از Address Validation API بازیابی می‌شوند که یک مشتری جداگانه وارد سیستم شود.

ذخیره سازی برای استفاده در تولید

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

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

  • داده ها از شی AddressComponent
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

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

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

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

پاسخ را درک کنید

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

  • نشانگر addressComplete در شیء Verdict true است،
  • validationGranularity در شی Verdict PREMISE یا SUB_PREMISE است
  • هیچ یک از AddressComponent به عنوان علامت گذاری نشده است:
    • Inferred (توجه : inferred=true می تواند زمانی اتفاق بیفتد که addressComplete=true )
    • spellCorrected
    • replaced
    • unexpected ، و
  • confirmationLevel : سطح تایید در AddressComponent روی CONFIRMED یا UNCONFIRMED_BUT_PLAUSIBLE تنظیم شده است.

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

  • formattedAddress
  • postalAddress
  • addressComponent componentNames یا
  • UspsData standardizedAddress

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

بر اساس بحث بالا:

  • به دلایل تجاری اغلب لازم است بخشی از پاسخ از Address Validation API ذخیره شود.
  • با این حال، شرایط خدمات در پلتفرم نقشه‌های Google، داده‌هایی را که می‌توان در حافظه پنهان ذخیره کرد، محدود می‌کند.

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

مرحله 1:

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

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

alt_text

  • طبق شرایط سرویس، می‌توانید addressComplete, validationGranularity and validationFlags را هنگام اعتبارسنجی آدرس‌ها به صورت بدون هد ذخیره کنید.

  • می توانید addressComplete,validationGranularity and validationFlags, PlaceID در مقابل یک UserID خاص در پایگاه داده مشتری کش کنید.

بنابراین در طی این مرحله از پیاده سازی، فیلدهای ذکر شده در بالا را در مقابل UserID ذخیره می کنیم.

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

گام 2:

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

نمودار B : این نمودار نشان می‌دهد که چگونه یکپارچه‌سازی پایان به پایان جریان رضایت کاربر می‌تواند به شکل زیر باشد:

alt_text

  1. هنگامی که کاربر وارد سیستم می شود، ابتدا بررسی کنید که آیا پرچم های اعتبار سنجی را در سیستم خود ذخیره کرده اید، مانند:

    • addressComplete درست است
    • اعتبارسنجی Granularity PREMISE یا SUB_PREMISE نیست
    • validationFlags inferred,spellCorrected,replaced,unexpected .
      • اگر پرچم وجود نداشته باشد، اطمینان زیادی وجود دارد که آدرس کش موجود از کیفیت خوبی برخوردار است و می توان از آن استفاده کرد.

  2. اگر پرچم‌هایی وجود دارد، باید یک رابط کاربری برای تصحیح/به‌روزرسانی آدرس کاربر ارائه دهید.

  3. می‌توانید با آدرس به‌روزرسانی شده یا ذخیره‌شده، دوباره با Address Validation API تماس بگیرید و آدرس تصحیح‌شده را برای تأیید به کاربر ارائه دهید.

  4. اگر آدرس از کیفیت خوبی برخوردار باشد، Address Validation API یک formattedAddress را برمی‌گرداند.

  5. اگر اصلاحاتی انجام شده باشد، می‌توانید آن آدرس را به کاربر ارائه دهید، یا در صورت عدم وجود اصلاح، بی‌صدا بپذیرید.

  6. هنگامی که کاربر پذیرفت، می توانید formattedAddress را در پایگاه داده کش کنید.

پیاده سازی کد شبه مرحله 2:

If addressComplete is FALSE

OR

If validationGranularity is Not PREMISE OR SUB_PREMISE

OR

If validationFlags is inferred OR spellCorrected OR replaced OR unexpected
  {

    # This means there are issues with the existing cached address

    Call UI to present the address to user

}
Else{

    # This means existing address is good
  Proceed to checkout
}

نتیجه

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

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

مراحل بعدی

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

پیشنهاد مطالعه بیشتر:

مشارکت کنندگان

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

Henrik Valve | مهندس راه حل
توماس آنگلرت | مهندس راه حل
سرتاک گنگولی | مهندس راه حل