Trackily Docs

Landings

Une landing dans Trackily, c'est une page web servie via /lp/<slug> ou injectée dans le flow d'une campagne via /c/<slug>. Quatre types (url, local, redirect_tracker, ai) couvrent tous les besoins, de la simple redirection au prelander AI-généré avec design DNA.

Liste des landings

Concept

Une landing est l'unité atomique de contenu dans Trackily (à comparer à la campagne qui est l'unité atomique de routage). Chaque landing a :

  • Un slug URL (/lp/<slug>).
  • Un type qui détermine COMMENT elle est servie (HTML inline, redirect, AI…).
  • Un is_active (les landings inactives sont skip par les flows).
  • Un protection_config (Lander Protection anti-spy).
  • Des meta (pour les landings AI : copy + design_dna + provider config — utilisés par rerender_landing_from_meta).
  • Optionnellement price_overrides (pour A/B tester des prix sur les mêmes variants de produit natif).

Une landing peut vivre sans campagne (en mode standalone, accessible via /lp/<slug>) ou être branchée dans le schema.landings[] d'un flow pour recevoir du trafic via /c/<slug>.

Les 4 types

Type Stockage Routing Quand l'utiliser
url Juste un champ url external 302 vers l'URL Tu héberges déjà la page ailleurs (Cloudflare Pages…)
local html_content TEXT dans la DB Renvoyé inline depuis /lp/<slug> Tu veux héberger toi sans déployer ailleurs
redirect_tracker redirect_config JSONB Page intermédiaire qui capture les params puis 302 Capturer fbclid / gclid / ttclid avant l'offre
ai html_content (généré) + meta (copy + DNA) Renvoyé inline depuis /lp/<slug> Générer une page complète via LLM + image provider

Détails complets : types.

Engine v1 vs v2 (pour les landings AI)

Le moteur AI a deux générations co-existantes :

  • v1 (legacy, defaut) : pick parmi 20 templates HTML hardcodés (5 originaux + 15 Phase-1). L'LLM remplit les copy slots via mustache. Prédictible, ~$0.02-0.05 par génération.
  • v2 (Phase 2) : le LLM émet ÉGALEMENT un Design DNA (palette OKLCH, typo, layout, ornaments, primitive selection) en plus du copy. Le renderer assemble la page à partir de 35 primitives CRO-testées. Chaque landing est visuellement unique. ~30 % de tokens en plus.

Tu choisis via le param engine: "v1" ou engine: "v2" de generate_ai_landing. Le moteur v2 expose 12 archetypes (archetypes) et 35 primitives (primitives).

Où elles sont servies

Trois routes Express dans server.js :

  • /lp/:slug (ligne ~18565) — accès direct à la landing. Pas de tracking campagne, juste affichage. Utile pour preview, share interne, QA.
  • /r/:slug (ligne ~18604) — route spéciale pour redirect_tracker qui sert d'abord un petit intermédiaire JS qui capture les params (fbclid, click_id, etc.) puis fait le redirect server-side.
  • /c/:slug (ligne ~7491) — l'URL de tracking de campagne. Le flow engine choisit une landing, puis sert son HTML inline (ou redirect selon le type). Le clic est inscrit dans clicks AVANT le rendu.

Une landing peut donc être appelée selon 3 chemins :

  • Standalone preview via /lp/<landing-slug> (toujours dispo).
  • Via redirect tracker via /r/<landing-slug> (uniquement si type='redirect_tracker').
  • Via campagne via /c/<campaign-slug> (la landing servie est celle choisie par le flow).

Le tableau de bord landings

L'UI admin (/admin/landings) liste toutes tes landings avec :

  • Status is_active (toggle direct).
  • Type, slug, # de campagnes liées.
  • Bouton "Preview" qui ouvre /lp/<slug> dans un nouvel onglet.
  • Bouton "Duplicate" qui clone la landing.
  • Lien vers le détail (édition HTML, settings, métadonnées).

Détail landing

Quoi faire ensuite

  • Types — deep dive de chaque type, exemples.
  • AI Builder — comment générer une landing IA, engine v1 vs v2.
  • Archetypes — les 12 archetypes V2 + quand utiliser chacun.
  • Primitives — les 35 primitives + smart picker.
  • Image providers — les 7 providers d'image + coûts.
  • Price testing — price_overrides pour A/B prix.

Cycle de vie d'une landing

1. Create (UI ou MCP)        →  ligne dans landing_pages, slug réservé
2. (AI only) Generate copy   →  meta.copy + meta.design_dna écrits
3. (AI only) Render HTML     →  html_content peuplé
4. Test en standalone        →  /lp/<slug> dans le navigateur
5. Link to campaign flow     →  schema.landings[].id du flow
6. Receive traffic           →  /c/<campaign-slug> route via le flow
7. Stats accumulate          →  clicks + conversions par landing_id
8. (Opt.) Re-render          →  rerender_landing_from_meta (zero cost)
9. (Opt.) Variants A/B       →  generate_landing_variants (1-8 siblings)
10. (Opt.) Pause             →  is_active=false, flows skip silently
11. (Opt.) Archive / delete  →  soft-delete via deleted_at

Distinguer une landing AI d'une landing classique

Depuis v38, tout vit dans landing_pages (pas de table séparée ai_landings). Le discriminator est le champ type :

  • type='ai' + meta.copy non-null → c'est une landing AI, regénérable.
  • type IN ('url', 'local', 'redirect_tracker') → classique.

L'API get_landing_detail retourne tous les types de la même façon. L'ancien get_ai_landing_detail (déprécié depuis v38) est un thin wrapper qui résout l'ID et appelle le tool unifié.

Voir aussi