Attribution des revenus

Reliez les commandes vérifiées au trafic et aux campagnes qui les ont produites.

Les commandes parviennent à Seean de deux façons : un connecteur natif reçoit les webhooks signés d’un prestataire de paiement, ou votre serveur envoie les commandes et remboursements vérifiés à l’API de commandes de Seean. Chaque site web rapporte dans une devise que vous choisissez. Lorsqu’une commande nomme un visiteur connu de Seean, l’attribution (contacts, première et dernière source, page d’atterrissage, délai d’achat) est dérivée sur le serveur à partir des visites suivies de ce visiteur dans les 90 jours précédant la commande. Les champs fournis par votre intégration ne servent que pour les visiteurs sans visites suivies.

Connecter un prestataire de paiement

Ouvrez Settings → Integrations → Payment providers (Paramètres → Intégrations → Prestataires de paiement) sur votre propre site web et sélectionnez Enable (Activer) sous Creem, Mollie, Paddle, Polar, RevenueCat, Revolut, Shopify, Stripe, Superwall ou Whop. Le panneau liste les étapes de configuration, l’URL de webhook du site web pour ce prestataire (https://events.seean.io/api/connect/<provider>/<site ID>) et les événements à activer ; collez le secret de signature du prestataire et Seean vérifie chaque livraison avant de l’enregistrer. Pour Stripe, Polar et Paddle, Quick connect (Connexion rapide) crée plutôt le webhook à partir d’une clé API collée une fois ; la clé n’est pas conservée. Après Save secret (Enregistrer le secret), le champ se vide par sécurité et la ligne en dessous indique Secret saved (ends in …) avec les quatre derniers caractères, pour que vous puissiez confirmer que le bon secret est enregistré ; collez une nouvelle valeur uniquement pour le remplacer. Les commandes payées et les remboursements arrivent ensuite automatiquement, et la ligne d’état affiche le dernier événement et toute erreur. Une connexion ou déconnexion échouée affiche la raison du serveur, y compris les secondes d’attente lorsque la requête a été limitée. Les guides des prestataires ci-dessous donnent pour chaque prestataire les étapes, l’extrait d’attribution, le comportement des remboursements et des devises, et les limites.

Stripe propose en plus, après connexion, une section distincte réservée au propriétaire : Optional Stripe payment reads (Lectures de paiement Stripe facultatives). Un contrôle de consentement, décoché au départ, autorise explicitement la conservation d’une clé de lecture restreinte pour la facture, les paiements et les remboursements initiaux exacts de Checkout — pas les renouvellements ni un rattrapage historique. La clé n’est jamais préremplie ni renvoyée ; seul le propriétaire voit l’état activé, le mode test/production, le compte et le suffixe. Le remplacement exige un nouveau consentement. Remove read key (Retirer la clé de lecture) laisse intacts le webhook, les commandes et les liens de paiement existants. Une reconnexion rapide/manuelle retire l’accès en lecture conservé, tandis que la clé de connexion rapide reste utilisée une fois puis écartée. Les contrôles démo/occupés sont désactivés ; les actions réussies et les changements de prestataire effacent la clé de lecture saisie. Voir le guide Stripe pour les permissions, les vérifications de remboursements réussis, le lien événement signé/relecture et la récupération bornée explicite en session unique. Cette livraison du code source ne confirme ni un déploiement en production ni une récupération historique en direct.

Récupération des livraisons

Un connecteur natif renvoie 503 lorsqu’un remboursement arrive avant sa commande (jusqu’à un jour après la création du remboursement ; ensuite le remboursement est accusé et ignoré), lorsqu’une recherche de commande Revolut échoue, ou lorsque l’ingestion est temporairement indisponible. Les limites de débit renvoient 429. Ces réponses laissent la livraison éligible aux nouvelles tentatives du prestataire ; Seean ne tient pas de seconde file de webhooks. Une fois la commande d’origine enregistrée, rejouer le remboursement avec le même identifiant de remboursement l’applique une seule fois.

Consultez Settings → Integrations → Payment providers pour l’heure de la dernière livraison et l’erreur de correspondance ou de recherche enregistrée. Corrigez les identifiants ou les données de paiement invalides à leur source. Une livraison réussie ultérieure efface la dernière erreur ; vérifiez donc aussi les livraisons échouées dans le tableau de bord du prestataire. Les événements non pris en charge et les erreurs permanentes de charge utile/devise sont accusés avec 200 ; les commandes rejetées ne sont pas enregistrées.

Les calendriers de nouvelles tentatives et l’expiration sont contrôlés par chaque prestataire. Si les tentatives de livraison expirent, utilisez ses contrôles de renvoi lorsqu’ils existent, ou envoyez la commande/le remboursement vérifié via l’API de commandes avec les identifiants d’origine. Les échecs déjà accusés ne sont pas rejoués automatiquement par ce changement. Les lectures facultatives de Stripe peuvent établir des liens de paiement initial à partir d’événements Checkout signés nouvellement livrés ou de relectures exactes ; activer la clé ne lance pas de récupération historique. Les propriétaires authentifiés peuvent demander séparément un essai à blanc de réconciliation en session unique, puis une application explicite via une intégration personnalisée ; il n’existe aucune exécution automatique ou à l’échelle du site. Les arrangements multi-factures/crédits non pris en charge et les références manquantes nécessitent une vérification. Ne créez jamais un nouvel identifiant de commande simplement pour réessayer un paiement.

Envoyer des commandes depuis votre serveur

Ouvrez Settings → Integrations → Revenue (Revenus), puis dépliez Custom server integration (Order API) (Intégration serveur personnalisée) pour choisir la devise de rapport et créer un secret d’API de commandes. Utilisez votre serveur ou votre gestionnaire de webhooks de paiement pour envoyer les commandes vérifiées au point de terminaison affiché. Gardez le secret sur votre serveur ; ne l’incluez pas dans le code navigateur. Il s’agit d’une intégration personnalisée, pas d’une connexion automatique à chaque prestataire de paiement.

Le traqueur expose window.seean.attribution() avec l’identifiant du visiteur, le chemin d’atterrissage, le chemin de conversion et la campagne. Transmettez ces champs à votre serveur avec la commande : l’identifiant du visiteur est ce qui relie la commande aux visites de l’acheteur. Sans lui, la commande est enregistrée comme non attribuée. Ne transmettez les événements de paiement qu’après les avoir vérifiés auprès de votre prestataire.

Devise de rapport

Chaque site web a une seule devise de rapport. Ouvrez la liste déroulante sous Reporting currency (Devise de rapport) dans la carte d’intégration des revenus et choisissez un code ISO 4217 (USD par défaut) ; la sélection s’enregistre automatiquement. Les montants sont envoyés en unités mineures de cette devise : 2900 vaut 29,00 USD, le JPY n’a pas d’unité mineure donc 2900 vaut 2 900 JPY, et le KWD utilise trois décimales donc 2900 vaut 2,900 KWD. Une commande dans toute autre devise est rejetée avec HTTP 400 et le message Order currency EUR does not match the website's reporting currency USD (avec les codes concernés). Seean ne convertit pas les devises.

Changer la devise de rapport ne convertit pas les commandes déjà envoyées. Les analyses les comptent comme exclues, et la page Revenus affiche un avis tel que « 3 commandes utilisent une autre devise et sont exclues des totaux en USD ». Seules les commandes dans la devise de rapport actuelle forment les totaux.

Remboursements

Les remboursements forment un registre par commande. Un remboursement peut couvrir la totalité du montant restant ou un amount partiel, porte éventuellement votre refundId pour dédupliquer les nouvelles tentatives, et peut porter son propre horodatage. Un remboursement supérieur au montant restant est rejeté avec HTTP 400 ; une commande accepte au plus 50 remboursements. Dès que le total remboursé atteint le montant de la commande, celle-ci est marquée remboursée.

Les remboursements réduisent les revenus nets dans la période de la commande d’origine, pas dans la période de la date du remboursement. Une commande de juin remboursée en juillet baisse le net de juin ; juillet n’affiche rien pour elle. Consultez la plage qui contient la commande.

Attribution dérivée

Pour une commande avec un visiteur connu, Seean lit les visites de ce visiteur dans les 90 jours précédant l’horodatage de la commande :

• Contacts : le nombre de visites dans cette fenêtre.
• Première source et Dernière source : le référent ou utm_source de la première et de la dernière visite ; Direct quand il n’y a ni l’un ni l’autre.
• Page d’atterrissage : la page d’entrée de la première visite.
• Délai d’achat : du début de la première visite à la commande.
• Campagne : la campagne fournie par votre intégration ; sinon l’utm_campaign de la visite balisée la plus récente.

Si le visiteur n’a aucune visite suivie dans la fenêtre, la première source, la dernière source, les contacts et le délai d’achat fournis par votre intégration sont utilisés, et la commande ne compte comme attribuée que lorsqu’elle nomme un visiteur et un chemin d’atterrissage. Les commandes envoyées sans identifiant de visiteur sont Non attribuées. Les commandes enregistrées avant l’existence de l’attribution dérivée sont complétées une fois à partir des visites suivies de leur visiteur ; une campagne fournie par votre intégration est conservée.

Limites de capture des parcours

L’ingestion des commandes accepte des historiques allant jusqu’à 2 000 événements correspondants dans la fenêtre de 90 jours. Elle sonde au plus 2 001 lignes pour détecter un dépassement, avec un budget de lecture de 1 Mio. Un parcours complet enregistré peut occuper jusqu’à 64 Kio. Ces limites s’appliquent à l’historique du visiteur de chaque commande, pas au trafic total d’un site web. Seean enregistre chaque contact lorsque l’historique complet tient ; il n’écarte plus les visites après la trentième.

Si l’historique dépasse une limite, la commande et les remboursements sont tout de même enregistrés exactement. Le rapport Revenus affiche un avis d’historique incomplet et une ligne de répartition Incomplete history (Historique incomplet) au lieu d’attribuer un crédit à partir d’une partie du parcours. Ces commandes ne contribuent ni aux revenus attribués ni au délai d’achat moyen ; elles restent dans les totaux monétaires et dans le dénominateur du taux d’attribution. Le rapport compte les commandes concernées pour la devise et la période sélectionnées, y compris celles entièrement remboursées. Changer la fenêtre ne récupère pas l’historique qui n’a pas pu être capturé à l’ingestion.

Les anciens parcours raccourcis sont aussi marqués incomplets jusqu’à ce que leur historique complet puisse être récupéré. Les résultats de rapport déjà enregistrés sont préservés. Les historiques sans visites suivies conservent l’attribution fournie par l’intégration décrite ci-dessus ; ils se distinguent d’un historique ayant dépassé une limite. Un enrichissement automatique au-delà de ces bornes n’est pas disponible actuellement.

Ignorer les visites de paiement et de remerciement

Un retour depuis le prestataire de paiement démarre souvent une nouvelle visite sur votre page de remerciement ou de paiement, qui prendrait le crédit du dernier contact. Sous Settings → Exclusions → Revenue attribution only (Attribution des revenus uniquement), les administrateurs et propriétaires ajoutent jusqu’à 20 règles de chemin avec la syntaxe des exclusions de trafic (/thanks exactement, ou /checkout/* pour un préfixe). Les visites qui entrent par un chemin correspondant sont retirées des contacts de la commande avant l’application de la fenêtre et du modèle ; s’il ne reste aucun contact, la commande est Non attribuée. Rien n’est supprimé : le trafic, les pages de la vue d’ensemble et tous les autres rapports conservent ces visites, et la page de conversion affiche toujours le chemin fourni par votre intégration. Les règles ne s’appliquent qu’aux nouveaux calculs : les rapports Revenus et Vue d’ensemble démarrent une nouvelle analyse lorsqu’une règle change, tandis que les résultats déjà enregistrés, les rapports programmés déjà calculés et les résultats de l’API restent tels quels ; la prochaine requête API calcule avec les nouvelles règles. Les commandes sans historique de visite (envoyées sans identifiant de visiteur, ou antérieures à l’attribution dérivée) ne peuvent pas être filtrées ; le rapport les compte sous l’avis des règles.

Rapport Revenus

Ouvrez Revenue (Revenus) dans la barre latérale du site web. Ses tableaux gardent chaque valeur sur une ligne ; sur les écrans étroits, un tableau défile latéralement dans sa carte et les longs parcours d’achat sont raccourcis par des points de suspension (survolez pour le chemin complet). La barre d’outils comporte la plage de dates et les contrôles d’attribution :

• Attribution model (Modèle d’attribution) : First touch (Premier contact) crédite la première visite de la fenêtre, Last touch (Dernier contact) la visite qui a mené à la commande, Linear (Linéaire) répartit la commande à parts égales entre ses visites.
• Attribution lookback (Fenêtre d’attribution) : 7, 14, 30 ou 90 jours avant la commande. Une visite plus ancienne que la fenêtre n’est pas un contact. Les visites complètes enregistrées servent au crédit du modèle, sous réserve des limites de capture ci-dessus.
• Valeur par défaut du site web : la page s’ouvre avec le modèle et la fenêtre enregistrés du site web (dernier contact, 30 jours jusqu’à ce qu’une valeur soit enregistrée). Lorsque votre sélection diffère, les administrateurs et propriétaires voient Save as website default (Enregistrer comme valeur par défaut du site web) ; la valeur par défaut est partagée avec le crédit de revenus de la vue d’ensemble, l’API d’analyse et le get_revenue MCP, et avec chaque coéquipier. Une sélection dans l’URL l’emporte toujours pour cette vue. Overview: net / gross (Vue d’ensemble : net / brut) choisit ce qu’affiche le KPI de la vue d’ensemble (voir KPI) ; le site web de démonstration ne peut pas modifier ces paramètres.

Le bandeau supérieur affiche le brut, les remboursements (avec leur nombre), le net, les revenus attribués, le taux d’attribution et le délai d’achat moyen. Attribution breakdown (Détail de l’attribution) a cinq onglets : Landing pages (Pages d’atterrissage), Converting pages (Pages de conversion), First source (Première source), Last source (Dernière source) et Sources. Sources crédite chaque source selon le modèle sélectionné ; avec Linéaire, une commande apparaît donc une fois sous chacune de ses sources avec une part de son montant net. Revenue by product (Revenus par produit) liste les commandes, les revenus, la part et la portion attribuée. Touches before purchase (Contacts avant l’achat) répartit les commandes par nombre de contacts dérivés. Purchase journeys (Parcours d’achat) regroupe les commandes payées par la page d’entrée de chaque visite dans la fenêtre, la plus ancienne d’abord (/ → /pricing → /checkout) : les répétitions consécutives sont regroupées, seules les six dernières étapes sont conservées derrière des points de suspension, un chemin fourni par votre intégration remplace le parcours dérivé, et les commandes sans historique de visite affichent leur page d’atterrissage. Les parcours sont des pages d’entrée de visite, pas toutes les pages vues.

Orders (Commandes) liste les commandes de la période, les plus récentes d’abord, vingt à la fois avec Load more (Charger plus), dans la devise de rapport uniquement : heure (survolez pour le moment exact dans votre fuseau horaire d’affichage), produit avec les badges Refunded (Remboursé) ou Partially refunded −montant (Partiellement remboursé), première source, parcours et montant selon le modèle et la fenêtre sélectionnés. Les commandes à l’historique incomplet affichent Incomplete history. Refunds (Remboursements) liste chaque remboursement de ces commandes — heure du remboursement, identifiant de commande (ou heure de commande), produit, identifiant de remboursement et montant — aussi vingt à la fois ; un remboursement total enregistré avant l’existence des registres de remboursement apparaît une fois sous legacy. Les remboursements comptent toujours dans la période de leur commande, ici comme dans les totaux. Les lecteurs peuvent lire les deux listes ; les exports bruts restent sous Settings → Data (Données).

Changer le modèle ou la fenêtre démarre une nouvelle analyse pour la même plage ; les résultats existants et les commandes stockées ne sont pas réécrits.

Comparer des périodes

Le bouton de comparaison à côté de la plage de dates propose les mêmes choix que la vue d’ensemble : Previous period, Previous week, Previous month, Previous quarter, Previous year, Custom range… et No comparison (voir plages de dates et filtres). Avec une comparaison active, chaque KPI du bandeau supérieur affiche sa variation en pourcentage par rapport à l’intervalle de comparaison au lieu de son nombre : brut, remboursements, net, revenus attribués, taux d’attribution et délai d’achat. Une hausse des remboursements ou du délai d’achat est affichée comme une baisse. Période précédente est calculée dans la même analyse ; les autres choix démarrent une analyse de revenus supplémentaire avec les mêmes modèle, fenêtre et devise de rapport. Les tableaux de détail, produits, contacts, parcours, commandes et remboursements restent des vues de la période en cours, et All time (Depuis le début) n’a pas de comparaison.

Transmission de l’attribution

Qu’un connecteur ou votre serveur enregistre la commande, le lien avec la visite est l’identifiant du visiteur. Avec un connecteur, attachez seean_visitor_id (et éventuellement seean_landing_path, seean_converting_path, seean_campaign) issus de window.seean.attribution() aux métadonnées de checkout, données personnalisées, attributs de panier ou attributs d’abonné du prestataire, comme le montre son guide ; Seean lit ces clés dans l’événement vérifié. Le jeton de suivi public n’autorise jamais l’ingestion de commandes.

Pour une intégration personnalisée, capturez window.seean?.attribution?.() lorsqu’il est disponible pendant la création du checkout et ne transmettez à votre serveur que les champs pris en charge. Stockez-les avec la référence du checkout/de la commande pour que l’événement de paiement vérifié ultérieur puisse les utiliser. L’assistant peut être absent avant le chargement ou ne renvoyer aucune attribution lorsque la collecte est désactivée. Acceptez une commande non attribuée dans ce cas ; n’inventez pas de valeurs de visiteur ou de campagne.

Après le chargement du traqueur, attendez window.seean?.ready avant de lire l’attribution. Il se termine après la tentative de collecte initiale ou son délai d’expiration ; il ne garantit pas qu’un identifiant de visiteur existe. Utilisez-le dans votre gestionnaire de checkout asynchrone et laissez le paiement continuer sans attribution. Chaque exemple de prestataire inclut cette attente.

L’empreinte de visiteur par défaut change à minuit UTC et est limitée à un site web. La fenêtre de 90 jours recherche les enregistrements portant l’identifiant capturé ; elle ne joint pas les différentes empreintes quotidiennes de ce visiteur. Préservez l’attribution capturée au moment du checkout pour les webhooks de paiement différés. Un retour ultérieur un nouveau jour UTC a une nouvelle identité ; les parcours sur plusieurs jours ne sont donc pas reconstitués. Les anciennes commandes et les résultats enregistrés conservent leurs identifiants et valeurs d’origine.

Gardez des identifiants de commande externes stables entre les tentatives. Transmettez les paiements récurrents comme les commandes payées distinctes qu’ils représentent, et associez chaque remboursement à l’identifiant de commande externe d’origine avec l’identifiant de remboursement du prestataire. Votre intégration doit tenir compte de l’ordre des événements et des doublons du prestataire. Convertissez les montants du prestataire en unités mineures de la devise de rapport du site web uniquement lorsque le paiement a réellement été débité dans cette devise ; Seean rejette les autres devises plutôt que de les convertir.

Vérifier votre intégration

Utilisez les outils de test de votre prestataire et, si possible, un site web Seean de test distinct. Vérifiez une commande payée, une nouvelle tentative identique, un remboursement partiel, un remboursement total et une commande sans attribution. Comparez le rapport Revenus du site web aux montants exacts et à l’attribution dérivée. Une requête de traqueur réussie ou une visite de la page de confirmation ne prouve pas que la commande a été ingérée.

Référence d’intégration

Suivez API de commandes et remboursements pour les charges utiles, la gestion de la clé serveur, les règles de devise, les règles de remboursement et le comportement des nouvelles tentatives. La disponibilité des prestataires résume quels prestataires disposent d’un connecteur natif.

Guides des prestataires

Chaque guide couvre les étapes de configuration du prestataire, l’extrait d’attribution pour son checkout, ce qui est enregistré, les remboursements, la devise, la vérification et les limites.

L’historique des visites suivies est capturé une fois lorsqu’une nouvelle commande est acceptée, via l’API de commandes ou un connecteur de prestataire pris en charge. Un échec temporaire de recherche d’historique renvoie une réponse réessayable ; un doublon accepté conserve l’attribution d’origine et le montant exact. Voir nouvelles tentatives de l’API de commandes.

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

Quelque chose n'est pas clair ? Contacter le support.