ใช้ Address Validation API เพื่อประมวลผลที่อยู่ปริมาณมาก

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

ในฐานะนักพัฒนาซอฟต์แวร์ คุณมักทำงานกับชุดข้อมูลที่มีที่อยู่ของลูกค้าซึ่งอาจไม่ได้มีคุณภาพดี คุณต้องตรวจสอบว่าที่อยู่ถูกต้องสำหรับกรณีการใช้งานต่างๆ ตั้งแต่การยืนยันรหัสลูกค้า การนำส่ง และอื่นๆ

Address Validation API เป็นผลิตภัณฑ์จาก Google Maps Platform ที่คุณใช้เพื่อตรวจสอบที่อยู่ได้ อย่างไรก็ตาม ระบบจะประมวลผลที่อยู่ได้ครั้งละ 1 รายการเท่านั้น ในเอกสารนี้ เราจะพูดถึงวิธีใช้การตรวจสอบที่อยู่ปริมาณมากในสถานการณ์ต่างๆ ตั้งแต่การทดสอบ API ไปจนถึงการตรวจสอบที่อยู่แบบครั้งเดียวและตามรอบ

Use Case

ต่อไปเรามาเข้าใจกรณีการใช้งานที่การตรวจสอบที่อยู่ปริมาณมากมีประโยชน์กัน

การทดสอบ

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

การตรวจสอบที่อยู่แบบครั้งเดียว

ขณะเริ่มต้นใช้งาน Address Validation API คุณต้องการตรวจสอบฐานข้อมูลที่อยู่ที่มีอยู่กับฐานข้อมูลผู้ใช้

การตรวจสอบที่อยู่ที่เกิดซ้ำ

มีบางสถานการณ์ที่จำเป็นต้องตรวจสอบที่อยู่เป็นประจำ เช่น

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

ข้อมูลเจาะลึกทางเทคนิค

สำหรับวัตถุประสงค์ของเอกสารนี้ เราถือว่า:

  • คุณเรียกใช้ Address Validation API ด้วยที่อยู่จากฐานข้อมูลลูกค้า (เช่น ฐานข้อมูลที่มีรายละเอียดของลูกค้า)
  • คุณแคชแฟล็กความถูกต้องของอีเมลแต่ละรายการในฐานข้อมูลได้
  • ระบบจะดึงข้อมูลแฟล็กความถูกต้องจาก Address Validation API เมื่อลูกค้าแต่ละรายเข้าสู่ระบบ

การแคชสำหรับการใช้งานจริง

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

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

  • ข้อมูลจากออบเจ็กต์ AddressComponent
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

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

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

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

ทำความเข้าใจคำตอบ

หากการตอบกลับ Address Validation API มีเครื่องหมายต่อไปนี้ คุณจะมั่นใจได้ว่าที่อยู่ที่ป้อนมีคุณภาพการนำส่งได้

  • เครื่องหมาย addressComplete ในออบเจ็กต์ Verdict คือ true
  • validationGranularity ในออบเจ็กต์การตัดสินคือ PREMISE หรือ SUB_PREMISE
  • ไม่มี AddressComponent ที่ทำเครื่องหมายว่าเป็น
    • Inferred(หมายเหตุ: inferred=trueอาจเกิดขึ้นเมื่อ addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected และ
  • confirmationLevel: ระดับการยืนยันใน AddressComponent ตั้งค่าเป็นCONFIRMEDหรือUNCONFIRMED_BUT_PLAUSIBLE

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

  • formattedAddress
  • postalAddress
  • addressComponent componentNamesหรือ
  • UspsData standardizedAddress

ใช้การตรวจสอบที่อยู่แบบไม่มีส่วนหัว

อ้างอิงจากการสนทนาข้างต้น:

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

ในส่วนต่อไป เราจะกล่าวถึงกระบวนการ 2 ขั้นตอนเกี่ยวกับวิธีปฏิบัติตามข้อกำหนดในการให้บริการและการนำการตรวจสอบที่อยู่ปริมาณมากไปใช้

ขั้นตอนที่ 1:

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

แผนภาพ A: แผนภาพต่อไปนี้แสดงวิธีเพิ่มประสิทธิภาพไปป์ไลน์ข้อมูลด้วยตรรกะการตรวจสอบที่อยู่ปริมาณมาก

alt_text

  • ตามข้อกำหนดในการให้บริการ คุณสามารถแคช addressComplete, validationGranularity and validationFlags ได้เมื่อตรวจสอบที่อยู่โดยไม่มีส่วนหัว

  • คุณแคช addressComplete,validationGranularity and validationFlags, PlaceID กับ UserID หนึ่งๆ ได้ในฐานข้อมูลลูกค้า

ดังนั้นระหว่างขั้นตอนการติดตั้งนี้ เราจะแคชช่องที่กล่าวถึงข้างต้นไว้กับ UserID

สำหรับข้อมูลเพิ่มเติม ให้ดูรายละเอียดเกี่ยวกับโครงสร้างข้อมูลจริง

ขั้นตอนที่ 2:

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

แผนภาพ ข: แผนภาพนี้แสดงให้เห็นว่าการผสานรวมกระบวนการขอความยินยอมจากผู้ใช้ตั้งแต่ต้นจนจบมีลักษณะดังนี้

alt_text

  1. เมื่อผู้ใช้เข้าสู่ระบบ ก่อนอื่นให้ตรวจสอบว่าคุณได้แคชแฟล็กการตรวจสอบความถูกต้องแล้ว เช่น

    • addressComplete เป็นจริง
    • validationGranularity ไม่ใช่ PREMISE หรือ SUB_PREMISE
    • validationFlags คือ inferred,spellCorrected,replaced,unexpected
      • หากไม่มีแฟล็ก ก็มั่นใจได้มากว่าที่อยู่ที่แคชไว้นั้นมีคุณภาพดีและใช้งานได้

  2. หากมีแฟล็ก คุณควรแสดง UI แก่ผู้ใช้เพื่อแก้ไข/อัปเดตที่อยู่

  3. คุณสามารถเรียกใช้ Address Validation API อีกครั้งด้วยที่อยู่ที่อัปเดตหรือแคช และแสดงที่อยู่ที่แก้ไขแล้วแก่ผู้ใช้เพื่อยืนยัน

  4. หากที่อยู่มีคุณภาพดี Address Validation API จะแสดงผล formattedAddress

  5. คุณอาจแสดงที่อยู่ดังกล่าวให้ผู้ใช้ทราบหากมีการแก้ไข หรือยอมรับโดยไม่แจ้งให้ทราบหากไม่มีการแก้ไข

  6. เมื่อผู้ใช้ยอมรับแล้ว คุณจะแคช formattedAddress ในฐานข้อมูลได้

การติดตั้งโค้ดเทียม ขั้นตอนที่ 2:

If addressComplete is FALSE

OR

If validationGranularity is Not PREMISE OR SUB_PREMISE

OR

If validationFlags is inferred OR spellCorrected OR replaced OR unexpected
  {

    # This means there are issues with the existing cached address

    Call UI to present the address to user

}
Else{

    # This means existing address is good
  Proceed to checkout
}

บทสรุป

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

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

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

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

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

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

Google เป็นผู้ดูแลบทความนี้ ผู้เขียนต่อไปนี้เป็นคนเขียน
ผู้เขียนหลัก:

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