راهنمای اعتبارسنجی نشانی با حجم بالا

هدف اصلی

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

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

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

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

آزمایش

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

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

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

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

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

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

ژرف‌کاوی فنی

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

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

حافظه نهان برای استفاده تولید

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

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

  • داده‌های شیء 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 تنظیم شده است

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

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

پیاده‌سازی «اعتبارسنجی نشانی» بدون سر

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

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

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

مرحله 1:

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

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

alt_text

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

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

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

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

مرحله 2:

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

نمودار ب: این نمودار نشان می‌دهد که ادغام سرتاسری جریان موافقت کاربر چگونه می‌تواند باشد:

alt_text

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

نتیجه‌گیری

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

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

مراحل بعدی

بهبود تسویه‌حساب، تحویل، و عملیات با نشانی‌های قابل‌اعتماد گزارش رسمی را بارگیری کنید و بهبود تسویه‌حساب، تحویل، و عملیات با Address Validation وبینار را مشاهده کنید.

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

همیاران

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

Henrik Valve | مهندس راه‌حل‌ها
Thomas Anglaret | مهندس راه‌حل‌ها
Sarthak Ganguly | مهندس راه‌حل‌ها