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

هدف

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

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

موارد استفاده

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

آزمایش

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

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

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

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

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

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

بررسی عمیق فنی

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

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

حافظه پنهان برای استفاده در محیط عملیاتی

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

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

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

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

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

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

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

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

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

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

بر اساس بحث فوق:

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

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

مرحله ۱:

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

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

alt_text

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

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

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

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

مرحله ۲:

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

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

alt_text

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

نتیجه‌گیری

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

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

مراحل بعدی

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

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

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

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

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