Installation

Connecter votre site à Reylin

Un guide d’installation par étapes pour les événements consentis, l’attribution des paiements ponctuels Stripe Checkout et une connexion vérifiée aux revenus de vos clients.

Avant de commencer

Cette documentation décrit la version locale implémentée, et ne prouve pas l’existence d’un service hébergé opérationnel. Commencez par une installation de préproduction approuvée. L’accès aux prestataires, la livraison des messages, le comportement du navigateur et la persistance du déploiement doivent encore être vérifiés.

Créez un compte et un projet, puis définissez l’origine exacte du site, avec le protocole et le port si nécessaire. L’identifiant public du projet achemine les requêtes de collecte ; ce n’est ni un secret ni un identifiant d’accès aux revenus. La politique de sécurité du contenu de votre site doit autoriser l’hôte d’analyse choisi.

1. Charger le traceur

Remplacez les deux valeurs de substitution par votre hôte approuvé et l’identifiant public du projet. Le simple chargement du script n’envoie aucune page vue.

<script src="https://YOUR-ANALYTICS-HOST/tracker.js"
        data-project="PUBLIC_PROJECT_ID"></script>

2. Relier votre décision de consentement

Appelez ces méthodes depuis votre gestionnaire de consentement après le chargement du script. N’accordez pas d’autorisation simplement parce que cet exemple contient consent(true). N’envoyez que les noms d’événements réellement nécessaires ; ne mettez ni adresses e-mail, ni jetons, ni autres informations sensibles dans les noms d’événements ou les valeurs de campagne.

  • Avant le consentement, track() renvoie consent_required sans envoyer d’événement.
  • L’identifiant du visiteur est limité à la session et n’est stocké qu’après consentement. Son retrait supprime cet identifiant stocké.
  • Configurez une origine autorisée exacte ; les identifiants publics et les contrôles d’origine du navigateur ne constituent pas un dispositif complet contre les abus.
// After the visitor grants the relevant permission:
reylin.consent(true);
await reylin.track('pageview');

// A deliberate application event:
await reylin.track('signup');

// When permission is withdrawn:
reylin.consent(false);

Facultatif : pages vues avec consentement pour une application monopage

Choisissez les pages vues manuelles OU cette politique automatique de routage ; n’envoyez pas les deux pour la même visite. Les pages vues automatiques restent désactivées tant que vous n’avez pas configuré de correspondance explicite. Les chemins exacts et les préfixes terminés par /* correspondent à des libellés statiques non personnels ; n’y placez jamais d’identifiants de clients. Les chaînes de requête et les fragments ordinaires ne deviennent pas des libellés de page. L’attribution catégorielle utm_source existante ne change pas.

La configuration peut précéder le consentement, mais aucun mécanisme d’écoute de navigation, identifiant ou événement n’est créé avant l’accord. Un nouvel accord n’enregistre que la page actuelle configurée, jamais l’historique refusé. GPC=true bloque l’accord et la collecte ; il est vérifié lors des opérations du traceur et de la navigation, pas au moyen d’un événement de changement du navigateur inventé. Le retrait arrête les mécanismes d’écoute et interrompt les requêtes en attente lorsque cela est pris en charge ; les événements déjà transmis ne peuvent pas être rappelés.

  • pushState, replaceState et les commandes précédent/suivant sont pris en charge ; les routeurs hash observent aussi hashchange. Les notifications en double et les changements portant uniquement sur la requête n’ajoutent pas d’événements automatiques.
  • Des chemins concrets différents peuvent correspondre à un même libellé statique et compter malgré tout comme des navigations distinctes. Les chemins sans correspondance ne sont pas envoyés.
  • initial:false ignore la page courante à chaque installation ou accord ; les changements ultérieurs de routes configurées sont collectés. Aucun nouvel essai automatique ni rejeu hors ligne n’est ajouté.
  • Les méthodes du routeur conservent leurs valeurs de retour, arguments et exceptions natifs. L’arrêt restaure uniquement les wrappers appartenant au traceur et préserve ceux installés ensuite par un autre code. Une validation réelle du framework et du navigateur reste nécessaire.
// Configure once after the script loads; this does NOT grant consent.
reylin.startPageviews({
  mode: 'history', // use 'hash' for #/pricing-style routers
  routes: {'/':'/', '/pricing':'/pricing', '/docs/*':'/docs'},
  initial: true
});
// Later, only after the visitor permits collection:
reylin.consent(true);
// Stop automatic navigation only (does not withdraw consent):
reylin.stopPageviews();
// Withdraw all tracking consent:
reylin.consent(false);

3. Associer un paiement ponctuel sur votre serveur

L’exemple ci-dessous illustre une structure côté serveur, pas un endpoint de paiement complet. Obtenez l’association consentie du visiteur via votre propre parcours applicatif validé. Gardez la sélection des prix, les identifiants d’accès et la propriété du projet sous contrôle du serveur. Omettez l’association si elle est indisponible ; n’en inventez pas.

  • Les métadonnées de Session et celles de PaymentIntent sont distinctes.
  • N’envoyez pas de clés secrètes ou restreintes Stripe au navigateur.
  • Les renouvellements d’abonnement nécessitent une association client persistante distincte ; cet exemple de paiement ponctuel ne l’implémente pas.
const metadata = consentedVisitorId
  ? { analytics_visitor_id: consentedVisitorId }
  : {};

const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  line_items: trustedLineItems,
  success_url: trustedSuccessUrl,
  cancel_url: trustedCancelUrl,
  payment_intent_data: { metadata }
});

4. Connecter le compte de revenus correspondant

Cette connexion mesure les paiements de vos clients ; elle est distincte du règlement de ce service d’analyse. Dans Connections, choisissez le projet dont vous êtes propriétaire, le compte correspondant en mode test et la clé de lecture restreinte. L’identité du compte est vérifiée avant l’enregistrement d’un brouillon chiffré. Le brouillon fournit une URL stable d’endpoint webhook, mais rejette les transmissions jusqu’à son activation.

Un accès en lecture est nécessaire pour le compte, les PaymentIntents et les remboursements ; l’import limité facultatif exige aussi l’accès à Events. Utilisez l’URL du brouillon pour configurer un endpoint webhook dans votre propre compte Stripe pour payment_intent.succeeded, refund.created, refund.updated et refund.failed. Saisissez ensuite le secret de signature de cet endpoint dans le formulaire d’activation du brouillon. Le compte, le projet, le mode et l’URL existants restent inchangés ; seule l’activation permet les transmissions.

La configuration en production est volontairement séparée et exige une activation explicite du serveur, HTTPS et des cookies Secure. Les connexions de test et de production ne peuvent pas partager un projet. Une connexion configurée ne prouve pas qu’une transmission a réussi.

5. Vérifier l’ensemble du parcours

  • Après consentement, envoyez un événement de test depuis l’origine autorisée et examinez la vue Events du projet.
  • Créez un paiement de test correspondant. Vérifiez la source, la devise et les encaissements bruts, pas la démo synthétique.
  • Testez un remboursement partiel, une transmission répétée et un paiement sans association à un visiteur.
  • Retirez le consentement et confirmez qu’aucun nouvel événement du navigateur n’est envoyé.
  • Vérifiez les avertissements de rapprochement en attente et ne considérez pas la configuration comme terminée tant que la transmission réelle du prestataire et le comportement du navigateur ne sont pas vérifiés.

Connaître les limites actuelles

Les quotas mensuels d’événements s’appliquent à tous les projets du propriétaire de la facturation. Au plafond, la nouvelle collecte s’arrête sans inventer de données ni facturer automatiquement un dépassement. Le rapprochement financier et les rapports existants restent accessibles.

L’import facultatif des 7 ou 30 derniers jours couvre uniquement les événements de paiement réussi disponibles. Il ne peut reconstituer ni l’historique des visiteurs ni l’ensemble des remboursements passés ; les rapports importés comportent un avertissement d’historique partiel. Les entonnoirs ordonnés à plusieurs étapes sont implémentés. L’import et les rapports Search Console exigent une connexion au prestataire autorisée séparément ; cet aperçu public n’a aucun prestataire connecté. L’identification entre appareils et le remplacement d’un système comptable ne sont pas disponibles.

Références

Cette documentation décrit le code et ses limites ; elle ne confirme pas une connexion active. Les exemples techniques conservent leurs identifiants d’origine.