개발자 도구 · URL 인코더 및 디코더
일관되지 않은 URL 인코딩으로 인해 분석에서 한 페이지가 여러 행으로 분할되는 이유
· 그것이 중요한 이유
분석 URL 인코딩 정규화
%20 및 +, %2F 및 /, %c3 및 %C3은 모두 동일한 URL을 설명할 수 있지만 보고서에서는 이를 다른 페이지로 처리합니다. 이 게시물에서는 변형이 어디서 왔는지, 계산하기 전에 변형을 정규화하는 방법을 설명합니다.
보고서에 6개의 URL이 포함된 방문 페이지 - 나란히 있는 변형과 분할된 트래픽
데이터 분석가는 분석 대시보드에서 하나의 방문 페이지가 6개의 다른 URL로 나타나는 것을 발견했습니다. 동일한 페이지는 다음과 같습니다. /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. 각 변형은 별도의 페이지 조회수, 트래픽 조각화로 계산됩니다. 스프레드시트, 이메일, 양식의 데이터에는 인코딩 변형이 발생합니다.
일관되지 않은 인코딩은 여러 데이터 소스 및 변환으로 인해 발생합니다. 손으로 작성한 링크는 원시 공백을 사용하거나 인코딩을 사용하지 않습니다. 스프레드시트 내보내기는 백분율로 인코딩된 URL을 생성합니다. 이메일 클라이언트는 URL을 조작하거나 다시 인코딩합니다. 리디렉션 체인이 일관되지 않게 정규화됩니다. API 통합, JavaScript 프레임워크 및 분석 코드는 서로 다른 규칙을 적용합니다. 동일한 URL 개념이 레이어를 통과하여 다르게 인코딩되고 다시 인코딩됩니다.
변형 소스 — 직접 작성한 링크, 스프레드시트 내보내기, 메일 클라이언트 및 리디렉션 체인
16진수 사례는 첫 번째 정규화 문제를 나타냅니다. RFC 3986에서는 16진수를 대문자로 지정합니다(%2f가 아니라 %2F). 대문자와 소문자 16진수는 동일한 바이트를 인코딩합니다. 엄격한 비교에서는 %2F와 %2f를 다르게 처리합니다. RFC 3986는 문자를 예약되지 않은 문자로 분류하므로 %65 문자 "e"는 인코딩되지 않은 "e"로 정규화되어야 합니다. 전체 URL을 과도하게 인코딩하면 다양한 분석 기록이 생성됩니다.
RFC 3986의 예약되지 않은 세트에는 A-Z, a-z, 0-9, 하이픈, 마침표, 밑줄 및 물결표가 포함됩니다. 이는 정규화된 URL에서 백분율로 인코딩되어서는 안 됩니다. RFC 정규화는 "A"에 대한 %41 디코딩이 인코딩되지 않은 "A"로 정규화되어야 함을 지정합니다. 이를 URL 전체에 적용하면 중복 인코딩이 제거됩니다. %2f%6c%61%6e%64%69%6e%67와 같은 URL은 디코딩 후 /landing이 됩니다.
16진수 대소문자 및 예약되지 않은 세트 — RFC 3986에서 말하는 것과 동일하지 않은 것
예약 문자는 서로 바꿔 사용할 수 없으며 정규화 중에 고유하게 유지되어야 합니다. RFC 3986는 gen 구분 기호(:, /, ?, #, [, ], @) 및 하위 구분 기호(!, $, &, ', (, ), *, +, ,, ;, =)를 예약합니다. 이것들은 구조적인 의미를 가지고 있습니다. 경로의 슬래시는 구분 기호 역할을 하며 인코딩해서는 안 됩니다. 쿼리 값에 동일한 문자가 데이터로 나타날 경우 %2F로 인코딩해야 합니다. 맹목적으로 디코딩하면 URL 구조가 깨집니다.
정규화의 미묘한 차이로 인해 상황에 맞는 이해가 필요한 문제가 발생합니다. 예약되지 않은 문자만 디코딩하고 예약된 문자는 인코딩된 상태로 둡니다. /landing?data=%2F%20%2f와 같은 URL은 여전히 모호합니다. 쿼리 문자열은 ?로 시작합니다. (예약됨, 구조적). 쿼리 값 안에는 무엇이든 나타날 수 있습니다. 물음표에는 %3F 인코딩이 필요합니다. %2f%6c%61%6e%64%69%6e%67%3fkey%3dvalue로 인코딩된 URL은 /landing?key=value.로 정규화됩니다.
예약 문자는 서로 바꿔 사용할 수 없습니다. 왜 %2F와 /가 합법적으로 다른 의미를 가질 수 있습니까?
작업된 예: 6개의 URL 변형을 정규화하면 완전한 정규화를 보여줍니다. 기본 URL은 /page?utm_source=email&campaign=test. 6가지 변형을 나타냅니다. 1) /page?utm_source=email&campaign=test(표준), 2) /page?utm_source=%65%6d%61%69%6c&campaign=test(소문자 16진수), 3) /page?utm_source=email%20&campaign=test(값의 공백), 4) /page?utm_source=email+&campaign=test(공백으로 추가), 5) /page?utm_source=EMAIL&campaign=test(다른 대소문자), 6) /page?utm_source=email&%63ampaign=test(이름의 16진수).
변형 2을 정규화하려면 16진수 대소문자를 수정하고 예약되지 않은 문자를 디코딩해야 합니다. %65%6d%61%69%6c는 이메일이 됩니다. 더하기 기호가 있는 변형 4에는 상황 인식이 필요합니다. 소스가 HTML 형식인 경우 더하기는 공백을 의미합니다. 그렇지 않으면 플러스는 문자 그대로입니다. 변형 5에는 대문자 "EMAIL"이 있습니다. 이메일은 대소문자를 구분하지 않으므로 소문자 "email"은 표준입니다. 변형 6에는 %63("c"의 경우 16진수)이 있습니다. 예약되지 않은 디코딩은 표준과 일치하는 "캠페인"을 생성합니다.
작업된 예: 하나의 URL의 6개 변형 정규화 — 안전한 문자 디코딩, 16진수 대소문자 수정 및 구별되는 사항
파이프라인에서 정규화 구현(수집 시 정규화하고 원시 값 유지)은 분석을 위해 권장되는 아키텍처입니다. URL이 데이터베이스(로깅 엔드포인트)에 입력되는 수집 지점에서 페이지 조회 키를 저장하거나 파생하기 전에 정규화를 적용합니다. 정규화: 1) URL을 구성 요소로 구문 분석, 2) 예약되지 않은 시퀀스 디코딩(16진수 대소문자 수정), 3) 매개변수 순서 정규화, 4) 그룹화를 위한 표준 형식 생성, 5) 정규화된 형식과 원시 값을 저장합니다. 이렇게 하면 6개 변형이 모두 동일한 그룹 키로 해시됩니다.
정규화된 URL을 기반으로 하는 해시 함수는 모든 변형이 보고서의 동일한 페이지에 매핑되도록 합니다. 분석 시스템에 기본 제공 정규화가 부족한 경우 데이터 엔지니어링 계층(ETL 파이프라인)은 데이터베이스 쓰기 전에 정규화됩니다. Google Analytics와 같은 도구의 경우 구성 가능한 필터를 사용하면 정규식 그룹화 또는 URL과 별도로 제목을 보낼 수 있습니다. 가장 강력한 접근 방식은 소스에서 정규화됩니다. 추적 코드가 분석에 URL을 보낼 때 정규화된 형식을 보장합니다.
파이프라인에서 수행 — 수집 시 정규화하고 패턴으로 설명된 원시 값을 유지합니다.
여기서 다루지 않는 내용에는 관련이 있지만 다른 SEO용 추적 매개변수 제거 및 표준 태그가 포함됩니다. utm_source 및 utm_campaign과 같은 추적 매개변수는 분석에서 제거되어 유기적 콘텐츠별로 그룹화될 수 있습니다. 이는 별도의 비즈니스 로직입니다. HTML 표준 태그는 SEO에 대한 변형 전체의 페이지 조회수를 통합하지만 내부 분석에는 영향을 미치지 않습니다. 포괄적인 전략에서는 두 가지 접근 방식을 결합한 여러 중복 제거 계층을 사용합니다.
분석 공간 정규화 지원은 매우 다양합니다. Google Analytics는 일부 정규화를 자동으로 처리하지만 변형이 누락될 수 있습니다. 다른 도구에는 수동 구성이 필요합니다. 유료 검색 플랫폼은 캠페인 URL에 다른 정규화를 적용합니다. 서버 로그는 정규화 없이 수신된 URL을 기록합니다. 포괄적인 전략은 각 계층에 적용된 정규화와 감사를 위해 보존된 원시 데이터를 문서화합니다. URL 인코더 및 디코더는 변형을 검사하는 데 도움이 됩니다.
여기서 다루지 않는 내용 — SEO용 추적 매개변수 제거 정책 및 표준 태그
요약: 계산하기 전에 정규화합니다. URL 인코더 및 디코더는 인코딩하는 내용과 표준 형식과 일치하는지 여부를 보여주는 모든 변형을 검사하는 데 도움이 됩니다. 의심스러운 분석 변형의 경우 디코딩된 출력을 검사하는 디코더에 붙여넣습니다. 두 개의 URL이 동일한 형식으로 디코딩되면 동일한 페이지를 나타내며 통합되어야 합니다. 이 도구는 인코딩된 문자, 해당 문자의 16진수 값 및 결과를 정확하게 보여줍니다. 이 검사는 첫 번째 문제 해결 단계입니다.
분석 불일치 문제를 해결할 때 관찰된 모든 URL 변형의 목록을 만들고 URL 인코더 및 디코더를 사용하여 각각을 디코딩합니다. 디코딩된 형식을 비교합니다. 양식의 데이터 내용이 다른 경우(예: 다른 utm_source 값) 합법적으로 다른 페이지입니다. 인코딩만 다른 경우(예: %65mail과 이메일) 정규화가 필요한 중복입니다. 표준 형식을 문서화하고 정규화를 구현합니다. URL 인코더 및 디코더가 진단을 제공합니다. 분석 파이프라인이 솔루션을 제공합니다.
요약: 계산하기 전에 정규화 — URL 인코더 및 디코더를 사용하여 변형을 검사하여 실제로 인코딩된 내용을 확인하는 방법
요약: 계산하기 전에 정규화합니다. URL 인코더 및 디코더는 인코딩 내용과 표준 형식과 일치하는지 여부를 보여주는 모든 변형을 검사하는 데 도움이 됩니다. 의심스러운 분석 변형의 경우 디코딩된 출력을 검사하는 디코더에 붙여넣습니다. 두 개의 URL이 동일한 형식으로 디코딩되면 동일한 페이지를 나타내며 통합되어야 합니다. 이 도구는 인코딩된 문자, 해당 문자의 16진수 값 및 결과를 정확하게 보여줍니다.
분석 불일치 문제를 해결할 때 관찰된 모든 URL 변형의 목록을 만들고 URL 인코더 및 디코더를 사용하여 각각을 디코딩합니다. 디코딩된 형식을 비교합니다. 양식의 데이터 내용이 다른 경우(예: 다른 utm_source 값) 합법적으로 다른 페이지입니다. 인코딩만 다른 경우(예: %65mail과 이메일) 정규화가 필요한 중복입니다. 표준 형식을 문서화하고 정규화를 구현합니다.