사용자 획득을 트리거하는 이벤트입니다. 이는 사용자가 진정으로 "획득"되었다고 간주하는 시점을 정의하는 중요한 비즈니스 작업입니다.

사용자 지정 이유 

기본값인 첫 방문은 종종 사용자 가치를 나타내는 약한 신호입니다. 사용자가 실수로 광고를 클릭하거나 즉시 이탈할 수 있습니다. 이 설정을 맞춤설정하면 단순한 호기심 클릭이 아닌 의미 있는 행동을 유도한 마케팅 소스에 장기 가치(LTV)가 기여되도록 할 수 있습니다.

기본값: 첫 방문(사용자가 웹사이트를 처음 방문할 때 획득됨)

업종별 일반적인 대안

작동 원리

첫 방문(으)로 설정된 경우:

• 사용자는 웹사이트를 처음 방문할 때 즉시 획득됩니다.
• 기여 분석은 첫 방문부터 시작됩니다.

맞춤 이벤트(예: sign_up)로 설정된 경우:

• 사용자는 이벤트를 수행할 때까지 첫 방문부터 "획득 전 기간"에 진입합니다.
• 획득 전 기간 동안 이벤트는 룩백 윈도우 내의 마지막 비오가닉 접점에 기여됩니다(마지막 접점 기여).
• 맞춤 UA 이벤트가 발생하면 사용자 획득 전환이 생성되고 장기 기여 분석이 시작됩니다.

예시 시나리오(UA 이벤트 = sign_up):

• 180일 사용자가 Facebook 광고를 통해 방문 → 획득 전 기간 시작
• 180일 사용자가 Google 광고를 통해 방문 → 기여가 Google로 전환됨(마지막 접점)
• 180일 사용자 가입 → 사용자 획득이 Google 광고에 기여됨

180일 사용자가 구매를 수행함 → LTV 측정을 위해 Google에 구매 기여가 할당됨

AppsFlyer가 사용자 획득을 유도한 마케팅 터치포인트를 찾기 위해 과거로 얼마나 거슬러 올라가는지를 나타냅니다.

이 윈도우는 AppsFlyer가 마케팅 터치포인트를 얼마나 오래 "기억"할지를 제어합니다. 사용자가 광고를 통해 방문했지만 나중에 UA 이벤트를 완료하는 경우, 이 설정은 해당 광고가 여전히 기여를 인정받을지 여부를 결정합니다.

기본값: 30일

범위: 1시간 ~ 90일

작동 원리

사용자가 UA 이벤트(예: sign_up)를 수행하면 AppsFlyer는 이 윈도우 내에서 가장 최근의 오가닉이 아닌 터치포인트를 찾아 해당 마케팅 소스에 획득을 기여시킵니다.

예시 1(30일 룩백):

• 180일 사용자가 Facebook 광고를 클릭하고 웹사이트를 방문함
• 180일 사용자가 직접 돌아와 sign_up 이벤트를 완료함
• 결과: Facebook에 할당된 사용자 획득(30일 룩백 윈도우 내)

예시 2(윈도우 만료):

• 180일 사용자가 Facebook 광고를 클릭하고 웹사이트를 방문함
• 180일 사용자가 직접 돌아와 sign_up 이벤트를 완료함

결과: 오가닉으로 표시된 사용자 획득(30일 룩백 윈도우 외부)

재참여 전환 후 AppsFlyer가 해당 마케팅 터치포인트에 이벤트를 계속 기여하는 기간입니다.

이 설정은 리타겟팅 캠페인이 사용자 활동에 대해 얼마나 오랫동안 기여를 인정받을지를 결정합니다. 이는 리타겟팅 노력에 대한 기여를 인정하는 것과 장기적인 LTV를 원래 획득 소스로 다시 기여하는 것 사이의 균형을 맞춥니다.

기본값: 30일

범위: 1시간 ~ 90일

작동 원리

획득된 사용자가 오가닉이 아닌 소스(예: 리타겟팅 광고)를 통해 돌아와 재참여 기준을 충족하면 리타겟팅 전환이 생성됩니다. 이 윈도우 내의 이벤트는 이중 기여를 받습니다:

1. 기본 기여 → 리타겟팅 캠페인
   • 목적 리타겟팅 캠페인에 기여도 부여
2. 보조 기여도 → 원래 UA 소스
   • 목적 전체 사용자 생애 가치(LTV)를 원래 획득 시점으로 되돌려 측정하는 UA 뷰를 지원함

예시 (기간 내):

• 180일 사용자가 페이스북 광고를 통해 획득됨
• 180일 사용자가 이메일 리타겟팅 캠페인을 클릭하고 돌아옴 (리타겟팅 전환 생성됨)
• 180일 사용자가 100달러를 구매함 (리타겟팅 10일 후)
• 결과 - 이중 기여도:
  • 기본 (리타겟팅 뷰): 이메일 캠페인이 100달러 구매에 대한 기여도를 획득함
  • 보조 (UA 뷰): 페이스북 광고 또한 사용자의 LTV에서 100달러로 추적됨
• 리포트:
  • 통합 뷰: 이메일에 기여된 구매를 표시함
  • 리타게팅 보기 이메일에 기여된 구매를 표시함
  • UA 뷰 페이스북에 기여된 구매를 표시함

오가닉이 아닌 터치포인트가 리인게이지먼트(리타겟팅) 전환을 생성하기 위해 필요한 최소 사용자 비활동 기간입니다.

사용자가 이미 귀하의 웹사이트와 활발히 상호작용하고 있을 때 리타겟팅 캠페인에 기여도가 부여되는 것을 방지합니다. 이는 캠페인이 실제로 비활동 상태인 사용자를 타겟팅하도록 보장하여 리타겟팅 예산을 최적화합니다.

기본값: 비활성화 완료

범위: 0(비활성화) ~ 30일

작동 원리

비활성화 시:

• 획득한 사용자의 모든 오가닉이 아닌 터치포인트가 리타겟팅 전환을 생성함

활성화 시 (예: 7일):

• 사용자가 최소 7일 동안 비활성 상태였던 경우에만 리타겟팅 전환을 생성합니다.
• 사용자가 최근에 활성 상태였다면, 방문은 대신 원래 UA 소스로 기여됩니다.

제약 조건:

• 비활성 기간(재획득)을 초과할 수 없습니다.

예시(7일 비활성 기간):

• 180일 사용자가 페이스북 광고를 통해 획득됨
• 180일 사용자가 오가닉으로 방문합니다.
• 180일 사용자가 리타겟팅 광고를 클릭함 → 리타겟팅 전환 없음 (비활성 기간 2일뿐임)
• 180일 사용자가 리타겟팅 광고를 클릭함 → 리타겟팅 전환 생성됨 (비활성 기간 12일)

사용자가 "이탈"된 것으로 표시되기까지의 완전한 비활성 기간입니다. 이탈된 사용자는 재획득될 수 있으며, 새로운 사용자 획득 전환을 생성합니다.

이 설정은 귀하의 비즈니스 이탈 임계값을 정의합니다. 이 설정은 사용자가 언제 "손실"된 것으로 간주되어 재획득 대상이 되는지를 결정하며, 이를 통해 윈백 캠페인이 이탈된 사용자를 다시 데려온 것에 대한 성과를 인정받을 수 있게 합니다.

기본값: 90일

범위: 1~180일

작동 원리

사용자가 이탈된 것으로 표시될 때:

• 사용자는 더 이상 새로운 이벤트에 대해 원래 UA 소스로 기여되지 않습니다.
• 사용자가 "재획득 전" 상태로 진입합니다(재획득 대기 중).
• 원래 획득 시의 기여 기간은 더 이상 적용되지 않습니다.

이탈된 사용자가 돌아올 때:

• 사용자가 재획득 이벤트를 수행하는 경우 → 새로운 UA 전환 생성됨
• 윈백 캠페인이 새로운 획득 소스로 인정받습니다
• 보고 관점에서 사용자는 완전히 새로운 획득으로 처리됩니다

예시(90일 기간):

• 180일 Google 광고를 통해 획득한 사용자
• 180일 마지막 활동
• 180일 사용자 이탈(90일 동안 비활동)
• 180일 사용자가 이메일 윈백 캠페인을 클릭함

180일 사용자가 재획득 이벤트를 수행함 → 새로운 UA 전환이 이메일 캠페인에 기여함

이탈한 사용자에 대한 재획득을 트리거하는 이벤트입니다. 이탈한 사용자만 재획득할 수 있습니다.

많은 사용자 획득 이벤트는 두 번 발생할 수 없는 일회성 작업(예: 가입, 첫 구매)입니다. 이 설정을 통해 이탈한 사용자가 돌아왔음을 알리는 반복 가능한 이벤트를 정의할 수 있습니다.

기본값: 방문 (이탈한 사용자는 첫 복귀 방문 시 즉시 재획득됩니다)

일반적인 대안: 로그인 또는 구매

작동 원리

사용자 지정 이벤트로 설정된 경우(예: 로그인):

• 이탈한 사용자는 재획득되려면 특정 이벤트를 수행해야 합니다
• 사용자는 재획득이 발생하기 전에 여러 번 방문할 수 있습니다
• "진정한" 재획득에 대한 더 엄격한 정의입니다.

예시(재획득 이벤트 = 로그인):

• 사용자가 90일 동안 활동하지 않아 이탈했습니다
• 사용자가 이메일 윈백 캠페인을 클릭하고 방문함 → 아직 재획득되지 않음
• 하루 후, 사용자가 로그인함 → 재획득 전환이 생성되고 이메일 캠페인에 기여됨

사용자 획득 후 AppsFlyer가 해당 전환에 이벤트를 기여하는 최대 기간입니다.

기본값: 영구적

사용 가능한 옵션 없음, 1일, 7일, 30일, 60일, 90일, 180일, 365일, 영구(데이터 보존 기간에 따라 제한됨)

기본(필수, 자동)

• 귀하의 메인 웹사이트 도메인(앱 생성 시 설정됨)
• 자동으로 추가되며 제거할 수 없습니다
• 웹 앱당 정확히 하나의 기본 도메인
• 자동 하위 도메인 제외: 기본 도메인은 모든 하위 도메인을 자동으로 제외합니다
  • 예: example.com은 shop.example.com, blog.example.com 등을 자동으로 제외합니다.
• 배제의 영향 논셀프 어트리뷰션 

내부(선택 사항)

• 기본 도메인에 포함되지 않는 귀하 브랜드의 다른 도메인
• 최대 99개의 추가 도메인 추가
• 예: example.co.uk, example.in와 같은 다양한 최상위 도메인
• 배제의 영향 논셀프 어트리뷰션 

외부 (선택 사항)

외부 도메인 제외에는 두 가지 유형이 있습니다:

외부(사용자가 기재)

• 웹사이트에서 직접 사용되지만 브랜드의 일부가 아닌 도메인.
• 여기에는 결제 게이트웨이, 결제 처리 사이트, 인증 제공업체가 포함됩니다
• 최대 99개의 추가 도메인 추가
• 예: auth0.com, okta.com, facebook.com, google.com
• 배제의 영향 방문은 무시됨

외부(앱스플라이어가 기재)

• AppsFlyer에서 자동으로 제외되는 도메인:

  결제 제공업체

  • PayPal (결제)
  • Stripe (결제)
  • Adyen (결제)
  • Klarna (결제)
  • Braintree (결제 게이트웨이)
  • Square (결제)
  • Paddle (결제)
  • Mollie (결제)
  • Alipay (결제)
  • Razorpay (결제)
  • Paytm (결제)
  • PayU (결제 체크아웃)
  • Mercado Pago (결제 체크아웃)
  • Yandex Pay (결제 체크아웃)
  • Naver Pay (결제 체크아웃)

  OAuth 및 SSO 로그인

  • Google 로그인 (Google 계정 로그인)
  • Apple ID (Apple 계정 로그인)
  • Microsoft (Microsoft 365 / Entra 계정 로그인)
  • Microsoft Live (Outlook/Live 계정 로그인)
  • Facebook 로그인 (Facebook 로그인 도메인 전용)
  • Yandex 로그인 (Yandex 계정 로그인)
  • Kakao 로그인 (Kakao 계정 로그인)
  • Naver 로그인 (Naver 계정 로그인)
  • LINE 로그인 (LINE 계정 로그인)
  • Weixin 로그인 (WeChat OAuth 로그인)
  • VK 로그인 (VK 계정 로그인)
  • Daum 로그인 (Daum 계정 로그인)
• 자동화된 도메인 목록은 수정할 수 없습니다.
• 배제의 영향 방문은 무시됨

도메인을 추가하려면:

1. 웹 앱 설정 → 기여(Attribution)로 이동하세요
2. 제외 도메인 섹션으로 이동합니다
3. 도메인 추가를 클릭합니다.
4. 도메인 이름을 입력합니다(예: custom-gateway.com)
5. 도메인 유형을 선택합니다: 내부 또는 외부
6. 저장을 클릭합니다.

중요 사항:

• 제외는 1시간 이내에 적용됩니다
• 변경 사항은 향후에만 적용됩니다(과거 데이터에는 영향을 주지 않음)
• 일반적인 결제 제공업체 및 OAuth/SSO 로그인 도메인은 자동으로 제외됩니다. 외부(AppsFlyer에서 나열됨)에서 전체 목록을 확인하세요(수동으로 추가할 필요 없음)

하위 도메인 형식

• 도메인 이름만 입력(프로토콜, 경로 또는 포트 제외)
• 도메인당 최대 500자
• 프로토콜(https://)은 자동으로 제거되며 소문자로 변환됩니다

예시:

• = ["example.com",
• shop.example.com ✅ (example.com이 기본 도메인인 경우 불필요)
• https://example.com → example.com ✅ (프로토콜 제거됨)
• example.com/path ❌ (경로 허용되지 않음)
• example.com:8080 ❌ (포트 허용되지 않음)

제한 사항:

• 총 최대 100개 도메인(기본 도메인 1개 포함)

1. 새 웹 앱 만들기
   1. 내 앱 → 앱 추가 → 웹사이트 선택으로 이동
2. 웹 SDK ID 선택 
   웹사이트의 코드 변경을 방지하려면 기존 PBA 개발자 키를 재사용(권장)하십시오.
3. 설정 구성 
   PBA 설정을 새 웹 기여도 설정에 매핑
4. 모든 제외 도메인 
   PBA(브랜드 번들) 제외 도메인을 새 웹 기여도 설정에 매핑

참고: 각 PBA 개발자 키는 하나의 새 웹 앱에만 할당할 수 있습니다.