Tài liệu này xác định một bản đặc tả kỹ thuật (được gọi là "Chế độ đồng ý bổ sung") chỉ dành cho việc sử dụng cùng với Khuôn khổ về tính minh bạch và sự đồng ý (TCF) phiên bản 2.0 của IAB để làm cầu nối cho các nhà cung cấp chưa được đăng ký trong Danh sách nhà cung cấp toàn cầu của IAB ở Châu Âu (GVL). Bản đặc tả kỹ thuật này cho phép nhà xuất bản, Nhà cung cấp dịch vụ quản lý sự đồng ý (CMP) và các đối tác thu thập và tạo sự đồng ý bổ sung — cùng với việc triển khai TCF phiên bản 2.0 — cho các công ty chưa được đăng ký trên Danh sách nhà cung cấp toàn cầu của IAB Châu Âu nhưng thuộc danh sách Nhà cung cấp công nghệ quảng cáo của Google (ATP).
Thông tin có liên quan
- Chuỗi về sự minh bạch và sự đồng ý phiên bản 2.0 với Định dạng danh sách nhà cung cấp toàn cầu
- API nền tảng quản lý sự đồng ý phiên bản 2.0
- Chính sách Khuôn khổ về tính minh bạch và sự đồng ý của IAB Châu Âu
- Chính sách về sự đồng ý của người dùng ở Liên minh Châu Âu của Google
Các thành phần của Chế độ đồng ý bổ sung
Trong "Chế độ đồng ý bổ sung", chúng tôi hỗ trợ cả hai thành phần sau:
- Chuỗi về sự minh bạch và sự đồng ý (chuỗi TC) theo sự xác định của bản đặc tả kỹ thuật TCF phiên bản 2.0 của IAB, chứa dữ liệu về tính minh bạch và sự đồng ý được thiết lập cho các nhà cung cấp trong Danh sách nhà cung cấp toàn cầu (GVL) của IAB. VÀ,
- Chuỗi
addtl_consent
ngắn gọn (chuỗi sự đồng ý bổ sung), chứa danh sách các Nhà cung cấp công nghệ quảng cáo của Google chưa được đăng ký với IAB.
Bản đặc tả kỹ thuật này xác định những điều sau:
- Định dạng chuỗi sự đồng ý bổ sung
- Phần mở rộng của API CMP cho TCF phiên bản 2.0 để hỗ trợ chuỗi sự đồng ý bổ sung
- Cách lưu trữ chuỗi sự đồng ý bổ sung
- Cách chuyển chuỗi sự đồng ý bổ sung qua chuỗi quảng cáo kỹ thuật số
Định dạng chuỗi "Sự đồng ý bổ sung" (AC)
Thông tin nào được lưu trữ trong chuỗi AC?
Một chuỗi AC chứa ba thành phần sau:
- Phần 1: Số phiên bản đặc tả kỹ thuật, chẳng hạn như "1"
- Phần 2: Một ký hiệu phân tách "~"
- Phần 3: Danh sách mã Nhà cung cấp công nghệ quảng cáo (ATP) của Google được người dùng đồng ý (phân tách bằng dấu chấm). Ví dụ: "1.35.41.101"
Ví dụ: chuỗi AC 1~1.35.41.101
có nghĩa là người dùng đã đồng ý với các ATP có mã 1
, 35
, 41
và 101
và chuỗi được tạo bằng cách sử dụng định dạng xác định trong bản đặc tả kỹ thuật phiên bản 1.0.
Ai nên tạo một chuỗi AC?
Chỉ CMP đã đăng ký TCF của IAB Châu Âu mới có thể tạo chuỗi AC bằng cách sử dụng mã CMP được chỉ định của CMP này theo Chính sách của IAB. Nhà cung cấp hoặc bất kỳ nhà cung cấp dịch vụ bên thứ ba nào khác không được tự tạo chuỗi AC.
Danh sách ATP của Google sẽ được phát hành ở đâu?
Google sẽ công bố danh sách các nhà cung cấp công nghệ quảng cáo chưa đăng ký với IAB và mã của các nhà cung cấp này tại địa chỉ sau:
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
Khi nào nên tạo một chuỗi AC?
Trong mọi trường hợp, chuỗi AC chỉ có thể được tạo khi nhà xuất bản tuân thủ Chính sách về sự đồng ý của người dùng ở Liên minh Châu Âu của Google. Đặc biệt, không được tạo chuỗi AC trước khi người dùng có sự đồng ý phù hợp về mặt pháp lý đối với: 1) việc sử dụng cookie hoặc dữ liệu lưu trữ cục bộ khác khi cần có sự cho phép của pháp luật; và 2) việc ATP thu thập, chia sẻ và sử dụng dữ liệu cá nhân để cá nhân hoá quảng cáo theo Chính sách về sự đồng ý của người dùng ở Liên minh Châu Âu của Google.
Chuỗi AC chỉ được tạo để làm chuỗi bổ sung cho chuỗi TC chứ không được thay thế cho chuỗi TC. Google sẽ không xử lý yêu cầu và sẽ loại bỏ chuỗi AC trong một yêu cầu mà Google nhận được nếu yêu cầu đó không có chuỗi TC.
Các CMP triển khai bản đặc tả kỹ thuật này phải đảm bảo rằng chuỗi AC mà họ tạo chỉ chứa các mã trong tệp ATP của Google đã phát hành (nghĩa là các nhà cung cấp không nằm trong GVL). Khi nhận được chuỗi TC, Google sẽ kiểm tra phiên bản GVL được liệt kê trong chuỗi TC đó. Nếu phiên bản GVL đó có dữ liệu đăng ký cho một nhà cung cấp, thì các mục kiểm soát chuỗi TC cho nhà cung cấp đó và bất kỳ mục nhập chuỗi AC nào cho nhà cung cấp đó sẽ bị bỏ qua. Trong trường hợp này, Google giữ quyền xoá các mục nhập “trùng lặp” như vậy khỏi chuỗi AC và chuyển chuỗi AC đã sửa đổi đó cùng với chuỗi TC. Các nhà cung cấp không phải Google không được sửa đổi chuỗi AC.
Phần mở rộng cho API CMP
Chúng tôi đề xuất mở rộng API JavaScript của CMP về TCF phiên bản 2.0 hiện có để cho phép trả về chuỗi AC. Cụ thể hơn, chúng tôi đề xuất mở rộng các đối tượng JSON TCData và InAppTCData để trả về dữ liệu này.
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
}
Cần lưu trữ chuỗi AC như thế nào?
Web
Cơ chế lưu trữ tùy thuộc vào sự lựa chọn của CMP.
Trong ứng dụng
Cần sử dụng NSUserDefaults (iOS) hoặc SharedPreferences (Android) để lưu trữ chuỗi AC bằng một SDK của CMP. Cách này cho phép:
- Nhà cung cấp dễ dàng truy cập chuỗi AC
- Chuỗi AC vẫn tồn tại qua nhiều phiên sử dụng ứng dụng
- Chuỗi AC có thể chuyển qua lại giữa các CMP để nhà xuất bản linh hoạt trong việc trao đổi một SDK của CMP cho một SDK khác
Nếu một nhà xuất bản chọn xoá một SDK của CMP khỏi ứng dụng của mình, thì nhà xuất bản đó có trách nhiệm xoá các giá trị AddtlConsent
cho người dùng để nhà cung cấp không tiếp tục sử dụng chuỗi AC đi kèm.
Khoá lưu trữ và tra cứu trong NSUserDefaults và SharedPreferences | Giá trị |
IABTCF_AddtlConsent |
Chuỗi: Chuỗi AC với phiên bản đặc tả kỹ thuật và mã nhà cung cấp công nghệ quảng cáo được đồng ý |
Cách chuyển chuỗi AC qua chuỗi quảng cáo kỹ thuật số
Yêu cầu giá thầu
Chúng tôi sẽ sử dụng lại ConsentedProvidersSettings
để đưa các nhà cung cấp không thuộc danh sách GVL xuống dưới.
- Trong proto phần mở rộng OpenRTB
- Phiên bản Protobuf cũ
message ConsentedProvidersSettings {
// Set of IDs corresponding to providers for whom the publisher has told
// Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local
// storage where legally required; and 2) the collection, sharing, and use of personal data for
// personalization of ads by an ATP in accordance with Google’s EU User Consent Policy.
// A mapping of provider ID to provider name is posted at providers.csv.
repeated int64 consented_providers = 2 [packed = true];
}
// Information about the providers for whom the publisher has told Google
// that its EEA users have consented to the use of their personal data for
// ads personalization in accordance with Google's EU User Consent Policy.
// This field will only be populated when regs_gdpr is true.
optional ConsentedProvidersSettings consented_providers_settings = 42;
Dịch vụ dựa trên URL
Khi một mẫu quảng cáo hiển thị, mẫu quảng cáo đó có thể chứa một số pixel trong thẻ <img>
. Ví dụ: <img src="http://vendor-a.com/key1=val1&key2=val2">
sẽ gửi một yêu cầu HTTP GET
từ trình duyệt đến miền của nhà cung cấp.
Vì pixel nằm trong thẻ <img>
không có khả năng thực thi JavaScript, nên không thể sử dụng API của CMP để lấy chuỗi TC. Tương tự như sự hỗ trợ cho chuỗi TC, chúng tôi cung cấp tham số URL chuẩn và macro trong các URL pixel cần chèn chuỗi AC.
Tham số URL | Macro tương ứng | Phần hiển thị trong URL |
addtl_consent |
ADDTL_CONSENT |
&addtl_consent=${ADDTL_CONSENT} |
Ví dụ 1
Để Nhà cung cấp A nhận được chuỗi AC, URL hình ảnh phải bao gồm một cặp khoá-giá trị với tham số URL và macro &addtl_consent=${ADDTL_CONSENT}
. URL kết quả là:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}
Ví dụ 2
Trong một yêu cầu cho trước, nếu chuỗi AC là: 1~1.35.41.101
Trình gọi hoặc trình kết xuất mẫu quảng cáo thay thế macro trong URL bằng chuỗi AC thực tế để pixel được đặt ban đầu chứa macro được sửa đổi như sau khi thực hiện lệnh gọi đến máy chủ được chỉ định:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101