Wprowadziliśmy kilka zmian w pakiecie Attribution Reporting opinii społeczności, od zmian mechanizmu interfejsu API po nowe funkcje.
Historia zmian
- 7 lutego 2022 r.: dodano sekcję dotyczącą przekierowania aktywatora w nagłówku.
- 27 stycznia 2022 roku: po raz pierwszy opublikowano artykuł.
Dla kogo jest ten post?
Ten post jest dla Ciebie:
- Jeśli znasz już interfejs API – na przykład jeśli obserwujesz lub biorą udział w dyskusjach w repozytorium WICG i chcemy zrozumieć zmian wprowadzonych w ofercie pakietowej w styczniu 2022 r.
- Jeśli używasz Attribution Reporting API w wersji demonstracyjnej lub w eksperymencie w wersji produkcyjnej.
Jeśli dopiero zaczynasz korzystać z tego interfejsu API lub nie masz z nim jeszcze doświadczenia, przejdź bezpośrednio do wprowadzenie do interfejsu API .
Zbliża się migracja
Jeśli po wdrożeniu tych zmian w Chrome korzystasz z raportów na poziomie zdarzenia pochodzących z interfejsu Attribution Reporting API w wersji demonstracyjnej lub w eksperymencie w wersji próbnej (źródłowy test), to aby interfejs API mógł nadal działać, musisz zmodyfikować kod. Możesz też rozważyć korzystanie z nowych funkcji.
Ten artykuł zawiera też informacje o zmianach w raportach agregowanych. Wdrożenie tych zmian nie wymaga jednak żadnych działań ani migracji, ponieważ w momencie pisania tego artykułu nie przeprowadzono jeszcze implementacji w przeglądarce, która umożliwiłaby zagregowanie raportów.
Zmiany imienia i nazwiska
Raporty podsumowujące i raporty agregowane
Raporty zbiorcze będą teraz odnosić się do sekcji jako raporty podsumowujące.
Raporty podsumowujące to ostateczne wyniki zestawień wielu raportów zbiorczych, wcześniej nazywanymi darowiznami lub histogramem.
zmiany mechanizmów interfejsu API,
Rejestracja źródła na podstawie nagłówka (raporty na poziomie zdarzenia)
Co się zmienia i dlaczego?
Gdy użytkownik wyświetli lub kliknie reklamę, przeglądarka zarejestruje to zdarzenie lokalnie na jego urządzeniu.
z parametrami charakterystycznymi dla raportów atrybucji (np.
attributionsourceeventid, attributiondestination, attributionexpiry i inne parametry).
wartości tych parametrów są ustawiane przez zespół AdTech.
Zmienia się sposób ustawiania tych parametrów.
W poprzedniej ofercie pakietowej parametry trzeba było uwzględnić po stronie klienta – albo w tagach kotwicy. jako atrybuty HTML lub jako argumenty wywołania opartego na JS. Parametry musiały być znane przy kliknięciu lub wyświetleniu obecnie się znajdujesz.
W nowej ofercie pakietowej wartość tych parametrów jest zdefiniowana na serwerze adtech.
Ma to wiele zalet, szczególnie w zakresie bezpieczeństwa: mechanizm nagłówka zapewnia pochodzenie (zwykle jest to technologia reklamowa), która ma bezpośrednią kontrolę nad tym, czy źródło atrybucji jest zarejestrowane zakresu. Częściowo eliminuje to ryzyko oszustw. Dzięki tej zmianie autentyczna przeglądarka zarejestrować źródło bez zgody źródła raportowania.
Jak działa rejestracja źródła?
- W przypadku danej reklamy zespół AdTech musiałby zdefiniować konkretny atrybut po stronie klienta.
attributionsrcWartością tego atrybutu jest adres URL, do którego przeglądarka prześle żądania; to żądanie będzie zawierać nowy nagłówek HTTPAttribution-Reporting-Source-Info, któregonavigationlubevent,określa, czy źródłem było odpowiednio kliknięcie czy wyświetlenie. - Po otrzymaniu tego żądania serwer śledzenia kliknięć/wyświetleń powinien odpowiedzieć z żądaniem HTTP
nagłówek,
Attribution-Reporting-Register-Source, który zawiera żądaną atrybucję . Punkt początkowy, który zwraca ten nagłówek, jest teraz źródłem raportowania (dawniej zdefiniowanym jako
attributionreportto).Nagłówek odpowiedzi HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Rejestrowanie źródeł atrybucji
Dołącz do dyskusji publicznej
Aktywator atrybucji opartej na nagłówku (raporty na poziomie zdarzenia)
Co się zmienia i dlaczego?
Podobnie jak w przypadku rejestracji kliknięcia lub wyświetlenia, nowa oferta zmienia regułę atrybucji – gdy
adtech instruuje przeglądarkę, aby zarejestrowała konwersję, wykorzystując nagłówek.
Mechanizm ten jest zgodny z rejestracją źródła opartą na nagłówku i jest więcej
konwencjonalnym niż używany wcześniej mechanizm przekierowania.
Dodatkowo w nowej ofercie pakietowej wymagany jest na stronie konwersji atrybut attributionsrc.
Uzasadnienie jest kwestią uprawnień – w poprzedniej ofercie witryny po stronie reguły – zwykle
w witrynie reklamodawcy – mieliśmy ogólną kontrolę nad funkcją za pomocą nagłówka Permissions-Policy, ale
nie miał szczegółowej kontroli na poziomie elementu, która określa, czy element może wysyłać żądania do strony.
które ostatecznie uruchamiałyby atrybucję. attributionsrc zmienia to: ten wymagany znacznik
Pozwala reklamodawcy monitorować i kontrolować, które elementy mogą
o pochodzeniu danych.
Pamiętaj, że po stronie źródła – zwykle w witrynie wydawcy – obejmuje ona kontrolę całej strony za pomocą
Dostępne są ustawienia Permissions-Policy oraz element kontrolny dla całego elementu za pomocą komponentu attributionsrc.
Jak działa reguła atrybucji?
Po otrzymaniu żądania piksela i sklasyfikowaniu go jako konwersji
powinien odpowiedzieć nowym żądaniem HTTP
nagłówek Attribution-Reporting-Register-Event-Trigger.
Wartość tego nagłówka określa, jak traktować zdarzenie aktywujące jako obiekt JSON. Nie ma żadnej zdefiniowane jako parametry zapytania w poprzedniej ofercie pakietowej.
Nagłówek odpowiedzi HTTP Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Przekierowanie (opcjonalnie)
Opcjonalnie serwer adtech może ustawić odpowiedź zawierającą Attribution-Reporting-Register-Event-Trigger jako odpowiedź przekierowania.
Dzięki temu inne firmy mogą obserwować zdarzenie konwersji i informować przeglądarkę, że ma je przypisać.
Przekierowanie jest opcjonalne. nie jest potrzebny, jeśli na stronie znajdują się zarówno technologie reklamowe, jak i firmy zewnętrzne.
Więcej informacji znajdziesz w sekcji Raporty innych firm.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Dołącz do dyskusji publicznej
Brak Worklet (raporty agregowane)
Co się zmienia i dlaczego?
W poprzedniej ofercie agregowanych raportów wywołanie JavaScriptu wymagało dostępu do Worklet – mechanizm oparty na języku JavaScript – który mógłby generować takie raporty.
W nowej ofercie pakietowej nie jest wymagany żaden Worklet. Zamiast tego firma AdTech zdefiniuje definicję deklaratywną – w ramach protokołu HTTP nagłówki – reguły, których przeglądarka powinna używać do generowania raportów zbiorczych.
Nowa oferta pakietowa ma kilka zalet:
- Implementacja za pomocą przeglądarki: nowy projekt, w przeciwieństwie do projektu Workletu, bo nie wymaga nowego środowiska wykonawczego w przeglądarkach.
- Wrażenia programistów: nowy wygląd opiera się na nagłówkach, które są często używane powszechnie znane programistom. a także do platformy API rejestracji źródła, co ułatwia naukę i używanie interfejsu API.
- Rozpowszechnienie: nowy wygląd umożliwia większej liczbie istniejących systemów pomiaru stosowanie agregacji raportów. Wiele rozwiązań analitycznych obsługuje tylko protokół HTTP: bazuje na żądaniach graficznych – piksele które nie wymagają dostępu do JavaScriptu. Ponieważ jednak podejście Worklet wymagało JavaScript, migracja z niektórych istniejących systemów pomiarowych może być trudna.
- Wydajność: nowy wygląd pomaga zmniejszyć ryzyko utraty danych, ponieważ integracja jest łatwiejsza
z semantyką
keepalive, np. jeśli kliknięcie lub wyświetlenie zostanie zarejestrowane, gdy użytkownik wyjdzie, stronę.
Jak działa mechanizm bez Workletów?
Ten mechanizm deklaratywny opiera się na nagłówkach HTTP – tak jak rejestracja źródła na poziomie zdarzenia. i nagłówek wyzwalacza atrybucji. Więcej informacji na ten temat znajdziesz w kolejnych sekcjach.
Dołącz do dyskusji publicznej
Rejestracja źródła na podstawie nagłówka (raporty agregowane)
zaproponowano nowy mechanizm rejestracji źródła raportu agregowanego; ten mechanizm jest co rejestracja źródła na poziomie zdarzenia.
Inna jest tylko nazwa nagłówka: Attribution-Reporting-Register-Aggregatable-Source.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Aktywator atrybucji opartej na nagłówku (raporty agregowane)
zaproponowano nowy mechanizm rejestracji źródła raportu agregowanego; ten mechanizm jest to samo co reguła atrybucji na poziomie zdarzenia.
Inna jest tylko nazwa nagłówka: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Rejestracja aktywatora atrybucji
Nowe funkcje
Raporty innych firm (raporty na poziomie zdarzenia i raporty zbiorcze)
Co się zmienia i dlaczego?
Dwa aspekty nowej propozycji pomagają lepiej obsługiwać raporty firm zewnętrznych:
- Opcjonalnie zespoły AdTech mogą przekierowywać żądania sieciowe do innych serwerów Adtechs, co umożliwia korzystanie z innych technologii reklamowych, aby generować własne źródła i aktywować rejestrację. Jest to popularny sposób, firm zostały skonfigurowane. Ułatwia to wdrożenie interfejsu API, między innymi w systemów raportowania firm zewnętrznych.
- Źródła raportowania – zazwyczaj związane z technologiami reklamowymi – nie mają już większości limitów związanych z prywatnością. Umożliwia to korzystanie z gdy wiele technologii reklamowych współpracuje z tymi samymi wydawcami lub reklamodawcami.
Jak działa raportowanie zewnętrzne?
W nowej ofercie pakietowej rejestracja i aktywator oparte na odpowiedziach zależy od Nagłówki HTTP. Technologie reklamowe mogą wykorzystywać przekierowania HTTP do obsługi tych żądań.
Jeśli żądanie kliknięcia/wyświetlenia w witrynie wydawcy (rejestracja źródła) zostanie następnie przekierowane do
wiele osób, każda z nich może zarejestrować to wyświetlenie lub kliknięcie (zdarzenie źródłowe).
Podobnie zespół AdTech może przekierować konkretne żądanie atrybucji wysłane z witryny reklamodawcy,
umożliwienie wielu innym stronom zarejestrowania konwersji (atrybucja oparta na atrybucji).
Każda ze stron może uzyskać dostęp do swoich osobnych raportów i skonfigurować je z oddzielnymi danymi.
Rejestrowanie wielu aktywatorów bez przekierowań
Można też zarejestrować wiele reguł atrybucji bez korzystania z przekierowań, dodając wiele elementów pikselowych po stronie konwersji (po jednym na regułę).
Dołącz do dyskusji publicznej
Pomiar po wyświetleniu (raporty na poziomie zdarzenia i raporty agregowane)
Co się zmienia i dlaczego?
W ramach nowej oferty pomiary po wyświetleniu i pomiar klikalności działają w ujednolicony sposób:
registerattributionsrc– atrybut dotyczący widoku danych, który nakazuje przeglądarce rejestrowania wyświetleń razem z kliknięciami, nie jest już częścią oferty.- Mechanizmy ochrony prywatności są teraz ujednolicone w przypadku kliknięć i wyświetleń. Szczegóły znajdziesz w sekcji Szum i przejrzystość.
Ma to na celu zapewnienie zgodności z nowym mechanizmem rejestracji opartym na nagłówku. Ułatwia to również programistom pracę, gdy zamierzają obsługiwać zarówno konwersje po kliknięciu, jak i po wyświetleniu. pomiar skuteczności.
Jak działa pomiar po wyświetleniu?
Pomiary po wyświetleniu i pomiar klikalności wymagają rejestracji opartej na nagłówku.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Raporty na poziomie zdarzenia (dotyczące zarówno kliknięć, jak i wyświetleń)
Dołącz do dyskusji publicznej
Debugowanie / analiza skuteczności (raporty na poziomie zdarzenia i raporty zbiorcze)
Co się zmienia i dlaczego?
Do oferty dodaliśmy mechanizm debugowania, który pomoże programistom wykrywać błędy, a także porównywać skuteczność raportów Attribution z dotychczasowymi rozwiązaniami pomiarowymi opartymi na plikach cookie.
Jak działa debugowanie?
Rejestracja źródła i aktywatora będzie akceptować nowy parametr debug_key, 64-bitowy nieoznaczony
jest liczbą całkowitą.
Jeśli raport został utworzony przy użyciu kluczy źródłowych i aktywujących klucze debugowania, a plik cookie Samesite=None ar_debug=1
jest obecny w pliku cookie źródła raportowania w momencie rejestracji
i aktywującego plik cookie,
(JSON) zostanie wysłany do punktu końcowego .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Raporty na poziomie zdarzenia i raporty agregowane również będą zawierać te 2 nowe parametry, dzięki czemu będzie można powiązane z odpowiednim raportem debugowania.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Opcjonalnie: rozszerzone raporty na temat debugowania
Dołącz do dyskusji publicznej
możliwości filtrowania (raportów na poziomie zdarzenia i raportów agregowanych).
Co się zmienia i dlaczego?
Obsługuje ona ważne przypadki użycia we współczesnym ekosystemie reklamowym, dlatego wiele zastosowań będzie teraz obsługiwana zarówno w raportach na poziomie zdarzenia, jak i w raportach agregowanych:
- Filtrowanie konwersji: filtrowanie konwersji na podstawie informacji po stronie źródła. Dla: np. wybrać różne dane reguły (dane o konwersjach) dla kliknięć i wyświetleń reklam.
- Niezgodność atrybucji: filtruj niewłaściwie przypisane konwersje. to jest konkretnego typu filtrowania konwersji. Na przykład odfiltrowuj konwersje pasujące do nieprawidłowe kliknięcie lub wyświetlenie reklamy z powodu zakresu docelowego etld+1 w interfejsie API.
Jak działają funkcje filtrowania? (w przypadku raportów na poziomie zdarzenia)
Opcjonalne pole source_data w obiekcie JSON po stronie źródłowej może określać elementy, które zostaną
są następnie używane przez przeglądarkę w momencie konwersji w celu zastosowania logiki filtrowania.
{
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"}
}
}
Rejestracja aktywatora będzie teraz akceptować opcjonalny nagłówek Attribution-Reporting-Filters.
Nagłówek odpowiedzi HTTP Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Nagłówek Attribution-Reporting-Register-Event-Trigger można też rozszerzyć za pomocą
filters w celu przeprowadzenia filtrowania selektywnego w celu ustawienia wartości trigger_data w oparciu o zasadę source_data.
Jeśli klucze w filtrach JSON pasują do kluczy w pliku source_data, aktywatorem jest
jest całkowicie ignorowany, jeśli skrzyżowanie jest puste.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Dołącz do dyskusji publicznej
Zmiany w ochronie prywatności
Szum i przejrzystość (raporty na poziomie zdarzenia i raporty zbiorcze)
Co się zmienia i dlaczego?
W nowej propozycji udoskonaliliśmy jeden z mechanizmów ochrony prywatności raportów:
mogą podlegać losowej odpowiedzi.
Oznacza to, że niektóre rzeczywiste konwersje będą raportowane prawidłowo. a pewna część
niektóre rzeczywiste konwersje zostaną pominięte lub zostaną dodane pewne fałszywe konwersje.
Ta nowa metoda ma kilka zalet:
- Ujednolica mechanizm ochrony prywatności kliknięć i wyświetleń.
- Rozumienie jest prostsze niż mechanizm, w którym oddzielono dane aktywujące (dane o konwersjach) i szum linku źródła reguły.
- Tworzy zasady ochrony prywatności, dzięki którym (przy odpowiednich ustawieniach szumu) żadna ze stron nie może polegać na interfejsie API, aby mieć pewność, że dany użytkownik dokonał konwersji w przypadku określonej reklamy (lub nie).
Ten nowy mechanizm zastępuje poprzedni, gdzie w 5% przypadków dane aktywujące (dane konwersji) została zastąpiona wartością losową.
Dodatkowo do treści raportu została dodana wartość prawdopodobieństwa odpowiedzi w losowych losach.
(pole randomized_trigger_rate). To pole określa prawdopodobieństwo (0–1), że źródło jest
mogą podlegać losowej odpowiedzi.
Ma to 2 główne zalety:
- Zapewnia przejrzystość działania przeglądarki dla stron, które będą otrzymywać raporty. (zwykle są to technologie reklamowe).
- Przyda się on w przyszłości, w których interfejs API będzie obsługiwany w różnych miejscach : różne przeglądarki mogą stosować różne poziomy szumu w zależności od w zakresie prywatności, a podmioty, które będą go obsługiwać, będą musiały mieć wgląd w to.
Jak działa szum?
W momencie zarejestrowania źródła (tj. zarejestrowania kliknięcia lub wyświetlenia reklamy) w nowej ofercie pakietowej, przeglądarka losowo decyduje, czy będzie prawdziwie przypisywać konwersje i wysyłać raporty dotyczące tego kliknięcia/obejrzenia reklamy, ani o tym, czy spowoduje to wygenerowanie fałszywych wyników.
Fałszywe dane wyjściowe mogą to być:
- Brak raportu – niezależnie od tego, czy użytkownik dokona konwersji.
- Co najmniej 1 fałszywy raport – niezależnie od tego, czy użytkownik dokona konwersji.
W fałszywych raportach dane reguły (dane o konwersjach) są losowe: 3-bitowa wartość losowa dla kliknięć (dowolny liczby z zakresu od 0 do 7) oraz losową 1-bitową wartość wyświetleń (0 lub 1).
Podobnie jak prawdziwe raporty, fałszywe raporty nie są wysyłane od razu po dokonaniu konwersji przez użytkownika. Są one wysyłane na adres koniec okna raportowania losowego.
W przypadku kliknięć dostępne są 3 okna raportowania (2 dni, 7 dni lub 30 dni po kliknięciu). Każdy fałszywy jest losowo przypisywany do jednego z okien raportowania.
Poza tym, jak wspomnieliśmy w poprzedniej ofercie, kolejność raportów w ramach przedziału czasu jest losowa.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Przykłady fałszywych konwersji z szumem
Dołącz do dyskusji publicznej
Ograniczenia raportowania (raporty na poziomie zdarzenia i raporty agregowane)
Co się zmienia i dlaczego?
Nowa oferta pakietowa jednoznacznie ogranicza liczbę podmiotów, które mogą mierzyć zdarzenia między 2 witrynami.
- Maksymalna liczba unikalnych źródeł raportowania (zwykle adtech), które mogą zarejestrować liczba źródeł na {publisher, advertiser} ma być ograniczona do 100 w ciągu 30 dni. Ten licznik zdarzeń będzie zwiększany dla każdego kliknięcia lub wyświetlenia reklamy (zdarzenia źródłowego), nawet jeśli nie atrybucja oparta na danych.
- Maksymalna liczba unikalnych źródeł raportowania (zwykle powiązanych z technologiami reklamowymi), które mogą wysyłać raporty na {publisher, advertiser} będzie obowiązywać ograniczenie do 10 w ciągu 30 dni. Ten licznik będzie dla każdej przypisanej konwersji.
Limity te są na tyle wysokie, że nie ograniczają możliwości pomiaru konwersji, ale na tyle niska, że pomaga ograniczyć niektóre formy nadużywania interfejsów API.
Limity czasu oczekiwania / częstotliwości raportowania
Co się zmienia i dlaczego?
Okres oczekiwania na raporty to mechanizm ochrony prywatności, który ogranicza ilość wszystkich wysyłanych informacji za pomocą tego interfejsu API w danym okresie dla użytkownika.
W nowej ofercie pakietowej 100 raportów na {źródłową witrynę, miejsce docelowe, źródło raportowania} (zwykle {publisher, advertiser, adtech}) można zaplanować na 30 dni.
Po przekroczeniu tego limitu przeglądarka przestanie planować raporty powiązane z tą {source site, miejsce docelowe, źródło raportowania} (zwykle {publisher, advertiser, adtech}) – do 30 kolejnych dni liczba raportów spadnie poniżej 100 w przypadku tej {witryny źródłowej, miejsca docelowego, źródła raportowania}.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Limity czasu oczekiwania / częstotliwości raportowania
Ograniczenie liczby miejsc docelowych (tylko raporty na poziomie zdarzenia)
Co się zmienia i dlaczego?
Ograniczenie liczby miejsc docelowych jest modyfikowane, by uwzględnić źródło raportowania (zwykle jest to technologia reklamowa) w zakresie: 100 unikalnych użytkowników oczekujące miejsca docelowe (zwykle witryny reklamodawców lub witryny, w których spodziewane są konwersje miejsce) są dozwolone na {publisher, adtech}.
To ochrona prywatności, która pozwala ograniczyć odbudowywanie historii przeglądania.
Więcej informacji znajdziesz w wyjaśnieniu technicznym
Ograniczenie liczby unikalnych miejsc docelowych objętych oczekującymi źródłami
Wszystkie zasoby
- Przeczytaj artykuł Raporty atrybucji.
- Przeczytaj artykuł Co musisz wiedzieć o interfejsie API.
Obraz w nagłówku pochodzi od Diany Polekhina na kanale Unsplash.