Atrybucja przychodów

Połącz zweryfikowane zamówienia z ruchem i kampaniami, które za nimi stoją.

Zamówienia docierają do Seean na dwa sposoby: natywny łącznik odbiera podpisane webhooki dostawcy płatności albo Twój serwer wysyła zweryfikowane zamówienia i zwroty do API zamówień Seean. Każda witryna raportuje w jednej wybranej przez Ciebie walucie. Gdy zamówienie wskazuje odwiedzającego znanego Seean, atrybucja (kontakty, pierwsze i ostatnie źródło, strona docelowa, czas do zakupu) jest wyprowadzana na serwerze ze śledzonych wizyt tego odwiedzającego w ciągu 90 dni przed zamówieniem. Pola dostarczone przez integrację są używane tylko dla odwiedzających bez śledzonych wizyt.

Podłączanie dostawcy płatności

Otwórz Settings → Integrations → Payment providers (Ustawienia → Integracje → Dostawcy płatności) we własnej witrynie i wybierz Enable (Włącz) pod Creem, Mollie, Paddle, Polar, RevenueCat, Revolut, Shopify, Stripe, Superwall lub Whop. Panel wyświetla kroki konfiguracji, adres URL webhooka witryny dla tego dostawcy (https://events.seean.io/api/connect/<provider>/<site ID>) oraz zdarzenia do włączenia; wklej sekret podpisu dostawcy, a Seean zweryfikuje każde dostarczenie przed zapisaniem. Dla Stripe, Polar i Paddle Quick connect (Szybkie łączenie) tworzy webhook z klucza API wklejanego jednorazowo; klucz nie jest przechowywany. Po Save secret (Zapisz sekret) pole czyści się ze względów bezpieczeństwa, a wiersz pod nim pokazuje Secret saved (ends in …) z ostatnimi czterema znakami, abyś mógł potwierdzić, że zapisano właściwy sekret; wklej nową wartość tylko po to, aby go zastąpić. Opłacone zamówienia i zwroty docierają wtedy automatycznie, a wiersz stanu pokazuje ostatnie zdarzenie i ewentualny błąd. Nieudane połączenie lub odłączenie pokazuje przyczynę z serwera, łącznie z liczbą sekund oczekiwania, gdy żądanie zostało ograniczone limitem. Poniższe przewodniki dostawców podają kroki każdego dostawcy, fragment kodu atrybucji, zachowanie zwrotów i waluty oraz ograniczenia.

Stripe dodatkowo oferuje po połączeniu osobną sekcję Optional Stripe payment reads (Opcjonalny odczyt płatności Stripe), dostępną tylko dla właściciela. Początkowo niezaznaczona kontrolka zgody jawnie autoryzuje zachowanie ograniczonego klucza odczytu dla dokładnej początkowej faktury, płatności i zwrotów Checkout — nie odnowień ani uzupełniania historii. Klucz nigdy nie jest wstępnie wypełniany ani zwracany; tylko właściciel widzi stan włączenia, tryb test/live, konto i sufiks. Zastąpienie wymaga nowej zgody. Remove read key (Usuń klucz odczytu) pozostawia webhook, zamówienia i istniejące powiązania płatności nienaruszone. Szybkie/ręczne ponowne połączenie usuwa zachowany dostęp do odczytu, a klucz szybkiego łączenia nadal jest używany raz i odrzucany. Kontrolki demo/zajęte są wyłączone; udane akcje i przełączenie dostawcy czyszczą wpisany klucz odczytu. Zobacz przewodnik Stripe, aby poznać uprawnienia, sprawdzanie udanych zwrotów, powiązanie podpisanych zdarzeń/ponownych wysyłek oraz ograniczone jawne odzyskiwanie w jednej sesji. To dostarczenie w kodzie źródłowym nie potwierdza wdrożenia produkcyjnego ani odzyskiwania historii na żywo.

Odzyskiwanie dostarczeń

Natywny łącznik zwraca 503, gdy zwrot dociera przed swoim zamówieniem (do jednego dnia od utworzenia zwrotu; potem zwrot jest potwierdzany i ignorowany), gdy wyszukanie zamówienia Revolut się nie powiedzie lub gdy przyjmowanie jest tymczasowo niedostępne. Limity częstotliwości zwracają 429. Te odpowiedzi pozostawiają dostarczenie kwalifikowane do ponownych prób dostawcy; Seean nie utrzymuje drugiej kolejki webhooków. Po zapisaniu pierwotnego zamówienia ponowne wysłanie zwrotu z tym samym identyfikatorem zwrotu stosuje go raz.

Sprawdź Settings → Integrations → Payment providers, aby zobaczyć czas ostatniego dostarczenia i zapisany błąd mapowania lub wyszukiwania. Popraw dane uwierzytelniające lub nieprawidłowe dane płatności u źródła. Późniejsze udane dostarczenie czyści ostatni błąd, więc sprawdzaj też nieudane dostarczenia w panelu dostawcy. Nieobsługiwane zdarzenia i trwałe błędy ładunku/waluty są potwierdzane kodem 200; odrzucone zamówienia nie są zapisywane.

Harmonogramy ponownych prób i wygasanie kontroluje każdy dostawca. Jeśli próby dostarczenia wygasną, użyj jego kontrolek ponownego dostarczenia, gdy są dostępne, lub wyślij zweryfikowane zamówienie/zwrot przez Order API z pierwotnymi identyfikatorami. Wcześniej potwierdzone niepowodzenia nie są automatycznie odtwarzane przez tę zmianę. Opcjonalne odczyty Stripe mogą ustalać powiązania początkowych płatności z nowo dostarczonych podpisanych zdarzeń Checkout lub dokładnych ponownych wysyłek; włączenie klucza nie uruchamia odzyskiwania historii. Uwierzytelnieni właściciele mogą osobno zażądać próbnego uruchomienia uzgodnienia w jednej sesji, a następnie jawnego zastosowania przez integrację niestandardową; nie ma uruchomienia automatycznego ani dla całej witryny. Nieobsługiwane układy z wieloma fakturami/notami kredytowymi i brakujące odniesienia wymagają przeglądu. Nigdy nie twórz nowego identyfikatora zamówienia tylko po to, aby ponowić płatność.

Wysyłanie zamówień z serwera

Otwórz Settings → Integrations → Revenue, a następnie rozwiń Custom server integration (Order API), aby wybrać walutę raportowania i utworzyć sekret API zamówień. Użyj serwera lub obsługi webhooka płatności, aby wysyłać zweryfikowane zamówienia do wyświetlonego punktu końcowego. Przechowuj sekret na serwerze; nie umieszczaj go w kodzie przeglądarki. To integracja niestandardowa, a nie automatyczne połączenie z każdym dostawcą płatności.

Skrypt śledzący udostępnia window.seean.attribution() z identyfikatorem odwiedzającego, ścieżką docelową, ścieżką konwertującą i kampanią. Przekaż te pola do serwera razem z zamówieniem: identyfikator odwiedzającego łączy zamówienie z wizytami kupującego. Bez niego zamówienie jest rejestrowane jako nieprzypisane. Przekazuj zdarzenia płatności dopiero po zweryfikowaniu ich u dostawcy.

Waluta raportowania

Każda witryna ma jedną walutę raportowania. Otwórz listę pod Reporting currency (Waluta raportowania) na karcie integracji Przychody i wybierz kod ISO 4217 (domyślnie USD); wybór zapisuje się automatycznie. Kwoty są wysyłane w najmniejszych jednostkach tej waluty: 2900 to 29,00 USD, JPY nie ma jednostki pomocniczej, więc 2900 to 2 900 JPY, a KWD używa trzech miejsc dziesiętnych, więc 2900 to 2,900 KWD. Zamówienie w jakiejkolwiek innej walucie jest odrzucane z HTTP 400 i komunikatem Order currency EUR does not match the website's reporting currency USD (z odpowiednimi kodami). Seean nie przelicza walut.

Zmiana waluty raportowania nie przelicza już wysłanych zamówień. Analizy liczą je jako wykluczone, a strona Przychody pokazuje komunikat, np. „3 orders use another currency and are excluded from the USD totals.” Sumy tworzą wyłącznie zamówienia w bieżącej walucie raportowania.

Zwroty

Zwroty to księga per zamówienie. Zwrot może obejmować całą pozostałą kwotę lub częściową kwotę amount, opcjonalnie niesie Twój refundId, aby ponowne próby były deduplikowane, i może mieć własny znacznik czasu. Zwrot przekraczający pozostałą kwotę jest odrzucany z HTTP 400; zamówienie przyjmuje najwyżej 50 zwrotów. Gdy łączna zwrócona suma osiągnie kwotę zamówienia, zamówienie jest oznaczane jako zwrócone.

Zwroty obniżają przychody netto w okresie pierwotnego zamówienia, a nie w okresie daty zwrotu. Czerwcowe zamówienie zwrócone w lipcu obniża czerwcowe netto; lipiec nie pokazuje dla niego nic. Przejrzyj zakres zawierający zamówienie.

Wyprowadzona atrybucja

Dla zamówienia ze znanym odwiedzającym Seean odczytuje wizyty tego odwiedzającego w ciągu 90 dni przed znacznikiem czasu zamówienia:

• Kontakty: liczba wizyt w tym oknie.
• Pierwsze źródło i Ostatnie źródło: źródło odesłania lub utm_source pierwszej i ostatniej wizyty; Direct, gdy nie ma żadnego.
• Strona docelowa: strona wejścia pierwszej wizyty.
• Czas do zakupu: od początku pierwszej wizyty do zamówienia.
• Kampania: kampania dostarczona przez integrację; w przeciwnym razie utm_campaign najnowszej otagowanej wizyty.

Jeśli odwiedzający nie ma śledzonej wizyty w oknie, używane są pierwsze źródło, ostatnie źródło, kontakty i czas do zakupu dostarczone przez integrację, a zamówienie liczy się jako przypisane tylko wtedy, gdy wskazuje odwiedzającego i ścieżkę docelową. Zamówienia wysłane bez identyfikatora odwiedzającego są Nieprzypisane (Unattributed). Zamówienia zarejestrowane przed wprowadzeniem wyprowadzonej atrybucji są jednorazowo uzupełniane ze śledzonych wizyt ich odwiedzającego; kampania dostarczona przez integrację jest zachowywana.

Limity atrybucji

Przyjmowanie zamówień akceptuje historie do 2 000 pasujących zdarzeń w oknie 90 dni. Sprawdza najwyżej 2 001 wierszy, aby wykryć przepełnienie, z budżetem odczytu 1 MiB. Pełna zapisana podróż może zajmować do 64 KiB. Te limity dotyczą historii odwiedzającego każdego zamówienia, a nie łącznego ruchu witryny. Seean zapisuje każdy kontakt, gdy pełna historia się mieści; nie pomija już wizyt po trzydziestej.

Jeśli historia przekroczy limit, zamówienie i zwroty są nadal rejestrowane dokładnie. Raport Przychody pokazuje komunikat o niepełnej historii i wiersz podziału Incomplete history (Niepełna historia), zamiast przypisywać zasługę z części podróży. Te zamówienia nie zasilają przypisanych przychodów ani średniego czasu do zakupu; pozostają w sumach pieniężnych i w mianowniku wskaźnika atrybucji. Raport liczy dotknięte zamówienia dla wybranej waluty i okresu, łącznie z w pełni zwróconymi. Zmiana okna atrybucji nie odzyskuje historii, której nie udało się uchwycić przy przyjęciu.

Starsze skrócone podróże są również oznaczane jako niepełne, dopóki nie da się odzyskać ich pełnej historii. Istniejące zapisane wyniki raportów są zachowywane. Historie bez śledzonych wizyt zachowują opisaną wyżej atrybucję dostarczoną przez integrację; różnią się od historii, która przekroczyła limit. Automatyczne wzbogacanie poza tymi granicami nie jest obecnie dostępne.

Ignorowanie wizyt na stronach zakupu i podziękowania

Powrót od dostawcy płatności często rozpoczyna nową wizytę na stronie podziękowania lub zakupu, która przejęłaby zasługę ostatniego kontaktu. W Settings → Exclusions → Revenue attribution only administratorzy i właściciele dodają do 20 reguł ścieżek ze składnią wykluczeń ruchu (/thanks dokładnie lub /checkout/* jako prefiks). Wizyty, które wchodzą na pasującą ścieżkę, są usuwane z kontaktów zamówienia przed zastosowaniem okna atrybucji i modelu; jeśli nie pozostanie żaden kontakt, zamówienie jest Nieprzypisane. Nic nie jest usuwane: ruch, strony Przeglądu i każdy inny raport zachowują te wizyty, a strona konwertująca nadal pokazuje ścieżkę dostarczoną przez integrację. Reguły dotyczą tylko nowych obliczeń — raporty Przychody i Przegląd rozpoczynają nową analizę po zmianie reguły, podczas gdy już zapisane wyniki, już obliczone zaplanowane raporty i wyniki API pozostają bez zmian; następne żądanie API oblicza z nowymi regułami. Zamówień bez historii wizyt (wysłanych bez identyfikatora odwiedzającego lub starszych niż wyprowadzona atrybucja) nie można filtrować; raport liczy je pod komunikatem o regułach.

Raport Przychody

Otwórz Revenue (Przychody) na pasku bocznym witryny. Jego tabele trzymają każdą wartość w jednej linii; na wąskich ekranach tabela przewija się w bok wewnątrz karty, a długie ścieżki zakupowe są skracane wielokropkiem (wskaż, aby zobaczyć pełną ścieżkę). Pasek narzędzi ma zakres dat oraz kontrolki atrybucji:

• Attribution model (Model atrybucji): First touch (Pierwszy kontakt) przypisuje zasługę pierwszej wizycie w oknie, Last touch (Ostatni kontakt) wizycie, która doprowadziła do zamówienia, Linear (Liniowy) dzieli zamówienie równo między wizyty.
• Attribution lookback (Okno atrybucji): 7, 14, 30 lub 90 dni przed zamówieniem. Wizyta starsza niż okno nie jest kontaktem. Pełne zapisane wizyty są używane do przypisania zasługi w modelu, z zastrzeżeniem limitów atrybucji powyżej.
• Domyślne ustawienie witryny: strona otwiera się z zapisanym modelem i oknem witryny (ostatni kontakt, 30 dni, dopóki nie zapisano innego). Gdy Twój wybór się różni, administratorzy i właściciele widzą Save as website default (Zapisz jako domyślne dla witryny); domyślne ustawienie jest współdzielone z zasługą przychodów w Przeglądzie, API analityki i MCP get_revenue oraz z każdym członkiem zespołu. Wybór w adresie URL zawsze ma pierwszeństwo dla danego widoku. Overview: net / gross wybiera, co pokazuje KPI Przeglądu (zobacz KPI); witryna demonstracyjna nie może zmieniać tych ustawień.

Górny pasek pokazuje brutto, zwroty (z liczbą zwrotów), netto, przypisane przychody, wskaźnik atrybucji i średni czas do zakupu. Attribution breakdown (Podział atrybucji) ma pięć zakładek: Landing pages, Converting pages, First source, Last source i Sources. Sources przypisuje zasługę każdemu źródłu według wybranego modelu, więc przy modelu liniowym zamówienie pojawia się raz pod każdym ze swoich źródeł z udziałem kwoty netto. Revenue by product (Przychody według produktu) wyświetla zamówienia, przychody, udział i część przypisaną. Touches before purchase (Kontakty przed zakupem) grupuje zamówienia według wyprowadzonej liczby kontaktów. Purchase journeys (Ścieżki zakupowe) grupuje opłacone zamówienia według strony wejścia każdej wizyty w oknie, od najstarszej (/ → /pricing → /checkout): kolejne powtórzenia są scalane, zachowywanych jest tylko sześć ostatnich kroków za wielokropkiem, ścieżka dostarczona przez integrację zastępuje wyprowadzoną podróż, a zamówienia bez historii wizyt pokazują stronę docelową. Podróże to strony wejścia wizyt, a nie każda obejrzana strona.

Orders (Zamówienia) wyświetla zamówienia okresu od najnowszych, po dwadzieścia na raz z Load more, wyłącznie w walucie raportowania: czas (wskaż, aby zobaczyć dokładny moment w strefie czasowej wyświetlania), produkt z odznakami Refunded lub Partially refunded −kwota, pierwsze źródło, podróż i kwota według wybranego modelu i okna. Zamówienia z niepełną historią pokazują Incomplete history. Refunds (Zwroty) wyświetla każdy zwrot tych zamówień — czas zwrotu, identyfikator zamówienia (lub czas zamówienia), produkt, identyfikator zwrotu i kwotę — również po dwadzieścia na raz; pełny zwrot zarejestrowany przed wprowadzeniem ksiąg zwrotów pojawia się raz jako legacy. Zwroty zawsze liczą się w okresie swojego zamówienia, zarówno tutaj, jak i w sumach. Przeglądający mogą czytać obie listy; surowe eksporty pozostają w Settings → Data.

Zmiana modelu lub okna rozpoczyna nową analizę dla tego samego zakresu; istniejące wyniki i zapisane zamówienia nie są przepisywane.

Porównywanie okresów

Przycisk porównania obok zakresu dat oferuje te same opcje co Przegląd: Previous period, Previous week, Previous month, Previous quarter, Previous year, Custom range… i No comparison (zobacz zakresy dat i filtry). Przy aktywnym porównaniu każdy KPI w górnym pasku pokazuje procentową zmianę względem interwału porównania zamiast liczby: brutto, zwroty, netto, przypisane przychody, wskaźnik atrybucji i czas do zakupu. Wzrost zwrotów lub czasu do zakupu jest pokazywany jako spadek. Previous period jest obliczany w tej samej analizie; pozostałe opcje uruchamiają jedną dodatkową analizę przychodów z tym samym modelem, oknem i walutą raportowania. Tabele podziału, produkty, kontakty, podróże, zamówienia i zwroty pozostają widokami bieżącego okresu, a All time nie ma porównania.

Przekazanie atrybucji

Niezależnie od tego, czy zamówienie rejestruje łącznik, czy Twój serwer, powiązaniem z wizytą jest identyfikator odwiedzającego. Z łącznikiem dołącz seean_visitor_id (i opcjonalnie seean_landing_path, seean_converting_path, seean_campaign) z window.seean.attribution() do metadanych checkout, danych niestandardowych, atrybutów koszyka lub atrybutów subskrybenta dostawcy, jak pokazuje przewodnik dostawcy; Seean odczytuje te klucze ze zweryfikowanego zdarzenia. Publiczny token śledzenia nigdy nie autoryzuje przyjmowania zamówień.

W integracji niestandardowej uchwyć window.seean?.attribution?.(), gdy jest dostępne, podczas tworzenia zakupu i przekaż do serwera tylko obsługiwane pola. Zapisz je z odniesieniem do zakupu/zamówienia, aby późniejsze zweryfikowane zdarzenie płatności mogło ich użyć. Pomocnik może być nieobecny przed wczytaniem lub nie zwracać atrybucji, gdy zbieranie jest wyłączone. W takim przypadku przyjmij nieprzypisane zamówienie; nie wymyślaj wartości odwiedzającego ani kampanii.

Po wczytaniu skryptu śledzącego poczekaj na window.seean?.ready przed odczytem atrybucji. Kończy się to po początkowej próbie zbierania lub jej przekroczeniu czasu; nie gwarantuje, że identyfikator odwiedzającego istnieje. Użyj tego wewnątrz asynchronicznej obsługi zakupu i pozwól zakupowi kontynuować bez atrybucji. Każdy przykład dostawcy zawiera to oczekiwanie.

Domyślny hasz odwiedzającego zmienia się o północy UTC i jest ograniczony do jednej witryny. Okno 90 dni przeszukuje rekordy noszące uchwycony identyfikator; nie łączy różnych dziennych haszy tego odwiedzającego. Zachowuj atrybucję z momentu zakupu dla opóźnionych webhooków płatności. Późniejszy powrót w nowym dniu UTC ma nową tożsamość, więc podróże wielodniowe nie są rekonstruowane. Starsze zamówienia i zapisane wyniki zachowują pierwotne identyfikatory i wartości.

Zachowuj stabilne zewnętrzne identyfikatory zamówień przy ponownych próbach. Przekazuj płatności cykliczne jako odrębne opłacone zamówienia, którymi są, i mapuj każdy zwrot na pierwotny zewnętrzny identyfikator zamówienia z identyfikatorem zwrotu dostawcy. Twoja integracja musi uwzględniać kolejność zdarzeń dostawcy i duplikaty. Przeliczaj kwoty dostawcy na najmniejsze jednostki waluty raportowania witryny tylko wtedy, gdy płatność faktycznie została pobrana w tej walucie; Seean odrzuca inne waluty, zamiast je przeliczać.

Weryfikacja integracji

Korzystaj z narzędzi testowych dostawcy i, gdy to możliwe, z osobnej witryny testowej Seean. Zweryfikuj opłacone zamówienie, identyczną ponowną próbę, zwrot częściowy, zwrot pełny i zamówienie bez atrybucji. Porównaj raport Przychody witryny z dokładnymi kwotami i wyprowadzoną atrybucją. Udane żądanie skryptu śledzącego lub wizyta na stronie potwierdzenia nie dowodzą, że zamówienie zostało przyjęte.

Dokumentacja integracji

Postępuj zgodnie z Order API i zwroty, aby poznać ładunki, obsługę klucza serwera, reguły walut, reguły zwrotów i zachowanie ponownych prób. Dostępność dostawców podsumowuje, którzy dostawcy mają natywny łącznik.

Przewodniki dostawców

Każdy przewodnik obejmuje kroki konfiguracji dostawcy, fragment kodu atrybucji dla jego procesu zakupu, co jest rejestrowane, zwroty, walutę, weryfikację i ograniczenia.

Śledzona historia odwiedzającego jest uchwytywana raz, gdy nowe zamówienie zostaje zaakceptowane, przez Order API lub obsługiwany łącznik dostawcy. Tymczasowe niepowodzenie wyszukiwania historii zwraca odpowiedź nadającą się do ponownej próby; zaakceptowany duplikat zachowuje pierwotną atrybucję i dokładną kwotę. Zobacz ponowne próby Order API.

• Creem

  Connect Creem to Seean with the webhook secret, pass the visitor ID as checkout metadata and receive completed checkouts and refunds.

• Mollie

  Connect Mollie to Seean through signed next-generation webhooks, pass the visitor ID as payment metadata and receive paid payments and refunds.

• Paddle

  Connect Paddle to Seean with the notification secret key, pass the visitor ID as checkout custom data and receive completed transactions and approved refunds.

• Polar

  Connect Polar to Seean with the webhook secret, pass the visitor ID as checkout metadata and receive paid orders, renewals and refunds.

• RevenueCat

  Connect RevenueCat to Seean with the webhook authorization value, pass the visitor ID as Web Billing metadata or a subscriber attribute and receive purchases, renewals and refunds.

• Revolut

  Connect the Revolut Merchant API to Seean with the webhook signing secret and Merchant API secret key, pass the visitor ID as order metadata and receive completed orders.

• Shopify

  Connect a Shopify store to Seean with the webhook signing secret, write the visitor ID as a cart attribute and receive paid orders and refunds.

• Stripe

  Connect Stripe Checkout to Seean with the webhook signing secret, pass the visitor ID as session metadata and receive paid orders and refunds.

• Superwall

  Connect Superwall to Seean with the webhook signing secret, set the visitor ID as a user attribute and receive purchases and renewals.

• Whop

  Connect Whop to Seean with the webhook signing secret, pass the visitor ID as checkout metadata and receive successful payments and refunds.

Coś jest niejasne? Skontaktuj się z pomocą.