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:
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 wersji internetowej, jak i wersji na system operacyjny platforma spróbuje wysłać raport 3 razy, ale jeśli nie uda się to po 3 próbach, raport nie zostanie wysł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 wróci ona do trybu online. Nie ma maksymalnego opóźnienia przesyłania raportów w sieci. Oznacza to, że jeśli przeglądarka przejdzie w tryb offline, to niezależnie od tego, jak dawno raport został wygenerowany, po powrocie do trybu online spróbuje go wysłać 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ć zgłoszenia, zostanie ono ponownie wysłane 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ć, porównując wartość scheduled_report_time z czasem otrzymania raportu. Różnica czasowa między tymi raportami pomoże Ci określić, jak długo chcesz czekać na raporty, które docierają z opóźnieniem. 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 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 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ć 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 generowany dla każdego raportu w celu śledzenia danych księgowych raportu podlegającego agregacji. Współużywany identyfikator zapewnia, że raporty z tym samym współdzielonym identyfikatorem wchodzą w skład tylko 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ć zmieniona szczegółowość danych dotyczących czasu.
Zduplikowane raporty w zbiorach
Pole shared_info w raporcie możliwym do zsumowania 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 parametrem report_id, zostanie zsumowany tylko pierwszy raport, a pozostałe zostaną potraktowane jako 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ę wzrostu skuteczności dzięki odfiltrowywaniu duplikatów raportów o tych samych identyfikatorach przed ich zsumowaniem.
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ą być wysyłane w ramach tego samego zbiorczego zgłoszenia. 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 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.
Prywatna agregacja nie zawiera pola attribution_destination, które jest polem reklamodawcy. 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ą też mieć ten sam udostępniony identyfikator. Aby uniknąć błędów, raporty te muszą 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 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 zbiorcze 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. Aby lepiej zrozumieć wpływ szumu na partie, przeprowadź eksperyment w Noise Lab.