리디렉션 및 별칭
리디렉션은 사용자 상호 작용 없이 브라우저를 새 위치로 지정합니다. 리디렉션은 웹 브라우저 (클라이언트측 리디렉션) 또는 웹 서버 (서버측 리디렉션)에서 실행됩니다.
리디렉션 및 별칭 aliases
리디렉션은 사용자 상호 작용 없이 브라우저를 새 위치로 지정합니다. 리디렉션은 웹 브라우저 (클라이언트측 리디렉션) 또는 웹 서버 (서버측 리디렉션)에서 실행됩니다.
리디렉션은 사용자 조정이 필요 없으므로, 종종 사용자도 모르게 리디렉션이 실행됩니다. 리디렉션이 발생했음을 나타내는 유일한 단서는 브라우저의 주소 표시줄입니다. 주소 표시줄이 브라우저가 초기에 요청한 링크와 다른 URL을 표시합니다.
두 가지 유형의 리디렉션만 있더라도, 다양한 방법으로 리디렉션을 구현할 수 있습니다. 예를 들어 사용자가 자신의 브라우저를 향해 있는 웹 페이지에는 브라우저를 다른 URL로 리디렉션하는 스크립팅 또는 특수 HTML 코드가 들어 있으므로 클라이언트측 리디렉션이 발생할 수 있습니다. 서버측 리디렉션은 페이지가 서버측 스크립팅을 포함하거나 사용자가 다른 URL로 향하도록 웹 서버가 구성되었기 때문에 발생할 수 있습니다.
Analytics 및 리디렉션 aa-redirects
Analytics는 브라우저에서 일부 데이터를 수집하고 특정 브라우저 속성에 의존합니다. 이러한 속성 중 "참조 URL" (또는 "레퍼러")과 "현재 URL" 속성은 서버측 리디렉션으로 변경될 수 있습니다. 브라우저는, 한 URL이 요청되었지만 다른 URL이 반환되었음을 인식하므로, 참조 URL을 지웁니다. 그 결과, 참조 URL은 공백이 되고, Analytics가 페이지에 대한 레퍼러가 없음을 보고할 수 있습니다.
예: 리디렉션 없이 찾아보기 browse-without
사용자가 리디렉션을 발견하지 않는 다음 가설 시나리오를 고려하십시오.
- 사용자가 자신의 브라우저를
www.google.com
을 가리키게 하고, 검색 필드에 "할인 항공 티켓"을 입력한 다음 검색 버튼을 클릭합니다. - 브라우저가 해당 사이트 ( https://www.example.com/ )에 대한 링크를 포함하는 검색 결과를 표시합니다. 검색 결과가 표시되고 브라우저의 주소 표시줄에 사용자가 검색 필드 (
https://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets
)에 입력한 검색어가 표시됩니다. 검색어는https://www.google.com/search?
다음에 오는 URL 쿼리 문자열 매개 변수에 포함됩니다. - 사용자가 가설 사이트 ( https://www.example.com/ )로 이동하는 링크를 클릭합니다. 사용자가 이 링크를 클릭하고 example.com 웹 사이트로 이동하면 Analytics는 JavaScript를 사용하여 참조 URL (
https://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets
)과 현재 URL (https://www.example.com/
)을 수집합니다. - Analytics는 참조 도메인, 검색 엔진 및 Search Keywords 등의 여러 보고서에 이러한 상호 작용 중에 수집된 정보를 보고합니다.
예: 리디렉션을 사용하여 찾아보기 browse-with
리디렉션으로 인해 브라우저는 실제 참조 URL을 완전히 지울 수 있습니다. 다음 시나리오를 참조하십시오.
- 사용자는 브라우저가
https://www.google.com
을 가리키게 하고 검색 필드에 할인 항공 티켓 을 입력한 다음 검색 버튼을 클릭합니다. - 브라우저 창의 주소 표시줄에 사용자가 검색 필드에 입력한 검색어 (
https://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets
)가 표시됩니다. 검색어는https://www.google.com/search?
다음에 오는 URL 쿼리 문자열 매개 변수에 포함됩니다. 또한 브라우저는 도메인 이름 중 하나 ( https://www.flytohawaiiforfree.com/ )에 대한 링크를 포함하는 검색 결과를 포함하는 페이지를 표시합니다. vanity 도메인은 사용자를https://www.example.com/
으로 리디렉션하도록 구성되었습니다. - 사용자가
https://www.flytohawaiiforfree.com/
링크를 클릭하면 서버가 사용자를 주 사이트인https://www.example.com
으로 리디렉션합니다. 리디렉션이 발생할 때 브라우저가 참조 URL을 지우므로 Analytics 데이터 수집에 중요한 데이터가 유실됩니다. 따라서 Analytics 보고서 (예: 참조 도메인, 검색 엔진, 검색 키워드)에 사용된 원래 검색 정보가 유실됩니다.
구현 리디렉션 implement
리디렉션에서 AnalyticsAppMeasurement 데이터를 캡처하려면 리디렉션 및 JavaScript용 파일을 만드는 코드에 대해 4가지 사항을 조정해야 합니다.
다음 단계를 완료하면 원래 레퍼러 (예: 위의 시나리오에서 https://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets
)가 사용자 사이트에 전달하는 정보는 그대로 유지됩니다.
레퍼러 대체 JavaScript 코드 구성 override
아래의 코드 스니펫은 두 개의 JavaScript 변수인 s_referrer
와 s_pageURL
을 보여 줍니다. 이 코드는 리디렉션의 최종 랜딩 페이지에 삽입됩니다.
<script language="JavaScript" src="//INSERT-DOMAIN-AND-PATH-TO-CODE-HERE/AppMeasurement.js"></script>
<script language="JavaScript"><!--
/* You may give each page an identifying name, server, and channel on
the next lines. */
s.pageName=""
s.server=""
s.campaign=""
s.referrer=""
s.pageURL=""
s.referrer
를 한 번만 설정합니다. 모든 추적 호출이나 추적되는 모든 링크 클릭으로 두 번 이상 설정하면 검색 엔진 및 키워드와 같은 레퍼러 및 관련 차원들이 두 번씩 계산됩니다.getQueryParam을 사용한 리디렉션 getqueryparam
getQueryParam은 Analytics 변수를 쿼리 문자열 값으로 채우는 쉬운 방법이지만, 쿼리 문자열이 비어 있을 때 적합한 레퍼러가 덮어쓰이지 않도록 임시 변수와 연결해서 구현해야 합니다. getQueryParam를 사용하는 가장 좋은 방법은 다음의 의사 코드로 설명했듯이 getValue와 관련되어 있습니다.
// AppMeasurement 1.x
var tempVar=s.Util.getQueryParam('origref')
if(tempVar)
s.referrer=tempVar;
// H Code
var tempVar=s.getQueryParam('origref')
if(tempVar)
s.referrer=tempVar;
리디렉션 메커니즘 수정 modify
브라우저는 URL을 참조하여 스크립트를 작성하므로, 원래 레퍼러 정보를 전달할 리디렉션 (예: 웹 서버, 서버측 코드, 클라이언트측 코드)을 처리하는 메커니즘을 구성해야 합니다. 또한 별칭 링크 URL을 기록할 경우에도 이를 최종 랜딩 페이지로 전달해야 합니다. 현재 URL을 재정의하려면 s_pageURL
변수를 사용하십시오.
리디렉션을 구현하는 방법으로는 여러 가지가 있으므로, 웹 운영 그룹 또는 온라인 광고 파트너와 함께 확인해서 웹 사이트에서 리디렉션을 실행하는 특정 메커니즘을 식별해야 합니다.
원래 레퍼러 캡처 original
일반적으로 Analytics는 브라우저의 document.referrer 속성에서 참조 URL을 획득하고 document.location 속성에서 현재 URL을 획득합니다. 값을 referrer
및 pageURL
변수에 전달하여 기본 처리를 재정의할 수 있습니다. referrer 변수로 값을 전달하여 Analytics에 document.referrer 속성에 있는 레퍼러 정보를 무시하고 사용자가 정의한 대체 값을 사용할 것을 지시합니다.
따라서 랜딩 페이지의 최종 버전은 "할인 항공 티켓" 시나리오에서 나타난 문제를 수정하기 위해 다음 코드를 포함해야 합니다.
<script language="JavaScript" src="https://INSERT-DOMAIN-AND-PATH-TO-CODE-HERE/AppMeasurement.js"></script>
<script language="JavaScript"><!--
/* You may give each page an identifying name, server, and channel on
the next lines. */
s.pageName=""
s.server=""
s.campaign=""
s.referrer="https://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets"
// Setting the s.pageURL variable is optional.
s.pageURL="https://www.flytohawaiiforfree.com"
Adobe Debugger로 레퍼러 확인 verify
테스트를 실행하여 레퍼러, 원래 URL (s_server
) 및 캠페인 변수가 캡처되고 있는지 확인합니다.
이러한 변수는 Experience Cloud Debugger에 다음 매개 변수로 표현되지 않습니다.
g=https://www.flytohawaiiforfree.com
이 값은 pageURL 변수를 사용하는 경우 DigitalPulse Debugger에 표시됩니다.
디버거가 표시하는 텍스트는 다음 예와 일치해야 합니다.
Image
https://examplecom.112.2o7.net/b/ss/examplecom/1/JS-1.4/s61944015791667?[AQB]
ndh=1
t=4/8/2014 13:34:28 4 360
pageName=Welcome to example.com
r=https://ref=www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets
cc=USD
g=https://www.flytohawaiiforfree.com
s=1280x1024
c=32
j=1.3
v=Y
k=Y
bw=1029
bh=716
ct=lan
hp=N
[AQE]
Adobe Debugger에 이러한 변수가 표시되는지 확인하면 항상 검색어와 원래 참조 도메인 (리디렉션 전)이 보고서에서 트래픽을 등록 중인지 확인하는 데 유용합니다.