Intäktsattribution

Koppla verifierade beställningar till trafiken och kampanjerna bakom dem.

Beställningar når Seean på två sätt: en inbyggd anslutning tar emot en betalleverantörs signerade webhooks, eller din server skickar verifierade beställningar och återbetalningar till Seeans beställnings-API. Varje webbplats rapporterar i en valuta som du väljer. När en beställning anger en besökare Seean känner till härleds attributionen (kontakter, första och sista källa, landningssida, tid till köp) på servern från den besökarens spårade besök under de 90 dagarna före beställningen. Fält som din integration skickar används bara för besökare utan spårade besök.

Ansluta en betalleverantör

Öppna Settings → Integrations → Payment providers (Inställningar → Integrationer → Betalleverantörer) på din egen webbplats och välj Enable (Aktivera) under Creem, Mollie, Paddle, Polar, RevenueCat, Revolut, Shopify, Stripe, Superwall eller Whop. Panelen listar installationsstegen, webbplatsens webhook-URL för den leverantören (https://events.seean.io/api/connect/<provider>/<site ID>) och händelserna att aktivera; klistra in leverantörens signeringshemlighet så verifierar Seean varje leverans innan den lagras. För Stripe, Polar och Paddle skapar Quick connect (Snabbanslutning) i stället webhooken från en API-nyckel du klistrar in en gång; nyckeln lagras inte. Efter Save secret (Spara hemlighet) rensas fältet av säkerhetsskäl och raden under det lyder Secret saved (ends in …) (Hemligheten sparades, slutar på …) med de sista fyra tecknen, så att du kan bekräfta att rätt hemlighet är lagrad; klistra in ett nytt värde bara för att ersätta det. Betalda beställningar och återbetalningar kommer sedan automatiskt, och statusraden visar den senaste händelsen och eventuellt fel. En misslyckad anslutning eller frånkoppling visar serverns orsak, inklusive sekunderna att vänta när begäran hastighetsbegränsades. Leverantörsguiderna nedan ger varje leverantörs steg, attributionskodavsnitt, beteende för återbetalningar och valuta samt begränsningar.

Stripe erbjuder dessutom ett separat avsnitt Optional Stripe payment reads (Valfria Stripe-betalningsläsningar) som bara ägaren ser efter anslutningen. En samtyckeskontroll som är avmarkerad från början auktoriserar uttryckligen att en begränsad läsnyckel behålls för exakt den initiala Checkout-fakturan, betalningar och återbetalningar—inte förnyelser eller en efterfyllning. Nyckeln förifylls eller returneras aldrig; bara ägaren ser aktiverad status, test-/live-läge, konto och suffix. Ersättning kräver nytt samtycke. Remove read key (Ta bort läsnyckel) lämnar webhooken, beställningarna och befintliga betalningslänkar intakta. Snabb/manuell återanslutning tar bort behållen läsåtkomst, medan snabbanslutningsnyckeln fortsatt används en gång och kastas. Demo-/upptagna kontroller är inaktiverade; lyckade åtgärder och leverantörsbyten rensar den inskrivna läsnyckeln. Se Stripe-guiden för behörigheter, kontroller av lyckade återbetalningar, koppling av signerad händelse/omspelning och begränsad uttrycklig återställning för en enskild session. Denna källeverans bekräftar inte produktionsutrullning eller historisk återställning i drift.

Återställning av leveranser

En inbyggd anslutning returnerar 503 när en återbetalning kommer före sin beställning (i upp till en dag efter att återbetalningen skapades; därefter bekräftas återbetalningen och ignoreras), en Revolut-beställningsuppslagning misslyckas eller mottagningen är tillfälligt otillgänglig. Hastighetsgränser returnerar 429. Dessa svar lämnar leveransen berättigad till leverantörens omförsök; Seean har ingen andra webhook-kö. När den ursprungliga beställningen lagrats tillämpar en omspelning av återbetalningen med samma återbetalnings-ID den en gång.

Kontrollera Settings → Integrations → Payment providers för den senaste leveranstiden och registrerat mappnings- eller uppslagningsfel. Rätta uppgifter eller ogiltiga betalningsdata vid källan. En senare lyckad leverans rensar det senaste felet, så kontrollera också misslyckade leveranser i leverantörens instrumentpanel. Händelser som inte stöds och permanenta fel i innehåll/valuta bekräftas med 200; avvisade beställningar lagras inte.

Scheman och utgång för omförsök styrs av varje leverantör. Om leveransförsöken går ut, använd dess kontroller för omleverans när de finns, eller skicka den verifierade beställningen/återbetalningen genom beställnings-API:et med de ursprungliga identifierarna. Tidigare bekräftade fel spelas inte upp igen automatiskt av den här ändringen. Stripes valfria läsningar kan upprätta länkar för initiala betalningar från nyligen levererade signerade Checkout-händelser eller exakta omspelningar; att aktivera nyckeln startar ingen historisk återställning. Autentiserade ägare kan separat begära en torrkörning av avstämning för en enskild session och sedan en uttrycklig tillämpning genom en egen integration; det finns ingen automatisk eller webbplatsomfattande körning. Flerfakturs-/kreditarrangemang som inte stöds och saknade referenser kräver granskning. Skapa aldrig ett nytt beställnings-ID bara för att försöka en betalning igen.

Skicka beställningar från din server

Öppna Settings → Integrations → Revenue (Inställningar → Integrationer → Intäkter) och expandera sedan Custom server integration (Order API) (Egen serverintegration) för att välja rapporteringsvaluta och skapa en API-hemlighet för beställningar. Använd din server eller din betalningswebhook-hanterare för att skicka verifierade beställningar till den visade slutpunkten. Behåll hemligheten på din server; inkludera den inte i webbläsarkod. Det är en egen integration, inte en automatisk anslutning till varje kassaleverantör.

Spåraren exponerar window.seean.attribution() med besökar-ID, landningssökväg, konverterande sökväg och kampanj. Skicka de fälten till din server tillsammans med beställningen: besökar-ID:t är det som kopplar beställningen till köparens besök. Utan det registreras beställningen som ej attribuerad. Vidarebefordra betalningshändelser först efter att du verifierat dem hos din leverantör.

Rapporteringsvaluta

Varje webbplats har en rapporteringsvaluta. Öppna listan under Reporting currency (Rapporteringsvaluta) i kortet för intäktsintegration och välj en ISO 4217-kod (USD som standard); valet sparas automatiskt. Belopp skickas i den valutans minsta enhet: 2900 är USD 29.00, JPY har ingen minsta enhet så 2900 är JPY 2 900, och KWD använder tre decimaler så 2900 är KWD 2.900. En beställning i någon annan valuta avvisas med HTTP 400 och meddelandet Order currency EUR does not match the website's reporting currency USD (med de berörda koderna). Seean konverterar inte valutor.

Att ändra rapporteringsvalutan konverterar inte beställningar du redan skickat. Analyserna räknar dem som uteslutna, och sidan Intäkter visar ett meddelande som ”3 beställningar använder en annan valuta och ingår inte i totalerna i USD.” Bara beställningarna i den aktuella rapporteringsvalutan bildar totalerna.

Återbetalningar

Återbetalningar är en liggare per beställning. En återbetalning kan täcka hela det återstående beloppet eller ett partiellt amount, bär valfritt ditt refundId så att omförsök dedupliceras, och kan bära sin egen tidsstämpel. En återbetalning som överskrider det återstående beloppet avvisas med HTTP 400; en beställning accepterar högst 50 återbetalningar. När den återbetalade summan når beställningsbeloppet markeras beställningen som återbetald.

Återbetalningar minskar nettointäkterna under den ursprungliga beställningens period, inte under återbetalningsdatumets period. En junibeställning som återbetalas i juli sänker junis netto; juli visar inget för den. Granska intervallet som innehåller beställningen.

Härledd attribution

För en beställning med en känd besökare läser Seean den besökarens besök under de 90 dagarna före beställningens tidsstämpel:

• Touches (Kontakter): antalet besök i det fönstret.
• First source och Last source (Första och sista källa): hänvisaren eller utm_source för det första och sista besöket; Direct när inget av dem finns.
• Landing page (Landningssida): ingångssidan för det första besöket.
• Time to buy (Tid till köp): från starten av det första besöket till beställningen.
• Campaign (Kampanj): kampanjen din integration anger; annars utm_campaign för det senaste taggade besöket.

Om besökaren inte har något spårat besök i fönstret används den första källan, sista källan, kontakterna och tiden till köp som din integration anger, och beställningen räknas som attribuerad bara när den anger en besökare och en landningssökväg. Beställningar som skickas utan besökar-ID är Unattributed (ej attribuerade). Beställningar som registrerades innan härledd attribution fanns efterfylls en gång från besökarens spårade besök; en kampanj som din integration angav behålls.

Attributionsgränser

Mottagningen av beställningar accepterar historiker på upp till 2 000 matchande händelser inom 90-dagarsfönstret. Den undersöker högst 2 001 rader för att upptäcka överskott, med en läsbudget på 1 MiB. En komplett sparad resa kan uppta upp till 64 KiB. Gränserna gäller varje beställnings besökarhistorik, inte webbplatsens totala trafik. Seean sparar varje kontakt när hela historiken ryms; den kastar inte längre besök efter det trettionde.

Om historiken överskrider en gräns registreras beställningen och återbetalningarna ändå exakt. Intäktsrapporten visar ett meddelande om ofullständig historik och en fördelningsrad Incomplete history (Ofullständig historik) i stället för att tilldela kredit från en del av resan. Dessa beställningar bidrar inte till attribuerade intäkter eller genomsnittlig tid till köp; de stannar i de monetära totalerna och i attributionsgradens nämnare. Rapporten räknar berörda beställningar för sin valda valuta och period, inklusive helt återbetalda. Att ändra fönstret återställer inte historik som inte kunde fångas vid mottagningen.

Äldre förkortade resor markeras också som ofullständiga tills deras fullständiga historik kan återställas. Befintliga sparade rapportresultat bevaras. Historiker utan spårade besök behåller den integrationslevererade attributionen som beskrivs ovan; de är skilda från en historik som överskred en gräns. Automatisk berikning bortom dessa gränser är för närvarande inte tillgänglig.

Ignorera kass- och tacksidesbesök

En återkomst från betalleverantören startar ofta ett nytt besök på din tacksida eller kassasida, vilket skulle ta krediten för sista kontakt. Under Settings → Exclusions → Revenue attribution only (Inställningar → Undantag → Endast intäktsattribution) lägger administratörer och ägare till upp till 20 sökvägsregler med syntaxen för trafikundantag (/thanks exakt, eller /checkout/* för ett prefix). Besök som börjar på en matchande sökväg tas bort från beställningens kontakter innan fönstret och modellen tillämpas; om ingen kontakt återstår är beställningen Unattributed. Inget tas bort: trafiken, sidorna i Översikt och varje annan rapport behåller de besöken, och den konverterande sidan visar fortfarande den sökväg din integration angav. Reglerna gäller bara nya beräkningar - rapporterna Intäkter och Översikt startar en ny analys när en regel ändras, medan redan sparade resultat, redan beräknade schemalagda rapporter och API-resultat förblir som de var; nästa API-begäran beräknar med de nya reglerna. Beställningar utan besökshistorik (skickade utan besökar-ID, eller äldre än härledd attribution) kan inte filtreras; rapporten räknar dem under meddelandet om regler.

Intäktsrapport

Öppna Revenue (Intäkter) i webbplatsens sidopanel. Dess tabeller håller varje värde på en rad; på smala skärmar rullar en tabell i sidled inuti sitt kort och långa köpresor kortas med en ellips (håll muspekaren över för hela vägen). Verktygsfältet har datumintervallet plus attributionskontrollerna:

• Attribution model (Attributionsmodell): First touch (Första kontakt) krediterar det första besöket i fönstret, Last touch (Sista kontakt) besöket som ledde till beställningen, Linear (Linjär) delar beställningen jämnt mellan dess besök.
• Attribution lookback (Attributionsfönster): 7, 14, 30 eller 90 dagar före beställningen. Ett besök äldre än fönstret är inte en kontakt. Kompletta sparade besök används för modellkredit, med förbehåll för attributionsgränserna ovan.
• Website default (Webbplatsens standard): sidan öppnas med webbplatsens sparade modell och fönster (sista kontakt, 30 dagar tills något sparats). När ditt val skiljer sig ser administratörer och ägare Save as website default (Spara som webbplatsens standard); standarden delas med intäktskrediten i Översikt, analys-API:et och MCP get_revenue, och med varje kollega. Ett val i URL:en vinner alltid för den vyn. Overview: net / gross (Översikt: netto / brutto) väljer vad nyckeltalet i Översikt visar (se nyckeltal); demowebbplatsen kan inte ändra dessa inställningar.

Den övre remsan visar brutto, återbetalningar (med antalet återbetalningar), netto, attribuerade intäkter, attributionsgrad och genomsnittlig tid till köp. Attribution breakdown (Attributionsfördelning) har fem flikar: Landing pages, Converting pages, First source, Last source och Sources (Landningssidor, Konverterande sidor, Första källa, Sista källa och Källor). Källor krediterar varje källa enligt den valda modellen, så med Linjär visas en beställning en gång under var och en av sina källor med en andel av sitt nettobelopp. Revenue by product (Intäkter per produkt) listar beställningar, intäkter, andel och den attribuerade delen. Touches before purchase (Kontakter före köp) grupperar beställningar efter härlett antal kontakter. Purchase journeys (Köpresor) grupperar betalda beställningar efter ingångssidan för varje besök inom fönstret, äldst först (/ → /pricing → /checkout): på varandra följande upprepningar slås ihop, bara de sista sex stegen behålls bakom en ellips, en sökväg som din integration anger ersätter den härledda resan, och beställningar utan besökshistorik visar sin landningssida. Resor är besökens ingångssidor, inte varje visad sida.

Orders (Beställningar) listar periodens beställningar nyast först, tjugo åt gången med Load more (Läs in fler), bara i rapporteringsvalutan: tid (håll muspekaren över för det exakta ögonblicket i din visningstidszon), produkt med märkena Refunded (Återbetald) eller Partially refunded −belopp (Delvis återbetald), första källa, resa och belopp enligt vald modell och valt fönster. Beställningar med ofullständig historik visar Incomplete history. Refunds (Återbetalningar) listar varje återbetalning för de beställningarna - återbetalningstid, beställnings-ID (eller beställningstid), produkt, återbetalnings-ID och belopp - också tjugo åt gången; en full återbetalning som registrerades innan återbetalningsliggare fanns visas en gång som legacy. Återbetalningar räknas alltid i sin beställnings period, både här och i totalerna. Läsare kan läsa båda listorna; råa exporter ligger kvar under Settings → Data.

Att ändra modell eller fönster startar en ny analys för samma intervall; befintliga resultat och lagrade beställningar skrivs inte om.

Jämför perioder

Jämförelseknappen bredvid datumintervallet erbjuder samma val som Översikt: Previous period, Previous week, Previous month, Previous quarter, Previous year, Custom range… och No comparison (se datumintervall och filter). Med en aktiv jämförelse visar varje nyckeltal i den övre remsan sin procentuella förändring mot jämförelseintervallet i stället för sitt antal: brutto, återbetalningar, netto, attribuerade intäkter, attributionsgrad och tid till köp. En ökning av återbetalningar eller tid till köp visas som en försämring. Previous period beräknas i samma analys; andra val startar en extra intäktsanalys med samma modell, fönster och rapporteringsvaluta. Fördelningstabeller, produkter, kontakter, resor, beställningar och återbetalningar förblir vyer för aktuell period, och All time har ingen jämförelse.

Attributionsöverlämning

Oavsett om en anslutning eller din server registrerar beställningen är kopplingen till besöket besökar-ID:t. Med en anslutning bifogar du seean_visitor_id (och valfritt seean_landing_path, seean_converting_path, seean_campaign) från window.seean.attribution() till leverantörens kassametadata, anpassade data, varukorgsattribut eller prenumerantattribut så som leverantörsguiden visar; Seean läser de nycklarna från den verifierade händelsen. Den publika spårningstoken auktoriserar aldrig mottagning av beställningar.

För en egen integration fångar du window.seean?.attribution?.() när det är tillgängligt under skapandet av kassan och skickar bara de fält som stöds till din server. Lagra dem med kassans/beställningens referens så att den senare verifierade betalningshändelsen kan använda dem. Hjälpfunktionen kan saknas före inläsning eller returnera ingen attribution när insamlingen är inaktiverad. Acceptera en ej attribuerad beställning i så fall; hitta inte på besökar- eller kampanjvärden.

Efter att spåraren lästs in, vänta på window.seean?.ready innan du läser attribution. Det slutförs efter det initiala insamlingsförsöket eller dess tidsgräns; det garanterar inte att ett besökar-ID finns. Använd det i din asynkrona kassahanterare och låt kassan fortsätta utan attribution. Varje leverantörsexempel innehåller väntan.

Standardbesökarhashen ändras vid midnatt UTC och är begränsad till en webbplats. 90-dagarsfönstret söker poster som bär den fångade identifieraren; det kopplar inte ihop besökarens olika dagliga hashar. Bevara attributionen från kassatillfället för fördröjda betalningswebhooks. En senare återkomst på en ny UTC-dag har en ny identitet, så resor över flera dagar återskapas inte. Äldre beställningar och sparade resultat behåller sina ursprungliga identifierare och värden.

Behåll stabila externa beställningsidentifierare över omförsök. Vidarebefordra återkommande betalningar som de separata betalda beställningar de representerar, och mappa varje återbetalning till det ursprungliga externa beställnings-ID:t med leverantörens återbetalnings-ID. Din integration måste hantera leverantörens händelseordning och dubbletter. Konvertera leverantörens belopp till webbplatsens rapporteringsvalutas minsta enhet bara när betalningen faktiskt debiterades i den valutan; Seean avvisar andra valutor i stället för att konvertera dem.

Verifiera din integration

Använd leverantörens testmöjligheter och en separat Seean-testwebbplats där det är möjligt. Verifiera en betald beställning, ett identiskt omförsök, en partiell återbetalning, en full återbetalning och en beställning utan attribution. Kontrollera webbplatsens intäktsrapport mot de exakta beloppen och den härledda attributionen. En lyckad spårarbegäran eller ett besök på bekräftelsesidan bevisar inte att beställningen togs emot.

Integrationsreferens

Följ Beställnings-API och återbetalningar för nyttolaster, hantering av servernyckel, valutaregler, återbetalningsregler och omförsöksbeteende. Leverantörstillgänglighet sammanfattar vilka leverantörer som har en inbyggd anslutning.

Leverantörsguider

Varje guide täcker leverantörens installationssteg, attributionskodavsnittet för dess kassa, vad som registreras, återbetalningar, valuta, verifiering och begränsningar.

Spårad besökarhistorik fångas en gång när en ny beställning accepteras, genom antingen beställnings-API:et eller en leverantörsanslutning som stöds. Ett tillfälligt fel vid historikuppslagning returnerar ett svar som kan försökas igen; en accepterad dubblett behåller den ursprungliga attributionen och det exakta beloppet. Se omförsök för beställnings-API:et.

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

Är något oklart? Kontakta supporten.