프로모션 넛지는 UI 한 덩어리로 보이지만, 실제로는 여러 앱·여러 페이지·재사용 컴포넌트에 흩어져 있다. 그래서 “이 클릭이 어느 지면의 어떤 변형에서 나왔는지”를 분석 이벤트에 일일이 심으려면 비용이 크다. 특히 넛지 → 내부 랜딩 → 외부 신청 URL처럼 단계가 나뉘면, 중간에서 맥락이 끊기기 쉽다.

이 글은 그때 우리가 시도한 작은 규약이다. 요지는 단순하다.

  • 같은 URL 안에서도 넛지를 구분할 수 있게 DOM에 data-* 규약을 둔다.
  • 페이지 단위 맥락location.pathname(또는 라우터의 현재 경로)을 보조로 쓴다.
  • 페이지를 넘어가도 남겨야 하는 맥락은 URL 쿼리 등 이동과 함께 전달되는 채널에 둔다.

즉, “DOM 규약만으로 끝”이 아니라 역할 분담을 명시하는 것이 포인트다.

왜 이벤트만으로는 빡센가

  1. 컴포넌트 재사용 — 같은 카드형 넛지가 마이·PDP·주문서에 붙으면, 클릭 핸들러 하나에 switch (page)를 계속 얹게 된다.
  2. 태깅 플랜의 폭발 — 이벤트 이름·프로퍼티 조합이 늘어날수록 대시보드·QA·온콜이 지친다.
  3. 랜딩 이후의 단절 — SPA 전환만 해도 “방금 그 넛지”는 DOM에서 사라진다. 외부 도메인으로 나가면 더하다.

그래서 “클릭 순간에만 의미 있는 정보”와 “이동 후에도 유지해야 하는 정보”를 나눠 설계할 필요가 있다.

우리가 정한 규약 (요약)

1) DOM: data-*는 “이 화면 안에서의 좌표”

넛지 루트(또는 클릭 가능한 래퍼)에 아래처럼 둔다고 하자. 이름은 팀 접두사로 통일한다.

속성 의미 예시
data-promo-surface 지면 ID (enum) mypage_main, pdp_discount, checkout_payment
data-promo-slot 같은 지면 안 위치 pushdown, accordion, sticky_cta
data-promo-variant 카피·실험 구분 (선택) copy_a, exp_2026q1

원칙: 값은 짧은 식별자만. 외부 파트너 URL의 긴 쿼리는 여기 붙이지 않는다. 민감정보·PII는 data-*에 넣지 않는다.

클릭 시에는 event.currentTarget.closest('[data-promo-surface]')로 읽고, 없으면 규약 누락으로 로깅하거나 unknown 버킷으로 보낸다.

2) Pathname: “어느 라우트인가” 보조

window.location.pathname페이지 단위 필터로는 유용하다. 다만 같은 pathname에 넛지가 여러 개일 수 있으므로 data-promo-slot 등이 필수이고, 앱이 여러 개면 필요 시 data-promo-app 같은 네임스페이스를 추가한다.

3) 이동: 쿼리는 “세션을 넘기는 용도”

랜딩 URL로 갈 때는 DOM이 사라지므로, 내부 랜딩에는 예를 들어 src(또는 팀 내부 키), 선택적으로 pos, variant만 붙인다. 외부 파트너 도메인으로 최종 이동할 때의 긴 파라미터는 랜딩/URL 빌더 한곳에서만 조립한다.

기대 효과와 한계

좋아진 것: QA가 DOM만 봐도 태그 확인 가능, 공통 헬퍼로 클릭 페이로드 조립, 이벤트 이름보다 규약이 안정적일 수 있음.

한계: 규약 누락·포털·중복 슬롯 이름, pathname만 믿기(웹뷰·리다이렉트), 이동 후는 쿼리·스토리지 등 다른 레이어가 맡아야 함.

정리

DOM에는 짧은 지면 ID, 이동에는 짧은 쿼리, 외부 URL 조립은 한 곳.


특정 제품 구현을 옮겨 적은 것이 아니라, 여러 앱에 퍼진 넛지를 추적할 때 팀에서 논의한 규약을 일반화한 메모다.