Trackily Docs

Vue d'ensemble

Comment Trackily est architecturé, et ce qui se passe quand un visiteur clique sur /c/mon-slug. Schéma ASCII inclus.

Dashboard Trackily

Les concepts

Trackily organise tout autour de 8 entités principales. Si tu connais déjà Voluum ou Keitaro, ça te sera familier — mais Trackily ajoute trois briques qu'ils n'ont pas : le cloaking visuel par workflow, l'AI landing builder et le commerce natif.

Entité Rôle Stockée dans
Campaign Le point d'entrée. Une URL /c/:slug, une source de trafic, un flow, optionnellement un workflow de cloaking. campaigns
Source D'où vient le trafic (Meta, Kadam, Taboola, TikTok, MGID, ExoClick, push, search…). Définit les macros ({click_id}, {cost}, etc.) et les credentials API. traffic_sources
Flow Les règles qui choisissent quelle landing montrer et quelle offer envoyer. Supporte conditions (geo, device, OS, browser, language) et poids (A/B). flows
Landing La page pré-offer. Trois types : HTML local, URL externe, ou AI-generated (engine v2 + design DNA). landing_pages, ai_landings
Offer La destination finale (réseau d'affiliation OU produit natif). Contient l'URL, le payout, la cap, le statut. offers
Network Le réseau d'affiliation (Everflow, ClickDealer, etc.) — gère les postbacks de conversion. affiliate_networks
Cloaking workflow Un graphe visuel de détection + actions. Évalué côté serveur sur chaque click si attaché à une campagne. cloaking_workflows
Automizer rule Une règle "si conditions alors actions" évaluée toutes les 60s par le moteur. automation_rules

Le commerce natif (Phase 6+) ajoute native_products, orders, customers, subscriptions, discount_codes, shipping_zones. Voir Commerce → index.

Le chemin d'un click

Voici ce qui se passe quand un visiteur tape sur /c/mon-slug (handler dans server.js:7491) :

┌─────────────────────────────────────────────────────────────────────┐
│  Visiteur → /c/mon-slug?sub1=facebook&sub2=adset123&click_id=...    │
└─────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
        ┌──────────────────────────────────────┐
        │ 1. Lookup campaign par slug          │
        │    findBySlug('campaigns', slug)     │
        │    → 404 si inactive ou inexistante  │
        └──────────────────────────────────────┘
                              │
                              ▼
        ┌──────────────────────────────────────┐
        │ 2. Extract IP + UA + CF data         │
        │    geolocateIP() → country, ISP      │
        │    parseUA() → os, browser, device   │
        └──────────────────────────────────────┘
                              │
                              ▼
        ┌──────────────────────────────────────┐
        │ 3. Fraud scoring                     │
        │    calculateFraudScore()             │
        │    → score 0-100 + flags             │
        │    Si score ≥ 80 → auto-blacklist IP │
        └──────────────────────────────────────┘
                              │
                              ▼
        ┌──────────────────────────────────────┐
        │ 4. CLOAKING WORKFLOW (si attaché)    │
        │    Charge cloaking_workflows.id      │
        │    Parcourt le graphe :              │
        │      trigger_visitor                 │
        │      → check_reviewer_ip             │
        │      → check_vpn                     │
        │      → check_datacenter              │
        │      → action_safe_page (redirect)   │
        │      OU action_allow (continue)      │
        └──────────────────────────────────────┘
                              │
                  ┌───────────┴───────────┐
                  ▼                       ▼
        ┌──────────────────┐    ┌──────────────────────┐
        │ CLOAKÉ : redirect│    │ HUMAIN : on continue │
        │ vers safe page,  │    │                      │
        │ 404, ou blacklist│    │                      │
        └──────────────────┘    └──────────────────────┘
                                            │
                                            ▼
                        ┌──────────────────────────────────────┐
                        │ 5. Bot filter (legacy)               │
                        │    Si bot_filter.enabled && bot      │
                        │    → redirect google.com             │
                        └──────────────────────────────────────┘
                                            │
                                            ▼
                        ┌──────────────────────────────────────┐
                        │ 6. Flow engine                       │
                        │    getFlowsByCampaign(id)            │
                        │    Pour chaque flow par priorité :   │
                        │      match conditions (geo, device,  │
                        │      OS, browser, lang)              │
                        │    → premier flow matchant gagne     │
                        └──────────────────────────────────────┘
                                            │
                                            ▼
                        ┌──────────────────────────────────────┐
                        │ 7. Landing rotation                  │
                        │    Tirage pondéré dans flow.landings │
                        │    → 1 landing choisie               │
                        │    URL = /l/:slug?click_id=xxx       │
                        └──────────────────────────────────────┘
                                            │
                                            ▼
                        ┌──────────────────────────────────────┐
                        │ 8. INSERT INTO clicks                │
                        │    + cost (depuis source.cost_param) │
                        │    + currency conversion             │
                        │    + retargeting pixels résolus      │
                        └──────────────────────────────────────┘
                                            │
                                            ▼
                        ┌──────────────────────────────────────┐
                        │ 9. RESPONSE                          │
                        │    res.redirect(landing.url)         │
                        │    OU res.send(landing.html_content) │
                        │    + pixels FB/Google/TikTok inline  │
                        └──────────────────────────────────────┘

                                Plus tard…

        ┌──────────────────────────────────────┐
        │ 10. Conversion postback              │
        │     Network call /postback?click_id=…│
        │     → INSERT INTO conversions        │
        │     → forward vers source si conf'd  │
        │     → trigger email automation       │
        │     → check automizer rules (60s)    │
        └──────────────────────────────────────┘

Les services background

À côté du serveur HTTP, Trackily fait tourner plusieurs boucles :

Service Fréquence Rôle
Automizer 60s Évalue toutes les règles actives, exécute les actions si conditions met. Voir automizer.js:16.
Email engine déclenché par events Envoie les sequences sur trigger (subscriber, conversion, abandoned cart…).
Auto-fulfill (commerce) déclenché par conversion Marque les orders comme ready si tous les items sont dispatched.
AI predictions déclenché par dashboard load Re-calcule les prédictions ROAS / churn / fatigue ad.
License check au boot + 6h Re-valide la licence si LICENSE_KEY set.

Cloaking — où il s'insère

Le cloaking est avant tout le reste. C'est l'étape 4 du schéma. Le workflow attaché à la campagne (via campaigns.cloaking_workflow_id) est exécuté à chaque click et peut :

  • Allow — le visiteur continue vers le flow
  • Safe page — redirect vers une URL inoffensive (un blog, un article wikipédia)
  • 404 — réponse 404 brute
  • Redirect — vers une URL custom
  • Block — 403 + blacklist IP

Le moteur d'évaluation est dans server.js:7540. Le builder visuel est dans public/cloaking-builder.html. Détails dans Cloaking → nodes.

Automizer — où il s'insère

L'Automizer ne touche pas au flux du click. Il tourne en background (boucle 60s, voir automizer.js:16) et regarde toutes les automation_rules actives :

boucle toutes les 60s:
  rules = SELECT * FROM automation_rules WHERE is_active = true
                AND (last_checked IS NULL
                     OR last_checked < NOW() - check_interval_minutes * INTERVAL '1 minute')
  pour chaque rule:
    stats = getStatsForTimeWindow(campaign_id, window)
    si TOUTES les conditions sont met:
      pour chaque action: executeAction(action)
      INSERT INTO automation_log

Détails dans Automizer → rules.

Engine v2 + Design DNA (landings AI)

Trackily ship un AI landing builder qui sait générer des prelanders sur mesure pour un produit / offer / archétype donné. Deux briques :

  • Engine v2 (ai-landing-renderer-v2.js) — assemble une page à partir de "primitives" (hero, social proof, comparison table, CTA banner, FAQ, footer…). Une primitive = un composant HTML standalone avec ses variantes.
  • Design DNA (ai-landing-dna.js) — chaque landing a une "DNA" : palette, font stack, mood, density, animation level. Génère des landings visuellement diverses sans coder 50 templates.

Voir Landings → AI builder et Landings → primitives.

Le commerce natif (en bref)

Tu peux vendre tes propres produits directement depuis Trackily, sans Shopify :

  • Products + Variants + Categories + Reviews
  • Orders + Refunds + Fulfillment (manuel ou auto)
  • Customers + Subscriptions
  • Discounts + Shipping zones + Payment accounts (Stripe Connect, PayPal)

Le checkout est servi par Trackily lui-même, les pixels retargeting sont injectés automatiquement, et chaque vente est trackée comme une conversion dans clicks/conversions. Voir Commerce → index.

Le MCP

Trackily expose ~150 outils via le protocole Model Context Protocol. Tu peux brancher Claude Desktop, Cursor, Continue ou n'importe quel agent MCP-compatible et lui dire "pause la campagne 42" ou "génère une landing pour mon produit X" — l'agent appelle l'outil HTTP correspondant via un token scopé.

Voir MCP → concept.

L'admin UI en bref

L'UI admin (/admin) est une SPA single-file (public/admin.html) qui parle au backend via /admin/api/*. Tout est rendu côté client à partir des données JSON. Les écrans suivent la structure de la sidebar.

Voir Admin UI → index.

Stack technique

  • Backend — Node.js 22 + Express 4
  • DB — PostgreSQL 14+
  • Frontend admin — Vanilla JS dans public/admin.html (single-file SPA, ~32k lignes)
  • Cloaking builder — Drawflow.js dans public/cloaking-builder.html
  • Tracking JS/pixel.js, /trackily.js, /cloak.js, /i18n.js
  • Packagingpkg pour générer un binaire Linux/Mac standalone
  • Reverse proxy / SSL — Caddy embarqué dans l'image Docker (optionnel)

Voir aussi