En règle générale, quel que soit le pourcentage de couverture de vos tests, ce n'est pas le cas. Quelle que soit la surface connue que vous couvrez, il y aura un ensemble passionnant de choses que vous n'aviez pas réalisé que vous deviez tester. L'analytique est tombée dans cette catégorie pour nous.

Nous utilisons Google Analytics dans notre application Web pour avoir une idée de la façon dont les utilisateurs utilisent le produit, plus récemment pour déterminer quelle fonctionnalité a été priorisée pour le Site mobile . En général, je consulte nos analyses toutes les semaines ou toutes les deux semaines pour aider les développeurs, et lorsque Simon m'a demandé de voir à quel point le site mobile était populaire, j'étais presque sûr que la réponse n'était pas « Cela a diminué l'utilisation de notre application Web de 98 %. » :

Je ne citerai pas de noms, mais le coupable rime avec « itwasian ».

Qu'est-ce qui s'est cassé

Notre interface utilisateur se compose presque entièrement de HAML Propulsé par backbone.js, souvent en même temps . Ce qui signifie que nous avons refactorisé le code par défaut de Google Analytics :

 :javascript var gaJsHost = (('https:' == document.location.protocol) ? 'https://ssl.' : 'http://www.'); document.write(unescape('%3Cscript src='' + gaJsHost + 'google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E')); :javascript // 

Vous remarquerez que cela génère deux blocs JavaScript, que nous avons judicieusement fusionnés en un seul.

C'est ce qui a tout cassé – et par tout, j'exclus certains navigateurs mobiles et rares qui ont quand même exécuté le code comme prévu. Pour 98 % de nos visiteurs, le fait que nous ayons fusionné ces deux blocs de script signifie que le DOM n'a pas le contrôle après le document.write et que le chargement de ga.js n'a pas lieu avant que _gat ne soit référencé. _gat n'existe pas et c'est la fin de nos analyses sur cette page.

La solution la plus simple consiste bien sûr à remettre le deuxième bloc de script. Mais à la place, nous sommes passés au tout dernier code asynchrone de Google Analytics, qui n'a pas besoin de 2 blocs, car il nécessite uniquement que _gaq soit un objet JavaScript, le reste des fonctionnalités venant plus tard, lorsque le navigateur s'en chargera.

 :javascript var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-8759953-1']); _gaq.push(['_setDomainName', 'pagerduty.com']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); 

Test du fonctionnement de Google Analytics

Pour m'assurer de détecter ce problème le plus tôt possible, j'ai configuré des événements d'intelligence sur notre application et le site Web dans Google Analytics pour détecter si nous avons un nombre anormalement faible ou élevé de visiteurs.

Il y a au moins un jour de retard avant que l'e-mail ne soit envoyé, ce qui est dommage (j'ai reçu le dernier pendant que j'écrivais ceci), mais c'est une autre couche dans notre réseau d'alertes. Connectez-vous à votre compte Google Analytics et vous verrez « Événements d'intelligence » :

J'ai l'intention de mettre en place des heuristiques plus avancées plus tard, mais pour l'instant, testons simplement que les analyses fonctionnent :

Cette journée de décalage a eu l'avantage, pour les tests, de m'envoyer l'alerte d'hier, alors que nos analyses étaient encore cassées (mais j'exagère vraiment en disant que c'est un avantage).

Relier le tout à PagerDuty

Ce n'est pas le genre d'alerte pour laquelle je veux être réveillé au milieu de la nuit, mais j'utilise toujours PagerDuty comme système de gestion des incidents pour mes alertes d'analyse, en partie pour le dogfooding, mais aussi pour suivre nos mentions dans les médias, nos mentions sur Twitter, etc.

Pour cela, j'ai mis en place un service qui ne résout pas automatiquement ni n'expire les accusés de réception, pour suivre tout ce qui est envoyé par e-mail à « analyze-me@pdt-dave.pagerduty.com »

Testez toutes les choses

Alors maintenant je remplis notre Bugs de brouillard avec de nouvelles choses à tester :

• Nos mailings de t-shirts
• si nous répondons assez rapidement aux demandes des clients
• tester nos temps de chargement sur le site Web, la pile d'applications, le blog et le site d'assistance (encore une fois avec des alertes automatisées de Google). Nous testons déjà cela avec Nouvelle relique .

Je n'ai pas de bonne procédure pour déterminer ce que nous oublions de tester, mais j'ai quelques principes :

• Si ça échoue une fois, ça sera testé pour toujours. Je m'attends à ce que ça se perde dans la confusion, mais apparemment nous n'avons jamais envoyé de t-shirts à une ou deux personnes à qui je les avais promis, donc ça a été automatisé et j'ai maintenant un rapport ad hoc de qui a reçu et qui n'a pas reçu ses t-shirts. Quand les choses vont mal, je l'intégrerai peut-être au suivi USPS.
• Il doit être automatique, idéalement en vous envoyant une alerte lorsque certaines mesures sont hors bande. Nous suivons notre temps de résolution avec Zendesk, donc l'un de mes projets est d'automatiser nos mesures avec automatisations
• Soyez un imbécile. Je teste le travail des autres et j'essaie de le faire échouer. Je me fiche de ce que disent les mesures de l'équipe de fiabilité, si le temps de chargement de ma page augmente, je vais exiger des réponses.

Nous sommes encore une jeune entreprise, mais nous sommes farouchement dévoués à la disponibilité et lorsque vous traitez des bugs, il y a des inconnues connues et des inconnues inconnues - et lorsque j'ai commencé ici, je n'aurais jamais su à quel point j'aimerais tirer avec des pistolets Nerf à travers le bureau chaque fois que le temps de chargement moyen des pages augmente.

(Avec un peu de chance, ce sera le premier article d’une série sur ce qui se passe lorsque vous confiez votre marketing à un mathématicien.)