Klucze agregacji na potrzeby raportów atrybucji

Czym są klucze agregacji, jak są używane w interfejsie Attribution Reporting API i jak można przekładać cele na klucze.

Jako firma z branży technologii reklamowych prowadzisz kampanie w różnych lokalizacjach dla różnych kategorii produktów. Chcesz pomóc reklamodawcom uzyskać odpowiedzi na te pytania:

1. Ile zakupów z poszczególnych kategorii produktów wygenerowały poszczególne kampanie w poszczególnych regionach geograficznych?
2. Ile przychodów w przypadku każdej kategorii produktów wygenerowały poszczególne kampanie w każdym regionie geograficznym?

Chociaż wiele firm zajmujących się technologiami reklamowymi zachęca reklamodawców do konfigurowania różnych typów konwersji, skupienie się na najważniejszych konwersjach, np. zakupach, to dobry sposób na zapewnienie szczegółowych i dokładnych wyników podsumowania w przypadku tych ważnych zdarzeń.

Zanim zaczniesz zbierać dane, zastanów się, na jakie pytania chcesz uzyskać odpowiedzi.

Wymiary, klucze i wartości

Aby odpowiedzieć na te pytania, spójrzmy na wymiary, klucze i wartości.

Uwaga: klucze agregacji opisane w tym dokumencie dotyczą tylko interfejsu Attribuion Reporting API.

Wymiary

Aby dowiedzieć się, jak Twoje kampanie generują przychody, musisz śledzić te wymiary:

• Identyfikator kampanii reklamowej: identyfikator konkretnej kampanii.
• Identyfikator geograficzny: region, w którym została wyświetlona reklama.
• Kategoria produktu: typ zdefiniowanego produktu.

Chociaż wymiary „Identyfikator kampanii” i „Identyfikator geograficzny” są znane w chwili wyświetlenia reklamy (czas wyświetlania reklamy), kategoria produktu jest znana ze zdarzenia wywołującego, gdy użytkownik zrealizuje konwersję (czas konwersji).

Uwaga: na diagramie w tym dokumencie widoczne są takie wymiary:

• Wymiary znane w momencie wyświetlania reklamy na zielonym tle.
• Wymiary znane w czasie konwersji na żółtym tle i podkreślone.

Wymiary, które chcesz śledzić w tym przykładzie, przedstawiono na tej ilustracji:

Wymiary do śledzenia

Czym są klucze agregacji (zasobniki)?

Hasła klucz agregacji i zasobnik odnoszą się do tego samego elementu. Klucz agregacji jest używany w interfejsach API przeglądarki używanych do konfigurowania raportów. Termin zasobnik jest używany w raportach agregowanych i podsumowujących oraz w interfejsach API usługi agregacji.

Klucz agregacji (w dalszej części tekstu nazywany po prostu kluczem) to część danych, która reprezentuje wartości śledzonych wymiarów. Dane są później agregowane według każdego klucza agregacji.

Załóżmy np., że śledzisz wymiary Kategoria produktu, Identyfikator regionu i Identyfikator kampanii.

Gdy użytkownik znajdujący się w regionie o identyfikatorze geograficznym 7 zobaczy reklamę z kampanii o identyfikatorze 12, a potem dokona konwersji, kupując produkt z kategorii Produkty 25, możesz ustawić klucz agregacji podobny do tego na poniższym obrazku:

Jak się przekonasz, klucz agregacji w praktyce nie wygląda dokładnie tak, jak w tym przykładzie, ale na razie skup się na informacjach zawartych w kluczu.

Czym są wartości agregujące?

Aby odpowiedzieć na Twoje pytania dotyczące wymienionych przez nas wymiarów, chcemy poznać następujące informacje:

• liczba zakupów (liczba zakupów); Po zsumowaniu i udostępnieniu w raporcie podsumowującym będzie to łączna liczba zakupów (wartość podsumowująca).
• Przychody z każdego zakupu (wartość zakupu). Po zsumowaniu i udostępnieniu w raporcie podsumowującym będzie to łączny przychód (wartość podsumowująca).

Każda z tych wartości – liczba zakupów dla jednej konwersji i wartość zakupu dla jednej konwersji – może być wartością agregowaną. Wartości agregowane możesz traktować jako wartości celów pomiarowych.

Pytanie	Wartość agregująca = cel pomiaru
		Liczba zakupów...	Liczba zakupów
Jakie przychody...	Wartość zakupu

Gdy użytkownik znajdujący się w regionie o identyfikatorze geograficznym 7 zobaczy reklamę kampanii o identyfikatorze 12, a potem dokona konwersji, kupując produkt z kategorii Produkt 25 za 120 USD (przy założeniu, że walutą jest dolar amerykański), możesz ustawić klucz agregacji i wartości podlegające agregacji w ten sposób:

Klucz agregacji i wartości agregujące. Uwaga: wartości agregujące są pogrubione na niebieskim tle.

Agregowane wartości są sumowane według klucza wielu użytkowników w celu wygenerowania zagregowanych statystyk w postaci wartości podsumowujących w raportach podsumowujących.

Wartości podlegające agregacji są sumowane, aby generować zagregowane statystyki na potrzeby celów pomiarowych.

Pamiętaj, że ten diagram pomija odszyfrowywanie i przedstawia uproszczony przykład bez dodanego szumu. W następnej sekcji pokażemy to na przykładzie obrazu z szumem.

Od kluczy i wartości do raportów

Teraz omówmy związek kluczy i wartości agregujących z raportami.

Raporty zbiorcze

Gdy użytkownik kliknie lub obejrzy reklamę, a później dokona konwersji, instruujesz przeglądarkę, aby zapisała parę {agregation key, agregatable value}.

Uwaga: w tłumaczeniu para {klucz agregacji, wartość agregacji} jest też nazywana wkładem w histogramie: przedstawia ona, jak ta konwersja (oraz powiązane z nią wymiary i wartości) wpływa na raport podsumowania.

W naszym przykładzie, gdy użytkownik kliknie lub wyświetli reklamę, a potem dokona konwersji, przekazujesz przeglądarce instrukcję generowania 2 wartości dodanych (po jednej na każde z celów pomiarowych).

Później przekonasz się, że raport zbiorczy {klucz agregacji, aggregatable value} nie wygląda tak dokładnie tak, jak ten raport. Skupmy się jednak na informacjach zawartych w raporcie.

Gdy zlecisz przeglądarce wygenerowanie 2 danych, przeglądarka wygeneruje raport możliwy do zsumowania (jeśli może dopasować konwersję do poprzedniego obejrzenia lub kliknięcia).

Raport agregowany zawiera:

• Skonfigurowane przez Ciebie treści.
• Metadane o zdarzeniu kliknięcia lub wyświetlenia oraz zdarzeniu konwersji: witryna, w której nastąpiła konwersja, i inne informacje. Zobacz wszystkie pola w raporcie agregowanym

Raporty agregujące mają format JSON i zawierają m.in. pole ładunku, które zostanie wykorzystane jako dane wejściowe do końcowego raportu podsumowującego.

Ładunek zawiera listę skrótów, z których każdy jest parą {klucz agregacji, wartość agregacji}:

• bucket: klucz agregacji zakodowany jako ciąg bajtów.
• value: agregowana wartość dla danego celu pomiarowego, zakodowana w postaci ciągu bajtów.

Oto przykład:

{
  "data": [
    {
      "bucket": "111001001",
      "value": "11111010000",
    }
  ],
  "operation": "histogram"
}

W praktyce raporty podlegające agregacji są kodowane w taki sposób, że zbiory i wartości wyglądają inaczej niż w poprzednim przykładzie (czyli zbiór może wyglądać jak \u0000\u0000\x80\u0000). Zbiór i wartość to oba ciągi bajtów.

Raporty podsumowujące

Raporty, które można agregować, są agregowane na podstawie wielu przeglądarek i urządzeń (użytkowników) w ten sposób:

• Firma zajmująca się technologiami reklamowymi prosi o raporty zbiorcze dotyczące danego zbioru kluczy i danego zbioru raportów, które można agregować, a które pochodzą z wielu różnych przeglądarek (użytkowników).
• Raporty agregowane są odszyfrowywane przez usługę agregacji.
• Dla każdego klucza agregowane wartości z raportów agregowanych są sumowane.
• Do wartości podsumowania jest dodawany szum.

Wynikiem jest raport podsumowujący zawierający zbiór par {klucz agregacji, podsumowania wartości}.

Raport podsumowujący zawiera zestaw par klucz-wartość w stylu słownika JSON. Każda para obejmuje:

• bucket: klucz agregacji zakodowany jako ciąg bajtów.
• value: wartość zbiorcza w postaci liczby dziesiętnej dla danego celu pomiaru, zsumowana z wszystkich dostępnych raportów, które można agregować, z dodatkowym poziomem szumu.

Przykład:

[
  {"bucket": "111001001", "value": "2558500"},
  {"bucket": "111101001", "value": "3256211"},
  {...}
]

W praktyce raporty zbiorcze są kodowane w taki sposób, że zbiory i wartości wyglądają inaczej niż w przykładzie (czyli zbiór może wyglądać jak \u0000\u0000\x80\u0000). Zbiór i wartość to oba ciągi bajtów.

Klucze agregacji w praktyce

Klucze agregacji (segmenty) są definiowane przez firmę zajmującą się technologią reklamową, zwykle w 2 etapach: gdy reklama jest klikana lub wyświetlana oraz gdy użytkownik dokonuje konwersji.

Struktura klucza

Używamy terminu struktura klucza, aby oznaczać zbiór wymiarów zakodowanych w kluczu.

Na przykład kluczowa struktura to identyfikator kampanii × identyfikator regionu × kategoria produktu.

Typy kluczy

Dane agregowane dla danego klucza są sumowane dla różnych użytkowników/przeglądarek. Zauważyliśmy jednak, że wartości podlegające agregacji mogą służyć do śledzenia różnych celów pomiarowych, np. wartości zakupu lub liczby zakupów. Chcesz mieć pewność, że usługa agregacji będzie sumować wartości tego samego typu, które można agregować.

Aby to zrobić, w każdym kluczu zakoduj część danych, która informuje, co reprezentuje wartość podsumowania, czyli cel pomiaru, do którego odnosi się ten klucz. Jednym ze sposobów jest utworzenie dla klucza dodatkowego wymiaru, który będzie reprezentował typ celu pomiarowego.

W poprzednim przykładzie ten typ celu pomiarowego miałby 2 możliwe wartości:

• Liczba zakupów to pierwszy typ celu pomiaru.
• Wartość zakupu to drugi typ celu pomiarowego.

Jeśli masz n celów pomiarowych, typ celu pomiarowego będzie miał n różnych typów wartości.

Wymiary klucza możesz traktować jak dane. Na przykład „liczba zakupów danego produktu w danej kampanii w danym regionie”.

Rozmiar klucza, rozmiar wymiaru

Maksymalny rozmiar klucza jest określony w bitach, czyli liczbie zer i jedynek w formacie binarnym potrzebnych do utworzenia pełnego klucza. Interfejs API zezwala na użycie klucza o długości 128 bitów.

Taki rozmiar umożliwia użycie bardzo szczegółowych kluczy, ale przy tym bardziej szczegółowych wartościach może być większe zaszumienie. Więcej informacji o szumie znajdziesz w artykule Co to jest szum?

Jak już wspomnieliśmy, wymiary są kodowane w kluczu agregacji. Każdy wymiar ma określoną moc zbioru, czyli liczbę różnych wartości, które może przyjąć. W zależności od mocy zbioru każdy wymiar musi być reprezentowany przez określoną liczbę bitów. Przy n bitów możliwe jest określenie 2ⁿ różnych opcji.

Na przykład wymiar Kraj może mieć moc zbioru 200, ponieważ na świecie jest około 200 krajów. Ile bitów potrzeba do zakodowania tego wymiaru?

W przypadku 7 bitów zapisywane jest tylko 2⁷ = 128 różnych opcji, czyli mniej niż wymagane 200.

8 bitów pozwoliłoby przechowywać 2⁸ = 256 różnych opcji, czyli więcej niż wymagane 200, więc możesz użyć n = 8 bitów do zakodowania tej wymiary.

Kodowanie klucza

Klucze ustawiane w przeglądarce powinny być zakodowane w systemie szesnastkowym. W raportach podsumowujących klucze będą widoczne w formacie binarnym (i będą nazwane zasobnikami).

Uwaga: dane szesnastkowe są zwykle poprzedzone ciągiem 0x. Na przykład 0x19 to 19 w zapisie szesnastkowym; wynik to 25, a nie 19. Liczby binarne są zwykle poprzedzone ciągiem 0b. Na przykład 0b11001 to 11001 w systemie dwójkowym; czyli 25 w zapisie dziesiętnym, a nie 11 001.

Ustaw 2 części klucza, aby utworzyć pełny klucz

Załóżmy, że używasz klucza do śledzenia tych wymiarów:

• Identyfikator kampanii
• Identyfikator regionu
• Kategoria produktów

Wymiary Identyfikator kampanii i Identyfikator geografii są znane w momencie wyświetlenia reklamy (czas wyświetlania reklamy), natomiast kategoria produktu będzie znana ze zdarzenia wywołującego, gdy użytkownik dokona konwersji (czas konwersji).

W praktyce oznacza to, że trzeba skonfigurować klucz w 2 krokach:

1. Jedną część klucza (identyfikator kampanii × identyfikator geografii) ustawiasz w momencie kliknięcia lub wyświetlenia reklamy.
2. Drugą część klucza, czyli kategorię produktu, ustawiasz w momencie konwersji.

Te różne części klucza nazywamy elementami klucza.

Klucz oblicza się, stosując operator LUB (v) jego kluczowych części.

Przykład:

• Klucz po stronie źródła = 0x159
• Klucz po stronie aktywatora = 0x400
• Klucz = 0x159 v 0x400 = 0x559

Wyrównywanie kluczowych elementów

W przypadku dwóch 64-bitowych części kluczowych rozszerzonych do 128-bitowych przy użyciu starannie rozmieszczonych 64-bitowych wypełniaczy/przesunięć (szesnaście zer) operator LUB jest równoważny z konkatenacją, co jest łatwiejsze do wyciągnięcia wniosków i weryfikacji:

• Element klucza po stronie źródła = 0xa7e297e7c8c8d0540000000000000000
• Element klucza po stronie aktywatora = 0x0000000000000000674fbe308a597271
• Klucz = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

Wiele kluczy na kliknięcie lub wyświetlenie reklamy

W praktyce możesz ustawić wiele kluczy na zdarzenie źródła atrybucji (kliknięcie lub wyświetlenie reklamy). Możesz na przykład ustawić:

• Klucz do śledzenia identyfikatora geograficznego × identyfikator kampanii.
• Kolejny klucz, który śledzi typ kreacji × identyfikator kampanii.

Innym przykładem jest strategia B.

Kodowanie wymiarów w kluczach

Gdy żądasz raportów zbiorczych, musisz poinformować usługę agregacji, do jakich danych chcesz uzyskać dostęp, prosząc o raporty zbiorcze dotyczące określonego zbioru kluczy agregacji.

Raporty podsumowania zawierają pary {klucz, wartość podsumowania} bez dodatkowych informacji o kluczu. Oznacza to, że:

• Gdy ustawiasz klucze w momencie, gdy użytkownik wyświetla lub klika reklamę, a potem dokonuje konwersji, musisz niezawodnie ustawiać klucze na podstawie wartości wymiarów, które reprezentują.
• Podczas definiowania kluczy, dla których chcesz otrzymywać raporty podsumowujące, musisz generować i na bieżąco uzyskiwać te same klucze, które zostały ustawione, gdy użytkownik wyświetlił lub kliknął reklamę i dokonał konwersji, na podstawie wartości wymiarów, o których chcesz zobaczyć zbiorcze dane.

Kodowanie wymiarów za pomocą map struktury kluczy

Aby zakodować wymiary w kluczach, możesz utworzyć i utrzymywać mapę struktury kluczy z wyprzedzeniem, gdy definiujesz klucze (przed czasem wyświetlania reklam).

Mapa struktury klucza przedstawia wszystkie wymiary i ich pozycję w kluczu.

W praktyce tworzenie i utrzymywanie map struktury kluczy oznacza wdrożenie i obsługę logiki dekodera. Jeśli szukasz metody, która nie wymaga tego, rozważ użycie metody opartej na haszach.

Oto przykład:

Załóżmy, że planujesz śledzić zarówno zakupy, jak i wartości zakupów w przypadku określonych kampanii, regionów geograficznych i produktów.

Kategoria produktu, identyfikator geografii i identyfikator kampanii muszą być wymiarami w kluczach. Ponieważ chcesz śledzić 2 różne cele pomiarowe – liczbę i wartość zakupów – musisz dodać do klucza 1 wymiar, który będzie rejestrować typ klucza. Pozwoli Ci to zdefiniować, co faktycznie agregowana wartość reprezentuje po otrzymaniu par {key, aggregatable value} w raportach podsumowujących.

W przypadku tych celów pomiarowych klucz ma te wymiary:

• Kategoria produktów
• Typ celu pomiaru
• Identyfikator geografii
• Identyfikator kampanii

Przyjrzyjmy się teraz poszczególnym wymiarom. Załóżmy, że w Twoim przypadku należy śledzić te dane:

• 29 różnych kategorii produktów.
• 8 różnych regionów geograficznych: Ameryka Północna, Ameryka Środkowa, Ameryka Południowa, Europa, Afryka, Azja, Karaiby i Oceania.
• 16 różnych kampanii.

Oto liczba bitów potrzebnych do zakodowania każdego wymiaru w Twoim kluczu:

• Kategoria produktu: 5 bitów (2⁵ = 32 > 29).
• Typ celu pomiaru: 1 bit. Celem pomiaru jest liczba zakupów lub wartość zakupu, co oznacza 2 różne możliwości i dlatego wystarczy jeden bit, aby ją zapisać.

• Identyfikator regionu: 3 bity (2³ = 8). Zdefiniowano też mapę wymiarów dla identyfikatora geograficznego, by sprawdzić, z jakiego regionu geograficznego odpowiadają poszczególne wartości binarne. Mapa wymiarów dla wymiaru Identyfikator geograficzny może wyglądać tak:

  Wartość binarna w kluczu	Geografia
  000	Ameryka Północna
  001	Ameryka Środkowa
  010	Ameryka Południowa
  011	Europa
  100	Afryka
  101	Azja
  110	Karaiby
  111	Oceania

• Identyfikator kampanii: 4 bity (2⁴ = 16).

Klucze zgodne z tą strukturą miałyby 13 bitów (5 + 1 + 3 + 4).

W tym przykładzie mapa struktury kluczy dla tych kluczy powinna wyglądać tak:

Kolejność wymiarów w kluczu zależy od Ciebie.

Aby zilustrować, jak wymiary tworzą strukturę klucza, użyjemy reprezentacji binarnej. Dlatego identyfikator kampanii (pierwsze bity) jest najdalej po prawej stronie, a kategoria produktu (ostatnie bity) – najbliżej lewej.

W każdym wymiarze najbardziej istotny fragment, czyli ten, który ma największą wartość liczbową, to ten, który znajduje się najbardziej na lewo. Najmniej znaczący bit – ten, który przechowuje najmniejszą wartość liczbową – znajduje się najdalej w prawo.

Zobaczmy, jak użyć mapy struktury kluczy do zdekodowania klucza.

Weźmy losowy klucz 0b1100100111100 i załóżmy, że wiesz, że ten klucz jest zgodny z mapą struktury klucza na poprzedniej ilustracji.

Zgodnie z mapą struktury klucza ten klucz zostałby odkodowany w ten sposób:

`11001 0 011 1100`

Klucz 0b1100100111100 reprezentuje liczbę zakupów w kategorii produktów 25 w przypadku identyfikatora kampanii 12 uruchomionej w Europie.

Kodowanie wymiarów za pomocą funkcji haszującej

Zamiast mapy struktury kluczy możesz użyć funkcji szyfrowania, aby dynamicznie generować klucze w sposób spójny i niezawodny.

Działa to w ten sposób:

1. Wybierz algorytm szyfrowania.
2. W momencie wyświetlania reklamy wygeneruj ciąg znaków zawierający wszystkie rozmiary, które chcesz śledzić, oraz ich wartości. Aby wygenerować fragment klucza po stronie źródła, zaszyfruj ten ciąg i rozważ dodanie 64-bitowego sufiksu zer, aby wyrównać go z fragmentem klucza po stronie aktywatora i ułatwić wyciąganie wniosków.
   • Element klucza po stronie źródła
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • Pamiętaj, że COUNT koduje to samo co measurementGoalType=0 w przypadku podejścia opartego na mapie kluczowej struktury. COUNT jest nieco luźniejszy i bardziej dosłowny.
3. W momencie konwersji wygeneruj ciąg znaków zawierający wszystkie wymiary, które chcesz śledzić, oraz ich wartości. Aby wygenerować fragment klucza po stronie aktywatora, zaszyfruj ten ciąg i dodaj 64-bitowy przedrostek zer:
   • Element klucza po stronie aktywatora = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Aby wygenerować klucz, przeglądarka łączy te elementy klucza OR.
   • 128-bitowy klucz agregacji
     = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
5. Gdy zechcesz wygenerować raport podsumowujący ten klucz, wygeneruj go na bieżąco:
   • Na podstawie interesujących Cię wymiarów wygeneruj klucz po stronie źródła i po stronie aktywatora, tak jak wcześniej.
     • Klucz po stronie źródła
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Klucz po stronie aktywatora
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • fragment klucza po stronie aktywatora = toHex(hash("productCategory=25"))
   • Podobnie jak przeglądarka, OR te elementy klucza, aby wygenerować ten sam klucz, który został wygenerowany wcześniej przez przeglądarkę.
     • 128-bitowy klucz agregacji
       = <64-bit source-side key piece hash><64-bit source-side key piece hash>

Oto kilka praktycznych wskazówek dotyczących korzystania z tego podejścia opartego na haszowaniu:

• Kolejność wymiarów zawsze powinna być taka sama. Zapewni to prawidłowe generowanie haszy. (Metoda "COUNT, CampaignID=12, GeoID=7" nie generuje takiego samego hasza jak funkcja "COUNT, GeoID=7, CampaignID=12"). Prostym sposobem, aby to osiągnąć, jest sortowanie wymiarów w sposób alfanumeryczny. To właśnie zrobimy w przykładzie. Wyjątkiem jest sytuacja, w której jako pierwszy element zawsze będzie w wymiarze COUNT lub VALUE. Można to zmienić, aby zwiększyć czytelność, ponieważ wartości COUNT lub VALUE kodują informacje, które są nieco inne koncepcyjnie niż wszystkie pozostałe wymiary.
• Śledź zestaw wymiarów, których używasz w kluczach. Nie chcesz generować kluczy na podstawie zestawu wymiarów, których nigdy nie używasz.
• Zderzenia haszy występują rzadko, jeśli używana jest odpowiednia funkcja skrótu, ale sprawdzenie pod kątem wcześniej używanych haszów (które należy przechowywać w celu interpretacji wyników z usługi agregacji) może uniknąć wprowadzania nowych kluczy, które mogą kolidować ze starszymi kluczami.

W przykładzie z jedną konwersją na kliknięcie lub wyświetlenie dowiesz się, jak w praktyce korzystać z kluczy opartych na haszowaniu.

Wartości nadające się do agregacji w praktyce

Gdy użytkownik dokonuje konwersji, firma z branży technologii reklamowych ustawia agregowane wartości.

Aby chronić prywatność użytkowników, w przypadku każdego z nich obowiązuje limit. Wśród wszystkich agregowanych wartości powiązanych z jednym źródłem (kliknięciem lub wyświetleniem reklamy) żadna wartość nie może być wyższa niż określony limit udziału.

Będziemy je nazywać CONTRIBUTION_BUDGET. W artykule ten limit jest nazywany budżetem L1, ale jest taki sam jak CONTRIBUTION_BUDGET.

Szczegółowe informacje o budżecie na wkład znajdziesz w artykule Budżet na wkład w raportach zbiorczych.

Przykład: jedna konwersja na kliknięcie lub wyświetlenie

W tym przykładzie załóżmy, że chcesz uzyskać odpowiedzi na następujące pytania:

• Które kategorie produktów są najcenniejsze w każdym regionie?
• Które strategie kampanii są najskuteczniejsze w poszczególnych regionach?

Załóżmy też, że w Twoim przypadku potrzebne są statystyki tygodniowe.

Musisz też śledzić:

• 16 różnych kampanii.
• 8 różnych regionów geograficznych: Ameryka Północna, Ameryka Środkowa, Ameryka Południowa, Europa, Afryka, Azja, Karaiby i Oceania.
• 29 różnych kategorii produktów.

Co warto mierzyć

Wiele firm z branży technologii reklamowych zachęca reklamodawców do konfigurowania różnych typów konwersji. Skoncentrowanie się na najważniejszych konwersjach, takich jak zakupy, to dobry sposób na zapewnienie szczegółowych i dokładnych wyników zbiorczych w przypadku tych ważnych zdarzeń konwersji. Im więcej danych zmierzysz, tym mniejszy będzie budżet przekazany na dany rodzaj danych, a co za tym idzie, im więcej będzie szumu w przypadku każdej wartości. Dlatego musisz uważnie wybrać, co chcesz mierzyć.

W tym przykładzie skupimy się na konfiguracjach kampanii, które mierzą tylko 1 konwersję na kliknięcie lub obejrzenie: zakup.

Nadal będziesz mierzyć zarówno liczbę zakupów, jak i ich wartość, a także uzyskasz dostęp do różnych ważnych zbiorczych statystyk, np. łączną wartość zakupów i podział na obszary geograficzne. Zapewnia to rozsądne skalowanie szumu i zapewnia proste skalowanie budżetu przeznaczonego na darowizny.

A co z walutami?

Prowadzenie kampanii w różnych regionach oznacza, że należy wziąć pod uwagę waluty. Możesz:

• Ustaw walutę jako specjalny wymiar w kluczach agregacji.
• Możesz też określić walutę na podstawie identyfikatora kampanii i przeliczyć wszystkie waluty na walutę odniesienia.

W tym przykładzie zakładamy, że możesz określić walutę na podstawie identyfikatora kampanii. Dzięki temu możesz przeliczyć dowolną wartość zakupu z lokalnej waluty użytkownika na wybraną przez siebie walutę odniesienia. Możesz też dokonać tej konwersji na bieżąco, gdy użytkownik kupi produkt.

Dzięki tej metodzie wszystkie agregowane wartości są podawane w tej samej walucie referencyjnej i dlatego można je zsumować, by wygenerować łączną zagregowaną wartość zakupu – sumę wartości zakupu.

Przekształć cele na klucze

Dzięki celom i danym pomiarowym masz do dyspozycji wiele opcji strategii kluczowej. Skupmy się na 2 z nich:

• Strategia A: jedna szczegółowa struktura klucza.
• Strategia B: dwie ogólne struktury kluczowe.

Strategia A: jedno głębokie drzewo (1 szczegółowa struktura klucza)

W strategii A używana jest jedna szczegółowa struktura klucza, która obejmuje wszystkie potrzebne Ci wymiary:

Wszystkie klucze używają tej struktury.

Dzielisz tę strukturę na 2 kluczowe typy, aby obsługiwać 2 cele pomiarowe.

• Typ klucza 0: typ celu pomiarowego = 0, który decydujesz się zdefiniować jako liczbę zakupów.
• Typ klucza 1: typ celu pomiarowego = 1, który decydujesz się zdefiniować jako wartość zakupu.

Raporty podsumowania wyglądają tak:

Strategię A można traktować jako strategię „jednego głębokiego drzewa”:

• Każda wartość podsumowania w raportach podsumowujących jest powiązana ze wszystkimi śledzonymi wymiarami.
• Możesz podsumować te wartości z każdym z tych wymiarów, aby podsumować ich szczegółowość, w jakiej masz określoną liczbę wymiarów.

W przypadku strategii A na pytania odpowiadasz w ten sposób:

Pytanie	Odpowiedź
Które kategorie produktów są najbardziej wartościowe w poszczególnych regionach?	Suma liczby i wartości zakupów w raportach podsumowujących, obejmująca wszystkie kampanie. Wyświetla się liczba i wartość zakupów na identyfikator geograficzny × kategoria produktu. Porównaj wartość zakupów i liczbę różnych kategorii produktów w każdym regionie.
Które strategie kampanii są najskuteczniejsze w poszczególnych regionach?	Suma liczby i wartości zakupów w raportach zbiorczych, obejmująca wszystkie kategorie produktów. Wyświetli się liczba zakupów i wartość na identyfikator kampanii × identyfikator geograficzny. Porównaj wartość zakupu i liczbę zakupów w różnych kampaniach w każdym regionie.

W ramach strategii A możesz też bezpośrednio odpowiedzieć na to trzecie pytanie:

„Jakie przychody z poszczególnych usług wygenerowały każda z moich kampanii w poszczególnych regionach geograficznych?”

Mimo że wartości podsumowania będą niedokładne, możesz określić, kiedy różnice w wartościach zmierzonych w poszczególnych kampaniach nie wynikają z samego szumu. Więcej informacji znajdziesz w artykule Porozumieć szum.

Strategia B: 2 płytkie drzewa (2 grube struktury kluczy)

W strategii B używasz 2 przybliżonych struktur kluczowych, z których każda zawiera podzbiór potrzebnych wymiarów:

Każdą z tych struktur kluczy dzielisz na 2 typy kluczy, aby realizować 2 cele pomiarowe.

• Typ celu pomiaru = 0, który zdefiniujesz jako liczbę zakupów.
• Typ celu pomiaru = 1, który możesz zdefiniować jako wartość zakupu.

W rezultacie otrzymujesz 4 typy kluczy:

• Typ klucza I-0: struktura klucza I, liczba zakupów.
• Typ klucza I-1: struktura klucza I, wartość zakupu.
• Typ klucza II-0: struktura klucza II, liczba zakupów.
• Typ klucza II-1: struktura klucza II, wartość zakupu.

Raporty podsumowania wyglądają tak:

Strategię B można wyobrazić jako „dwa płytkie drzewa”:

• Wartości podsumowania w raportach podsumowujących są mapowane na jeden z dwóch małych zestawów wymiarów.
• Te wartości podsumowania możesz podsumowywać przy każdym z wymiarów w tych zestawach. Oznacza to, że te podsumowania nie są tak szczegółowe jak w przypadku opcji A, ponieważ ma mniej wymiarów.

W przypadku strategii B na pytania odpowiadasz w ten sposób:

Pytanie	Odpowiedź
Które kategorie produktów są najcenniejsze w każdym regionie?	bezpośredni dostęp do liczby i wartości zakupów podanych w raportach zbiorczych;
Które strategie kampanii są najskuteczniejsze w poszczególnych regionach?	Ma bezpośredni dostęp do podsumowania liczby zakupów i ich wartości, które znajdują się w raportach podsumowujących.

Decyzja: strategia A

Strategia A jest prostsza: wszystkie dane mają tę samą strukturę klucza, co oznacza, że musisz utrzymywać tylko jedną strukturę klucza.

W przypadku strategii A musisz jednak zsumować wartości podsumowania otrzymane w raportach z podsumowaniem, aby uzyskać odpowiedź na niektóre swoje pytania. Każda z tych wartości jest niekompletna. Sumując te dane, sumujesz szum.

Inaczej jest w przypadku strategii B, w której wartości podsumowania widoczne w raportach podsumowujących już zapewniają Ci potrzebne informacje. Oznacza to, że strategia B prawdopodobnie doprowadzi do mniejszego wpływu szumu niż strategia A.

Jak wybrać odpowiednią strategię? W przypadku dotychczasowych reklamodawców lub kampanii możesz polegać na danych historycznych, aby określić, czy większa liczba konwersji jest bardziej odpowiednia dla strategii A czy B. Jednak w przypadku nowych reklamodawców lub kampanii możesz zdecydować się na:

• Zbieraj dane z całego miesiąca za pomocą kluczy szczegółowych (strategia A). Wydłużasz czas zbierania danych, więc wartości podsumowania będą wyższe, a szum – względnie mniejszy.
• Oceń z odpowiednią dokładnością tygodniową liczbę konwersji i wartość zakupów.

Uwaga: nie polegaj na liczbach w raportach ani danych dostępnych tylko w raportach debugowania jako źródła informacji podczas projektowania. W przyszłości dane dostępne w raportach debugowania ulegną zmianie, a obok prawdziwych raportów będą generowane raporty z dużą liczbą błędów. Dlatego sygnały te należy wykorzystywać tylko do sprawdzania implementacji i strategii testowania.

W tym przykładzie załóżmy, że tygodniowa liczba i wartość zakupów są na tyle wysokie, że strategia A doprowadziła do wygenerowania odsetka szumu, który uznajesz za akceptowalny w Twoim przypadku użycia.

Strategia A jest prostsza i prowadzi do negatywnego wpływu szumu, który nie wpływa na Twoją zdolność do podejmowania decyzji, więc decydujesz się na strategię A.

Wybierz algorytm szyfrowania

Postanawiasz stosować klucze generowane na podstawie hasha. Aby to zrobić, musisz wybrać algorytm szyfrowania, który obsługuje tę metodę.

Załóżmy, że wybrano SHA-256. Możesz też użyć prostszego, mniej bezpiecznego algorytmu, np. MD5.

W przeglądarce: ustawianie kluczy i wartości

Po wybraniu struktury klucza i algorytmu szyfrowania możesz rejestrować klucze i wartości, gdy użytkownicy klikają lub wyświetlają reklamy, a później dokonują konwersji.

Poniżej znajdziesz omówienie nagłówków, które musisz ustawić, aby zarejestrować klucze i wartości w przeglądarce:

Konfigurowanie elementów klucza po stronie źródła

Gdy użytkownik kliknie reklamę lub ją obejrzy, ustaw w nagłówku Attribution-Reporting-Register-Aggregatable-Source klucze agregacji. Na tym etapie dla każdego klucza możesz ustawić tylko tę część klucza, czyli fragment klucza, który jest znany w momencie wyświetlania reklam.

Wygenerujmy kluczowe elementy:

Element klucza po stronie źródła dla identyfikatora klucza…	Ciąg znaków zawierający wartości wymiarów, które chcesz ustawić	Hash tego ciągu w formacie szesnastkowym, przycięty do pierwszych 64 bitów (64/4 = 16 znaków^1)	Skrót szesnastkowy z dodanymi zerami, aby uprościć stosowanie operatorów LUB. To jest fragment klucza po stronie źródła.
key_purchaseCount	COUNT, CampaignID=12, GeoID=7	0x3cf867903fbb73ec	0x3cf867903fbb73ec0000000000000000
key_purchaseValue	VALUE, CampaignID=12, GeoID=7	0x245265f432f16e73	0x245265f432f16e730000000000000000

¹ Każda cyfra szesnastkowa reprezentuje 4 bity (cyfry binarne).

Wyznaczmy teraz najważniejsze elementy:

// Upon receiving the request from the publisher site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Source",
  JSON.stringify([
    {
      "id": "key_purchaseCount",
      "key_piece": "0x3cf867903fbb73ec0000000000000000"
    },
    {
      "id": "key_purchaseValue",
      "key_piece": "0x245265f432f16e730000000000000000"
    }
  ])
);

Pamiętaj, że identyfikatory kluczy nie pojawią się w raportach końcowych. Są one używane tylko podczas ustawiania kluczy w przeglądarce, dzięki czemu klucze po stronie źródła i po stronie aktywatora mogą być mapowane ze sobą i łączone w pełny klucz.

Opcjonalnie: raporty na poziomie zdarzenia

Jeśli raportów na poziomie zdarzenia i raportów zbiorczych chcesz używać jednocześnie, sprawdź, czy w przypadku danego źródła można dopasować dane na poziomie zdarzenia (identyfikator źródłowego zdarzenia i dane reguły) do klucza agregacji.

Możesz używać obu raportów, jeśli np. planujesz używać raportów na poziomie zdarzenia do uruchamiania modeli, które wskazują, które typy reklam zwykle prowadzą do największej liczby zakupów.

Użytkownik dokonuje konwersji

Gdy użytkownik dokonuje konwersji, do serwera technologii reklamowych jest zazwyczaj wysyłane żądanie piksela. Po otrzymaniu tej prośby:

• Ustaw fragmenty klucza po stronie konwersji (po stronie reguły), aby uzupełnić klucz. Te kluczowe elementy ustawisz w nagłówku Attribution-Reporting-Register-Aggregatable-Trigger-Data.
• Ustaw wartość agregacyjną dla tej konwersji za pomocą nagłówka.Attribution-Reporting-Register-Aggregatable-Values

Ustaw fragmenty klucza po stronie aktywatora, aby uzupełnić klucz

Wygenerujmy najważniejsze elementy:

Fragment klucza po stronie aktywatora dla identyfikatora klucza...	Ciąg zawierający wartości wymiarów, które chcesz ustawić	Hash tego ciągu w formacie szesnastkowym, przycięty do pierwszych 64 bitów (64/4 = 16 znaków^1)	Skrót szesnastkowy z dodanymi zerami, aby uprościć operator LUB. To jest fragment klucza po stronie źródła.
key_purchaseCount	ProductCategory=25	0x1c7ce88c4904bbe2	0x0000000000000000f9e491fe37e55a0c
key_purchaseValue	(to samo)	(to samo)	(ta sama)

¹ Każda cyfra szesnastkowa reprezentuje 4 bity (cyfry binarne).

Skonfigurujmy teraz najważniejsze elementy:

// Upon receiving the pixel request from the advertiser site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Trigger-Data",
  JSON.stringify([
    // Each dictionary independently adds pieces to multiple source keys
    {
      "key_piece": "0x0000000000000000f9e491fe37e55a0c",
      "source_keys": ["key_purchaseCount", "key_purchaseValue"]
    },
  ])
);

Zwróć uwagę, że dodając ten sam element klucza do kilku kluczy, podajesz kilka identyfikatorów kluczy w sekcji source_keys. Element klucza zostanie dodany do obu kluczy.

Ustaw wartości agregujące

Zanim ustawisz wartości podlegające agregacji, musisz je przeskalować, aby zmniejszyć szum.

Załóżmy, że jeden zakup produktu typu 25 został dokonany za 52 zł.

Tych wartości nie możesz ustawić bezpośrednio jako wartości agregujących:

• key_purchaseCount: 1 konwersja
• key_purchaseValue: 52 USD

Zanim zarejestrujesz te wartości podlegające agregacji, musisz je przekształcić, aby zminimalizować szum.

Masz 2 cele, na które możesz wydać budżet na wkład, więc możesz zdecydować się na jego podział na 2 części.

W tym przypadku każdemu celowi przypisuje się maksymalnie CONTRIBUTION_BUDGET/2(=65 536 / 2 = 32 768).

Załóżmy, że maksymalna wartość zakupu w przypadku pojedynczego użytkownika (na podstawie historii zakupów u wszystkich użytkowników witryny) wynosi 1500 zł. Mogą wystąpić odchylenia od normy, np. bardzo niewielu użytkowników, którzy wydali więcej niż ta suma, ale możesz zignorować te odchylenia.

Współczynnik skalowania wartości zakupu powinien wynosić:

((CONTRIBUTION_BUDGET/2) / 1,500) = 32,768/1,500 = 21.8 ≈ 22

Współczynnik skalowania liczby zakupów to 32 768/1 = 32 768, ponieważ zdecydowałeś(-aś) śledzić maksymalnie 1 zakup na kliknięcie lub obejrzenie reklamy (zmienna source_event).

Możesz teraz ustawić te wartości:

• key_purchaseCount: 1 × 32 768 = 32 768
• key_purchaseValue: 52 × 22 = 1144

W praktyce ustawienia te należy ustawić w ten sposób, korzystając z dedykowanego nagłówka: Attribution-Reporting-Register-Aggregatable-Values:

// Instruct the browser to schedule-send a report
res.set(
  "Attribution-Reporting-Register-Aggregatable-Values",
  JSON.stringify({
    "key_purchaseCount": 32768,
    "key_purchaseValue": 1144,
  })
);

Raport agregacyjny jest generowany

Przeglądarka dopasowuje konwersję do poprzedniego wyświetlenia lub kliknięcia i generuje raport możliwy do zsumowania, który zawiera zaszyfrowany ładunek danych obok metadanych raportu.

Oto przykład danych, które można znaleźć w ładunku raportu podlegającego agregacji, gdyby był on czytelny w postaci zwykłego tekstu:

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece OR conversion-side key piece for the key key_purchaseCount
    value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
  },
  {
    key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece OR conversion-side key piece for the key key_purchaseValue
    value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
  },
]

W jednym (zbiorczym) raporcie znajdują się 2 osobne treści.

Prośba o raport podsumowujący

• Raporty zbiorcze. Postępuj zgodnie z poradami podanymi w artykule Praca zbiorcza.
• Wygeneruj klucze, których dane chcesz wyświetlić. Aby na przykład wyświetlić podsumowanie danych COUNT (łączna liczba zakupów) i VALUE (łączna wartość zakupów) dla kampanii o identyfikatorze 12 × region o identyfikatorze 7 × kategoria produktów 25:
  • Wygeneruj część klucza po stronie źródła, tak jak podczas konfigurowania go w przeglądarce.
  • Wygeneruj klucz po stronie aktywatora w taki sam sposób jak podczas ustawiania go w przeglądarce.

Dane, których dotyczy żądanie^1	Klucz po stronie źródła	Element klucza po stronie wyzwalacza	Klucz do wysyłania żądań do usługi agregacji^2
Łączna liczba zakupów (COUNT)	0x3cf867903fbb73ec 0000000000000000	0x00000000000000 00f9e491fe37e55a0c	0x3cf867903fbb73 ecf9e491fe37e55a0c
Łączna wartość zakupu (VALUE)	0x245265f432f16e73 0000000000000000	0x0000000000000000 f9e491fe37e55a0c	0x245265f432f16e73 f9e491fe37e55a0c

¹ Dane, o które prosisz (identyfikator kampanii 12 × identyfikator geograficzny 7 × kategoria produktów 25). ²Klucz do wysyłania do usługi agregacji = część klucza po stronie źródła LUB część klucza po stronie wyzwalacza.

• Poproś usługę agregującą o dane zbiorcze dotyczące tych kluczy.

Obsługa raportu zbiorczego

Ostatecznie raport podsumowujący może wyglądać tak:

[
  {"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
    "value": "2558500"},
  {"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
    "value": "687060"},
  …
]

Pierwszy zbiór to klucz COUNT w postaci binarnej. Drugi zasobnik to klucz VALUE w pliku binarnym. Pamiętaj, że chociaż klucze są heterogeniczne (COUNT i VALUE), są zawarte w tym samym raporcie.

Uwaga: w praktyce raporty zbiorcze są kodowane w taki sposób, że zbiory i wartości wyglądają inaczej niż w przypadku zbiorów danych (czyli zbiór może wyglądać jak \u0000\u0000\x80\u0000). Zbiór i wartość to oba ciągi bajtów. Przykład znajdziesz tutaj.

Skalowanie wartości w dół

• Wartość 2 558 500 odnosi się do liczby zakupów dla tego klucza, powiększonej o wcześniej obliczony współczynnik skalowania. Współczynnik skalowania dla liczby zakupów wynosił 32 768. Podziel 2 558 500 przez wkład w cel: 2 558 500/32 768 = 156,15 zakupów.
• 687 060 → 687 060/22 = łączna wartość zakupu w wysokości 31 230 USD.

W rezultacie raporty podsumowujące zawierają następujące informacje:

- Within the reporting time period, campaign #12
  run in Europe drove about 156 purchases (± noise)
  for the product category #25
  ```

  ```text
- Within the reporting time period, campaign #12
  run in Europe drove $31,230 of purchases (± noise)
  for the product category #25.