Plus tôt cette année, mon manager m'a envoyé un article très intéressant de Data Colada, un article de blog écrit par trois spécialistes du comportement qui examine les recherches publiées. Les auteurs de Data Colada ont travaillé avec une équipe de chercheurs anonymes et ont trouvé de curieuses anomalies dans un ensemble de données de kilométrage automobile qui a été utilisé dans un article de 2012. Je suis chargé de tester le Explorer les modèles plate-forme dans JMP , qui peut être utilisé pour identifier des modèles inhabituels ou inattendus dans les données. Dans cet article, j'utilise Explorer les modèles, ainsi que d'autres outils utiles dans JMP, pour rechercher des modèles inattendus ou inhabituels dans les données de kilométrage de la voiture.
Fond
Les premières lignes et colonnes de l'ensemble de données de kilométrage de la voiture sont présentées ci-dessous. Ces données ont été recueillies à partir d'une étude dans laquelle 13 488 clients d'une agence d'assurance automobile particulière ont été invités à déclarer leurs lectures d'odomètre actuelles. Les lectures signalées par les clients sont incluses dans les données en tant que colonnes update_car1 à update_car4, car chaque client a signalé des informations pour un maximum de quatre voitures. Les données contiennent également les lectures du compteur kilométrique pour chaque véhicule lorsque les polices d'assurance ont été émises pour la première fois. Ces colonnes sont nommées baseline_car1 à baseline_car4. Étant donné que toutes les polices n'ont pas été émises en même temps, le temps écoulé entre la ligne de base et la mise à jour varie selon les observations de cette étude.
Dans le post Data Colada, les chercheurs ont présenté quatre anomalies qui ont été trouvées dans cet ensemble de données. Examinons chacun de ces résultats à l'aide de JMP.
Anomalie #1 : La répartition des kilomètres parcourus est uniforme
Les auteurs de Data Colada ont constaté que la répartition des kilomètres parcourus correspondait à une répartition uniforme allant de 0 à 50 000 milles.
Étant donné que les données incluent une colonne de référence et de mise à jour pour les lectures du compteur kilométrique de chaque voiture, nous créons des colonnes de formules pour stocker les kilomètres parcourus en soustrayant les valeurs de référence des valeurs mises à jour. Dans JMP, nous utilisons ensuite la plate-forme Distribution pour afficher la distribution des valeurs de référence et de mise à jour, ainsi que le nombre total de kilomètres parcourus pour chaque voiture. Considérez le rapport Distribution de la première voiture pour chaque client.
La forme de la distribution du kilométrage de base est similaire à la distribution du kilométrage mis à jour, avec le compteur kilométrique médian lisant environ 26 000 miles plus haut au moment de la mise à jour. Ce constat n'est pas en soi surprenant. Ce que je trouve le plus intéressant dans les lectures de base et de mise à jour, c'est que deux participants possédaient des véhicules qui ont parcouru près d'un million de kilomètres ! Ils doivent avoir une très bonne mécanique.
La partie la plus alarmante du rapport est la troisième distribution ci-dessus, montrant la différence entre les deux premières. La répartition des kilomètres parcourus entre les temps de référence et de mise à jour semble être uniformément répartie entre 0 et 50 000 milles. Il n'y a pas de valeurs supérieures à 50 000 milles et chaque case de l'histogramme contient approximativement le même nombre de participants. L'inspection visuelle donne une preuve solide dans ce cas que les données sont uniformément réparties. Cependant, pour les données qui ne sont pas aussi évidentes, vous pouvez effectuer un test d'adéquation à l'aide de l'option Fit Beta dans la plate-forme de distribution .
La capture d'écran ci-dessous montre la répartition des kilomètres parcourus (mise à jour – référence) pour chacune des voitures des participants. Nous constatons que chaque distribution apparaît uniformément répartie entre 0 et 50 000 pour les deuxième, troisième et quatrième voitures également. Sur la base de ce modèle de distribution, nous pouvons conclure que les valeurs de kilométrage mises à jour pourraient avoir été générées en ajoutant des valeurs aléatoires uniformément distribuées aux valeurs de kilométrage de base.
Anomalie n°2 : le kilométrage de référence a été arrondi, et les kilométrages mis à jour ne l'ont pas fait
Les auteurs de Data Colada ont découvert que le kilométrage de base avait de nombreuses valeurs arrondies au millier le plus proche alors que le kilométrage mis à jour ne contenait pas cet arrondi.
Les chercheurs de Data Colada ont étudié l'arrondi en examinant les trois derniers chiffres des kilométrages. Nous pourrions utiliser JSL pour adopter une approche similaire, mais utilisons plutôt Explorer Patterns ! Si vous n'avez jamais utilisé Explorer les modèles auparavant, vous pouvez le trouver en sélectionnant Analyser > Filtrage.
Après avoir lancé Explorer les modèles pour explorer chaque ligne de base et mettre à jour la colonne, nous obtenons la sortie vue dans la capture d'écran suivante. Dans le rapport Modèles univariés, sélectionnez la ligne de base et mettez à jour les valeurs de la première voiture pour comparer les modèles.
Par défaut, Explorer les modèles inclut les rapports pour les valeurs les plus dupliquées dans chaque colonne, les exécutions les plus longues dans chaque colonne et les séquences dupliquées les plus longues dans chaque colonne. Pour la première voiture détenue par les participants, il n'y a pas grand-chose à gagner des rapports des plus longues courses ou des plus longues séquences en double. Cependant, le rapport Valeurs les plus dupliquées montre un contraste intéressant. Dans les kilométrages de base de la première voiture possédée, de nombreuses valeurs semblent être arrondies au 10 000 le plus proche. Ce n'est pas nécessairement un modèle inattendu à trouver ; quand on me demande le kilométrage de mon véhicule, je fais toujours le tour pour répondre.
Le rapport Valeurs les plus dupliquées pour les kilométrages mis à jour est assez différent. Dans ce rapport, il y a beaucoup moins de doublons et les doublons qui apparaissent ne sont pas arrondis comme les valeurs de référence. C'est ce qui se produirait si les colonnes de mise à jour étaient générées en ajoutant des valeurs aléatoires uniformément distribuées aux valeurs de base. Par conséquent, ce résultat est cohérent avec l'anomalie n°1.
Anomalie #3 – Les données ont été saisies dans deux polices, et chaque observation a un « jumeau » dans l'autre police
Les chercheurs ont remarqué que dans le fichier de données d'origine, les observations étaient enregistrées à l'aide de deux polices de caractères différentes. Grâce à un tri intelligent, les chercheurs ont découvert que chaque observation de base dans une police correspondait à une ligne très similaire dans l'autre police.
Je félicite les chercheurs d'avoir remarqué les différentes polices et d'avoir adopté cette approche. Cependant, supposons que les données soient toutes dans la même police et que ce drapeau rouge n'ait pas été levé. Pouvons-nous utiliser JMP pour identifier des relations curieuses entre les lignes et les colonnes ? Bien sûr que nous le pouvons – c'est le blog JMP après tout.
Nous pouvons utiliser Explorer les modèles pour rechercher s'il existe des relations linéaires entre les colonnes pour les lignes contiguës. Considérez l'exemple simple suivant. Dans les quatre premières lignes, les colonnes ont une relation linéaire exacte où Y=2*X. Dans les trois lignes suivantes, les deux colonnes ont à nouveau une relation linéaire exacte où Y=0,5*X.
Nous pouvons utiliser Explorer les modèles pour rechercher des relations linéaires comme celle-ci entre les colonnes de ligne de base. Si nous n'avions pas déjà remarqué l'anomalie #1, il serait logique de rechercher également des relations linéaires dans les colonnes mises à jour.
S'il y avait de nombreuses relations linéaires exactes, ou peut-être de grandes séries de relations linéaires, cela peut être un signe que les valeurs d'une colonne ont été générées à l'aide d'un multiple d'une autre colonne. Ici, il n'y a que quelques lignes pour lesquelles les colonnes de ligne de base ont une relation linéaire exacte. Nous pourrions utiliser l'option Coloriser pour afficher ces cellules et rechercher d'éventuelles irrégularités, mais pour un ensemble de données de cette taille avec de nombreuses valeurs arrondies, il n'est pas surprenant de trouver quelques relations linéaires.
À l'aide d'Explorer les modèles, nous avons recherché s'il existe des relations linéaires suspectes entre les lignes de deux colonnes pour les valeurs de base. Cependant, les résultats n'étaient pas très utiles. Maintenant, recherchons également les relations linéaires entre les colonnes parmi deux lignes, encore une fois pour les valeurs de base. Pour ce faire, nous devrons utiliser Explore Patterns sur la transposition de nos données.
J'ai utilisé l'option Transposer dans JMP pour transposer les données par les colonnes de référence, pour les participants qui ont déclaré le kilométrage d'au moins trois véhicules. J'ai exclu les rangées où les participants avaient deux voitures ou moins, car elles n'aideraient pas à identifier les relations linéaires.
Dans le rapport Explorer les modèles pour ces données transposées, il existe de nombreuses relations linéaires exactes où la pente est d'environ un. Ainsi, il existe de nombreuses lignes dans la table de données d'origine qui ont une ligne presque jumelle de valeurs de base pour les voitures. (Conseil : vous pouvez cliquer avec le bouton droit sur la colonne Pente et utiliser la fonction Sélectionner où pour mettre en surbrillance toutes les lignes où la pente est proche de un. Il y a 69 paires où la pente est comprise entre 0,99 et 1,01).
Vous pouvez sélectionner Coloriser au-dessus du tableau des relations linéaires pour colorer toutes les valeurs dans une relation linéaire exacte, ou vous pouvez cliquer avec le bouton droit sur la colonne Y pour colorer des valeurs spécifiques. Le tableau ci-dessous contient les valeurs colorisées pour les trois premières lignes du rapport Relations linéaires.
Explore Patterns a identifié plusieurs paires de « jumelles de conduite » où les valeurs de kilométrage de base étaient très similaires pour toutes les voitures, ayant une relation linéaire exacte. Nous pourrions poursuivre sur cette question en recherchant plus de paires qui n'ont pas de relation linéaire exacte mais qui sont toujours très étroitement liées. Comme illustré dans l'article Data Colada, une fois que vous avez trié par valeur de référence pour la quatrième voiture, il est facile d'identifier de nombreux jumeaux de conduite.
Anomalie #4 – Une police a de nombreuses valeurs de base arrondies, et l'autre pas
Les chercheurs ont découvert que les valeurs de base de la police Calibri étaient arrondies et que les valeurs de la police Cambria n'étaient pas arrondies.
Maintenant, supposons que nous sachions que certaines lignes ont été écrites dans une police et les autres lignes ont été écrites dans une deuxième police, et que nous avons une colonne dans nos données avec la police pour chaque ligne. Nous pouvons utiliser Explorer Patterns avec le nom de la police comme colonne By.
Comme le montrent les rapports Explorer les modèles, les valeurs de kilométrage de base pour les lignes de la police Calibri ont de nombreuses valeurs arrondies, tandis que les valeurs de base pour les lignes Cambria ne sont pas arrondies. Étant donné que nous nous attendons à ce que les kilométrages déclarés par les clients soient arrondis, cela suggère que les valeurs déclarées d'origine étaient les lignes avec la police Calibri et que les données « driving twin » ont été créées puis saisies dans la police Cambria.
Conclusion
Chaque fois que vous acquérez un nouvel ensemble de données, vous effectuez probablement une analyse exploratoire et un nettoyage des données. Peut-être toi rechercher des valeurs aberrantes , vérifier les données pour les valeurs manquantes , ou afficher la distribution de chaque variable. J'espère que cet article vous a encouragé à envisager d'utiliser Explore Patterns pour rechercher des modèles inhabituels dans vos données. Tous les modèles que vous trouvez en utilisant Explorer les modèles ne sont pas la preuve que quelque chose ne va pas ou est préoccupant, mais l'utilitaire vous fournit un outil pour trouver des modèles qui justifient une enquête plus approfondie.
