Sự đồng ý trong WebView: Giữ đồng bộ giữa native và web

Vấn đề hai banner

Nhiều ứng dụng một phần là native, một phần là web. Một trò chơi hiển thị cửa hàng, tin tức hoặc trang trợ giúp trong WebView; một ứng dụng tiện ích hiển thị các bài viết từ trang web của nó; một ứng dụng lai bọc phần lớn giao diện trong nội dung web. Mỗi bên có cơ chế đồng ý riêng: ứng dụng native dùng CMP hoặc SDK trong ứng dụng, còn các trang web tải một CMP web. Nếu chúng không được kết nối, người dùng bị hỏi hai lần, lựa chọn ở nơi này bị bỏ qua ở nơi kia, và các yêu cầu quảng cáo từ bên trong WebView được gửi đi với tín hiệu sai.

Hướng dẫn này trình bày cách làm cho sự đồng ý ở native và web khớp nhau, để người dùng chỉ trả lời một lần và mọi yêu cầu quảng cáo đều mang cùng một quyết định.

Mỗi bên lưu sự đồng ý ở đâu

Native

IAB TCF quy định cách một CMP trong ứng dụng lưu sự đồng ý: trong NSUserDefaults trên iOS và SharedPreferences trên Android, dùng các khóa chuẩn như IABTCF_TCString, IABTCF_gdprApplies và IABTCF_PurposeConsents. Các SDK quảng cáo đọc trực tiếp các khóa này. IAB GPP định nghĩa các khóa tương tự với tiền tố IABGPP_, chẳng hạn IABGPP_HDR_GppString.

Web

Một CMP web thường lưu quyết định của nó trong cookie bên thứ nhất hoặc bộ nhớ cục bộ cho tên miền của trang, và cung cấp qua các hàm JavaScript __tcfapi và __gpp. Các thẻ quảng cáo trong trang gọi các hàm đó, chứ không phải bộ nhớ native.

Khoảng trống

WebView có không gian cookie và lưu trữ riêng, tách biệt với trình duyệt của thiết bị và tách biệt với tùy chọn native của ứng dụng. Trên iOS, một WKWebView dùng kho dữ liệu không bền vững sẽ quên mọi thứ khi đóng lại. Không có gì chảy giữa hai bên trừ khi bạn tự xây dựng.

Chọn một nguồn sự thật duy nhất

Quyết định đầu tiên là bên nào sở hữu sự đồng ý. Với hầu hết ứng dụng, câu trả lời là CMP native, vì:

Ưu tiên web có thể hợp lý với các ứng dụng lai mà toàn bộ giao diện là nội dung web, nhưng khi đó bạn phải ghi quyết định ngược về bộ nhớ native cho các SDK native.

Chuyển sự đồng ý native vào WebView

Khi native là nguồn sự thật, WebView cần thấy cùng quyết định đó. Các mẫu phổ biến:

  1. Chèn một bản triển khai __tcfapi. Trước khi các tập lệnh của trang chạy, hãy chèn một tập lệnh nhỏ định nghĩa __tcfapi (và __gpp nếu cần) và trả lời các lệnh gọi bằng TC string cùng các giá trị đọc từ bộ nhớ native. Các thẻ quảng cáo trong trang khi đó nhận quyết định native qua API chuẩn.
  2. Ẩn banner web. Cấu hình CMP web để luôn ẩn khi trang được tải bên trong ứng dụng của bạn, ví dụ dựa trên một tham số truy vấn hoặc một token user agent tùy chỉnh mà bạn kiểm soát. Nếu không, người dùng sẽ thấy banner thứ hai.
  3. Truyền chuỗi khi tải. Một số CMP web có thể nhận một chuỗi đồng ý sẵn có khi khởi tạo và áp dụng nó. Hãy kiểm tra tài liệu của CMP web của bạn để biết các phương thức được hỗ trợ.

Dù dùng mẫu nào, hãy đảm bảo các giá trị được chèn cập nhật khi người dùng đổi lựa chọn trong màn hình cài đặt native, chứ không chỉ ở lần khởi chạy ứng dụng kế tiếp.

Chuyển sự đồng ý từ web về native

Nếu người dùng có thể đổi sự đồng ý bên trong WebView, chẳng hạn qua trang cài đặt quyền riêng tư, ứng dụng phải biết điều đó. Hãy dùng cầu nối JavaScript: một trình xử lý thông điệp trên iOS hoặc một giao diện JavaScript trên Android. Phía web lắng nghe bằng __tcfapi('addEventListener', ...) và gửi chuỗi mới cho mã native, nơi ghi các khóa chuẩn. Hãy xác thực dữ liệu đầu vào từ WebView trước khi ghi; chỉ chấp nhận thông điệp từ nội dung của chính bạn.

Quảng cáo bên trong WebView

Quảng cáo được hiển thị trong WebView là quảng cáo web. Chúng đọc sự đồng ý từ trang, không phải từ bộ nhớ native, trừ khi SDK quảng cáo cung cấp cách liên kết hai bên. Chẳng hạn, Mobile Ads SDK của Google cung cấp một API để đăng ký WebView để quảng cáo bên trong có thể dùng các tín hiệu từ ứng dụng; hãy kiểm tra tài liệu hiện hành cho SDK của bạn. Dù thế nào, hãy xác nhận bằng một lần kiểm thử rằng các yêu cầu quảng cáo từ WebView mang cùng chuỗi TC hoặc GPP như các yêu cầu quảng cáo native.

Danh sách kiểm thử

Những điểm chính

← Blog Đọc tất cả →