Tous les articles

Pourquoi les tests fermés échouent : notes de terrain sur la fenêtre de 14 jours

guidesgoogle-playfield-notes
par Console Testers
Pourquoi les tests fermés échouent : notes de terrain sur la fenêtre de 14 jours

La plupart des demandes d'accès à la production ne se perdent pas au niveau du formulaire. Elles se perdent quelque part au milieu de la fenêtre, quand le compte glisse discrètement sous le plancher et que personne ne s'en aperçoit avant que Google ne renvoie la demande.

L'exigence est facile à énoncer : 12 testeurs, inscrits, en continu pendant 14 jours. Les comptes personnels créés après le 13 novembre 2023 ne peuvent pas diffuser une application tant que ce cycle n'est pas terminé et que la demande n'a pas été examinée.

Les développeurs entendent cela comme un problème de recrutement, alors tous les efforts vont au premier jour. Le groupe de discussion, le serveur Discord, les cousins. Le reste de la fenêtre est traité comme une période d'attente. C'est dans ce cadre de pensée que meurent les tests. L'exigence n'est pas de douze testeurs le premier jour. Elle est de douze testeurs à chaque jour de la fenêtre, y compris les jours où personne ne pense à votre application.

Les trois façons dont un test meurt

1. Le compte glisse

Les inscriptions arrivent en début de période. Presque tous ceux que vous aurez un jour répondent oui dans les premiers jours, quand vous demandez encore. Les départs vont dans l'autre sens, lentement, pendant deux semaines : un testeur se désinscrit, désinstalle lors d'un nettoyage du téléphone, perd intérêt. Chaque départ est petit. Le seuil, lui, ne l'est pas. À onze, vous êtes sous le plancher, et le cycle ne compte plus.

Les jours non plus ne reviennent pas. La consigne de Google est explicite : la période doit être continue. Un testeur qui se désinscrit puis se réinscrit plus tard commence une nouvelle série, pas une reprise. Un creux que vous laissez passer au sixième jour peut coûter toute la fenêtre.

2. L'installation qui ne s'ouvre jamais

Le compte n'est pas toute l'exigence. Google indique un engagement insuffisant des testeurs comme motif officiel pour renvoyer une application en test prolongé, juste à côté du passage sous le minimum. Le chiffre peut être juste et la demande revient quand même.

C'est l'échec qui se cache le mieux. Un lien d'inscription met un nom sur la liste ; il ne met pas de session dans vos analytics. Les testeurs qui installent et n'ouvrent jamais l'application maintiennent le tableau de bord au vert pendant que le vrai signal se dégrade en dessous. Rien ne passe au rouge.

Le formulaire vous rattrape aussi. La demande interroge sur ce qu'ont fait les testeurs : s'ils ont utilisé toutes les fonctions disponibles, si leur usage correspondait au comportement en production, quels retours vous avez reçus et comment vous les avez collectés. Un test sans activité n'a pas de réponse à ces questions, et une réponse vide n'est pas une réponse neutre.

3. Le compte était déjà en difficulté

Certains cycles sont perdus avant de commencer. Une demande d'accès à la production antérieure refusée. Une fiche store incomplète. Un problème de politique jamais résolu. Les quatorze jours s'écoulent, les rapports arrivent, le formulaire part, et Google refuse pour une raison qui n'a rien à voir avec vos testeurs. Vérifiez le compte avant de lancer l'horloge, pas après qu'il est revenu.

Pourquoi recruter en début de période est la mauvaise obsession

La règle de l'inscription continue change le calcul. Les testeurs ne valent pas la même chose à chaque jour de la fenêtre.

Perdre votre douzième testeur le douzième jour coûte plus que d'en gagner cinq le jour zéro. Les recrues précoces sont bon marché et abondantes : le lien d'inscription accepte jusqu'à 100 noms, la limite n'a donc jamais été le facteur limitant. Les testeurs de fin de fenêtre sont ceux qui tiennent le cycle ensemble.

Donc le chiffre à optimiser n'est pas l'effectif de pointe. C'est le minimum le pire jour. Recrutez avec une marge confortable au-dessus du plancher, puis consacrez les deux semaines suivantes à défendre le plancher.

À quoi ressemble vraiment l'abandon

Un test qui échoue a une forme, et on la voit dans un décompte quotidien :

  • Jours 1 à 3. Le compte grimpe à son maximum. Tout le monde que vous avez invité se présente. Cela ressemble à une réussite et c'est la partie la moins parlante du graphique.
  • Jours 4 à 9. La plage calme. Un ou deux testeurs dérivent, le compte reste au-dessus du plancher, donc rien ne semble mal. C'est là que les cycles commencent à mal tourner, et c'est la partie que les gens cessent de vérifier.
  • Jours 10 à 14. Là où les cycles sont réellement perdus. Le compte érode depuis une semaine, le développeur n'a pas ouvert la console depuis trois jours, et un seul départ remet maintenant tout en cause.

La vérification quotidienne est ennuyeuse : ouvrez la console et comparez aujourd'hui à hier. Vingt testeurs qui tombent vers douze est une position pire que quatorze qui tiennent au même niveau.

À quoi ressemble un test sain

Trois choses, dans l'ordre :

  1. La tendance. La direction vous indique à quoi ressemble la semaine prochaine. Le total ne vous dit où vous en êtes qu'aujourd'hui.
  2. Si les testeurs ouvrent l'application. Les inscriptions sont l'exigence ; les sessions sont la raison de l'exigence. Si vous ne voyez pas d'activité, vous tenez une liste, pas un test.
  3. La date à laquelle vous redémarreriez. Gardez-la visible pendant les quatorze jours. Chaque jour où le compte tient, cette date s'éloigne, et c'est le seul tableau de score qui compte.

Quand le chiffre plonge, remplacez le testeur dans la journée, depuis une source en laquelle vous avez déjà confiance. Un creux réparé en vingt-quatre heures ne vous coûte rien. Un creux réparé le treizième jour coûte deux semaines. Attendre de voir s'ils reviennent est le choix le plus cher.

L'étape que personne ne peut tricher

Maintenir le compte prend quelques minutes par jour. La partie dure est l'offre : des testeurs vérifiés qui restent inscrits pendant toute la fenêtre, plutôt que des gens qui installent au deuxième jour et disparaissent.

C'est la partie que gère Console Testers. Nous plaçons 30 testeurs vérifiés sur votre voie de test et les y maintenons pendant toute la fenêtre et au-delà, avec les rapports de test générés à la fin pour le formulaire d'accès à la production. Le compte ne dépend pas de votre groupe de discussion qui serait encore vivant le onzième jour.

Le bilan honnête

Le recrutement se fait le premier jour. Le test se passe dans les treize autres jours, et ce sont ceux-là qui n'apparaissent jamais dans le calendrier.

Une attention quotidienne pendant quatorze jours vous mène au formulaire. Un renvoi vous renvoie pour quatorze jours de plus avant de pouvoir le remplir à nouveau.

Sources

  1. Aide Google Play Console : exigences de test pour les nouveaux comptes de développeur personnel, pour le minimum de testeurs, la règle d'inscription continue, l'engagement comme motif de test prolongé, le formulaire de demande et le calendrier de l'examen.
par Console Testers

Prêt à franchir le cap du Play Store ?

Lancez votre compte à rebours de 14 jours dès aujourd'hui.

Lancer ma campagne