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

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

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

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

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

اعتبار سنجی آدرس چیست؟

اعتبار سنجی آدرس (همچنین به عنوان تأیید آدرس نیز شناخته می شود) فرآیندی است که برای تشخیص وجود آدرس های خیابانی و پستی وارد شده طراحی شده است و از کیفیت قابل تحویلی برخوردار است.

چرا هنگام تسویه حساب به تأیید اعتبار نیاز دارید؟

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

سرویس تکمیل خودکار مکان‌ها و Address Validation API به کاربر این امکان را می‌دهد که داده‌های خود را در هنگام بررسی سریع و آسان وارد کند. برخی از سناریوهای متداول که Address Validation API را به بخشی ضروری از فرآیند پرداخت تبدیل می کند عبارتند از:

غلط املایی

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

سفارشات تلفنی

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

خرید هدیه

مردم اغلب محصولاتی را به عنوان هدیه برای دوستان و خانواده می خرند که آدرس آنها را با اطمینان 100٪ نمی دانند. در چنین سناریوهایی، Address Validation API کمک می‌کند تا لایه‌ای از اطمینان از معتبر بودن آدرس وارد شده ارائه شود.

مشتری به فراداده آدرس اضافی نیاز دارد

یک شرکت حمل و نقل بسته یا پیک اغلب برای تکمیل یک تحویل به اطلاعات بیشتری نیاز دارد، مانند نوع ساختمان مسکونی در مقابل تجاری، یا مقدار USPS DPV (فقط ایالات متحده).

تفاوت به دلیل شرکت های تحویل مختلف

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

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

پیاده سازی Address Validation API

پس از اینکه مشتری آدرس خود را وارد کرد، چه از محل تکمیل خودکار یا یک ورودی دستی، داده های آدرس وارد شده را می توان به Address Validation API ارسال کرد.

زمان پیشنهادی برای تماس با Address Validation API با کلیک روی دکمه Next/Continue در فرم آدرس است که به احتمال زیاد به صفحه پردازش پرداخت منتهی می شود.

یک جریان سرتاسری با استفاده از Address Validation API در طول فرآیند پرداخت می‌تواند به شکل زیر باشد:

تصویر

اکنون هر مرحله را به تفصیل شرح می دهیم.

مرحله 1: جریان ورود آدرس - با استفاده از سرویس تکمیل خودکار مکان

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

تکمیل خودکار می تواند ورود آدرس در برنامه شما را ساده کند و منجر به نرخ تبدیل بالاتر و تجربه یکپارچه برای مشتریان شما شود. این یک فیلد ورود سریع و واحد با پیش‌بینی آدرس «نوعی پیش‌رو» ارائه می‌کند که می‌تواند برای پر کردن خودکار فرم آدرس صورت‌حساب یا حمل و نقل استفاده شود.

با گنجاندن تکمیل خودکار در سبد خرید آنلاین خود، می توانید:

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

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

تصویر

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

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

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

  1. مشتری به جای تکمیل خودکار از تکمیل خودکار مرورگر استفاده کرد.
  2. مشتری ورودی تکمیل خودکار را نادیده گرفت.
  3. از تکمیل خودکار استفاده شد، اما آدرس برگشتی ویرایش شد.
  4. شما در حال پردازش یک تراکنش با ارزش بالا هستید که در آن تحویل موفق بسیار مهم است.
  5. به دلایل قانونی باید آدرس های مصرف کننده را ذخیره کنید.

مرحله 3: تایید بصری را ارائه دهید

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

Maps JavaScript API یک نقشه تعاملی برای نمایش موقعیت کاربر ارائه می دهد. Maps Static API امکان جاسازی تصویر در صفحه وب یا در مرحله بعد در ایمیل را فراهم می کند.

Deep Dive - آدرس سناریوهای پذیرش

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

سناریو 1: آدرس معتبر

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

  • نشانگر addressComplete true است،
  • اعتبارسنجی Granularity در PREMISE یا SUB_PREMISE, و
  • هیچ یک از اجزای آدرس به عنوان علامت گذاری نشده است:
    • inferred
    • spellCorrected
    • replaced
    • unexpected

توصیه می‌کنیم داده‌های آدرس توصیه‌شده را از Address Validation API بگیرید، زیرا ممکن است شامل اصلاحات و اضافات جزئی باشد، مانند:

  • حروف بزرگ
  • برای مثال اصلاحات قالب بندی
    • خیابان به خیابان
    • ترتیب صحیح اجزای آدرس
  • ZIP+4 در ایالات متحده آمریکا.

نمونه ای از نحوه استفاده از این بازخورد در فرآیند اعتبار سنجی در زیر نشان داده شده است:

درخواست واکنش
  "address": {
    "regionCode": "US",
    "locality": "Mountain View",
    "addressLines": ["1600 Amphitheatre Pkwy"]
  }
"verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "PREMISE",
      "geocodeGranularity": "PREMISE",
      "addressComplete": true,
      "hasInferredComponents": true
    } …
"addressComponents": [
        {
          "componentName": {
            "text": "1600",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Amphitheatre Parkway",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Mountain View",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED"
        }

سناریو 2: آدرس مشکوک

Address Validation API ممکن است نشان دهد که تغییرات معنی‌داری در آدرس وجود دارد، معمولاً با گنجاندن inferred ، spellCorrected یا replaced در فیلدهای جداگانه ، آدرس برگشتی باید با مشتری تأیید شود. این را می توان با استفاده از یک پاپ آپ مدال، با گزینه ای برای انتخاب آدرس وارد شده، یا توصیه ارائه شده توسط API انجام داد.
  • وقتی Address Validation API مطابقت با آدرس پیدا می‌کند (شبیه به "مطابقت نامزد" برای پاسخ تکمیل خودکار مکان)، با یک آدرس منطبق با محتمل‌ترین آدرس پاسخ می‌دهد و هر مؤلفه اصلاح‌شده را پرچم‌گذاری می‌کند (پاسخ API اعتبار سنجی آدرس: "spellCorrected": true ) . مثلا:
"1600 amphiteatre parkway" با "1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA" مطابقت دارد
نمونه ای از نحوه استفاده از این بازخورد در فرآیند اعتبار سنجی در زیر نشان داده شده است:
درخواست واکنش
  "address": {
    "regionCode": "US",
    "addressLines": ["1600 amphiteatre parkway"]
  }
      "verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "PREMISE",
      "geocodeGranularity": "PREMISE",
      "addressComplete": true,
      "hasInferredComponents": true
    } …
      "address": {
      "formattedAddress": "1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA",
      …
      "addressComponents": [
        {
          "componentName": {
            "text": "1600",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Amphitheatre Parkway",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "CONFIRMED",
          "spellCorrected": true
        }
...
{ "componentName": {
            "text": "Mountain View",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED",
          "inferred": true
        }
توجه: مسیر فاقد «h» است، نام محل وجود ندارد (نمای کوه)

سناریو 3: آدرس نامعتبر است

اگر پاسخ از Address Validation API نشان دهنده یک آدرس نامعتبر باشد، مشتری باید به فرم ورود آدرس هدایت شود تا داده های وارد شده خود را بررسی کند. زمانی که Address Validation API نتواند یک کاندید منطبق برای یک آدرس پیدا کند، اجزای جداگانه آدرس را واجد شرایط می‌کند و داده‌های گمشده/نامعتبر را علامت‌گذاری می‌کند، بنابراین می‌توان فیلدهایی را که نیاز به افزودن یا اصلاح دارند پرچم‌گذاری کرد.
نمونه ای از نحوه استفاده از این بازخورد در فرآیند اعتبار سنجی در زیر نشان داده شده است:
درخواست واکنش
  "address": {
    "regionCode": "US",
    "addressLines": ["123 fake street new york"]
  }

"verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "ROUTE",
      "geocodeGranularity": "ROUTE",
      "hasUnconfirmedComponents": true,
      "hasInferredComponents": true
    } …
"addressComponents": [...
       {"componentName": {
            "text": "123",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
        },
        { "componentName": {
            "text": "fake street",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
        },
        {"componentName": {
            "text": "New York",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED"
        } …

منطق توضیح داده شده در بالا می تواند به عنوان بخشی از جریان پرداخت همانطور که در نمودار جریان زیر نشان داده شده است پیاده سازی شود:

تصویر

نکاتی برای افزایش بیشتر پرداخت

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

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

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

می‌توانید به‌صورت اختیاری از روش provideValidationFeedback Address Validation API برای ارائه بازخورد به Google در مورد یک تلاش برای تأیید اعتبار خاص استفاده کنید. اینجا بیشتر بیاموزید.

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

  • آدرس‌ها را می‌توان فقط در مقابل یک کاربر کش کرد.
  • آدرس قالب‌بندی شده و اکثر ویژگی‌های دیگر تنها پس از کسب رضایت کاربر قابل ذخیره‌سازی هستند.

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

برای مثال، اگر در ایالات متحده هستید، این گزینه را دارید که CASS ™ از US Postal Service® 1 را در پاسخ Address Validation API فعال کنید، که درجه بالایی از جزئیات را در مورد هر آدرس ارائه می دهد.

بسیاری از مشتریان ترجیح می‌دهند که آدرس‌ها را از طریق یک فرآیند ثانویه تأیید کنند، مانند:

  • دلایل نظارتی مشتریان را موظف می کند که آدرس دقیق ذخیره شده را تضمین کنند.
  • اگر تماس اولیه برای تأیید اعتبار آدرس ناموفق بود، آدرس را مجدداً به صورت آفلاین تأیید کنید.

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

نتیجه

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

مراحل بعدی

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

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

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

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

  1. دارنده مجوز غیر انحصاری خدمات پستی ایالات متحده. علامت(های) تجاری زیر متعلق به US Postal Service® است و با مجوز استفاده می شود: CASS™، USPS®، DPV®. ↩