reakcje wg źródła zapisu (formularz

Reakcje według źródła zapisu pokazują, czy odbiorcy z formularza reagują inaczej niż zapisani innym kanałem.

Źródło zapisu jako wymiar danych formularza

„Reakcje wg źródła zapisu (formularz)” oznaczają porównanie zachowań osób, które wysłały formularz, z podziałem na kanał lub miejsce, z którego trafiły do formularza. Źródłem może być na przykład wynik wyszukiwania, reklama, odsyłacz z innej strony, wiadomość e-mail albo wejście bezpośrednie. Samo źródło nie opisuje jeszcze jakości kontaktu. Jest jedynie atrybutem przypisanym do zdarzenia zapisu, dlatego powinno być przechowywane razem z identyfikatorem formularza, datą, adresem strony i wynikiem walidacji.

Technicznie system może zapisywać źródło na podstawie parametrów adresu URL, takich jak utm_source, utm_medium i utm_campaign, danych przekazanych przez system reklamowy albo informacji o stronie odsyłającej dostępnej w nagłówku HTTP Referer. Parametry UTM są wartościami tekstowymi i nie mają jednej obowiązkowej listy dozwolonych nazw, dlatego spójność zależy od przyjętej konwencji. Wartości „google”, „Google” i „google-search” mogą zostać potraktowane jako trzy różne źródła, jeżeli aplikacja nie normalizuje zapisu.

Rejestrowanie reakcji przed i po wysłaniu formularza

Porównanie reakcji wymaga rozdzielenia co najmniej kilku zdarzeń. Otwarcie strony z formularzem nie jest równoznaczne z rozpoczęciem jego wypełniania, rozpoczęcie wypełniania nie oznacza poprawnego przesłania, a przesłanie formularza nie musi oznaczać przyjęcia danych przez serwer. Aplikacja powinna więc rozróżniać zdarzenia takie jak wyświetlenie formularza, fokus na pierwszym polu, rozpoczęcie wpisywania, błąd walidacji, kliknięcie przycisku wysyłki, odpowiedź HTTP oraz potwierdzenie zapisu po stronie serwera.

W praktyce formularz może być wysyłany metodą HTTP POST, przez żądanie AJAX albo za pośrednictwem interfejsu Fetch API. O wyniku nie powinien decydować sam fakt kliknięcia przycisku. Za udany zapis należy uznać dopiero sytuację, w której serwer zwróci oczekiwany status i aplikacja potwierdzi utworzenie rekordu. Odpowiedź 200 OK lub 201 Created może wskazywać poprawne wykonanie żądania, natomiast kod 400 zwykle sygnalizuje nieprawidłowe dane, a kody z zakresu 500 błąd po stronie serwera. Konkretne znaczenie zależy od implementacji API.

Jeżeli system rejestruje tylko zakończone formularze, nie pozwala odróżnić źródła generującego dużo rozpoczętych, lecz porzucanych formularzy od źródła z mniejszym ruchem i większym odsetkiem poprawnych zapisów. Przydatne są zatem wskaźniki liczone osobno dla każdego źródła: liczba wyświetleń, liczba rozpoczęć, liczba wysyłek, liczba odrzuceń walidacyjnych, liczba błędów technicznych oraz liczba zapisów zaakceptowanych przez backend. Współczynnik ukończenia można wyliczyć jako liczbę poprawnych zapisów podzieloną przez liczbę rozpoczętych formularzy, pod warunkiem że oba zdarzenia są rejestrowane według tej samej definicji.

Spójność atrybucji i interpretacja wyników

Najczęstszy problem z analizą źródła polega na utracie informacji między wejściem na stronę a wysłaniem formularza. Użytkownik może przejść przez kilka podstron, odświeżyć widok, otworzyć formularz w nowej karcie albo wrócić po kilku dniach. Dlatego źródło powinno być przechowywane w kontrolowanym zakresie, na przykład w sesji przeglądarki, ukrytym polu formularza lub rekordzie powiązanym z identyfikatorem wizyty. Należy przy tym ustalić, czy raport używa pierwszego źródła kontaktu, ostatniego źródła przed zapisem, czy źródła przypisanego bezpośrednio do bieżącej sesji.

Brak wartości źródła nie oznacza automatycznie, że użytkownik przyszedł z ruchu bezpośredniego. Przyczyną może być usunięcie parametrów przez przekierowanie, blokada skryptu pomiarowego, przejście z aplikacji mobilnej, polityka prywatności przeglądarki albo brak przekazania pola w żądaniu formularza. W raporcie warto więc rozróżniać wartości „direct”, „unknown”, „missing” i „not set”, jeżeli system potrafi ustalić przyczynę braku danych. Takie rozróżnienie ogranicza ryzyko przypisywania wszystkich nieznanych zapisów do jednego kanału.

Wyników nie należy porównywać wyłącznie na podstawie liczby reakcji. Źródło z największą liczbą formularzy może mieć niski odsetek poprawnych zapisów, natomiast kanał z małą liczbą kontaktów może generować mniej błędów i większy udział kompletnych zgłoszeń. Należy także sprawdzić liczebność próby, zakres dat, powtarzające się identyfikatory, duplikaty oraz różnice w konstrukcji formularzy. Zmiana nazwy kampanii lub formularza bez migracji danych może utworzyć pozorny spadek albo wzrost reakcji, mimo że zachowanie użytkowników faktycznie się nie zmieniło.

Kontrola zapisu danych w aplikacji serwisowej

W aplikacji obsługującej formularz warto sprawdzić cały przebieg danych: generowanie adresu strony, odczyt parametrów źródłowych, zapis ich w przeglądarce, wstawienie do formularza, przesłanie żądania, walidację po stronie serwera oraz zapis rekordu w bazie. Każdy etap powinien używać jednoznacznych nazw pól i tego samego typu danych. Jeżeli źródło jest tekstem, baza i warstwa API powinny obsługiwać tekst bez niejawnego obcinania wartości. Przydatne są również logi techniczne zawierające identyfikator zdarzenia, identyfikator formularza, wynik walidacji i kod odpowiedzi, bez zapisywania pełnej treści pól kontaktowych.

Podczas diagnostyki można porównać liczbę zdarzeń w logach aplikacji z liczbą rekordów zaakceptowanych przez backend oraz z raportem analitycznym. Różnice mogą wynikać z ponowionych żądań, błędów sieci, odrzuceń antyspamowych, opóźnionego wysłania zdarzenia albo podwójnego uruchomienia procedury po kliknięciu przycisku. Warto testować osobno wejście z parametrami UTM, wejście bez parametrów, przekierowanie, odświeżenie strony, błąd walidacji i ponowną wysyłkę tego samego formularza. Taki zestaw testów pozwala ustalić, czy „reakcja wg źródła zapisu” opisuje rzeczywiste zapisy, czy tylko próby wykonania operacji.