구글 분석이 AdBlocker에 의해 저지되는 것을 방지하다

데이터를 표시하고 그들을 위한 상업적 목적으로 수집한 데이터 (프라이버시를 잊는 것) 를 제외하고는 구글 분석에 대해 원하는 것, 특히 그들을 어떻게 생각하는지 말할 수 있다.만약 당신이 사이트 소유자라면, 방문자를 위해 합리적인 추적 방법을 찾고 있습니다. 이것은 당신이 가장 먼저 선택할 해결 방안입니다.
Google Analytics의 문제는 웹 사이트의 속도를 떨어뜨리는 추적 스크립트가 중요하다는 것입니다.
이 문제를 해결하는 동시에 기본적인 분석 기능을 유지하기 위해서 구글의 추적 방법을 하나의 부분, 일부로 대체할 수 있다. 이것은 당신의 수요를 완전히 만족시킬 것이다.이 스크랩은 Minimal Google Analytics라고 불리며 DavidKuennen에 편제되었고 GitHub Gist에 통일되지 않은 형식으로 출판되었다.
무게가 73kB인 구글 추적 코드를 교체했기 때문에 우리가 제공한 캡처 코드는 1.5kB로 줄었다.
만약 사이트 속도와 핵심 사이트의 관건적인 지표가 걱정된다면, 가장 먼저 해야 할 일은 최소한의 분석으로 외부 추적 스크립트를 바꾸는 것이다.
모든'나의'사이트는 현재 이 캡처를 사용하고 있다. 나는 그 중에서 내가 필요로 하는 모든 분석을 얻었다.
방문자가 한 페이지를 방문하면 잘린 페이지는 /collect URL을 통해 구글 분석에 신호를 보내고 지정한 추적 코드UA-XXXXXXXXX-X를 가지고 있다.이렇게 간단해.
2021년의 사이트 통계 데이터를 2020년의 데이터와 비교했을 때 모든 사이트의 데이터가 대폭 감소한 것을 발견했다.
Hugo와 1년 동안 실시된 많은 SEO방면으로 인해 페이지 속도가 크게 향상되었지만 무슨 일이 일어났는지 모르겠다.
최근에 나는 이 부분에서 내가 나의 사이트를 방문한 상황을 보고하지 않았다는 것을 알아차렸다.
나는 좀 이상하다고 생각한다.
만약 나의 방문이 기록되지 않았다면 (나는 구글 분석에 있어서 어떠한 예외도 없었다), 나는 매일 얼마나 많은 방문량을 손실했을까?
나는 SNIPTED 자체의 결함을 제거했다. 왜냐하면 그것이 잘 작동하기 때문이다.
그게 나로 하여금 생각하게 한다.어떤 것이 나의 캡처를 막고 구글에 방문 상황을 분석하는 것을 막았다.
그리고 나는 내 쪽에 무슨 변화가 생겼는지 보았다.
AdBlocker (특히 AdBlock Plus) 와 DuckDuckGo 브라우저 확장을 사용하고 있습니다.
차단 목록에 의존할 때, AdBlock은 기본적으로 구글 분석을 막지 않으며, DuckDuckGo 확장은 상자를 열면 우리의 프라이버시를 보호합니다.나는 내가 알고 있다는 것을 알고 있지만, 나는 여전히 누가 나의 사이트를 방문하고 있는지 알고 싶다. 나는 데이터가 정확하고 틀림없기를 바란다.
각종 블로그를 분석할 때, 나는 여러 해 동안 많은 사람들이 비슷한 행위를 보고했고, 상당 부분의 방문자들은 기본적으로 구글 분석을 막았다는 것을 알아차렸다.
마르코 사리치가 그의 게시물에서 언급한13% of my website visitors block Google Analytics처럼 동의보다 더 중요한 것은 없다.
이 비율은 갈수록 높아진다.
데이터가 매우 많은'나의'사이트에서 2021년의 사용자 수는 2020년에 비해 12.43% 감소했고 같은 기간에 방문한 페이지 수는 51.06% 감소한 것을 보았다.
뭐 좀 하고 싶은데.
나는 심지어 Plausible Analytics의 단기 시용을 살펴보고 시작했다. 이것은 간단하고 프라이버시가 좋은 구글 분석 대체 방안이다.
질문이 하나 있습니다. 죄송합니다.나는 이 때문에 계산을 하고 싶지 않다. 특히 이윤과 데이터가 발생하지 않는 개인 사이트에서는 이 때문에 추가 비용을 늘릴 가치가 없다.
합리적인 것 같지만 구글 분석의 기본값처럼 광고 차단기에 의해 차단되지는 않았다.

We're not blocked to the same extent as Google Analytics (neither Firefox nor Safari blocks Plausible) but we're blocked by some block list maintainers who have taken the stance that they want to block every tracking script and don't want to have the responsibility to judge what's good and what's bad.

상황이 불안정하다. 그들은 구글에 진정한 프라이버시 가이드 대안을 제공하기 위해 노력했지만, 어느 순간 그들의 해결 방안이 저지 명단에 올라갈 것이라는 것을 안다.

We're not blocked to the same extent as Google Analytics (neither Firefox nor Safari blocks Plausible) but we're blocked by some block list maintainers who have taken the stance that they want to block every tracking script and don't want to have the responsibility to judge what's good and what's bad**.

이 문제는 앞에서 언급한 것처럼 겉과 속이 다르다. 일부 열성적인 사람들은 모든 것을 막으려고 한다. 비록 그들은 겉과 속이 다르지만 추적 업계를 더욱 좋아지게 하려고 한다.
그들은 어느 순간에 AdBlocker와 싸워야 하며, 각종 장면에 해결 방안을 제공할 준비가 되어 있다는 것을 안다.
키워드를 기반으로 하는 방법 외에 AdBlocker의 작업 방식은 저희 사이트의 외부 링크를 분석하는 것입니다.만약 그들이 내 사이트에서 외부 google-analytics.com 의 인용을 본다면, 그들은 그것을 막을 것이다.기본적으로 DuckDuckGo 확장(및 브라우저)은 이렇게 합니다.
그러나 AdBlocker는 저희 사이트 주소에서 유래한'물건'을 차단하지 않았습니다.
이런 상황에서 구글 분석 스크립트를 제공해서 이 문제를 해결할 수 있다고 생각할 수도 있다.꼭 그렇지는 않다.
구글은 이런 방식을 금지하고 당신의 계정을 차단함으로써 당신을 처벌할 수 있다.이 밖에 구글 스크립트의 클립북을 삭제했기 때문에 모든 것이 이미 우리에게 제공되었기 때문에 다른 서비스는 없습니다.
면제는 하나뿐입니다.
내 사이트에 새로운 데이터가 나올 때마다 Minimal analytics snipped는 www.google-analytics.com/collect에'ping'을 보낸다.
미래plausible.js가 차단될 수 있는 것처럼 당연히 차단될 것이다.
프록시 원시 서버를 통해 추적 스크립트를 차단하는 해결 방안이 제시된 것 같지 않다.
나는 Netlify에서 나의 사이트를 위탁 관리했기 때문에 그들이 어떻게 하는지 보았다mentioned. 그리고 나는 내가 사용하고 있는 최소 분석으로 같은 일을 할 수 있다는 것을 발견했다.
나는 www.google-analytics.com/collect 규칙을 사용하여 나의 호출 에이전트를 _redirects에게 주고 내가 내 영역에서 데이터를 수집하고 있는 척할 수 있다.
인용google-analytics.com이 없어 어떤 내용도 막히지 않았다.
그러므로 _redirects 파일에 다음 줄을 입력합니다.

/collect   https://www.google-analytics.com/collect   200

www.google-analytics.com/collect를 도메인 이름으로 바꿉니다.이런 상황에서 그것은 dariusz.wieckiewicz.org/collect이다.
보시다시피 저는 여전히 단편을 통해 데이터를 수집하지만 이론적으로 제 사이트에 위치를 정할 것입니다.백스테이지에서 AdBlocker 추적 기능의 배후에서 저/collect의 전화는 구글 분석으로 리셋됩니다.
물론, 이 단어를 차단 목록에 추가하기로 결정하지 않도록 랜덤 문자열 (사이트마다 유일한) 으로 바꿀 가치가 있다.
Proxying Plausible through Netlify
결점
이런 해결 방안은 현저한 결점이 하나 있다.
리디렉션 규칙은 백그라운드에서 발생하며, AdBlock 눈에서 멀어지며, 위탁 공급자 서버에서 발생합니다.Netlify를 사용할 때, Netlify CDN에서 발생하기 때문에, 이것은 Netlify 분포식 서버 네트워크에서 발생합니다. 서버가 제 위치로 닫힙니다.
이런 상황에서 내가 영국에서 나의 사이트를 방문했을 때 가장 최근의 그다지 바쁘지 않은 서버가 독일에 있었기 때문에 모든 데이터 출처에서 활발한 사용자가 갑자기 독일에서 왔다는 것을 알 수 있었다.
이것은 당연히 사실이 아니다.만약 우리가 이 방면의 정확한 데이터를 원한다면, 우리는 snipped에서 /collect까지의 원시 통화를 견지해야 한다.이런 상황에서 우리는 30퍼센트에 달하는 진실한 교통 정보를 잃어버리지만 사용자의 출처로부터 정보를 얻을 수 있다.
그러나 오차가 30%에 이르는 데이터는 분석할 가치가 있는가?
나는 그들이 어디에서 왔는지 알지 않고 얼마나 많은 사용자들이 나의 사이트를 방문하는지 더 알고 싶다는 결정을 내렸다.
나는 내가 있는 사이트가 폴란드에서 온 대부분의 사용자를 보유할 것이고 폴란드는 세계 각지에 분포하는 더 많은 사용자를 보유할 것이라고 안다.
당신이 당신의 사이트를 특정한 지역에 포지셔닝하고 얼마나 많은 사용자가 어느 나라에서 왔는지 알아야 한다면, 이러한 정보는 그다지 중요하지 않다.나의 예에서 나는 내 사이트의 어떤 부분이 가장 읽기 쉬운지 더 알고 싶다. 그러면 나는 내가 만든 내용에 집중하여 독자들이 즐겨 읽는 내용을 찾을 수 있다.70% 의 정확도는 결코 가장 좋은 정보 원천이 아니다.
이것은 결코 상술한 부분의 유일한 문제가 아니다.Netlify에서 옳고 그름을 사용한다면, 에이전트 방법을 사용할 때 비슷한 행동을 할 수 있습니다.
그러나 Netlify에서 또 다른 방해가 될 수 있는 것은 자바스크립트의 자산 최적화이다.
절에서 이 점을 언급한 것도 합리적이다.Netlify CDN은 JavaScript에 넣은 주소를 방해하고 분산 서버와 일치하도록 다시 쓸 수 있습니다.이러한 상황을 피하기 위해서 자바 스크립트의 자산 최적화 (묶음과 축소) 를 비활성화해야 합니다.

This typically happens if in a script we will refer to just part of the URL string and not to the full domain name and string, like in my above example.

Troubleshooting
저는 자산 최적화된 이미지 압축 부분만 최소 분석으로 사용하고 미리 축소된 버전(다른 JS 서비스)에서 만약에 제가 Hugo 사이트에서 CSS나 JS를 호출한다면 내장된 축소기와 지문을 사용하고 있기 때문에 무의미한 것은 두 번 축소하는 것입니다.
만약 이'결점'이 당신을 실망시키지 않았다면, 위치 추적에 있어서 정확성을 잃었음에도 불구하고 실제 방문 횟수에 더욱 가깝게 보일 것이다.단, 사용자 위치를 포함한 정확한 데이터가 필요하고 이를 위해 비용을 지불하고자 한다면 해 보십시오.
Netlify는 또한 자체 서버 측 대응 분석 솔루션을 제공하기 때문에 시도를 선택할 수 있습니다.