한눈에 보기: 특정 집약 데이터 기준이 초과로 표시되는 이유와 수량 한계에 도달하지 않기 위한 방법.
데이터 한도 초과란 무엇인가요?
앱스플라이어는 귀사의 인스톨 및 이벤트 데이터를 수집하여 집약합니다. 데이터는 각 데이터 기준에서 고유값으로 집약됩니다. 데이터 차원에서 고유값의 개수를 카디널리티(데이트 그룹별 수량)라고 부릅니다. 대부분의 분석 및 집약 리포팅 도구는 차원별로 카디널리티(데이트 그룹별 수량) 한계가 있습니다. 하나의 차원에서 고유값의 수가 수량 한계를 초과하면, 그 초과하는 데이터는 초과 그룹으로 분류됩니다. 미디어 소스 차원의 고유값 수가 수량 한계를 초과할 경우, 그 남은 미디어 소스 데이터 및 그에 기반한 모든 차원의 데이터도 초과 그룹으로 분류됩니다.
다음 예시들은 데이터 한계 수량이 귀사의 리포트에 어떤 영향을 미치는지 보여줍니다.
예시
예제 A: 캠페인 ID의 수량 한계
캠페인 ID의 수량 한계는 3000입니다. 어떤 날에 보고된 캠페인 ID 수가 3000개를 넘어가면, 초과하는 캠페인 ID들은 Exceeded_CampaignID_Limit 그룹으로 묶입니다.
예제 B: 이벤트의 수량 제한
- 이벤트 수량 한계를 3이라고 가정하겠습니다.
- 어떤 날에 7개의 고유 이벤트가 리포트됩니다: A, B, C, D, E, F, G. 즉, 이벤트 수량은 7입니다.
- 집약 리포트에서 이벤트 A, B, C는 개별적으로 나열됩니다. 이벤트 D, E, F, G는 Exceeded_Events_Limit 그룹에 묶입니다.
초과된 차원과 량 한계는 집약 데이터에 다음과 같은 영향을 미칩니다:
- 개요 대시보드
- 집약 데이터 내보내기 및 Pull API 리포트
- 마스터 API 리포트
- 액티비티 및 커스텀 대시보드에서의 클릭과 노출 데이터
- Protect360 대시보드
로데이터는 카디널리티(데이트 그룹별 수량) 한계의 영향을 받지 않습니다.
귀하의 데이터가 상당 부분 초과 그룹에 포함된 경우, 그 데이터는 세분화되지 않습니다. 이는 분석 리포트에서 부정확한 결과로 이어질 수 있습니다. 필요하다면, 카디널리티(데이트 그룹별 수량) 한계 없이 그룹을 만들기 위해 로데이터를 활용하세요.
다음 표에서는 앱 당, 일별로 카디널리티(데이트 그룹별 수량) 한계를 나열합니다.
| 디멘션 | 그룹 이름 초과 | ...당 제한 유형 | 일일 데이터 수량 제한 | Protect360의 일일 데이터 수량 |
|---|---|---|---|---|
| Ad | 광고 한도 초과 | 미디어 소스 | 1000 | - |
| 광고 ID | Exceeded_AdID_Limit | 미디어 소스 | 1000 | - |
| 광고세트 | Exceeded_AdSet_Limit | 미디어 소스 | 1000 | - |
| 광고세트 ID | Exceeded_AdSetID_Limit | 미디어 소스 | 1000 | - |
| 캠페인 | 캠페인 한도 초과 | 미디어 소스 | 3000 |
|
| 캠페인 ID | Exceeded_CampaignID_Limit | 미디어 소스 | 3000 |
|
| 채널 | Exceeded_Channels_Limit | 미디어 소스 | 200억 | 200억 |
| 사이트 ID | Exceeded_SiteID_Limit | 미디어 소스 | 1000 |
|
| 이벤트 | Exceeded_Events_Limit | 앱 | 300 | 인스톨/인앱 이벤트: 300 |
| 키워드 | 키워드 한도 초과 | 미디어 소스 | 1000 | - |
| 미디어 소스 이름* | Exceeded_MediaSource_Limit | 앱 | 1000 |
|
| * 미디어 소스 차원에서 고유 값이 수량 제한을 넘어서는 경우, 초과하는 미디어 소스 데이터 및 그 초과 미디어 소스를 기반으로 하는 모든 차원의 데이터는 초과 그룹으로 분류됩니다. | ||||
차원별 카디널리티( 제한
광고 세트 한도 초과 및 광고 한도 초과
- 미디어 소스 당 최대 1000개의 광고 세트 이름과 1000개의 광고 이름을 보유할 수 있습니다.
- 특정 날에는 1001번째 광고 세트 정보부터 광고 세트 한도 초과 소스로 그룹화됩니다. 광고 한도 초과 소스에도 같은 원칙이 적용됩니다.
팁
"나누어 정복" 전략을 다시 활용합니다. 일반적인 광고 세트 이름을 소수로 정하고(최대 50개가 이상적), 모든 이전 광고 세트 이름을 단일 광고로 할당하세요. 앱스플라이어 어트리뷰션 링크에 af_sub 파라미터를 사용하는 것도 가능합니다. 웹사이트 어트리뷰션으로 다음과 같은 일을 할 수 있습니다.
1. 광고 세트 한도 초과 나 광고 한도 초과를 방지하세요.
2. 중요 광고 세트 및 광고 트래픽을 중심으로 효율적으로 최적화하세요.
3. 로데이터에 있는 광고 세트 및 광고 이름을 기준으로 심도 있는 분석을 수행하세요.
광고 세트 ID 한도 초과 및 광고 ID 한도 초과
- 미디어 소스 당 최대 1000개의 고유 광고 세트 ID와 1000개의 고유 광고 ID를 사용할 수 있습니다.
- 특정 날에는 1001번째 광고 세트 ID부터 광고 세트 ID 한도 초과 소스로 그룹화됩니다. 광고 ID 한도 초과 소스에도 같은 원칙이 적용됩니다.
캠페인 한도 초과
- 하루에 최대 3000개의 고유 캠페인 이름을 사용할 수 있습니다.
- 어떤 날에는 3001번째 캠페인 정보부터 캠페인 한도 초과 소스로 그룹화됩니다.
팁
소수의 일반적인 캠페인 이름을 정의하고(최대 300개 권장), 모든 이전 캠페인 이름을 광고 세트로 할당하세요. af_adset는 앱스플라이어 어트리뷰션 링크 파라미터입니다. 웹사이트 어트리뷰션으로 다음과 같은 일을 할 수 있습니다.
1. Exceeded_Campaign_Limit.이(가) 나타나지 않도록 방지합니다.
2. 주요 광고 세트 트래픽을 기준으로 효과적으로 최적화하세요.
3. 로데이터에 담긴 캠페인 및 광고 세트 이름을 분석하여 심층적인 분석을 진행하세요.
Exceeded_CampaignID_Limit
- 하루 최대 3000개의 고유 캠페인 ID를 사용할 수 있습니다.
- 하루 동안 3001번째 캠페인 ID부터 시작하는 모든 캠페인 정보는 Exceeded_CampaignID_Limit 소스에 속하게 됩니다.
Exceeded_Channels_Limit
- 하루에 미디어 소스마다 최대 20개의 고유 채널 이름을 사용할 수 있습니다. Protect360의 경우, 한도는 1000입니다.
- 하루 동안 21번째 채널부터의 모든 채널 정보는 Exceeded_Channel_Limit 소스로 귀속됩니다.
Exceeded_Events_Limit
- 하루에 최대 300개의 고유 이벤트 이름을 사용할 수 있습니다.
- 하루 동안 301번째 이벤트부터의 모든 이벤트 정보는 Exceeded_Events_Limit라는 이름의 이벤트로 귀속됩니다.
팁
Exceeded_Events_Limit을 보지 않기 위해 고려해볼 수 있는 것:
- 리치 인앱 이벤트 사용하기. 다양한 이벤트에 대해 리포팅하는 대신 몇 가지 일반적인 이벤트 이름을 정의하세요(이상적으로 20개 이내). 이벤트간 차이점을 나타내기 위해 동적 이벤트 값을 이용하세요. 이 방법은 값 파라미터에 따라 최적화하고, 인앱 이벤트 로데이터 리포트.를 통해 이벤트 값들에 기반해 분석을 할 수 있게 합니다.
- 앱스플라이어 플랫폼에서 필요하지 않은 인앱 이벤트를 제거하기 위한 유효성 검증 규칙을 사용하세요.
예
예를 들어, 귀하의 앱 com.greatapp은 판매하는 양말의 색상별로 구매 인앱 이벤트를 보냅니다, 예를 들면 buy_red_socks, buy_blue_socks, buy_white_socks 등과 같은. 다양한 이벤트의 확장을 방지하기 위해, 색상을 이벤트 파라미터로 포함시킨 단일 이벤트 buy_socks로 모든 것을 단순화하세요.
키워드 한도 초과
- 하루에 미디어 소스별로 최대 1000개의 고유 키워드를 활용할 수 있습니다.
- 하루 동안 1001번째 키워드 이상의 모든 키워드 정보는 Exceeded_Keywords_Limit 소스에 그룹화됩니다.
Exceeded_MediaSource_Limit
- 하루에 사용할 수 있는 미디어 소스별 고유 이름은 최대 1000개입니다.
- 어느 날, 1001번째 이상의 미디어 소스 이름으로부터 얻은 캠페인 정보는 Exceeded_MediasSource_Limit소스로 묶여 처리됩니다.
Exceeded_SiteID_Limit
- 하루 동안 미디어 소스 별로 최대 1000개의 사이트 ID를 제공합니다.
- 하루 동안, 미디어 소스별로 1001번째 사이트 ID부터의 정보는 Exceeded_SiteID_Limit이라는 이름의 단일 사이트 ID로 분류됩니다. 따라서, 만약 사이트 ID Exceeded_SiteID_Limit을 보게 된다면, 문제가 된 미디어 소스에 너무 많은 사이트 ID가 사용되어서 사이트 ID별로 트래픽을 최적화하는 것이 정확도와 효율성이 떨어진다는 의미입니다.
팁
"분할 정복"을 실천하세요. 집계 데이터가 왜곡될 수 있는 미디어 소스 당 수천 개의 사이트 ID를 사용하는 대신, af_sub_siteid라고 불리는 두 번째 파라미터를 귀하의 어트리뷰션 링크에 사용해 보세요. 적은 수의 일반적인 사이트 ID(최적의 경우 최대 50개)를 정의하고, 그 아래에 이전의 모든 사이트 ID를 서브 사이트 ID로 분류하세요. 웹사이트 어트리뷰션으로 다음과 같은 일을 할 수 있습니다.
1. Exceeded_SiteID_Limit을 보기 금지
2. 중요한 사이트 ID 트래픽을 바탕으로 효과적으로 최적화하세요
3. 로데이터에 포함된 사이트 ID 및 서브 사이트 ID를 기반으로 심층 분석을 수행하세요
참고
리텐션 리포트에서 Exceeded_SiteID_Limit는 표시되지 않지만 모든 사이트 ID가 표시되는 것은 아닙니다. 사이트 ID가 무작위로 표시되긴 하지만, 한도를 초과했을 때 모든 것을 표시할 수 있는 UI의 제한점이 있습니다. 이 문제를 해결하기 위해 마스터 API를 통해 리텐션 데이터를 가져오세요.
초과된 소스를 피하는 방법은 무엇일까요?
장기적인 해결방안
대다수 광고주는 보통 수동으로 3000개의 캠페인을 정의하지 않기 때문에 초과 소스를 겪지 않을 것입니다.
만약 초과 소스를 겪게 된다면, 하나 이상의 미디어 소스가 캠페인, 사이트 ID, 광고 세트 또는 광고의 이름에 동적 값을 사용하고 있을 가능성이 큽니다. 앱 코드 내의 동적 인앱 이벤트로 인해 Exceeded_Events_Limit 소스 데이터가 나타날 수 있습니다.
팁
초과 소스를 방지하기 위해 인앱 이벤트, 캠페인, 사이트 ID, 광고 세트 및 광고의 명칭에 정적 값만을 사용하세요.
또한 언급된 초과 소스에 대한 구체적인 조언을 확인하세요.
단기적인 해결책
장기적인 해결책을 전부 시행하는 데는 며칠에서 몇 주가 소요될 수 있습니다.
하지만 지금 바로 당신의 데이터를 확인하고 싶다면 어떻게 해야 할까요?
설명한 바와 같이, 하루 동안 N+1 번째 클릭(또는 이벤트) 소스를 앱스플라이어가 수신할 때 초과 소스가 발생합니다. "초과" 소스의 데이터와 결합될 가능성이 있는 주목할만한 매체 소스를 사용하는 경우, 그런 매체들이 하루 중 늦은 시간에 도착할 수 있습니다. 보이는 초과 소스의 영향을 줄일 수 있는 간단한 방법이 있습니다:
팁
오늘의 데이터는 잠시 잊고 어제 및 그 이전 데이터만을 봅니다. 매일매일 데이터 집계 과정에서 전날 데이터를 재계산하고, 초과 소스에 가장 작은(늦지 않은 소스가 아닌) 소스들만을 소급해 할당합니다. 이러한 방식은 클릭 과잉에 의해 발생할 수 있는 왜곡을 최소화할 수 있도록 도와줍니다!