Crawlbase est le client numéro un, si bien que le premier passage sérieux de Knockwire a visé notre propre activité. Nous avons écrit un profil client idéal à partir de ce que nous croyions de nos meilleurs comptes, pointé le système dessus, puis nous nous sommes assis et avons lu les cent premiers refus dans l'ordre. Le profil était faux en deux endroits. Les deux erreurs étaient visibles dans les entreprises que nous avons refusées et invisibles dans celles qui se sont qualifiées.
01Lisez les refus, pas les victoires
L'index des refus est la partie de ce produit qui publie ce qui a été décliné et pourquoi. Chaque rejet porte un motif écrit plutôt qu'un code, ce qui veut dire que le relevé se lit comme de la prose au lieu de se compter, et le lire de bout en bout est un exercice différent de faire défiler la liste des qualifiées.
La liste des qualifiées vous donne raison. Elle le doit. Une entreprise s'est qualifiée parce qu'elle correspondait au profil que vous avez écrit, si bien qu'une page d'entreprises qualifiées est une page de vos propres hypothèses rendues avec des logos dessus. Les refus sont le seul endroit où le profil rencontre quelque chose qu'il n'avait pas prévu. Une entreprise qui franchit toutes les étapes sauf une, avec un motif écrit sur celle qui l'a arrêtée, est un petit argument contre la règle qui l'a arrêtée.
Deux de ces groupes ne disent rien de nous. Les entreprises mortes relèvent de l'hygiène, et aucune porte utilisable est un fait au sujet d'un site plutôt qu'au sujet de notre profil. Les trois autres sont le profil mis à l'épreuve, et deux d'entre eux nous contredisaient par écrit.
02Première erreur : nous avions écrit les entreprises qui ont besoin de données
Notre cible affichée était les entreprises qui ont besoin de données. C'est le genre de phrase qui survit à un atelier parce que personne ne peut la contredire, et elle était fausse comme les phrases larges le sont d'habitude. Elle admettait beaucoup trop, et les étapes derrière elle ont passé tout le passage à rejeter le surplus.
Trente-quatre des cent premiers refus portaient une version du même motif écrit : la donnée est ici une entrée, pas le produit. Chacune de ces entreprises avait franchi le contrôle de profil. Une société de logistique qui scrape les tarifs des transporteurs a un vrai besoin de données. Un détaillant qui surveille les prix des concurrents aussi, et une banque qui filtre des listes de sanctions également. Dans les trois cas, la collecte est un poste que quelqu'un aux finances cherche à réduire, et ce fait fixe le plafond de ce qu'ils dépenseront jamais.
Un refus comme celui-là se lit comme un échec de peu. Trente-quatre se lisent comme une définition. L'étape des preuves avait trouvé l'attribut qui manquait à la phrase de notre profil, et l'écrivait en clair, une fois par entreprise, depuis quinze jours, avant que quiconque ne lise le relevé depuis le début.
Nos douze premiers comptes en chiffre d'affaires cumulé ne ressemblent en rien à ces trente-quatre. Chacun des douze vend un produit de données. La collecte est leur coût des ventes plutôt qu'une activité annexe, ce qui explique que leur dépense monte quand l'activité va bien au lieu de baisser quand le budget est revu. Ils se regroupent sur trois familles de cibles, les places de marché, le voyage, et les données de personnes ou d'entreprises, et chacune de ces cibles bloque le trafic ordinaire.
La cible n'est donc pas une entreprise qui a besoin de données. C'est une entreprise dont le produit est la donnée, qui fait déjà du scraping, et qui peine avec. Cette version est plus étroite, plus nette, et répondable au moment de la lecture, parce que vous pouvez regarder une entreprise et voir ce qu'elle vend. Vous ne pouvez pas regarder une entreprise et voir à quel point elle a besoin de quelque chose.
03Deuxième erreur : nous comptions des têtes au lieu du volume
La deuxième erreur était plus discrète et nous a coûté davantage, parce qu'elle refusait des entreprises au lieu de simplement gâcher des lectures sur elles. Nous avions mis un seuil d'effectif dans le profil en supposant que la taille de l'entreprise prédit le budget.
La taille prédit bien le budget, faiblement, et dans le mauvais sens pour ce marché. Plusieurs des comptes les plus solides de notre portefeuille sont de petites équipes avec un volume très lourd : des entreprises mono-produit où une poignée d'ingénieurs fait tourner une collecte continue contre des cibles qui résistent. L'effectif est un indicateur indirect de la dépense, et c'est un mauvais indicateur dès lors que le produit est la donnée, parce que le volume vient de la cible du crawl et non de l'organigramme. Huit personnes qui indexent une place de marché aux millions d'annonces dépensent plus que quatre cents personnes qui tirent une liste de prix concurrente chaque lundi.
Dans le relevé, cela s'est manifesté comme une contradiction plutôt que comme un motif récurrent. Quatorze entreprises ont été refusées sur la taille tout en portant des preuves fortes sur tout le reste, si bien que leurs motifs écrits se lisaient comme des arguments contre eux-mêmes : qualifiée sur la famille de cibles, qualifiée sur les preuves de collecte, sous le seuil d'effectif. Une fois que vous avez une douzaine de refus de cette forme, vous n'avez pas un seuil d'effectif. Vous avez un bug que vous n'avez pas encore reconnu.
Nous avons retiré le seuil et mis deux questions observables à sa place : la famille de cibles bloque-t-elle le trafic ordinaire, et la surface publique suppose-t-elle une collecte continue plutôt qu'un projet avec une date de fin. Les deux se répondent depuis des preuves qu'une source a réellement renvoyées. Aucune ne nous demande de deviner une masse salariale.
04Un profil client idéal est une hypothèse
La leçon générale porte sur la nature de l'objet qu'est un profil. Nous traitions le nôtre comme une description de clients que nous avions déjà, alors que c'était en réalité une hypothèse : écrite avant les preuves, reportée sans examen, et jamais éprouvée contre ce qu'elle excluait. Une description se vérifie en regardant. Une hypothèse se vérifie en observant ce qu'elle jette, et un relevé de refus est le registre de tout ce qu'un profil a jeté, avec le motif attaché.
Cela change ce que l'on fait des cent premiers de n'importe quoi. L'instinct est de lire les entreprises qualifiées et de décider si le système fonctionne. Le passage utile est de lire les refus et de décider si le profil fonctionne. Dans notre cas, le système a fait exactement ce qu'on lui avait dit, deux fois, et ce qu'on lui avait dit était faux.
Ce qui nous amène à ce que nous refusons de faire ici. Nous n'ajustons pas discrètement le profil dans le dos de l'opérateur. Rien dans ce pipeline n'auto-règle le profil client idéal à partir des comportements de validation et de refus, alors même que les données pour le faire sont là et que la démonstration serait excellente.
La raison est qu'un profil auto-ajusté rend l'index des refus illisible. L'index ne vaut d'être publié que si un motif signifie la même chose en mars qu'en janvier. Si les règles dérivent d'elles-mêmes, personne ne peut dire si une entreprise a été déclinée parce que sa situation a changé ou parce que la règle a bougé sous elle, et chaque refus historique devient une affirmation au sujet d'une version du profil qui n'a jamais été écrite.
Le système propose donc et l'opérateur décide. Quand les refus se regroupent, nous faisons remonter le groupe : voici trente-quatre entreprises déclinées pour le même motif écrit, voici l'étape qui les a déclinées, voici le changement du profil qui les aurait laissées passer, et voici ce que ce changement aurait fait au reste du passage. L'opérateur le lit et tranche. Un changement du profil client idéal est une décision avec une date et un nom dessus, et les deux erreurs ci-dessus ont été corrigées ainsi, au grand jour, par une personne.