Czym są klucze agregacji, jak są używane w interfejsie Attribution Reporting API i jak przełożyć cele na klucze.
Twoja firma zajmująca się technologiami reklamowymi prowadzi kampanie w wielu lokalizacjach dla różnych kategorii produktów. Chcesz pomóc reklamodawcom uzyskać odpowiedzi na te pytania:
- Ile zakupów w poszczególnych kategoriach produktów przyniosła każda z moich kampanii w poszczególnych regionach geograficznych?
- Jakie przychody z poszczególnych kategorii produktów wygenerowały poszczególne kampanie w poszczególnych regionach geograficznych?
Wiele firm z branży technologii reklamowych zachęca reklamodawców do konfigurowania różnych typów konwersji. Skupianie się na najważniejszych konwersjach, takich jak zakupy, to dobry sposób na uzyskanie szczegółowych i dokładnych wyników podsumowania w przypadku tych ważnych zdarzeń.
W tym celu musisz zastanowić się, na jakie pytania chcesz odpowiedzieć przed zgromadzeniem danych.
Wymiary, klucze i wartości
Aby odpowiedzieć na te pytania, przyjrzyjmy się wymiarom, kluczom i wartościom.
Wymiary
Aby zrozumieć, w jaki sposób kampanie generują przychody, musisz śledzić te wymiary:
- Identyfikator kampanii reklamowej: identyfikator konkretnej kampanii.
- Identyfikator geograficzny: region geograficzny, w którym reklama została wyświetlona.
- Kategoria produktu: określony przez Ciebie typ produktu.
Wymiary „Identyfikator kampanii” i „Identyfikator geograficzny” są znane w momencie wyświetlenia reklamy (czas wyświetlania reklamy), ale kategoria produktu będzie określana na podstawie zdarzenia uruchamiającego, gdy użytkownik dokona konwersji (czasu konwersji).
Wymiary, które chcesz śledzić w tym przykładzie, widać na tej ilustracji:
Czym są klucze agregacji (zasobniki)?
Terminy klucz agregacji i zasobnik odnoszą się do tego samego elementu. Klucz agregacji jest używany w interfejsach API przeglądarek do konfigurowania raportów. Termin zasobnik jest używany w raportach zbiorczych i zbiorczych oraz w interfejsach API usług agregacji.
Klucz agregacji (w skrócie klucz) to fragment danych reprezentujący 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 geograficzny i Identyfikator kampanii.
Jeśli użytkownik z identyfikatora geograficznego 7 zobaczy reklamę z identyfikatorem kampanii 12, a później dokona konwersji, kupując produkt w kategorii produktów 25, możesz ustawić klucz agregacji podobny do tego na ilustracji poniżej:
Jak widać później, klucz agregacji nie wygląda tak samo w praktyce, ale na razie skupmy się na informacjach zawartych w tym kluczu.
Czym są wartości zbiorcze?
Aby uzyskać odpowiedzi na pytania dotyczące wymiarów, które omówiliśmy, podaj te informacje:
- Liczba zakupów (liczba zakupów). Po zagregowaniu i udostępnieniu w raporcie podsumowującym będzie to łączna liczba zakupów (wartość podsumowania).
- Przychody z każdego zakupu (wartość zakupu). Po zagregowaniu i udostępnieniu w raporcie podsumowującym będą to łączne przychody (wartość podsumowania).
Każda z tych wartości (liczba zakupów na 1 konwersję i wartość zakupu w przypadku jednej konwersji) jest wartością zbiorczą. Wartości, które można łączyć, można traktować jako wartości celów pomiarowych.
| Pytanie | Agregacja wartości = cel pomiaru |
|---|---|
| Liczba zakupów... | Liczba zakupów, |
| Jakie przychody... | Wartość zakupu |
Jeśli użytkownik z obszaru o identyfikatorze geograficznym 7 zobaczy reklamę z identyfikatorem kampanii 12, a później dokona konwersji, kupując produkt z kategorii produktów 25 za 120 zł (przy założeniu, że Twoja waluta to dolar amerykański), możesz ustawić klucz agregacji i wartości zbiorcze, które będą wyglądać tak:
Agregowane wartości są sumowane według klucza wielu użytkowników, co umożliwia generowanie zbiorczych statystyk w formie wartości podsumowujących w raportach podsumowujących.
Agregujące wartości są sumowane, aby wygenerować zbiorcze statystyki na potrzeby celów pomiarowych.
Pamiętaj, że ten diagram pomija odszyfrowywanie i przedstawia uproszczony przykład bez szumu. W następnej sekcji omówimy ten przykład z użyciem szumu.
Od kluczy i wartości do raportów
Porozmawiajmy teraz o tym, jak agregowane klucze i wartości są powiązane z raportami.
Raporty zbiorcze
Gdy użytkownik kliknie lub wyświetli reklamę, a potem dokona konwersji, informujesz przeglądarkę, że ma przechowywać parę {agregation key, aggregatable value}.
W naszym przykładzie, gdy użytkownik kliknie lub wyświetli reklamę, a potem dokona konwersji, instruujesz przeglądarkę, aby wygenerowała 2 elementy (po jednym na każdy cel pomiaru).
Jak przekonasz się później, {agregation key, aggregatable value} raport nie wygląda identycznie jak ten raport, ale skupmy się teraz na informacjach zawartych w tym raporcie.
Gdy postanowisz wygenerować w przeglądarce 2 elementy składowe, przeglądarka wygeneruje raport skumulowany (jeśli może dopasować konwersję do wcześniejszego wyświetlenia lub kliknięcia).
Raport zbiorczy zawiera:
- Skonfigurowane przez Ciebie darowizny.
- Metadane zdarzenia kliknięcia lub wyświetlenia oraz zdarzenia konwersji: witryny, w której nastąpiła konwersja, itp. Przejrzyj wszystkie pola w raporcie zbiorczym
Raporty zbiorcze mają format JSON i zawierają między innymi pole ładunku, które będzie używane jako dane wejściowe w końcowym raporcie podsumowującym.
Ładunek zawiera listę elementów, z których każdy jest parą {aggregation key, aggregatable value}:
- zasobnika: klucz agregacji zakodowany w postaci ciągu bajtów.
- value: zagregowana wartość celu pomiaru, zakodowana w postaci ciągu bajtów.
Oto przykład:
{
"data": [
{
"bucket": "111001001",
"value": "11111010000",
}
],
"operation": "histogram"
}
W praktyce raporty możliwe do zagregowania są kodowane w taki sposób, że zasobniki i wartości wyglądają inaczej niż w poprzednim przykładzie (tzn. zasobnik może wyglądać tak: \u0000\u0000\x80\u0000). Zasobnik i wartość to ciągi bajtów.
Raporty podsumowujące
Zbiorcze raporty są zbierane z różnych przeglądarek i urządzeń (użytkowników) w taki sposób:
- Technologie reklamowe żądają raportów podsumowujących dla danego zestawu kluczy i zbiorczego zbioru raportów pochodzących z wielu różnych przeglądarek (użytkowników).
- Raporty zbiorcze są odszyfrowywane przez usługę agregacji.
- Przy każdym kluczu sumowane są wartości zbiorcze z raportów zbiorczych.
- Szum jest dodawany do wartości podsumowania.
Wynik to raport podsumowujący, który zawiera zestaw par {agregation key,summary value}.
Raport podsumowujący zawiera zestaw par klucz-wartość w stylu słownika JSON. Każda para zawiera:
- zasobnika: klucz agregacji zakodowany w postaci ciągu bajtów.
- wartość: suma wartości dziesiętnej danego celu pomiaru, zsumowana ze wszystkich dostępnych raportów zbiorczych, z dodatkowym poziomem szumu.
Przykład:
[
{"bucket": "111001001", "value": "2558500"},
{"bucket": "111101001", "value": "3256211"},
{...}
]
W praktyce raporty podsumowujące są kodowane w taki sposób, że zasobniki i wartości wyglądają inaczej niż w przykładzie (tzn. zasobnik może wyglądać tak: \u0000\u0000\x80\u0000). Zasobnik i wartość to ciągi bajtów.
Klucze agregacji w praktyce
Klucze agregujące (zasobniki) są definiowane przez firmę zajmującą się technologiami reklamowymi. Zwykle przebiegają w 2 krokach: po kliknięciu lub wyświetleniu reklamy i dokonaniu konwersji przez użytkownika.
Struktura klucza
Termin struktura klucza oznacza zestaw wymiarów zakodowanych w kluczu.
Na przykład identyfikator kampanii x identyfikator geograficzny x kategoria produktu to kluczowa struktura.
Typy kluczy
Agregujące wartości są sumowane dla danego klucza w różnych użytkownikach/przeglądarkach. Zauważyliśmy jednak, że wartości zbiorcze mogą śledzić różne cele pomiarowe, np. wartość zakupu lub liczbę zakupów. Chcesz mieć pewność, że usługa agregacji będzie sumować wartości agregujące tego samego typu.
Aby to zrobić, w każdym kluczu zakoduj fragment danych informujący, co reprezentuje wartość podsumowująca – cel pomiaru, do którego odnosi się ten klucz. Możesz na przykład utworzyć dla klucza dodatkowy wymiar, który reprezentuje typ celu pomiaru.
We wcześniejszym przykładzie ten typ celu pomiarowego miałby 2 różne możliwe wartości:
- Liczba zakupów to pierwszy typ celu pomiaru.
- Wartość zakupu to drugi typ celu pomiaru.
Jeśli masz n celów pomiarowych, typ celu pomiarowego miałby n różnych typów wartości.
Wymiary klucza możesz traktować jako dane. na przykład „liczba zakupów określonego produktu w ramach kampanii na danym obszarze geograficznym”.
Rozmiar klucza, rozmiar wymiaru
Maksymalny rozmiar klucza jest określony w bitach, czyli liczbie zer i jedynek w postaci binarnej, która tworzy pełny klucz. Interfejs API zezwala na długość klucza 128 bitów.
Taki rozmiar umożliwia stosowanie bardzo szczegółowych kluczy, ale bardziej szczegółowe klucze prowadzą do bardziej zaszumionych wartości. Więcej informacji o szumie znajdziesz w artykule Zrozumienie szumu.
Jak już wspomnieliśmy, wymiary są kodowane w kluczu agregacji. Każdy wymiar ma pewną moc zbioru, czyli liczbę różnych wartości, jakie może przyjąć. W zależności od swojej mocy zbioru każdy wymiar musi być reprezentowany przez określoną liczbę bitów. Za pomocą bitów n można wyrazić 2n różnych opcji.
Na przykład wymiar Kraj może mieć moc zbioru równą 200, ponieważ na świecie jest około 200 krajów. Ile bitów jest potrzebnych do zakodowania tego wymiaru?
7 bitów umożliwia przechowywanie tylko 27 =128 różnych opcji, czyli mniej niż wymagana wartość 200.
8 bitów umożliwia zapisanie 28 =256 różnych opcji, czyli więcej niż niezbędne 200 bitów, więc do zakodowania tego wymiaru można użyć n=8 bitów.
Kodowanie klucza
Klucze ustawiane w przeglądarce powinny być zakodowane w formacie szesnastkowym. W raportach podsumowujących klucze pojawią się w formacie binarnym (i będą nazywane zasobnikami).
Ustaw 2 klucze dla pełnego klucza
Załóżmy, że używasz klucza do śledzenia tych wymiarów:
- Identyfikator kampanii
- Identyfikator regionu
- Kategoria produktu
Wymiary „Identyfikator kampanii” i „Identyfikator geograficzny” są znane w momencie wyświetlenia reklamy (czas wyświetlania reklamy), ale kategoria produktu jest określana na podstawie zdarzenia uruchamiającego, gdy użytkownik wykona konwersję (czas konwersji).
W praktyce oznacza to, że musisz skonfigurować klucz w 2 krokach:
- Jedna część klucza – identyfikator kampanii x identyfikator regionu geograficznego – ustawia się na czas kliknięcia lub wyświetlenia.
- Drugą część klucza, czyli kategorię produktu, ustawisz w czasie konwersji.
Te różne części są nazywane częściami kluczy.
Klucz jest obliczany na podstawie wartości XOR (^) jego fragmentów.
Przykład:
- Klucz po stronie źródła =
0x159 - Klucz po stronie wyzwalacza =
0x400 - Klucz =
0x159 ^ 0x400 = 0x559
Wyrównywanie kluczowych elementów
W przypadku dwóch 64-bitowych fragmentów kluczy wydłużonych do 128 bitów przy użyciu starannie rozmieszczonych 64-bitowych wypełniaczy/przesunięć (szesnaście zer) łączenie kluczy XOR jest równoważne z konkatenacją, co ułatwia analizę i weryfikację:
- Klucz po stronie źródła =
0xa7e297e7c8c8d0540000000000000000 - Klucz po stronie wyzwalacza =
0x0000000000000000674fbe308a597271 - Klucz =
- 0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 =
- 0xa7e297e7c8c8d054674fbe308a597271
Wiele kluczy na kliknięcie lub wyświetlenie reklamy
W praktyce możesz ustawić wiele kluczy dla każdego zdarzenia źródła atrybucji (kliknięcia lub wyświetlenia reklamy). Możesz na przykład ustawić:
- Klucz śledzący identyfikator geograficzny x identyfikator kampanii.
- Kolejny klucz do śledzenia Typ kreacji x Identyfikator kampanii.
Przeanalizujmy Strategię B jako kolejny przykład.
Kodowanie wymiarów w klucze
Wysyłając żądanie raportów podsumowujących, musisz wskazać usłudze agregacji, do jakich danych chcesz uzyskać dostęp, wysyłając żądanie raportów podsumowujących dla określonego zestawu kluczy agregacji.
Raporty podsumowania zawierają nieprzetworzone pary {klucz, wartość podsumowania} bez dodatkowych informacji o kluczu. Oznacza to, że:
- Gdy konfigurujesz klucze, gdy użytkownik wyświetla lub klika reklamę, a później dokonuje konwersji, musisz skonfigurować klucze na podstawie wartości wymiarów, które reprezentują.
- Podczas definiowania kluczy, dla których chcesz otrzymywać raporty podsumowujące, musisz niezawodnie generować te same klucze lub mieć do nich dostęp na bieżąco, co klucze ustawione, gdy użytkownik wyświetlił lub kliknął reklamę i dokonał konwersji, na podstawie wartości wymiarów, których dane zbiorcze chcesz wyświetlić.
Kodowanie wymiarów za pomocą map struktury kluczy
Aby zakodować wymiary w kluczach, możesz z wyprzedzeniem utworzyć i obsługiwać mapę struktury kluczy po zdefiniowaniu kluczy (przed rozpoczęciem wyświetlania reklam).
Mapa struktury klucza przedstawia wszystkie wymiary i ich pozycję w kluczu.
W praktyce tworzenie i utrzymywanie map struktur kluczowych oznacza, że trzeba wdrożyć i utrzymywać logikę dekodera. Jeśli szukasz metody, która nie wymaga tego robić, rozważ zastosowanie metody opartej na haszowaniu.
Oto przykład:
Załóżmy, że planujesz śledzić zarówno zakupy, jak i wartości zakupów w określonych kampaniach, regionach geograficznych i produktach.
Kategoria produktu, identyfikator geograficzny i identyfikator kampanii muszą być wymiarami w kluczach. Poza tym chcesz śledzić 2 różne cele pomiarowe – liczba zakupów i wartość zakupów – musisz dodać do klucza 1 wymiar, który będzie śledził typ klucza. Pozwoli Ci to określić, co faktycznie reprezentuje wartość zagregowana po otrzymaniu par {key, aggregatable value} w raportach podsumowujących.
W przypadku tych celów pomiarowych klucz ma następujące wymiary:
- Kategoria produktu
- Typ celu pomiaru
- Identyfikator regionu
- Identyfikator kampanii
Teraz przyglądając się poszczególnym wymiarom, załóżmy w Twoim przypadku użycia, że chcesz śledzić:
- 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, jaką musisz zakodować do zakodowania każdego wymiaru w kluczu:
- Kategoria produktu: 5 bitów (25 = 32 > 29).
- Typ celu pomiaru: 1 bit. Celem pomiaru jest liczba lub wartość zakupu, co oznacza 2 różne możliwości – do zapisania tych danych wystarczy 1 bit.
Identyfikator regionu geograficznego: 3 bity (23 = 8). Definiujesz też mapę wymiarów dla identyfikatora regionu geograficznego, by wiedzieć, jaki region geograficzny reprezentuje każda wartość binarna. Mapa wymiarów dla wymiaru identyfikatora geograficznego 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 (24 = 16)
Klucze następujące po tej strukturze będą miały 13 bitów (5 + 1 + 3 + 4).
W tym przykładzie mapa struktury kluczy tych kluczy będzie wyglądać tak:
Kolejność wymiarów w kluczu należy do Ciebie.
Aby pokazać, jak wymiary składają się na strukturę kluczową, wykorzystamy reprezentację binarną – identyfikator kampanii (pierwsze bity) jest widoczny najdalej z prawej strony, a kategoria produktu (ostatnie bity) – po lewej.
W każdym wymiarze najważniejszym bitem, czyli tym, który ma największą wartość liczbową,, jest bit znajdujący się najbardziej po lewej stronie. Najmniej istotny bit, czyli ten, który ma najmniejszą wartość liczbową, to bit znajdujący się najbardziej po prawej stronie.
Zobaczmy, jak można użyć mapy struktury klawiszy do zdekodowania klucza.
Przyjmijmy, że klucz 0b1100100111100 to dowolny przykładowy klucz i załóżmy, że masz sposób, aby się dowiedzieć, że ten klucz występuje zgodnie z mapą struktury kluczy na poprzedniej ilustracji.
Zgodnie z mapą struktury kluczy ten klucz dekodowałby się na:
11001 0 011 1100
Klucz 0b1100100111100 reprezentuje liczbę zakupów kategorii produktów 25 dla identyfikatora kampanii 12 wprowadzonej w Europie.
Wymiary kodowania z użyciem funkcji skrótu
Zamiast mapy struktury kluczy możesz użyć funkcji haszującej, aby dynamicznie generować klucze w spójny i niezawodny sposób.
Działa to w ten sposób:
- Wybierz algorytm szyfrowania.
- W momencie wyświetlania reklam wygeneruj ciąg znaków zawierający wszystkie wymiary, które chcesz śledzić, oraz ich wartości. Aby wygenerować klucz po stronie źródła, zahaszuj ten ciąg znaków i rozważ dodanie 64-bitowego sufiksu zer, aby wyrównać go z kluczem po stronie aktywatora i ułatwić sobie uzasadnienie XOR.
- Fragment klucza po stronie źródła
= <64-bitowy hasz szesnastkowy("COUNT, campaignID=12, geoID=7"))><64-bitowy 00000000...> - Zwróć uwagę, że w metodzie mapy kluczowej funkcja COUNT koduje to samo, co matchingGoalType=0. COUNT jest nieco węższy i bardziej wyrazisty.
- Fragment klucza po stronie źródła
- Podczas konwersji wygeneruj ciąg znaków zawierający wszystkie wymiary, które chcesz śledzić, oraz ich wartości. Aby wygenerować klucz po stronie aktywatora, zaszyfruj ten ciąg znaków i dodaj 64-bitowy prefiks zer:
- Klucz po stronie aktywatora = <64-bitowy 00000000...><64-bitowy hasz szesnastkowy("productCategory=25")>
- Przeglądarka XOR przetwarza te klucze, aby wygenerować klucz.
- 128-bitowy klucz agregacji
= <64-bitowy szesnastkowy kod klucza po stronie źródła><64-bitowy szesnastkowy kod klucza po stronie źródła>
- 128-bitowy klucz agregacji
- Aby później pobrać raport podsumowujący dotyczący tego klucza, wygeneruj go na bieżąco:
- Na podstawie interesujących Cię wymiarów wygeneruj klucz po stronie źródła i po stronie reguły, tak jak poprzednio.
- Fragment klucza po stronie źródła
= <64-bitowy hasz szesnastkowy("COUNT, campaignID=12, geoID=7"))><64-bitowy 00000000...> - Klucz po stronie aktywatora
= <64-bitowy 00000000...><64-bitowy hasz szesnastkowy("productCategory=25")> - klucz po stronie aktywatora = toHex(hash("productCategory=25"))
- Fragment klucza po stronie źródła
- XOR – tak jak w przypadku przeglądarki, umożliwia generowanie tego samego klucza, który przeglądarka wygenerowała wcześniej.
- 128-bitowy klucz agregacji
= <64-bitowy hasz klucza po stronie źródła><64-bitowy klucz fragmentu po stronie źródła>
- 128-bitowy klucz agregacji
- Na podstawie interesujących Cię wymiarów wygeneruj klucz po stronie źródła i po stronie reguły, tak jak poprzednio.
Kilka praktycznych wskazówek dotyczących korzystania z tej metody opartej na haszach:
- Zawsze używaj tej samej kolejności wymiarów. Dzięki temu hasze mogą być generowane ponownie. ("COUNT, IDKampanii=12, GeoID=7" nie wygeneruje takiego samego skrótu co "LICZ, GeoID=7, IDKampanii=12"). Prostym sposobem, aby to osiągnąć, jest posortowanie wymiarów alfanumerycznie. Tym właśnie się zajmiemy w przykładzie, z tą różnicą, że jako pierwszy element w wymiarze zawsze decyduje LICZBA lub WARTOŚĆ – wybór należy do kwestii czytelności, ponieważ LICZBA lub WARTOŚĆ kodują informacje nieco odmienne od pozostałych wymiarów.
- Śledź zestaw wymiarów wykorzystywanych w kluczach. Nie chcesz generować kluczy na podstawie nigdy nieużywanego zestawu wymiarów.
- Jeśli używana jest odpowiednia funkcja skrótu, zderzenia z haszami występują rzadko, ale sprawdzenie ich przy użyciu wcześniej używanych haszów (które powinny być przechowywane w celu interpretacji wyników z usługi agregacji) może zapobiec wprowadzaniu nowych kluczy, które kolidują ze starszymi kluczami.
Zobacz, jak w praktyce korzystać z kluczy opartych na haszach, w przykładzie dotyczącym 1 konwersji na kliknięcie lub wyświetlenie.
Agregowane wartości w praktyce
Firma zajmująca się technologiami reklamowymi wyznacza agregujące wartości, gdy użytkownik dokonuje konwersji.
Aby chronić prywatność użytkowników, obowiązuje górny limit publikowania treści przez każdego użytkownika. W przypadku wszystkich wartości zbiorczych powiązanych z pojedynczym źródłem (kliknięcie lub wyświetlenie reklamy) żadna wartość nie może być wyższa niż określony limit darowizn.
Określamy ten limit jako CONTRIBUTION_BUDGET. W objaśnieniu ten limit nazywa się Budżet L1, ale jest taki sam jak CONTRIBUTION_BUDGET.
Szczegółowe informacje o budżecie darowizn znajdziesz w artykule Budżet na darowizny w raportach podsumowujących.
Przykład: jedna konwersja na kliknięcie lub wyświetlenie
W tym przykładzie załóżmy, że chcesz odpowiedzieć na następujące pytania:
- Które kategorie produktów są najbardziej wartościowe w każdym regionie?
- Które strategie kampanii są najskuteczniejsze w każdym regionie?
Załóżmy też, że w Twoim przypadku potrzebujesz cotygodniowych statystyk.
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ć
Chociaż wiele firm z branży technologii reklamowych zachęca reklamodawców do konfigurowania różnych typów konwersji, skupienie się na najważniejszych konwersjach, np. zakupach, to dobry sposób na uzyskanie szczegółowych i dokładnych wyników zbiorczych w przypadku tych ważnych zdarzeń konwersji. Rzeczywiście im więcej danych mierzysz, tym mniejszy budżet na dany rodzaj danych i tym bardziej zaszumiona jest każda wartość. Musisz więc dobrze wybrać, co chcesz mierzyć.
W tym przykładzie skupimy się na konfiguracjach kampanii, które mierzą tylko jedną konwersję na kliknięcie lub wyświetlenie, czyli na zakup.
Nadal będziesz mierzyć liczbę i wartość zakupów, a także uzyskać dostęp do różnych ważnych statystyk zbiorczych, takich jak łączna wartość zakupów i podział geograficzny. Pozwala to utrzymać odpowiedni poziom szumu i ułatwia skalowanie budżetu darowizn.
A co z walutami?
Prowadzenie kampanii w różnych regionach wymaga uwzględnienia walut. Możesz:
- Ustaw walutę jako dedykowany wymiar w kluczach agregacji.
- Możesz też wywnioskować walutę na podstawie identyfikatora kampanii i przeliczyć wszystkie waluty na waluty referencyjne.
W tym przykładzie zakładamy, że możesz wywnioskować walutę na podstawie identyfikatora kampanii. Dzięki temu możesz przeliczać dowolną wartość zakupu z waluty lokalnej użytkownika na wybraną przez Ciebie walutę referencyjną. Możesz też przeprowadzić tę konwersję na bieżąco, gdy użytkownik kupi produkt.
Dzięki tej metodzie wszystkie wartości zbiorcze są podawane w tej samej walucie referencyjnej i dlatego można je zsumować w celu wygenerowania łącznej łącznej wartości zakupu (czyli łącznej wartości zakupu).
Przekształć cele w klucze
Korzystając z celów i danych związanych z pomiarami, masz do wyboru różne opcje kluczowej strategii. Skupmy się na 2 z tych strategii:
- Strategia A: jedna szczegółowa struktura klucza.
- Strategia B: 2 ogólne struktury kluczowe.
Strategia A: jedno głębokie drzewo (1 szczegółowa struktura klucza)
W strategii A używasz jednej szczegółowej struktury klucza, która obejmuje wszystkie potrzebne wymiary:
Tej struktury używają wszystkie Twoje klucze.
Dzielisz tę strukturę klucza na 2 typy, aby obsługiwać 2 cele pomiarowe.
- Typ klucza 0: typ celu pomiaru = 0, który określasz jako liczbę zakupów.
- Typ klucza 1: typ celu pomiaru = 1, który określasz jako wartość zakupu.
Raporty podsumowujące wyglądają tak:
Strategię A można traktować jako „jedno głębokie drzewo”:
- Każda wartość podsumowująca w raportach podsumowujących jest powiązana ze wszystkimi śledzonymi wymiarami.
- Podsumowanie możesz podsumowywać wartości z każdym z tych wymiarów, dzięki czemu dane o podsumowaniach mogą być głębsze od posiadanych przez Ciebie wymiarów.
Dzięki strategii A możesz uzyskać odpowiedź na swoje pytania w następujący sposób:
| Pytanie | Odpowiedź |
|---|---|
| Które kategorie produktów są najbardziej wartościowe w każdym regionie? | Sumowanie łącznej liczby zakupów i wartości znajdujących się w raportach podsumowujących we wszystkich kampaniach. W ten sposób zobaczysz liczbę i wartość zakupów przypadającą na identyfikator geograficzny i kategorię produktów. W każdym regionie porównaj wartość zakupu i liczbę różnych kategorii produktów. |
| Które strategie kampanii są najskuteczniejsze w każdym regionie? | Sumowanie łącznej liczby zakupów i wartości znajdujących się w raportach podsumowujących dla wszystkich kategorii produktów. W ten sposób poznasz liczbę zakupów oraz wartość na identyfikator kampanii i identyfikator geograficzny. Porównaj wartość zakupu i liczbę zakupów w każdym regionie w przypadku różnych kampanii. |
Dzięki strategii A możesz też bezpośrednio odpowiedzieć na to trzecie pytanie:
„Jakie przychody z poszczególnych produktów wygenerowały poszczególne kampanie w poszczególnych regionach geograficznych?”
Mimo że wartości podsumowujące będą odszukiwać, możesz określić, kiedy różnice w wartościach mierzonych w poszczególnych kampaniach nie wynikają tylko z samego szumu. Aby dowiedzieć się, jak to zrobić, przeczytaj artykuł Interpretowanie szumu.
Strategia B: dwa płytkie drzewa (dwie ogólne struktury kluczowe)
W strategii B korzystasz z 2 grubszych struktur kluczowych, z których każda zawiera podzbiór potrzebnych wymiarów:
Dzielisz każdą z tych kluczowych struktur na 2 rodzaje kluczy, aby obsługiwać 2 cele z pomiarami.
- Typ celu pomiaru = 0, który definiujesz jako liczbę zakupów.
- Typ celu pomiaru = 1, który określasz jako wartość zakupu.
Dzielą się przez to cztery 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 podsumowujące wyglądają tak:
Strategię B można traktować jako rodzaj „dwóch płytkich drzew”:
- Wartości podsumowujące w raportach podsumowujących są mapowane na jeden z 2 niewielkich zbiorów wymiarów.
- Możesz podsumowywać wartości z każdego wymiaru w tych zestawach. Oznacza to, że dane o podsumowaniu nie są tak szczegółowe jak w opcji A ze względu na mniejszą liczbę wymiarów do podłączenia.
Dzięki strategii B możesz uzyskać odpowiedź na swoje pytania w następujący sposób:
| Pytanie | Odpowiedź |
|---|---|
| Które kategorie produktów są najbardziej wartościowe w każdym regionie? | Ma bezpośredni dostęp do podsumowania liczby zakupów i ich wartości w raportach podsumowujących. |
| Które strategie kampanii są najskuteczniejsze w każdym regionie? | Ma bezpośredni dostęp do podsumowania liczby zakupów i ich wartości w raportach podsumowujących. |
Decyzja: strategia A
Strategia A jest prostsza: wszystkie dane mają tę samą kluczową strukturę, co oznacza, że masz tylko jedną kluczową strukturę do utrzymania.
W przypadku strategii A musisz jednak zsumować wartości podsumowujące otrzymywane w raportach podsumowujących, aby uzyskać odpowiedzi na niektóre z Twoich pytań. Każda z tych wartości podsumowujących jest zniekształcona. Sumując te dane, sumujesz szum.
Inaczej jest w przypadku strategii B, w której wartości podsumowujące dostępne w raportach podsumowujących dostarczają już potrzebne informacje. Oznacza to, że strategia B będzie prawdopodobnie miała mniejszy wpływ szumu niż strategia A.
Jak wybrać najlepszą strategię? W przypadku obecnych reklamodawców lub kampanii możesz polegać na danych historycznych, aby określić, czy liczba konwersji jest bardziej odpowiednia dla strategii A czy strategii B. W przypadku nowych reklamodawców i kampanii możesz jednak zdecydować:
- Zbieraj dane z danego miesiąca za pomocą szczegółowych kluczy (strategia A). Wydłużasz czas zbierania danych, więc wartości podsumowujące będą wyższe, a szum – stosunkowo mniejszy.
- Oceń z odpowiednią dokładnością tygodniową liczbę konwersji i wartość zakupów.
W tym przykładzie załóżmy, że tygodniowa liczba zakupów i wartość zakupów są na tyle wysokie, że strategia A umożliwiłaby osiągnięcie odsetka szumu, który jest dla Ciebie akceptowalny w Twoim przypadku.
Strategia A jest prostsza i generuje szum, który nie wpływa negatywnie na możliwość podejmowania decyzji, dlatego postanawiasz wybrać strategię A.
Wybierz algorytm szyfrowania
Do generowania kluczy postanawiasz przyjąć podejście oparte na haszach. Aby to zrobić, musisz wybrać algorytm szyfrowania, który obsługuje tę metodę.
Załóżmy, że wybrano zakres SHA-256. Możesz też użyć prostszego i mniej bezpiecznego algorytmu, np. MD5.
W przeglądarce: ustaw klucze i wartości
Po określeniu struktury klucza i algorytmu szyfrowania możesz zacząć rejestrować klucze i wartości, gdy użytkownicy klikną lub zobaczą reklamy, a potem dokonają konwersji.
Teraz omówimy nagłówki, które skonfigurujesz do rejestrowania kluczy i wartości w przeglądarce:
Ustaw fragmenty kluczy po stronie źródła
Gdy użytkownik kliknie lub wyświetli reklamę, ustaw w nagłówku Attribution-Reporting-Register-Aggregatable-Source klucze agregacji.
Na tym etapie dla każdego klucza możesz ustawić tylko tę część, czyli klucz, znaną w czasie wyświetlania reklamy.
Wygenerujmy kluczowe fragmenty:
| Klucz po stronie źródła dla identyfikatora klucza... | Ciąg tekstowy zawierający wartości wymiarów, które chcesz ustawić | Hasz tego ciągu w formacie szesnastkowym przycięty do pierwszych 64 bitów (64/4 = 16 znaków1) | Szesnastkowy hasz z dołączonymi zerami, aby uprościć wykonywanie operacji XOR. To jest klucz po stronie źródła. |
|---|---|---|---|
| key_purchaseCount | LICZBA, IDKampanii=12, identyfikator geograficzny=7 | 0x3cf867903fbb73ec | 0x3cf867903fbb73ec0000000000000000 |
| key_purchaseValue | VALUE, CampaignID=12, GeoID=7 | 0x245265f432f16e73 | 0x245265f432f16e730000000000000000 |
Ustalmy 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 konfigurowania kluczy w przeglądarce, dzięki czemu klucze po stronie źródła i po stronie aktywatora mogą być ze sobą mapowane i łączone w pełny klucz.
Opcjonalnie: raporty na poziomie zdarzenia
Jeśli musisz używać raportów na poziomie zdarzenia razem z raportami agregującymi, upewnij się, że w przypadku danego źródła dane na poziomie zdarzenia (identyfikator zdarzenia źródłowego i dane reguły) oraz klucz agregacji mogą być dopasowane.
Obydwu raportów możesz używać, jeśli np. planujesz korzystać z raportów na poziomie zdarzenia, aby uruchamiać modele, dla których typów reklam najczęściej generują najwięcej zakupów.
Użytkownik dokonuje konwersji
Gdy użytkownik dokonuje konwersji, do serwera technologii reklamowych wysyłane jest zwykle żądanie piksela. Po otrzymaniu tego żądania:
- Ustaw fragmenty kluczy po stronie konwersji (po stronie reguły), aby uzupełnić klucz.
Kluczowe elementy ustawisz w nagłówku
Attribution-Reporting-Register-Aggregatable-Trigger-Data. - Ustaw możliwą do agregacji wartość tej konwersji w nagłówku
Attribution-Reporting-Register-Aggregatable-Values.
Ustaw fragmenty klucza po stronie spustu, aby zakończyć klucz
Wygenerujmy kluczowe fragmenty:
| Klucz po stronie wyzwalacza dla identyfikatora klucza... | Ciąg tekstowy zawierający wartości wymiarów, które chcesz ustawić | Hasz tego ciągu w formacie szesnastkowym przycięty do pierwszych 64 bitów (64/4 = 16 znaków1) | Szesnastkowy hasz z dołączonymi zerami w celu simplify operacji XOR. To jest klucz po stronie źródła. |
|---|---|---|---|
| key_purchaseCount | Kategoria produktu=25 | 0x1c7ce88c4904bbe2 | 0x0000000000000000f9e491fe37e55a0c |
| key_purchaseValue | (taka sama) | (taka sama) | (taka sama) |
Ustalmy 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ę, jak dodajesz ten sam klucz do kilku kluczy, podając kilka identyfikatorów w source_keys – klucz zostanie dodany do obu kluczy.
Ustaw wartości, które można agregować
Zanim ustawisz wartości agregujące, musisz przeskalować je w górę, aby ograniczyć szum.
Załóżmy, że dokonano jednego zakupu dla produktu typu 25 za 52 zł.
Nie możesz ustawić tych wartości bezpośrednio jako wartości zbiorczych:
key_purchaseCount: 1 konwersjakey_purchaseValue: 52 USD
Zamiast tego przed zarejestrowaniem tych wartości zbiorczych musisz je przeskalować w celu zminimalizowania szumu.
Masz 2 cele, względem których możesz wydawać środki z budżetu na wpłatę, więc możesz zdecydować się na ich podział na dwie części.
W tym przypadku każdemu celowi przydzielone są maksymalnie CONTRIBUTION_BUDGET/2(=65 536/2=32 768).
Przyjmijmy, że maksymalna wartość zakupu dla jednego użytkownika (na podstawie historii zakupów dokonywanych przez wszystkich użytkowników witryny) wynosi 1500 zł. Mogą być wyjątki, np. bardzo niewielu użytkowników, którzy wydali ponad kwotę, możesz je zignorować.
Współczynnik skalowania wartości zakupu powinien wynosić:
((CONTRIBUTION_BUDGET/2) / 1500) = 32 768/1500 = 21,8~ 22
Współczynnik skalowania liczby zakupów wynosi 32 768/1 = 32 768, ponieważ według Twoich ustawień chcesz śledzić maksymalnie 1 zakup na kliknięcie lub wyświetlenie reklamy (zdarzenie źródłowe).
Możesz teraz ustawić te wartości:
key_purchaseCount: 1*32 768 = 32 768key_purchaseValue: 52*22 = 1144
W praktyce możesz ustawić je w ten sposób z użyciem 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 zbiorczy jest generowany
Przeglądarka dopasowuje konwersję do poprzedniego widoku lub poprzedniego kliknięcia i generuje raport możliwy do zagregowania, który zawiera zaszyfrowany ładunek obok metadanych raportu.
Oto przykład danych, które można znaleźć w ładunku raportu zbiorczego, jeśli byłyby czytelne w postaci tekstu nieszyfrowanego:
[ {
key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece XOR 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 XOR 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 widać 2 osobne treści.
Poproś o raport podsumowujący
- Zbiorowe raporty zbiorcze. Postępuj zgodnie ze wskazówkami w artykule Grupowanie.
- Wygeneruj klucze, których dane chcesz wyświetlić. Aby np. zobaczyć podsumowanie danych dotyczących COUNT (łącznej liczby zakupów) i VALUE (łącznej wartości zakupu) w przypadku identyfikatora kampanii 12 x identyfikator geograficzny 7 x kategorii produktów 25:
- Wygeneruj klucz po stronie źródła, tak jak podczas konfigurowania go w przeglądarce.
- Wygeneruj klucz po stronie aktywatora, tak jak podczas konfigurowania go w przeglądarce.
| Dane, o które prosisz1 | Klucz po stronie źródła | Klucz po stronie spustu | Klucz żądania do usługi agregacji2 |
|---|---|---|---|
| Łączna liczba zakupów (COUNT) | 0x3cf867903fbb73ec 0000000000000000 |
0x00000000000000 00f9e491fe37e55a0c |
0x3cf867903fbb73 ecf9e491fe37e55a0c |
| Łączna wartość zakupu (VALUE) | 0x245265f432f16e73 0000000000000000 |
0x0000000000000000 f9e491fe37e55a0c |
0x245265f432f16e73 f9e491fe37e55a0c |
- Poproś o dane podsumowujące dla tych kluczy do usługi agregacji.
Obsługa raportu podsumowującego
Otrzymasz raport podsumowujący, który może wyglądać tak:
[
{"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
"value": "2558500"},
{"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
"value": "687060"},
…
]
Pierwszy zasobnik to klucz COUNT w pliku binarnym. Drugi zasobnik to klucz VALUE w pliku binarnym. Pamiętaj, że chociaż klucze są heterogeniczne (COUNT w porównaniu z VALUE), znajdują się w tym samym raporcie.
Skalowanie wartości w dół
- 2 558 500 odnosi się do liczby zakupów związanych z tym kluczem, przeskalowanych w górę o wcześniej obliczony współczynnik skalowania. Współczynnik skalowania liczby zakupów wyniósł 32 768. Podziel 2 558 500 przez budżet na wpłatę celu: 2 558 500/32 768 = 156,15 zakupów.
- 687 060 → 687 060/22 = łączna wartość zakupu na kwotę 31 230 USD.
W rezultacie raporty podsumowujące zawierają te statystyki:
Within the reporting time period, campaign #12
run in Europe drove about 156 purchases (± noise)
for the product category #25.
Within the reporting time period, campaign #12
run in Europe drove $31,230 of purchases (± noise)
for the product category #25.