Omzetattributie

Koppel geverifieerde bestellingen aan het verkeer en de campagnes erachter.

Bestellingen bereiken Seean op twee manieren: een eigen connector ontvangt de ondertekende webhooks van een betaalprovider, of uw server stuurt geverifieerde bestellingen en terugbetalingen naar de bestel-API van Seean. Elke website rapporteert in één valuta die u kiest. Wanneer een bestelling een bezoeker noemt die Seean kent, wordt de attributie (contacten, eerste en laatste bron, landingspagina, tijd tot aankoop) op de server afgeleid uit de gemeten bezoeken van die bezoeker in de 90 dagen vóór de bestelling. Velden die uw integratie aanlevert, worden alleen gebruikt voor bezoekers zonder gemeten bezoeken.

Een betaalprovider koppelen

Open Settings → Integrations → Payment providers (Instellingen → Integraties → Betaalproviders) op uw eigen website en kies Enable (Inschakelen) onder Creem, Mollie, Paddle, Polar, RevenueCat, Revolut, Shopify, Stripe, Superwall of Whop. Het paneel toont de installatiestappen, de webhook-URL van de website voor die provider (https://events.seean.io/api/connect/<provider>/<site ID>) en de gebeurtenissen om in te schakelen; plak het ondertekeningsgeheim van de provider en Seean verifieert elke levering voordat die wordt opgeslagen. Voor Stripe, Polar en Paddle maakt Quick connect (Snel koppelen) de webhook in plaats daarvan aan vanuit een API-sleutel die u één keer plakt; de sleutel wordt niet opgeslagen. Na Save secret (Geheim opslaan) wordt het veld om veiligheidsredenen leeggemaakt en de regel eronder toont Secret saved (ends in …) (Geheim opgeslagen, eindigt op …) met de laatste vier tekens, zodat u kunt bevestigen dat het juiste geheim is opgeslagen; plak alleen een nieuwe waarde om het te vervangen. Betaalde bestellingen en terugbetalingen komen daarna automatisch binnen, en de statusregel toont de laatste gebeurtenis en eventuele fout. Een mislukte koppeling of ontkoppeling toont de reden van de server, inclusief de seconden om te wachten wanneer het verzoek een snelheidslimiet raakte. De providergidsen hieronder geven per provider de stappen, het attributiefragment, het gedrag voor terugbetalingen en valuta en de limieten.

Stripe biedt na het koppelen bovendien een aparte sectie Optional Stripe payment reads (Optionele Stripe-betalingsreads), alleen voor de eigenaar. Een aanvankelijk niet aangevinkt toestemmingsvakje autoriseert expliciet het bewaren van een beperkte leessleutel voor de exacte initiële Checkout-factuur, betalingen en terugbetalingen - geen verlengingen of backfill. De sleutel wordt nooit vooraf ingevuld of teruggegeven; alleen de eigenaar ziet de ingeschakelde status, test-/livemodus, account en achtervoegsel. Vervangen vereist nieuwe toestemming. Remove read key (Leessleutel verwijderen) laat de webhook, bestellingen en bestaande betaalkoppelingen intact. Snel/handmatig opnieuw koppelen verwijdert de bewaarde leestoegang, terwijl de sleutel voor snel koppelen één keer wordt gebruikt en daarna wordt weggegooid. Demo-/bezet-besturingselementen zijn uitgeschakeld; geslaagde acties en het wisselen van provider wissen de getypte leessleutel. Zie de Stripe-gids voor rechten, controles van geslaagde terugbetalingen, koppeling van ondertekende gebeurtenissen/herhalingen en begrensd expliciet herstel in één sessie. Deze bronlevering bevestigt geen productie-uitrol of live historisch herstel.

Herstel van leveringen

Een eigen connector geeft 503 terug wanneer een terugbetaling vóór de bestelling binnenkomt (tot één dag na het aanmaken van de terugbetaling; daarna wordt de terugbetaling bevestigd en genegeerd), een Revolut-bestelopzoeking mislukt of de verwerking tijdelijk niet beschikbaar is. Snelheidslimieten geven 429 terug. Deze antwoorden houden de levering geschikt voor de nieuwe pogingen van de provider; Seean houdt geen tweede webhookwachtrij bij. Nadat de oorspronkelijke bestelling is opgeslagen, past het opnieuw afspelen van de terugbetaling met dezelfde terugbetalings-ID die één keer toe.

Controleer Settings → Integrations → Payment providers voor de laatste leveringstijd en de geregistreerde toewijzings- of opzoekfout. Corrigeer inloggegevens of ongeldige betaalgegevens bij de bron. Een latere geslaagde levering wist de laatste fout, dus controleer ook mislukte leveringen in het dashboard van de provider. Niet-ondersteunde gebeurtenissen en permanente payload-/valutafouten worden bevestigd met 200; afgewezen bestellingen worden niet opgeslagen.

Schema’s voor nieuwe pogingen en het verlopen daarvan worden door elke provider bepaald. Als leveringspogingen verlopen, gebruik dan de herleveringsfuncties van de provider indien beschikbaar, of stuur de geverifieerde bestelling/terugbetaling via de Order API met de oorspronkelijke identificaties. Eerder bevestigde mislukkingen worden door deze wijziging niet automatisch opnieuw afgespeeld. De optionele reads van Stripe kunnen koppelingen voor de initiële betaling leggen vanuit nieuw geleverde ondertekende Checkout-gebeurtenissen of exacte herhalingen; het inschakelen van de sleutel start geen historisch herstel. Geverifieerde eigenaren kunnen apart een proefafstemming in één sessie en daarna een expliciete toepassing aanvragen via een eigen integratie; er is geen automatische of website-brede uitvoering. Niet-ondersteunde regelingen met meerdere facturen/credits en ontbrekende referenties vereisen controle. Maak nooit een nieuwe bestel-ID aan alleen om een betaling opnieuw te proberen.

Bestellingen vanaf uw server versturen

Open Settings → Integrations → Revenue (Instellingen → Integraties → Omzet) en vouw Custom server integration (Order API) (Eigen serverintegratie) uit om de rapportagevaluta te kiezen en een geheim voor de bestel-API aan te maken. Gebruik uw server of de handler van uw betaalwebhook om geverifieerde bestellingen naar het getoonde eindpunt te sturen. Houd het geheim op uw server; neem het niet op in browsercode. Dit is een eigen integratie, geen automatische koppeling met elke afrekenprovider.

De tracker biedt window.seean.attribution() met de bezoekers-ID, het landingspad, het converterende pad en de campagne. Geef die velden met de bestelling door aan uw server: de bezoekers-ID is wat de bestelling aan de bezoeken van de koper koppelt. Zonder die ID wordt de bestelling als niet toegewezen geregistreerd. Stuur betaalgebeurtenissen pas door na verificatie bij uw provider.

Rapportagevaluta

Elke website heeft één rapportagevaluta. Open de keuzelijst onder Reporting currency (Rapportagevaluta) in de kaart Omzetintegratie en kies een ISO 4217-code (standaard USD); de keuze wordt automatisch opgeslagen. Bedragen worden verzonden in de kleinste eenheid van die valuta: 2900 is USD 29,00, JPY heeft geen kleinste eenheid dus 2900 is JPY 2.900, en KWD gebruikt drie decimalen dus 2900 is KWD 2,900. Een bestelling in een andere valuta wordt afgewezen met HTTP 400 en het bericht Order currency EUR does not match the website's reporting currency USD (met de betrokken codes). Seean converteert geen valuta’s.

Het wijzigen van de rapportagevaluta converteert bestellingen die u al hebt verzonden niet. Analyses tellen ze als uitgesloten, en de pagina Omzet toont een melding zoals “3 bestellingen gebruiken een andere valuta en zijn uitgesloten van de USD-totalen.” Alleen de bestellingen in de huidige rapportagevaluta vormen de totalen.

Terugbetalingen

Terugbetalingen zijn een grootboek per bestelling. Een terugbetaling kan het volledige resterende bedrag of een gedeeltelijk amount dekken, draagt optioneel uw refundId zodat nieuwe pogingen worden gededupliceerd, en kan een eigen tijdstempel dragen. Een terugbetaling die het resterende bedrag overschrijdt, wordt afgewezen met HTTP 400; een bestelling accepteert maximaal 50 terugbetalingen. Zodra het terugbetaalde totaal het bestelbedrag bereikt, wordt de bestelling als terugbetaald gemarkeerd.

Terugbetalingen verlagen de netto-omzet in de periode van de oorspronkelijke bestelling, niet in de periode van de terugbetalingsdatum. Een bestelling uit juni die in juli wordt terugbetaald, verlaagt het netto van juni; juli toont er niets voor. Bekijk de periode die de bestelling bevat.

Afgeleide attributie

Voor een bestelling met een bekende bezoeker leest Seean de bezoeken van die bezoeker in de 90 dagen vóór het tijdstempel van de bestelling:

• Contacten: het aantal bezoeken in dat venster.
• Eerste bron en Laatste bron: de verwijzer of utm_source van het eerste en laatste bezoek; Direct wanneer er geen van beide is.
• Landingspagina: de instappagina van het eerste bezoek.
• Tijd tot aankoop: van het begin van het eerste bezoek tot de bestelling.
• Campagne: de campagne die uw integratie aanlevert; anders de utm_campaign van het meest recente getagde bezoek.

Als de bezoeker geen gemeten bezoek in het venster heeft, worden de eerste bron, laatste bron, contacten en tijd tot aankoop die uw integratie aanlevert gebruikt, en telt de bestelling alleen als toegewezen wanneer die een bezoeker en een landingspad noemt. Bestellingen zonder bezoekers-ID zijn Unattributed (Niet toegewezen). Bestellingen die vóór het bestaan van afgeleide attributie zijn geregistreerd, worden één keer aangevuld uit de gemeten bezoeken van hun bezoeker; een campagne die uw integratie aanleverde, blijft behouden.

Attributielimieten

De bestelverwerking accepteert geschiedenissen tot 2.000 overeenkomende gebeurtenissen binnen het venster van 90 dagen. Ze onderzoekt maximaal 2.001 rijen om overloop te detecteren, met een leesbudget van 1 MiB. Een volledig opgeslagen route kan tot 64 KiB innemen. Deze limieten gelden voor de bezoekersgeschiedenis van elke bestelling, niet voor het totale verkeer van een website. Seean slaat elk contact op wanneer de volledige geschiedenis past; bezoeken na het dertigste worden niet meer weggelaten.

Als de geschiedenis een limiet overschrijdt, worden de bestelling en terugbetalingen nog steeds exact geregistreerd. Het rapport Omzet toont een melding over onvolledige geschiedenis en een uitsplitsingsrij Incomplete history (Onvolledige geschiedenis) in plaats van credit toe te wijzen uit een deel van de route. Deze bestellingen dragen niet bij aan toegewezen omzet of de gemiddelde tijd tot aankoop; ze blijven in de geldtotalen en in de noemer van het attributiepercentage. Het rapport telt de betreffende bestellingen voor de geselecteerde valuta en periode, inclusief volledig terugbetaalde. Het wijzigen van de terugblik herstelt geen geschiedenis die bij de verwerking niet kon worden vastgelegd.

Verouderde verkorte routes worden ook als onvolledig gemarkeerd tot hun volledige geschiedenis kan worden hersteld. Bestaande opgeslagen rapportresultaten blijven behouden. Geschiedenissen zonder gemeten bezoeken behouden de hierboven beschreven door de integratie aangeleverde attributie; ze verschillen van een geschiedenis die een limiet overschreed. Automatische aanvulling buiten deze grenzen is momenteel niet beschikbaar.

Afreken- en bedankbezoeken negeren

Een terugkeer van de betaalprovider start vaak een nieuw bezoek op uw bedank- of afrekenpagina, dat de laatste-contactcredit zou krijgen. Onder Settings → Exclusions → Revenue attribution only (Instellingen → Uitsluitingen → Alleen omzetattributie) voegen beheerders en eigenaren tot 20 padregels toe met de syntaxis van verkeersuitsluitingen (/thanks exact, of /checkout/* voor een voorvoegsel). Bezoeken die binnenkomen op een overeenkomend pad worden uit de contacten van de bestelling verwijderd voordat de terugblik en het model worden toegepast; als er geen contact overblijft, is de bestelling Unattributed. Er wordt niets verwijderd: verkeer, Overzichtspagina’s en elk ander rapport behouden die bezoeken, en de converterende pagina toont nog steeds het pad dat uw integratie aanleverde. Regels gelden alleen voor nieuwe berekeningen - de rapporten Omzet en Overzicht starten een nieuwe analyse wanneer een regel verandert, terwijl al opgeslagen resultaten, al berekende geplande rapporten en API-resultaten blijven zoals ze waren; het volgende API-verzoek rekent met de nieuwe regels. Bestellingen zonder bezoekgeschiedenis (verzonden zonder bezoekers-ID, of ouder dan afgeleide attributie) kunnen niet worden gefilterd; het rapport telt ze onder de regelmelding.

Omzetrapport

Open Revenue (Omzet) in de zijbalk van de website. De tabellen houden elke waarde op één regel; op smalle schermen scrolt een tabel zijwaarts binnen de kaart en worden lange aankooproutes afgekort met een beletselteken (beweeg erover voor het volledige pad). De werkbalk heeft de periode plus de attributiebesturing:

• Attribution model (Attributiemodel): First touch (Eerste contact) kent het eerste bezoek binnen de terugblik toe, Last touch (Laatste contact) het bezoek dat tot de bestelling leidde, Linear (Lineair) verdeelt de bestelling gelijk over de bezoeken.
• Attribution lookback (Attributieterugblik): 7, 14, 30 of 90 dagen vóór de bestelling. Een bezoek ouder dan de terugblik is geen contact. Volledig opgeslagen bezoeken worden gebruikt voor modelcredit, onder voorbehoud van de attributielimieten hierboven.
• Website default (Websitestandaard): de pagina opent met het opgeslagen model en de terugblik van de website (laatste contact, 30 dagen tot er een is opgeslagen). Wanneer uw keuze afwijkt, zien beheerders en eigenaren Save as website default (Opslaan als standaard voor de website); de standaard wordt gedeeld met de omzetcredit van het Overzicht, de analytics-API en MCP get_revenue, en met elk teamlid. Een keuze in de URL wint altijd voor die weergave. Overview: net / gross (Overzicht: netto / bruto) kiest wat de Overzichts-KPI toont (zie KPI’s); de demowebsite kan deze instellingen niet wijzigen.

De bovenste strook toont bruto, terugbetalingen (met het aantal terugbetalingen), netto, toegewezen omzet, attributiepercentage en gemiddelde tijd tot aankoop. Attribution breakdown (Attributie-uitsplitsing) heeft vijf tabbladen: Landing pages, Converting pages, First source, Last source en Sources (Landingspagina’s, Converterende pagina’s, Eerste bron, Laatste bron en Bronnen). Bronnen kent elke bron toe volgens het geselecteerde model, dus met Lineair verschijnt een bestelling één keer onder elk van haar bronnen met een aandeel van het nettobedrag. Revenue by product (Omzet per product) toont bestellingen, omzet, aandeel en het toegewezen deel. Touches before purchase (Contacten vóór aankoop) groepeert bestellingen op afgeleid aantal contacten. Purchase journeys (Aankooproutes) groepeert betaalde bestellingen op de instappagina van elk bezoek binnen de terugblik, oudste eerst (/ → /pricing → /checkout): opeenvolgende herhalingen worden samengevouwen, alleen de laatste zes stappen blijven achter een beletselteken, een pad dat uw integratie aanlevert vervangt de afgeleide route, en bestellingen zonder bezoekgeschiedenis tonen hun landingspagina. Routes zijn instappagina’s van bezoeken, niet elke bekeken pagina.

Orders (Bestellingen) toont de bestellingen van de periode, nieuwste eerst, twintig tegelijk met Load more (Meer laden), alleen in de rapportagevaluta: tijd (beweeg erover voor het exacte moment in uw weergavetijdzone), product met de badges Refunded (Terugbetaald) of Partially refunded −bedrag (Gedeeltelijk terugbetaald), eerste bron, route en bedrag volgens het geselecteerde model en de terugblik. Bestellingen met een onvolledige geschiedenis tonen Incomplete history. Refunds (Terugbetalingen) toont elke terugbetaling van die bestellingen - terugbetalingstijd, bestel-ID (of besteltijd), product, terugbetalings-ID en bedrag - ook twintig tegelijk; een volledige terugbetaling die vóór het bestaan van terugbetalingsgrootboeken is geregistreerd, verschijnt één keer als legacy. Terugbetalingen tellen altijd in de periode van hun bestelling, zowel hier als in de totalen. Kijkers kunnen beide lijsten lezen; ruwe exports blijven onder Settings → Data.

Het wijzigen van het model of de terugblik start een nieuwe analyse voor dezelfde periode; bestaande resultaten en opgeslagen bestellingen worden niet herschreven.

Periodes vergelijken

De vergelijkingsknop naast de periode biedt dezelfde keuzes als het Overzicht: Previous period, Previous week, Previous month, Previous quarter, Previous year, Custom range… en No comparison (zie periodes en filters). Met een actieve vergelijking toont elke KPI in de bovenste strook het procentuele verschil ten opzichte van het vergelijkingsinterval in plaats van het aantal: bruto, terugbetalingen, netto, toegewezen omzet, attributiepercentage en tijd tot aankoop. Een stijging van terugbetalingen of tijd tot aankoop wordt als daling getoond. Previous period wordt in dezelfde analyse berekend; andere keuzes starten één extra omzetanalyse met hetzelfde model, dezelfde terugblik en rapportagevaluta. Uitsplitsingstabellen, producten, contacten, routes, bestellingen en terugbetalingen blijven weergaven van de huidige periode, en All time heeft geen vergelijking.

Attributie-overdracht

Of een connector of uw server de bestelling registreert, de koppeling met het bezoek is de bezoekers-ID. Voeg met een connector seean_visitor_id (en optioneel seean_landing_path, seean_converting_path, seean_campaign) uit window.seean.attribution() toe aan de checkout-metadata, custom data, winkelwagenattributen of abonnee-attributen van de provider zoals de providergids toont; Seean leest die sleutels uit de geverifieerde gebeurtenis. Het openbare trackingtoken autoriseert nooit bestelverwerking.

Leg voor een eigen integratie window.seean?.attribution?.() vast wanneer beschikbaar tijdens het aanmaken van de checkout en geef alleen de ondersteunde velden door aan uw server. Sla ze op bij de checkout-/bestelreferentie zodat de latere geverifieerde betaalgebeurtenis ze kan gebruiken. De helper kan vóór het laden ontbreken of geen attributie teruggeven wanneer het verzamelen is uitgeschakeld. Accepteer in dat geval een niet-toegewezen bestelling; verzin geen bezoekers- of campagnewaarden.

Wacht na het laden van de tracker op window.seean?.ready voordat u attributie leest. Dit is voltooid na de eerste verzamelpoging of de time-out ervan; het garandeert niet dat een bezoekers-ID bestaat. Gebruik dit binnen uw asynchrone afrekenhandler en laat het afrekenen doorgaan zonder attributie. Elk providervoorbeeld bevat het wachten.

De standaardbezoekershash verandert om middernacht UTC en is beperkt tot één website. De terugblik van 90 dagen zoekt records die de vastgelegde identificatie dragen; verschillende dagelijkse hashes van die bezoeker worden niet samengevoegd. Bewaar attributie van het afrekenmoment voor vertraagde betaalwebhooks. Een latere terugkeer op een nieuwe UTC-dag heeft een nieuwe identiteit, dus routes over meerdere dagen worden niet gereconstrueerd. Verouderde bestellingen en opgeslagen resultaten behouden hun oorspronkelijke identificaties en waarden.

Houd stabiele externe bestel-ID’s over nieuwe pogingen heen. Stuur terugkerende betalingen door als de afzonderlijke betaalde bestellingen die ze vertegenwoordigen, en koppel elke terugbetaling aan de oorspronkelijke externe bestel-ID met de terugbetalings-ID van de provider. Uw integratie moet rekening houden met de gebeurtenisvolgorde en duplicaten van de provider. Converteer providerbedragen alleen naar de kleinste eenheid van de rapportagevaluta van de website wanneer de betaling daadwerkelijk in die valuta is afgeschreven; Seean wijst andere valuta’s af in plaats van ze te converteren.

Uw integratie controleren

Gebruik de testmogelijkheden van uw provider en waar mogelijk een aparte Seean-testwebsite. Controleer een betaalde bestelling, een identieke nieuwe poging, een gedeeltelijke terugbetaling, een volledige terugbetaling en een bestelling zonder attributie. Vergelijk het rapport Omzet van de website met de exacte bedragen en de afgeleide attributie. Een geslaagd trackerverzoek of een bezoek aan de bevestigingspagina bewijst niet dat de bestelling is verwerkt.

Integratiereferentie

Volg Order API en terugbetalingen voor payloads, omgang met serversleutels, valutaregels, terugbetalingsregels en gedrag bij nieuwe pogingen. Beschikbaarheid van providers vat samen welke providers een eigen connector hebben.

Providergidsen

Elke gids behandelt de installatiestappen van de provider, het attributiefragment voor de checkout, wat wordt geregistreerd, terugbetalingen, valuta, verificatie en limieten.

De gemeten bezoekersgeschiedenis wordt één keer vastgelegd wanneer een nieuwe bestelling wordt geaccepteerd, via de Order API of een ondersteunde providerconnector. Een tijdelijke fout bij het opzoeken van de geschiedenis geeft een antwoord dat opnieuw kan worden geprobeerd; een geaccepteerd duplicaat behoudt de oorspronkelijke attributie en het exacte bedrag. Zie nieuwe pogingen van de 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.

Is iets onduidelijk? Neem contact op met de ondersteuning.