Email Marketing

Trackily embarque un ESP complet : listes, autoresponders (sequences), serveurs SMTP, suppression, opt-in / double opt-in, tracking opens/clicks, Send-Time Optimization, et déclencheurs basés sur tes conversions affiliées. Aucun Mailchimp / Klaviyo à payer en parallèle.

Concept

L'email marketing dans Trackily n'est pas un add-on bricolé : c'est un sous-système qui partage la même DB, le même worker, les mêmes tokens MCP et les mêmes scopes que le reste de l'app. Tu manipules les mêmes notions qu'un Mailchimp — liste, subscriber, sequence, step, send — mais avec deux singularités qu'un ESP classique ne peut pas offrir :

1. Conversion → enrollment automatique. Quand un postback affiliate /postback arrive pour une offre donnée, Trackily peut auto-enrôler l'acheteur dans une liste, qui démarre alors la sequence par défaut (thank-you, cross-sell, ascension). Un ESP classique ne voit jamais tes postbacks.
2. Landing → liste binding natif. Chaque landing peut être liée à une liste : toute soumission de formulaire enrôle automatiquement, sans ZapierMake/webhook intermédiaire.

Pourquoi c'est intégré

L'argument commercial est simple : tu te débarrasses d'une dépendance externe à 30-200$/mois, tu gardes toutes tes data first-party, et tu peux automatiser des flows que personne d'autre ne peut faire (parce que personne d'autre n'a accès à tes postbacks réseau ni à tes leads issus de prelanders).

L'argument technique est plus subtil : le moteur d'email réutilise la même infrastructure de scheduling que le reste de Trackily. Le email_sends.scheduled_at est lu par le même cron tick que tes campaigns, ton automizer et tes flows. Pas de queue Redis à déployer, pas de worker séparé à monitorer.

Architecture en une image

              ┌────────────────────────────────────────────────────────┐
              │                   EMAIL SUBSYSTEM                       │
              └────────────────────────────────────────────────────────┘

   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
   │  email_     │───▶│  email_     │───▶│  email_     │───▶│  email_     │
   │  smtp_      │    │  lists      │    │  sequences  │    │  sequence_  │
   │  servers    │    │             │    │             │    │  steps      │
   └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
         ▲                  ▲                                       │
         │                  │                                       ▼
         │            ┌─────────────┐                       ┌─────────────┐
         │            │  email_     │ ◀───── schedule ─────│  email_     │
         │            │  subscribers│                       │  sends      │
         │            └─────────────┘                       └─────────────┘
         │                  ▲                                       │
         │                  │                                       ▼
   ┌─────────────┐          │                                ┌─────────────┐
   │  email_     │          │                                │  email_     │
   │  suppression│──────────┘                                │  events     │
   └─────────────┘  (block list,                             │ (open/click)│
                    cross-list,                              └─────────────┘
                    bounces +
                    complaints)

Les 5 tables racines

Le flow nominal

1. Tu crées un serveur SMTP (Mailgun, SES…) dans Settings → Email — SMTP ou via MCP create_email_smtp_server.
2. Tu crées une liste et tu la lies à ce SMTP (create_email_list).
3. Tu crées une sequence sur la liste (create_email_sequence) — la première sequence devient automatiquement la default_sequence de la liste.
4. Tu ajoutes des steps (add_email_sequence_step) : subject, preheader, body_html, body_text, delay_days/hours/minutes depuis l'enrollment.
5. Tu enrolles des subscribers — manuellement (enroll_email_subscriber), via le binding landing→liste, ou via un trigger conversion.
6. Le worker tourne en continu : pour chaque subscriber actif, il calcule les steps "dus maintenant" et insère des email_sends à status='queued'.
7. À chaque tick (env. 30s), le worker prend les sends queued, route via le SMTP de la liste (en respectant les quotas daily/hourly), met à jour status='sent', et stocke le message_id retourné par le MTA.
8. Quand un destinataire ouvre / clique, un pixel ou un redirect signé loggue dans email_events. Les bounces / complaints reviennent via webhooks Mailgun/SES.
9. Hard bounce ou complaint = ajout automatique à email_suppression → plus jamais réémis vers cet email, depuis n'importe quelle liste.

Où ça se trouve dans l'admin

L'accordéon Email Marketing dans la sidebar regroupe les cinq pages :

• Lists — créer, éditer, soft-delete. Voir les subscribers d'une liste, le compteur, les sequences attachées.
• Sequences — visual builder de l'autoresponder. Reorder, preview, send-test.
• SMTP Servers — gérer les relays, tester la connexion, voir les compteurs daily/hourly.
• Sends Log — audit des emails (queued / sending / sent / failed / bounced). Filtre par status, liste, email.
• Suppression — view-only de la blocklist globale + ajout manuel via UI ou MCP.

Les conversion triggers ne vivent pas dans la sidebar : ils se configurent depuis la page MCP Autopilot ou la page Email — Lists (sous l'onglet "Triggers" d'une liste donnée).

Variables de templating

Dans subject, preheader, et body_html, ces placeholders sont rendus au moment de l'envoi :

• {{first_name}} — premier mot du name, ou la partie avant @ de l'email
• {{name}} — email_subscribers.name
• {{email}} — adresse
• {{country}} — country code ISO
• {{custom.X}} — n'importe quel champ de email_subscribers.custom_fields JSONB
• {{unsubscribe_url}} — lien one-click (auto-injecté en footer + dans List-Unsubscribe header)
• {{list_name}} — nom de la liste

Voir aussi

• Lists — gestion des listes, opt-in modes, GDPR
• Sequences — builder d'autoresponder, exemple de welcome series
• SMTP — Mailgun, SendGrid, Postmark, SES, Gmail
• Suppression — pourquoi c'est critique pour la réputation
• Automations — landing→liste, post-purchase, abandoned cart, conversion triggers
• Magic Link — passwordless auth pour les clients
• MCP Autopilot — pilote toutes ces tables depuis Claude / Cursor