Đề xuất Báo cáo phân bổ đã trải qua một số thay đổi để giải quyết phản hồi của cộng đồng, từ thay đổi cơ chế API cho đến chức năng mới.
Nhật ký thay đổi
- Ngày 7 tháng 2 năm 2022: Thêm phần về lệnh chuyển hướng điều kiện kích hoạt tiêu đề.
- Ngày 27 tháng 1 năm 2022: Bài viết được xuất bản lần đầu tiên.
Đối tượng mà bài đăng này nhắm đến là ai?
Bài đăng này dành cho bạn:
- Nếu bạn đã hiểu về API (ví dụ: nếu bạn đang quan sát hoặc tham gia vào các cuộc thảo luận trên kho lưu trữ WICG và muốn hiểu loạt các thay đổi đối với đề xuất vào tháng 1 năm 2022.
- Nếu bạn đang sử dụng Attribution Reporting API trong bản minh hoạ hoặc trong một thử nghiệm thực tế.
Nếu bạn mới bắt đầu sử dụng API này và/hoặc chưa thử nghiệm với API này, hãy truy cập trực tiếp vào giới thiệu về API thay thế.
Sắp di chuyển
Sau khi những thay đổi này được triển khai trong Chrome: nếu sử dụng báo cáo cấp sự kiện từ Attribution Reporting API trong bản minh hoạ hoặc trong một thử nghiệm đang trong quá trình chính thức (bản dùng thử theo nguyên gốc), thì bạn sẽ cần chỉnh sửa mã để API tiếp tục hoạt động. Bạn cũng có thể cân nhắc việc sử dụng các tính năng mới.
Bài viết này cũng liệt kê các thay đổi đối với báo cáo tổng hợp. Tuy nhiên, những thay đổi này (nếu được triển khai) sẽ không yêu cầu hành động hoặc di chuyển, vì hiện chưa có phương thức triển khai cho trình duyệt đối với báo cáo tổng hợp tại thời điểm viết bài này.
Thay đổi tên
Báo cáo tóm tắt và báo cáo tổng hợp
Những dữ liệu mà bạn có thể đã thấy được mô tả dưới dạng báo cáo tổng hợp giờ đây sẽ được gọi làm báo cáo tóm tắt.
Báo cáo tóm tắt là kết quả cuối cùng của hoạt động tổng hợp nhiều báo cáo tổng hợp, trước đây được gọi là khoản đóng góp trên biểu đồ hoặc khoản đóng góp trên biểu đồ.
Các thay đổi về cơ chế API
Đăng ký nguồn dựa trên tiêu đề (báo cáo ở cấp sự kiện)
Điều gì sẽ thay đổi và tại sao?
Khi người dùng xem hoặc nhấp vào quảng cáo, trình duyệt (cục bộ trên thiết bị của người dùng) sẽ ghi lại sự kiện này,
cùng với các thông số dành riêng cho báo cáo phân bổ (chẳng hạn như
attributionsourceeventid, attributiondestination, attributionexpiry và các tham số khác). Chiến lược phát hành đĩa đơn
giá trị của các thông số này do công nghệ quảng cáo đặt.
Cách đặt những thông số này đang thay đổi.
Trong đề xuất trước đó, các thông số phải được đưa vào phía máy khách: trong thẻ ký tự liên kết làm thuộc tính HTML hoặc làm đối số của lệnh gọi dựa trên JS. Thông số phải được xác định khi nhấp vào hoặc xem bất cứ lúc nào.
Trong đề xuất mới, giá trị của các thông số này được xác định trên máy chủ công nghệ quảng cáo.
Điều này có một số ưu điểm, đáng chú ý là về mặt bảo mật: cơ chế tiêu đề cho phép báo cáo nguồn gốc (thường là công nghệ quảng cáo) kiểm soát trực tiếp việc nguồn phân bổ có được đăng ký trong phạm vi. Điều này phần nào giảm thiểu được mối lo ngại về gian lận, vì với thay đổi này, một trình duyệt chính thống sẽ không bao giờ đăng ký một nguồn mà không có lựa chọn sử dụng của nguồn gốc báo cáo.
Quy trình đăng ký nguồn hoạt động như thế nào?
- Đối với một quảng cáo nhất định, giờ đây, công nghệ quảng cáo sẽ cần xác định một thuộc tính cụ thể phía máy khách
attributionsrc. Giá trị của thuộc tính này là một URL mà trình duyệt sẽ gửi một URL đến yêu cầu; yêu cầu này sẽ bao gồm một tiêu đề HTTP mớiAttribution-Reporting-Source-Infocónavigationhoặcevent,chỉ định nguồn lần lượt là lượt nhấp hay lượt xem. - Khi nhận được yêu cầu này, máy chủ theo dõi lượt nhấp/lượt xem sẽ phản hồi bằng một HTTP
tiêu đề,
Attribution-Reporting-Register-Source, có chứa thuộc tính mong muốn tham số. Nguồn gốc trả về tiêu đề này hiện là nguồn gốc báo cáo (trước đây được định nghĩa là
attributionreportto).Tiêu đề phản hồi HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Tham gia cuộc thảo luận công khai
Điều kiện kích hoạt mô hình phân bổ dựa trên tiêu đề (báo cáo ở cấp sự kiện)
Điều gì sẽ thay đổi và tại sao?
Giống như việc đăng ký lượt nhấp hoặc lượt xem, đề xuất mới cũng thay đổi điều kiện kích hoạt mô hình phân bổ – khi một
công nghệ quảng cáo hướng dẫn trình duyệt ghi lại lượt chuyển đổi theo cách tiếp cận dựa trên tiêu đề.
Cơ chế này phù hợp với việc đăng ký nguồn dựa trên tiêu đề và
thông thường so với cơ chế chuyển hướng được sử dụng trước đó.
Ngoài ra, trong đề xuất mới, thuộc tính attributionsrc cần thiết trên trang chuyển đổi.
Lý do là vấn đề về quyền: trong đề xuất trước đó, trang web phía điều kiện kích hoạt – thường là
trang web của nhà quảng cáo—có quyền kiểm soát chung đối với tính năng thông qua tiêu đề Permissions-Policy, nhưng
không có kiểm soát chi tiết ở cấp phần tử về việc liệu một phần tử có thể gửi yêu cầu đến một bên hay không
cuối cùng sẽ kích hoạt một hoạt động phân bổ. attributionsrc thay đổi điều này: điểm đánh dấu bắt buộc này
mang lại cho nhà quảng cáo khả năng theo dõi và từ đó kiểm soát yếu tố nào có thể kích hoạt
phân bổ giá trị đóng góp.
Xin lưu ý rằng ở phía nguồn (thường là trang web của nhà xuất bản) là chế độ kiểm soát trên toàn trang thông qua
Permissions-Policy, cũng như một chế độ điều khiển toàn phần tử thông qua attributionsrc, cũng có sẵn.
Trình kích hoạt phân bổ hoạt động như thế nào?
Sau khi nhận được yêu cầu về pixel và quyết định rằng nên phân loại lượt chuyển đổi đó là lượt chuyển đổi, một công nghệ quảng cáo
sẽ phản hồi bằng một HTTP mới
tiêu đề Attribution-Reporting-Register-Event-Trigger.
Giá trị của tiêu đề này chỉ định cách xử lý sự kiện kích hoạt dưới dạng đối tượng JSON. Điều này cũng giống nhau được xác định là tham số truy vấn trong đề xuất trước đó.
Tiêu đề phản hồi HTTP Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Chuyển hướng (không bắt buộc)
Nếu muốn, máy chủ công nghệ quảng cáo có thể tạo phản hồi chứa Attribution-Reporting-Register-Event-Trigger làm phản hồi chuyển hướng.
Cách này cho phép bên thứ ba quan sát sự kiện chuyển đổi và hướng dẫn trình duyệt phân bổ sự kiện đó.
Việc chuyển hướng là không bắt buộc; khi cả công nghệ quảng cáo và bên thứ ba đều có pixel trên trang.
Bạn có thể xem thêm thông tin chi tiết tại Báo cáo bên thứ ba.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Tham gia cuộc thảo luận công khai
Không có worklet nào (báo cáo tổng hợp)
Điều gì sẽ thay đổi và tại sao?
Trong đề xuất trước đây về báo cáo tổng hợp, bạn cần có quyền truy cập JavaScript để gọi một worklet – cơ chế dựa trên JavaScript – sẽ tạo các báo cáo này.
Trong đề xuất mới, không cần có worklet. Thay vào đó, một công nghệ quảng cáo sẽ xác định theo cách khai báo thông qua HTTP tiêu đề – những quy tắc mà trình duyệt nên sử dụng để tạo báo cáo tổng hợp.
Đề xuất mới mang lại một số lợi ích:
- Triển khai trình duyệt: thiết kế mới, không giống như thiết kế worklet, về cơ bản đơn giản hơn vì không cần một môi trường thực thi mới trong trình duyệt.
- Trải nghiệm của nhà phát triển: thiết kế mới dựa trên tiêu đề, vốn thường được sử dụng và được các nhà phát triển biết đến rộng rãi—không giống như các Worklet. Điều này cũng phù hợp chặt chẽ với nền tảng API cho đăng ký nguồn, giúp API dễ tìm hiểu và sử dụng hơn.
- Sử dụng: thiết kế mới cho phép nhiều hệ thống đo lường hiện có hơn sử dụng các tổng hợp . Nhiều giải pháp đo lường chỉ dùng giao thức HTTP: các giải pháp này dựa vào các yêu cầu về hình ảnh (pixel) yêu cầu—không yêu cầu quyền truy cập JavaScript. Nhưng vì phương pháp worklet thực hiện yêu cầu Quyền truy cập JavaScript, có thể bạn đã gặp khó khăn khi di chuyển từ một số hệ thống đo lường hiện có.
- Tính mạnh mẽ: thiết kế mới giúp giảm thiểu tình trạng mất dữ liệu vì dễ tích hợp hơn
với ngữ nghĩa
keepalive, ví dụ: nếu một lượt nhấp hoặc lượt xem được đăng ký khi người dùng đang rời khỏi một trang.
Cơ chế không có worklet hoạt động như thế nào?
Cơ chế khai báo này dựa trên tiêu đề HTTP, giống như việc đăng ký nguồn ở cấp sự kiện và tiêu đề của điều kiện kích hoạt phân bổ. Thông tin chi tiết về vấn đề này trong các phần tiếp theo.
Tham gia cuộc thảo luận công khai
Đăng ký nguồn dựa trên tiêu đề (báo cáo tổng hợp)
Một cơ chế mới được đề xuất để đăng ký nguồn cho một báo cáo tổng hợp; cơ chế này là giống như quy trình đăng ký nguồn ở cấp sự kiện.
Chỉ có tên tiêu đề là khác: Attribution-Reporting-Register-Aggregatable-Source.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Điều kiện kích hoạt mô hình phân bổ dựa trên tiêu đề (báo cáo tổng hợp)
Một cơ chế mới được đề xuất để đăng ký nguồn cho một báo cáo tổng hợp; cơ chế này là giống như điều kiện kích hoạt phân bổ ở cấp sự kiện.
Chỉ có tên tiêu đề là khác: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Đăng ký điều kiện kích hoạt phân bổ
Tính năng mới
Báo cáo của bên thứ ba (báo cáo cấp sự kiện và báo cáo tổng hợp)
Điều gì sẽ thay đổi và tại sao?
Hai khía cạnh của đề xuất mới giúp hỗ trợ tốt hơn cho các trường hợp sử dụng báo cáo của bên thứ ba:
- Theo tuỳ chọn, các công nghệ quảng cáo có thể chuyển hướng yêu cầu mạng đến máy chủ của các công nghệ quảng cáo khác, điều này cho phép những công nghệ quảng cáo khác các công nghệ quảng cáo thực hiện việc đăng ký nguồn và điều kiện kích hoạt của riêng chúng. Đây là cách phổ biến thứ ba các bên được định cấu hình ngay hôm nay. Điều này giúp việc áp dụng API này dễ dàng hơn, ngoài các API hệ thống báo cáo của bên thứ ba.
- Nguồn gốc báo cáo (thường là công nghệ quảng cáo) không còn dùng chung hầu hết các giới hạn về quyền riêng tư. Điều này hỗ trợ việc sử dụng trường hợp nhiều công nghệ quảng cáo hoạt động với cùng một nhà xuất bản hoặc nhà quảng cáo.
Báo cáo của bên thứ ba hoạt động như thế nào?
Trong đề xuất mới, việc đăng ký nguồn và điều kiện kích hoạt dựa trên phản hồi sẽ dựa vào Tiêu đề HTTP. Một công nghệ quảng cáo có thể tận dụng lệnh chuyển hướng HTTP cho các yêu cầu này.
Nếu sau đó yêu cầu nhấp/xem trên trang web của nhà xuất bản (đăng ký nguồn) được chuyển hướng đến
nhiều bên, mỗi bên có thể đăng ký lượt xem hoặc lượt nhấp này (sự kiện nguồn).
Tương tự như vậy, một công nghệ quảng cáo có thể chuyển hướng một yêu cầu phân bổ cụ thể được thực hiện từ trang web của nhà quảng cáo,
cho phép nhiều bên khác đăng ký một lượt chuyển đổi (điều kiện kích hoạt phân bổ).
Mỗi bên có thể truy cập vào các báo cáo riêng của họ và định cấu hình báo cáo bằng dữ liệu riêng.
Đăng ký nhiều điều kiện kích hoạt mà không cần chuyển hướng
Bạn cũng có thể đăng ký nhiều điều kiện kích hoạt phân bổ mà không cần sử dụng lệnh chuyển hướng, bằng cách thêm nhiều phần tử pixel ở phía chuyển đổi (một phần tử cho mỗi điều kiện kích hoạt).
Tham gia cuộc thảo luận công khai
Đo lường xem qua (báo cáo cấp sự kiện và báo cáo tổng hợp)
Điều gì sẽ thay đổi và tại sao?
Trong đề xuất mới, tính năng đo lường lượt xem hết và lượt nhấp hoạt động theo cách thống nhất:
registerattributionsrc, thuộc tính dành riêng cho khung hiển thị đã hướng dẫn trình duyệt ghi lại lượt xem cùng với lượt nhấp không còn là một phần của đề xuất.- Cơ chế quyền riêng tư hiện được hợp nhất giữa lượt nhấp và lượt xem. Về vấn đề này, hãy xem thông tin chi tiết trong phần Tiếng ồn và tính minh bạch.
Thay đổi này được đề xuất để phù hợp với cơ chế đăng ký dựa trên tiêu đề mới. Việc này cũng giúp đơn giản hoá trải nghiệm của nhà phát triển khi dự định hỗ trợ cả lượt nhấp và lượt xem hết đo lường.
Giải pháp đo lường lượt xem hết hoạt động như thế nào?
Cả dịch vụ đo lường lượt xem hết và lượt nhấp đều dựa vào việc đăng ký dựa trên tiêu đề.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Báo cáo ở cấp sự kiện (cho cả lượt nhấp và lượt xem)
Tham gia cuộc thảo luận công khai
Gỡ lỗi / Phân tích hiệu suất (báo cáo cấp sự kiện và báo cáo tổng hợp)
Điều gì sẽ thay đổi và tại sao?
Một cơ chế gỡ lỗi đã được thêm vào đề xuất để giúp nhà phát triển phát hiện lỗi, cũng như so sánh hiệu suất của Báo cáo phân bổ với các giải pháp đo lường dựa trên cookie hiện có.
Tính năng gỡ lỗi hoạt động như thế nào?
Cả hoạt động đăng ký nguồn và điều kiện kích hoạt đều sẽ chấp nhận tham số mới debug_key (một tham số 64 bit chưa được ký)
số nguyên (tức là một số lớn).
Trường hợp một báo cáo được tạo bằng khoá gỡ lỗi nguồn và điều kiện kích hoạt và nếu là cookie Samesite=None ar_debug=1
hiện diện trong kho cookie của nguồn gốc báo cáo tại thời điểm đăng ký điều kiện kích hoạt và nguồn, một bản gỡ lỗi
báo cáo (JSON) sẽ được gửi đến điểm cuối .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Các báo cáo cấp sự kiện và báo cáo tổng hợp cũng sẽ bao gồm 2 thông số mới này để chúng có thể được được liên kết với báo cáo gỡ lỗi chính xác.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Không bắt buộc: báo cáo gỡ lỗi mở rộng
Tham gia cuộc thảo luận công khai
Khả năng lọc (báo cáo cấp sự kiện và báo cáo tổng hợp)
Điều gì sẽ thay đổi và tại sao?
Vì chúng hỗ trợ các trường hợp sử dụng quan trọng trong hệ sinh thái quảng cáo ngày nay, nên một số trường hợp sử dụng giờ đây sẽ được hỗ trợ trong cả báo cáo cấp sự kiện và báo cáo tổng hợp:
- Lọc lượt chuyển đổi: lọc lượt chuyển đổi dựa trên thông tin phía nguồn. Cho ví dụ: chọn dữ liệu điều kiện kích hoạt khác nhau (dữ liệu lượt chuyển đổi) cho lượt nhấp và lượt xem quảng cáo.
- Phân bổ không khớp: lọc các lượt chuyển đổi được phân bổ sai; đây là loại lọc lượt chuyển đổi cụ thể. Ví dụ: lọc ra các lượt chuyển đổi được so khớp với lượt nhấp/lượt xem quảng cáo không chính xác do phạm vi đích đến etld+1 trong API.
Các chức năng lọc hoạt động như thế nào? (đối với báo cáo ở cấp sự kiện)
Trường source_data không bắt buộc trong đối tượng JSON phía nguồn có thể xác định các mục sẽ
sau đó được trình duyệt sử dụng tại thời điểm chuyển đổi để áp dụng logic lọc.
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
Bây giờ, quy trình đăng ký điều kiện kích hoạt sẽ chấp nhận tiêu đề không bắt buộc Attribution-Reporting-Filters.
Tiêu đề phản hồi HTTP Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Ngoài ra, bạn có thể mở rộng tiêu đề Attribution-Reporting-Register-Event-Trigger bằng một
Trường filters để lọc có chọn lọc nhằm đặt trigger_data dựa trên source_data.
Nếu các khoá trong bộ lọc JSON khớp với các khoá trong source_data, thì điều kiện kích hoạt sẽ là
hoàn toàn bị bỏ qua nếu giao lộ trống.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Tham gia cuộc thảo luận công khai
Các thay đổi về tính năng bảo vệ quyền riêng tư
Độ nhiễu và tính minh bạch (báo cáo cấp sự kiện và báo cáo tổng hợp)
Điều gì sẽ thay đổi và tại sao?
Trong đề xuất mới, một trong những cơ chế bảo mật cho báo cáo đã được cải thiện: báo cáo được
tuỳ thuộc vào phản ứng ngẫu nhiên.
Điều này có nghĩa là một số lượt chuyển đổi thực tế sẽ được báo cáo chính xác; và một tỷ lệ phần trăm nhất định
, một số lượt chuyển đổi thực sự sẽ bị chặn hoặc một số lượt chuyển đổi giả sẽ được thêm vào.
Kỹ thuật mới này có một số lợi ích:
- Giải pháp này hợp nhất cơ chế bảo vệ quyền riêng tư cho lượt nhấp và lượt xem.
- Lý do đơn giản hơn so với một cơ chế trong đó dữ liệu điều kiện kích hoạt (dữ liệu lượt chuyển đổi) và yếu tố nhiễu đường liên kết nguồn điều kiện kích hoạt sẽ được tách riêng.
- Giải pháp này thiết lập một khung về quyền riêng tư mà có thể với chế độ cài đặt độ nhiễu phù hợp, giúp đảm bảo rằng không bên nào có thể dựa vào API này để biết chắc chắn một người dùng cá nhân đã chuyển đổi (hay không) cho một quảng cáo nhất định.
Cơ chế mới này thay thế cơ chế trước đó, trong đó 5% thời gian sẽ kích hoạt dữ liệu (dữ liệu lượt chuyển đổi) đã được thay thế bằng một giá trị ngẫu nhiên.
Ngoài ra, giá trị xác suất phản hồi ngẫu nhiên đã được thêm vào nội dung báo cáo
(randomized_trigger_rate trường). Trường này chỉ định xác suất (0 đến 1) mà nguồn là
được phản hồi ngẫu nhiên.
Điều này có hai lợi ích chính:
- Điều này giúp minh bạch hành vi cơ bản của trình duyệt đối với các bên sẽ nhận báo cáo (thường là công nghệ quảng cáo).
- Điều này rất hữu ích cho một tương lai mà API sẽ được hỗ trợ trên trình duyệt: các trình duyệt khác nhau có thể quyết định áp dụng độ nhiễu khác nhau tuỳ theo các mục tiêu về quyền riêng tư và các bên sẽ xử lý báo cáo sẽ cần biết được vấn đề này.
Tiếng ồn hoạt động như thế nào?
Trong đề xuất mới, tại thời điểm nguồn được đăng ký (tức là một lượt nhấp hoặc lượt xem quảng cáo được ghi lại), trình duyệt ngẫu nhiên sẽ quyết định xem có phân bổ chuyển đổi một cách chính xác và gửi báo cáo về việc này hay không lượt nhấp/lượt xem quảng cáo hoặc liệu quảng cáo có tạo ra đầu ra giả mạo hay không.
Kết quả đầu ra giả có thể là:
- Không có báo cáo nào – bất kể người dùng có chuyển đổi hay không;
- Một hoặc nhiều báo cáo giả mạo – bất kể người dùng có chuyển đổi hay không.
Trong báo cáo giả mạo, dữ liệu điều kiện kích hoạt (dữ liệu lượt chuyển đổi) là ngẫu nhiên: một giá trị 3 bit ngẫu nhiên cho các lượt nhấp (bất kỳ giá trị nào từ 0 đến 7) và một giá trị 1 bit ngẫu nhiên cho các khung hiển thị (0 hoặc 1).
Giống như báo cáo thực, báo cáo giả mạo không được gửi ngay sau khi người dùng chuyển đổi. Thời gian gửi: phần cuối của khoảng thời gian báo cáo ngẫu nhiên.
Có 3 khoảng thời gian báo cáo cho lượt nhấp (2 ngày, 7 ngày hoặc 30 ngày sau lượt nhấp). Mỗi giả mạo báo cáo được chỉ định ngẫu nhiên cho một trong các khoảng thời gian báo cáo.
Ngoài ra, như đề xuất trước đó đã nêu, thứ tự của các báo cáo trong một khoảng thời gian là ngẫu nhiên.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Ví dụ về lượt chuyển đổi giả mạo gây ồn
Tham gia cuộc thảo luận công khai
Giới hạn về báo cáo (báo cáo ở cấp sự kiện và báo cáo tổng hợp)
Điều gì sẽ thay đổi và tại sao?
Đề xuất mới giới hạn rõ ràng số bên có thể đo lường sự kiện giữa hai trang web.
- Số lượng nguồn gốc báo cáo riêng biệt tối đa (thường là công nghệ quảng cáo) có thể đăng ký nguồn cho mỗi {nhà xuất bản, nhà quảng cáo} được đề xuất giới hạn ở mức 100 nguồn mỗi 30 ngày. Chiến dịch này bộ đếm sẽ được tăng cho mỗi lượt nhấp hoặc lượt xem quảng cáo (sự kiện nguồn), ngay cả khi không được phân bổ.
- Số lượng tối đa các nguồn gốc báo cáo riêng biệt (thường là công nghệ quảng cáo) có thể gửi báo cáo cho mỗi {publisher, advertiser} được đề xuất giới hạn ở mức 10 lần mỗi 30 ngày. Bộ đếm này sẽ tăng lên cho mỗi lượt chuyển đổi được phân bổ.
Các giới hạn này được thiết kế đủ cao để không giới hạn khả năng đo lường của bất kỳ đối tượng nào lượt chuyển đổi, nhưng đủ thấp để giúp giảm thiểu một số hình thức sử dụng API sai mục đích.
Thời gian chờ trong báo cáo / giới hạn số lượng yêu cầu
Điều gì sẽ thay đổi và tại sao?
Thời gian chờ khi báo cáo là một cơ chế bảo vệ quyền riêng tư giúp điều tiết tổng lượng thông tin được gửi thông qua API này trong một khoảng thời gian nhất định cho người dùng.
Trong đề xuất mới, 100 báo cáo cho mỗi {nguồn trang web, đích, nguồn gốc báo cáo} (thường là {nhà xuất bản, nhà quảng cáo, công nghệ quảng cáo}) có thể được lên lịch trong 30 ngày.
Khi vượt quá giới hạn này, trình duyệt sẽ ngừng lập lịch báo cáo phù hợp với {source site, điểm đến, nguồn gốc báo cáo} (thường là {nhà xuất bản, nhà quảng cáo, công nghệ quảng cáo})—cho đến 30 ngày luân phiên số lượng báo cáo giảm xuống dưới 100 cho {nguồn trang web, đích, nguồn gốc báo cáo} đó.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Thời gian chờ / giới hạn số lượng yêu cầu trong báo cáo
Giới hạn đích đến (chỉ dành cho báo cáo ở cấp sự kiện)
Điều gì sẽ thay đổi và tại sao?
Giới hạn đích đến được sửa đổi để bao gồm nguồn gốc báo cáo (thường là công nghệ quảng cáo) trong phạm vi: 100 duy nhất đích đến đang chờ xử lý (thường là trang web của nhà quảng cáo hoặc trang web nơi lượt chuyển đổi dự kiến sẽ thực hiện vị trí) được phép cho mỗi {publisher, công nghệ quảng cáo}.
Đây là một biện pháp bảo vệ quyền riêng tư nhằm hạn chế việc tạo lại nhật ký duyệt web.
Tìm hiểu thêm trong phần giải thích về kỹ thuật
Giới hạn số lượng điểm đến riêng biệt thuộc phạm vi của các nguồn đang chờ xử lý
Tất cả tài nguyên
- Xem Báo cáo phân bổ.
- Hãy đọc bài viết Những điều bạn cần biết về API.
Hình ảnh tiêu đề là của Diana Polekhina trên Unsplash.