Hỗ trợ tính năng nhắm mục tiêu theo đối tượng tuỳ chỉnh thông qua Protected Audience API

Lưu ý: Bài viết này đề cập đến các đề xuất thiết kế hiện tại của Hộp cát về quyền riêng tư trên Android và các đề xuất này còn tiếp tục thay đổi. Chúng tôi mong nhận được ý kiến phản hồi và nhận xét của bạn để có thể tiếp tục cải thiện.

Nội dung cập nhật gần đây

• Thêm thông tin về cách lập lịch cập nhật đối tượng tuỳ chỉnh
• Thêm tính năng tích hợp Báo cáo phân bổ với Protected Audience
• Xuất bản lịch trình của các tính năng Protected Audience.
• FLEDGE đổi tên thành Protected Audience API.
• Thêm đề xuất cho tính năng uỷ quyền đối tượng tuỳ chỉnh.
• Xoá yêu cầu k-anonymity đối với URL cập nhật hằng ngày.

Protected Audience đang ở giai đoạn beta và có thể kiểm thử trên các thiết bị công khai!

Nhờ Protected Audience, bạn có thể:

• Quản lý đối tượng tuỳ chỉnh dựa trên các thao tác của người dùng trước.
• Bắt đầu phiên đấu giá trên thiết bị với một người bán duy nhất hoặc tính năng hỗ trợ dàn xếp kiểu thác nước.
• Báo cáo lượt hiển thị sau khi lựa chọn quảng cáo.

Để bắt đầu, hãy đọc Hướng dẫn cho nhà phát triển về Protected Audience. Chúng tôi trân trọng ý kiến phản hồi của bạn trong quá trình tiếp tục phát triển Protected Audience.

Lịch trình

Chúng tôi sẽ phát hành các tính năng mới trong những tháng tới. Ngày phát hành chính xác sẽ khác nhau tuỳ thuộc vào tính năng, đồng thời bảng này cũng sẽ cập nhật các đường liên kết đến tài liệu khi có.

Tính năng	Có trong Bản dùng thử cho nhà phát triển	Có trong bản beta
Báo cáo cấp sự kiện	Q1 2023	Q3 2023
Dàn xếp kiểu thác nước	Q1 2023	Q4 2023
Lọc quảng cáo cài đặt ứng dụng	Q2 2023	Q3 2023
Lọc giới hạn tần suất	Q2 2023	Q3 2023
Truyền quảng cáo theo bối cảnh đến quy trình lựa chọn quảng cáo để lọc	Q2 2023	Q3 2023
Báo cáo lượt tương tác	Q2 2023	Q3 2023
Tham gia uỷ quyền đối tượng tuỳ chỉnh	Q3 2023	Q4 2023
Thanh toán không phải CPM	Q3 2023	Q4 2023
Tích hợp dịch vụ Đặt giá thầu và Phiên đấu giá	Q3 2023	Q4 2023
Báo cáo gỡ lỗi	Q3 2023	Q4 2023
Tích hợp Báo cáo phân bổ	Không áp dụng	Q4 2023
Dàn xếp đặt giá thầu mở	Q4 2023	Q4 2023
Quản lý đơn vị tiền tệ	Q1 2024	Q2 2024
Tích hợp K-anon	Không áp dụng	Q2 2024
Tích hợp báo cáo tổng hợp	Q3 2024	Q4 2024

Tổng quan

Trong quảng cáo trên thiết bị di động, nhà quảng cáo thường phải phân phát quảng cáo đến những người dùng có khả năng quan tâm dựa trên cách họ từng tương tác với ứng dụng của nhà quảng cáo. Ví dụ: nhà phát triển của SportingGoodsApp có thể muốn quảng cáo cho những người dùng đã để lại mặt hàng trong giỏ hàng, bằng cách hiển thị quảng cáo để nhắc người dùng hoàn tất giao dịch mua. Ngành quảng cáo thường mô tả ý tưởng này bằng các thuật ngữ chung như "tái tiếp thị" và "nhắm mục tiêu theo đối tượng tuỳ chỉnh".

Hiện nay, các trường hợp sử dụng này thường được triển khai bằng cách chia sẻ thông tin ngữ cảnh về cách hiển thị quảng cáo (chẳng hạn như tên ứng dụng) và thông tin riêng tư chẳng hạn như danh sách đối tượng có nền tảng công nghệ quảng cáo. Nhờ thông tin này, nhà quảng cáo có thể chọn các quảng cáo phù hợp trên máy chủ của họ.

Protected Audience API trên Android (trước đây là FLEDGE) bao gồm các API sau cho nền tảng công nghệ quảng cáo và nhà quảng cáo nhằm hỗ trợ cho những trường hợp sử dụng thông thường dựa trên hoạt động tương tác theo cách hạn chế chia sẻ cả giá trị nhận dạng trên nhiều ứng dụng cũng như thông tin về hoạt động tương tác với ứng dụng của người dùng với bên thứ ba:

1. Custom Audience API (API Đối tượng tuỳ chỉnh): Đây là trọng tâm của khái niệm trừu tượng "đối tượng tuỳ chỉnh", đại diện cho đối tượng có các ý định thông thường do nhà quảng cáo chỉ định. Thông tin về đối tượng được lưu trữ trên thiết bị và có thể được liên kết với các quảng cáo đề xuất phù hợp cho đối tượng đó và siêu dữ liệu tùy ý (chẳng hạn như tín hiệu đặt giá thầu). Thông tin này có thể được dùng làm cơ sở cho giá thầu của nhà quảng cáo, tính năng lọc và hiển thị quảng cáo.
2. API lựa chọn quảng cáo: API này cung cấp khung điều phối các nền tảng công nghệ quảng cáo quy trình công việc sử dụng tín hiệu trên thiết bị để quyết định "giành chiến thắng" bằng cách xem xét các quảng cáo đề xuất được lưu trữ cục bộ và thực hiện quy trình xử lý bổ sung đối với các quảng cáo đề xuất mà một nền tảng công nghệ quảng cáo quay lại thiết bị.

Biểu đồ quy trình cho thấy quy trình lựa chọn quảng cáo và quản lý đối tượng tuỳ chỉnh trong Hộp cát về quyền riêng tư trên Android.

Lưu ý: Đề xuất thiết kế này tập trung vào hoạt động tương tác của người dùng giữa ứng dụng với ứng dụng trường hợp sử dụng quảng cáo, trong đó ứng dụng có thể đăng ký đối tượng tuỳ chỉnh có thể được cân nhắc hiển thị quảng cáo trong các ứng dụng khác. Trong tương lai, chúng tôi sẽ xem xét thêm thông tin về các trường hợp sử dụng khác, chẳng hạn như khi người dùng tương tác với WebView và trình duyệt trong một ứng dụng web.

Ở cấp độ tổng quát, quá trình tích hợp sẽ hoạt động như sau:

1. SportingGoodsApp muốn nhắc người dùng mua các món hàng trong giỏ hàng nếu họ không hoàn tất giao dịch mua trong vòng 2 ngày. SportingGoodsApp sử dụng Custom Audience API để thêm người dùng vào danh sách đối tượng "có sản phẩm trong giỏ hàng". Nền tảng nêu trên sẽ quản lý và lưu trữ danh sách đối tượng này trên thiết bị để hạn chế việc chia sẻ với bên thứ ba. SportingGoodsApp hợp tác với một nền tảng công nghệ quảng cáo để hiển thị quảng cáo cho người dùng có trong danh sách đối tượng của ứng dụng đó. Nền tảng công nghệ quảng cáo quản lý siêu dữ liệu cho các danh sách đối tượng và cung cấp quảng cáo đề xuất. Những quảng cáo này sẽ được xem xét trong quy trình chọn quảng cáo. Nền tảng này có thể được định cấu hình để định kỳ tìm nạp quảng cáo dựa trên đối tượng đã cập nhật trong nền. Điều này giúp đảm bảo danh sách quảng cáo đề xuất dựa trên đối tượng luôn được cập nhật và không tương quan với các yêu cầu gửi đến máy chủ quảng cáo của bên thứ ba trong cơ hội quảng cáo (tức là những yêu cầu quảng cáo theo bối cảnh).

2. Khi người dùng chơi FrisbeeGame trên cùng một thiết bị, họ có thể nhìn thấy quảng cáo nhắc họ hoàn tất giao dịch mua các món hàng trong giỏ hàng của SportingGoodsApp. Việc này có thể đạt được khi FrisbeeGame (được tích hợp SDK quảng cáo) gọi Ad Selection API (API Lựa chọn quảng cáo) để chọn quảng cáo giành chiến thắng cho người dùng dựa trên danh sách đối tượng bất kỳ mà họ nằm trong đó (trong ví dụ này là đối tượng tuỳ chỉnh "có sản phẩm trong giỏ hàng" do SportingGoodsApp tạo). Quy trình lựa chọn quảng cáo có thể được thiết lập để xem xét các quảng cáo được truy xuất từ máy chủ của nền tảng công nghệ quảng cáo, ngoài các quảng cáo trên thiết bị được liên kết với đối tượng tuỳ chỉnh cũng như các tín hiệu khác trên thiết bị. Quy trình này cũng có thể được tuỳ chỉnh thông qua nền tảng công nghệ quảng cáo và SDK quảng cáo bằng logic đặt giá thầu và tính điểm tuỳ chỉnh để đạt được mục tiêu quảng cáo phù hợp. Với cách tiếp cận này, dữ liệu về mối quan tâm hoặc hoạt động tương tác trong ứng dụng của người dùng sẽ chính là cơ sở cho việc chọn quảng cáo, trong khi vẫn giới hạn việc chia sẻ dữ liệu này với các bên thứ ba.

3. SDK của nền tảng công nghệ quảng cáo hoặc ứng dụng phân phát quảng cáo sẽ hiển thị quảng cáo đã chọn.

4. Nền tảng này sẽ hỗ trợ hoạt động báo cáo về số lượt hiển thị và kết quả chọn quảng cáo. Tính năng báo cáo này bổ sung cho Attribution Reporting API. Các nền tảng công nghệ quảng cáo có thể tuỳ chỉnh dựa trên nhu cầu báo cáo của các nền tảng đó.

Truy cập vào Protected Audience API trên Android

Các nền tảng công nghệ quảng cáo cần đăng ký để truy cập vào Protected Audience API. Hãy xem bài viết Đăng ký tài khoản Hộp cát về quyền riêng tư để biết thêm thông tin.

Quản lý đối tượng tuỳ chỉnh

Đối tượng tuỳ chỉnh

Đối tượng tuỳ chỉnh đại diện cho một nhóm người dùng do nhà quảng cáo xác định dựa trên các ý định hoặc mối quan tâm chung. Ứng dụng hoặc SDK có thể dùng đối tượng tuỳ chỉnh để chỉ ra một đối tượng cụ thể, chẳng hạn như ai đó đã "thêm mặt hàng vào giỏ hàng" hoặc "hoàn tất cấp độ dành cho người mới bắt đầu" trong một trò chơi. Nền tảng này duy trì và lưu trữ thông tin về đối tượng ngay trên thiết bị, đồng thời không cho biết người dùng thuộc đối tượng tuỳ chỉnh nào. Đối tượng tuỳ chỉnh khác với nhóm có cùng mối quan tâm trong Protected Audience của Chrome và không thể dùng chung trên các trang web và ứng dụng. Điều này nhằm hạn chế việc chia sẻ thông tin người dùng.

Ứng dụng của nhà quảng cáo hoặc SDK tích hợp có thể tham gia hoặc rời khỏi một đối tượng tuỳ chỉnh, dựa trên hoạt động tương tác của người dùng trong ứng dụng chẳng hạn.

Siêu dữ liệu về đối tượng tuỳ chỉnh

Mỗi đối tượng tuỳ chỉnh chứa siêu dữ liệu sau:

• Chủ sở hữu: Tên gói của ứng dụng chủ sở hữu. Giá trị này được ngầm đặt thành tên gói của ứng dụng gọi.
• Người mua: Mạng quảng cáo dành cho người mua quản lý các quảng cáo cho đối tượng tuỳ chỉnh này. Người mua cũng đại diện cho bên có thể truy cập vào đối tượng tuỳ chỉnh và tìm nạp thông tin quảng cáo phù hợp. Người mua được chỉ định theo định dạng eTLD+1.
• Tên: Tên hoặc giá trị nhận dạng tuỳ ý của đối tượng tuỳ chỉnh, chẳng hạn như người dùng đã "bỏ giỏ hàng". Ví dụ: thuộc tính này có thể được dùng làm một trong các tiêu chí nhắm mục tiêu trong chiến dịch quảng cáo của nhà quảng cáo, hoặc một chuỗi truy vấn trong URL để tìm nạp mã đặt giá thầu.
• Thời gian kích hoạt và thời gian hết hạn: Những trường này xác định khoảng thời gian khi đối tượng tuỳ chỉnh này có hiệu lực. Nền tảng nêu trên sẽ sử dụng thông tin này để chấm dứt tư cách thành viên của một đối tượng tuỳ chỉnh. Thời gian hết hạn không được vượt quá khoảng thời gian tối đa để giới hạn thời hạn của một đối tượng tuỳ chỉnh.
• URL cập nhật hằng ngày: URL mà nền tảng sử dụng để tìm nạp quảng cáo đề xuất và siêu dữ liệu khác được xác định định kỳ trong các trường "Tín hiệu đặt giá thầu của người dùng" và "Tín hiệu đặt giá thầu đáng tin cậy". Để biết thêm thông tin chi tiết, hãy xem phần trình bày về cách tìm nạp quảng cáo đề xuất cho đối tượng tuỳ chỉnh.
• Tín hiệu đặt giá thầu của người dùng: Các tín hiệu dành riêng cho nền tảng công nghệ quảng cáo đối với bất kỳ hoạt động đặt giá thầu quảng cáo tái tiếp thị nào. Ví dụ về các tín hiệu bao gồm: vị trí thô của người dùng, ngôn ngữ ưu tiên, v.v.
• Dữ liệu đặt giá thầu đáng tin cậy: Các nền tảng công nghệ quảng cáo coi dữ liệu theo thời gian thực là cơ sở cho việc tính điểm và truy xuất quảng cáo. Ví dụ: một quảng cáo có thể hết ngân sách và cần phải dừng phân phát ngay lập tức. Công nghệ quảng cáo có thể xác định điểm cuối URL mà ở đó dữ liệu theo thời gian thực này có thể được tìm nạp và tập hợp khoá cần thiết để thực hiện tính năng tra cứu theo thời gian thực. Máy chủ xử lý yêu cầu này sẽ là máy chủ đáng tin cậy do nền tảng công nghệ quảng cáo quản lý.
• URL logic đặt giá thầu: Là URL mà nền tảng sử dụng để tìm nạp mã đặt giá thầu từ nền tảng bên cầu. Nền tảng nêu trên sẽ thực hiện bước này khi phiên đấu giá quảng cáo được khởi tạo.
• Quảng cáo: Là danh sách các quảng cáo đề xuất cho đối tượng tuỳ chỉnh. Danh sách này bao gồm siêu dữ liệu quảng cáo dành riêng cho nền tảng công nghệ quảng cáo và URL để hiển thị quảng cáo đó. Khi một phiên đấu giá được khởi tạo cho đối tượng tuỳ chỉnh, danh sách siêu dữ liệu quảng cáo sẽ được xem xét. Danh sách quảng cáo này sẽ được làm mới bằng điểm cuối URL cập nhật hằng ngày khi có thể. Do các hạn chế về tài nguyên trên thiết bị di động nên sẽ có giới hạn về số lượng quảng cáo có thể lưu trữ trong một đối tượng tuỳ chỉnh.

Uỷ quyền đối tượng tuỳ chỉnh

Việc định nghĩa và định cấu hình đối tượng tuỳ chỉnh theo cách truyền thống thường dựa vào các công nghệ phía máy chủ, cũng như hoạt động tích hợp do các công nghệ quảng cáo mang lại khi hợp tác với khách hàng, đối tác của đại lý và nhà quảng cáo. Protected Audience API hỗ trợ việc định nghĩa và định cấu hình đối tượng tuỳ chỉnh trong khi vẫn bảo vệ quyền riêng tư của người dùng. Để tham gia một đối tượng tuỳ chỉnh, các công nghệ quảng cáo của Người mua không xuất hiện trên SDK trong các ứng dụng cần phải cộng tác với các công nghệ quảng cáo xuất hiện trên thiết bị, chẳng hạn như các đối tác đo lường trên thiết bị di động (MMP) và nền tảng bên cung (SSP). Protected Audience API hướng đến việc hỗ trợ những SDK này bằng cách cung cấp các giải pháp linh hoạt để quản lý đối tượng tuỳ chỉnh thông qua việc cho phép phương thức gọi trên thiết bị gọi quá trình tạo đối tượng tuỳ chỉnh, thay cho người mua. Quá trình này gọi là uỷ quyền đối tượng tuỳ chỉnh. Hãy làm theo các bước sau để định cấu hình tính năng uỷ quyền đối tượng tuỳ chỉnh:

Tham gia một đối tượng tuỳ chỉnh

Bạn có thể tham gia một đối tượng tuỳ chỉnh theo 2 cách:

joinCustomAudience()

Một ứng dụng hoặc SDK có thể yêu cầu tham gia một đối tượng tuỳ chỉnh bằng cách gọi joinCustomAudience() sau khi tạo thực thể đối tượng CustomAudience với các thông số dự kiến. Dưới đây là ví dụ về đoạn mã minh hoạ:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

Ứng dụng hoặc SDK có thể yêu cầu tham gia một đối tượng tuỳ chỉnh thay mặt cho một công nghệ quảng cáo không xuất hiện trên thiết bị bằng cách gọi fetchAndJoinCustomAudience() với các tham số dự kiến, như trong ví dụ sau:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

Điểm cuối URL do người mua sở hữu sẽ phản hồi bằng một đối tượng JSON CustomAudience trong nội dung phản hồi. Trường người mua và chủ sở hữu của đối tượng tuỳ chỉnh sẽ bị bỏ qua (và được API tự động điền). Ngoài ra, API thực thi việc URL cập nhật hằng ngày khớp với eTLD+1 của người mua.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

API fetchAndJoinCustomAudience() xác định danh tính của người mua từ eTLD+1 của fetchUri. Danh tính của người mua CustomAudience dùng để thực hiện cùng một quy trình kiểm tra đăng ký và uỷ quyền ứng dụng do joinCustomAudience() thực hiện, đồng thời không thể thay đổi bằng phản hồi tìm nạp. Chủ sở hữu CustomAudience là tên gói của ứng dụng gọi. Không có quy trình xác thực nào khác cho fetchUri ngoài bước kiểm tra eTLD+1, cụ thể là không có quy trình kiểm tra k-anon. API fetchAndJoinCustomAudience() gửi yêu cầu HTTP GET đến fetchUri và dự kiến đối tượng JSON sẽ đại diện cho đối tượng tuỳ chỉnh. Các điều kiện ràng buộc bắt buộc, không bắt buộc và giá trị mặc định cho các trường đối tượng tuỳ chỉnh sẽ được áp dụng cho phản hồi. Tìm hiểu về các yêu cầu và giới hạn hiện tại trong Hướng dẫn cho nhà phát triển của chúng tôi.

Bất cứ phản hồi lỗi HTTP nào từ người mua đều khiến fetchAndJoinCustomAudience không thành công. Cụ thể, phản hồi trạng thái HTTP là 429 (Quá nhiều yêu cầu) sẽ chặn các yêu cầu từ ứng dụng hiện tại trong một khoảng thời gian (sẽ được xác định). Lệnh gọi API cũng sẽ không thành công nếu phản hồi từ người mua không đúng định dạng. Lỗi sẽ được báo cáo cho phương thức gọi API chịu trách nhiệm thử lại do các lỗi tạm thời (chẳng hạn như máy chủ không phản hồi) hoặc xử lý các lỗi liên tục (chẳng hạn như lỗi xác thực dữ liệu hoặc các lỗi khác không mang tính tạm thời khi giao tiếp với máy chủ).

Đối tượng CustomAudienceFetchRequest cho phép lệnh gọi API xác định một số thông tin cho Đối tượng tuỳ chỉnh bằng cách sử dụng các thuộc tính không bắt buộc như ví dụ trên. Nếu được thiết lập trong yêu cầu, thì phản hồi của người mua mà nền tảng nhận được sẽ không ghi đè các giá trị này; Protected Audience API sẽ bỏ qua các trường trong phản hồi. Nếu không được thiết lập trong yêu cầu thì các giá trị này phải được thiết lập trong phản hồi, vì đây là các trường bắt buộc để tạo một đối tượng tuỳ chỉnh. Bản trình bày JSON trong nội dung của CustomAudience (được phương thức gọi API xác định một phần) sẽ được đưa vào yêu cầu GET gửi đến fetchUri trong một tiêu đề X-CUSTOM-AUDIENCE-DATA đặc biệt. Giới hạn kích thước của dạng đã chuyển đổi tuần tự của dữ liệu được chỉ định cho Đối tượng tuỳ chỉnh (Custom Audience) là 8KB. Nếu vượt quá kích thước này thì lệnh gọi API fetchAndJoinCustomAudience sẽ không thành công.

Việc không có chế độ kiểm tra k-anon cho phép bạn sử dụng fetchUri để xác minh người mua và cho phép chia sẻ thông tin giữa người mua và SDK. Để tạo điều kiện cho việc xác minh đối tượng tuỳ chỉnh, người mua có thể cung cấp một mã xác minh. SDK trên thiết bị phải bao gồm mã này trong fetchUri để điểm cuối do người mua lưu trữ có thể tìm nạp nội dung của đối tượng tuỳ chỉnh và sử dụng mã xác minh để xác minh rằng thao tác fetchAndJoinCustomAudience() tương ứng với người mua, đồng thời có nguồn gốc từ một đối tác đáng tin cậy trên thiết bị. Để chia sẻ thông tin, người mua có thể đồng ý với phương thức gọi trên thiết bị rằng một số thông tin dùng để tạo đối tượng tuỳ chỉnh sẽ được thêm vào fetchUri dưới dạng tham số truy vấn. Điều này cho phép người mua kiểm tra các lệnh gọi và phát hiện xem công nghệ quảng cáo độc hại có dùng mã thông báo xác thực để tạo một số đối tượng tuỳ chỉnh khác nhau hay không.

Lưu ý về việc định nghĩa và lưu trữ mã xác minh

• Mã xác minh không được Protected Audience API sử dụng cho bất kỳ mục đích nào và là mã không bắt buộc.

  • Người mua có thể sử dụng mã xác minh để xác minh rằng đối tượng đang được tạo là đối tượng đại diện cho họ.
  • Đề xuất Protected Audience API không chỉ định định dạng của mã xác minh và cách người mua chuyển mã xác minh cho phương thức gọi. Ví dụ: mã xác minh có thể được tải sẵn trong SDK của chủ sở hữu hoặc phần phụ trợ, hoặc có thể được SDK của chủ sở hữu truy xuất theo thời gian thực từ máy chủ của người mua.

Rời khỏi một đối tượng tuỳ chỉnh

Chủ sở hữu của một đối tượng tuỳ chỉnh có thể chọn rời khỏi bằng cách gọi leaveCustomAudience(), như mô tả trong đoạn mã minh hoạ dưới đây:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

Lưu ý: API này không có giá trị trả về để ngăn ứng dụng dùng API này để suy ra tư cách thành viên của một người dùng trong đối tượng tuỳ chỉnh.

Để giúp tiết kiệm mức sử dụng bộ nhớ và các tài nguyên khác trên thiết bị, đối tượng tuỳ chỉnh hết hạn sẽ bị xoá khỏi cửa hàng trên thiết bị sau một khoảng thời gian xác định trước. Giá trị mặc định sẽ được xác định. Chủ sở hữu có thể ghi đè giá trị mặc định này.

Quyền kiểm soát của người dùng

• Đề xuất này nhằm giúp người dùng xem được danh sách ứng dụng đã cài đặt đã tạo ít nhất một đối tượng tuỳ chỉnh
• Người dùng có thể xoá các ứng dụng khỏi danh sách này. Thao tác xoá sẽ xoá mọi đối tượng tuỳ chỉnh liên kết với những ứng dụng đó và ngăn những ứng dụng đó tham gia các đối tượng tuỳ chỉnh mới.
• Người dùng có thể đặt lại hoàn toàn Protected Audience API. Khi điều này xảy ra, mọi đối tượng tuỳ chỉnh hiện có trên thiết bị sẽ bị xoá.
• Người dùng có thể chọn hoàn toàn không sử dụng Hộp cát về quyền riêng tư trên Android, bao gồm cả Protected Audience API. Nếu người dùng đã chọn không sử dụng Hộp cát về quyền riêng tư, thì Protected Audience API sẽ âm thầm ngừng hoạt động.

Thiết kế của tính năng này đang trong quá trình thực hiện và thông tin chi tiết sẽ được đưa vào nội dung cập nhật sau này.

Nội dung cập nhật theo lịch

Các giải pháp đã mô tả trước đó yêu cầu SDK ứng dụng hoặc công nghệ quảng cáo gọi phương thức API trong khi ứng dụng chạy trên nền trước và cung cấp đầy đủ thuộc tính của đối tượng tuỳ chỉnh, trực tiếp hoặc uỷ quyền. Tuy nhiên, không phải lúc nào nhà quảng cáo và nhà cung cấp công nghệ quảng cáo cũng có thể xác định đối tượng mà người dùng thuộc về theo thời gian thực khi họ sử dụng ứng dụng.

Để hỗ trợ việc này, công nghệ quảng cáo có thể gọi API scheduleCustomAudienceUpdate(). API này cho phép phương thức gọi chỉ định một độ trễ khi thực hiện lệnh gọi API, do đó kéo dài thêm thời gian để công nghệ quảng cáo phản hồi xử lý các sự kiện ở cấp ứng dụng và xác định sự kiện nào Đối tượng được bảo vệ mà người dùng nên tham gia hoặc bị xoá.

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest chứa thông tin cần thiết để đăng ký một công việc bị trì hoãn để chạy trên nền tảng. Sau khoảng thời gian trễ đã chỉ định, một công việc trong nền sẽ chạy định kỳ và gửi (các) yêu cầu. Chiến lược phát hành đĩa đơn ScheduleCustomAudienceUpdateRequest có thể chứa các thông tin sau:

• UpdateUri: Điểm cuối URI sẽ được gửi lệnh gọi GET để tìm nạp nội dung cập nhật. Danh tính của người mua được suy ra từ eTLD+1 và không cần phải được cung cấp rõ ràng cũng như không thể bị thay đổi bằng phản hồi cập nhật. Hàm GET yêu cầu dự kiến một đối tượng JSON chứa danh sách đối tượng customAudience trong lợi nhuận.
• DelayTime: Thời gian biểu thị độ trễ từ thời điểm thực hiện lệnh gọi API scheduleCustomAudienceUpdate() để lên lịch cập nhật.

Lưu ý: Một lượng nhiễu tuỳ ý sẽ được thêm vào độ trễ và các quy định hạn chế sẽ được đặt trên giá trị tối thiểu và tối đa của độ trễ

• PartialCustomAudience: API này cũng cho phép SDK trên thiết bị gửi danh sách Đối tượng tuỳ chỉnh được tạo một phần. Điều này cho phép SDK trong ứng dụng đóng vai trò kép, từ kiểm soát toàn bộ đến kiểm soát một phần việc quản lý Đối tượng tuỳ chỉnh dựa trên mối quan hệ đối tác với DSP.

  • Điều này cũng giúp API này tương thích với API fetchAndJoinCustomAudience() cho phép chia sẻ thông tin tương tự.

• ShouldReplacePendingUpdates: Boolean xác định xem có bất kỳ sự kiện nào đang chờ xử lý hay không bản cập nhật định kỳ sẽ bị huỷ và thay thế bằng bản cập nhật được nêu chi tiết trong ScheduleCustomAudienceUpdateRequest hiện tại. Nếu bạn đặt giá trị này thành false và có các bản cập nhật được yêu cầu trước đó vẫn đang chờ xử lý cho cùng một người mua trong cùng một ứng dụng, lệnh gọi đến scheduleCustomAudienceUpdate bằng tính năng này ScheduleCustomAudienceUpdateRequest sẽ không thực hiện được. Giá trị mặc định là false.

Quyền cho ứng dụng và quyền kiểm soát

Đề xuất này nhằm cung cấp cho các ứng dụng quyền kiểm soát đối tượng tuỳ chỉnh của chúng:

• Ứng dụng có thể quản lý sự liên kết giữa ứng dụng và đối tượng tuỳ chỉnh.
• Ứng dụng có thể cấp cho nền tảng công nghệ quảng cáo bên thứ ba các quyền quản lý đối tượng tuỳ chỉnh thay cho ứng dụng.

Tính năng này đang trong quá trình thiết kế và thông tin chi tiết sẽ được đưa vào nội dung cập nhật sau này.

Kiểm soát nền tảng công nghệ quảng cáo

Đề xuất này nêu ra các cách giúp công nghệ quảng cáo kiểm soát các đối tượng tuỳ chỉnh của chúng:

• Công nghệ quảng cáo đăng ký bằng Hộp cát về quyền riêng tư và cung cấp một miền eTLD+1 khớp với tất cả các URL cho một đối tượng tuỳ chỉnh.
• Công nghệ quảng cáo có thể hợp tác với ứng dụng hoặc SDK để cung cấp mã xác minh dùng để xác minh việc tạo đối tượng tuỳ chỉnh. Khi quy trình này được ủy quyền cho một đối tác, việc tạo đối tượng tuỳ chỉnh có thể được định cấu hình để yêu cầu công nghệ quảng cáo xác nhận.
• Một công nghệ quảng cáo có thể chọn tắt các lệnh gọi joinCustomAudience thay mặt cho chúng và chỉ cho phép API fetchAndJoinCustomAudience bật tất cả các đối tượng tuỳ chỉnh của lệnh gọi. Bạn có thể cập nhật quyền kiểm soát trong quá trình đăng ký Hộp cát về quyền riêng tư. Lưu ý rằng quyền kiểm soát này cho phép mọi công nghệ quảng cáo hoặc không cho phép công nghệ quảng cáo nào. Do các hạn chế của nền tảng, bạn không thể cấp quyền uỷ quyền cho từng công nghệ quảng cáo.

Phản hồi về siêu dữ liệu và quảng cáo đề xuất

Quảng cáo đề xuất và siêu dữ liệu được trả về từ nền tảng bên mua phải bao gồm các trường sau đây:

• Siêu dữ liệu: Siêu dữ liệu quảng cáo dành riêng cho công nghệ quảng cáo, phía bên mua. Ví dụ: siêu dữ liệu này có thể bao gồm thông tin về chiến dịch quảng cáo và tiêu chí nhắm mục tiêu, chẳng hạn như vị trí và ngôn ngữ.
• URL hiển thị: Điểm cuối để hiển thị mẫu quảng cáo.
• Bộ lọc: Thông tin không bắt buộc cần thiết để Protected Audience API lọc quảng cáo dựa vào dữ liệu trên thiết bị. Để biết thêm thông tin chi tiết, hãy đọc phần logic lọc của bên mua.

Quy trình lựa chọn quảng cáo

Đề xuất này nhằm cải thiện quyền riêng tư bằng cách giới thiệu Ad Selection API. API này sẽ thực thi quy trình đấu giá cho các nền tảng công nghệ quảng cáo.

Ngày nay, các nền tảng công nghệ quảng cáo thường chỉ tiến hành đặt giá thầu và chọn quảng cáo trên các máy chủ của chúng. Với đề xuất này, đối tượng tuỳ chỉnh và các tín hiệu nhạy cảm khác của người dùng, chẳng hạn như thông tin sẵn có về gói đã cài đặt, sẽ chỉ truy cập được qua Ad Selection API (API Lựa chọn quảng cáo). Ngoài ra, đối với trường hợp sử dụng tái tiếp thị, các quảng cáo đề xuất sẽ được tìm nạp bên ngoài (nghĩa là không ở trong ngữ cảnh hiển thị quảng cáo). Các nền tảng công nghệ quảng cáo sẽ cần chuẩn bị để triển khai và thực thi một số phần của phiên đấu giá hiện tại cũng như logic lựa chọn quảng cáo trên thiết bị. Các nền tảng công nghệ quảng cáo có thể cân nhắc những thay đổi sau đây đối với quy trình lựa chọn quảng cáo:

• Khi không có sẵn thông tin về gói đã cài đặt trên máy chủ, các nền tảng công nghệ quảng cáo nên gửi trả nhiều quảng cáo theo ngữ cảnh về thiết bị và gọi quy trình lựa chọn quảng cáo để hỗ trợ tính năng lọc dựa trên lượt cài đặt ứng dụng nhằm tối đa hoá cơ hội hiển thị quảng cáo phù hợp.
• Vì quảng cáo tiếp thị lại được tìm nạp bên ngoài, nên các mô hình đặt giá thầu hiện tại có thể cần được cập nhật. Các nền tảng công nghệ quảng cáo nên tạo các mô hình phụ đặt giá thầu (việc triển khai có thể dựa trên mẫu được gọi là mô hình hai toà tháp) có thể hoạt động riêng biệt trên các tính năng quảng cáo và tín hiệu bối cảnh, đồng thời kết hợp đầu ra của mô hình phụ trên thiết bị để dự đoán giá thầu. Điều này có thể được hưởng lợi từ cả phiên đấu giá phía máy chủ và phiên đấu giá cho cơ hội quảng cáo nhất định.

Với cách tiếp cận này, dữ liệu về hoạt động tương tác của người dùng với ứng dụng sẽ làm cơ sở cho việc chọn quảng cáo, trong khi vẫn giới hạn hoạt động chia sẻ dữ liệu với bên thứ ba.

Biểu đồ quy trình hiển thị cách bắt đầu quy trình lựa chọn quảng cáo.

Quy trình lựa chọn quảng cáo này sắp xếp hoạt động thực thi trên thiết bị của mã JavaScript do công nghệ quảng cáo cung cấp dựa trên trình tự sau đây:

1. Thực thi logic đặt giá thầu của bên mua
2. Xử lý và lọc quảng cáo bên mua
3. Thực thi logic quyết định của bên bán

Đối với các lựa chọn quảng cáo liên quan đến đối tượng tuỳ chỉnh, nền tảng sẽ tìm nạp mã JavaScript do bên mua cung cấp dựa trên điểm cuối URL công khai do siêu dữ liệu "URL logic đặt giá thầu" của đối tượng tuỳ chỉnh xác định. Hệ thống cũng sẽ chuyển điểm cuối URL của mã quyết định bên bán làm đầu vào để bắt đầu quy trình lựa chọn quảng cáo.

Thiết kế của những lựa chọn quảng cáo không liên quan đến đối tượng tuỳ chỉnh đang trong quy trình thiết kế chủ động.

Bắt đầu quy trình lựa chọn quảng cáo

Khi một ứng dụng cần hiển thị quảng cáo, SDK nền tảng công nghệ quảng cáo có thể bắt đầu quy trình chọn quảng cáo bằng cách gọi phương thức selectAds() sau khi tạo bản sao đối tượng AdSelectionConfig với các tham số dự kiến:

• Người bán: Giá trị nhận dạng cho nền tảng quảng cáo bên bán, theo định dạng eTLD+1
• URL logic quyết định: Khi bắt đầu một phiên đấu giá quảng cáo, nền tảng sẽ sử dụng URL này để tìm nạp mã JavaScript từ nền tảng bên bán để tính điểm quảng cáo giành chiến thắng.
• Người mua đối tượng tuỳ chỉnh: Danh sách các nền tảng bên mua có nhu cầu đấu giá dựa trên đối tượng tuỳ chỉnh, theo định dạng eTLD+1.
• Tín hiệu lựa chọn quảng cáo: Thông tin về phiên đấu giá (kích thước quảng cáo, định dạng quảng cáo, v.v.).
• Tín hiệu người bán: Các tín hiệu dành riêng cho nền tảng bên cung.
• URL tín hiệu tính điểm đáng tin cậy: Điểm cuối URL của tín hiệu đáng tin cậy bên bán mà từ đó thông tin cụ thể về mẫu quảng cáo theo thời gian thực có thể được tìm nạp.
• Tín hiệu từ mỗi người mua: Các bên có nhu cầu tham gia có thể sử dụng thông số này để cung cấp đầu vào cho phiên đấu giá. Ví dụ: thông số này có thể bao gồm thông tin toàn diện về ngữ cảnh hữu ích cho việc xác định giá thầu.

Đoạn mã minh họa sau đây hiển thị SDK nền tảng công nghệ quảng cáo bắt đầu quy trình lựa chọn quảng cáo bằng cách xác định AdSelectionConfig trước, sau đó gọi selectAds để nhận Quảng cáo thắng cuộc:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

Logic đặt giá thầu bên mua

Logic đặt giá thầu thường do các nền tảng bên mua cung cấp. Mục đích của mã này là xác định giá thầu cho quảng cáo đề xuất. Có thể áp dụng thêm logic kinh doanh để xác định kết quả.

Nền tảng này sẽ sử dụng siêu dữ liệu "URL logic đặt giá thầu" của đối tượng tuỳ chỉnh để tìm nạp mã JavaScript. Mã này sẽ bao gồm chữ ký hàm dưới đây:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

Phương thức generateBid() trả về giá thầu được tính toán. Nền tảng này sẽ gọi hàm này theo trình tự cho tất cả các quảng cáo (theo bối cảnh hoặc tiếp thị lại). Nếu có nhiều nhà cung cấp logic đặt giá thầu, hệ thống sẽ không đảm bảo trình tự thực thi trong số các nhà cung cấp.

Hàm này yêu cầu các thông số sau:

• Quảng cáo: Quảng cáo đang được cân nhắc bởi mã đặt giá thầu bên mua. Đây sẽ là quảng cáo từ một đối tượng tuỳ chỉnh đủ điều kiện
• Tín hiệu đấu giá: Tín hiệu dành riêng cho nền tảng bên bán.
• Tín hiệu từ mỗi người mua: Các bên có nhu cầu tham gia có thể sử dụng thông số này để cung cấp đầu vào cho phiên đấu giá. Ví dụ: thông số này có thể bao gồm thông tin toàn diện về ngữ cảnh hữu ích cho việc xác định giá thầu.
• Tín hiệu đặt giá thầu đáng tin cậy: Các nền tảng công nghệ quảng cáo coi dữ liệu theo thời gian thực là cơ sở cho việc tính điểm và truy xuất quảng cáo. Ví dụ: một quảng cáo có thể hết ngân sách và cần phải dừng phân phát ngay lập tức. Công nghệ quảng cáo có thể xác định điểm cuối URL mà ở đó dữ liệu theo thời gian thực này có thể được tìm nạp và tập hợp khoá cần thiết để thực hiện tính năng tra cứu theo thời gian thực. Máy chủ được quản lý của nền tảng công nghệ quảng cáo phân phát yêu cầu này sẽ là một máy chủ đáng tin cậy do nền tảng công nghệ quảng cáo quản lý.
• Tín hiệu theo bối cảnh: Tín hiệu này có thể bao gồm dấu thời gian thô hoặc thông tin vị trí ước chừng, hay chi phí mỗi lượt nhấp vào quảng cáo.
• Tín hiệu người dùng: Tín hiệu này có thể bao gồm các thông tin, chẳng hạn như thông tin sẵn có về gói đã cài đặt.

Chi phí quảng cáo

Ngoài giá thầu, các nền tảng bên mua có thể trả về chi phí mỗi lượt nhấp như một phần của generateBid(). Ví dụ:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

Nếu quảng cáo này giành chiến thắng, adCost sẽ được làm tròn một cách ngẫu nhiên lên 8 bit để đảm bảo quyền riêng tư. Sau đó, giá trị làm tròn của adCost được chuyển vào tham số contextual_signals trong reportWin trong quá trình báo cáo lượt hiển thị.

Logic lọc của bên mua

Các nền tảng bên mua có thể lọc quảng cáo dựa trên tín hiệu bổ sung trên thiết bị có sẵn trong giai đoạn lựa chọn quảng cáo. Ví dụ: các nền tảng công nghệ quảng cáo có thể triển khai các tính năng giới hạn tần suất tại đây. Nếu có nhiều nhà cung cấp tính năng lọc, thì hệ thống sẽ không đảm bảo trình tự thực thi giữa các nhà cung cấp đó.

Logic lọc của bên mua có thể được triển khai như một phần của logic đặt giá thầu bằng cách trả về giá trị giá thầu của 0 cho một quảng cáo nhất định.

Ngoài ra, các nền tảng bên mua có thể ra tín hiệu rằng một quảng cáo nhất định sẽ được lọc dựa trên các tín hiệu bổ sung trên thiết bị có sẵn cho Protected Audience và sẽ vẫn ở trên thiết bị. Khi chúng tôi củng cố các thiết kế của logic lọc bổ sung, các nền tảng bên mua sẽ tuân theo cấu trúc tương tự này để ra tín hiệu rằng quá trình lọc sẽ xảy ra.

Logic tính điểm của bên bán

Logic tính điểm thường do nền tảng bên bán cung cấp. Mục đích của mã là xác định quảng cáo giành chiến thắng dựa trên đầu ra của logic đặt giá thầu. Có thể áp dụng thêm logic kinh doanh để xác định kết quả. Nếu có nhiều nhà cung cấp logic quyết định, hệ thống sẽ không đảm bảo trình tự thực thi trong số các nhà cung cấp đó. Nền tảng này sẽ sử dụng thông số đầu vào "URL logic quyết định" của API selectAds() để tìm nạp mã JavaScript. Mã này sẽ bao gồm chữ ký hàm dưới đây:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

Hàm này yêu cầu các thông số sau:

• Quảng cáo: Quảng cáo đang được đánh giá; kết quả của hàm generateBid().
• Giá thầu: Đầu ra về giá thầu của hàm generateBid().
• Cấu hình đấu giá: Thông số đầu vào cho phương thức selectAds().
• Tín hiệu tính điểm đáng tin cậy: Các nền tảng công nghệ quảng cáo coi dữ liệu theo thời gian thực là cơ sở cho việc tính điểm và lọc quảng cáo. Ví dụ: nhà xuất bản quảng cáo có thể chặn một chiến dịch quảng cáo hiển thị quảng cáo trong ứng dụng. Dữ liệu này được tìm nạp từ thông số url tín hiệu tính điểm đáng tin cậy của cấu hình phiên đấu giá. Máy chủ phân phát yêu cầu này phải là máy chủ đáng tin cậy do công nghệ quảng cáo quản lý.
• Tín hiệu theo ngữ cảnh: Tín hiệu này có thể bao gồm dấu thời gian thô hoặc thông tin vị trí ước chừng.
• Tín hiệu người dùng: Tín hiệu này có thể bao gồm những thông tin như cửa hàng ứng dụng bắt đầu quy trình cài đặt ứng dụng.
• Tín hiệu đối tượng tuỳ chỉnh: Nếu quảng cáo đang được tính điểm bắt nguồn từ một đối tượng tuỳ chỉnh trên thiết bị, quảng cáo này sẽ chứa thông tin chẳng hạn như trình đọc và tên của đối tượng tuỳ chỉnh đó.

Thời gian chạy mã lựa chọn quảng cáo

Trong đề xuất, hệ thống sẽ tìm nạp mã đấu giá do nền tảng công nghệ quảng cáo cung cấp từ các điểm cuối URL có thể định cấu hình và thực thi trên thiết bị. Do các hạn chế về tài nguyên trên thiết bị di động, mã đấu giá phải tuân theo nguyên tắc sau đây:

• Mã sẽ hoàn tất quy trình thực thi trong khoảng thời gian xác định sẵn. Giới hạn này sẽ áp dụng nhất quán cho tất cả các mạng quảng cáo của người mua. Thông tin chi tiết về giới hạn này sẽ được chia sẻ trong nội dung cập nhật sau này.
• Mã phải độc lập và không chứa bất kỳ phần nào phụ thuộc bên ngoài.

Vì mã đấu giá, chẳng hạn như logic đặt giá thầu có thể cần quyền truy cập vào dữ liệu riêng tư của người dùng, chẳng hạn như các nguồn cài đặt ứng dụng, nên thời gian chạy sẽ không cung cấp quyền truy cập vào mạng hoặc bộ nhớ.

Ngôn ngữ lập trình

Mã đấu giá do nền tảng công nghệ quảng cáo cung cấp phải được viết bằng ngôn ngữ JavaScript. Chẳng hạn, điều này sẽ cho phép các nền tảng công nghệ quảng cáo chia sẻ mã đặt giá thầu trên các nền tảng hỗ trợ Hộp cát về quyền riêng tư.

Hiển thị quảng cáo có hiệu quả cao

Quảng cáo có điểm số cao nhất được xem là quảng cáo giành chiến thắng trong phiên đấu giá. Trong đề xuất ban đầu này, quảng cáo giành chiến thắng được chuyển vào SDK để hiển thị.

Mục đích của kế hoạch này là phát triển giải pháp nhằm đảm bảo rằng ứng dụng hoặc SDK không xác định được thông tin về gói thành viên của người dùng trong đối tượng tuỳ chỉnh hoặc nhật ký tương tác của người dùng với ứng dụng thông qua thông tin về quảng cáo thắng cuộc (tương tự như đề xuất về khung bảo vệ của Chrome).

Báo cáo sự kiện và lượt hiển thị

Lưu ý: Có những khác biệt nhỏ trong API Báo cáo JS giữa phiên đấu giá trên thiết bị và phiên đấu giá chạy thông qua dịch vụ Đặt giá thầu và Đấu giá (B&A). Để biết thông tin cụ thể về báo cáo B&A, bạn có thể tham khảo tài liệu về B&A.

Sau khi quảng cáo được hiển thị, hệ thống có thể báo cáo lượt hiển thị thắng cuộc ngược trở lại cho nền tảng bên bán và nền tảng bên mua tham gia. Điều này cho phép người mua và người bán thêm thông tin từ phiên đấu giá (chẳng hạn như giá thầu hoặc tên đối tượng tuỳ chỉnh) vào báo cáo lượt hiển thị thắng cuộc. Ngoài ra, nền tảng bên bán và nền tảng bên mua thắng cuộc đủ điều kiện để nhận báo cáo bổ sung ở cấp sự kiện về quảng cáo thắng cuộc. Do đó, bạn có thể bao gồm thông tin về phiên đấu giá (giá thầu, tên đối tượng tuỳ chỉnh, v.v.) cùng với số lượt nhấp, lượt xem và các sự kiện quảng cáo khác. Nền tảng gọi logic báo cáo theo thứ tự sau:

1. Báo cáo bên bán.
2. Báo cáo bên mua.

Điều này giúp nền tảng bên mua và bên bán gửi thông tin quan trọng trên thiết bị về máy chủ để hỗ trợ các tính năng như lập ngân sách theo thời gian thực, cập nhật mô hình đặt giá thầu và quy trình thanh toán chính xác. Tính năng hỗ trợ báo cáo lượt hiển thị này bổ sung cho Attribution Reporting API.

Có 2 bước cần thiết để hỗ trợ báo cáo sự kiện: JavaScript bên bán và bên mua cần đăng ký sự kiện nào nên nhận được báo cáo sự kiện và bên bán chịu trách nhiệm về thông tin báo cáo ở cấp sự kiện.

Protected Audience cung cấp cơ chế đăng ký các sự kiện trong tương lai liên quan đến một phiên đấu giá thắng cuộc bằng cách đăng ký beacon. Trong hàm JavaScript reportResult() của người bán, nền tảng bên bán có thể đăng ký beacon bằng cách sử dụng hàm registerAdBeacon() của nền tảng đó. Tương tự, các nền tảng bên mua có thể gọi phương thức registerAdBeacon() từ hàm JavaScript reportWin().

registerAdBeacon(beacons)

Đầu vào:

• event_key: Chuỗi cho biết loại tương tác cần đăng ký. URL này được dùng làm khoá để tra cứu điểm cuối mà nền tảng sẽ ping khi báo cáo kết quả phiên đấu giá.
• reporting_url: URL do nền tảng công nghệ quảng cáo sở hữu để xử lý sự kiện.

Khoá sự kiện là các giá trị nhận dạng kiểu chuỗi thuộc sở hữu của SDK bên bán chịu trách nhiệm báo cáo kết quả của phiên đấu giá. Để thực hiện lệnh gọi lại, công nghệ quảng cáo sẽ đăng ký beacon bằng các khoá khớp với khoá mà bên bán sử dụng khi báo cáo sự kiện. Các khoá này không cần phải là k-anonymous, mặc dù có giới hạn về số lượng và độ dài cho các khoá có thể được đăng ký cho một đối tượng tuỳ chỉnh nhất định. Nếu reportEvent() được gọi, các nền tảng bên bán đã chạy phiên đấu giá sẽ luôn đủ điều kiện để nhận các báo cáo sự kiện này. Chỉ nền tảng bên mua giành chiến thắng mới đủ điều kiện nhận các báo cáo này.

Lưu ý: Đề xuất này gọi tính năng báo cáo ở cấp sự kiện. Thiết kế này sẽ phát triển thành cơ chế báo cáo tổng hợp trong tương lai.

Báo cáo bên bán

Nền tảng sẽ gọi hàm JavaScript reportResult() trong mã do bên cung cung cấp, được tải xuống từ tham số URL logic quyết định của người bán cho API selectAds():

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Đầu ra: Một đối tượng JSON chứa

• Trạng thái: 0 nếu thành công, mọi giá trị khác nếu không thành công.
• URL báo cáo: Nền tảng gọi URL này do hàm trả về.
• Tín hiệu cho người mua: Một đối tượng JSON được truyền đến hàm reportWin của người mua.

Bên cung có thể mã hoá các tín hiệu phù hợp trong URL báo cáo để giúp họ thu thập thêm thông tin chi tiết cho phiên đấu giá và quảng cáo giành chiến thắng. Chẳng hạn, có thể bao gồm các tín hiệu dưới đây:

• URL hiển thị quảng cáo
• Số tiền giá thầu giành chiến thắng
• Tên ứng dụng
• Giá trị nhận dạng truy vấn
• Tín hiệu cho người mua: Để hỗ trợ hoạt động chia sẻ dữ liệu giữa bên cung và bên cầu, nền tảng sẽ truyền giá trị trả về này dưới dạng tham số đầu vào sang mã báo cáo bên cầu.

Báo cáo bên mua

Nền tảng sẽ gọi hàm JavaScript reportWin() trong mã do bên cầu cung cấp. Mã này được tải xuống từ siêu dữ liệu URL logic đặt giá thầu của đối tượng tuỳ chỉnh liên kết với phiên đấu giá.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

Đầu vào:

• auction_signals và per_buyer_signals được tìm nạp từ AuctionConfig. Bất kỳ thông tin nào mà nền tảng bên mua cần chuyển vào URL báo cáo đều có thể bắt nguồn từ dữ liệu này.
• signals_for_buyer là kết quả của reportResult ở bên bán. Điều này mang lại cho nền tảng bên bán cơ hội chia sẻ dữ liệu với nền tảng bên mua cho mục đích báo cáo.
• contextual_signals chứa các thông tin như tên ứng dụng và custom_audience_signals chứa thông tin về đối tượng tuỳ chỉnh. Các thông tin khác có thể được thêm trong tương lai.

Đầu ra:

• Trạng thái: 0 nếu thành công, mọi giá trị khác nếu không thành công.
• URL báo cáo: Nền tảng gọi URL này do hàm trả về.

Báo cáo sự kiện

Bạn chỉ có thể báo cáo sự kiện sau khi quá trình báo cáo lượt hiển thị cho phiên đấu giá đã hoàn tất. SDK bên bán chịu trách nhiệm báo cáo mọi sự kiện. Nền tảng này sẽ hiển thị một API để lấy ReportEventRequest chỉ định phiên đấu giá đã chạy gần đây, khoá sự kiện được báo cáo, dữ liệu liên kết với khoá đó, liệu báo cáo nên được gửi đến người mua hay người bán (hoặc cả hai) và một sự kiện đầu vào không bắt buộc cho các sự kiện quảng cáo. Ứng dụng xác định khoá sự kiện và hoạt động thu thập dữ liệu để báo cáo.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

Đầu vào:

• ad_selection_id cần phải là AdSelectionId của phiên đấu giá đã chạy gần đây được truy xuất từ AdSelectionOutcome.
• event_key là một chuỗi do bên bán xác định, mô tả sự kiện tương tác.
• event_data là một chuỗi đại diện cho dữ liệu liên kết với event_key
• reporting_destinations là một tập hợp mặt nạ bit sử dụng cờ do nền tảng cung cấp. Đó có thể là một trong hai cờ FLAG_REPORTING_DESTINATION_SELLER hoặc FLAG_REPORTING_DESTINATION_BUYER hoặc cả hai.
• input_event (không bắt buộc) được dùng để tích hợp với Attribution Reporting API. Đó có thể là một đối tượng InputEvent (đối với sự kiện nhấp chuột) hoặc giá trị rỗng (đối với sự kiện xem). Hãy xem bài viết Tích hợp Attribution Reporting API để biết thêm thông tin chi tiết về tham số này.

Sau khi SDK bên bán gọi reportEvent và tuỳ thuộc vào cờ reporting_destinations, nền tảng sẽ tìm cách so khớp event_key với các khoá mà người mua và người bán đã đăng ký trong các hàm JavaScript reportWin và reportResult của họ. Nếu khớp, nền tảng sẽ POST (đăng) event_data vào reporting_url liên quan. Nội dung yêu cầu này thuộc loại văn bản thuần tuý với phần nội dung là event_data. Yêu cầu này được thực hiện với nỗ lực tối đa và sẽ tự động không thực hiện được trong trường hợp xảy ra lỗi mạng, phản hồi lỗi máy chủ hoặc trường hợp không tìm thấy khoá nào khớp.

Tích hợp Attribution Reporting API

Để hỗ trợ những người mua tham gia vào phiên đấu giá Protected Audience, chúng tôi hiện cung cấp chức năng trên nhiều API trên Protected Audience API và Attribution Reporting API (ARA). Chức năng này cho phép các công nghệ quảng cáo đánh giá hiệu suất phân bổ trên nhiều chiến thuật tái tiếp thị. Nhờ đó, chúng có thể hiểu được những loại đối tượng nào mang lại ROI cao nhất.

Thông qua việc tích hợp trên nhiều API này, các công nghệ quảng cáo có thể:

• Tạo một sơ đồ khoá-giá trị của URI cần dùng cho cả việc 1) báo cáo lượt tương tác và 2) đăng ký nguồn.
• Đưa dữ liệu phiên đấu giá từ phiên đấu giá trong Protected Audience vào liên kết khoá phía nguồn để báo cáo tóm tắt tổng hợp (sử dụng Attribution Reporting API). Hãy xem bài viết đề xuất thiết kế ARA để biết thêm thông tin.

Khi người dùng xem hoặc nhấp vào một quảng cáo:

• URL dùng để báo cáo các lượt tương tác với sự kiện đó bằng Protected Audience sẽ cung cấp dữ liệu cần thiết cho người mua. Dữ liệu này sẽ được dùng cho việc đăng ký một lượt xem hoặc lượt nhấp làm nguồn đủ điều kiện thông qua Attribution Reporting API.
• Công nghệ quảng cáo có thể chọn truyền CustomAudience (hoặc các thông tin bối cảnh liên quan khác về quảng cáo, chẳng hạn như vị trí đặt quảng cáo hoặc thời lượng xem) thông qua URL đó để siêu dữ liệu này có thể truyền xuống các báo cáo tóm tắt khi công nghệ quảng cáo đang xem xét hiệu suất chiến dịch tổng hợp.

Bật tính năng đăng ký nguồn

reportEvent() sẽ chấp nhận một tham số không bắt buộc mới là InputEvent. Những người mua chiến thắng đăng ký beacon quảng cáo có thể chọn báo cáo reportEvent nào được đăng ký bằng Attribution Reporting API làm nguồn đã đăng ký. Tiêu đề của yêu cầu Attribution-Reporting-Eligible sẽ được thêm vào tất cả các yêu cầu báo cáo sự kiện được gửi từ reportEvent(). Mọi phản hồi có tiêu đề ARA thích hợp sẽ được phân tích cú pháp theo cách tương tự như mọi phản hồi đăng ký nguồn ARA thông thường khác. Hãy xem thông tin giải thích về Attribution Reporting API để biết cách đăng ký một URL nguồn.

Vì ARA trên Android hỗ trợ các sự kiện xem và nhấp chuột, nên InputEvents được dùng để phân biệt giữa 2 loại. Tương tự như trong quy trình đăng ký nguồn ARA, API reportEvent() sẽ diễn giải InputEvent đã được nền tảng xác minh là một sự kiện nhấp chuột. Nếu InputEvent bị thiếu, rỗng hoặc không hợp lệ, thì việc đăng ký nguồn sẽ được coi là một khung hiển thị.

Xin lưu ý rằng eventData sau phiên đấu giá có thể chứa thông tin nhạy cảm. Vì vậy, nền tảng sẽ bỏ eventData trong các yêu cầu đăng ký nguồn được chuyển hướng.

Ví dụ về báo cáo lượt tương tác và lượt chuyển đổi

Trong ví dụ này, chúng ta sẽ xem xét điều này từ góc độ người mua muốn liên kết dữ liệu từ phiên đấu giá, quảng cáo được hiển thị và ứng dụng chuyển đổi với nhau.

Trong quy trình công việc này, người mua phối hợp với người bán để gửi một mã nhận dạng duy nhất vào phiên đấu giá. Trong phiên đấu giá, người mua gửi mã nhận dạng duy nhất này cùng với dữ liệu phiên đấu giá. Trong thời gian hiển thị và chuyển đổi, dữ liệu từ quảng cáo được hiển thị cũng được gửi với cùng một mã nhận dạng duy nhất. Sau đó, mã nhận dạng duy nhất có thể được dùng để liên kết các báo cáo này với nhau.

Quy trình công việc: Trước khi phiên đấu giá bắt đầu, người mua gửi một mã nhận dạng duy nhất cho người bán trong quá trình phản hồi giá thầu bằng tuỳ chọn đặt giá thầu theo thời gian thực ("RTB") có lập trình. Mã nhận dạng có thể được đặt ở dạng một biến như auctionId. Mã nhận dạng được truyền vào dưới dạng perBuyerSignals trong auctionConfig và có trong logic đặt giá thầu của người mua.

1. Trong quá trình thực thi reportWin, người mua có thể đăng ký một beacon quảng cáo để được kích hoạt trong thời gian hiển thị quảng cáo và cho các sự kiện tương tác cụ thể (registerAdBeacon()). Để liên kết các tín hiệu đấu giá cho một sự kiện quảng cáo, hãy đặt auctionId làm tham số truy vấn của URL beacon.
2. Trong thời gian hiển thị quảng cáo, các beacon mà bạn đã đăng ký trong thời gian đấu giá có thể được kích hoạt hoặc nâng cao bằng dữ liệu ở cấp sự kiện. Người bán phải kích hoạt reportEvent() và truyền dữ liệu cấp sự kiện. Nền tảng sẽ ping URL beacon quảng cáo đã đăng ký của người mua tương quan với reportEvent() đã được kích hoạt.
3. Người mua sẽ đăng ký quảng cáo với Attribution Reporting API bằng cách phản hồi các yêu cầu beacon quảng cáo có tiêu đề Attribution-Reporting-Register-Source. Để liên kết các tín hiệu đấu giá cho một sự kiện chuyển đổi, hãy đặt auctionId trong URL nguồn Đăng ký.

Sau quy trình trên, người mua sẽ có báo cáo phiên đấu giá, báo cáo lượt tương tác và báo cáo lượt chuyển đổi. Các báo cáo này có thể tương quan bằng cách sử dụng mã nhận dạng duy nhất có thể dùng để liên kết với nhau.

Quy trình công việc tương tự sẽ áp dụng cho người bán nếu cần quyền truy cập vào dữ liệu phân bổ và người bán cũng có thể sử dụng một mã nhận dạng duy nhất để gửi bằng registerAdBeacon(). Lệnh gọi reportEvent() chứa một thuộc tính đích có thể được dùng để gửi báo cáo cho cả người mua và người bán.

Máy chủ đáng tin cậy do nền tảng công nghệ quảng cáo quản lý

Logic chọn quảng cáo hiện nay yêu cầu thông tin theo thời gian thực, chẳng hạn như trạng thái cạn kiệt ngân sách để xác định xem có nên chọn đề xuất quảng cáo cho phiên đấu giá không. Cả nền tảng bên mua và bên bán đều có thể lấy thông tin này từ máy chủ mà chúng vận hành. Để giảm thiểu sự rò rỉ thông tin nhạy cảm qua các máy chủ này, đề xuất sẽ gọi các hạn chế sau:

• Hành vi của những máy chủ này, được mô tả sau trong phần này, sẽ không làm rò rỉ thông tin của người dùng.
• Các máy chủ sẽ không tạo hồ sơ biệt danh dựa trên dữ liệu mà máy chủ nhìn thấy, nghĩa là dữ liệu cần phải "đáng tin cậy".

Bên mua: Sau khi bên mua bắt đầu logic đặt giá thầu bên mua, nền tảng sẽ thực hiện tìm nạp HTTP dữ liệu đặt giá thầu đáng tin cậy từ máy chủ đáng tin cậy. URL này được tạo bằng cách thêm URL và khoá có trong siêu dữ liệu Tín hiệu đặt giá thầu đáng tin cậy của đối tượng tuỳ chỉnh đang được xử lý. Hoạt động tìm nạp này chỉ được thực hiện khi xử lý quảng cáo từ đối tượng tuỳ chỉnh trên thiết bị. Ở giai đoạn này, bên mua có thể thực thi ngân sách, kiểm tra trạng thái tạm dừng/huỷ tạm dừng của chiến dịch, thực hiện nhắm mục tiêu, v.v.

Dưới đây là URL mẫu để tìm nạp dữ liệu đặt giá thầu đáng tin cậy, dựa trên siêu dữ liệu tín hiệu đặt giá thầu đáng tin cậy của đối tượng tuỳ chỉnh:

https://www.kv-server.example/getvalues?keys=key1,key2

Phản hồi từ máy chủ phải là đối tượng JSON có khoá là key1, key2, v.v. và có các giá trị được cung cấp cho hàm đặt giá thầu của bên mua.

Bên bán: Tương tự như quy trình dành cho bên mua ở trên, bên bán nên tìm nạp thông tin về mẫu quảng cáo được cân nhắc trong phiên đấu giá. Ví dụ: một nhà xuất bản có thể muốn thực thi rằng không hiển thị một số mẫu quảng cáo nhất định dựa trên những mối lo ngại về an toàn thương hiệu. Thông tin này có thể được tìm nạp và cung cấp cho logic đấu giá của bên bán. Tương tự như tra cứu máy chủ đáng tin cậy của bên mua, hãy bán quá trình tra cứu máy chủ đáng tin cậy bên cũng diễn ra bằng cách sử dụng tìm nạp HTTP. URL này được tạo bằng cách thêm URL tín hiệu tính điểm đáng tin cậy với URL hiển thị của mẫu quảng cáo mà dữ liệu cần để được tìm nạp.

Dưới đây là URL mẫu để tìm nạp thông tin về mẫu quảng cáo được cân nhắc trong phiên đấu giá, dựa trên URL hiển thị mẫu quảng cáo:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

Phản hồi từ máy chủ phải là đối tượng JSON có khoá là URL hiển thị được gửi trong yêu cầu.

Những máy chủ này hoạt động theo cách đáng tin cậy để mang lại các lợi ích về bảo mật và quyền riêng tư:

• Giá trị trả về của máy chủ cho từng khoá có thể được tin cậy để chỉ dựa trên khoá đó.
• Máy chủ không thực hiện ghi nhật ký ở cấp sự kiện.
• Máy chủ không có tác dụng phụ nào dựa trên những yêu cầu này.

Là một cơ chế tạm thời, người bán và người mua có thể tìm nạp các tín hiệu đặt giá thầu này từ mọi máy chủ, bao gồm cả máy chủ mà họ đang tự vận hành. Tuy nhiên, trong phiên bản phát hành, yêu cầu sẽ chỉ được gửi cho một máy chủ dạng khoá-giá trị đán g tin cậy.

Người mua và người bán có thể sử dụng một máy chủ dạng khoá-giá trị chung, đáng tin cậy cho các nền tảng tương thích với Hộp cát về quyền riêng tư trên Android và cho web.