기여 분석 보고서 제안서는 API 메커니즘 변경사항부터 새로운 기능에 이르기까지 커뮤니티 의견 반영
변경 로그
- 2022년 2월 7일: 헤더 트리거 리디렉션에 관한 섹션이 추가되었습니다.
- 2022년 1월 27일: 도움말이 처음 게시됨.
이 게시물은 누구를 대상으로 하나요?
이 게시물은 나를 위한 것입니다.
- API에 대해 이미 이해하고 있는 경우, 예를 들어 API를 관찰했거나 WICG 저장소에서 이루어지는 토론에 참여하고, 2022년 1월에 제안 변경사항이 있을 수 있습니다.
- 데모 또는 프로덕션 실험에서 Attribution Reporting API를 사용 중입니다.
이 API를 처음 사용하거나 아직 실험해 보지 않았다면 (으)로 API 소개 하세요.
마이그레이션 예정
이러한 변경사항이 Chrome에 구현되면 데모 또는 프로덕션 실험 (오리진 트라이얼)에서 Attribution Reporting API의 이벤트 수준 보고서를 사용하는 경우 API가 계속 작동하도록 코드를 수정해야 합니다. 새로운 기능을 사용해 보세요.
이 도움말에는 집계 가능한 보고서에 적용되는 변경사항도 나와 있습니다. 하지만 이 문서의 작성 시점에는 집계 가능한 보고서를 위한 브라우저 구현이 아직 없으므로 구현되는 경우 별도의 조치나 이전이 필요하지 않습니다.
이름 변경
요약 보고서 및 집계 가능한 보고서
종합 보고서로 볼 수 있는 내용은 이제 요약 보고서로 사용할 수 있습니다.
요약 보고서는 여러 집계 가능한 보고서를 종합한 결과입니다. 이전에는 기여 또는 히스토그램 참여라고 했습니다.
API 메커니즘 변경사항
헤더 기반 소스 등록 (이벤트 수준 보고서)
변경되는 사항과 이유는 무엇인가요?
사용자가 광고를 보거나 클릭하면 브라우저가 사용자 기기의 로컬에 이 이벤트를 기록합니다.
속성 보고 전용 매개변수 (예:
attributionsourceeventid, attributiondestination, attributionexpiry 및 기타 매개변수). 이
이러한 매개변수의 값은 광고 기술에서 설정합니다.
이러한 매개변수의 설정 방식이 바뀌고 있습니다.
이전 제안서에서는 매개변수를 클라이언트 측(앵커 태그 HTML 속성 또는 JS 기반 호출의 인수로 사용됩니다. 클릭 또는 조회 시 매개변수를 알아야 함 있습니다.
새 제안서에서는 이러한 매개변수의 값이 대신 광고 기술 서버에서 정의됩니다.
이 방식에는 여러 가지 장점이 있는데, 특히 보안 측면에서는 여러 가지 장점이 있습니다. 헤더 메커니즘은 출처(일반적으로 광고 기술)에서 기여 분석 소스가 범위를 제공합니다 이렇게 변경하면 사기 우려가 부분적으로 완화됩니다. 이 변경사항으로 인해 실제 브라우저는 보고 출처의 선택 없이 소스를 등록
소스 등록은 어떻게 작동하나요?
- 이제 광고 기술은 특정 광고에 대해 특정 클라이언트 측 속성을 정의해야 합니다.
attributionsrc이 속성의 값은 브라우저에서 request; 이 요청에는 새 HTTP 헤더Attribution-Reporting-Source-Info가 포함됩니다. 값navigation또는event,소스가 각각 클릭인지 조회인지를 지정합니다. - 이 요청을 받으면 클릭/조회 추적 서버가 HTTP
원하는 속성이 포함된
Attribution-Reporting-Register-Source헤더 매개변수입니다. 이제 이 헤더를 반환하는 출처가 보고 출처입니다 (이전에는
attributionreportto)을 입력합니다.HTTP 응답 헤더
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
기술 설명에서 자세히 알아보기
공개 토론 참여
헤더 기반 기여 분석 트리거 (이벤트 수준 보고서)
변경되는 사항과 이유는 무엇인가요?
클릭 또는 조회 등록과 마찬가지로 새 제안은
adtech는 브라우저에 헤더 기반 접근 방식으로 전환을 기록하도록 지시합니다.
이 메커니즘은 헤더 기반 소스 등록과 일치합니다.
기존에 사용된 리디렉션 메커니즘보다 전통적인 방식을 사용합니다.
또한 새 제안서에서는 attributionsrc 속성이 전환 페이지에 필요합니다.
그 이유는 권한의 문제입니다. 이전 제안서에서는 트리거 측 사이트(일반적으로
광고주 사이트: Permissions-Policy 헤더를 통해 기능을 전반적으로 제어할 수 있었지만
요소가 상대방에게 요청을 보낼 수 있는지 여부에 대한 세분화된 요소 수준 제어 기능이 없음
기여 분석을 트리거하게 됩니다 attributionsrc이(가) 다음을 변경합니다. 이 필수 마커
광고주는 이 기능을 통해 전환 액션을 트리거할 수 있는 요소를 모니터링하고 제어할 수 있습니다.
저작자 표시입니다.
소스 측(일반적으로 게시자 사이트)에서는
Permissions-Policy 및 attributionsrc를 통한 요소 전체 컨트롤이 있습니다.
기여 분석 트리거는 어떻게 작동하나요?
픽셀 요청을 받고 전환으로 분류되어야 한다고 판단한 광고 기술은
새 HTTP로 응답해야 합니다.
헤더 Attribution-Reporting-Register-Event-Trigger.
이 헤더의 값은 트리거 이벤트를 JSON 객체로 처리하는 방법을 지정합니다. 이것도 검색어 매개변수로 정의된 정보를 생성할 수 있습니다.
HTTP 응답 헤더 Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
리디렉션 (선택사항)
선택적으로 광고 기술 서버는 Attribution-Reporting-Register-Event-Trigger가 포함된 응답을 리디렉션 응답으로 만들 수 있습니다.
이렇게 하면 서드 파티가 전환 이벤트를 관찰하고 브라우저에 기여도를 부여하도록 지시할 수 있습니다.
리디렉션은 선택사항입니다. 광고 기술과 서드 파티 모두 페이지에 픽셀이 있는 경우에는 필요하지 않습니다.
자세한 내용은 서드 파티 보고를 참조하세요.
기술 설명에서 자세히 알아보기
공개 토론 참여
Worklet 없음 (집계 가능한 보고서)
변경되는 사항과 이유는 무엇인가요?
집계 가능한 보고서에 대한 이전 제안에서는 worklet을 사용하여 이러한 보고서를 생성합니다.
새 제안서에서는 Worklet이 필요하지 않습니다. 대신 광고 기술은 HTTP를 통해 선언적으로 정의합니다. 헤더: 브라우저에서 집계 가능한 보고서를 생성하기 위해 사용해야 하는 규칙입니다.
새 제안서에는 다음과 같은 몇 가지 이점이 있습니다.
- 브라우저 구현: 새로운 디자인은 워크렛 디자인과 달리 상당히 브라우저에서 새로운 실행 환경이 필요하지 않기 때문에 더 간단합니다.
- 개발자 환경: 새로운 디자인은 흔히 사용되며 널리 알려진 워크렛과 다릅니다 또한 API 노출 영역과 밀접하게 소스 등록으로 API를 더 쉽게 배우고 사용할 수 있습니다.
- 채택: 새로운 설계를 사용하면 더 많은 기존 측정 시스템에서 집계 가능한 있습니다. 많은 측정 솔루션이 HTTP 전용이며 이미지 요청(픽셀)을 사용합니다. JavaScript 액세스가 필요하지 않은 요청입니다. 하지만 Worklet 접근 방식에는 JavaScript 액세스가 있다면 일부 기존 측정 시스템에서 이전하기 어려웠을 수 있습니다.
- 견고성: 새로운 디자인은 통합하기가 더 쉬우므로 데이터 손실을 줄이는 데 도움이 됩니다.
keepalive의미 체계를 사용합니다. 예를 들어 사용자가 떠날 때 클릭 또는 조회가 등록되는 경우 있습니다.
Worklet-free 메커니즘은 어떻게 작동하나요?
이 선언적 메커니즘은 이벤트 수준의 소스 등록과 마찬가지로 HTTP 헤더를 기반으로 합니다. 기여 분석 트리거 헤더가 있습니다 이에 관한 자세한 내용은 다음 섹션을 참고하세요.
공개 토론 참여
헤더 기반 소스 등록 (집계 가능한 보고서)
집계 가능한 보고서의 소스를 등록하는 새로운 메커니즘이 제안됩니다. 이 메커니즘은 이벤트 수준 소스 등록과 동일합니다.
헤더 이름만 다릅니다(Attribution-Reporting-Register-Aggregatable-Source).
기술 설명에서 자세히 알아보기
헤더 기반 기여 분석 트리거 (집계 가능한 보고서)
집계 가능한 보고서의 소스를 등록하는 새로운 메커니즘이 제안됩니다. 이 메커니즘은 이벤트 수준 기여 분석 트리거와 동일합니다.
헤더 이름만 다릅니다(Attribution-Reporting-Register-Aggregatable-Trigger-Data).
기술 설명에서 자세히 알아보기
새로운 기능
타사 보고 (이벤트 수준 보고서 및 집계 가능한 보고서)
변경되는 사항과 이유는 무엇인가요?
새로운 제안의 두 가지 측면은 서드 파티 보고 사용 사례를 더 잘 지원하는 데 도움이 됩니다.
- 선택적으로 광고 기술은 네트워크 요청을 다른 광고 기술 서버로 리디렉션하여 광고 기술을 사용하여 자체 소스 및 트리거 등록을 실행합니다. 셋째, 일반적인 방법으로 오늘 구성되었습니다 이렇게 하면 기존 서드 파티 보고 시스템을 사용하지 않는 것이 좋습니다
- 보고 출처(일반적으로 광고 기술)는 더 이상 대부분의 개인 정보 보호 제한을 공유하지 않습니다. 이는 여러 광고 기술이 동일한 게시자 또는 광고주와 작동하는 경우
제3자 보고는 어떻게 작동하나요?
새로운 제안에서는 응답 기반 소스 등록 및 트리거가 HTTP 헤더. 광고 기술은 이러한 요청에 HTTP 리디렉션을 활용할 수 있습니다.
이후에 게시자 사이트에 대한 클릭/조회 요청 (소스 등록)이
각 당사자가 이 뷰 또는 클릭 (소스 이벤트)을 등록할 수 있습니다.
마찬가지로 광고 기술은 구매자 사이트에서 보낸 특정 기여 분석 요청을 리디렉션할 수 있습니다.
여러 다른 당사자가 전환을 등록할 수 있음 (기여 분석 트리거)
각 당사자는 각자의 개별 보고서에 액세스하고, 별도의 데이터로 보고서를 구성할 수 있습니다.
리디렉션 없이 여러 트리거 등록
전환 측에 여러 픽셀 요소 (트리거당 하나)를 추가하면 리디렉션을 사용하지 않고 여러 기여 분석 트리거를 등록할 수도 있습니다.
공개 토론 참여
조회 완료 측정 (이벤트 수준 보고서 및 집계 가능한 보고서)
변경되는 사항과 이유는 무엇인가요?
새 제안에서는 조회 후 측정과 클릭연결 측정이 통합된 방식으로 작동합니다.
registerattributionsrc: 브라우저에 다음과 같이 지시한 뷰별 속성입니다. 클릭수와 함께 조회수를 기록하는 기능은 더 이상 제안서에 포함되지 않습니다.- 이제 클릭과 조회에서 개인 정보 보호 메커니즘이 통합되었습니다. 자세한 내용은 노이즈 투명성을 갖춰야 합니다.
이 변경사항은 새로운 헤더 기반 등록 메커니즘에 부합하기 위해 제안되었습니다. 또한 클릭연결 및 조회연결을 모두 지원하려는 경우 개발자 환경이 간소화됩니다. 있습니다.
조회 후 측정의 작동 방식
조회 후 측정과 클릭연결 측정은 모두 헤더 기반 등록을 사용합니다.
기술 설명에서 자세히 알아보기
공개 토론 참여
디버깅 / 성능 분석 (이벤트 수준 보고서 및 집계 가능한 보고서)
변경되는 사항과 이유는 무엇인가요?
디버깅 메커니즘이 제안서에 추가되어 개발자가 버그를 감지하고 기여도 보고의 실적을 기존의 쿠키 기반 측정 솔루션과 비교
디버깅은 어떻게 작동하나요?
소스 및 트리거 등록은 모두 부호 없는 64비트인 새 매개변수 debug_key를 허용합니다.
정수 (즉, 큰 수)입니다.
소스 디버그 키와 트리거 디버그 키로 보고서를 만든 경우와 Samesite=None ar_debug=1 쿠키가 있는지 확인합니다.
소스 및 트리거 등록 시간에 보고 출처의 쿠키 jar에 있는 경우 디버그
보고서 (JSON)가 .well-known/attribution-reporting/debug 엔드포인트로 전송됩니다.
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
이벤트 수준 보고서와 집계 가능한 보고서에는 이러한 두 가지 새로운 매개변수가 포함되므로 올바른 디버그 보고서와 연결되어 있는지 확인합니다.
기술 설명에서 자세히 알아보기
공개 토론 참여
필터링 기능 (이벤트 수준 보고서 및 집계 가능한 보고서)
변경되는 사항과 이유는 무엇인가요?
오늘날의 광고 생태계에서 중요한 사용 사례를 지원하기 때문에 이제 이벤트 수준 보고서와 집계 가능한 보고서에서 모두 지원됩니다.
- 전환 필터링: 소스 측 정보를 기준으로 전환을 필터링합니다. 대상 예를 들어 광고 클릭 및 조회에 대해 다른 트리거 데이터 (전환 데이터)를 선택합니다.
- 기여 분석 불일치: 기여도가 잘못 부여된 전환을 필터링합니다. 이것은 특정 유형의 전환 필터링에 대해 알아보겠습니다. 예를 들어 '광고주'와 '일치하는 전환'을 API의 etld+1 대상 범위로 인해 잘못된 광고 클릭/조회가 발생합니다.
필터링 기능은 어떻게 작동하나요? (이벤트 수준 보고서의 경우)
소스 측 JSON 객체의 선택적 source_data 필드는
필터링 로직을 적용하기 위해 전환 시 브라우저에서 사용합니다.
{
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"}
}
}
이제 트리거 등록에서 선택적 헤더 Attribution-Reporting-Filters를 허용합니다.
HTTP 응답 헤더 Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
또는 Attribution-Reporting-Register-Event-Trigger 헤더를 다음과 같이 확장할 수 있습니다.
filters 필드를 사용하여 source_data에 따라 trigger_data를 설정하는 선택적 필터링을 실행합니다.
필터 JSON의 키가 source_data의 키와 일치하면 트리거는
입니다.
교집합이 비어 있으면 완전히 무시됩니다.
기술 설명에서 자세히 알아보기
공개 토론 참여
개인 정보 보호 기능 변경사항
노이즈와 투명성 (이벤트 수준 보고서 및 집계 가능한 보고서)
변경되는 사항과 이유는 무엇인가요?
새 제안에서는 보고서의 개인 정보 보호 메커니즘 중 하나가 개선되었습니다. 보고서는
무작위 응답이 적용됩니다.
즉, 일부 실제 전환이 올바르게 보고됩니다. 특정 비율의 광고가
일부 실제 전환은 억제되고 일부 허위 전환이 추가됩니다.
이 새로운 기법에는 몇 가지 이점이 있습니다.
- 클릭수와 조회수에 대한 개인 정보 보호 메커니즘을 통합합니다.
- 트리거 데이터 (전환 데이터)와 트리거-소스 링크 노이즈가 분리되는 메커니즘보다 추론이 더 간단합니다.
- 적절한 노이즈 설정으로 어떤 당사자도 API에 의존하여 개별 사용자의 특정 광고 전환 여부를 확실하게 알 수 있도록 하는 개인 정보 보호 프레임워크를 설정합니다.
이 새로운 메커니즘은 5% 의 확률로 데이터를 트리거한 기존 메커니즘을 대체합니다. (전환 데이터)이 임의의 값으로 대체되었습니다.
또한 무작위 응답 가능성 값이 보고서 본문에 추가되었습니다.
(randomized_trigger_rate 필드) 이 필드는 소스가 특정 데이터 포인트에 도달할 확률 (0~1)을
경우에 따라서는 무작위 응답이
적용될 수 있습니다
여기에는 두 가지 주요 이점이 있습니다.
- 보고서를 받는 당사자에게 기본 브라우저 동작을 투명하게 보여 줍니다. 광고 기술(일반적으로 광고 기술)입니다.
- 향후 API가 모든 플랫폼에서 지원될 시점에 : 각 브라우저에서 주파수에 따라 다른 수준의 노이즈를 개인 정보 보호가 목표이며 보고서 처리 당사자는 이 사항에 대한 가시성이 필요합니다.
노이즈는 어떻게 작동하나요?
새 제안서에서 소스가 등록되면 (즉, 광고 클릭 또는 조회가 기록됨) 전환 기여도를 제대로 부여할지 무작위로 판단하고 이에 대한 보고서를 허위 출력을 생성할지 여부를 지정할 수 있습니다.
가짜 출력은 다음과 같을 수 있습니다.
- 사용자 전환 여부와 관계없이 보고서를 전혀 사용하지 않음
- 하나 또는 여러 개의 허위 보고서: 사용자 전환 여부와 관계없이
가짜 보고서에서는 트리거 데이터 (전환 데이터)가 임의이며 클릭에 대한 임의의 3비트 값 (임의의 0과 7 사이의 숫자)과 뷰에 대한 임의의 1비트 값 (0 또는 1)을 포함할 수 있습니다.
실제 신고와 마찬가지로 허위 신고는 사용자가 전환한 직후 전송되지 않습니다. 다음 주소로 전송됩니다. 임의의 보고 기간 종료
클릭에는 세 가지 보고 기간 (클릭 후 2일, 7일 또는 30일)이 있습니다. 모든 가짜 보고 기간 중 하나에 무작위로 할당됩니다.
이와 별도로 이전 제안에서 이미 언급한 것처럼 기간 내의 보고서 순서는 무작위입니다.
기술 설명에서 자세히 알아보기
공개 토론 참여
보고 제한사항 (이벤트 수준 보고서 및 집계 가능한 보고서)
변경되는 사항과 이유는 무엇인가요?
새 제안은 두 사이트 간 이벤트를 측정할 수 있는 당사자의 수를 명시적으로 제한합니다.
- 등록할 수 있는 고유한 보고 출처 (일반적으로 광고 기술)의 최대 개수입니다. {publisher, advertiser}당 소스 수는 30일당 100개로 제한되도록 제안되었습니다. 이 카운터는 광고 클릭 또는 조회 (소스 이벤트)가 발생할 때마다 증가하며, 기여 분석 모델입니다.
- 사용자당 보고서를 전송할 수 있는 고유한 보고 출처 (일반적으로 광고 기술)의 최대 개수입니다. {게시자, 광고주}에게 30일당 10회로 제한하도록 제안되었습니다. 이 카운터는 기여 분석된 전환이 발생할 때마다 증가합니다.
이러한 한도는 행위자의 측정 능력을 제한하지 않을 정도로 높게 설계되어 있습니다. 일부 형태의 API 남용을 완화하는 데 도움이 될 정도로 낮습니다.
보고 쿨다운 / 비율 제한
변경되는 사항과 이유는 무엇인가요?
보고 쿨다운은 전송되는 총 정보의 양을 제한하는 개인 정보 보호 메커니즘입니다. 이 API를 통해 사용자에게 제공할 수 있습니다.
새 제안서에서는 {출처 사이트, 대상, 보고 출처}당 보고서 100개 (일반적으로 {publisher, advertiser, adtech})를 예약하는 데는 30일이 걸립니다.
이 한도를 초과하면 브라우저에서 지정된 {source site, 연결 대상, 보고 출처} (일반적으로 {publisher, advertiser, adtech}) 해당 {소스 사이트, 대상, 보고 출처}의 보고서 수가 100개 미만입니다.
기술 설명에서 자세히 알아보기
도착 페이지 설정 (이벤트 수준 보고서만 해당)
변경되는 사항과 이유는 무엇인가요?
도착 페이지 설정은 100개의 고유 범위에 보고 출처 (일반적으로 광고 기술)를 포함하도록 수정됩니다. 대기 중인 도착 페이지 (일반적으로 광고주 사이트 또는 전환이 발생할 것으로 예상되는 사이트) 장소)는 {publisher, adtech}별로 허용됩니다.
이는 방문 기록 재구성을 제한하는 개인 정보 보호 기능입니다.
기술 설명에서 자세히 알아보기
모든 리소스
- 기여도 보고를 참고하세요.
- API에 대해 알아야 할 사항 읽어보기