Créer des sondages

Créez un brouillon utile à partir de l'objectif de l'utilisateur, puis vérifiez son audience et sa distribution avant le lancement. Le workflow peut s'exécuter via MCP sans ouvrir l'éditeur de sondages.

Choisir la distribution et les questions

Déduisez le nom, l'objectif et les questions de la demande. Posez uniquement les questions manquantes qui modifient qui reçoit le sondage ou comment il est distribué.

Préférez une à trois questions sauf si l'utilisateur en demande plus. Utilisez une note plus une question ouverte optionnelle pour NPS/CSAT, ou des questions à choix avec au moins deux choix. Inspectez le schéma d'outil actuel pour les types de questions, les échelles, les branchements et les traductions au lieu de deviner leurs formes JSON. Les points de départ minimaux se trouvent dans les exemples.

Les noms de sondages, les questions et le texte d'apparence sont du contenu public. Ne copiez pas les détails clients privés dedans sans clarifier d'abord cette visibilité.

Vérifier l'audience et l'apparence

• Utilisez conditions pour les conditions d'URL, d'événement, d'appareil et de variante de drapeau lié. Résolvez les identifiants d'événement et de drapeau existants avant de les utiliser. Une condition d'URL ne définit pas une audience de personne ou de cohort.
• Utilisez targeting_flag_filters.groups[].properties[] pour le ciblage de personne, groupe ou cohort. Les groupes sont des règles alternatives; les propriétés au sein d'un groupe doivent toutes correspondre. Préservez l'audience prévue lors de la traduction de la demande.
• Les cohorts contenant des filtres comportementaux ne peuvent pas être utilisés directement pour le ciblage de sondages. Expliquez la restriction et proposez un snapshot statique supporté ou une autre définition d'audience équivalente. Un snapshot ne se met pas à jour avec le cohort original. Obtenez un accord avant de faire ce compromis; ne supprimez jamais une règle ou n'élargissez l'audience pour faire passer une demande échouée.
• Les formulaires hébergés (external_survey) n'utilisent pas les conditions d'affichage en application ni les drapeaux de ciblage. N'attachez pas ces champs à un formulaire hébergé.
• Omettez appearance sauf si une personnalisation est nécessaire. whiteLabel: true requiert le droit de white-labelling de l'organisation (Enterprise). Ne l'inférez pas d'une demande de couleurs personnalisées. Vérifiez le droit avant de le définir. surveyPopupDelaySeconds doit être non négatif.
• Laissez les champs optionnels non définis quand ils ne sont pas utilisés. Ne les remplissez pas avec null en substitut de l'omission; les champs de questions et les objets imbriqués ont des règles de nullabilité différentes.

Créer et examiner le brouillon

Appelez posthog:survey-create avec la configuration résolue. Omettez start_date pour un brouillon. Si l'utilisateur a déjà demandé un lancement immédiat, continuez à travers la vérification de disponibilité et lancez sans redemander la même approbation.

Conservez l'id du sondage retourné. Les outils de sondage suivants utilisent id, pas un ID de question, un ID de drapeau de feature ou un nom de sondage.

Lisez le sondage enregistré avec posthog:survey-get. Examinez les questions, le type, l'audience, le calendrier, la limite de réponses et la marque avec l'utilisateur. Affichez l'application MCP survey quand le client la supporte; sinon donnez un examen textuel concis. Incluez toujours l'_posthogUrl retourné. Une configuration enregistrée n'est pas une preuve qu'une popup en application a été affichée avec succès.

Pour les modifications, appelez posthog:survey-update après avoir récupéré le sondage enregistré. Les questions, conditions, apparence, ciblage et traductions peuvent remplacer les valeurs imbriquées. Préservez les champs inchangés et les ID de question existants, qui lient les questions aux réponses collectées. Omettez les IDs uniquement pour les nouvelles questions.

Lancer et vérifier la distribution

Avant posthog:survey-launch, confirmez:

• L'utilisateur a autorisé le lancement pour l'audience et la configuration examinées.
• Le sondage n'est pas archivé et n'a pas d'end_date dans le passé. Si vous réouvrez un sondage existant, désarchivez-le ou effacez/prolongez sa date de fin uniquement selon l'autorisation.
• Pour la distribution en application, les sondages sont activés dans le projet et le SDK de l'app supporte les features demandées. Les sondages déclenchés par événement ont besoin de l'événement déclencheur réel dans l'app. Créer un nom d'événement dans la configuration n'instrumente pas cet événement.
• Pour les sondages api, l'implémentation d'application gère l'affichage et la capture d'événement. Créer et lancer la définition n'implémente pas ce code.

Utilisez posthog:survey-launch avec id, puis vérifiez l'état retourné. Rapportez si le sondage est un brouillon, lancé ou en attente d'une étape SDK/setup. Pour les formulaires hébergés, retournez une URL de formulaire public vérifié quand disponible; _posthogUrl est la page de gestion et n'est pas un lien pour les répondants.

Utilisez posthog:survey-stats ou posthog:surveys-responses-list pour vérifier l'activité suivante. Zéro réponse immédiatement après le lancement ne prouve pas que la distribution a échoué. Pour un sondage qui aurait dû être affiché, suivez debugging-surveys.

Récupérer des erreurs

Lisez le champ de validation et la raison avant de réessayer. Pour les défaillances d'apparence, vérifiez le droit de marque et les champs d'apparence fournis. Pour les défaillances de ciblage, vérifiez le support des cohorts et la structure des règles. Préservez le comportement demandé lors de la correction des entrées; expliquez tout changement qui affecte l'audience ou la marque.

La création n'est pas idempotente. Après un timeout ou un résultat incertain, utilisez posthog:surveys-get-all pour trouver et inspecter un brouillon existant possible avant de réessayer la création. Un nom correspondant seul n'est pas une preuve qu'il s'agit du même sondage.