Podczas grupowania raportów możliwych do agregacji ważne jest zoptymalizowanie strategii grupowania, aby nie przekraczać limitów prywatności. Poniżej znajdziesz kilka zalecanych strategii wysyłania partii raportów do usługi do agregacji.
Zbieranie raportów
Podczas zbierania raportów do uwzględnienia w przesyłaniu zbiorczym pamiętaj o tych kwestiach:
Zgłaszanie prób przesyłania
Uwaga: kryteria ponownego próbowania mogą ulec zmianie. W takim przypadku informacje w tej sekcji zostaną zaktualizowane.
Zarówno w przypadku przeglądarki, jak i systemu operacyjnego platforma będzie próbować wysłać raport 3 razy, ale jeśli po 3 próbach nie uda się go wysłać, nie będzie on wysyłany. Pierwotna wartość
scheduled_report_time jest zachowywana niezależnie od tego, kiedy raport może zostać wysłany. Oś czasu ponownych prób różni się w zależności od platformy:
- Przeglądarka internetowa będzie wysyłać raporty, gdy będzie online. Jeśli raport nie zostanie wysłany, poczeka 5 minut na drugą próbę, a potem 15 minut na trzecią. Jeśli przeglądarka przejdzie w tryb offline, następna próba zostanie podjęta po minucie od chwili, gdy powróci ona do trybu online. Nie ma maksymalnego opóźnienia w przesyłaniu raportów w internecie. Oznacza to, że jeśli przeglądarka przejdzie w tryb offline, to niezależnie od tego, jak dawno raport został wygenerowany, gdy przeglądarka wróci do trybu online, spróbuje wysłać raport zgodnie z zasadami dotyczącymi ponownych prób.
- Telefon z Androidem ma stabilne połączenie z internetem. W związku z tym zadanie wysyłania raportów będzie wykonywane raz na godzinę. Oznacza to, że jeśli nie uda się wysłać raportu, zostanie on ponownie wysłany następnej godziny, a potem jeszcze raz po upływie kolejnej godziny. Jeśli urządzenie nie ma połączenia, spróbuje ponownie wysłać raport w ramach następnego zadania raportowania, które zostanie uruchomione po ponownym połączeniu urządzenia z siecią. Maksymalne opóźnienie wynosi 28 dni, co oznacza, że urządzenie nie wyśle raportu wygenerowanego ponad 28 dni temu.
Czekaj na raporty
Podczas zbierania raportów do zbiorczego przetwarzania zalecamy poczekać na spóźnione raporty. Opóźnione raporty można zidentyfikować, sprawdzając wartość scheduled_report_time w powiązaniu z czasem otrzymania raportu. Różnica czasowa między tymi raportami pomoże Ci określić, jak długo warto czekać na raporty, które się spóźniają. Podczas zbierania opóźnionych raportów sprawdź pole scheduled_report_time i zauważ, że opóźnienie w godzinach wynosi 90%, 95% i 99% otrzymanych raportów. Na podstawie tych danych można określić, jak długo należy czekać na raporty, które docierają z opóźnieniem.
Raporty zbiorcze z Szybkiej rezerwacji mogą zmniejszyć ryzyko opóźnienia raportów.
Na poniższej ilustracji widać, jak raporty opóźnione są przechowywane w odpowiednich partiach zgodnie z planowanym czasem raportowania. Wartość T w przypadku zbiorczego raportu odpowiada wartości scheduled_report_time, a wartość T + X odpowiada czasowi oczekiwania na opóźnione raporty. W efekcie raport podsumowania zawiera większość raportów uwzględnionych w partii, które odpowiadają zaplanowanemu terminowi raportowania.
Uwzględnianie danych w raportach zbiorczych
Usługa do agregacji przestrzega reguły „bez duplikatów”. Ta reguła nakazuje, aby wszystkie raporty podlegające agregacji o tym samym wspólnym identyfikatorze były uwzględniane w tym samym zbiorze.
Po zebraniu raportów należy je utworzyć w takiej postaci, aby wszystkie raporty z tym samym wspólnym identyfikatorem tworzyły jeden pakiet.
Jeśli raport został już przetworzony w ramach innej partii, przetwarzanie może spowodować błąd związany z wyczerpaniem budżetu na potrzeby prywatności. Prawidłowe tworzenie raportów zbiorczych pomaga zapobiegać odrzuceniu zbiorów z powodu reguły „brak duplikatów”.
Udostępniony identyfikator to klucz wygenerowany dla każdego raportu, który służy do śledzenia danych księgowych raportu podlegającego agregacji. Udostępniony identyfikator zapewnia, że raporty z tym samym udostępnionym identyfikatorem przyczyniają się tylko do jednego raportu zbiorczego. Oznacza to, że raporty, które odnoszą się do jednego wspólnego identyfikatora, muszą być zawarte w jednym zbiorze. Jeśli na przykład raport X i raport Y mają ten sam wspólny identyfikator, muszą być uwzględnione w tym samym zbiorze, aby uniknąć odrzucenia raportów z powodu duplikacji.
Na poniższym obrazie widać komponenty shared_info, które są zaszyfrowane, aby wygenerować wspólny identyfikator.
Na ilustracji widać, że 2 różne raporty mogą mieć ten sam wspólny identyfikator:
Uwaga: wartość scheduled_report_time jest zaokrąglana do godziny, a wartość source_registration_time – do dnia. Ponadto report_id nie jest używany do tworzenia wspólnego identyfikatora. W przyszłości może zostać zaktualizowana szczegółowość danych.
zduplikowane raporty w zbiorach,
Pole shared_info w raporcie możliwym do zgrupowania zawiera w polu report_id identyfikator UUID, który służy do identyfikowania duplikatów raportów w zbiorze. Jeśli w partii znajduje się więcej niż 1 raport z tym samym identyfikatorem report_id, zostanie zsumowany tylko pierwszy raport, a pozostałe zostaną uznane za duplikaty i po cichu odrzucone. Zbiorczość będzie przebiegać normalnie i nie zostaną wysłane żadne błędy.
Chociaż nie jest to wymagane, usługi adtech mogą spodziewać się pewnych wzrostów skuteczności dzięki odfiltrowywaniu duplikatów raportów o tych samych identyfikatorach przed złączeniem.
report_id jest unikalny dla każdego raportu.
Zduplikowane raporty w ramach partii
Każdemu raportowi przypisany jest wspólny identyfikator, który jest generowany na podstawie połączonych punktów danych pochodzących z pola shared_info raportu. Wiele raportów może mieć ten sam wspólny identyfikator, a każdy z nich może zawierać wiele wspólnych identyfikatorów. Wszystkie raporty z tym samym wspólnym identyfikatorem muszą znajdować się w tym samym zbiorze. Jeśli raporty z tym samym wspólnym identyfikatorem znajdą się w kilku partiach, zostanie zaakceptowana tylko pierwsza partia, a pozostałe zostaną odrzucone jako duplikaty. Aby temu zapobiec, partie muszą być tworzone w odpowiednim czasie.
Na ilustracji poniżej widać przykład, w którym raporty z tym samym identyfikatorem w różnych partiach mogą spowodować niepowodzenie późniejszej partii. Na obrazku widać, że co najmniej 2 raporty z tym samym identyfikatorem współdzielonyme679aa są grupowane w różne partie – 1 i 2. Ponieważ budżet na wszystkie raporty z wspólnym identyfikatorem
e679aa jest wykorzystywany podczas generowania raportu zbiorczego w partii 1, partia 2 nie jest dozwolona i nie udaje się jej utworzyć.
Raporty zbiorcze
Poniżej znajdziesz zalecane sposoby zbiorczego tworzenia raportów, które pozwolą uniknąć duplikatów i zoptymalizować księgowanie danych w raportach zbiorczych.
Grupowanie według reklamodawcy
Uwaga: ta strategia jest zalecana tylko do agregacji raportów o przypisaniu.
W przypadku prywatnej agregacji nie ma pola attribution_destination, które odpowiada za reklamodawcę. Zalecamy grupowanie według reklamodawcy, czyli uwzględnianie w jednym zbiorze raportów należących do jednego reklamodawcy, aby uniknąć osiągnięcia limitu raportów możliwych do zsumowania w przypadku każdego zbioru. Reklamodawca to pole brane pod uwagę przy generowaniu udostępnionego identyfikatora, więc raporty z tym samym reklamodawcą mogą mieć ten sam udostępniony identyfikator. Aby uniknąć błędów, muszą one być w tym samym zbiorze.
Sortowanie według czasu
Podczas grupowania zalecamy uwzględnienie zaplanowanego czasu wysyłki raportu (shared_info.scheduled_report_time). Czas zaplanowanego raportu jest przycinany do godziny w ramach generowania wspólnego identyfikatora, dlatego raporty powinny być grupowane co godzinę. Oznacza to, że wszystkie raporty z zaplanowanym czasem raportu w tej samej godzinie powinny trafić do tego samego zbioru, aby uniknąć raportów z tym samym wspólnym identyfikatorem w różnych zbiorach, co może spowodować błędy w zbiorze.
Częstotliwość i szum w grupie
Zalecamy uwzględnienie wpływu szumu na częstotliwość przetwarzania raportów podlegających agregacji. Jeśli raporty podlegające agregacji są grupowane częściej (np. przetwarzane co godzinę), uwzględniane jest mniej zdarzeń konwersji, a błąd będzie miał większy wpływ. Jeśli częstotliwość zostanie zmniejszona, a raporty będą przetwarzane raz w tygodniu, szum będzie miał mniejszy wpływ na wyniki. Aby lepiej zrozumieć wpływ szumu na partie, przeprowadź eksperyment w Noise Lab.