Đề xuất 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ừ việc thay đổi cơ chế API sang 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ề lệnh chuyển hướng của trình 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.
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 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 tìm hiểu loạt thay đổi đối với đề xuất vào tháng 1 năm 2022).
- Bạn đang sử dụng Attribution Reporting API trong bản minh hoạ hoặc trong thử nghiệm trên thực tế.
Nếu bạn chỉ mới bắt đầu sử dụng API này và/hoặc chưa thử nghiệm, hãy chuyển thẳng đến phần giới thiệu về API.
Di chuyển trước
Sau khi những thay đổi này được triển khai trong Chrome: nếu sử dụng các báo cáo cấp sự kiện từ Attribution Reporting API trong bản minh hoạ hoặc trong thử nghiệm ở phiên bản chính thức (bản dùng thử theo nguyên gốc), bạn sẽ phải 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, nếu được triển khai, những thay đổi này sẽ không yêu cầu hành động hay di chuyển vì trình duyệt chưa 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 gì 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 việc tổng hợp nhiều báo cáo tổng hợp, trước đây được gọi là đóng góp hoặc biểu đồ đóng góp.
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 một quảng cáo, trình duyệt (ngay 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 thiết lập các thông số này đang thay đổi.
Trong đề xuất trước đó, các thông số phải được bao gồm phía máy khách: trong thẻ ký tự liên kết 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. Tham số phải xác định tại thời điểm nhấp hoặc thời điểm xem.
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.
Việc này có một số ưu điểm, đặc biệt là về mặt bảo mật: cơ chế tiêu đề giúp nguồn gốc báo cáo (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 của chúng hay không. Điều này giảm thiểu một phần lo ngại về hành vi gian lận, vì với thay đổi này, một trình duyệt thực sự sẽ không bao giờ đăng ký nguồn nếu không có lựa chọn tham gia của nguồn 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 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 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 tương ứng 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 tiêu đề HTTP
Attribution-Reporting-Register-Sourcecó chứa các thông số phân bổ mong muốn. Nguồn 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?
Tương tự như quy trình đăng ký lượt nhấp hoặc lượt xem, đề xuất mới sẽ thay đổi điều kiện kích hoạt phân bổ (khi 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à mang tính thông thường hơn so với cơ chế chuyển hướng đã dùng trước đây.
Ngoài ra, trong đề xuất mới, thuộc tính attributionsrc là cần thiết trên trang chuyển đổi.
Lý do nằm ở vấn đề về quyền: trong đề xuất trước đây, 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 tính năng 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 liệu một phần tử có thể gửi yêu cầu đến một bên sẽ kích hoạt phân bổ hay không. attributionsrc sẽ 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à từ đó kiểm soát những phần tử có thể kích hoạt hoạt động 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 chế độ kiểm soát trên toàn trang thông qua Permissions-Policy và chế độ kiểm soát trên toàn phần tử thông qua attributionsrc.
Trình kích hoạt phân bổ hoạt động như thế nào?
Khi nhận được yêu cầu pixel và quyết định phân loại yêu cầu đó là lượt chuyển đổi, công nghệ quảng cáo cần 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 là đối tượng JSON. Đây cũng chính là 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)
Máy chủ công nghệ quảng cáo có thể đưa ra phản hồi chứa Attribution-Reporting-Register-Event-Trigger phản hồi chuyển hướng (không bắt buộc).
Nhờ đó, các 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 đó.
Việc chuyển hướng là không bắt buộc và không cần thiết khi cả công nghệ quảng cáo và bên thứ ba đều có pixel trên trang.
Bạn có thể tìm thêm thông tin chi tiết trong bài viết Báo cáo 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ó worklet (báo cáo tổng hợp)
Điều gì sẽ thay đổi và tại sao?
Trong đề xuất trước đây dành cho báo cáo tổng hợp, bạn cần có quyền truy cập JavaScript để gọi một công việc (một 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 yêu cầu 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 các tiêu đề HTTP) các quy tắc mà trình duyệt sẽ 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 cho nhà phát triển: thiết kế mới dựa trên 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ư worklet. API này cũng phù hợp với giao diện API để đă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 báo cáo tổng hợp. Nhiều giải pháp đo lường chỉ dành cho 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, do phương pháp worklet bộ công việc yêu cầu quyền truy cập vào JavaScript, nên có thể khó chuyển sang 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 lượng dữ liệu mất đi vì dễ tích hợp hơn với ngữ nghĩa
keepalive, chẳng hạn như khi 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 các tiêu đề HTTP – giống như hoạt động đă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ổ. Bạn có thể tìm hiểu thêm về nội dung 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 báo cáo tổng hợp; cơ chế này giống như cơ chế đă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)
Một cơ chế mới được đề xuất để đăng ký nguồn cho báo cáo tổng hợp; cơ chế này 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 kỹ thuật
Đăng ký trình 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 này 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:
- 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ông nghệ quảng cáo khác (không bắt buộc), cho phép các công nghệ quảng cáo đó thực hiện đăng ký nguồn và điều kiện kích hoạt riêng. Đây là một cách phổ biến để định cấu hình các bên thứ ba ngay hôm nay. Điều này giúp bạn dễ dàng sử dụng API này, cùng với các API khác trong các hệ thống báo cáo bên thứ ba hiện có.
- Các 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ợ 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.
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 dựa trên 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 những 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ý một lượt chuyển đổi (điều kiện kích hoạt phân bổ).
Mỗi bên đều có thể truy cập vào các báo cáo riêng của mình và thiết lập các 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 hế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?
Trong đề xuất mới, tính năng đo lường lượt xem hết và đo lường lượt nhấp hoạt động theo cách thống nhất:
registerattributionsrc, thuộc tính theo từng khung hiển thị đã hướng dẫn trình duyệt ghi lại các 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ế bảo mật hiện được hợp nhất cho 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. Bản ghi này cũng giúp đơn giản hoá trải nghiệm của nhà phát triển khi có ý định hỗ trợ cả hoạt động đo lường lượt nhấp và lượt xem hết.
Tính năng đ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à đo lường lượt nhấp đều dựa trên việc đă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 (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 cơ chế gỡ lỗi 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ó.
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. Đây là 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 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, 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
}
Các báo cáo tổng hợp và báo cáo cấp sự kiện cũng sẽ bao gồm 2 thông số mới này để có thể liên kết với đúng báo cáo gỡ lỗi.
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
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ì các báo cáo 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 ngày nay, nên một số trường hợp sử dụng hiện sẽ được hỗ trợ trong cả báo cáo tổng hợp và báo cáo cấp sự kiện:
- Lọc lượt chuyển đổi: lọc một lượt chuyển đổi dựa trên thông tin phía nguồn. 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 bị phân bổ không đúng; đây là một 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.
Chức năng lọc hoạt động như thế nào? (đối với các 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ẽ được trình duyệt 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, việc đăng ký điều kiện kích hoạt sẽ chấp nhận tiêu đề không bắt buộc là Attribution-Reporting-Filters.
Tiêu đề phản hồi HTTP Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Ngoài ra, tiêu đề Attribution-Reporting-Register-Event-Trigger có thể được mở rộng bằng trường filters để thực hiện 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 khoá trong source_data, thì điều kiện kích hoạt sẽ
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 kỹ thuật
Tham gia cuộc thảo luận công khai
Những thay đổi về việc 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ế quyền riêng tư cho báo cáo đã được cải thiện: báo cáo sẽ phải phản hồi ngẫu nhiên.
Điều này có nghĩa 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, 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ả sẽ được thêm vào.
Kỹ thuật mới này có một vài lợi ích:
- Hộp cát về quyền riêng tư hợp nhất cơ chế bảo vệ quyền riêng tư cho số lượt nhấp và lượt xem.
- Lý do đơn giản hơn so với cơ chế tách biệt dữ liệu điều kiện kích hoạt (dữ liệu lượt chuyển đổi) và nhiễu liên kết nguồn điều kiện kích hoạt.
- AI của Google thiết lập một khung về quyền riêng tư để có chế độ cài đặt độ nhiễu phù hợp giúp đảm bảo 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 cá nhân đã chuyển đổi (hoặc không chuyển đổi) 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, 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 (0 đến 1) mà một nguồn phải dùng phản hồi ngẫu nhiên.
Việc này có hai lợi ích chính:
- Điều này giúp hành vi cơ bản của trình duyệt transparent với các bên sẽ nhận được báo cáo (thường là công nghệ quảng cáo).
- Đ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 về quyền riêng tư và các bên xử lý báo cáo sẽ cần biết thông tin 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 sẽ quyết định ngẫu nhiên liệu sẽ phân bổ chính xác cá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 sẽ tạo kết quả giả.
Kết quả đầu ra giả mạo 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 các 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 (số bất kỳ từ 0 đến 7) và một giá trị 1 bit ngẫu nhiên cho các lượt xem (0 hoặc 1).
Giống như báo cáo thực tế, báo cáo giả mạo không được gửi ngay sau khi người dùng chuyển đổi. Hệ thống sẽ gửi báo cáo vào cuối 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 xảy ra lượt 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.
Riêng biệt, như đề xuất trước đó đã nêu, thứ tự của các báo cáo trong một thời lượng 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ả gây nhiều tiếng ồn
Tham gia cuộc thảo luận công khai
Các 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ố lượng 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 {publisher, advertiser} được đề xuất giới hạn ở mức 100 nguồn/30 ngày. Bộ đếm này sẽ tăng lên 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ổ.
- Đề xuất giới hạn 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} là 10 nguồn gốc mỗi 30 ngày. Bộ đếm này sẽ tăng lên đối với mọi lượt chuyển đổi được phân bổ.
Các giới hạn này nhằm đủ cao để không giới hạn khả năng đo lường lượt chuyển đổi của bất kỳ bên nào, nhưng cũ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ờ 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ờ báo cáo là một cơ chế bảo vệ quyền riêng tư điều tiết tổng lượng thông tin được gửi 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 cho 100 báo cáo cho mỗi {trang web nguồn, đích, nguồn báo cáo} (thường là {nhà xuất bản, nhà quảng cáo, công nghệ quảng cáo}) trong 30 ngày.
Vượt quá giới hạn này, trình duyệt sẽ ngừng lập lịch các báo cáo khớp với {source site, destination, reporting origin} (thường là {publisher, nhà quảng cáo, công nghệ quảng cáo}) này, cho đến khi số lượng báo cáo trong 30 ngày luân phiên 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
Thời gian chờ báo cáo / giới hạn số lượng yêu cầu
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à một công nghệ quảng cáo) trong phạm vi: cho phép 100 đích đến riêng biệt đ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ẽ diễn ra) cho mỗi {publisher,công nghệ quảng cáo}.
Đây là 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 kỹ thuật
Giới hạn số lượng đích đế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
Hình ảnh tiêu đề là của Diana Polekhina trên Unsplash.