Html5-boilerplate: 사용 가능한 경우 Google Analytics 추적에 localStorage 사용

Modernizr을 종속성으로 잠그고 싶은지 확실하지 않습니다.

어쩌면 문서에 추가하는 것이 가장 좋을까요?

또한 ping @mathiasbynens.

스니핑을 최적화해주셔서 감사합니다, David. @alrra 로서 나는 그것을 문서에 추가하는 것이 좋다고 생각합니다.

크레딧은 제 소유가 아닙니다. 이것은 @elmerbulthuis에 의해 제 주의를 끌었습니다. 비록 이것이 _snippet_ 자체의 최적화라고 생각하지는 않지만, 그 자체로 --- 웹 전체의 최적화에 가깝습니다 :-p.

모두가 localStorage 솔루션을 채택한다면 전 세계적으로 얼마나 많은 바이트를 절약할 수 있을지 궁금합니다.

나는 분명히 이 솔루션의 열렬한 팬입니다. 기본적으로 보일러플레이트에 포함하는 것과 관련된 유일한 문제는 @davidmurdoch 가 언급한 문제입니다. 먼저 localStorage 에 대한 기능 테스트가 필요합니다. 이것은 Modernizr를 사용하거나 작은 독립 실행형 코드 를 추가하여 수행할 수 있지만 어느 쪽이든 페이지 크기가 약간 증가합니다. 그런 다음 영향을 받는 도메인의 리소스에 대한 요청 헤더에 쿠키가 전송되지 않기 때문에 장기적으로 많은 바이트를 절약할 수 있습니다.

이 같은:

(function(b,o,i,l,e,r){b.GoogleAnalyticsObject=l;b[l]||(b[l]=
function(){(b[l].q=b[l].q||[]).push(arguments)});b[l].l=+new Date;
e=o.createElement(i);r=o.getElementsByTagName(i)[0];
e.src='//www.google-analytics.com/analytics.js';
r.parentNode.insertBefore(e,r)}(window,document,'script','ga'));
(function(){var a=(function(){var c=new Date,b;try{
localStorage.setItem(c,c);b=localStorage.getItem(c)==c;
localStorage.removeItem(c);return b&&localStorage}catch(d){}}());
ga('create','UA-XXXXX-X',a?{storage:'none',clientId:a.gaId}:{});
ga(function(b){a.gaId=b.get('clientId')});ga('send','pageview')}());

(http://mathiasbynens.be/notes/localstorage-pattern에서 가져온 localStorage 기능 테스트를 사용합니다.)

몇 가지 빠른 테스트 후에 잘 작동하는 것 같습니다. 이것을 더 광범위하게 테스트한 후 PR을 작성하겠습니다. (물론 환영합니다!)

참고: 영향을 받는 도메인에 대한 각 요청에 대해 왕복당 약 33개의 원시 바이트(헤더/쿠키가 압축되지 않음)를 절약할 수 있습니다.

@mathiasbynens ' 현재 인라인 기능 감지 솔루션은 130 압축 바이트* 더 큽니다(분명히 이것은 각 고유 페이지마다 다르지만 대략적인 아이디어를 제공합니다). 그래서 우리는 우리가 이것을 조금 더 골프를 칠 수 있는지 봐야 할 것입니다.

개인적으로 gzip으로 압축된 diff를 65바이트까지 보고 싶고 곧 직접 시도해 볼 것입니다. :-)

_*이 디플레이터 사용: http://www.vervestudios.co/projects/compression-tests/snippet-deflator_

318 GZIPped 바이트(현재 버전은 248 GZIPped 바이트):

(function(l,e){GoogleAnalyticsObject='ga',(window.ga||(ga=function(l,e){(ga.q=ga.q||[]).push(arguments)})).l=+new Date,l=document.createElement('script'),l.src='//www.google-analytics.com/analytics.js',(e=document.getElementsByTagName('script')[0]).parentNode.insertBefore(l,e);ga('create','UA-XXXXX-X',(function(l,e){try{l=(localStorage[ga.l]=ga.l)==ga.l;localStorage.removeItem(ga.l);return l}catch(l){}}())?{storage:'none',clientId:localStorage.clientId}:{});ga(function(l,e){localStorage.clientId=l.get('clientId')});ga('send','pageview')}())

이것은 잘 테스트되지 않았으므로 여전히해야합니다. 하지만 시작입니다.

불행히도 setItem 및 getItem 호출을 제거하고 다른 골프 "트릭"을 사용했기 때문에 localStorage 테스트는 일부 브라우저에서 손상되었을 수 있습니다.

지금은 그게 다야. :-)

방금 우리가 스니펫 자체를 압축하고 있다는 생각이 들었습니다. 이는 다소 무의미합니다. Gzip 결과는 문서의 나머지 부분에 따라 달라집니다(예: 문서에 인라인된 경우 HTML 소스, 문서의 일부인 경우 JavaScript 파일의 나머지 부분). 스니펫의 gzip 압축 크기를 비교하는 것이 이것을 측정하는 가장 좋은 방법이 아닐 수도 있습니다.

스니펫이 좋아 보입니다. 새 타임스탬프를 생성하는 대신 ga.l 타임스탬프를 재사용하는 것이 좋습니다!

불행히도 localStorage 테스트는 아마도 setItem 및 getItem 호출을 제거하고 다른 골프 "트릭"을 사용했기 때문에 일부 브라우저에서 손상되었을 수 있습니다.

그렇다면 그것은 거래 차단기 IMHO가 될 것입니다.

Firefox < 9 지원이 더 이상 문제가 되지 않을 때 document.getElementsByTagName('script')[0] 를 document.scripts[0] 로 바꿀 수 있습니다.

@mathiasbynens GZIPping 스니펫은 압축으로 인한 _최소_바이트 절약에 가깝습니다. 따라서 완전히 논점이 아닙니다. 거의 모든 경우에 페이지 크기가 증가함에 따라 스니펫의 압축 비율이 증가합니다.

아직 테스트가 필요합니다! getItem 및 setItem 호출을 다시 추가하고 309바이트로 줄였습니다.

+function(l,e){(ct=this[GoogleAnalyticsObject='ct']||function(l,e){(ct.q=ct.q||[]).push(arguments)}).l=+new Date,l=document.createElement('script'),l.src='//www.google-analytics.com/analytics.js',(e=document.getElementsByTagName('script')[0]).parentNode.insertBefore(l,e);try{localStorage.setItem(ct.l,ct.l),l=localStorage.getItem(ct.l)-ct.l,localStorage.removeItem(ct.l)}catch(l){};ct('create','UA-XXXXX-X',l?{}:{clientId:localStorage.clientId,storage:'none'}),ct(function(l,e){localStorage.clientId=l.get('clientId')}),ct('send','pageview')}()

• 지금은 괄호를 감싸는 대신 + 기호를 사용하는 IIFE를 사용하고 있습니다.
• 나는 또한 localStorage.clientId 대신 localStorage.gaId 를 사용하고 있습니다 clientId 가 바이트를 절약하기 때문입니다.
• $#$ window this 를 사용하면 1바이트가 더 절약됩니다( GoogleAnalyticsObject 할당 이동과 함께).
• ga 를 ct 로 변경하면(ct가 더 일반적임) 1바이트를 더 절약할 수 있습니다(이는 아마도 혼동할 가치가 없을 것입니다).
• 함수 호출을 제거하고 성공 시 0 에 할당하여 localStorage 검사에 l 를 재사용하면 많은 바이트가 절약됩니다.

다시 말하지만 이것은 더 많은 테스트가 필요합니다.

@davidmurdoch 아직 테스트에 대한 업데이트가 있습니까? 다른 사람들이 테스트를 도울 수 있도록 테스트 흐름을 기록할 수 있습니까?

죄송합니다. 저는 MIA였습니다. 우선순위가 높은 6개월 프로젝트에 배정되어 다른 일에 많은 시간을 할애할 수 없었습니다.

이것을 테스트하는 가장 쉬운(그리고 가장 어리석은) 방법은 분석 코드를 이 새 코드로 교체하고 숫자와 브라우저 버전에 이상한 변동이 있는지 확인하는 것입니다. 나는 이것을 직접했고 눈에 띄는 것을 보지 못했습니다. 그러나 어쨌든 oldie 방문자가 많지 않습니다.

또 다른 방법은 생성된 iframe에 이 실험적 분석 스크립트를 로드하고(안정적인 분석 스니펫을 방해하지 않도록) 물론 다른 GA 계정으로 거기에서 _trackPageview 를 호출하는 것입니다. 그런 다음 일주일 정도 후에 데이터를 비교하기만 하면 됩니다.

조만간 이것을 테스트하기 위한 드롭인 스니펫 작업을 할 수 있다고 장담할 수는 없습니다. 내가 숨어 있는 동안 다른 사람이 이 아이디어의 소유권을 갖고 싶다면 바로 가세요. :-)

방금 http://drublic.github.io/css-modal/에 대한 테스트를 시작했습니다. 지난 달에 97,000 페이지 뷰를 얻었지만 브라우저 전체에 널리 퍼졌습니다.

숫자들:

1. 크롬 44.01%
2. 파이어폭스 34.38%
3. 인터넷 익스플로러 8.86%
4. 오페라 5.26%
5. 사파리 4.01%
6. 안드로이드 브라우저 2.22%

기다리고 보자. 병렬로 실행되는 "정상" 통계가 있습니다.

그 외에도 코드가 가독성을 위해 추가 업데이트가 필요하다고 생각합니다(한 줄에 80자 및 식별자를 삽입할 위치).

약 일주일 후에 이 테스트로 돌아오겠습니다.

나는 조금 이르지만 내 발견은 현재 매우 안정적입니다. 불행히도 두 계정의 방문자 수에는 큰 차이가 있습니다.

기본 구현 은 3월 13일부터 17일까지 2,964회의 고유 방문 을 표시합니다.
로컬 스토리지 기반 은 같은 기간 동안 756명의 고유한 방문 을 보여줍니다.

다음과 같은 세 가지 이유가 있을 수 있습니다.

• 스니핑된 내 구현이 손상되었습니다.
• iframe 로드가 브라우저에 의해 차단됨
• 스니핑된 로컬 스토리지 통합이 중단되었습니다.

현재 내 코드에 오류가 없습니다. http://drublic.github.io/css-modal/test-gau-localstorage.html (사이트에 통합된 iframe임).

또한 브라우저나 페이지에서 iframe이 차단되는 것을 경험한 적이 없습니다. 이것이 일어날 수 있는지 아는 사람이 있습니까?

이는 로컬 스토리지 GUA가 스니핑한 버그가 있는 솔루션으로 안내합니다. 나는 문제가 무엇인지 조사하지 않았습니다.
추가 테스트를 위해 축소되지 않은 변형을 개발하고 작업 솔루션을 만든 후 최소화할 수 있습니까?

또한 HTML5BP v5.0에서 이를 설명하고 솔루션을 찾으면 5.1로 릴리스하도록 선택하겠습니다. 여러분은 어떻게 생각하세요?

또한 HTML5BP v5.0에서 이것을 설명하고 5.1과 함께 릴리스하기로 선택했습니다.

@drublic :+1: ( v5.1.0 마일스톤 에 문제 추가됨).

숫자가 충분하지 않은 경우 ga('create', w/ storage:'none' 를 호출할 때 기본 clientId를 제공 해야 한다는 사실일 수 있습니다.

https://developers.google.com/analytics/devguides/collection/analyticsjs/domains#disableCookies

내 사이트(여기: LocalStorage를 사용하는 Google Async Analytics 및 테스트 페이지 설정: http://davidmurdoch.com/google-async-analytics-using-localstorage-test/)에서 이 문제에 대해 방금 블로그에 올렸습니다.

읽고 공유하고 테스트하십시오.

(참고: 해당 페이지에서 오타나 오류를 발견하면 트위터 @pxcoach 로 알려주세요.

이봐, 파티에 조금 늦게 도착해서 미안해. 저는 Google Analytics 팀에서 일하고 있으며 이 문제에 대해 의견을 제시하고 제 생각을 제공하고 싶습니다.

먼저 H5BP 프로젝트에서 공식적으로 권장하는 것과 기능적으로 다른 구글 애널리틱스 추적 스니펫을 추천하는 것은 좋지 않다고 생각합니다. 사람들은 아마 그들이 같다고 생각할 것이고, 실제로 그렇지 않다면 혼란을 일으킬 것입니다. Google 웹로그 분석 문서에서 GA가 일부 기능을 지원한다고 주장하지만 누군가 다른 스니펫을 사용하고 있기 때문에 지원하지 않는 경우 디버그하기 매우 어려운 문제가 발생할 수 있습니다(특히 H5BP가 스니펫이 다르다는 것을 분명히 하지 않는 경우).

GA가 더 잘할 수 있는 것이 있다면 커뮤니티에서 벗어나지 않고 커뮤니티의 요구와 함께 발전하고 싶습니다. (BTW, GA와 관련된 Github 문제에 대해 자유롭게 ping하거나 참조하십시오.)

어쨌든, 다음은 localStorage의 주요 문제와 GA가 이를 기본 저장 메커니즘으로 제공하지 않는 이유입니다.

localStorage의 범위는 location.origin 인 반면 쿠키는 최상위 도메인으로 범위가 지정될 수 있습니다. 쿠키 저장소를 사용하면 analytics.js가 기본적으로 하위 도메인 추적을 수행할 수 있으며 이는 localStorage에서는 불가능합니다. 또한 사이트의 일부가 HTTP이고 다른 부분이 HTTPS인 경우에도 실패합니다(실패하면 스토리지가 공유되지 않으므로 클라이언트 ID가 손실되고 GA는 이를 별도의 세션으로 처리합니다. ). 이것이 대부분의 GA 사용자에게 문제가 되지 않는 것은 사실이지만, 내가 방금 설명한 기능 손실로 인해 이 제안된 스니펫을 드롭인 대체품으로 제공하는 것은 여전히 ​​나쁠 것이라고 생각합니다.

즉, 이 문제와 @davidmurdoch 의 블로그 게시물을 기반으로 공식적으로 지원되는 localStorage 메커니즘 구축에 우선 순위를 두려고 합니다. 현재 storage 매개변수는 cookie 및 none 옵션만 지원하지만 세 번째 localStorage 옵션을 추가하고 싶습니다. 하위 도메인이 필요하거나 교차 체계 추적이 옵트인할 수 있습니다. 이것이 언제 추가될지 모르지만 추가될 때 이 문제를 업데이트할 수 있습니다.

이것이 모든 사람에게 합리적으로 보입니까?

@philipwalton 댓글 감사합니다!

이것이 모든 사람에게 합리적으로 보입니까?

참조: @davidmurdoch , @mathiasbynens

즉, 이 문제와 @davidmurdoch 의 블로그 게시물을 기반으로 공식적으로 지원되는 localStorage 메커니즘 구축에 우선 순위를 두려고 합니다.

:+1:

이것이 추가되면 문제를 업데이트하십시오. 감사 해요!

@philipwalton , :+1: 좋은 소식입니다! 그러나 빌드하기 위해 _시도_할 필요는 없습니다. 이미 했습니다! :-p (나는 꼬마, 나는 꼬마).

이 뉴스로 블로그 게시물을 업데이트하고 비공식 localStorage 추적 코드로 GitHub 저장소를 만들어 단점을 강조하겠습니다. 감사 해요!

:+1: 하지만 미래의 웹에는 일종의 topLevelStorage 가 필요할 것 같습니다. 옵션을 사용할 수 있게 되어 기쁩니다. 이를 염두에 두고 스니펫이 들어올 때 h5bp에 대한 기본 설정은 무엇입니까?

@jonathantneal , 우리는 파이어폭스에 globalStorage 를 가지고 있었는데, 이것은 교차 체계, 포트, 그리고 하위 도메인 저장을 했습니다. Firefox는 그것을 구현한 유일한 사람이었고 그 이후로 더 이상 사용되지 않는 것으로 표시되었습니다. :-(

@davidmurdoch 이 호를 열어서 조사해 주셔서 감사합니다. 진심으로 감사드립니다!

@philipwalton 토론에 참여해 주셔서 다시 한 번 감사드리며 @mathiasbynens 가 말했듯 이 최신 정보를 계속 알려주세요!

그리고 비공식 localStorage 추적 코드를 사용하여 GitHub 리포지토리를 만들어 단점을 강조합니다.

@davidmurdoch 의 저장소는 https://github.com/davidmurdoch/ga-localstorage 입니다.(아직 업데이트되지는 않았지만).

방금 "localStorage를 사용하는 Google 애널리틱스" 스크립트를 npm에 게시했습니다. https://www.npmjs.org/package/ga-localstorage

https://github.com/davidmurdoch/ga-localstorage 리포지토리도 코드로 업데이트되었습니다.

안녕하세요, 이 SO 댓글을 읽었습니까?

http://stackoverflow.com/questions/4502128/convert-google-analytics-cookies-to-local-session-storage/19207035#comment -44767913

다들 어떻게 생각하시는지 궁금합니다.

@caesarsol 정말 나쁜 생각이라고 생각합니다. 내 의견 에서 설명했듯이 쿠키와 localStorage에는 동일한 제한이 없으므로 페이지에서 실행되는 모든 단일 스크립트에 대해 쿠키를 교체하는 것은 매우 위험합니다.

안녕하세요 @philipwalton님 , 답변에 감사드립니다. 하지만 제가 설명을 잘못했을 수도 있습니다. SO 사용자 _smhmic_의 이 댓글을 참조한 것 같습니다.

이것은 GA TOS를 위반할 수 있습니다! 다음은 이 문서에서 가져온 GA 팀 구성원의 간접 인용문입니다. "쿠키 상태를 전파하기 위해 HTTP 상태 관리 메커니즘 사용"(localStorage 읽기) "은 개인 정보 보호를 우회하는 것입니다. 그렇게 하는 것은 Google Analytics 서비스 약관을 위반하는 것입니다. ". 이에 대한 나의 해석은 더 많은 사용자가 쿠키의 개념과 쿠키를 지우는 방법에 익숙하기 때문에 GA가 localStorage가 아닌 쿠키를 사용한다는 것입니다. 따라서 GA의 쿠키 사용은 개인 정보 보호 기능입니다. – 흠흠

HTTP 상태 관리 메커니즘"(localStorage 참조)을 사용하여 쿠키 상태를 전파하는 것은 당사의 개인 정보 보호 장치를 우회하는 것입니다. 그렇게 하는 것은 Google Analytics 서비스 약관을 위반하는 것입니다.

흠, 나는 이것이 사실이 아니라고 생각합니다. 쿠키를 사용하는 구현자에 의존하지 않는 GA가 제공하는 선택 해제 기능(예: Chrome 확장 프로그램)이 있습니다. 이 TOS 섹션의 요점은 공식 "추적 금지" 확장을 사용하는 사람이 _여전히_ 추적되는 메커니즘을 만들 수 없다는 것입니다.

더 자세히 조사할 수 있으며 이 스레드를 업데이트하겠습니다. 내 가정이 거짓으로 판명되면 이 스레드를 업데이트하겠습니다.

업데이트:

LocalStorage를 사용하여 ClientID를 저장하는 것은 TOS에 위배되지 않습니다. 이제 Google에서 공식적으로 지원합니다. https://developers.google.com/analytics/devguides/collection/analyticsjs/cookies-user-id#using_localstorage_to_store_the_client_id

참고: iOS5 및 FF4와 같은 오래된 브라우저를 (매우) 지원해야 하는 경우 예제 스니펫이 실패할 수 있습니다(https://github.com/Modernizr/Modernizr/blob/master/feature-detects/storage/localstorage 참조). js).