brak danych transakcyjnych do raportów kampanii

Brak danych transakcyjnych do raportów kampanii to usterka uniemożliwiająca ocenę wpływu wysyłki na rzeczywiste przychody.

Na czym polega brak danych transakcyjnych w raporcie kampanii

Brak danych transakcyjnych do raportów kampanii oznacza, że system raportowy otrzymuje informacje o wysyłce, odbiorcach, otwarciach lub kliknięciach, ale nie dostaje poprawnych danych o późniejszych zakupach, płatnościach albo wartości zamówień. W efekcie można zmierzyć aktywność odbiorców, lecz nie da się wiarygodnie ustalić, czy konkretna kampania doprowadziła do transakcji. Problem może dotyczyć całego raportu, wybranego kanału, określonego zakresu dat albo tylko części zamówień.

Do połączenia kampanii z transakcją zwykle potrzebny jest identyfikator przypisany do wejścia użytkownika lub zdarzenia, na przykład parametr kampanii w adresie URL, identyfikator kliknięcia, identyfikator odbiorcy albo identyfikator sesji. System sprzedażowy musi następnie zapisać transakcję z kwotą, walutą, czasem wykonania i identyfikatorem pozwalającym na przypisanie jej do źródła. Jeżeli którykolwiek z tych elementów zostanie utracony, raport może pokazywać zerowy przychód mimo prawidłowo zrealizowanych zamówień.

Gdzie może zostać przerwany przepływ danych

Przepływ danych transakcyjnych składa się zazwyczaj z kilku etapów: kliknięcie w wiadomości lub reklamie, przejście na stronę, zapis identyfikatora kampanii, utworzenie koszyka, złożenie zamówienia, potwierdzenie płatności, przekazanie zdarzenia do systemu analitycznego oraz agregacja danych w raporcie. Usterka może wystąpić na każdym z tych etapów. Przykładowo parametr kampanii może być usuwany podczas przekierowania, ciasteczko może nie zostać zapisane, a zdarzenie zakupu może być wysyłane przed otrzymaniem potwierdzenia płatności.

Ważne jest rozróżnienie między brakiem transakcji a brakiem jej przypisania. W pierwszym przypadku system sprzedażowy nie ma zamówienia lub płatności. W drugim zamówienie istnieje, ale nie zawiera informacji o źródle pozyskania. Raport może również odrzucać prawidłowe rekordy z powodu niezgodnego formatu daty, pustej wartości waluty, ujemnej kwoty zwrotu, powtórzonego identyfikatora albo różnicy między czasem lokalnym a czasem zapisanym w systemie raportowym. Przydatne jest porównanie liczby zamówień w systemie sprzedażowym z liczbą zdarzeń zakupu odebranych przez narzędzie analityczne.

Diagnostyka powinna objąć także dzienniki aplikacji, historię zadań synchronizacyjnych, odpowiedzi interfejsu API oraz statusy kolejek zdarzeń. Błąd HTTP 4xx może wskazywać na nieprawidłowe dane żądania lub brak uprawnień, a błąd 5xx na problem po stronie usługi odbierającej. Sam fakt, że eksport zakończył się komunikatem o poprawnym wykonaniu, nie potwierdza kompletności danych. Trzeba sprawdzić liczbę przetworzonych rekordów, liczbę odrzuceń, zakres czasu oraz to, czy rekordy zostały oznaczone jako dostarczone.

Kontrola identyfikatorów, kwot i zakresu czasu

Podstawowym testem jest prześledzenie pojedynczej transakcji od zamówienia do raportu. Należy porównać identyfikator zamówienia, identyfikator kampanii, czas utworzenia koszyka, czas opłacenia, kwotę brutto lub netto oraz walutę. Jeżeli raport korzysta z czasu kliknięcia, a system sprzedażowy z czasu płatności, transakcja może trafić poza analizowany zakres dat. Podobny efekt powstaje po zmianie strefy czasowej, zaokrągleniu znacznika czasu albo zastosowaniu filtra obejmującego wyłącznie zamówienia o określonym statusie.

Trzeba również sprawdzić, czy dane nie są filtrowane przez reguły deduplikacji. Dwa zdarzenia z tym samym identyfikatorem transakcji mogą zostać potraktowane jako powtórzenie, choć jedno dotyczy utworzenia zamówienia, a drugie potwierdzenia płatności. Odwrotny problem występuje wtedy, gdy ponowienie wysyłki tworzy wiele rekordów tego samego zakupu i zawyża przychód. W przypadku zwrotów oraz anulowań raport powinien jasno określać, czy prezentuje wartość zamówienia, wartość opłaconej transakcji czy przychód po korektach.

Naprawa przepływu polega na przywróceniu brakującego etapu, poprawieniu mapowania pól albo ponownym przetworzeniu rekordów, które nie zostały dostarczone. Przed ponowną synchronizacją należy zabezpieczyć identyfikatory transakcji i ustalić, czy odbiorca obsługuje bezpieczne ponowienie tego samego zdarzenia. Po korekcie raport powinien zostać porównany z systemem źródłowym na tym samym przedziale czasu, z uwzględnieniem zamówień anulowanych, zwróconych i oczekujących na płatność.

Diagnostyka komputera używanego do eksportu i raportowania

Jeżeli problem pojawia się tylko na jednym stanowisku, należy sprawdzić komputer, na którym działa przeglądarka, aplikacja raportowa, lokalny moduł eksportu lub harmonogram synchronizacji. Znaczenie mogą mieć uszkodzony profil przeglądarki, rozszerzenie blokujące skrypty, nieaktualny certyfikat, błędny zegar systemowy, brak miejsca na dysku albo program zabezpieczający przerywający połączenie. Warto wykonać test w nowym profilu, sprawdzić konsolę przeglądarki i porównać wynik eksportu z innym stanowiskiem.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC oraz ich podzespołów, w tym diagnostykę problemów ze stabilnością systemu, przeglądarką i lokalnym oprogramowaniem używanym do pracy. Przy zgłoszeniu dotyczącym raportów należy udostępnić opis brakujących danych, przykładowy przedział czasu, komunikaty błędów oraz informację, czy zamówienia są widoczne w systemie źródłowym. Takie rozdzielenie problemu aplikacyjnego od problemu samego komputera ułatwia ustalenie, czy przyczyny trzeba szukać w stanowisku użytkownika, konfiguracji integracji czy danych wejściowych.