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ì:
- Nó chạy đầu tiên, trước khi bất kỳ WebView nào được mở.
- Các SDK quảng cáo native, thường mang lại phần lớn doanh thu, đọc bộ nhớ native.
- Trên iOS, nó có thể được phối hợp với lời nhắc App Tracking Transparency.
Ư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:
- 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à__gppnế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. - Ẩ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.
- 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ử
- Cài đặt mới: một lời nhắc đồng ý, không phải hai.
- Từ chối tất cả trong CMP native, mở WebView, kiểm tra các yêu cầu quảng cáo: chuỗi phải phản ánh việc từ chối.
- Đổi sự đồng ý trong cài đặt native, quay lại một WebView đang mở: trang phải thấy quyết định mới.
- Nếu có cài đặt web, đổi sự đồng ý ở đó và xác nhận các khóa native được cập nhật.
- Tắt hẳn rồi khởi chạy lại ứng dụng: các quyết định được giữ ở cả hai bên.
- Kiểm thử trên cả iOS và Android, vì bộ nhớ WebView hoạt động khác nhau trên mỗi nền tảng.
Những điểm chính
- Sự đồng ý native và WebView nằm trong các kho riêng biệt và không đồng bộ theo mặc định.
- Chọn một nguồn sự thật duy nhất; với hầu hết ứng dụng đó là CMP native.
- Cung cấp sự đồng ý native cho nội dung web qua
__tcfapihoặc__gppđược chèn vào và ẩn banner web. - Dùng cầu nối JavaScript để gửi các thay đổi từ web về bộ nhớ native.
- Kiểm tra rằng các yêu cầu quảng cáo từ WebView mang cùng chuỗi đồng ý như các yêu cầu native.