Đề xuất về Báo cáo phân bổ đã trải qua một số thay đổi để giải quyết ý kiến phản hồi của cộng đồng, từ các thay đổi về cơ chế API đến chức năng mới.
Nhật ký thay đổi
- Ngày 7 tháng 2 năm 2022: Thêm mục về 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.
Bài đăng này dành cho ai?
Bài đăng này dành cho bạn:
- Nếu bạn đã hiểu rõ API, ví dụ: nếu bạn đã quan sát hoặc tham gia các cuộc thảo luận về kho lưu trữ WICG và muốn tìm hiểu về loạt thay đổi đã thực hiện đố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 một bản minh hoạ hoặc trong một thử nghiệm trong môi trường 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 API này, hãy chuyển thẳng đến phần giới thiệu về API.
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 chính thức (bản dùng thử theo nguyên gốc), 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 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, nếu được triển khai, những thay đổi này sẽ không yêu cầu bạn làm gì hoặc di chuyển vì chưa có trình duyệt nào triển khai 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 báo cáo mà bạn có thể đã thấy được mô tả là báo cáo tổng hợp giờ đây sẽ được gọi là 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 quá trình tổng hợp nhiều báo cáo tổng hợp, trước đây gọi là giá trị đóng góp hoặc giá trị đóng góp cho biểu đồ.
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 (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 thông số khác). Giá trị của các tham số này do công nghệ quảng cáo đặt.
Cách đặt các thông số này sẽ thay đổi.
Trong đề xuất trước, các tham số phải được đưa vào phía máy khách: trong thẻ neo dưới dạng thuộc tính HTML hoặc dưới dạng đối số của lệnh gọi dựa trên JS. Bạn phải biết các thông số tại thời điểm nhấp hoặc xem.
Trong đề xuất mới, giá trị của các tham 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 đề cung cấp cho nguồn báo cáo (thường là một công nghệ quảng cáo) quyền kiểm soát trực tiếp đối với việc liệu một nguồn phân bổ có được đăng ký trong phạm vi của chúng hay không. Điều này giúp giảm bớt một phần các vấn đề về gian lận, vì với thay đổi này, trình duyệt chính hãng sẽ không bao giờ đăng ký một nguồn nếu nguồn đó không chọn tham gia 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, công nghệ quảng cáo hiện cần xác định một thuộc tính phía máy khách cụ thể
attributionsrc. Giá trị của thuộc tính này là một URL mà trình duyệt sẽ gửi yêu cầu đến; yêu cầu này sẽ bao gồm một tiêu đề HTTP mớiAttribution-Reporting-Source-Infocó giá trịnavigationhoặcevent,chỉ định nguồn là lượt nhấp hay lượt xem tương ứng. - 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 tiêu đề HTTP,
Attribution-Reporting-Register-Source, chứa các thông số phân bổ mong muốn. 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 xác định 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 kỹ thuật
Tham gia cuộc thảo luận công khai
Điều kiện kích hoạt 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 sẽ thay đổi trình kích hoạt phân bổ (khi một công nghệ quảng cáo hướng dẫn trình duyệt ghi lại một lượt chuyển đổi) thành phương pháp dựa trên tiêu đề.
Cơ chế này phù hợp với quy trình đăng ký nguồn dựa trên tiêu đề và thông thường hơn so với cơ chế chuyển hướng từng được sử dụng.
Ngoài ra, trong đề xuất mới, bạn cần có thuộc tính attributionsrc trên trang chuyển đổi.
Lý do là vấn đề về quyền: trong đề xuất trước, trang web bê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 này thông qua tiêu đề Permissions-Policy, nhưng không có quyền kiểm soát chi tiết ở cấp phần tử về việc một phần tử có thể gửi yêu cầu đến một bên hay không, từ đó kích hoạ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 cho phép nhà quảng cáo theo dõi và do đó kiểm soát những phần tử có thể kích hoạt mô hình phân bổ.
Xin lưu ý rằng ở phía nguồn (thường là trang web của nhà xuất bản), bạn sẽ thấy một chế độ kiểm soát trên toàn trang thông qua Permissions-Policy, cũng như một chế độ kiểm soát trên toàn phần tử thông qua attributionsrc.
Điều kiện kích hoạt mô hình 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 yêu cầu đó sẽ được phân loại là lượt chuyển đổi, công nghệ quảng cáo sẽ phản hồi bằng tiêu đề HTTP
mới 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. Đây là thông tin giống với thông tin đượ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à phản hồi chuyển hướng.
Nhờ đó, bên thứ ba có thể quan sát sự kiện chuyển đổi và hướng dẫn trình duyệt phân bổ sự kiện đó.
Bạn không bắt buộc phải chuyển hướng; bạn không cần phải chuyển hướng khi cả công nghệ quảng cáo và bên thứ ba đều có pixel trên trang.
Xem thêm thông tin chi tiết trong phần Báo cáo của bên thứ ba.
Tìm hiểu thêm trong phần giải thích kỹ thuật
Tham gia cuộc thảo luận công khai
Không có công việc (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 ra các báo cáo này.
Trong đề xuất mới, bạn không cần phải có worklet. Thay vào đó, công nghệ quảng cáo sẽ xác định theo cách khai báo (thông qua tiêu đề HTTP) các 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, đơn giản hơn đáng kể vì không yêu cầu 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 vào các tiêu đề mà các nhà phát triển thường sử dụng và biết đến rộng rãi, không giống như các worklet. API này cũng liên kết chặt chẽ với giao diện API để đăng ký nguồn, giúp bạn dễ dàng tìm hiểu và sử dụng API hơn.
- Sử dụng: thiết kế mới cho phép nhiều hệ thống đo lường hiện có sử dụng các báo cáo tổng hợp hơn. Nhiều giải pháp đo lường chỉ sử dụng giao thức HTTP: các giải pháp này dựa vào các yêu cầu hình ảnh (yêu cầu pixel) không yêu cầu quyền truy cập JavaScript. Tuy nhiên, vì phương pháp worklet yêu cầu quyền truy cập vào JavaScript, nên có thể khó di chuyển từ một số hệ thống đo lường hiện có.
- Độ mạnh mẽ: thiết kế mới giúp giảm thiểu việc mất dữ liệu vì dễ dàng tích hợp với ngữ nghĩa
keepalivehơn, ví dụ: nếu một lượt nhấp hoặc lượt xem được đăng ký khi người dùng rời khỏi 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 đề điều kiện kích hoạt phân bổ. Bạn có thể xem thêm 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)
Chúng tôi đề xuất một cơ chế mới để đăng ký nguồn cho báo cáo tổng hợp; cơ chế này giống với 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 kỹ thuật
Điều kiện kích hoạt phân bổ dựa trên tiêu đề (báo cáo tổng hợp)
Chúng tôi đề xuất một cơ chế mới để đăng ký nguồn cho báo cáo tổng hợp; cơ chế này giống với đ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 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?
Đề xuất mới có hai khía cạnh giúp hỗ trợ tốt hơn các trường hợp sử dụng báo cáo của bên thứ ba:
- Nếu muốn, công nghệ quảng cáo có thể chuyển hướng các yêu cầu mạng đến máy chủ của các công nghệ quảng cáo khác, cho phép các công nghệ quảng cáo khác đó thực hiện việc đăng ký nguồn và điều kiện kích hoạt của riêng mình. Đây là cách phổ biến để định cấu hình bên thứ ba hiện nay. Điều này giúp API dễ dàng được áp dụng hơn so với các API khác trong các hệ thống báo cáo hiện có 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 chia sẻ hầu hết các giới hạn về quyền riêng tư. Điều này hỗ trợ các trường hợp sử dụng trong đó 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.
Tính năng 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. 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 một yêu cầu nhấp/xem trên trang web của nhà xuất bản (đăng ký nguồn) sau đó được chuyển hướng đến nhiều bên, thì mỗi bên trong số này có thể đăng ký lượt xem hoặc lượt nhấp này (sự kiện nguồn).
Tương tự, 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ý 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 báo cáo riêng 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 lượt 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 lượt xem (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, phương pháp đo lường lượt xem và phương pháp đo lường lượt nhấp hoạt động theo cách thống nhất:
registerattributionsrc, thuộc tính dành riêng cho chế độ xem đã hướng dẫn trình duyệt ghi lại số lượt xem cùng với số lượt nhấp, không còn nằm trong đề xuất này.- Cơ chế quyền riêng tư hiện được hợp nhất trên 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 Độ nhiễu và độ trong suốt.
Thay đổi này được đề xuất để phù hợp với cơ chế đăng ký dựa trên tiêu đề mới. Điều này cũng đơn giản hoá trải nghiệm của nhà phát triển khi có ý định hỗ trợ cả tính năng đo lường lượt nhấp và lượt xem.
Tính năng đo lường lượt xem hết hoạt động như thế nào?
Cả phương pháp đo lường lượt xem hết và phương pháp đo lường lượt nhấp đều dựa vào quy trình đăng ký dựa trên tiêu đề.
Tìm hiểu thêm trong phần giải thích kỹ thuật
Báo cáo ở cấp sự kiện (dành 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?
Chúng tôi đã thêm một cơ chế gỡ lỗi vào đề xuất này để 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ó.
Quá trình 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 chấp nhận tham số mới debug_key, một số nguyên 64 bit chưa ký (tức là một số lớn).
Nếu 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, đồng thời nếu cookie Samesite=None ar_debug=1 có trong hộp cookie của nguồn báo cáo tại thời điểm đăng ký nguồn và điều kiện kích hoạt, thì báo cáo gỡ lỗi (JSON) sẽ được gửi đến điểm cuối .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Báo cáo cấp sự kiện và báo cáo tổng hợp cũng sẽ bao gồm hai thông số mới này để có thể 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 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
Tính 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ì các sự kiện này hỗ trợ các trường hợp sử dụng quan trọng trong hệ sinh thái quảng cáo hiện nay, nên một số trường hợp sử dụng 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. Ví dụ: chọn nhiều dữ liệu điều kiện kích hoạt (dữ liệu chuyển đổi) cho lượt nhấp vào quảng cáo và lượt xem.
- Không khớp mô hình phân bổ: lọc những lượt chuyển đổi đã được phân bổ không chính xác; đây là một loại bộ lọc lượt chuyển đổi cụ thể. Ví dụ: lọc ra những 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 etld+1 trong API.
Các tính năng lọc hoạt động như thế nào? (dành cho 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 mà trình duyệt sẽ sử dụng sau đó 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"}
}
}
Giờ đây, quy trình đăng ký điều kiện kích hoạt sẽ chấp nhận tiêu đề Attribution-Reporting-Filters không bắt buộc.
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 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 JSON bộ lọc khớp với các khoá trong source_data, thì trình kích hoạt sẽ hoàn toàn bị bỏ qua nếu giao điểm trống.
Tìm hiểu thêm trong phần giải thích kỹ thuật
Bộ lọc mô hình phân bổ không bắt buộc
Tham gia cuộc thảo luận công khai
Thay đổi về tính năng bảo vệ quyền riêng tư
Độ nhiễu và độ 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 các cơ chế bảo vệ quyền riêng tư cho báo cáo đã được cải thiện: báo cáo phải tuân theo phản hồi ngẫu nhiên.
Tức là một số lượt chuyển đổi thực sẽ được báo cáo chính xác; và trong một tỷ lệ phần trăm nhất định
thời gian, một số lượt chuyển đổi thực sẽ bị chặn hoặc một số lượt chuyển đổi giả mạo sẽ được thêm vào.
Kỹ thuật mới này có một số lợi ích:
- Cơ chế này hợp nhất cơ chế quyền riêng tư cho lượt nhấp và lượt xem.
- Cách này đơn giản hơn so với cơ chế tách riêng dữ liệu điều kiện kích hoạt (dữ liệu lượt chuyển đổi) và tạp âm liên kết điều kiện kích hoạt-nguồn.
- API này thiết lập một khung quyền riêng tư có thể đảm bảo rằng không bên nào có thể dựa vào API để biết chắc chắn rằng một người dùng riêng lẻ đã chuyển đổi (hoặc không) cho một quảng cáo nhất định, với các chế độ cài đặt nhiễu phù hợp.
Cơ chế mới này thay thế cơ chế trước đó, trong đó 5% thời gian, dữ liệu điều kiện kích hoạt (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 (trường randomized_trigger_rate). Trường này chỉ định xác suất (từ 0 đến 1) để một nguồn chịu sự phản hồi ngẫu nhiên.
Điều này có hai lợi ích chính:
- Tính năng này giúp các bên nhận được báo cáo (thường là các công nghệ quảng cáo) nắm được toàn bộ hành vi cơ bản của trình duyệt.
- Điều này sẽ hữu ích trong tương lai khi API được hỗ trợ trên các trình duyệt: các trình duyệt khác nhau có thể quyết định áp dụng các mức độ nhiễu khác nhau tuỳ thuộc vào mục tiêu quyền riêng tư của chúng, và các bên sẽ xử lý báo cáo sẽ cần biết được điều này.
Độ nhiễu hoạt động như thế nào?
Trong đề xuất mới, tại thời điểm một 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 sẽ quyết định ngẫu nhiên xem liệu trình duyệt có phân bổ chính xác lượt chuyển đổi và gửi báo cáo cho lượt nhấp/lượt xem quảng cáo này hay không, hoặc liệu trình duyệt có tạo kết quả giả mạo hay không.
Kết quả 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 lượt nhấp (bất kỳ số nào từ 0 đến 7) và một giá trị 1 bit ngẫu nhiên cho lượt xem (0 hoặc 1).
Giống như báo cáo thực, báo cáo giả mạo sẽ không được gửi ngay sau khi người dùng chuyển đổi. Các báo cáo này được gửi vào cuối một 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 khi nhấp). Mỗi báo cáo giả mạ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ư đã nêu trong đề xuất trước, 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 kỹ thuật
Ví dụ về lượt chuyển đổi giả mạo không chính xác
Tham gia cuộc thảo luận công khai
Giới hạn 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ố lượng bên có thể đo lường sự kiện giữa hai trang web.
- Số lượng tối đa nguồn gốc báo cáo riêng biệt (thường là công nghệ quảng cáo) có thể đăng ký nguồn cho mỗi {publisher, advertiser} được đề xuất là 100 nguồn trong 30 ngày. Bộ đếm này sẽ được tăng lên cho mỗi lượt nhấp vào quảng cáo hoặc lượt xem quảng cáo (sự kiện nguồn), ngay cả những lượt không được phân bổ.
- Số lượng tối đa 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 {nhà xuất bản, nhà quảng cáo} được đề xuất là 10 báo cáo trong 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 lượt chuyển đổi của bất kỳ thực thể nào, nhưng đủ thấp để giúp giảm thiểu một số hình thức sử dụng sai API.
Báo cáo thời gian quan sát thêm / giới hạn tốc độ
Điều gì sẽ thay đổi và tại sao?
Thời gian chờ 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, bạn có thể lên lịch gửi 100 báo cáo cho mỗi {source site, destination, reporting origin} (thường là {publisher, advertiser, adtech}) trong 30 ngày.
Ngoài giới hạn này, trình duyệt sẽ ngừng lên lịch báo cáo khớp với {source site, destination, reporting origin} (thường là {publisher, advertiser, adtech}) đã cho này cho đến khi số lượng báo cáo trong 30 ngày liên tục giảm xuống dưới 100 cho {source site, destination, reporting origin} đó.
Tìm hiểu thêm trong phần giải thích kỹ thuật
Báo cáo thời gian chờ / hạn mức tần suất
Giới hạn đích đến (chỉ áp dụng 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 để đưa nguồn gốc báo cáo (thường là một công nghệ quảng cáo) vào phạm vi: 100 đích đến đang chờ xử lý duy nhất (thường là trang web của nhà quảng cáo hoặc trang web dự kiến sẽ diễn ra lượt chuyển đổi) được cho phép trên mỗi {publisher, adtech}.
Đây là một biện pháp bảo vệ quyền riêng tư để hạn chế việc khôi phục nhật ký duyệt web.
Tìm hiểu thêm trong phần giải thích kỹ thuật
Giới hạn số lượng các điểm đến riêng biệt mà nguồn đang chờ xử lý bao gồm
Tất cả tài nguyên
- Xem phần Báo cáo phân bổ.
- Đọ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.