از 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 آدرس تصحیح شده را برمی گرداند که می توانید با استفاده از اعلان رابط کاربری نمایش دهید. هنگامی که مشتری آدرس فرمت شده را پذیرفت، می توانید موارد زیر را از پاسخ ذخیره کنید:

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

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

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

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

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

مرحله 1:

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

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

alt_text

طبق شرایط سرویس، می‌توانید داده‌های زیر را از addressComponent ذخیره کنید:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

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

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

مرحله 2:

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

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

alt_text

  1. هنگامی که کاربر وارد سیستم می شود، ابتدا بررسی کنید که آیا پرچم های اعتبار سنجی را در سیستم خود ذخیره کرده اید یا خیر.
  2. در صورت وجود پرچم، باید یک رابط کاربری برای تصحیح و به روز رسانی آدرس کاربر ارائه دهید.
  3. می‌توانید با آدرس به‌روزرسانی شده یا ذخیره‌شده، دوباره با Address Validation API تماس بگیرید و آدرس تصحیح‌شده را برای تأیید به کاربر ارائه دهید.
  4. اگر آدرس از کیفیت خوبی برخوردار باشد، Address Validation API یک formattedAddress برمی‌گرداند.
  5. اگر اصلاحاتی انجام شده باشد، می‌توانید آن آدرس را به کاربر ارائه دهید، یا در صورت عدم وجود اصلاح، بی‌صدا بپذیرید.
  6. هنگامی که کاربر پذیرفت، می توانید آدرس formattedAddress را در پایگاه داده کش کنید.

نتیجه گیری

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

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

مراحل بعدی

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

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

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

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

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

،

هدف

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

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 آدرس تصحیح شده را برمی گرداند که می توانید با استفاده از اعلان رابط کاربری نمایش دهید. هنگامی که مشتری آدرس فرمت شده را پذیرفت، می توانید موارد زیر را از پاسخ ذخیره کنید:

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

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

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

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

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

مرحله 1:

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

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

alt_text

طبق شرایط سرویس، می‌توانید داده‌های زیر را از addressComponent ذخیره کنید:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

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

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

مرحله 2:

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

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

alt_text

  1. هنگامی که کاربر وارد سیستم می شود، ابتدا بررسی کنید که آیا پرچم های اعتبار سنجی را در سیستم خود ذخیره کرده اید یا خیر.
  2. در صورت وجود پرچم، باید یک رابط کاربری برای تصحیح و به روز رسانی آدرس کاربر ارائه دهید.
  3. می‌توانید با آدرس به‌روزرسانی شده یا ذخیره‌شده، دوباره با Address Validation API تماس بگیرید و آدرس تصحیح‌شده را برای تأیید به کاربر ارائه دهید.
  4. اگر آدرس از کیفیت خوبی برخوردار باشد، Address Validation API یک formattedAddress برمی‌گرداند.
  5. اگر اصلاحاتی انجام شده باشد، می‌توانید آن آدرس را به کاربر ارائه دهید، یا در صورت عدم وجود اصلاح، بی‌صدا بپذیرید.
  6. هنگامی که کاربر پذیرفت، می توانید آدرس formattedAddress را در پایگاه داده کش کنید.

نتیجه گیری

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

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

مراحل بعدی

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

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

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

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

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

،

هدف

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

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 آدرس تصحیح شده را برمی گرداند که می توانید با استفاده از اعلان رابط کاربری نمایش دهید. هنگامی که مشتری آدرس فرمت شده را پذیرفت، می توانید موارد زیر را از پاسخ ذخیره کنید:

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

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

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

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

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

مرحله 1:

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

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

alt_text

طبق شرایط سرویس، می‌توانید داده‌های زیر را از addressComponent ذخیره کنید:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

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

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

مرحله 2:

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

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

alt_text

  1. هنگامی که کاربر وارد سیستم می شود، ابتدا بررسی کنید که آیا پرچم های اعتبار سنجی را در سیستم خود ذخیره کرده اید یا خیر.
  2. در صورت وجود پرچم، باید یک رابط کاربری برای تصحیح و به روز رسانی آدرس کاربر ارائه دهید.
  3. می‌توانید با آدرس به‌روزرسانی شده یا ذخیره‌شده، دوباره با Address Validation API تماس بگیرید و آدرس تصحیح‌شده را برای تأیید به کاربر ارائه دهید.
  4. اگر آدرس از کیفیت خوبی برخوردار باشد، Address Validation API یک formattedAddress برمی‌گرداند.
  5. اگر اصلاحاتی انجام شده باشد، می‌توانید آن آدرس را به کاربر ارائه دهید، یا در صورت عدم وجود اصلاح، بی‌صدا بپذیرید.
  6. هنگامی که کاربر پذیرفت، می توانید آدرس formattedAddress را در پایگاه داده کش کنید.

نتیجه گیری

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

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

مراحل بعدی

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

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

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

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

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