Zduplikowane konwersje Adgora: jak je diagnozować

Zduplikowane konwersje w kampanii Adgora po wysłaniu postbacka: porównanie sposobów diagnozowania

Konwersja może pojawić się dwukrotnie, nawet jeśli użytkownik wykonał daną czynność tylko raz. Dodatkowy wpis może być skutkiem ponownego wysłania postbacka, przyjęcia tego samego zdarzenia więcej niż raz przez punkt końcowy albo zliczenia jednego zdarzenia w dwóch miejscach w raportach. Jeśli zastanawiasz się, jak diagnozować zduplikowane konwersje w Adgora, prześledź cały przepływ i ustal, gdzie po raz pierwszy pojawia się drugi wpis, zanim zmienisz ustawienia kampanii.

W tym porównaniu omawiamy trzy sposoby zapobiegania duplikatom: deduplikację według identyfikatora zdarzenia, weryfikację identyfikatora transakcji i reguły oparte na przedziale czasu. Wybór zależy od tego, jakimi identyfikatorami dysponuje integracja oraz czy klienci mogą dokonać kolejnych prawidłowych konwersji. Zbyt szeroka reguła może usunąć rzeczywiste zakupy lub rejestracje.

Przed porównaniem rozwiązań ustal kryteria

Oceń każde rozwiązanie według trzech kryteriów: czy blokuje powtórzone zdarzenie, czy zachowuje prawidłowe kolejne konwersje i czy można je przetestować bez zakłócania działania aktywnych kampanii. Zapisz te kryteria przed wprowadzeniem zmian w przepływie postbacków. W przeciwnym razie mniejsza liczba konwersji może wyglądać na sukces, nawet jeśli reguła zablokowała prawidłową aktywność.

Określ, co uznajesz za duplikat w przypadku mierzonej czynności. Przy jednorazowym zakupie dwukrotnie zapisane zamówienie najpewniej jest duplikatem. W przypadku odnowienia subskrypcji dwa zakupy tego samego klienta dokonane w różnym czasie mogą być prawidłowe. Definicję dopasuj do konkretnego zdarzenia, a nie tylko do kampanii.

Zachowaj dane potrzebne do porównania wyników: zdarzenie źródłowe, identyfikator zdarzenia lub transakcji, próby wysłania postbacka, odpowiedzi punktu końcowego i raport konwersji Adgora. Jeśli któregoś pola brakuje, odnotuj ten brak zamiast zakładać, że oba wpisy dotyczą tej samej czynności. Krótki dziennik testów jest bardziej przydatny niż ogólne stwierdzenie, że konwersji „wydaje się za dużo”.

Prześledź jedną konwersję w całym przepływie postbacka

Wybierz jedną zaraportowaną konwersję i prześledź jej drogę od pierwotnej czynności do widoku raportu. Zacznij od zdarzenia źródłowego, na przykład potwierdzenia zamówienia, wysłania formularza lub działania w aplikacji. Zapisz jego znacznik czasu i wszelkie przypisane do niego identyfikatory. Następnie znajdź odpowiadający mu wychodzący postback oraz wpis w odbierającym go punkcie końcowym.

Porównaj identyfikatory i znaczniki czasu na każdym etapie. Jeśli źródło zawiera jedno zdarzenie, a punkt końcowy dwa pasujące wpisy, drugi wpis powstał gdzieś między dostarczeniem postbacka a zapisaniem go w punkcie końcowym. Jeśli punkt końcowy ma jeden wpis, a Adgora pokazuje dwie konwersje, zbadaj ścieżkę raportowania lub importu, zamiast zmieniać mechanizm deduplikacji punktu końcowego.

Ustal, w którym miejscu pojawiają się rozbieżności. Na przykład zdarzenie z przeglądarki i zdarzenie po stronie serwera mogą raportować ten sam zakup albo ponowiona próba może trafić do punktu końcowego, który zapisuje każde żądanie jako nowe. To dwa różne rodzaje problemu, wymagające odmiennych rozwiązań. Jeśli obie ścieżki przekazują ten sam identyfikator zdarzenia, łatwiej będzie je uzgodnić; jeśli nie, być może trzeba dodać taki identyfikator u źródła.

Zapisz kolejne etapy przepływu: zdarzenie źródłowe, wygenerowanie postbacka, próba dostarczenia, odpowiedź punktu końcowego, zapisany wpis i raport Adgora. Dzięki temu zespół będzie miał konkretną sekwencję do przetestowania. Pozwoli to też uniknąć częstej pułapki: obwiniania kampanii, zanim sprawdzisz, czy punkt końcowy nie utworzył już dwóch wpisów.

Porównaj metody deduplikacji

Deduplikacja konwersji po identyfikatorze zdarzenia jest zwykle najprostszym rozwiązaniem, gdy ta sama konwersja może mieć jeden niezmienny, unikatowy identyfikator przekazywany ze źródła do odbiorcy. Punkt końcowy zapisuje pierwsze zdarzenie, a późniejsze żądanie z tym samym identyfikatorem uznaje za już przetworzone. Sprawdź, czy identyfikator nie zmienia się przy ponownych próbach ani między ścieżkami przeglądarkową i serwerową, które mogą raportować tę samą czynność.

Weryfikacja identyfikatora transakcji sprawdza się przy zakupach, gdy każde zamówienie ma stały numer referencyjny. Gorzej pasuje do formularza kontaktowego, rozpoczęcia okresu próbnego czy innego zdarzenia, które nie generuje identyfikatora transakcji. Sprawdź też zakres jego unikatowości: numer transakcji może być niepowtarzalny tylko w obrębie danego konta lub sklepu, więc klucz deduplikacji może wymagać również tego kontekstu.

Reguły oparte na przedziale czasu są rozwiązaniem zastępczym, gdy integracja nie zapewnia stałego identyfikatora zdarzenia ani transakcji. Mogą traktować podobne konwersje zarejestrowane w krótkim odstępie jako jedną, ale „blisko siebie w czasie” nie znaczy „to samo zdarzenie”. Klient może wykonać dwie prawidłowe czynności w wybranym przedziale. Wybierz najkrótszy przedział odpowiadający zaobserwowanemu wzorcowi duplikatów, a następnie przetestuj ponowne, prawidłowe konwersje, zanim zastosujesz regułę na większą skalę.

Ta sama staranność przydaje się zespołom analizującym szerzej pomiar kampanii, w tym źródła ruchu i definicje konwersji. targetowanie w sieci reklamowej crypto może pomóc w doborze targetowania, ale jego zmiana nie naprawi duplikatu utworzonego po dotarciu postbacka do punktu końcowego.

Sprawdź zachowanie przy ponawianiu prób i odpowiedziach

Przekroczenie limitu czasu nie dowodzi, że postback nie został dostarczony. Punkt końcowy mógł zapisać zdarzenie, ale nie odesłać jednoznacznego potwierdzenia, przez co nadawca ponowił próbę. Sprawdź, jak nadawca obsługuje przekroczenia limitu czasu, które kody odpowiedzi uruchamiają ponowienia oraz czy punkt końcowy odpowiada dopiero po zapisaniu zdarzenia.

Zanim przypiszesz duplikaty ponawianiu prób, sprawdź rzeczywiste dzienniki żądań i odpowiedzi. Zwróć uwagę na liczbę prób, znaczniki czasu, kody odpowiedzi oraz to, czy każda próba zawierała ten sam identyfikator zdarzenia. Następnie potwierdź udokumentowane zachowanie punktu końcowego w używanym przez Ciebie środowisku.

Warto tu rozróżnić dwie sytuacje. Jeśli każde ponowione żądanie ma ten sam identyfikator, a punkt końcowy zapisuje je wszystkie, odbiorca może wymagać obsługi idempotentnej. Jeśli ponowione żądania mają różne identyfikatory, choć pochodzą z jednego zdarzenia źródłowego, sprawdź, gdzie są generowane. Sama polityka ponawiania prób nie wyjaśnia tej rozbieżności.

Przetestuj rozwiązania na duplikatach i kolejnych zdarzeniach

Przed wdrożeniem reguły przeprowadź dwa kontrolowane testy. Najpierw wyślij dwukrotnie postback tej samej konwersji z tym samym identyfikatorem. Oczekiwany wynik to jeden zapisany wpis. Następnie wygeneruj dwie prawidłowe konwersje z różnymi identyfikatorami, na przykład dwa oddzielne zamówienia, i sprawdź, czy obie są widoczne.

W obu przypadkach porównaj dziennik źródłowy, dziennik dostarczenia, wpisy punktu końcowego i raport Adgora. Rozwiązanie działa tylko wtedy, gdy usuwa powtórzone zdarzenie, nie usuwając prawidłowej drugiej konwersji. Jeśli stosujesz regułę opartą na przedziale czasu, przetestuj ponowną konwersję w proponowanym przedziale. Test poza nim nie pokaże, czy reguła jest zbyt szeroka.

Jeśli to możliwe, przeprowadź test poza aktywną optymalizacją kampanii. Użyj kampanii testowej, środowiska testowego punktu końcowego albo wyraźnie oznaczonego zdarzenia testowego, aby wynik nie wpłynął na decyzje dotyczące kampanii. Jeśli test w środowisku produkcyjnym jest nieunikniony, przed jego przeprowadzeniem uzgodnij zdarzenie testowe i okres obserwacji z osobami odpowiedzialnymi za raportowanie.

Jeśli kampanie śledzą również działania w aplikacji, upewnij się, że test odzwierciedla sposób wysyłania tych zdarzeń. Osobny przegląd reklamy kryptowalutowej na potrzeby kampanii promujących instalacje aplikacji może dostarczyć kontekstu kampanii, ale kontrola duplikatów nadal musi obejmować konkretną instalację lub zdarzenie w aplikacji i jego własny przepływ postbacka.

Wdrażaj stopniowo i przygotuj plan wycofania zmian

Zacznij od ograniczonego wdrożenia: jednego typu zdarzenia, jednego punktu końcowego lub jednej kampanii testowej. Przed zmianą reguły zapisz bieżącą konfigurację i wartości bazowe dla liczby zdarzeń źródłowych, dostarczonych postbacków, wpisów w punkcie końcowym i zaraportowanych konwersji. Bez tych danych późniejszy spadek trudno będzie zinterpretować.

Monitoruj obie strony problemu. Mniejsza liczba duplikatów jest dobrym wynikiem tylko wtedy, gdy prawidłowe konwersje pozostają nienaruszone. Zwracaj uwagę na brakujące wpisy, nieoczekiwany spadek liczby ponownych zakupów, wzrost liczby błędów dostarczenia lub rozbieżność między danymi punktu końcowego a raportami Adgora. Jeśli pojawi się którykolwiek z tych sygnałów, wstrzymaj zmianę i porównaj identyfikatory zdarzeń lub numery transakcji.

Przed wdrożeniem określ jasny warunek wycofania zmian. Na przykład cofnij je, jeśli znana konwersja testowa zostanie pominięta lub znikną prawidłowe kolejne zdarzenia z dziennika punktu końcowego. Zachowaj poprzednią regułę, dopóki nowa nie zostanie sprawdzona na rzeczywistych danych kampanii.

Zapisz, co i kiedy zmieniono oraz których typów zdarzeń dotyczy zmiana. Taka dokumentacja ułatwia odróżnienie poprawki postbacka od niezwiązanych zmian w kampanii. Pozwala też kolejnej osobie szybko przywrócić wcześniejsze działanie, jeśli liczba konwersji nieoczekiwanie się zmieni.

Wniosek: gdy to możliwe, wybieraj identyfikację na poziomie zdarzenia

Jeśli integracja na to pozwala, używaj stałego, unikatowego identyfikatora zdarzenia, który może przejść od zdarzenia źródłowego do odbierającego je punktu końcowego. Dzięki temu odbiorca może bezpośrednio rozpoznać ponowione żądanie, zamiast uznawać za duplikat każdą konwersję zarejestrowaną w krótkim odstępie czasu.

Jeśli nie ma odpowiedniego identyfikatora zdarzenia, w przypadku zakupów użyj identyfikatora transakcji, o ile numer zamówienia jest wiarygodny. Dla innych zdarzeń reguła oparta na przedziale czasu może być najwęższym dostępnym rozwiązaniem zastępczym, ale przed wdrożeniem sprawdź ją pod kątem prawidłowych kolejnych konwersji. Aby ustalić, jak zapobiec duplikowaniu postbacków, wybierz rozwiązanie, które usuwa powtórzony wpis, zachowując drugą rzeczywistą czynność — a nie po prostu obniża łączną liczbę konwersji w kampanii Adgora.