‘에어브릿지 디바이스 ID’는 에어브릿지의 결정 방식에 따라 여러 환경에서 수집한 식별자 중 가장 적합한 식별자로 결정됩니다. 따라서 에어브릿지 기능별 특성, 디바이스당 식별자가 충분히 수집됐는지 여부 등에 따라 에어브릿지 기능별로 다른 식별자가 ‘에어브릿지 디바이스 ID’로 사용될 수 있습니다. 그렇기 때문에 에어브릿지 리포트에서 나타나는 유저 수와 원본 앱 데이터에서 ‘Airbridge Device ID’로 추출한 식별자 개수가 서로 다를 수 있습니다.

그룹바이로 ‘Is First Event per Device ID’가 있는지 확인해 주세요. 이 그룹바이를 선택하면 ‘에어브릿지 디바이스 ID’를 기준으로 첫 이벤트를 판별할 수 있습니다. 이때 ‘에어브릿지 디바이스 ID’는 에어브릿지의 결정 방식에 따라 여러 환경에서 수집한 식별자 중 가장 적합한 식별자로 결정되기 때문에 수치가 달라질 수 있습니다.

메트릭은 업데이트 주기에 따라 가장 마지막으로 업데이트 된 데이터를 반영합니다. 데이터 종류마다 업데이트 주기는 다릅니다. SDK를 통해 수집되는 데이터는 실시간에 가깝게 업데이트 됩니다. 스토리지 연동이나 비용 연동과 같은 연동 데이터는 4시간마다, SKAN 데이터는 24시간마다 업데이트 됩니다. 연동별 업데이트 주기에 관한 자세한 내용은 에어브릿지 가이드를 참고하세요.

에어브릿지 SDK를 정상적으로 설치했다면 Installs (App)을 별도 이벤트 설정 없이 트래킹할 수 있습니다. 하지만 Installs (App)은 앱을 최초로 실행해야 집계됩니다. 앱을 설치한 후에 앱을 실행하지 않은 경우는 Installs (App) 이벤트로 집계되지 않습니다.

트래킹 링크 파라미터 중에서 채널 파라미터에 값이 없는 성과는 $$default$$라는 광고 채널로 집계됩니다. 에어브릿지 대시보드에서 트래킹 링크를 생성하면 채널 파라미터는 반드시 값이 있습니다. 따라서 에어브릿지 대시보드를 거치지 않고 트래킹 링크를 생성하는 경우에 $$default$$에 광고 성과가 집계될 수 있습니다.

• 채널 파라미터가 있는 트래킹 링크: https://abr.ge/@your_app_name/ad_channel?campaign=abc

• 채널 파라미터가 없는 트래킹 링크: https://abr.ge/@your_app_name?campaign=abc

트래킹 링크 구조와 파라미터에 대한 자세한 내용은 에어브릿지 가이드를 참고해 주세요.

google.adwords와 google은 다른 채널입니다.

google.adwords는 구글 애즈의 에어브릿지 표시 이름입니다. google.adwords 채널을 통해 구글 애즈에 기여된 광고 성과를 확인할 수 있습니다. 에어브릿지와 연동된 광고 채널의 에어브릿지 표시 이름은 에어브릿지 가이드에서 확인할 수 있습니다.

하지만 google은 에어브릿지 표시 이름이 아닙니다. 일반적으로 google이라는 이름으로 정의된 커스텀 채널입니다. 커스텀 채널용 트래킹 링크로 커스텀 채널의 성과를 수집할 수 있습니다.

리텐션 리포트의 Installs (App)은 '에어브릿지 디바이스 ID' 기준으로 중복을 제외한 수치입니다. 같은 날짜에 '에어브릿지 디바이스 ID'를 기준으로 Installs (App)이 2건 발생하면 마지막에 발생한 이벤트에 대해서만 리텐션을 측정합니다. 다른 날짜에 '에어브릿지 디바이스 ID'를 기준으로 Installs (App)이 2건 발생하면 각각의 이벤트에 대해서 리텐션을 측정합니다.

이때 액츄얼스 리포트는 중복을 제외하지 않기 때문에 일반적으로 리텐션 리포트의 Installs (App) 수치가 액츄얼스 리포트 수치보다 작을 수 있습니다. 에어브릿지에서 사용하는 식별자에 대한 자세한 내용은 에어브릿지 가이드를 참고해 주세요.

그룹바이별로 첫 이벤트를 판단하는 기준에 사용하는 식별자가 다릅니다. 자세한 내용은 에어브릿지 가이드를 참고해 주세요.

Is First Event per User ID는 여러 플랫폼에서 첫 이벤트가 발생하면 먼저 발생한 플랫폼에만 집계됩니다. 예를 들어 A 이벤트가 유저 ID를 기준으로 웹 환경에서 발생한 후에 A 이벤트가 앱 환경에서 발생하면 웹에서 발생한 A 이벤트만 집계됩니다.

오류가 아닙니다. 액츄얼스 리포트에서 오늘 확인한 수치는 전날 확인한 수치와 다를 수 있습니다. 액츄얼스 리포트 수치가 변경되는 현상이 발생하는 이유는 2가지입니다.

• 데이터 누락 방지를 위한 보정 작업

• 집계 기준에 따른 조회 결과 변경

자세한 내용은 아래에서 확인해 주세요.

데이터 누락이 발생할 수 있는 주요 원인은 아래와 같습니다.

• 불안정한 유저의 네트워크 환경으로 이벤트 집계 지연

• 이벤트 발생 직후 이벤트가 에어브릿지 서버로 전송되기 전에 앱을 백그라운드로 보내거나 종료

에어브릿지는 데이터 누락 방지를 위해 매일 KST(한국표준시) 기준 오전 6시에 2일 전 데이터를 하루치(24시간) 보정합니다. 데이터 보정을 통해 누락된 이벤트가 추가되면 액츄얼스 리포트의 일부 수치가 증가할 수 있습니다.

따라서 대부분의 데이터는 조회하는 날을 기준으로 2일 전(D-2) 데이터는 변경되지 않습니다.

예시) 1월 3일 KST 오전 8시에 액츄얼스 리포트를 조회

• 수치가 변경될 수 있는 기간은 1월 2일 KST 오전 0시부터 1월 3일 오전 8시까지입니다.

• 1월 2일 KST 오전 0시 이전의 수치는 확정된 수치입니다.

집계 기준에 따라 액츄얼스 리포트의 조회 결과가 확정되는데 걸리는 시간이 더 필요할 수 있습니다. 집계 기준을 타겟 이벤트 날짜 또는 터치포인트 날짜로 설정하면 이벤트가 과거에 발생한 타겟 이벤트 또는 터치포인트가 발생한 날짜에 집계됩니다.

이에 따라 액츄얼스 리포트 수치는 어트리뷰션 윈도우가 끝나기 전까지 조회 시점에 따라 변경될 수 있습니다.

예시) 액츄얼스 리포트를 터치포인트 날짜 설정으로 조회

• 2월 10일에 확인한 2월 1일의 수치가 10이면 2월 1일 발생한 터치포인트가 10의 수치가 발생시켰다는 의미입니다.

• 2월 11일에 확인한 2월 1일의 수치가 11로 증가할 수 있습니다. 어트리뷰션 윈도우가 끝나지 않았다면 터치포인트의 성과가 더 집계될 수 있기 때문입니다.

일부 채널의 개인정보보호정책에 따라 아래 조건에 해당하는 메트릭은 액츄얼스 리포트(Actuals Report)에서 미기여(unattributed)로 처리됩니다. 해당 메트릭 수치는 액츄얼스 리포트에서 0으로 변경되어서 집계됩니다. Campaign, Ad Group, Ad Creative 등 일부 터치포인트 관련 데이터도 에어브릿지에서 확인할 수 없습니다.

미기여로 처리될 수 있는 메트릭은 액츄얼스 리포트에서 설정한 집계 기준에 따라 다릅니다. 같은 메트릭이라도 집계 기준에 따라 수치를 확인하거나 미기여로 변경됩니다. 아래를 참고해 주세요.

미기여로 처리될 수 있는 메트릭이 아래 조건을 만족하는 미기여로 변경됩니다. 테이블에서 확인할 수 있는 수치는 0으로 나옵니다.

• 기간: 기여한 시점이 UTC(협정세계시간) 기준으로 180일 전(D-180)입니다. 설정한 타임존에 따라 시차만큼 조금 늦거나 이르게 변경됩니다.

• 채널: 기여한 터치포인트가 발생한 채널이 메타 애즈(facebook.business), 구글 애즈(google.adwords), 틱톡 포 비즈니스(tiktok)입니다.

• 터치포인트 유형: 기여한 터치포인트의 터치포인트 생성 타입(Touchpoint Generation Type)이 Self-attributing Network입니다. 틱톡 포 비즈니스는 생성 타입이 Tracking Link 유형도 포함됩니다.

오늘을 기준으로 UTC 9개월 전에 메타 애즈로 기여된 구매 완료 (App)가 10건 발생했습니다. 해당 메트릭은 집계 기준을 제외한 조건을 만족했기 때문에 집계 기준에 따라 모두 미기여로 변경될 수 있습니다.

구매 완료 (App) 메트릭으로 확인할 수 있는 수치는 집계 기준에 따라 액츄얼스 리포트에서 아래와 같이 표시됩니다.

액츄얼스 리포트에서 집계 기준을 Event Date로 설정하고 오늘을 기준으로 UTC(협정세계시) 180일 전에 메타 애즈, 구글, 틱톡 포 비즈니스에 기여된 이벤트 또는 터치포인트를 조회하면 미기여된 유저 수가 미기여된 이벤트 수보다 많을 수 있습니다.

메타 애즈, 구글, 틱톡 포 비즈니스의 개인정보보호정책에 따라 이름에 ‘유저 수’가 붙는 메트릭만 미기여로 변경되기 때문입니다.

오늘을 기준으로 UTC 9개월 전에 20명의 유저가 각각 1번씩 구매 완료 (App)를 실행했습니다. 유저 10명은 구글에 기여되었고 나머지 유저 10명은 기여되지 않았습니다. 해당 데이터를 액츄얼스 리포트에서 집계 기준을 Event Date로 설정하면 미기여된 유저 수가 아래와 같이 표시됩니다.

터치포인트 분석, 터치포인트 오버랩 리포트와 액츄얼스 리포트의 앱 설치 수가 일치하지 않을 수 있습니다. 대표적인 이유는 아래와 같습니다.

• 타임존

• 설치 집계 방식

각 리포트의 타임존이 다릅니다.

터치포인트 분석, 터치포인트 오버랩 리포트의 타임존은 KST(한국표준시)입니다. 해당 리포트의 타임존은 변경할 수 없습니다. 액츄얼스 리포트의 기본 타임존은 앱 타임존입니다. 해당 리포트의 타임존은 KST를 포함한 다른 타임존으로 변경할 수 있습니다.

따라서 액츄얼스 리포트의 타임존이 KST가 아니면 터치포인트 분석, 터치포인트 오버랩 리포트와 액츄얼스 리포트 사이에 설치 수 차이가 발생할 수 있습니다.

터치포인트 분석, 터치포인트 오버랩 리포트에서 분석 기준 이벤트를 Install로 설정하면 Total 또는 Total Conversions에서 앱 설치 수를 조회할 수 있습니다. 해당 수치는 분석 기간 동안 각 유저가 최초로 실행한 앱 설치를 집계한 수치입니다.

액츄얼스 리포트에서 Installs (App)로 조회할 수 있는 앱 설치 수는 분석 기간 동안 발생한 전체 앱 설치를 집계한 수치입니다. 같은 유저가 앱 설치를 여러 번 실행하면 액츄얼스 리포트는 각 앱 설치를 모두 집계합니다.

아래 예시를 참고해 주세요.

예시)

하나의 유저 여정에서 발생한 앱 설치 수가 리포트별로 다르게 집계될 수 있습니다. 유저 여정이 아래와 같습니다.

1. 1월 1일 앱 설치

2. 1월 2일 앱 삭제

3. 1월 3일 앱 설치

조회 기간이 KST 기준 1월 1일부터 1월 3일이면 해당 유저가 발생시킨 앱 설치 수는 아래와 같이 집계됩니다.

리텐션 리포트의 Installs (App)은 '에어브릿지 디바이스 ID' 기준으로 중복을 제외한 수치입니다. 같은 날짜에 '에어브릿지 디바이스 ID'를 기준으로 Installs (App)이 2건 발생하면 마지막에 발생한 이벤트에 대해서만 리텐션을 측정합니다. 다른 날짜에 '에어브릿지 디바이스 ID'를 기준으로 Installs (App)이 2건 발생하면 각각의 이벤트에 대해서 리텐션을 측정합니다.

이때 액츄얼스 리포트는 중복을 제외하지 않기 때문에 일반적으로 리텐션 리포트의 Installs (App) 수치가 액츄얼스 리포트 수치보다 작을 수 있습니다. 에어브릿지에서 사용하는 식별자에 대한 자세한 내용은 에어브릿지 가이드를 참고해 주세요.

리턴 이벤트가 스타트 이벤트를 모두 포함하도록 설정하면 Day, Week, Month, Hour, Minute 0 잔존율은 100%로 표시됩니다. 잔존을 판단하는 기준이 되는 리턴 이벤트에 스타트 이벤트가 항상 포함되기 때문입니다.

아래 예시를 확인해 주세요.

예시)

유저 4명이 4월 1일에 각각 아래 이벤트를 발생시켰습니다.

• A: Install (App), 구독 (App)

• B: Deeplink Open (App), 구독 (App)

• C: 장바구니 담기 (App), Install (App)

• D: 장바구니 담기 (App), Deeplink Open (App)

리텐션 리포트를 아래와 같이 설정했습니다.

• 조회 기간과 주기: 2024년 4월 1일~4월 5일, 일별

• 스타트 이벤트: Install (App), Deeplink Open (App)

• 리턴 이벤트: Install (App), Deeplink Open (App), 회원가입 (App), 구매 완료 (App)

Install (App)과 Deeplink Open (App)은 스타트 이벤트이자 리턴 이벤트입니다. 유저 A, B, C, D는 모두 4월 1일에 앱 설치 또는 딥링크 오픈을 실행했기 때문에 4월 1일의 Day 0에 스타트 이벤트와 리턴 이벤트를 실행한 유저로 집계됩니다.

따라서 4월 1일의 Day 0 잔존율은 100%로 표시됩니다.

고유 유저를 집계하는 기간이 다르기 때문에 전체 스타트 이벤트 열의 상위 행 잔존 수치와 하위 행 잔존 수치의 합계는 일치하지 않을 수 있습니다. 상위 행은 전체 분석 기간에 걸쳐 고유 유저를 집계합니다. 동일한 유저가 분석 기간 중 서로 다른 구간에 여러 개의 스타트 이벤트를 발생시켜도 상위 행은 유저 수를 1명으로 집계합니다.

하위 행은 각 구간에 한해서 고유 유저를 집계합니다. 동일한 유저가 분석 기간 중 서로 다른 구간에 여러 개의 스타트 이벤트를 발생시키면 각 하위 행에서 별개의 유저로 집계합니다. 따라서 상위 행의 총 잔존 수치는 각 하위 행의 잔존 수치를 모두 더한 값과 다를 수 있습니다. 고유 유저 집계에 사용되는 식별자에 대한 자세한 내용은 에어브릿지 가이드를 참고해 주세요.

예를 들어 동일한 유저가 아래처럼 행동했습니다.

• 1월 1일: A 광고 채널의 광고를 통해 앱 설치 이후 삭제

• 1월 2일: A 광고 채널의 다른 광고를 통해 앱 재설치

이때 리텐션 리포트의 주기를 일별로 설정했을 때 조회할 수 있는 결과는 아래와 같습니다.

• 1월 1일에서 1월 2일까지 A 광고 채널의 상위 행에 집계된 유저 수: 1명

• A 광고 채널의 1월 1일 하위 행에 집계된 유저 수: 1명

• A 광고 채널의 1워 2일 하위 행에 집계된 유저 수: 1명

리턴 이벤트는 이벤트가 발생한 날짜를 기준으로 집계됩니다.

예를 들어 1월 1일 KST(한국표준시) 오후 10시에 앱 설치 이벤트가 발생했습니다. 이 유저는 1월 1일 KST 오후 11시에 앱을 실행했습니다. 그리고 1월 2일 KST 오전 2시에도 앱을 실행했습니다.

리텐션 리포트에서 스타트 이벤트로 Install, 리턴 이벤트로 Any Event로 설정하면 Day0, Day1에 리턴 이벤트가 발생한 것으로 집계됩니다.

아니오, 날짜 단위로 집계됩니다. 아래 예시를 참고해 주세요.

유저가 아래처럼 행동했습니다.

• 1월 1일 오후 8시 앱 설치

• 1월 1일 오후 10시 앱 오픈

• 1월 2일 오전 8시 앱 오픈

리텐션 리포트에서 스타트 이벤트와 리턴 이벤트를 아래처럼 설정했습니다.

• 스타트 이벤트: Installs (App)

• 리턴 이벤트: Opens (App)

리텐션 리포트에서 조회할 수 있는 결과는 아래와 같습니다.

• Day 0(1월 1일)의 잔존 수치: 1명

• Day 1(1월 2일)의 잔존 수치: 1명

1월 2일 오전 8시에 발생한 앱 오픈은 앱 설치 발생 시각을 기준으로 12시간 후에 발생했습니다. 하루(24시간)이 모두 지나지 않았지만 1월 1일이 아닌 1월 2일에 발생했기 때문에 해당 이벤트는 Day 1의 잔존 수치로 기록됩니다.

리텐션 리포트(Retention Report)에서 예측 잔존일(Predictive Lifetime)을 확인하기 위해서는 만족해야 하는 조건이 있습니다. 아래 상황을 참고해 조건을 만족하는지 확인해 주세요.

• Predictive Lifetime을 활성화할 수 없다면 설정한 주기 또는 조회 기간을 확인해 주세요. 주기가 일별이어야 예측 잔존일을 확인할 수 있습니다. 또한, 조회 기간 시작일을 오늘 기준 최소 3일 전(D-3)으로 설정해야 합니다

• 테이블의 Predictive Lifetime 열에 Insufficient Cohort가 있다면 해당 열의 코호트에 있는 유저 수가 충분하지 않다는 의미입니다. 코호트에 있는 유저 수가 30명 이상이어야 합니다

예측 잔존일과 ARPDAU(Average Revenue Per Daily Active User)를 곱하면 예측 LTV(pLTV)를 계산할 수 있습니다. pLTV에 관한 내용은 에어브릿지 가이드를 참고해 주세요.

Users의 Total 수치는 Users의 날짜별 수치를 모두 더한 수치보다 항상 작거나 같습니다. 스타트 이벤트를 실행한 고유한 유저 수를 계산하는 기간 단위가 다르기 때문입니다. Total 수치는 분석 기간 전체에 걸쳐 유저 수를 집계합니다. 날짜별 수치는 날짜 단위로 유저 수를 집계합니다.

Paying Users 또한 같은 방식으로 스타트 이벤트와 레비뉴 이벤트를 모두 실행한 고유한 유저 수를 계산합니다.

유저가 10월 1일부터 10월 2일 사이에 아래와 같이 행동했습니다.

1. 10월 1일: 광고를 보고 앱 설치. 앱에서 제품을 구매한 이후에 앱 삭제

2. 10월 2일: 광고를 보고 다시 앱 설치. 이후 다시 앱에서 제품을 구매

레비뉴 리포트(Revenue Report)에서 10월 1일부터 10월 2일까지 조회하면 제품을 구매한 유저는 아래와 같이 집계됩니다.

• Users, Paying Users의 Total 수치: 총 1명

• Users, Paying Users의 일자별 수치: 1명(10월 1일), 1명(10월 2일), 총 2명

레비뉴 리포트의 Total Revenue 수치와 액츄얼스 리포트(Actuals Report)에서 매출 관련 메트릭으로 조회할 수 있는 매출액 수치는 아래 이유로 다를 수 있습니다.

• 음수 계산 여부

• 광고 성과 측정 방식

• 중복 집계

레비뉴 리포트와 액츄얼스 리포트의 수치는 아래 이벤트와 메트릭을 선택해서 비교할 수 있습니다.

레비뉴 리포트는 음수를 0으로 치환해 집계합니다. 액츄얼스 리포트는 0 미만의 음수를 집계합니다.

액츄얼스 리포트와 레비뉴 리포트는 서로 다른 방식으로 광고 성과를 측정합니다.

• 액츄얼스 리포트: 어트리뷰션 윈도우 안에 발생한 매출 관련 이벤트를 광고 성과로 측정합니다. 어트리뷰션 윈도우를 벗어난 이벤트는 메트릭 수치에 포함되지 않습니다

• 레비뉴 리포트: 레비뉴 이벤트를 가장 최근에 발생한 스타트 이벤트의 광고 성과로 측정합니다. [규칙 관리]>[기여 규칙]에서 설정할 수 있는 어트리뷰션 윈도우가 적용되지 않습니다

레비뉴 리포트에서는 어트리뷰션 윈도우 동안 발생하지 않은 매출도 함께 확인할 수 있습니다. 따라서 액츄얼스 리포트와 레비뉴 리포트의 수치 차이는 어트리뷰션 윈도우가 짧을수록 더 크게 발생할 수 있습니다.

유저가 같은 날 여러 건의 스타트 이벤트를 실행하면 레비뉴 이벤트는 레비뉴 리포트에서 중복으로 집계될 수 있습니다.

예를 들어 유저가 아래와 같이 행동했습니다.

1. 1월 1일 오후 2시: A 광고로 앱 설치

2. 1월 1일 오후 7시: B 광고로 설치한 앱을 딥링크 오픈

3. 1월 2일 오전 11시: 해당 앱으로 상품 구매

레비뉴 리포트에서 조회 기간을 1월 1일부터 1월 2일까지 설정하면 해당 유저를 아래와 같이 조회할 수 있습니다.

• A 광고로 유저가 발생시킨 1월 2일 레비뉴 이벤트: 1건

• B 광고로 유저가 발생시킨 1월 2일 레비뉴 이벤트: 1건

네, 액티브 유저 리포트(Active Users Report)에서는 앱 데이터와 웹 데이터를 모두 조회할 수 있습니다. 해당 데이터는 앱 메트릭과 웹 메트릭를 선택하면 확인할 수 있습니다.

액티브 유저 리포트에서 메트릭에 포함된 유저 수는 칼큘레이티드 바이에서 선택한 식별자를 기준으로 집계됩니다. 에어브릿지에서 사용하는 식별자에 대한 자세한 내용은 에어브릿지 가이드를 참고해 주세요.

액티브 유저 리포트는 설정한 주기를 기준으로 고유 유저를 집계하는 리포트이기 때문에 한 달 동안 집계된 DAU를 모두 더한 수치와 같은 기간 MAU 수치가 다릅니다.

예를 들어 유저 1명이 1달(30일) 동안 매일 앱을 실행했습니다. 주기에 따라 집계되는 수치는 아래와 같습니다.

• 일별: 1일을 기준으로 고유 유저를 집계합니다. 따라서 매일 DAU가 1로 집계됩니다. DAU의 합계는 30입니다.

• 월별: 1달을 기준으로 고유 유저를 집계합니다. 따라서 MAU가 1로 집계됩니다.

액티브 유저 리포트에서 그룹바이를 설정하면 그룹바이를 기준으로 고유 유저를 다시 집계한 결과를 확인할 수 있습니다. 따라서 그룹바이로 나뉜 항목의 합이 더 클 수 있습니다.

예를 들어 광고 채널 A와 광고 채널 B로 앱을 실행한 유저가 있습니다. 액티브 유저 리포트에서 그룹바이로 채널을 설정하면 해당 유저는 광고 채널 A와 광고 채널 B에서 각각 고유 유저로 집계될 수 있습니다. 하지만 그룹바이 설정을 해제하면 해당 유저는 채널과 관계 없이 고유 유저 1명이기 때문에 무조건 1번만 집계됩니다.

아닙니다. 알 수 없습니다. 스텝 간 전환 시간을 계산할 때 조회 대상이 되는 유저가 스텝에 따라 바뀌기 때문입니다. 대신 원하는 구간에 맞는 스텝을 설정해서 새로 조회하면 일정 구간의 전환 시간을 알 수 있습니다.

예를 들어 2번째 스텝과 3번째 스텝의 스텝 간 전환 시간이 10분, 3번째 스텝과 4번째 스텝의 스텝 간 전환 시간이 20분이라고 해서 2번째 스텝부터 4번째 스텝까지의 전환 시간이 30분은 아닙니다. 2번째 스텝부터 4번째 스텝까지의 전환 시간은 해당 스텝만 설정해 퍼널 리포트를 다시 조회해야 알 수 있습니다.

퍼널 리포트 설정을 정상적으로 마쳤다면 첫 스텝은 항상 100%로 나옵니다. 또한 나머지 스텝이 1%가 되지 않는 것은 전환율이 낮기 때문입니다. 아래 방법에 따라 설정을 변경하고 퍼널 리포트를 다시 조회해 보세요.

• 기존에 있는 첫 스텝을 삭제하고, 나머지 스텝만 남깁니다

• 컨버전 윈도우를 늘립니다. 전환이 발생하기 위해서는 충분한 기간이 필요할 수 있습니다

• 서비스의 유저 여정을 다시 고민합니다. 스텝과 선택한 스텝의 순서를 적절하게 설정해야 합니다

네, 저장됩니다. 하지만 퍼널 리포트를 조회한 결과가 항상 같지 않습니다.

Between과 Since는 특정 날짜를 선택하기 때문에 리포트 저장 기능으로 특정 날짜의 퍼널 리포트 결과를 쉽게 확인할 수 있습니다. 이와 다르게 last는 조회 시점을 기준으로 조회 기간이 결정되기 때문에 퍼널 리포트 결과가 바뀝니다. 예를 들어 기간이 last 10 days로 설정된 퍼널 리포트를 저장하면 리포트를 불러온 시점을 기준으로 항상 최근 10일의 퍼널 리포트 결과를 확인할 수 있습니다.

터치포인트 분석, 터치포인트 오버랩 리포트와 액츄얼스 리포트의 앱 설치 수가 일치하지 않을 수 있습니다. 대표적인 이유는 아래와 같습니다.

• 타임존

• 설치 집계 방식

각 리포트의 타임존이 다릅니다.

터치포인트 분석, 터치포인트 오버랩 리포트의 타임존은 KST(한국표준시)입니다. 해당 리포트의 타임존은 변경할 수 없습니다. 액츄얼스 리포트의 기본 타임존은 앱 타임존입니다. 해당 리포트의 타임존은 KST를 포함한 다른 타임존으로 변경할 수 있습니다.

따라서 액츄얼스 리포트의 타임존이 KST가 아니면 터치포인트 분석, 터치포인트 오버랩 리포트와 액츄얼스 리포트 사이에 설치 수 차이가 발생할 수 있습니다.

터치포인트 분석, 터치포인트 오버랩 리포트에서 분석 기준 이벤트를 Install로 설정하면 Total 또는 Total Conversions에서 앱 설치 수를 조회할 수 있습니다. 해당 수치는 분석 기간 동안 각 유저가 최초로 실행한 앱 설치를 집계한 수치입니다.

액츄얼스 리포트에서 Installs (App)로 조회할 수 있는 앱 설치 수는 분석 기간 동안 발생한 전체 앱 설치를 집계한 수치입니다. 같은 유저가 앱 설치를 여러 번 실행하면 액츄얼스 리포트는 각 앱 설치를 모두 집계합니다.

아래 예시를 참고해 주세요.

예시)

하나의 유저 여정에서 발생한 앱 설치 수가 리포트별로 다르게 집계될 수 있습니다. 유저 여정이 아래와 같습니다.

1. 1월 1일 앱 설치

2. 1월 2일 앱 삭제

3. 1월 3일 앱 설치

조회 기간이 KST 기준 1월 1일부터 1월 3일이면 해당 유저가 발생시킨 앱 설치 수는 아래와 같이 집계됩니다.