Xây dựng logic xác thực

Tài liệu này mô tả quy trình xây dựng hệ thống kiểm tra địa chỉ để xử lý nhiều phản hồi từ API xác thực địa chỉ. Hướng dẫn này trình bày cách xây dựng logic để sử dụng chính xác phản hồi, tìm hiểu các tín hiệu khác từ API, cũng như thời điểm và cách thức nhắc khách hàng cung cấp thêm thông tin.

Nhìn chung, phản hồi của API xác định những cách sau đây mà hệ thống của bạn sẽ xử lý một địa chỉ:

  • Khắc phục – địa chỉ này có chất lượng thấp. Bạn nên nhắc cung cấp thêm thông tin.
  • Xác nhận – địa chỉ có chất lượng cao, nhưng có thay đổi so với địa chỉ nhập. Bạn có thể nhắc xác nhận.
  • Chấp nhận – địa chỉ có chất lượng cao. Bạn có thể chấp nhận địa chỉ được cung cấp.

Mục đích chính

Tài liệu này giúp bạn sửa đổi hệ thống để phân tích tốt nhất phản hồi của API và xác định các hành động tiếp theo cần thực hiện với địa chỉ đã cung cấp. Mã giả sau đây minh hoạ một luồng khả thi.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

Logic chính xác sẽ tuỳ thuộc vào tình huống của bạn. Hãy xem bài viết Hướng dẫn triển khai để biết thêm thông tin chi tiết. Bạn cũng có thể sử dụng cách triển khai nguồn mở của chúng tôi cho logic này, nằm trong Thư viện thành phần mở rộng.

Tổng quan về quy trình công việc

Bảng dưới đây tóm tắt hai hành động đối với hệ thống của bạn:

  1. Quy trình làm việc sẽ sử dụng dựa trên hành vi khắc phục, xác nhận, chấp nhận.
  2. Tín hiệu đầu tiên cần kiểm tra trong câu trả lời. Các tín hiệu được mô tả ở đây bắt nguồn từ thuộc tính verdictkhông phải là tín hiệu duy nhất cần kiểm tra, nhưng cung cấp chỉ báo ban đầu về chất lượng của địa chỉ. Mỗi loại hành vi tương ứng với một phần trong tài liệu này mô tả thêm các tín hiệu mà bạn có thể cũng cần tìm hiểu.
Hành vi hệ thống của bạn
Sửa địa chỉ

Phản hồi của verdict cho biết thông tin quan trọng bị thiếu mà bạn cần cung cấp. Địa chỉ mà API xác thực địa chỉ trả về có thể không đảm bảo chất lượng.

Quy trình làm việc

  1. Hãy kiểm tra các thành phần của địa chỉ nếu cần.
  2. Nhắc khách hàng khắc phục các vấn đề về địa chỉ.
  3. Yêu cầu xác thực địa chỉ đã cập nhật.
  4. (Không bắt buộc) Gửi yêu cầu đến điểm cuối phản hồi cho API. Xem bài viết Xử lý các địa chỉ đã cập nhật.
  5. Tiếp tục với địa chỉ.

Tín hiệu kết quả

Áp dụng bất kỳ trường hợp nào sau đây:

Xác nhận địa chỉ

Phản hồi từ verdict cho biết địa chỉ có thể gửi, nhưng đã thay đổi dữ liệu đầu vào ban đầu: suy luận dữ liệu đã sửa lỗi chính tả hoặc dữ liệu có thể được xác nhận.

Quy trình làm việc

  1. Cần khắc phục:
    1. Hãy kiểm tra các thành phần của địa chỉ nếu cần.
    2. Yêu cầu xác thực địa chỉ đã cập nhật.
    3. (Không bắt buộc) Gửi yêu cầu đến điểm cuối phản hồi cho API. Xem bài viết Xử lý các địa chỉ đã cập nhật.
    4. Tiếp tục với địa chỉ.
  2. Không cần chỉnh sửa:
    1. (Không bắt buộc) Gửi yêu cầu đến điểm cuối phản hồi cho API. Xem bài viết Xử lý các địa chỉ đã cập nhật.
    2. Tiếp tục với địa chỉ.

Tín hiệu kết quả

Tất cả các trường hợp sau đây áp dụng:

  • validationGranularity chứa ROUTE trở lên. Xem các giá trị về độ chi tiết.
  • addressCompletetrue.
  • Trường hasInferredComponentstrue HOẶC trường hasReplacedComponentstrue.
Chấp nhận địa chỉ

Phản hồi của API xác thực địa chỉ cho biết một địa chỉ có chất lượng rất tốt.

Quy trình làm việc

Tiếp tục với địa chỉ được trả về.

Tín hiệu kết quả

Tất cả các trường hợp sau đây áp dụng:

  • validationGranularity chứa PREMISE trở lên. Xem các giá trị về độ chi tiết.
  • addressCompletetrue.
  • Không có thành phần được thay thế hoặc suy luận.

Hướng dẫn triển khai

Khi thiết kế cách hệ thống phản hồi các tín hiệu từ API xác thực địa chỉ, những đề xuất sau có thể giúp bạn xây dựng một mô hình phản hồi hiệu quả hơn. Tuy nhiên, đây chỉ là các đề xuất, vì vậy, hãy lưu ý rằng cách triển khai của bạn phải phù hợp với mô hình kinh doanh của bạn.

Hướng dẫn Chi tiết
Mức độ rủi ro

Hãy xem xét mức độ chấp nhận đối với trường hợp của bạn khi cân bằng giữa việc nhắc chỉnh sửa và chấp nhận địa chỉ đã nhập.

API xác thực địa chỉ sẽ trả về nhiều tín hiệu mà bạn có thể kết hợp với mức độ rủi ro của mình để tối ưu hoá quy trình xác thực.

Ví dụ: nếu một địa chỉ có số nhà chưa được xác nhận, bạn vẫn có thể chấp nhận địa chỉ đó. Mặt khác, nếu hoạt động kinh doanh của bạn yêu cầu địa chỉ chính xác hơn, thì bạn có thể nhắc người dùng. Để xem ví dụ có thể thuộc một trong hai danh mục này, hãy xem mục Số nhà chưa được xác nhận ở Hoa Kỳ trong bài viết Chấp nhận địa chỉ – ví dụ.

Chấp nhận địa chỉ

Bạn nên cho phép hệ thống chấp nhận mục nhập ban đầu nếu khách hàng không phản hồi lời nhắc.

Trong những trường hợp này, có thể khách hàng đã nhập một địa chỉ không có trong hệ thống, chẳng hạn như cho công trình mới.

Gửi ý kiến phản hồi

Khi gửi lại yêu cầu xác thực địa chỉ, bạn cũng có thể gửi yêu cầu đến điểm cuối provideValidationFeedback.

Thông tin này cho Google biết cách bạn xử lý phản hồi cuối cùng. Xem bài viết Xử lý các địa chỉ đã cập nhật.

Sửa địa chỉ

Sửa địa chỉ khi kết quả chỉ rõ rằng địa chỉ đó không thể giao hàng. Khi đó, hệ thống có thể nhắc khách hàng cung cấp thông tin cần thiết, sau đó bạn phát hành lại quy trình công việc để nhận được địa chỉ giao hàng.

Khắc phục tín hiệu

API xác thực địa chỉ cung cấp một số tín hiệu để cho bạn biết liệu một địa chỉ có cần được khắc phục hay không.

1. Độ chi tiết của quy trình xác thực và các thành phần còn thiếu

Hai tín hiệu này là dấu hiệu tốt nhất cho thấy một địa chỉ có vấn đề:

  • Bất cứ khi nào trường validationGranularityOTHER, hệ thống của bạn nên điều tra các tín hiệu thành phần địa chỉ để tìm hiểu thêm về vị trí xảy ra lỗi và cách khắc phục.
  • Bất cứ khi nào đối tượng address đã xử lý sau xử lý trả về trường missingComponentTypes, hệ thống của bạn nên kiểm tra thành phần đó. Các thành phần bị thiếu cũng khiến địa chỉ không đầy đủ và không thể phân phối được.

2. Các tín hiệu khác

API xác thực địa chỉ cũng cung cấp các tín hiệu khác để giúp chẩn đoán các vấn đề cụ thể:

Thành phần đáng ngờ Khi enum cấp xác nhận của một thành phần là UNCOMFIRMED_AND_SUSPICIOUS, có thể thành phần đó không chính xác.
Thành phần chưa được giải quyết unresolvedToken là một phần của dữ liệu đầu vào không được nhận dạng là một phần hợp lệ của một địa chỉ.

3. Tín hiệu địa chỉ ở Hoa Kỳ

Một số trường chỉ áp dụng cho các địa chỉ ở Hoa Kỳ cung cấp một tín hiệu hữu ích rằng địa chỉ đó không thể giao được và cần được khắc phục. Đối với một địa chỉ cần sửa, bạn sẽ thấy những thông tin sau:

dpvConfirmation N, D hoặc trống.

Để biết thông tin chi tiết về dpvConfirmation, hãy xem bài viết Xử lý các địa chỉ tại Hoa Kỳ.

Ví dụ về cách chỉnh sửa địa chỉ

Xác nhận địa chỉ

Bạn xác nhận một địa chỉ khi kết quả cho biết rằng API Xác thực địa chỉ đã suy ra hoặc thực hiện thay đổi đối với các thành phần nhằm tạo ra một địa chỉ đã được xác thực. Trong những trường hợp này, bạn có một địa chỉ có thể giao hàng, nhưng muốn chắc chắn hơn rằng địa chỉ nhận được là địa chỉ mà khách hàng mong muốn.

Để cung cấp cho khách hàng câu lệnh chính xác, logic của bạn sẽ xác định các thành phần bị dịch vụ gắn cờ để xác định thao tác hoặc gắn cờ API đã áp dụng cho thành phần, chẳng hạn như inferred, replaced hoặc spellCorrected. Xem AddressComponent trong tài liệu tham khảo.

Xác nhận tín hiệu

API xác thực địa chỉ cung cấp một số tín hiệu để cho bạn biết liệu một địa chỉ có cần được xác nhận hay không.

1. Chi tiết về kết quả xác thực

Bạn có thể chấp nhận validationGranularity có giá trị ROUTE trở lên. Tuy nhiên, PREMISE hoặc SUBPREMISE sẽ cung cấp tín hiệu mạnh hơn về khả năng gửi.

2. Các tín hiệu khác

Khi quyết định xác nhận mục nhập địa chỉ với khách hàng, kết quả cũng cung cấp những thông tin sau để xác định thành phần cần điều tra:

Dữ liệu suy luận Khi trường hasInferredComponentstrue, bạn biết rằng API đã điền thông tin mà API này thu thập từ các thành phần địa chỉ khác.
Dữ liệu được thay thế Khi trường hasReplacedComponentstrue, API sẽ thay thế dữ liệu đã nhập bằng dữ liệu mà API cho là hợp lệ.

3. Tín hiệu địa chỉ ở Hoa Kỳ

Một số trường chỉ áp dụng cho địa chỉ ở Hoa Kỳ cho biết rằng logic của bạn phải xác nhận thông tin chi tiết với khách hàng. Áp dụng một trong hai trường hợp sau:

dpvConfirmation S

Để biết thông tin chi tiết về dpvConfirmation, hãy xem bài viết Xử lý các địa chỉ ở Hoa Kỳ.

Nội dung phản hồi của địa chỉ Chứa trường missingComponentType có giá trị subpremise.

Xác nhận ví dụ về địa chỉ

Chấp nhận địa chỉ

Bạn chấp nhận địa chỉ khi kết quả đưa ra mức độ tin cậy cao rằng địa chỉ đó có thể giao được và có thể sử dụng mà không cần khách hàng phải tương tác thêm trong quá trình tiếp theo.

Chấp nhận tín hiệu

API xác thực địa chỉ cung cấp một số tín hiệu để cho bạn biết liệu một địa chỉ có cần được xác nhận hay không.

1. Chi tiết về kết quả xác thực

Bạn có thể chấp nhận validationGranularity có giá trị PREMISE trở lên, nhưng trong một số trường hợp, ROUTE vẫn cho biết địa chỉ có thể chuyển phát.

2. Các tín hiệu khác

Kết quả cho một địa chỉ chất lượng cao cũng phải cung cấp những thông tin sau:

  • Chưa có dữ liệu nào được thay thế. Trong trường hợp này là hasReplacedComponents: FALSE.
  • Không có thành phần nào được dự đoán. Trong trường hợp này là hasInferredComponents: FALSE.

3. Tín hiệu địa chỉ ở Hoa Kỳ

Một số trường chỉ áp dụng cho địa chỉ ở Hoa Kỳ cho biết một địa chỉ chất lượng cao có thể được gửi đến. Để có một địa chỉ được chấp nhận ở Hoa Kỳ, bạn nên xem những thông tin sau:

dpvConfirmation Y

Để biết thông tin chi tiết về dpvConfirmation, hãy xem bài viết Xử lý các địa chỉ ở Hoa Kỳ.

Chấp nhận ví dụ về địa chỉ