Sử dụng API Xác thực địa chỉ để xử lý các địa chỉ ở khối lượng lớn

Mục tiêu

Là một nhà phát triển, bạn thường làm việc với các tập dữ liệu có chứa địa chỉ khách hàng có thể không có chất lượng tốt. Bạn cần đảm bảo rằng địa chỉ là chính xác cho các trường hợp sử dụng từ xác minh id khách hàng, giao hàng, v.v.

API xác thực địa chỉ là một sản phẩm của Nền tảng Google Maps mà bạn có thể dùng để xác thực địa chỉ. Tuy nhiên, mỗi lần chỉ xử lý một địa chỉ. Trong tài liệu này, chúng ta sẽ tìm hiểu cách sử dụng tính năng Xác thực địa chỉ số lượng lớn trong các tình huống khác nhau, từ thử nghiệm API đến xác thực địa chỉ một lần và định kỳ.

Trường hợp sử dụng

Bây giờ, hãy hiểu các trường hợp sử dụng mà tính năng Xác thực địa chỉ số lượng lớn hữu ích.

Kiểm thử

Bạn thường muốn kiểm tra API xác thực địa chỉ bằng cách chạy hàng nghìn địa chỉ. Bạn có thể có các địa chỉ trong tệp Giá trị được phân tách bằng dấu phẩy và muốn xác thực chất lượng của các địa chỉ này.

Xác thực địa chỉ một lần

Khi làm quen với API Xác thực địa chỉ, bạn muốn xác thực cơ sở dữ liệu địa chỉ hiện có của mình dựa trên cơ sở dữ liệu người dùng.

Xác thực định kỳ các địa chỉ

Một số tình huống yêu cầu xác thực địa chỉ định kỳ:

  • Bạn có thể đã lên lịch cho các công việc để xác thực địa chỉ đối với những thông tin thu thập được trong ngày, ví dụ như thông tin đăng ký của khách hàng, chi tiết đơn đặt hàng, lịch giao hàng.
  • Bạn có thể nhận được tệp kết xuất dữ liệu chứa địa chỉ từ các phòng ban khác nhau, ví dụ: từ bộ phận bán hàng đến bộ phận tiếp thị. Bộ phận mới nhận các địa chỉ thường muốn xác thực chúng trước khi sử dụng.
  • Bạn có thể thu thập địa chỉ trong các cuộc khảo sát hoặc nhiều chương trình khuyến mãi và sau đó cập nhật trong hệ thống trực tuyến. Bạn muốn kiểm tra xem các địa chỉ này đã chính xác hay chưa trong khi nhập vào hệ thống.

Tìm hiểu chuyên sâu về kỹ thuật

Theo mục đích của tài liệu này, chúng tôi giả định rằng:

  • Bạn đang gọi API xác thực địa chỉ bằng địa chỉ từ một cơ sở dữ liệu khách hàng (tức là cơ sở dữ liệu có thông tin chi tiết về khách hàng)
  • Bạn có thể lưu các cờ hợp lệ vào bộ nhớ đệm đối với các địa chỉ riêng lẻ trong cơ sở dữ liệu của mình.
  • Cờ tính hợp lệ được truy xuất từ API xác thực địa chỉ khi một khách hàng cá nhân đăng nhập.

Lưu vào bộ nhớ đệm để dùng cho kênh phát hành công khai

Khi sử dụng API xác thực địa chỉ, bạn thường muốn lưu một số phần của phản hồi từ lệnh gọi API vào bộ nhớ đệm. Mặc dù Điều khoản dịch vụ của chúng tôi giới hạn loại dữ liệu có thể được lưu vào bộ nhớ đệm, nhưng mọi dữ liệu có thể được lưu vào bộ nhớ đệm thông qua API xác thực địa chỉ đều phải được lưu vào bộ nhớ đệm dựa trên tài khoản người dùng. Điều này có nghĩa là trong cơ sở dữ liệu, địa chỉ hoặc siêu dữ liệu địa chỉ phải được lưu vào bộ nhớ đệm dựa trên địa chỉ email hoặc mã nhận dạng chính khác của người dùng.

Đối với trường hợp sử dụng tính năng Xác thực địa chỉ số lượng lớn, việc lưu dữ liệu vào bộ nhớ đệm phải tuân thủ Điều khoản dành riêng cho dịch vụ của API Xác thực địa chỉ, nêu trong Mục 11.3. Dựa trên thông tin này, bạn sẽ có thể xác định liệu địa chỉ của người dùng có thể không hợp lệ hay không. Trong trường hợp đó, bạn sẽ nhắc người dùng cung cấp một địa chỉ đã sửa trong lần tương tác tiếp theo của họ với ứng dụng của bạn.

  • Dữ liệu của đối tượng Kết quả

    • inputGranularity
    • validationGranularity
    • geocodeGranularity
    • addressComplete
    • hasUnconfirmedComponents
    • hasInferredComponents
    • hasReplacedComponents
  • Dữ liệu của đối tượng AddressComponent

    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

Nếu bạn muốn lưu vào bộ nhớ đệm bất kỳ thông tin nào về địa chỉ thực, thì dữ liệu đó chỉ được lưu vào bộ nhớ đệm khi có sự đồng ý của người dùng. Điều này đảm bảo rằng người dùng biết rõ lý do tại sao một dịch vụ cụ thể lưu trữ địa chỉ của họ và họ chấp nhận các điều khoản chia sẻ địa chỉ của mình.

Ví dụ về sự đồng ý của người dùng là hoạt động tương tác trực tiếp với biểu mẫu địa chỉ thương mại điện tử trên trang thanh toán. Chúng tôi hiểu rằng bạn sẽ lưu vào bộ nhớ đệm và xử lý địa chỉ để vận chuyển kiện hàng.

Nếu có sự đồng ý của người dùng, bạn có thể lưu formattedAddress và các thành phần chính khác vào phản hồi vào bộ nhớ đệm. Tuy nhiên, trong trường hợp không có giao diện người dùng, người dùng không thể đồng ý vì quá trình xác thực địa chỉ đang diễn ra qua phần phụ trợ. Do đó, bạn có thể lưu vào bộ nhớ đệm rất ít thông tin trong trường hợp không có giao diện người dùng này.

Tìm hiểu câu trả lời

Nếu phản hồi của API xác thực địa chỉ có chứa các dấu sau, thì bạn có thể yên tâm rằng địa chỉ nhập có chất lượng gửi được:

  • Điểm đánh dấu addressComplete trong đối tượng Kết quảtrue,
  • validationGranularity trong đối tượng Kết quảPREMISE hoặc SUB_PREMISE
  • Không có AddressComponent nào được đánh dấu là:
    • Inferred(Lưu ý: inferred=truecó thể xảy ra khi addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected
  • confirmationLevel: Cấp xác nhận trong AddressComponent được đặt thànhCONFIRMEDhoặcUNCONFIRMED_BUT_PLAUSIBLE

Nếu phản hồi của API không chứa các điểm đánh dấu nêu trên thì địa chỉ đầu vào có thể có chất lượng kém và bạn có thể lưu cờ vào bộ nhớ đệm trong cơ sở dữ liệu để phản ánh điều đó. Cờ được lưu trong bộ nhớ đệm cho biết toàn bộ địa chỉ có chất lượng kém, trong khi cờ chi tiết hơn như Đã sửa lỗi chính tả cho biết loại vấn đề cụ thể về chất lượng địa chỉ. Trong lần tiếp theo khách hàng tương tác với một địa chỉ bị gắn cờ là có chất lượng kém, bạn có thể gọi API xác thực địa chỉ bằng địa chỉ hiện tại. API xác thực địa chỉ sẽ trả về địa chỉ đã sửa mà bạn có thể hiển thị qua lời nhắc trên giao diện người dùng. Sau khi khách hàng chấp nhận địa chỉ đã định dạng, bạn có thể lưu các nội dung sau vào bộ nhớ đệm từ phản hồi:

  • formattedAddress
  • postalAddress
  • addressComponent componentNameshoặc
  • UspsData standardizedAddress

Triển khai quy trình xác thực địa chỉ không có giao diện người dùng

Dựa trên nội dung thảo luận ở trên:

  • Thông thường, cần phải lưu một số phần của phản hồi từ API xác thực địa chỉ vào bộ nhớ đệm vì lý do kinh doanh.
  • Tuy nhiên, Điều khoản dịch vụ trong Nền tảng Google Maps hạn chế loại dữ liệu có thể được lưu vào bộ nhớ đệm.

Trong phần sau, chúng ta sẽ thảo luận về quy trình gồm 2 bước để tuân thủ Điều khoản dịch vụ và triển khai quy trình xác thực địa chỉ xử lý số lượng lớn.

Bước 1:

Trong bước đầu tiên, chúng ta sẽ tìm hiểu cách triển khai một tập lệnh xác thực địa chỉ khối lượng lớn từ quy trình dữ liệu hiện có. Quá trình này sẽ cho phép bạn lưu trữ các trường cụ thể trong phản hồi của API Xác thực địa chỉ theo cách tuân thủ Điều khoản dịch vụ.

Biểu đồ A: Sơ đồ dưới đây cho thấy cách cải thiện quy trình dữ liệu bằng logic Xác thực địa chỉ khối lượng lớn.

alt_text

  • Theo Điều khoản dịch vụ , bạn có thể lưu addressComplete,validationGranularity and validationFlags vào bộ nhớ đệm khi xác thực các địa chỉ theo cách không có giao diện người dùng .

  • Bạn có thể lưu addressComplete,validationGranularity and validationFlags, PlaceID vào bộ nhớ đệm dựa trên một UserID cụ thể trong cơ sở dữ liệu khách hàng.

Do đó, trong bước triển khai này, chúng tôi sẽ lưu các trường được đề cập ở trên vào bộ nhớ đệm dựa vào UserID.

Để biết thêm thông tin, hãy xem chi tiết về cấu trúc dữ liệu thực tế.

Bước 2:

Ở bước 1, chúng tôi đã thu thập ý kiến phản hồi rằng một số địa chỉ trong tập dữ liệu đầu vào có thể không có chất lượng cao. Ở bước tiếp theo, chúng tôi sẽ lấy những địa chỉ bị gắn cờ này và cung cấp cho người dùng, đồng thời yêu cầu họ đồng ý cho sửa địa chỉ đã lưu trữ.

Biểu đồ B: Sơ đồ này cho thấy quy trình tích hợp toàn diện của quy trình lấy sự đồng ý của người dùng có thể trông như thế nào:

alt_text

  1. Khi người dùng đăng nhập, trước tiên, hãy kiểm tra xem bạn đã lưu bất kỳ cờ xác thực nào vào bộ nhớ đệm trong hệ thống của mình hay chưa, chẳng hạn như:

    • addressComplete là đúng
    • validationGranularity không ở trạng thái PREMISE hoặc SUB_PREMISE
    • validationFlagsinferred,spellCorrected,replaced,unexpected.
      • Nếu không có cờ nào thì bạn chắc chắn rằng địa chỉ đã lưu vào bộ nhớ đệm hiện có có chất lượng tốt và có thể được sử dụng.
  2. Nếu có cờ, bạn nên hiển thị cho người dùng một giao diện người dùng để sửa/cập nhật địa chỉ của họ.

  3. Bạn có thể gọi lại API xác thực địa chỉ bằng địa chỉ đã cập nhật hoặc được lưu vào bộ nhớ đệm và hiển thị địa chỉ đã sửa cho người dùng để xác nhận.

  4. Nếu địa chỉ có chất lượng tốt, API xác thực địa chỉ sẽ trả về formattedAddress.

  5. Bạn có thể hiển thị địa chỉ đó cho người dùng nếu đã sửa chữa hoặc ngầm chấp nhận nếu không có sửa đổi.

  6. Sau khi người dùng chấp nhận, bạn có thể lưu formattedAddress vào bộ nhớ đệm trong cơ sở dữ liệu.

Triển khai mã giả mạo Bước 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
}

Kết luận

Xác thực địa chỉ số lượng lớn là một trường hợp sử dụng phổ biến mà có khả năng bạn sẽ gặp trong nhiều ứng dụng. Tài liệu này cố gắng minh hoạ một số trường hợp và mẫu thiết kế về cách triển khai một giải pháp như vậy tuân theo Điều khoản dịch vụ của Nền tảng Google Maps.

Chúng tôi cũng đã viết một tài liệu tham khảo về cách triển khai tính năng Xác thực địa chỉ số lượng lớn dưới dạng thư viện nguồn mở trên GitHub. Hãy xem tài liệu đó để bắt đầu xây dựng nhanh chóng bằng tính năng Xác thực địa chỉ số lượng lớn. Ngoài ra, hãy xem bài viết về các mẫu thiết kế về cách sử dụng thư viện trong nhiều trường hợp.

Các bước tiếp theo

Tải Sách trắng về Cải thiện quy trình thanh toán, giao hàng và hoạt động với địa chỉ đáng tin cậy rồi xem Hội thảo trên web Cải thiện quy trình thanh toán, giao hàng và hoạt động bằng tính năng Xác thực địa chỉ .

Bạn nên đọc thêm:

Người đóng góp

Google duy trì bài viết này. Những cộng tác viên sau đây ban đầu đã viết bài đăng này.
Các tác giả chính:

Henrik Valve | Kỹ sư giải pháp
Thomas Anglaret | Kỹ sư giải pháp
Sarthak Ganguly | Kỹ sư giải pháp