Trang này được dịch bởi Cloud Translation API.

Tích hợp, tối ưu hoá dịch vụ Đặt giá thầu và Phiên đấu giá

Đề xuất thiết kế Dịch vụ Đặt giá thầu và Phiên đấu giá cho Android nêu chi tiết luồng thực thi và luồng dữ liệu của các phiên đấu giá đang chạy trên Android bằng cách dùng máy chủ Đặt giá thầu và Phiên đấu giá đáng tin cậy. Để đảm bảo chỉ các API bảo đảm quyền riêng tư và máy chủ đáng tin cậy mới được xử lý dữ liệu đang truyền, dữ liệu sẽ được mã hoá giữa ứng dụng và máy chủ bằng tính năng Mã hoá khoá công khai kết hợp hai chiều.

Hình minh hoạ luồng Protected Audience. Ba cột thể hiện cách dữ liệu di chuyển giữa các thiết bị, dịch vụ không tin cậy của người bán và một môi trường thực thi đáng tin cậy. — Quy trình đấu giá Protected Audience.

Để chạy phiên đấu giá như đã nêu chi tiết trước đó, công nghệ quảng cáo của người bán trên thiết bị phải thực hiện các bước sau:

Thu thập và mã hoá dữ liệu cho phiên đấu giá phía máy chủ
Gửi yêu cầu tới một Dịch vụ không tin cậy của người bán
Nhận phản hồi từ một Dịch vụ không tin cậy của người bán
Giải mã phản hồi của phiên đấu giá trong Protected Audience và nhận kết quả phiên đấu giá

Protected Audience sẽ giới thiệu 2 API mới để hỗ trợ chạy các phiên đấu giá phía máy chủ:

API getAdSelectionData thu thập dữ liệu cho phiên đấu giá phía máy chủ và tạo ra tải trọng được mã hoá chứa dữ liệu phiên đấu giá. Máy chủ Đặt giá thầu và Phiên đấu giá sử dụng tải trọng này để chạy một phiên đấu giá, tạo ra và trả về kết quả phiên đấu giá.
Các ứng dụng sử dụng công nghệ quảng cáo trên thiết bị có thể gọi API persistAdSelectionResult để giải mã kết quả do phiên đấu giá phía máy chủ tạo ra và nhận URL hiển thị quảng cáo giành chiến thắng.

Công nghệ quảng cáo của người bán trên thiết bị cần tích hợp và xây dựng các yếu tố sau để chạy một phiên đấu giá:

Thu thập và mã hoá dữ liệu của Người bán có phiên đấu giá phía máy chủ : Công nghệ quảng cáo phải gọi API getAdSelectionData để lấy tải trọng được mã hoá.
Gửi yêu cầu đến Dịch vụ không tin cậy của người bán: Một yêu cầu HTTP POST hoặc PUT chứa tải trọng được mã hoá do API getAdSelectionData tạo ra đối với dữ liệu và dịch vụ không tin cậy của người bán theo yêu cầu của dịch vụ không tin cậy của người bán nhằm tạo ra kết quả theo bối cảnh.
Nhận phản hồi từ dịch vụ không tin cậy của người bán: Phản hồi từ dịch vụ không tin cậy của người bán sẽ chứa kết quả phiên đấu giá trong Protected Audience và kết quả phiên đấu giá theo bối cảnh.
Giải mã phản hồi của phiên đấu giá trong Protected Audience và nhận kết quả của phiên đấu giá đó: Để giải mã kết quả phiên đấu giá trong Protected Audience, công nghệ quảng cáo của người bán phải gọi API persistAdSelectionResult. Kết quả do persistAdSelectionResult tạo ra sẽ giúp các công nghệ quảng cáo xác định liệu quảng cáo theo bối cảnh hay quảng cáo Protected Audience giành chiến thắng trong phiên đấu giá và URI của quảng cáo Protected Audience giành chiến thắng (nếu có).

Các tính năng được hỗ trợ cho phiên đấu giá phía máy chủ

Chúng tôi muốn hỗ trợ tất cả các tính năng hiện có cho phiên đấu giá trên thiết bị. Tiến trình hỗ trợ những tính năng này trong phiên đấu giá phía máy chủ diễn ra như sau:

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

Chạy phiên đấu giá phía máy chủ bằng Protected Audience API

Trong kênh Bản dùng thử cho nhà phát triển, AdSelectionManager hiển thị 2 API mới: getAdSelectionData và persistAdSelectionResult. Các API này cho phép SDK công nghệ quảng cáo tích hợp với các máy chủ Đặt giá thầu và Phiên đấu giá.

Thu thập và mã hoá dữ liệu cho phiên đấu giá phía máy chủ

API getAdSelectionData tạo dữ liệu đầu vào bắt buộc cho các thành phần Đặt giá thầu và Phiên đấu giá, chẳng hạn như BuyerInput và ProtectedAudienceInput, đồng thời mã hoá dữ liệu trước khi đưa ra kết quả cho phương thức gọi. Để ngăn rò rỉ dữ liệu trên các ứng dụng, dữ liệu này chứa thông tin của tất cả những người mua có trên thiết bị. Đọc thêm về quyết định này trong phần những điều cần cân nhắc về quyền riêng tư và các chiến lược để tối ưu hoá quyết định này trong phần những điều cần cân nhắc về kích thước.

Để truy cập vào API, bạn phải cấp quyền truy cập vào Protected Audience API và xác định quyền ACCESS_ADSERVICES_CUSTOM_AUDIENCE trong tệp kê khai của phương thức gọi.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

Phương thức gọi phải đặt trường seller trong yêu cầu vì trường này được dùng để chạy các đợt kiểm tra đăng ký trước khi thực hiện yêu cầu.

public class GetAdSelectionDataRequest {
  Public setSeller(AdTechIdentifier seller);
}

Sau khi yêu cầu được xác thực, dữ liệu của người mua trên thiết bị bao gồm BuyerInput và ProtectedAudienceInput. Sau đó, đối tượng tải trọng cuối cùng được mã hoá bằng tính năng Mã hoá khoá công khai kết hợp hai chiều.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome được tạo dưới dạng kết quả của API getAdSelectionData bao gồm những thành phần sau:

adSelectionId: một số nguyên không rõ ràng để xác định lệnh gọi này của getAdSelectionData. Ứng dụng sử dụng công nghệ quảng cáo nên duy trì giá trị adSelectionId này bởi vì giá trị đó đóng vai trò là con trỏ đến lệnh gọi getAdSelectionData. Giá trị nhận dạng này được API persistAdSelectionResult yêu cầu để giải mã kết quả phiên đấu giá từ máy chủ Đặt giá thầu và Phiên đấu giá, đồng thời cũng được API reportImpression và reportEvent yêu cầu.
adSelectionData: Đây là dữ liệu phiên đấu giá đã mã hoá mà máy chủ Đặt giá thầu và Phiên đấu giá cần có để chạy các phiên đấu giá. Phương thức này chứa:
1. Dữ liệu đối tượng tuỳ chỉnh được lọc ra dựa trên giới hạn tần suất, bộ lọc lượt cài đặt ứng dụng và các yêu cầu của phiên đấu giá phía máy chủ cho Đối tượng tuỳ chỉnh.
2. Phiên bản trong tương lai sẽ chứa dữ liệu về lượt cài đặt ứng dụng.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Xử lý lỗi, ngoại lệ và sự cố

Nếu không thể hoàn tất thành công quá trình tạo dữ liệu lựa chọn quảng cáo vì những lý do như đối số không hợp lệ, hết thời gian chờ hoặc việc sử dụng tài nguyên quá mức, thì lệnh gọi lại OutcomeReceiver.onError() sẽ cung cấp AdServicesException cùng với những hành vi sau:

Nếu getAdSelectionData được bắt đầu bằng các đối số không hợp lệ, thì AdServicesException` sẽ cho biết nguyên nhân là IllegalArgumentException.
Tất cả các lỗi khác sẽ nhận được AdServicesException với IllegalStateException là nguyên nhân.

Gửi yêu cầu tới một dịch vụ không tin cậy của người bán

Khi sử dụng AdSelectionData, SDK trên thiết bị có thể gửi một yêu cầu đến dịch vụ quảng cáo của người bán bằng cách đưa dữ liệu vào một yêu cầu POST hoặc PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

SDK trên thiết bị chịu trách nhiệm mã hoá dữ liệu này. Bạn nên sử dụng một giải pháp hiệu quả về không gian, chẳng hạn như gửi yêu cầu đến dịch vụ quảng cáo của người bán dưới dạng multipart/form-data.

Nhận phản hồi từ một dịch vụ không tin cậy của người bán

Như đã trình bày chi tiết trong phần Giải thích về máy chủ Đặt giá thầu và Phiên đấu giá, khi dịch vụ không tin cậy của người bán nhận được yêu cầu, dịch vụ đó sẽ thực hiện lệnh gọi đến người mua đối tác để yêu cầu quảng cáo theo bối cảnh.

Dịch vụ không tin cậy của người bán sẽ chuyển tiếp adSelectionData và AuctionConfig đã mã hoá đến dịch vụ SellerFrontEnd của máy chủ Đặt giá thầu và Phiên đấu giá chạy trong một TEE (Môi trường thực thi đáng tin cậy).

Khi phiên đấu giá trong Protected Audience hoàn tất, dịch vụ SellerFrontEnd sẽ mã hoá kết quả phiên đấu giá và trả về kết quả đó dưới dạng một phản hồi cho dịch vụ không tin cậy của người bán.

Dịch vụ không tin cậy của người bán gửi một phản hồi đến thiết bị chứa quảng cáo theo bối cảnh và/hoặc kết quả phiên đấu giá trong Protected Audience đã mã hoá.

Khi nhận được phản hồi, mã công nghệ quảng cáo của người bán trên thiết bị có thể chọn chỉ sử dụng quảng cáo theo bối cảnh trong phản hồi hoặc nếu cho rằng có giá trị gia tăng trong việc nhận kết quả Protected Audience, thì mã này có thể chọn giải mã kết quả Protected Audience bằng cách gọi API PersistAdSelectionResult.

PersistAdSelectionResult API

Để giải mã kết quả Protected Audience, công nghệ quảng cáo của người bán có thể gọi Protected Audience API thứ hai persistAdSelectionResult. API giải mã kết quả và trả về một AdSelectionOutcome, chính là đối tượng được một phiên đấu giá trên thiết bị trả về hôm nay.

Để truy cập vào API, phương thức gọi phải cấp quyền truy cập vào Protected Audience API và xác định quyền ACCESS_ADSERVICES_CUSTOM_AUDIENCE trong tệp kê khai.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

Phương thức gọi phải đặt các tham số sau trong yêu cầu:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

adSelectionId: Giá trị nhận dạng không rõ ràng được lệnh gọi getAdSelectionData tạo ra. Lệnh gọi này có kết quả mà phương thức gọi muốn giải mã.
seller: Bạn phải đặt giá trị nhận dạng công nghệ quảng cáo của người bán trong yêu cầu để chạy các đợt kiểm tra đăng ký trước khi thực hiện yêu cầu.
adSelectionResult: Kết quả phiên đấu giá đã mã hoá được tạo bởi máy chủ Đặt giá thầu và Phiên đấu giá mà phương thức gọi muốn giải mã.

Phản hồi AdSelectionOutcome

Nếu có quảng cáo giành chiến thắng trong Protected Audience, AdSelectionOutcome sẽ trả về URI hiển thị quảng cáo giành chiến thắng. Sau khi adSelectionResult được giải mã, dữ liệu báo cáo sẽ được duy trì trong nội bộ. Lệnh gọi lại OutcomeReceiver.onResult() trả về một AdSelectionOutcome chứa:

URI: Nếu có quảng cáo giành chiến thắng trong Protected Audience, thì URL hiển thị quảng cáo cho quảng cáo giành chiến thắng sẽ được trả về. Nếu không có quảng cáo giành chiến thắng trong Protected Audience, `Uri.EMPTY sẽ được trả về.
adSelectionId: adSelectionId được liên kết với lần chạy phiên đấu giá phía máy chủ này.

Xử lý lỗi, ngoại lệ và sự cố

Nếu getAdSelectionData được bắt đầu bằng các đối số không hợp lệ, AdServicesException sẽ cho biết nguyên nhân là IllegalArgumentException.
Tất cả các lỗi khác sẽ nhận được AdServicesException với IllegalStateException là nguyên nhân.

Những điều cần cân nhắc về quyền riêng tư

adSelectionData được mã hoá để đảm bảo rằng chỉ có PPAPI và các máy chủ đáng tin cậy mới truy cập được vào dữ liệu đang truyền.

Mặc dù đã mã hoá, nhưng sự cố rò rỉ dữ liệu vẫn có thể xảy ra do kích thước của adSelectionData. Kích thước của adSelectionData có thể thay đổi do:

Các thay đổi về dữ liệu CustomAudience có trên thiết bị.
Các thay đổi đối với logic lọc CustomAudience.
Các thay đổi đối với phương thức nhập vào lệnh gọi getAdSelectionData.

Bạn có thể sử dụng sự thay đổi về kích thước của adSelectionData để tạo giá trị nhận dạng trên nhiều ứng dụng như đã đề cập trong cuộc thảo luận về rò rỉ 1 bit. Nhiều biện pháp giảm thiểu áp dụng cho sự cố rò rỉ 1 bit cũng được áp dụng tại đây.

Để quản lý những sự cố rò rỉ này, chúng tôi dự định tạo cùng một adSelectionData cho tất cả các lệnh gọi đến API getAdSelectionData. Trong các bản phát hành ban đầu, mọi CustomAudiences trên thiết bị đều được dùng để tạo adSelectionData và tải trọng đã mã hoá sẽ được dùng làm khoảng đệm để tạo mặt nạ cho các biến kích thước. Chúng tôi cũng sẽ hạn chế ảnh hưởng của các tham số đầu vào GetAdSelectionData đối với adSelectionData đã tạo.

Tuy nhiên, việc tạo cùng một adSelectionData cho tất cả các công nghệ quảng cáo bằng cách dùng mọi dữ liệu của phiên đấu giá trên thiết bị sẽ tạo ra một tải trọng lớn cần được truyền trong mỗi lệnh gọi đến máy chủ công nghệ quảng cáo. Việc sử dụng tất cả các đối tượng tuỳ chỉnh trên thiết bị để tạo tải trọng phiên đấu giá cũng sẽ khiến hệ sinh thái lạm dụng các thực thể độc hại. Chúng tôi đã trình bày những mối lo ngại này trong các phần Tối ưu hoá kích thước và Giảm thiểu hành vi lạm dụng ở bên dưới.

Tối ưu hoá kích thước

SDK ứng dụng sử dụng công nghệ quảng cáo dự kiến sẽ đóng gói các byte đã mã hoá của adSelectionData thành lệnh gọi theo bối cảnh HTTP PUT/POST được gửi đến máy chủ công nghệ quảng cáo. Để giảm bớt chi phí và độ trễ cho thời gian khứ hồi, cần phải giảm kích thước của adSelectionData nhiều nhất có thể mà không làm ảnh hưởng đến phần mềm tiện ích.

Chúng tôi dự định khám phá và có thể sẽ triển khai các tính năng tối ưu hoá sau đây trong các bản phát hành sắp tới để giảm kích thước của adSelectionData:

Tải trọng được tạo trong một tập hợp kích thước nhóm cố định có khoảng đệm: Để giảm thiểu tình trạng rò rỉ từ các biến kích thước mà vẫn cho phép các tải trọng thấp hơn, bạn nên sử dụng nhóm kích thước cố định cho tải trọng đã tạo. Ví dụ: việc giữ số lượng nhóm nhỏ bằng 7 sẽ dẫn đến ít hơn 3 bit entropy bị rò rỉ trên mỗi lệnh gọi đến getAdSelectionData.

Nếu dữ liệu trên thiết bị vượt quá kích thước nhóm tối đa, thì các chiến lược được đề cập dưới đây, chẳng hạn như giá trị ưu tiên, sẽ được dùng để quyết định xem dữ liệu nào bị bỏ qua.
Cấu hình của người mua: Chúng tôi sẽ đánh giá tính khả thi của việc cho phép người mua thiết lập một cấu hình tải trọng trên mỗi người mua. Cấu hình này sẽ giúp ích trong việc xác định các phiên đấu giá mà người mua muốn tham gia. Nếu khả thi, trong quá trình đăng ký, một công nghệ quảng cáo của người mua có thể đăng ký một điểm cuối mà từ đó Protected Audience sẽ tìm nạp cấu hình tải trọng theo tần suất bình thường hằng ngày. Ngoài ra, các API bảo đảm quyền riêng tư sẽ hiển thị một API để cho phép công nghệ quảng cáo của người mua đăng ký điểm cuối này.

Sau đó, cấu hình này sẽ được dùng để đánh giá sự đóng góp của người mua vào adSelectionData được tạo cho từng yêu cầu getAdSelectionData.

Cấu hình tải trọng của người mua sẽ cho phép người mua chỉ định:
1. Danh sách người bán được phép: Đối tượng tuỳ chỉnh của người mua sẽ chỉ được thêm vào tải trọng nếu lệnh gọi getAdSelectionData do người bán khởi tạo trong danh sách cho phép. Chúng tôi sẽ tìm nạp cấu hình tải trọng theo tần suất hằng ngày để luôn cập nhật danh sách cho phép.
2. Giới hạn kích thước trên mỗi người bán: Người mua có thể chỉ định giới hạn kích thước trên mỗi người bán để xác định kích thước dữ liệu sẽ được gửi trong tải trọng khi phiên đấu giá do một người bán nhất định khởi tạo. Điều này sẽ giúp ích nếu người mua muốn dành nhiều tài nguyên hơn cho việc xử lý dữ liệu phiên đấu giá từ một số người bán. SellerFrontendService chỉ chuyển tiếp dữ liệu dành riêng cho người mua cho từng BuyerFrontendService. Vì vậy, bằng cách xác định giới hạn kích thước trên mỗi người bán, người mua có thể kiểm soát rõ ràng lượng dữ liệu mà BuyerFrontendService của máy chủ Đặt giá thầu và Phiên đấu giá nhập và xử lý đối với các phiên đấu giá do một người bán chạy.
Cấu hình của người bán: Chúng tôi đang đánh giá tính khả thi của cấu hình đấu giá trên mỗi người bán, qua đó cho phép người bán xác định các tham số đấu giá để kiểm soát kích thước tải trọng và người tham gia phiên đấu giá. Nếu khả thi, trong quá trình đăng ký, một công nghệ quảng cáo của người bán có thể chỉ định một điểm cuối mà từ đó Protected Audience sẽ tìm nạp cấu hình phiên đấu giá trên mỗi người bán theo một tần suất bình thường. Sau đó, cấu hình này sẽ được dùng để xác định thành phần và các giới hạn của adSelectionData được tạo cho từng yêu cầu getAdSelectionData.

Tương tự như cấu hình của người mua, cấu hình trên mỗi người bán sẽ cho phép người bán chỉ định tập hợp người mua mà họ muốn nhìn thấy trong phiên đấu giá và chỉ định các giới hạn đối với sự đóng góp trên mỗi người mua vào kích thước tải trọng.

Cấu hình phiên đấu giá của người bán sẽ cho phép người bán chỉ định:
1. Danh sách người mua được phép: Đối với các phiên đấu giá do người bán nhất định khởi tạo, chỉ những người mua trong danh sách cho phép mới có thể đóng góp Đối tượng tuỳ chỉnh cho phiên đấu giá. Bạn cần cập nhật cấu hình phiên đấu giá hằng ngày để danh sách cho phép luôn được cập nhật với danh sách cho phép của người mua phía máy chủ.
2. Giới hạn kích thước trên mỗi người mua: Người bán có thể chỉ định giới hạn trên mỗi người mua để điều chỉnh kích thước dữ liệu mà mỗi người mua tải lên trong tải trọng đang được gửi đến SellerFrontendService. Nếu người mua vượt quá giới hạn kích thước trên mỗi người mua, mức độ ưu tiên của Đối tượng tuỳ chỉnh được đặt trong cấu hình tải trọng của người mua sẽ được dùng để lấy dữ liệu trong các giới hạn dự kiến.
3. Mức độ ưu tiên trên mỗi người mua: Cho phép người bán đặt mức độ ưu tiên trên mỗi người mua. Mức độ ưu tiên của người mua sẽ được dùng để xác định dữ liệu nào của người mua sẽ được giữ lại trong tải trọng nếu kích thước tải trọng vượt quá giới hạn về kích thước tải trọng.
4. Giới hạn kích thước tối đa cho tải trọng: Mỗi người bán có thể có một mức phân bổ tài nguyên riêng và họ có thể muốn đặt giới hạn kích thước tối đa cho tải trọng phiên đấu giá theo yêu cầu. Giới hạn kích thước tối đa sẽ tuân theo nhóm kích thước cố định do Protected Audience API đặt ra.
Thay đổi về đối tượng tuỳ chỉnh
1. Chỉ định mức độ ưu tiên của đối tượng tuỳ chỉnh: Cho phép người mua chỉ định một giá trị ưu tiên trong một Đối tượng tuỳ chỉnh. Trường priority sẽ dùng để xác định đối tượng tuỳ chỉnh sẽ có trong phiên đấu giá nếu tập hợp đối tượng tuỳ chỉnh của người mua vượt quá giới hạn kích thước trên mỗi người bán hoặc giới hạn kích thước trên mỗi người mua. Một giá trị ưu tiên chưa được chỉ định trong Đối tượng tuỳ chỉnh sẽ đặt mặc định ở 0.0.
Thay đổi về dữ liệu tải trọng
1. Giảm bớt lượng dữ liệu được gửi trong tải trọng: Như đã nêu chi tiết trong phần Tối ưu hoá tải trọng dịch vụ Đặt giá thầu và Phiên đấu giá, dữ liệu ads của đối tượng tuỳ chỉnh, tín hiệu đặt giá thầu của người dùng, tín hiệu của Android sẽ khiến tải trọng cao hơn. Có thể giảm bớt các tải trọng cao hơn bằng cách:
  1. Yêu cầu ứng dụng gửi giá trị nhận dạng hiển thị quảng cáo (thay cho đối tượng quảng cáo) trong tải trọng.
  2. Yêu cầu ứng dụng không gửi dữ liệu quảng cáo trong tải trọng.
  3. Không gửi tín hiệu đặt giá thầu của người dùng trong tải trọng ứng dụng.

Mặc dù các chiến lược nêu trên cho phép các công nghệ quảng cáo xác định cấu hình để quản lý thành phần và giới hạn của tải trọng adSelectionData, nhưng các chiến lược này cũng có thể trở thành một yếu tố để điều chỉnh kích thước adSelectionData bằng cách thay đổi các tham số cấu hình. Để tránh điều này, cấu hình sẽ được Protected Audience tìm nạp hằng ngày từ điểm cuối được định cấu hình.

Tối ưu hoá độ trễ

Để các phiên đấu giá phía máy chủ có được mức độ hữu dụng mong muốn, chúng ta cần đảm bảo rằng API getAdSelectionData và API persistAdSelectionResult có độ trễ ở mức thấp đối với mỗi lệnh gọi. Mặc dù mục tiêu của chúng tôi là cung cấp dịch vụ hỗ trợ tính năng cho các API vào năm 2023, nhưng bản phát hành tiếp theo của chúng tôi sẽ tập trung vào các điểm chuẩn và tính năng tối ưu hoá độ trễ cho các API này.

Chúng tôi đang tìm hiểu các chiến lược sau đây để đảm bảo độ trễ luôn ở trong giới hạn có thể chấp nhận:

Tạo trước dữ liệu Protected Audience trên mỗi người bán: Vì cấu hình phiên đấu giá của người bán và cấu hình tải trọng của người mua sẽ ổn định trong một khoảng thời gian đáng kể (hằng ngày), nên nền tảng này có thể tính toán trước và lưu trữ dữ liệu Protected Audience đủ điều kiện.

Điều này sẽ đòi hỏi nền tảng xây dựng một cơ chế để theo dõi thông tin cập nhật đối tượng tuỳ chỉnh và sửa đổi dữ liệu Protected Audience được tạo trước dựa trên thông tin cập nhật đó. Nền tảng này cũng cần khai báo SLO trên độ trễ của cuộc đua mà công nghệ quảng cáo có thể kỳ vọng giữa các lần cập nhật đối tượng tuỳ chỉnh và nhận thấy thay đổi về adSelectionData` được tạo cho phiên đấu giá phía máy chủ.

Vì một thiết bị cung cấp mô hình tính toán tài nguyên giới hạn với các mức độ ưu tiên khác nhau về quy trình, nên chúng tôi nhận ra rằng việc cung cấp phương tiện tạo trước này phải có độ tin cậy cao và đảm bảo SLO.

Sau đó, việc tạo trước dữ liệu Protected Audience sẽ dựa trên đó
1. Người bán chọn tạo trước dữ liệu về Protected Audience.
2. Người mua đủ điều kiện tham gia phiên đấu giá do một người bán cụ thể khởi tạo.
3. Xác định đối tượng tuỳ chỉnh cho mỗi người mua, là một phần của tải trọng dựa trên:
  1. Giới hạn kích thước trên mỗi người mua, mức độ ưu tiên trên mỗi người mua và giới hạn kích thước tối đa được xác định trong cấu hình của người bán,
  2. Giới hạn kích thước trên mỗi người bán, mức độ ưu tiên về đối tượng tuỳ chỉnh được xác định trong cấu hình của người mua.
Ứng dụng Eager có chức năng lọc phủ định: Nếu được một người bán ưu tiên, nền tảng có thể tính toán trước adSelectionData bằng cách tạo trước dữ liệu Protected Audience và áp dụng chế độ lọc phủ định ở bên ngoài lệnh gọi getAdSelectionData quan trọng. Điều này cho phép người bán cân bằng việc giảm độ trễ trong khi chấp nhận tình trạng lỗi thời khi ở chế độ lọc phủ định.

Nền tảng có thể cung cấp dịch vụ hỗ trợ này bằng cách đưa ra một tuỳ chọn mặc định trong cấu hình của Người bán với một giới hạn về mức độ lỗi thời và một tuỳ chọn ghi đè trong getAdSelectionData để có dữ liệu tính toán mới nhất nếu cần. Ngoài ra, nền tảng có thể cung cấp một API khởi tạo bổ sung sẽ được gọi trước getAdSelectionData để khởi động phiên đấu giá.
Tính toán tải trọng cho nhiều phiên đấu giá: Trong một số trường hợp, bạn nên có một API đảm bảo tính hiệu quả về độ trễ khi mức độ lỗi thời của dữ liệu tăng. Để mang lại điều này, nền tảng có thể giới thiệu một API khởi tạo nhằm tính toán toàn bộ tải trọng và cung cấp dữ liệu tham chiếu đến tải trọng được tính toán cho phương thức gọi.

Đối với các lệnh gọi tiếp theo tới getAdSelectionData, phương thức gọi có thể cung cấp dữ liệu tham chiếu đến tải trọng được tính toán trước sẽ được dùng để tạo adSelectionData.

Cả 3 chiến lược nêu trên đều đang ở giai đoạn tìm hiểu ban đầu và nhằm mô tả định hướng của nền tảng có thể là tối ưu hoá cho độ trễ. Khi tìm hiểu chi tiết hơn về hồ sơ độ trễ của API và các yêu cầu của công nghệ quảng cáo, chúng tôi sẽ tiếp tục đề xuất các chiến lược bổ sung.

Cách nhận dạng và giảm thiểu hành vi lạm dụng

Như đã đề cập trong phần Những điều cần cân nhắc về quyền riêng tư, adSelectionData được tạo bằng cách sử dụng tất cả dữ liệu người mua trên thiết bị.

Tuy nhiên, nếu tất cả dữ liệu người mua trên thiết bị được dùng để tạo đầu ra adSelectionData, thì một thực thể độc hại có thể đóng vai người mua và tạo dữ liệu người mua gian lận để làm giảm hiệu suất Android, tăng tải trọng để tăng chi phí cho công nghệ quảng cáo chạy phiên đấu giá hoặc chạy đặt giá thầu, v.v.

Giải pháp giảm thiểu

Một số biện pháp được đề cập trong phần những điều cần cân nhắc về kích thước (chẳng hạn như cấu hình tải trọng của người mua bao gồm những người bán có trong danh sách cho phép và cấu hình phiên đấu giá của người bán bao gồm những người mua có trong danh sách cho phép) sẽ giúp loại trừ dữ liệu không mong muốn trong tải trọng.

Bạn cũng cần cân nhắc các biện pháp khác về kích thước, chẳng hạn như cho phép SSP chỉ định mức độ ưu tiên của người mua, đặt hạn mức trên mỗi người mua trong tải trọng đã tạo và đặt kích thước tối đa trên mỗi tải trọng đấu giá để có thể giảm thiểu tác động của việc tăng tải trọng độc hại. Những biện pháp này nhằm giúp các công nghệ quảng cáo có thể xác định công nghệ quảng cáo mà chúng có thể cộng tác và đặt ra các giới hạn chấp nhận được đối với tải trọng mà chúng cần xử lý.

Như đã đề cập trước đó, tất cả các biện pháp giảm thiểu dùng trong trường hợp chống hành vi lạm dụng và hạn chế về kích thước đều phải tuân thủ những điều cần cân nhắc về quyền riêng tư.

Cách nhận dạng thực thể độc hại

Mặc dù các biện pháp giảm thiểu được đề cập ở trên bảo vệ quy trình tạo adSelectionData cho các phiên đấu giá phía máy chủ, chúng không hỗ trợ việc xác định thực thể độc hại hoặc bảo vệ nền tảng khỏi hành vi lạm dụng, chẳng hạn như tạo số lượng đối tượng tuỳ chỉnh chưa từng có từ một người mua.

Để đảm bảo tính ổn định và tình hình của nền tảng, chúng tôi cần tìm một cơ chế nhằm xác định các thực thể độc hại, xác định vectơ có hành vi lạm dụng và xác định động cơ của các cuộc tấn công cụ thể. Trong các bản phát hành sau này, chúng tôi sẽ giới thiệu nội dung giải thích nêu chi tiết về các vectơ có thể có hành vi lạm dụng và các biện pháp bảo vệ để ngăn chặn những vectơ đó.