Reno Compare Isolation 1

• List Tests — Liste tous les tests A/B avec leur configuration. Retourne pour chaque test : test_id, name, status, url_from (pattern URL), optimize (on/off), discovery_rate (taux exploration epsilon-greedy), nombre de variations et liste des noms de variations. Utile pour decouvrir les tests disponibles avant d'utiliser les autres outils.
• Get Test Details — Recupere le detail complet d'un test A/B par son test_id. Retourne : configuration du test, liste des variations avec leurs scores PageSpeed (desktop/mobile), resume des keyword groups (clustering IA), et configuration des goals. Les variations sont liees par STRING (variation_name), pas par variation_id.
• Get Statistics — Requete statistique agregee sur les visites (visit_log), groupee par une dimension au choix. C'est l'outil principal pour analyser les performances. Dimensions disponibles : variation, keyword, keyword_group, utm_source, utm_campaign, device_type, os, browser, uri, uri_path, abtest, optimization_method. Metriques retournees : visits, views, goals, goal_rate (%), phone_validation, phone_validation_rate (%), bounce_rate (%), avg_duration (s), avg_server_response_time (ms). TIMESTAMPS : start_date/
• Get Daily Trends — Retourne les series temporelles jour par jour pour analyse de tendances. Memes parametres que get_statistics mais les resultats sont ventiles par date. Utile pour detecter des tendances, saisonnalite, regressions de performance. TIMESTAMPS : start_date/end_date acceptent ISO 8601 (YYYY-MM-DD) ou UNIX epoch.
• Get Variation Comparison — Comparaison directe de 2+ variations d'un test A/B. Calcule pour chaque variation : visits, goals, goal_rate, phone_validation_rate, bounce_rate, avg_duration. Determine le winner avec le lift % par rapport au baseline (premiere variation = original). Calcule la confiance statistique (Z-test sur proportions). Genere une recommandation textuelle. TIMESTAMPS : start_date/end_date acceptent ISO 8601 (YYYY-MM-DD) ou UNIX epoch.
• Get Funnel Analysis — Analyse de funnel profonde pour une variation donnee. Retourne : engagement (goal_rate, bounce_rate, duree moyenne), segmentation des abandons (bounce / soft_bounce / early / qualified / late / converted), taux de completion par etape de formulaire (form_steps), points de friction (champs ou les visiteurs abandonnent), comparaison convertis vs abandonnes (duree, profondeur, champs remplis). Utilise les donnees form_steps JSON de visit_log pour l'analyse formulaire. TIMESTAMPS : start_date/end_da
• Get Web Vitals — Analyse des Core Web Vitals : donnees RUM reelles (visit_log) + scores Lighthouse lab (variation). RUM : LCP, FCP, CLS, TTFB moyennes et P75 par variation, avec rating (good/needs-improvement/poor). Lighthouse : scores PageSpeed desktop/mobile depuis la table variation. Compte les pages lentes (score composite < 90). Permet de correler performance technique et taux de conversion. TIMESTAMPS : start_date/end_date acceptent ISO 8601 ou UNIX epoch.
• Get Best Performance — Simule la recherche hierarchique de la meilleure variation telle que le moteur la fait en production. Utilise la table performance (agregation pre-calculee) avec 6 niveaux de granularite : Niveau 1: test_id + variation + device_type + time_slot + utm_source + utm_campaign + keywords. Niveau 2: test_id + variation + device_type + time_slot + utm_source + utm_campaign. Niveau 3: test_id + variation + device_type + time_slot + utm_source. Niveau 4: test_id + variation + device_type + time_slot. Niv
• Get Keyword Performance — Analyse de performance par keyword brut ou par keyword_group (clustering IA Claude). Retourne pour chaque keyword/groupe : visits, goals, goal_rate, phone_validation_rate, bounce_rate, avg_duration. En mode keyword_group, indique aussi le nombre de keywords dans chaque groupe et les keywords non-classes. Jointure logique : keyword_group.keyword_raw = visit_log.keywords. TIMESTAMPS : start_date/end_date acceptent ISO 8601 ou UNIX epoch.
• Get Traffic Sources — Analyse de performance par source de trafic (utm_source ou utm_campaign). Option cross_with_variation pour croiser source x variation et identifier quelles sources marchent avec quelles landings. Retourne visits, goals, goal_rate, phone_validation_rate, bounce_rate, avg_duration par source. TIMESTAMPS : start_date/end_date acceptent ISO 8601 ou UNIX epoch.
• Query Visits — Requete sur les visites individuelles (visit_log) avec tous les champs disponibles. Retourne les visites brutes avec : visitId, timestamp, uri, variation, test_id, device_type, time_slot (matin/apres-midi/soir/nuit, derive du timestamp via Visit::computeTimeSlot), keywords, utm_source, utm_campaign, goal_nb, phone_validation, visit_duration, form_steps (JSON), optimization_method (explore/exploit/control), decision_id (référence vers le journal du moteur A/B → à passer à explain_decision pour le
• Query Database — Execute une requete SQL SELECT en lecture seule sur la base de donnees A/B Testing. Filet de securite pour les questions imprevues que les autres outils ne couvrent pas. TABLES DISPONIBLES (7) : test, visit_log, performance, variation, goal, keyword_group, redirection. IMPORTANT : tous les timestamps sont en UNIX epoch (INT secondes depuis 1970-01-01), sauf goal.created_at (MYSQL TIMESTAMP). Utiliser FROM_UNIXTIME(timestamp) pour convertir en date lisible. Utiliser DATE(FROM_UNIXTIME(timestamp))
• Explain Decision — Explique la décision du moteur A/B test pour UNE visite donnée : la bonne variation a-t-elle été choisie, et si non pourquoi. Croise visit_log (servi + vraies dimensions), abtest.log (raisonnement exact figé au moment de la décision : dimensions réellement utilisées, cascade niveau par niveau, explore/exploit), et un replay live. Détecte : dimension connue mais perdue par le moteur, choix sur segment trop faible (< seuil de visites), repli aléatoire (fallback), exploitation sur peu de dimensions
• Verify Aggregates — Vérifie que la table performance est correctement calculée : recompute l'agrégat attendu depuis visit_log (fenêtre glissante) et le diffe contre la table. Détecte valeurs fausses (agrégat périmé), lignes manquantes, lignes périmées. Paramètre level (0=toutes dimensions … 5=totaux par variation, défaut 5, le plus fiable). Dimensions du moteur dans l'ordre : device_type, time_slot, utm_source, utm_campaign, keywords. Idéal après explain_decision quand on suspecte un mauvais calcul de performance.
• Analyze Dimensions — Recommande quelles dimensions d'optimisation activer pour un test A/B (lesquelles, dans quel ordre), OÙ arrêter la granularité, et CHIFFRE le gain : uplift de conversion de la config recommandée vs la config actuelle, rejoué hors-échantillon sur les N derniers jours (replay off-policy doublement robuste, IC95 par bootstrap). Verdict APPLIQUER / NE RIEN CHANGER selon que l'IC95 exclut 0. Fenêtres train/test auto (en jours, maximisées sous contrainte de rotation des variations). Champ « rapport »

Schemas and invoke metadata: Directory API