로컬라이제이션 분석 이유

다음에 번역할 언어를 선택하는 것은 베팅입니다: 시간과 비용이 들며, 보상은 보통 보이지 않는 수요에 달려 있습니다. 현지화 분석은 그 수요를 가시적으로 만듭니다.

의사결정, 대시보드 아님

여기에 분석 데이터를 수집하는 목적은 좁고 의도적입니다: '언어 X 로 현지화해야 하는가?'를 생각한 것입니다. 신호들은 일반적인 분석 모음이 되도록 선택된 것이 아니라, 그 질문에 답하기 위해 선택되었습니다.

의사결정을 이끄는 세 가지 입력:

1. Demand. 이 언어를 원하는 방문자는 몇 명입니까? 브라우저 언어와 국가는 관심사가 어디에 있는지 알려줍니다.
2. 격차. 그 수요가 이미 충족되었습니까? 선호 언어를 프로젝트 대상, 페이지 언어, 그리고 광고된 번역과 비교하면 벽에 부딪히는 트래픽 비율이 드러납니다.
3. 가치. 현지화의 효과가 있을까요? 로케일 격차별 참여도, 지원되지 않는 페이지에 트래픽이 도착하는 곳, 그리고 그 트래픽의 출처는 새 로케일이 전환되는지 여부를 나타냅니다.

왜 격차가 입수 시점에 계산되는가

served_locale 는 <html lang> 에 명시된 실제 페이지 언어를 기록하며, 방문자가 받았다고 가정하는 언어를 기록하지 않습니다. has_locale_gap 는 브라우저 선호도를 프로젝트 대상, 페이지 언어, 그리고 hreflang 링크를 통해 광고된 번역과 비교합니다. 둘 다 방문 당시 상태대로 이벤트별로 저장됩니다. 이는 역사적 데이터가 그때 당신이 마주한 기회를 반영하며, 오늘의 대상에 대한 재계산이 아닙니다. 다음 달에 포르투갈어를 추가하면, 지난 달의 격차는 역술적으로 줄어들지 않습니다. 충족되지 않았던 수요에 대한 정직한 기록을 유지합니다.

특히 쿠키 없는 이유

"유니크 방문자"를 원할 때의 본능은 쿠키를 설정하거나 브라우저를 핑거프린팅하는 것입니다. 둘 다 장기 식별자를 생성하며, 대부분의 개인정보 보호 체계 아래서 핑거프린팅은 쿠키보다 삭제하기 어렵습니다. 여기서는 둘 다 불필요합니다.

하루의 유니크 방문자 수는 식별자가 하루 내 안정적으로 유지되는 것입니다. IP 와 User-Agent 의 해시를 매일 로테이션하고 프로젝트당 범위를 한정하면, 매일 방문자 수 계산을 지원하면서도 날짜 간 또는 사이트 간 연결이 불가능합니다. 이는 장기적인 재방문자 추적 기능을 제공하지 않습니다.

이 설계는 분석에서 유지되는 식별자를 제한합니다. 특정 사이트가 동의가 필요한지 확인하지는 않습니다. 이는 사이트가 분석을 사용하는 방식과 적용되는 규칙에 달려 있습니다.