Trackily Docs

Cloaking sur une campagne

Brancher un cloaking workflow à une campagne, c'est un seul champ : campaigns.cloaking_workflow_id. L'effort est dans le workflow lui-même (voir cloaking/workflows) — l'assignation est triviale en deux temps.

Liste cloaking workflows

Concept

Quand campaigns.cloaking_workflow_id est NON-NULL, chaque requête à /c/<slug> passe d'abord par le moteur cloaking AVANT le flow engine. Le workflow décide :

  • Safe page : le visiteur (bot, scraper, reviewer ad network) voit une page innocente.
  • Real page : le visiteur légitime continue vers le flow engine et la vraie landing.

Sans cloaking workflow assigné, le moteur cloaking est court-circuité — tout le monde voit la real page. C'est l'état par défaut d'une campagne fraîche.

L'assignation est une opération Tier-2 (impacte le trafic live), donc deux étapes : preview + confirm. Le confirm_token expire en 5 minutes et est single-use.

Comment faire — via l'UI

  1. Settings → Cloaking : crée d'abord ton workflow via le Visual Workflow Builder (cloaking/workflows).
  2. Campaigns → ta campagne → Settings.
  3. Dropdown Cloaking workflow : sélectionne le workflow.
  4. Save.

La campagne route immédiatement le trafic à travers le workflow. Pas de redéploiement nginx, pas de redémarrage Trackily — c'est instant.

Comment faire — via MCP (flow OAuth-style preview + confirm)

Tool : assign_cloaking_workflow_to_campaign (Tier-2, scope settings:write).

Étape 1 — Preview (sans confirm_token)

{
  "name": "assign_cloaking_workflow_to_campaign",
  "arguments": {
    "workflow_id": 7,
    "campaign_id": 42
  }
}

Réponse :

{
  "status": "confirmation_required",
  "action": "assign_cloaking_workflow_to_campaign",
  "workflow": { "id": 7, "name": "Antivirus US safe-page", "is_active": true },
  "campaign": { "id": 42, "name": "MemoMind FR — Push Kadam" },
  "current_workflow_id": null,
  "will_replace": false,
  "confirm_token": "ctok_a8f3...c712",
  "confirm_token_ttl_seconds": 300
}

Trackily te montre :

  • Le workflow qu'il va assigner (avec son is_active).
  • La campagne ciblée.
  • Si tu vas REMPLACER un workflow existant (will_replace: true quand current_workflow_id est non-NULL et différent).
  • Le confirm_token (TTL 5 min).

Étape 2 — Confirm

{
  "name": "assign_cloaking_workflow_to_campaign",
  "arguments": {
    "workflow_id": 7,
    "campaign_id": 42,
    "confirm_token": "ctok_a8f3...c712"
  }
}

Réponse :

{
  "status": "ok",
  "workflow_id": 7,
  "campaign_id": 42,
  "preview": { "...": "..." }
}

Le UPDATE campaigns SET cloaking_workflow_id = $1 WHERE id = $2 est exécuté ; le workflow s'applique au clic suivant.

Voir le code source : autopilot-workflow-tools.js:550 (toolAssignToCampaign) et autopilot-workflow-tools.js:681 (registration).

Pourquoi le OAuth-style preview + confirm

Une mauvaise assignation de cloaking peut :

  • Envoyer 100 % du trafic vers la safe page → 0 conversion, tu brûles ton budget.
  • Envoyer 100 % vers la real page → review reject potentiel du compte ad network.
  • Remplacer silencieusement un workflow qui marchait, sans que personne ne s'en aperçoive.

Le confirm_token force l'opérateur (ou le LLM) à RELIRE le preview avant de valider. Surtout quand will_replace: true.

Workflow recommandé

  1. Créer le workflow : Settings → Cloaking → New Workflow → définir les nodes (Trigger → checks VPN/headless/bots → action_safe / action_allow).
  2. Tester en isolation : utiliser un workflow is_active: false d'abord, vérifier le DSL via MCP get_cloaking_workflow.
  3. Assigner sur une campagne staging : pas directement sur la prod.
  4. Activer le workflow : update_cloaking_workflow avec is_active: true.
  5. Monitorer les logs : cloaking_logs table + admin/logs UI.
  6. Si OK : assigner sur la campagne prod via le flow preview → confirm.

Exemples

Première assignation (workflow vierge)

{
  "name": "assign_cloaking_workflow_to_campaign",
  "arguments": { "workflow_id": 7, "campaign_id": 42 }
}

Preview montre will_replace: false. Tu confirmes avec le token.

Remplacement d'un workflow existant

{
  "name": "assign_cloaking_workflow_to_campaign",
  "arguments": { "workflow_id": 12, "campaign_id": 42 }
}

Si la campagne avait déjà cloaking_workflow_id: 7, le preview répond will_replace: true, current_workflow_id: 7. Relis bien avant de confirmer — tu peux désactiver un workflow qui marchait.

Détacher un workflow

Pas de tool dédié detach_cloaking_from_campaign. À la place :

  • Via UI : Campaign Settings → Cloaking workflow dropdown → "None" → Save.
  • Via SQL direct : UPDATE campaigns SET cloaking_workflow_id = NULL WHERE id = 42;
  • Via MCP : pas encore exposé en Tier-2. Roadmap.

À noter : si tu soft-delete le workflow via delete_cloaking_workflow, toutes les campagnes qui le référencent ont automatiquement cloaking_workflow_id remis à NULL (voir autopilot-workflow-tools.js:655 — "no traffic is interrupted, the campaign just runs without cloaking").

Erreurs courantes

  • Workflow is_active: false : tu l'assignes, mais aucune logique cloaking n'est appliquée. Trackily n'erreure PAS — il skip silencieusement. Vérifie toujours le is_active avant l'assign.
  • Workflow soft-deleted : assign_cloaking_workflow_to_campaign rejette avec Cloaking workflow #X not found. Restaure le workflow ou crée-en un nouveau.
  • Confirm_token expiré : 5 minutes. Au-delà, refais l'étape preview pour obtenir un nouveau token.
  • Confirm_token cross-tool : un token émis pour assign_cloaking_workflow_to_campaign ne marche pas pour update_cloaking_workflow. Ils sont liés au nom du tool.
  • Workflow trop strict : si ton workflow renvoie 95 % du trafic vers la safe page, tu vois tes conversions s'effondrer. Toujours auditer les cloaking_logs après une nouvelle assignation.

Voir aussi