LibCore · 광고 페이지 카운팅

페이지 카운팅 동작 명세

전면광고 노출 조건의 기준이 되는 페이지 카운트가 어떻게 판정·누적·소비되는지에 대한 현재 동작 명세. 원칙은 하나다 — 사용자 조작(user action) 1회는 페이지 최대 1회로 계상된다. 이 문서는 LibCore 공통 규칙을 다루며, 앱 쪽 대응(명시 카운팅 지점·진입/제외 배선·상속 요건·디버그 도구)은 워드빗 적용 명세 → 에 따로 있다.

01동작 원리

유저 입력이 있고 난 뒤에 화면(Activity 또는 Fragment)이 변경되었을 때만 카운트한다. 상태는 ViewExtensions.userActionPending(FLAG) boolean 1개.

기본 동작

 유저 입력 (터치/키 다운)
   → FLAG ON
   → Activity.onResume     → 카운팅 & FLAG 전환 (OFF)
   → Fragment.onResume     → FLAG == OFF → SKIP

 // 조작 1회 = 카운트 정확히 1회. 같은 입력에서 이어지는 연쇄 resume 은 전부 SKIP

예외 — 앱 아이콘 실행 진입

아이콘 탭은 런처(다른 앱)의 터치라 FLAG 가 서지 않지만, 앱 실행도 카운트되어야 하는 진입이다. 그래서 이 경우에만 메인 진입을 "유저 입력이 있는 상태"로 만들어 준다:

 Splash → AppOpen 광고 → Count 0 (리셋)
   → MainActivity.onCreate   → 유저 입력 처리 (FLAG ON)   // goMain 이 실어 보낸 extra 소비
   → MainActivity.onResume   → 카운팅 (count = 1) & FLAG 전환 (OFF)
   → LearnFragment.onResume  → FLAG == OFF → SKIP
   → WordFragment.onResume   → FLAG == OFF → SKIP   // 한 진입 = 정확히 1회

부가 정보 — 플래그(FLAG) 상세 규칙

• FLAG ON (앱 내 입력) — BaseActivity2.dispatchTouchEvent(터치 다운)·dispatchKeyEvent(백 키)에서 noteUserInteraction() 호출. 같은 지점에서 increaseTouchCount()(터치 집계)도 함께 돈다. 백 키는 경로가 하나 더 있다 — API 33+ 에서 화면이 자기 OnBackPressedCallback 을 가지면 back 이 dispatchKeyEvent 에 오지 않으므로, backUserActionSpy(소비하지 않는 감시 콜백)가 FLAG 만 기록하고 원래 처리자에게 재-dispatch 한다. 세는 단위는 AdMob 정책의 user action 정의(clicks, swipes, back button presses)에 맞춘 것.
• FLAG ON (앱 윈도우 밖의 조작 — 명시 부여) — 우리 dispatch 에 안 잡히는 조작은 해당 지점에서 직접 켠다: ① 앱 실행 — goMain 이 EXTRA_NOTE_USER_ACTION extra 를 실어 보내고 Main 의 onCreate 가 1회 소비하며 ON (launch 시점에 직접 켜면 Splash finish 의 무효화와 경합하므로 extra 로 전달) ② 광고 닫기 — setAdPageAndTimeReset 안에서 ON (광고 닫는 탭은 광고 SDK 윈도우에서 발생).
• FLAG OFF (소비) — increasePageCount 진입 시 FLAG 가 ON 이면 카운트 후 OFF, OFF 면 카운트 없이 skip (사용자 조작 없음) 로그만 남긴다.
• FLAG OFF (무효화) — 앱이 백그라운드로 갈 때(BaseApplication2.onActivityStopped → clearPendingUserInteraction) 소비되지 않은 잔존 FLAG 를 끈다 — 다음 진입의 자동 체인(배달 등)이 이전 세션의 터치를 잘못 소비해 오카운트되는 것을 방지. 정상 네비게이션은 새 화면 resume(소비)이 이전 화면 stop 보다 먼저라 영향 없다.

02카운트가 올라가는 경로

모든 경로가 increasePageCount() 한 곳으로 모이고, 판정은 그 안의 플래그가 한다.

03카운트되지 않는 경우

04시나리오별 동작

05광고 게이트와의 관계

카운트는 전면광고 노출 조건(isAdShowEnable)의 입력이다.

06재진입 경로와 Splash 중복 (태스크 동작)

홈으로 나갔다 돌아올 때 Splash·앱오픈 광고가 다시 나올지는 태스크의 상태와 출생 기록(baseIntent)이 결정한다.

baseIntent 오염 — 아이콘 탭에서도 중복이 재현되는 조건

baseIntent(태스크를 만든 인텐트)는 태스크 생성 시 딱 한 번 기록되고, 위에 액티비티를 얹는 것으로는 바뀌지 않는다. 아이콘 탭의 "전면 전환만" 특수 처리는 런처 인텐트가 baseIntent 와 filterEquals 로 일치할 때만 적용된다.

 ── 오염 시나리오: 태스크가 명시 인텐트로 '생성'된 경우 ──────────────

 앱 죽은 상태에서 노티 클릭 / 딥링크 / am start
   → 태스크 생성, baseIntent = 명시 인텐트 (MAIN/LAUNCHER 카테고리 없음)

 이후 아이콘 탭 (태스크 살아 있음)
   → 런처 인텐트와 filterEquals 불일치 → "다른 실행" 으로 판단
   → 살아있는 Main 위에 Splash 를 쌓음

 ── 중복 진입 체인 (문제) ─────────────────────────────────────────

 [Main(살아있음), Splash(새로 얹힘)]
   → getOpenAD → 앱오픈 광고 SHOW (리셋: count 0)
   → DISMISS → goMain (NEW_TASK | CLEAR_TOP)
   → 아래의 구 Main 재사용 (singleTop) → ★ onNewIntent
   → onNewIntent 는 게이트를 열지 않음 (setAdEnable 은 잠금화면 수신자 전용)
   → count 0 그대로 → 전면광고 안 뜸 // 연속 광고 차단 — 남는 현상은 앱오픈 광고 중복 노출뿐

재현 레시피와 확인 명령

# 1. 태스크 제거 후 명시 인텐트로 '태스크 생성' (baseIntent 오염)
adb shell am force-stop net.wordbit.enkr
adb shell am start -n net.wordbit.enkr/.SplashActivity
# 2. Main 진입 → 홈키 → 아이콘 탭 → Splash 가 Main 위에 쌓이면 재현

# 재현 가능 상태인지 사전 확인 — cat=[...LAUNCHER] 가 없으면 재현됨
adb shell dumpsys activity activities | grep -A3 "baseIntent.*wordbit"

07기록과 Firestore 업로드

카운팅 정확도를 실데이터로 검증하기 위한 장치. RC 게이트 기본 off.

08디버깅 방법