Attribuzione dei ricavi

Collega gli ordini verificati al traffico e alle campagne che li hanno generati.

Gli ordini raggiungono Seean in due modi: un connettore nativo riceve i webhook firmati di un fornitore di pagamenti, oppure il tuo server invia ordini e rimborsi verificati all’API degli ordini di Seean. Ogni sito web rendiconta in una sola valuta che scegli tu. Quando un ordine indica un visitatore noto a Seean, l’attribuzione (contatti, prima e ultima sorgente, pagina di atterraggio, tempo all’acquisto) viene derivata sul server dalle visite tracciate di quel visitatore nei 90 giorni precedenti l’ordine. I campi forniti dalla tua integrazione vengono usati solo per i visitatori senza visite tracciate.

Collegare un fornitore di pagamenti

Apri Settings → Integrations → Payment providers (Impostazioni → Integrazioni → Fornitori di pagamento) sul tuo sito web e seleziona Enable (Attiva) sotto Creem, Mollie, Paddle, Polar, RevenueCat, Revolut, Shopify, Stripe, Superwall o Whop. Il pannello elenca i passaggi di configurazione, l’URL del webhook del sito web per quel fornitore (https://events.seean.io/api/connect/<provider>/<site ID>) e gli eventi da attivare; incolla il segreto di firma del fornitore e Seean verifica ogni consegna prima di memorizzarla. Per Stripe, Polar e Paddle, Quick connect (Connessione rapida) crea invece il webhook da una chiave API che incolli una sola volta; la chiave non viene memorizzata. Dopo Save secret (Salva segreto) il campo si svuota per sicurezza e la riga sotto riporta Secret saved (ends in …) (Segreto salvato, termina con …) con gli ultimi quattro caratteri, così puoi confermare che è memorizzato il segreto giusto; incolla un nuovo valore solo per sostituirlo. Ordini pagati e rimborsi arrivano poi automaticamente e la riga di stato mostra l’ultimo evento ed eventuali errori. Una connessione o disconnessione fallita mostra il motivo del server, inclusi i secondi di attesa quando la richiesta è stata limitata. Le guide dei fornitori sotto riportano per ogni fornitore i passaggi, lo snippet di attribuzione, il comportamento di rimborsi e valute e i limiti.

Stripe offre inoltre, dopo la connessione, una sezione separata riservata al proprietario, Optional Stripe payment reads (Letture dei pagamenti Stripe opzionali). Un controllo di consenso inizialmente non selezionato autorizza esplicitamente la conservazione di una chiave di lettura limitata per l’esatta fattura iniziale del Checkout, i pagamenti e i rimborsi — non i rinnovi né un recupero storico. La chiave non viene mai precompilata né restituita; solo il proprietario vede lo stato attivo, la modalità test/live, l’account e il suffisso. La sostituzione richiede un nuovo consenso. Remove read key (Rimuovi chiave di lettura) lascia intatti webhook, ordini e collegamenti ai pagamenti esistenti. La riconnessione rapida o manuale rimuove l’accesso in lettura conservato, mentre la chiave della connessione rapida resta usata una volta e scartata. I controlli in demo o durante un’operazione sono disattivati; le azioni riuscite e i cambi di fornitore cancellano la chiave di lettura digitata. Vedi la guida Stripe per permessi, verifiche dei rimborsi riusciti, collegamento di eventi firmati/replay e recupero esplicito a sessione singola delimitato. Questa consegna del codice non conferma il rilascio in produzione né il recupero storico dal vivo.

Recupero delle consegne

Un connettore nativo restituisce 503 quando un rimborso arriva prima del suo ordine (fino a un giorno dopo la creazione del rimborso; oltre, il rimborso viene confermato e ignorato), quando una ricerca di un ordine Revolut fallisce o quando l’acquisizione non è temporaneamente disponibile. I limiti di frequenza restituiscono 429. Queste risposte lasciano la consegna idonea ai nuovi tentativi del fornitore; Seean non tiene una seconda coda di webhook. Dopo che l’ordine originale è memorizzato, ripetere il rimborso con lo stesso ID di rimborso lo applica una sola volta.

Controlla Settings → Integrations → Payment providers per l’ora dell’ultima consegna e l’errore di mappatura o ricerca registrato. Correggi credenziali o dati di pagamento non validi alla loro origine. Una consegna successiva riuscita cancella l’ultimo errore, quindi controlla anche le consegne fallite nella dashboard del fornitore. Gli eventi non supportati e gli errori permanenti di payload o valuta vengono confermati con 200; gli ordini rifiutati non vengono memorizzati.

I programmi di nuovo tentativo e la scadenza sono controllati da ciascun fornitore. Se i tentativi di consegna scadono, usa i suoi controlli di riconsegna quando disponibili, oppure invia l’ordine o il rimborso verificato tramite l’API degli ordini con gli identificatori originali. I fallimenti già confermati non vengono ripetuti automaticamente da questa modifica. Le letture opzionali di Stripe possono stabilire collegamenti al pagamento iniziale a partire da eventi Checkout firmati appena consegnati o da replay esatti; attivare la chiave non avvia il recupero storico. I proprietari autenticati possono richiedere separatamente una prova di riconciliazione a sessione singola e poi un’applicazione esplicita tramite un’integrazione personalizzata; non esiste un’esecuzione automatica o per l’intero sito. Gli accordi multi-fattura/credito non supportati e i riferimenti mancanti richiedono revisione. Non creare mai un nuovo ID ordine solo per ritentare un pagamento.

Inviare ordini dal tuo server

Apri Settings → Integrations → Revenue (Impostazioni → Integrazioni → Ricavi), poi espandi Custom server integration (Order API) (Integrazione server personalizzata) per scegliere la valuta di rendicontazione e creare un segreto per l’API degli ordini. Usa il tuo server o il gestore dei webhook di pagamento per inviare gli ordini verificati all’endpoint mostrato. Tieni il segreto sul tuo server; non includerlo nel codice del browser. È un’integrazione personalizzata, non una connessione automatica a ogni fornitore di checkout.

Il tracker espone window.seean.attribution() con l’ID del visitatore, il percorso di atterraggio, il percorso di conversione e la campagna. Passa quei campi al tuo server insieme all’ordine: l’ID del visitatore è ciò che collega l’ordine alle visite dell’acquirente. Senza di esso l’ordine viene registrato come non attribuito. Inoltra gli eventi di pagamento solo dopo averli verificati con il tuo fornitore.

Valuta di rendicontazione

Ogni sito web ha una sola valuta di rendicontazione. Apri il menu a tendina sotto Reporting currency (Valuta di rendicontazione) nella scheda dell’integrazione Ricavi e scegli un codice ISO 4217 (USD per impostazione predefinita); la selezione si salva automaticamente. Gli importi si inviano nelle unità minori di quella valuta: 2900 è USD 29,00, JPY non ha unità minore quindi 2900 è JPY 2.900, e KWD usa tre decimali quindi 2900 è KWD 2,900. Un ordine in qualsiasi altra valuta viene rifiutato con HTTP 400 e il messaggio Order currency EUR does not match the website's reporting currency USD (con i codici coinvolti). Seean non converte le valute.

Cambiare la valuta di rendicontazione non converte gli ordini già inviati. Le analisi li contano come esclusi e la pagina Ricavi mostra un avviso come “3 orders use another currency and are excluded from the USD totals.” (3 ordini usano un’altra valuta e sono esclusi dai totali in USD). Solo gli ordini nella valuta di rendicontazione corrente formano i totali.

Rimborsi

I rimborsi sono un registro per ordine. Un rimborso può coprire l’intero importo residuo o un amount parziale, porta opzionalmente il tuo refundId così i nuovi tentativi vengono deduplicati, e può avere un proprio timestamp. Un rimborso che supera l’importo residuo viene rifiutato con HTTP 400; un ordine accetta al massimo 50 rimborsi. Quando il totale rimborsato raggiunge l’importo dell’ordine, l’ordine viene segnato come rimborsato.

I rimborsi riducono i ricavi netti nel periodo dell’ordine originale, non nel periodo della data del rimborso. Un ordine di giugno rimborsato a luglio abbassa il netto di giugno; luglio non mostra nulla al riguardo. Controlla l’intervallo che contiene l’ordine.

Attribuzione derivata

Per un ordine con un visitatore noto, Seean legge le visite di quel visitatore nei 90 giorni precedenti il timestamp dell’ordine:

• Touches (Contatti): il numero di visite in quella finestra.
• First source (Prima sorgente) e Last source (Ultima sorgente): il referrer o utm_source della prima e dell’ultima visita; Direct quando non c’è nessuno dei due.
• Landing page (Pagina di atterraggio): la pagina di ingresso della prima visita.
• Time to buy (Tempo all’acquisto): dall’inizio della prima visita all’ordine.
• Campaign (Campagna): la campagna fornita dalla tua integrazione; altrimenti l’utm_campaign della visita taggata più recente.

Se il visitatore non ha visite tracciate nella finestra, vengono usati prima sorgente, ultima sorgente, contatti e tempo all’acquisto forniti dalla tua integrazione, e l’ordine conta come attribuito solo quando indica un visitatore e un percorso di atterraggio. Gli ordini inviati senza ID visitatore sono Unattributed (Non attribuiti). Gli ordini registrati prima dell’esistenza dell’attribuzione derivata vengono completati una volta dalle visite tracciate del loro visitatore; una campagna fornita dalla tua integrazione viene mantenuta.

Limiti di attribuzione

L’acquisizione degli ordini accetta cronologie fino a 2.000 eventi corrispondenti nella finestra di 90 giorni. Sonda al massimo 2.001 righe per rilevare lo sforamento, con un budget di lettura di 1 MiB. Un percorso completo salvato può occupare fino a 64 KiB. Questi limiti si applicano alla cronologia del visitatore di ciascun ordine, non al traffico totale di un sito web. Seean salva ogni contatto quando la cronologia completa rientra nei limiti; non scarta più le visite dopo la trentesima.

Se la cronologia supera un limite, l’ordine e i rimborsi vengono comunque registrati esattamente. Il report Ricavi mostra un avviso di cronologia incompleta e una riga di dettaglio Incomplete history (Cronologia incompleta) invece di assegnare credito da una parte del percorso. Questi ordini non contribuiscono ai ricavi attribuiti né al tempo medio all’acquisto; restano nei totali monetari e nel denominatore del tasso di attribuzione. Il report conta gli ordini interessati per la valuta e il periodo selezionati, inclusi quelli interamente rimborsati. Cambiare la finestra retrospettiva non recupera la cronologia che non è stato possibile catturare all’acquisizione.

Anche i percorsi abbreviati legacy vengono segnati come incompleti finché la loro cronologia completa non può essere recuperata. I risultati dei report già salvati vengono conservati. Le cronologie senza visite tracciate mantengono l’attribuzione fornita dall’integrazione descritta sopra; sono distinte da una cronologia che ha superato un limite. L’arricchimento automatico oltre questi limiti non è attualmente disponibile.

Ignorare le visite di checkout e di ringraziamento

Un ritorno dal fornitore di pagamenti avvia spesso una nuova visita sulla tua pagina di ringraziamento o di checkout, che prenderebbe il credito dell’ultimo contatto. Sotto Settings → Exclusions → Revenue attribution only (Impostazioni → Esclusioni → Solo attribuzione dei ricavi), amministratori e proprietari aggiungono fino a 20 regole di percorso con la sintassi delle esclusioni del traffico (/thanks esattamente, o /checkout/* per un prefisso). Le visite che entrano su un percorso corrispondente vengono rimosse dai contatti dell’ordine prima di applicare la finestra retrospettiva e il modello; se non resta alcun contatto, l’ordine è Unattributed. Nulla viene eliminato: traffico, pagine della Panoramica e ogni altro report mantengono quelle visite, e la pagina di conversione mostra ancora il percorso fornito dalla tua integrazione. Le regole si applicano solo ai nuovi calcoli — i report Ricavi e Panoramica avviano una nuova analisi quando una regola cambia, mentre i risultati già salvati, i report programmati già calcolati e i risultati dell’API restano com’erano; la richiesta API successiva calcola con le nuove regole. Gli ordini senza cronologia delle visite (inviati senza ID visitatore, o più vecchi dell’attribuzione derivata) non possono essere filtrati; il report li conta sotto l’avviso delle regole.

Report Ricavi

Apri Revenue (Ricavi) nella barra laterale del sito web. Le sue tabelle tengono ogni valore su una riga; sugli schermi stretti una tabella scorre lateralmente dentro la sua scheda e i percorsi d’acquisto lunghi vengono abbreviati con puntini di sospensione (passa il puntatore per il percorso completo). La barra degli strumenti ha l’intervallo di date più i controlli di attribuzione:

• Attribution model (Modello di attribuzione): First touch (Primo contatto) accredita la prima visita nella finestra retrospettiva, Last touch (Ultimo contatto) la visita che ha portato all’ordine, Linear (Lineare) divide l’ordine equamente tra le sue visite.
• Attribution lookback (Finestra retrospettiva di attribuzione): 7, 14, 30 o 90 giorni prima dell’ordine. Una visita più vecchia della finestra non è un contatto. Le visite complete salvate si usano per il credito del modello, nei limiti di attribuzione descritti sopra.
• Website default (Predefinito del sito web): la pagina si apre con il modello e la finestra salvati del sito web (ultimo contatto, 30 giorni finché non ne viene salvato uno). Quando la tua selezione è diversa, amministratori e proprietari vedono Save as website default (Salva come predefinito del sito web); il predefinito è condiviso con il credito dei ricavi della Panoramica, con l’API di analisi e get_revenue di MCP, e con ogni collega. Una selezione nell’URL vince sempre per quella vista. Overview: net / gross (Panoramica: netto / lordo) sceglie cosa mostra il KPI della Panoramica (vedi KPI); il sito web demo non può cambiare queste impostazioni.

La fascia superiore mostra lordo, rimborsi (con il numero di rimborsi), netto, ricavi attribuiti, tasso di attribuzione e tempo medio all’acquisto. Attribution breakdown (Dettaglio dell’attribuzione) ha cinque linguette: Landing pages, Converting pages, First source, Last source e Sources (Pagine di atterraggio, Pagine di conversione, Prima sorgente, Ultima sorgente e Sorgenti). Sorgenti accredita ogni sorgente secondo il modello selezionato, quindi con Lineare un ordine compare una volta sotto ciascuna delle sue sorgenti con una quota del suo importo netto. Revenue by product (Ricavi per prodotto) elenca ordini, ricavi, quota e porzione attribuita. Touches before purchase (Contatti prima dell’acquisto) raggruppa gli ordini per numero di contatti derivato. Purchase journeys (Percorsi d’acquisto) raggruppa gli ordini pagati per pagina di ingresso di ogni visita dentro la finestra retrospettiva, dal più vecchio (/ → /pricing → /checkout): le ripetizioni consecutive si compattano, si conservano solo gli ultimi sei passi dietro puntini di sospensione, un percorso fornito dalla tua integrazione sostituisce il percorso derivato e gli ordini senza cronologia delle visite mostrano la loro pagina di atterraggio. I percorsi sono pagine di ingresso delle visite, non ogni pagina vista.

Orders (Ordini) elenca gli ordini del periodo dal più recente, venti alla volta con Load more (Carica altri), solo nella valuta di rendicontazione: ora (passa il puntatore per il momento esatto nel tuo fuso di visualizzazione), prodotto con i badge Refunded (Rimborsato) o Partially refunded −importo (Parzialmente rimborsato), prima sorgente, percorso e importo secondo il modello e la finestra selezionati. Gli ordini con cronologia incompleta mostrano Incomplete history. Refunds (Rimborsi) elenca ogni rimborso di quegli ordini — ora del rimborso, ID ordine (o ora dell’ordine), prodotto, ID rimborso e importo — anch’essi venti alla volta; un rimborso totale registrato prima dell’esistenza dei registri dei rimborsi compare una volta come legacy. I rimborsi contano sempre nel periodo del loro ordine, sia qui sia nei totali. Gli osservatori possono leggere entrambi gli elenchi; le esportazioni grezze restano sotto Settings → Data (Impostazioni → Dati).

Cambiare modello o finestra avvia una nuova analisi per lo stesso intervallo; i risultati esistenti e gli ordini memorizzati non vengono riscritti.

Confrontare i periodi

Il pulsante di confronto accanto all’intervallo di date offre le stesse scelte della Panoramica: Previous period, Previous week, Previous month, Previous quarter, Previous year, Custom range… e No comparison (vedi intervalli di date e filtri). Con un confronto attivo, ogni KPI della fascia superiore mostra la variazione percentuale rispetto all’intervallo di confronto invece del suo valore: lordo, rimborsi, netto, ricavi attribuiti, tasso di attribuzione e tempo all’acquisto. Un aumento dei rimborsi o del tempo all’acquisto viene mostrato come peggioramento. Previous period viene calcolato nella stessa analisi; le altre scelte avviano un’analisi dei ricavi aggiuntiva con lo stesso modello, finestra e valuta di rendicontazione. Tabelle di dettaglio, prodotti, contatti, percorsi, ordini e rimborsi restano viste del periodo corrente, e All time non ha confronto.

Passaggio dell’attribuzione

Che sia un connettore o il tuo server a registrare l’ordine, il collegamento alla visita è l’ID del visitatore. Con un connettore, allega seean_visitor_id (e opzionalmente seean_landing_path, seean_converting_path, seean_campaign) da window.seean.attribution() ai metadati del checkout, ai dati personalizzati, agli attributi del carrello o agli attributi dell’abbonato del fornitore, come mostra la guida del fornitore; Seean legge quelle chiavi dall’evento verificato. Il token di tracciamento pubblico non autorizza mai l’acquisizione degli ordini.

Per un’integrazione personalizzata, cattura window.seean?.attribution?.() quando disponibile durante la creazione del checkout e passa al tuo server solo i campi supportati. Memorizzali con il riferimento del checkout/ordine così che il successivo evento di pagamento verificato possa usarli. L’helper può essere assente prima del caricamento o non restituire alcuna attribuzione quando la raccolta è disattivata. In quel caso accetta un ordine non attribuito; non inventare valori di visitatore o campagna.

Dopo il caricamento del tracker, attendi window.seean?.ready prima di leggere l’attribuzione. Si completa dopo il tentativo di raccolta iniziale o il suo timeout; non garantisce che esista un ID visitatore. Usalo dentro il tuo gestore di checkout asincrono e permetti al checkout di continuare senza attribuzione. Ogni esempio per fornitore include l’attesa.

L’hash predefinito del visitatore cambia a mezzanotte UTC ed è limitato a un sito web. La finestra retrospettiva di 90 giorni cerca i record che portano l’identificatore catturato; non unisce i diversi hash giornalieri di quel visitatore. Conserva l’attribuzione del momento del checkout per i webhook di pagamento ritardati. Un ritorno successivo in un nuovo giorno UTC ha una nuova identità, quindi i percorsi su più giorni non vengono ricostruiti. Gli ordini legacy e i risultati salvati mantengono identificatori e valori originali.

Mantieni identificatori esterni degli ordini stabili tra i nuovi tentativi. Inoltra i pagamenti ricorrenti come gli ordini pagati distinti che rappresentano e mappa ogni rimborso all’ID ordine esterno originale con l’ID rimborso del fornitore. La tua integrazione deve tenere conto dell’ordine degli eventi e dei duplicati del fornitore. Converti gli importi del fornitore nelle unità minori della valuta di rendicontazione del sito web solo quando il pagamento è stato effettivamente addebitato in quella valuta; Seean rifiuta le altre valute invece di convertirle.

Verificare l’integrazione

Usa gli strumenti di test del tuo fornitore e, dove possibile, un sito web Seean di prova separato. Verifica un ordine pagato, un nuovo tentativo identico, un rimborso parziale, un rimborso totale e un ordine senza attribuzione. Confronta il report Ricavi del sito web con gli importi esatti e l’attribuzione derivata. Una richiesta del tracker riuscita o una visita alla pagina di conferma non dimostrano che l’ordine sia stato acquisito.

Riferimento per l’integrazione

Segui API degli ordini e rimborsi per payload, gestione della chiave server, regole sulle valute, regole sui rimborsi e comportamento dei nuovi tentativi. La disponibilità dei fornitori riassume quali fornitori hanno un connettore nativo.

Guide dei fornitori

Ogni guida copre i passaggi di configurazione del fornitore, lo snippet di attribuzione per il suo checkout, cosa viene registrato, rimborsi, valuta, verifica e limiti.

La cronologia del visitatore tracciato viene catturata una volta quando un nuovo ordine viene accettato, tramite l’API degli ordini o un connettore di un fornitore supportato. Un errore temporaneo nella ricerca della cronologia restituisce una risposta ritentabile; un duplicato accettato mantiene l’attribuzione originale e l’importo esatto. Vedi nuovi tentativi dell’API degli ordini.

• 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.

Qualcosa non è chiaro? Contatta il supporto.