Outils de développement · Encodeur et décodeur d'URL
Pourquoi un codage d'URL incohérent divise une page en plusieurs lignes dans Analytics
· Pourquoi c'est important
analyses API encodage d'URL normalisation
%20 et +, %2F et /, %c3 et %C3 peuvent tous décrire la même URL, mais les rapports les traitent comme des pages différentes. Cet article explique d'où viennent les variantes et comment les normaliser avant de les compter.
La page de destination avec six URL dans le rapport – les variantes côte à côte et le trafic qu'elles répartissent
Les analystes de données remarquent qu'une page de destination apparaît sous la forme de six URL différentes dans les tableaux de bord d'analyse. Les mêmes pages peuvent être : /landing?utm_source=email, /landing?utm_source=%65mail, /landing?utm_source=email%20campaign, /landing?utm_source=email+campaign, /landing?utm_source=email%20Campaign, /landing?utm_source=email%2bcampaign. Chaque variante compte comme des pages vues distinctes, fragmentant le trafic. Les données provenant de feuilles de calcul, de courriers électroniques et de formulaires introduisent des variations de codage.
Un codage incohérent provient de plusieurs sources de données et transformations. Les liens écrits à la main utilisent des espaces bruts ou aucun encodage. Les exportations de feuilles de calcul produisent des URL codées en pourcentage. Les clients de messagerie modifient ou réencodent les URL. Les chaînes de redirection se normalisent de manière incohérente. Les intégrations d'API, les frameworks JavaScript et le code d'analyse appliquent des règles différentes. Le même concept d'URL traverse des couches, étant codé et réencodé différemment.
Les sources de variation : liens manuscrits, exportations de feuilles de calcul, clients de messagerie et chaînes de redirection
Le cas en chiffres hexadécimaux présente le premier problème de normalisation. La RFC 3986 spécifie que les chiffres hexadécimaux doivent être en majuscules : %2F, et non %2f. Les majuscules et les minuscules codent en hexadécimal des octets identiques. Une comparaison stricte traite %2F et %2f différemment. Le caractère « e » comme %65 devrait être normalisé en « e » non codé car la RFC 3986 classe les lettres comme non réservées. Le surcodage d'URL entières produit différents enregistrements d'analyse.
L'ensemble non réservé dans la RFC 3986 comprend : A-Z, a-z, 0-9, trait d'union, point, trait de soulignement et tilde. Ceux-ci ne doivent jamais être codés en pourcentage dans les URL normalisées. La normalisation RFC spécifie que le décodage %41 en « A » doit être normalisé en « A » non codé. L'application de cela sur les URL supprime le codage redondant. Les URL telles que %2f%6c%61%6e%64%69%6e%67 deviennent /landing après décodage.
Cas en chiffres hexadécimaux et ensemble non réservé — ce que dit la RFC 3986 est équivalent et ce qui ne l'est pas
Les caractères réservés ne sont pas interchangeables et doivent rester distincts lors de la normalisation. La RFC 3986 réserve les gen-delims (:, /, ?, #, [, ], @) et les sous-delims (!, $, &, ', (, ), *, +, ,, ;, =). Ceux-ci ont une signification structurelle. Les barres obliques dans les chemins fonctionnent comme des séparateurs et ne doivent pas être codées. Lorsque le même caractère apparaît comme données dans les valeurs de requête, il doit être codé sous la forme %2F. Le décodage aveugle brise la structure de l’URL.
Les nuances de normalisation créent des défis nécessitant une compréhension contextuelle. Décodez uniquement les caractères non réservés, en laissant les caractères réservés codés. Les URL telles que /landing?data=%2F%20%2f restent ambiguës. Les chaînes de requête commencent par ? (réservé, structurel). Dans les valeurs de requête, tout peut apparaître : les points d'interrogation nécessitent un encodage %3F. Les URL codées en %2f%6c%61%6e%64%69%6e%67%3fkey%3dvalue se normalisent à /landing?key=value.
Les caractères réservés ne sont pas interchangeables : pourquoi %2F et / peuvent légitimement signifier des choses différentes
Exemple concret : la normalisation de six variantes d'URL démontre une normalisation complète. L'URL de base représente /page?utm_source=email&campaign=test. Six variantes : 1) /page?utm_source=email&campaign=test (canonique), 2) /page?utm_source=%65%6d%61%69%6c&campaign=test (minuscule hexadécimal), 3) /page?utm_source=email%20&campaign=test (espace en valeur), 4) /page?utm_source=email+&campaign=test (plus comme espace), 5) /page?utm_source=EMAIL&campaign=test (cas différent), 6) /page?utm_source=email&%63ampaign=test (hexadécimal dans le nom).
La variante de normalisation 2 nécessite de corriger la casse hexadécimale et de décoder les lettres non réservées : %65%6d%61%69%6c devient un e-mail. La variante 4 avec des signes plus nécessite une prise en compte du contexte : si les sources sont des formulaires HTML, plus signifie espace ; sinon, plus est littéral. La variante 5 comporte « EMAIL » en majuscule ; « e-mail » minuscule est canonique puisque les e-mails ne sont pas sensibles à la casse. La variante 6 a %63 (hexadécimal pour "c") ; le décodage sans réserve produit une correspondance canonique de « campagne ».
Exemple concret : normaliser six variantes d'une URL – décoder les caractères sécurisés, corriger la casse hexadécimale et ce qui reste distinct
La mise en œuvre de la normalisation dans les pipelines (normaliser lors de l'ingestion et conserver les valeurs brutes) est une architecture recommandée pour l'analyse. Aux points d'ingestion où les URL entrent dans les bases de données (points de terminaison de journalisation), appliquez la normalisation avant de stocker ou de dériver les clés d'affichage de page. Normalisation : 1) Analyser les URL en composants, 2) Décoder les séquences non réservées (corriger la casse hexadécimale), 3) Normaliser l'ordre des paramètres, 4) Produire des formulaires canoniques pour le regroupement, 5) Stocker les formulaires normalisés et les valeurs brutes. Cela garantit que les six variantes sont hachées sur la même clé de groupe.
Les fonctions de hachage basées sur des URL normalisées garantissent que toutes les variantes correspondent à des pages identiques dans les rapports. Si les systèmes d'analyse manquent de normalisation intégrée, les couches d'ingénierie des données (pipelines ETL) se normalisent avant l'écriture de la base de données. Pour des outils comme Google Analytics, les filtres configurables permettent le regroupement d'expressions régulières ou l'envoi de titres distincts des URL. Les approches les plus robustes normalisent les sources : lorsque le code de suivi envoie des URL aux analyses, assurez-vous que les formulaires sont canonisés.
Le faire dans un pipeline - normaliser l'ingestion et conserver la valeur brute, décrite comme un modèle
Ce qui ne couvre pas comprend la suppression des paramètres de suivi et les balises canoniques pour le référencement, qui sont liées mais différentes. Les paramètres de suivi tels que utm_source et utm_campaign peuvent être supprimés des analyses pour être regroupés par contenu organique. Il s’agit d’une logique métier distincte. Les balises canoniques HTML consolident les pages vues entre les variantes pour le référencement, mais n'affectent pas les analyses internes. Les stratégies globales utilisent plusieurs couches de déduplication combinant les deux approches.
La prise en charge de la normalisation de l'espace Analytics varie considérablement. Google Analytics gère automatiquement une certaine normalisation, mais peut manquer des variantes. D'autres outils nécessitent une configuration manuelle. Les plateformes de recherche payante appliquent une normalisation différente aux URL de campagne. Les journaux du serveur enregistrent les URL telles que reçues sans normalisation. Des stratégies globales documentent la normalisation appliquée à chaque couche et les données brutes préservées pour l'audit. L'encodeur et le décodeur d'URL permettent d'inspecter les variantes.
Ce que cela ne couvre pas : politiques de suppression des paramètres de suivi et balises canoniques pour le référencement
À retenir : normalisez avant de compter : l'encodeur et le décodeur d'URL permettent d'inspecter toute variante en montrant ce qu'elle encode et si elle correspond aux formes canoniques. Pour les variantes d'analyse suspectes, collez-les dans les décodeurs en examinant les sorties décodées. Si deux URL décodent sous des formes identiques, elles représentent des pages identiques et doivent se consolider. L'outil montre exactement quels caractères codent, leurs valeurs hexadécimales et les résultats. Cette inspection est la première étape de dépannage.
Lors du dépannage des écarts d'analyse, créez des listes de toutes les variantes d'URL observées et décodez chacune avec l'encodeur et le décodeur d'URL. Comparez les formes décodées. Si les formulaires diffèrent par le contenu des données (comme les différentes valeurs utm_source), ce sont légitimement des pages différentes. S'ils diffèrent uniquement par l'encodage (comme %65mail vs email), ce sont des doublons nécessitant une normalisation. Documentez les formes canoniques et implémentez la normalisation. L'encodeur et le décodeur URL fournissent un diagnostic ; Le pipeline d'analyse fournit une solution.
À retenir : normalisez avant de compter – comment l'encodeur et le décodeur d'URL vous aident à inspecter n'importe quelle variante pour voir ce qu'elle encode réellement
À retenir : normalisez avant de compter : l'encodeur et le décodeur d'URL permettent d'inspecter toute variante en montrant ce qu'elle encode et si elle correspond aux formes canoniques. Pour les variantes d'analyse suspectes, collez-les dans les décodeurs en examinant les sorties décodées. Si deux URL décodent sous des formes identiques, elles représentent des pages identiques et doivent se consolider. L'outil montre exactement quels caractères codent, leurs valeurs hexadécimales et les résultats.
Lors du dépannage des écarts d'analyse, créez des listes de toutes les variantes d'URL observées et décodez chacune avec l'encodeur et le décodeur d'URL. Comparez les formes décodées. Si les formulaires diffèrent par le contenu des données (comme les différentes valeurs utm_source), ce sont légitimement des pages différentes. S'ils diffèrent uniquement par l'encodage (comme %65mail vs email), ce sont des doublons nécessitant une normalisation. Documentez les formes canoniques et implémentez la normalisation.