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 agregacji.
Zbieranie raportów
Podczas zbierania raportów do uwzględnienia w przesyłaniu zbiorczym pamiętaj o tych kwestiach:
Ponowne próby przesłania raportu
Uwaga: kryteria ponownego próbowania mogą ulec zmianie. 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 zostanie on wysłany. Pierwotna wartość
scheduled_report_time jest zachowywana niezależnie od tego, kiedy raport może zostać wysłany. Harmonogram ponownych prób różni się w zależności od platformy:
- Przeglądarka będzie wysyłać raporty, gdy będzie w trybie 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, kolejna ponowna próba nastąpi po minucie od powrotu do trybu online. Wysyłanie raportów w internecie nie występuje w maksymalnym czasie. Oznacza to, że jeśli przeglądarka przejdzie w tryb offline, niezależnie od tego, kiedy raport został wygenerowany, po ponownym przejściu w tryb online będzie próbował wysłać raport zgodnie z zasadami 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ą. Na przykład, gdy zbierane są raporty z opóźnieniem, sprawdź pole scheduled_report_time i zauważ, że opóźnienie czasowe wynosi odpowiednio 90%, 95% i 99% godzin, w których przypadku raporty są odbierane. 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 scheduled_report_time, a wartość T+X to czas oczekiwania na opóźnione raporty. W efekcie powstanie raport podsumowujący, który zawiera większość raportów uwzględnionych w grupie, który odpowiada zaplanowanemu czasowi raportowania.
Uwzględnianie w raportach agregowanych
Usługa 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 grupować w taki sposób, by wszystkie raporty z tym samym udostępnionym identyfikatorem były częścią jednej grupy.
Jeśli raport został już przetworzony w ramach innej partii, jego przetworzenie może spowodować wyświetlenie błędu związanego z wyczerpaniem budżetu na prywatność. 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 umożliwia śledzenie danych księgowych raportu podlegającego agregacji. Współużywany identyfikator zapewnia, że raporty z tym samym współdzielonym identyfikatorem będą się składać tylko do jednego raportu zbiorczego. Oznacza to, że raporty, które są mapowane na jeden wspólny identyfikator, 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ć, jak 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 identyfikatorów współdzielonych. W przyszłości może zostać zaktualizowana szczegółowość danych dotyczących czasu.
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 grupie jest więcej niż 1 raport z tym samym parametrem report_id, tylko pierwszy raport zostanie zagregowany, a pozostałe będą uznawane za duplikaty i pozbawione je dyskretnie. Agregacja będzie przebiegać jak zwykle, a żadne błędy nie będą wysyłane.
Chociaż nie jest to wymagane, dostawcy technologii reklamowych mogą spodziewać się wzrostu skuteczności, jeśli przed zsumowaniem wykluczą duplikaty raportów z tymi samymi identyfikatorami.
report_id jest unikalny dla każdego raportu.
Zduplikowane raporty w różnych partiach
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 pakiet 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 sposób.
Na poniższym obrazku 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ć zbiorcze raportowanie.
Grupowanie według reklamodawcy
Uwaga: ta strategia jest zalecana tylko do agregacji raportowania atrybucji.
Prywatna agregacja nie zawiera pola attribution_destination, które jest polem reklamodawcy. Zalecamy grupowanie według reklamodawcy, co pozwoli uwzględniać raporty należące do 1 reklamodawcy do tej samej partii. Pozwoli to uniknąć osiągnięcia limitu kont zbiorczych na koncie w przypadku każdej grupy. Reklamodawca to pole brane pod uwagę przy generowaniu udostępnionego identyfikatora, więc raporty z tym samym reklamodawcą mogą też mieć ten sam udostępniony identyfikator. Aby uniknąć błędów, raporty te muszą być w tym samym zbiorze.
Sortowanie według czasu
Przy grupowaniu zalecamy uwzględnienie czasu zaplanowanego 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 raportowania w ramach tej samej godziny powinny znajdować się w tym samym zbiorze, aby uniknąć raportów z tym samym wspólnym identyfikatorem w różnych zbiorach, co może powodować 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 agregujące są częściej grupowane (np. raporty te są przetwarzane po wprowadzeniu liczby zdarzeń konwersji o mniejszej liczbie godzin), to szum będzie miał większy względny 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.