README

## 1.10.6 - Interface Google Ads professionnelle

La page **CallTracker AWM -> Google Ads** suit maintenant le shell AWM : cartes Light/Dark, etats OAuth/MCC/synchronisation, formulaires compacts et rendu responsive. Le moteur Google Ads/CPL 1.10.4/1.10.5 reste inchangé.

## Google Ads - écran de configuration 1.10.5
CallTracker possède maintenant sa propre page **CallTracker AWM -> Google Ads**. Les réglages Google Ads ne sont plus recherchés dans **Hub AWM -> Réglages**. La page permet d enregistrer OAuth, plusieurs MCC, de connecter Google, de tester un MCC et d ouvrir directement les campagnes / l historique CPL.

## Google Ads CPL - 1.10.4
CallTracker peut utiliser deux MCC ou davantage avec une seule integration Google Ads. Chaque campagne conserve son MCC (`login_customer_id`), son compte Google Ads et, au besoin, son `campaign_id`. Le cout mensuel provient de `metrics.cost_micros` et alimente l investissement CPL sans modifier la definition des leads: appels entrants admissibles + formulaires admissibles.

La synchronisation automatique traite de petits lots toutes les 15 minutes et reprend le mois courant ainsi que le mois precedent. Une erreur API ne remplace jamais un cout valide par zero. La derniere valeur reste disponible avec un etat de fraicheur et la derniere erreur pour diagnostic.

Depuis septembre 2026, le niveau d acces Google Ads API est lie au projet Google Cloud qui porte les identifiants OAuth. Le champ Developer Token historique est donc facultatif dans le moteur; une valeur deja enregistree reste envoyee pour compatibilite.

## 1.10.3 — Pulse v2 routage — 2026-09-12

- Le score Health CallTracker pénalise uniquement les erreurs de synchronisation/routage connues.
- Les campagnes et Twilio restent non modifiés automatiquement; le score sert au triage.

## 1.10.2 — Pulse opérationnel transversal — 2026-09-12

- Expose au Core un pulse campagnes actives / brouillons / erreurs de synchronisation routage.
- Le pulse reste strictement descriptif et ne déclenche aucune opération Twilio.

# CallTracker AWM 1.10.0 — parcours Funnel client piloté par CRM

CallTracker 1.10.0 sépare maintenant la commande du service et l exécution téléphonique. Le client démarre dans **Nouveaux services**, crée un Funnel à **10 $/mois** géré commercialement par CRM, choisit ensuite son numéro, récupère son webhook de formulaire puis configure son routage avancé. Le service CRM reste en configuration et non facturable automatiquement jusqu à l attribution confirmée du numéro.

Le routage client couvre la destination principale, le fuseau, les horaires, les jours fermés, la destination hors heures, le débordement séquentiel et le délai. Les secrets et opérations Twilio restent exclusivement côté Alliance/Core/CallTracker.

# CallTracker AWM 1.9.9 — Webhooks de formulaires par Funnel
CallTracker 1.9.9 fournit à chaque Funnel client un webhook HTTPS unique. Les envois provenant d Elementor, Gravity Forms, WPForms ou d un formulaire personnalisé sont attribués automatiquement au bon client et à la bonne campagne, puis stockés dans l historique de formulaires utilisé par Leads et CPL.


## Routage avancé 1.9.7

La phase 1 du Lot C ajoute des horaires par campagne, des fermetures spéciales, une destination hors heures et un débordement séquentiel. Le fuseau de campagne demeure la référence. Le secours est déclenché par une route TwiML Core signée par Twilio et ne sonne qu après échec/non-réponse de la destination initiale. Hub affiche l aperçu de la route; Validation et santé exige les essais correspondants.


CallTracker AWM 1.9.6 ajoute une procédure contrôlée pour reprendre **tous les numéros des campagnes actives et les numéros encore actifs dans l’export legacy retrouvés localement** dans AWM avant de décommissionner l’ancienne plateforme. La procédure est accessible dans **Validation et santé** et travaille par lots avec progression.

La reprise ne se contente pas de modifier WordPress : elle résout le Phone Number SID si nécessaire, replace le `VoiceUrl` Twilio sur AWM, retire les fallbacks/application voix legacy et relit ensuite la ressource Twilio pour confirmer que la bascule a réellement eu lieu. Les campagnes dont les appels entrants sont désactivés sont quand même reprises par AWM; le webhook CallTracker refuse ensuite le transfert, ce qui rend enfin le crochet de désactivation maître du comportement.

Une fois tous les numéros conformes, l’action **BASCULE AWM** verrouille les imports Laravel et CPL. L’ancienne plateforme reste consultable comme référence historique mais ne peut plus réécrire les données CallTracker sans réouverture explicite.

# CallTracker AWM 1.9.5 — resynchronisation du routage des campagnes existantes

CallTracker 1.9.5 corrige le cas des campagnes déjà existantes lorsque le numéro de réception est modifié. La sauvegarde locale ne suffit plus : CallTracker vérifie le Phone Number SID, reprend automatiquement le webhook entrant AWM chez Twilio et mémorise la destination effectivement synchronisée. Un état de routage et une action de resynchronisation manuelle sont visibles dans l'éditeur de campagne.

Le routage reste dynamique : le numéro de transfert défini dans la campagne est prioritaire; s'il est vide, le numéro de destination du client est utilisé. Une modification du numéro client resynchronise aussi les campagnes qui utilisent ce fallback. Les lots Validation et santé, Fiabilité 1.9.3 et connexion non bloquante 1.9.4 restent conservés.
Pour l’éditeur complet, Hub AWM 4.5.15 filtre aussi les requêtes Heartbeat de fond afin qu’elles n’ouvrent plus le loader « Récupération des données » toutes les ~30 secondes.

---

# CallTracker AWM 1.9.4 — éditeur de campagne sans popup WordPress

CallTracker 1.9.4 corrige le dialogue WordPress « Connexion perdue » sur les campagnes. L'autosave WordPress est retiré uniquement du CPT interne CallTracker; la barre AWM conserve l'enregistrement manuel et affiche un état de connexion non bloquant. Le lot Fiabilité 1.9.3 reste inchangé et continue sa validation terrain.

# CallTracker AWM 1.9.3 — Fiabilité des événements Twilio

CallTracker 1.9.3 consolide le lot Fiabilité et sécurité des événements après le centre Validation et santé de 1.9.2.

## Webhooks
- idempotence persistante pour `status` et `recording`;
- détection de rejeu/doublon;
- ordre monotone des statuts avec `SequenceNumber`;
- file de reprise locale pour erreurs transitoires;
- cinq tentatives maximum puis échec définitif visible;
- erreurs 4xx déterministes ignorées sans boucle de retry;
- événements TwiML observés pour rejeu mais jamais bloqués uniquement parce qu ils sont répétés.

## Temps et CPL
Les nouveaux appels/formulaires disposent d instants UTC canoniques. Les historiques sont convertis avec le fuseau de leur campagne lorsque possible. Le CPL mensuel utilise le mois civil du fuseau de campagne puis convertit ses bornes en UTC pour interroger les données.

## Enregistrements
L API cliente ne retourne plus l URL Twilio brute. Core vérifie la propriété, récupère le média côté serveur avec les secrets protégés, puis Hub Client le relaie via une URL locale de session.

## Validation et santé
Le panneau affiche les événements reçus, traités, en reprise, en échec définitif et le dernier événement UTC. Les tests réels Alliance/Twilio restent obligatoires avant approbation des campagnes et clôture de migration.