การตรวจสอบที่อยู่สําหรับการชําระเงินอีคอมเมิร์ซ

วัตถุประสงค์

การบันทึกที่อยู่ที่ถูกต้องจากคำสั่งซื้อของลูกค้าเป็นสิ่งสำคัญสำหรับอีคอมเมิร์ซ เพราะจะช่วยให้มั่นใจได้ว่าผลิตภัณฑ์จะนำส่งได้สำเร็จ เพิ่มการนำส่งตรงเวลา และลดค่าบริการแก้ไขที่อยู่จัดส่ง

เอกสารนี้จะอธิบายแนวทางปฏิบัติแนะนำในการใช้ Address Validation API ที่จุดชำระเงินอีคอมเมิร์ซ ซึ่งรวมถึงกรณีที่ควรยอมรับที่อยู่ที่ดีอย่างเงียบๆ, ยืนยันการตอบกลับการตรวจสอบที่อยู่กับลูกค้า หรือส่งลูกค้ากลับไปยังแบบฟอร์มการป้อนที่อยู่เพื่อทำการแก้ไขด้วยตนเอง

Google Maps Platform มีบทแนะนำ เกี่ยวกับวิธีปรับปรุงการชำระเงินโดยใช้บริการเติมข้อความอัตโนมัติเกี่ยวกับสถานที่อยู่แล้ว เอกสารนี้จะขยายบทแนะนำให้เพิ่มเติมด้วยการเพิ่มความสามารถใหม่ของ Address Validation API ซึ่งออกแบบมาเพื่อระบุข้อผิดพลาดในการป้อนที่อยู่ ซึ่งช่วยพัฒนาความสามารถในการนำส่งและทำให้การชำระเงินมีประสิทธิภาพมากขึ้น

การตรวจสอบที่อยู่คืออะไร

การตรวจสอบที่อยู่ (หรือที่เรียกว่าการยืนยันที่อยู่) คือกระบวนการที่ออกแบบมาเพื่อระบุว่าที่อยู่ถนนและไปรษณีย์ที่ป้อนมีอยู่จริงหรือไม่ และมีคุณภาพในการจัดส่งได้

เหตุใดคุณจึงต้องมีการตรวจสอบที่อยู่ที่จุดชำระเงิน

ข้อผิดพลาดที่สังเกตไม่ได้ในที่อยู่ที่จุดชำระเงินอาจก่อให้เกิดปัญหาการนำส่งที่ร้ายแรง การตรวจสอบที่อยู่ในหน้าจอชำระเงินช่วยให้มั่นใจได้ว่าที่อยู่ที่ลูกค้าป้อนสำหรับการนำส่งนั้นถูกต้อง ผลก็คือลดการส่งที่ไม่สำเร็จ และการส่งผิด ซึ่งเป็นการสร้างความเสียหายให้กับธุรกิจ

บริการ Places Autocomplete และ Address Validation API ช่วยให้ผู้ใช้ ป้อนข้อมูลอย่างถูกต้องที่จุดชำระเงินได้อย่างรวดเร็วและง่ายดาย กรณีทั่วไปที่ทำให้ Address Validation API เป็นส่วนสำคัญของกระบวนการชำระเงินมีดังนี้

พิมพ์ผิด

ลูกค้ามักจะพิมพ์ผิดเมื่อป้อนที่อยู่ โดยเฉพาะในอุปกรณ์เคลื่อนที่ เช่น การใส่นิวยอร์กเป็นย่านสำหรับที่อยู่ในบรูคลิน

คำสั่งซื้อทางโทรศัพท์

ผู้ที่รับคำสั่งซื้อทางโทรศัพท์อาจเข้าใจผิดเกี่ยวกับที่อยู่หรือบันทึกข้อมูลที่อยู่บางส่วนได้ ด้วยเหตุนี้จึงทำให้การนำส่งคำสั่งซื้อใช้เวลานานขึ้น หรือล้มเหลวอย่างสิ้นเชิง

การซื้อของขวัญ

คนส่วนใหญ่มักซื้อผลิตภัณฑ์เป็นของขวัญให้เพื่อนๆ และครอบครัว ซึ่งพวกเขา อาจไม่ทราบที่อยู่ที่แน่นอน 100% ในสถานการณ์เช่นนี้ Address Validation API จะช่วยเพิ่มระดับความมั่นใจว่าที่อยู่ที่ป้อนนั้นถูกต้อง

ลูกค้าต้องการข้อมูลเมตาที่อยู่เพิ่มเติม

บริษัทจัดส่งพัสดุหรือบริษัทจัดส่งมักต้องการข้อมูลเพิ่มเติมเพื่อดำเนินการนำส่งให้เสร็จสิ้น เช่น ประเภทอาคารที่อยู่อาศัยเทียบกับอาคารพาณิชย์ หรือค่า USPS DPV (สหรัฐอเมริกาเท่านั้น)

ความแตกต่างเนื่องจากบริษัทจัดส่งแต่ละแห่ง

บริการไปรษณีย์ท้องถิ่นมักมีความรู้เกี่ยวกับย่านใกล้เคียงมากกว่าผู้ให้บริการจัดส่งขนาดเล็ก ดังนั้นแม้ว่าจะไม่มีหมายเลขอพาร์ตเมนต์หรือจุดสังเกตในท้องถิ่น ผู้ให้บริการขนส่งบางราย (เช่น ที่ทำการไปรษณีย์) อาจส่งพัสดุได้ในกรณีที่ผู้ให้บริการรายอื่นอาจดำเนินการไม่สำเร็จ

หากผู้ให้บริการจัดส่งไม่มีความรู้ในท้องถิ่นเกี่ยวกับพื้นที่นำส่ง ผู้ให้บริการจัดส่งยิ่งมีข้อมูลเพิ่มเติมจะช่วยให้การจัดส่งประสบความสำเร็จ การแก้ไขที่ Address Validation API แนะนำจะทำให้ผู้ให้บริการจัดส่งมั่นใจมากขึ้นว่าสินค้านั้นจะได้รับการจัดส่งได้

การใช้งาน Address Validation API

หลังจากที่ลูกค้าป้อนที่อยู่แล้ว ไม่ว่าจะเป็นที่อยู่จาก Place Autocomplete หรือการป้อนด้วยตนเอง ข้อมูลที่อยู่ที่ป้อนจะสามารถส่งไปยัง Address Validation API ได้

เวลาที่แนะนำสำหรับการเรียกใช้ Address Validation API คือการคลิกปุ่ม "ถัดไป/ดำเนินการต่อ" ในแบบฟอร์มที่อยู่ ซึ่งน่าจะนำไปยังหน้าการประมวลผลการชำระเงิน

ขั้นตอนตั้งแต่ต้นจนจบที่ใช้ Address Validation API ระหว่างขั้นตอนการชำระเงินอาจมีลักษณะดังนี้

รูปภาพ

ตอนนี้เราจะแจกแจงแต่ละขั้นตอนโดยละเอียด

ขั้นตอนที่ 1: ขั้นตอนการป้อนที่อยู่ - การใช้บริการเติมข้อความอัตโนมัติ

คุณควรใช้บริการเติมสถานที่อัตโนมัติในบรรทัดแรกของแบบฟอร์มการป้อนที่อยู่ โดยให้คําแนะนําแก่ลูกค้าขณะที่ป้อนรายละเอียดที่อยู่

การเติมข้อความอัตโนมัติจะช่วยลดความซับซ้อนในการป้อนที่อยู่ในแอปพลิเคชัน ซึ่งนำไปสู่อัตรา Conversion ที่สูงขึ้นและช่วยให้ลูกค้าได้รับประสบการณ์การใช้งานที่ราบรื่น โดยใช้ช่องป้อนข้อความสั้นๆ เพียงช่องเดียวที่มีการคาดคะเนที่อยู่แบบ "พิมพ์ล่วงหน้า" ที่สามารถใช้สร้างแบบฟอร์มที่อยู่สำหรับจัดส่งหรือเรียกเก็บเงินโดยอัตโนมัติได้

การรวมการเติมข้อความอัตโนมัติไว้ในรถเข็นช็อปปิ้งออนไลน์ช่วยให้คุณทำสิ่งต่อไปนี้ได้

  • ลดการกดแป้นพิมพ์และเวลาโดยรวมที่ต้องใช้ในการสั่งซื้อได้อย่างมาก
  • ลดข้อผิดพลาดในการป้อนที่อยู่
  • ลดการละทิ้งรถเข็นกลางคัน
  • ลดความซับซ้อนของประสบการณ์การป้อนที่อยู่ในอุปกรณ์เคลื่อนที่หรืออุปกรณ์ที่สวมใส่ได้

ตัวอย่างบางส่วนของลักษณะหน้าจอโฟลว์ในระยะนี้จะแสดงที่นี่

รูปภาพ

ขั้นตอนที่ 2: ใช้ Address Validation API เพื่อตรวจสอบที่อยู่

เราขอแนะนำให้เรียกใช้ Address Validation API ที่จุดชำระเงินเพื่อยืนยันว่าที่อยู่ถูกต้องและครบถ้วน

อย่างไรก็ตาม หากไม่มีการเรียกใช้ Address Validation API ในขั้นตอนเริ่มต้นด้วยเหตุผลบางประการ เราขอแนะนำให้คุณเรียกใช้อย่างน้อยภายใต้สถานการณ์ต่อไปนี้

  1. ลูกค้าใช้การป้อนข้อความอัตโนมัติในเบราว์เซอร์แทนการเติมข้อความอัตโนมัติ
  2. ลูกค้าไม่สนใจการป้อนข้อมูลอัตโนมัติ
  3. มีการใช้การเติมข้อความอัตโนมัติ แต่มีการแก้ไขที่อยู่ที่ส่งคืน
  4. คุณกำลังประมวลผลธุรกรรมที่มีมูลค่าสูง ซึ่งการแสดงโฆษณาที่ประสบความสำเร็จนั้นสำคัญเป็นพิเศษ
  5. คุณต้องจัดเก็บที่อยู่ของผู้บริโภคด้วยเหตุผลทางกฎหมาย

ขั้นตอนที่ 3: ส่งภาพยืนยัน

หลังจากป้อนที่อยู่ ให้ภาพการยืนยันสถานที่นำส่งแก่ผู้ใช้ด้วยแผนที่แบบคงที่แบบง่าย แผนที่นี้ให้ความมั่นใจเพิ่มเติมแก่ลูกค้าว่าที่อยู่ถูกต้อง และลดความผิดพลาดในการจัดส่ง/รับสินค้า
แผนที่อาจแสดงในหน้าเว็บที่ลูกค้าป้อนที่อยู่ หรือแม้แต่ส่งภายในอีเมลยืนยันเมื่อลูกค้าทำธุรกรรมเสร็จแล้ว กรณีการใช้งานทั้ง 2 อย่างนี้สามารถทำได้โดยใช้ API ต่อไปนี้

Maps JavaScript API จะมีแผนที่แบบอินเทอร์แอกทีฟสำหรับแสดงตำแหน่งของผู้ใช้ Maps Static API ช่วยให้ฝังรูปภาพไว้ในหน้าเว็บหรือในขั้นตอนท้ายๆ ของอีเมลได้

เจาะลึก - สถานการณ์การยอมรับที่อยู่

มี 3 สถานการณ์หลักๆ ที่สามารถกำหนดจากการตอบสนองของ Address Validation API ได้ ระบบจะไฮไลต์คอมโพเนนต์ในการตอบกลับสำหรับการตรวจสอบคุณภาพที่อยู่ และโฟลว์ชาร์ตที่อยู่ในช่วงต้นของเอกสารจะมีขั้นตอนแนะนำในภาพรวมสำหรับสถานการณ์ที่อธิบายไปเหล่านี้

สถานการณ์ 1: ที่อยู่ที่ถูกต้อง

หาก API แสดงผลสัญญาณว่าที่อยู่ที่ป้อนมีคุณภาพดี จุดชำระเงินจะย้ายไปยังขั้นตอนถัดไปได้โดยไม่ต้องแจ้งให้ทราบลูกค้า
สัญญาณที่บ่งชี้ที่อยู่ที่มีคุณภาพดีมีดังนี้

  • เครื่องหมาย addressComplete ที่เป็น true
  • ValidationGranularity ที่ 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 พบข้อมูลที่ตรงกันกับที่อยู่ (คล้ายกับ "การจับคู่ผู้สมัคร" สำหรับการตอบกลับของ Place Autocomplete) ก็จะตอบกลับด้วยที่อยู่ที่น่าจะตรงกันมากที่สุดที่อยู่เดียวแล้วแจ้งคอมโพเนนต์ที่แก้ไขแล้ว (การตอบกลับจาก Address Validation 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" ไม่มีชื่อท้องถิ่น (Mountain View)

สถานการณ์ 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 ระบุอย่างต่อเนื่องว่ารายการของลูกค้าเป็นที่อยู่ที่ไม่ถูกต้อง

เราขอแนะนำให้ลูกค้ามีโอกาสสูงสุด 2 ครั้งในการป้อนที่อยู่ และในความพยายามครั้งที่ 2 ลูกค้าควรจะได้รับการยอมรับแม้ว่าจะไม่ได้ตรวจสอบก็ตาม ซึ่งทำได้โดยการให้ลูกค้า "บังคับให้ดำเนินการต่อ" เมื่อแสดงป๊อปอัปโมดัลที่มีคำแนะนำ API หรือยอมรับการป้อนที่อยู่เป็นครั้งที่ 2 แม้ว่าที่อยู่ไม่ได้ตรวจสอบความถูกต้องโดยสมบูรณ์ก็ตาม ข้อมูลที่อยู่ที่ไม่ผ่านการตรวจสอบโดยสมบูรณ์สามารถแจ้งให้ฝ่ายบริการลูกค้าตรวจสอบด้วยตนเองก่อนจัดส่งผลิตภัณฑ์ได้

ตัวอย่างที่แสดงให้เห็นว่าการเปลี่ยนแปลงนี้สำคัญอย่างไรคือการสร้างใหม่ อาจมีช่องว่างระหว่างตอนที่สร้างอาคารใหม่เสร็จกับเวลาที่ใส่ที่อยู่ของอาคารในฐานข้อมูลที่อยู่ไปรษณีย์ ลูกค้าควรสามารถบังคับให้ดำเนินการต่อไปยังหน้าชำระเงินด้วยที่อยู่ที่พิมพ์ ซึ่งอาจจะยังไม่ได้ผ่านการตรวจสอบความถูกต้อง

คุณอาจใช้เมธอด provideValidationFeedback ของ Address Validation API เพื่อให้ความคิดเห็นแก่ Google เกี่ยวกับการพยายามตรวจสอบที่เฉพาะเจาะจงได้ ดูข้อมูลเพิ่มเติม ที่นี่

ที่อยู่จะแสดงใน UI หรือแคชในฐานข้อมูลได้หากสอดคล้องกับข้อกำหนดเฉพาะของบริการการตรวจสอบที่อยู่ API หากมีการแคชที่อยู่ไว้ในฐานข้อมูล เราจะต้องตรวจสอบสิ่งต่อไปนี้

  • ที่อยู่จะแคชไว้กับผู้ใช้ได้เท่านั้น
  • ระบบจะแคชที่อยู่ที่จัดรูปแบบและแอตทริบิวต์อื่นๆ ส่วนใหญ่ได้หลังจากได้รับความยินยอมจากผู้ใช้เท่านั้น

คุณจะพบว่าการตอบกลับบางรายการจากการเติมข้อความอัตโนมัติและ/หรือ API การตรวจสอบที่อยู่ไม่สมบูรณ์บางส่วนหรือทั้งหมด เราขอแนะนำให้ใช้ตรรกะทางธุรกิจเพื่อให้ผ่อนปรนมากขึ้นเมื่อตัดสินใจว่าจะยอมรับที่อยู่ที่ Address Validation API ยืนยันไม่ได้ ทั้งนี้ขึ้นอยู่กับภูมิศาสตร์และความต้องการทางธุรกิจของคุณ

เช่น หากอยู่ในสหรัฐอเมริกา คุณจะมีตัวเลือกให้เปิดใช้ CASSTM จาก United States Postal Service®1 ในการตอบกลับเกี่ยวกับ Address Validation API ซึ่งจะให้รายละเอียดเกี่ยวกับที่อยู่แต่ละรายการอย่างละเอียด

ลูกค้าจำนวนมากต้องการตรวจสอบที่อยู่อีกครั้งผ่านกระบวนการรอง เช่น

  • เหตุผลด้านการกำกับดูแลบังคับให้ลูกค้ารับประกันที่อยู่ที่แน่นอนในการแคช
  • หากการเรียกเพื่อยืนยันที่อยู่ครั้งแรกล้มเหลว ให้ตรวจสอบที่อยู่แบบออฟไลน์อีกครั้ง

เราให้บริการการตรวจสอบที่อยู่ปริมาณมากเป็นเครื่องมือซอฟต์แวร์โอเพนซอร์สเพื่อใช้การตรวจสอบที่อยู่อีกครั้งในกระบวนการแบบกลุ่ม

บทสรุป

Address Validation API เป็นเครื่องมือที่มีประสิทธิภาพในการปรับปรุงประสบการณ์การชำระเงินสำหรับแพลตฟอร์มอีคอมเมิร์ซ ดูข้อมูลเพิ่มเติมเกี่ยวกับ Address Validation API และลองใช้ได้ที่นี่

ขั้นตอนถัดไป

ดาวน์โหลดเอกสารประกอบปรับปรุงการชำระเงิน การนำส่ง และการดำเนินการด้วยที่อยู่ที่เชื่อถือได้ และดูการสัมมนาผ่านเว็บเกี่ยวกับการปรับปรุงการชำระเงิน การนำส่ง และการดำเนินการด้วยการตรวจสอบที่อยู่

แนะนำให้อ่านเพิ่มเติม:

ผู้ร่วมให้ข้อมูล

Henrik Valve | วิศวกรโซลูชัน
Thomas Anglaret | วิศวกรโซลูชัน
Sarthak Ganguly | วิศวกร โซลูชัน

  1. ผู้รับอนุญาตแบบไม่เฉพาะตัวของบริการไปรษณีย์ของสหรัฐอเมริกา เครื่องหมายการค้าต่อไปนี้เป็นของ United States Postal Service® และได้รับอนุญาตแล้ว: CASSTM, USPS®, DPV® ↩