Toute la documentation

Démarrer

  1. 01Pour commencer
  2. 02Installation
  3. 03Suivi

Fonctionnalités

  1. 04Le tableau de bord
  2. 05Objectifs
  3. 06Liens courts
  4. 07Sources et agents IA
  5. 08Rapports par e-mail
  6. 09Vérification planifiée
  7. 10Interrogez votre IA

Référence

  1. 11Configuration
  2. 12API HTTP

Plateformes

  1. 13Serveur autonome
  2. 14PHP
  3. 15WordPress
  4. 16Drupal
  5. 17Craft CMS
  6. 18Python
  7. 19Rails
  8. 20Ruby
  9. 21Go
  10. 22Java
  11. 23.NET
  12. 24Elixir
  13. 25Rust

Confiance

  1. 26Confidentialité

Fonctionnalités

Rapports par e-mail

Runlight envoie des résumés hebdomadaires ou mensuels par e-mail via votre propre service d’e-mail, dans la langue de chaque lecteur.

Runlight peut envoyer par e-mail un résumé d’un site chaque semaine ou chaque mois. Chaque résumé contient la phrase de résumé, les six chiffres comparés à la période précédente, les pages, sources et pays principaux, et les conversions avec leurs revenus. Il est envoyé depuis votre propre adresse, via un service d’e-mail que vous utilisez déjà.

1. Configurer le service d’e-mail

Dans Réglages, Service d’e-mail, choisissez un service et saisissez ses clés ainsi que l’adresse d’expédition des rapports. Envoyer un test vérifie que tout fonctionne. Un seul service d’e-mail sert tous les sites de l’installation.

Service Ce qu’il demande
Amazon SES La région, l’ID de clé d’accès et la clé d’accès secrète (un utilisateur IAM autorisé à ses:SendEmail)
Resend Une clé d’API
Postmark Un jeton d’API du serveur et, en option, le flux de messages
SendGrid Une clé d’API
Mailgun Le domaine d’envoi, une clé d’API et la région (US ou EU)
Brevo Une clé d’API
Mailjet Une clé d’API et une clé secrète
MailerSend Un jeton d’API
SparkPost Une clé d’API et la région (US ou EU)
SMTP L’hôte, le port, la sécurité (STARTTLS, TLS ou aucune) et, en option, un identifiant et un mot de passe
Webhook Une URL à laquelle Runlight envoie chaque e-mail en JSON et, en option, un secret de signature

L’adresse d’expédition doit être une adresse depuis laquelle votre service vous laisse envoyer, généralement sur un domaine que vous avez vérifié auprès de lui.

Les clés sont stockées chiffrées avec une clé dérivée de RUNLIGHT_SECRET (ou, à défaut, de RUNLIGHT_TOKEN) et ne sont jamais renvoyées au navigateur. Laissez donc un champ vide pour garder la clé enregistrée. Si aucune des deux variables n’est définie, les clés sont stockées telles que saisies, et les Réglages vous le signalent.

Vous pouvez aussi définir le service dans le code en passant mail. Les Réglages l’affichent alors sans pouvoir le modifier.

ts

runlight({
  store,
  mail: { service: "resend", apiKey: process.env.RESEND_API_KEY!, from: "reports@example.com", fromName: "Runlight" },
});

Envoyer via votre application

Une application qui envoie déjà des e-mails, comme un CMS, peut plutôt passer son propre système d’envoi comme mail. Ce système se compose d’une fonction send qui reçoit chaque message (to, from, fromName, subject, html, text et headers), de l’adresse et du nom d’expédition, et de via, le nom que les Réglages affichent pour lui. Les rapports, les e-mails de test, les invitations et les liens de connexion passent alors par lui, et les Réglages affichent son nom et son adresse d’expédition.

Le système d’envoi de l’application est une valeur par défaut. Le propriétaire peut toujours choisir un autre service dans les Réglages, qui prend sa place, et retirer ce service revient au système d’envoi de l’application. Les extensions WordPress, Drupal et Craft passent le leur quand le site a un vrai système d’envoi configuré.

ts

runlight({
  store,
  mail: { from: "hello@example.com", fromName: "Example", via: "My app", send: (message) => mailer.send(message) },
});

En Go, le système d’envoi est une option à part, AppMailer, avec Send, From, FromName et Via, et en Rust c’est app_mailer. Ruby et Elixir nomment l’expéditeur from_name, et PHP accepte un callable comme send.

Passez mailServices avec les identifiants des services que les Réglages peuvent proposer pour écarter les autres, comme le fait l’extension WordPress avec SMTP. Un service enregistré auparavant qui n’est pas dans la liste compte comme aucun, et le système d’envoi de l’application reprend la main.

Le webhook

Le webhook reçoit un POST dont le corps JSON contient to, from, fromName, subject, html, text et headers. Si un secret de signature est défini, l’en-tête x-runlight-signature contient sha256= suivi du HMAC-SHA256 du corps brut, en hexadécimal. L’URL doit utiliser https (ou être localhost).

2. Ajouter les destinataires

Dans Réglages, Rapports par e-mail, ajoutez une adresse avec sa fréquence (hebdomadaire ou mensuelle) et la langue de l’e-mail. Envoyer un exemple envoie aussitôt le dernier rapport, une fois par minute pour chaque adresse. Depuis un serveur autonome connecté, les exemples partent une fois toutes les dix minutes pour l’ensemble du site.

  • Les rapports hebdomadaires couvrent du lundi au dimanche et partent à partir de 8 h le lundi.
  • Les rapports mensuels couvrent le mois civil et partent à partir de 8 h le 1er.

Les deux utilisent le fuseau horaire du site, et chaque période n’est envoyée qu’une fois. Si l’envoi échoue, la vérification suivante réessaie.

3. Planifier la vérification

Les rapports sont envoyés par la vérification horaire, donc rien ne part tant qu’elle n’est pas planifiée.

Se désabonner

Chaque e-mail contient un lien de désabonnement et les en-têtes List-Unsubscribe que les applications de messagerie utilisent pour leur propre bouton de désabonnement. Le lien ouvre une page avec un bouton, pour qu’un scanner de messagerie qui ouvre les liens ne puisse désabonner personne par accident.