From bf891d2177696130c00db8f378a8d7bd82b5198e Mon Sep 17 00:00:00 2001 From: ttipo Date: Tue, 6 Oct 2026 13:14:42 +0900 Subject: [PATCH] =?UTF-8?q?docs:=20=EA=B5=AC=EB=A7=A4=20=EB=95=8C=20?= =?UTF-8?q?=EC=9C=A0=EC=9E=85=C2=B7=EB=B9=84=ED=9A=8C=EC=9B=90=20=EC=97=85?= =?UTF-8?q?=EC=B2=B4=20=EC=8B=A4=EC=A0=81=20=EA=B5=AC=ED=98=84=20=ED=98=84?= =?UTF-8?q?=ED=99=A9=EA=B3=BC=20=EB=B0=B0=ED=8F=AC=20=EC=88=9C=EC=84=9C=20?= =?UTF-8?q?=EC=A0=95=EB=A6=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5.5 --- docs/purchase-tracking.md | 132 ++++++++++++++++++++++---------------- 1 file changed, 78 insertions(+), 54 deletions(-) diff --git a/docs/purchase-tracking.md b/docs/purchase-tracking.md index cb3ad3a..f473585 100644 --- a/docs/purchase-tracking.md +++ b/docs/purchase-tracking.md @@ -1,37 +1,37 @@ -# 유료 구매 추적 — 현황과 다음 작업 +# 유료 구매 추적 — 현황과 배포 > 작성: 2026-10-06 · 다음 작업을 이어갈 때 먼저 읽는 문서. -> 운영 사용 안내는 [`imweb/README.md`](../imweb/README.md) 의 "신청·구매 내역" · "유료 구매 기록" · "업체 링크" 절. +> 운영 사용 안내는 [`imweb/README.md`](../imweb/README.md) 의 "신청·구매 내역" · "유료 구매 기록" · "구매 때 유입" · "업체 링크" 절. ## 0. 한눈에 | 항목 | 상태 | | --- | --- | -| 유료 구매 목록 (회원·비회원) | **구현 완료 · 운영 미배포** | -| 신청·구매 통합 화면 | **구현 완료 · 운영 미배포** | +| 유료 구매 목록 (회원·비회원) | 구현 완료 · `main` 머지 · **운영 미배포** | +| 신청·구매 통합 화면 | 구현 완료 · `main` 머지 · **운영 미배포** | | 업체 링크 구매 실적 (회원) | 운영 중 (이전 배포분) | -| 구매 때 유입경로 | **미구현** — 다음 작업 (4절) | -| 비회원 구매의 업체 실적 | **미구현** — 다음 작업 (4절) | +| 업체 링크 우선 (신청·구매 때 유입) | **구현 완료 · 푸시·머지 전** (`feat/purchase-inflow`, 4.5절) | +| 구매 때 유입경로 | **구현 완료 · 푸시·머지 전** (`feat/purchase-inflow`, 4절) | +| 비회원 구매의 업체 실적 | **구현 완료 · 푸시·머지 전** (`feat/purchase-inflow`, 4절) | -브랜치: `feat/purchase-history` (커밋 `ab7ef37`, 푸시·머지 전). -`fix/admin-ui-tweaks` 에서 따왔으므로 그 브랜치의 미푸시 커밋 3개(카톡 버튼 문구·링크 칸 줄 맞춤·직전 유입 표시 제거)를 함께 담고 있다. +`feat/purchase-history` 는 `main` 에 머지·푸시됐다 (`9e6cae7`). 구매 때 유입 작업은 그 위의 +`feat/purchase-inflow` 브랜치에 있다 (2026-10-06 기준 푸시·머지 전). --- ## 1. 지금 구매에 대해 알 수 있는 것 아임웹 주문 API(`GET /orders`)에는 **손님이 어디서 왔는지(UTM)가 없다.** -무료 신청은 신청 완료 화면이 그 순간의 유입을 보내지만, 구매에는 그런 화면 연동이 아직 없다. +그래서 무료 신청처럼 주문완료 화면이 그 순간의 유입을 보내고, 주문 동기화가 주문번호로 잇는다 (4절). | 항목 | 알 수 있나 | 근거 · 조건 | | --- | --- | --- | | 누가 샀는지 | O | 회원: 회원 정보 / 비회원: 주문서의 주문자 이름·이메일·연락처 | | 무엇을·언제 | O | 주문·상품당 한 줄, 주문 시각(wtime) | | 환불·취소 여부 | O | 최근 60일 주문만 다시 봐서 반영 | -| 업체 링크로 왔는지 | 일부 | **회원만.** 링크를 누른 브라우저에서 로그인 → 30일 안에 같은 상품 구매 | +| 업체 링크로 왔는지 | O | 회원: 링크를 누른 브라우저에서 로그인 / 비회원: 주문완료 화면이 보낸 클릭 ID. 30일 안에 같은 상품 구매 | | 가입 경로 | 회원만 | 가입 때 경로라 이번 구매 경로와 다를 수 있다 | -| 구매 때 유입경로 | **X** | 주문 데이터에 없다 | -| 비회원 구매의 업체 | **X** | 회원 코드가 없어 클릭과 이을 수 없다 | +| 구매 때 유입경로 | O (연동 후 주문) | 주문완료 화면이 보낸 값. 다른 기기에서 결제·스크립트 차단이면 없음 | --- @@ -90,7 +90,7 @@ | `GET /api/admin/activities/groups` | 상품별·업체별 신청·구매 수 | `by`(product·partner), `from`/`to` | | `GET /api/admin/activities/inflow-stats` | 유입 집계 | `basis`(apply·join), `groupBy`, 목록 필터와 동일 | -- `basis=apply`(신청 때 유입)는 **무료 신청만** 센다. 구매는 `join`(가입 경로)으로만 집계된다 — 비회원은 값 없음. +- `basis=apply` 는 처음엔 무료 신청만 셌으나, 4절 이후 **신청·구매 때 유입**(구매 포함)이다. `join` 은 가입 경로 — 비회원은 값 없음. - 구매 수는 `is_valid` 만, 환불·취소는 `cancelledCount` 로 따로. - **예전 `/api/admin/applications` (목록·groups·inflow-stats·products) 는 삭제했다.** 위젯과 백엔드를 함께 배포해야 한다. - 무료 신청 수집(`POST /api/applications`, 카톡 클릭)은 그대로다. `inflow_last_*` 는 저장만 하고 화면에서 쓰지 않는다. @@ -99,7 +99,7 @@ - 메뉴 "신청 내역" → **"신청·구매"**. 종류 [전체·무료 신청·유료 구매], 상품별/업체별 표에 무료 신청·카톡 버튼 클릭·유료 구매(환불 N) 칸. - 목록: 구분 배지(무료 신청 / 유료 구매 / 환불·취소), 비회원은 주문자 이름 + "비회원". 상세 패널에 주문번호·상태·주문자. -- 유료 구매만 볼 때 유입 집계는 가입 경로로 고정(신청 때 유입 버튼 비활성). +- (4절 이전) 유료 구매만 볼 때 유입 집계는 가입 경로로 고정했다 — 4절에서 풀었다. - 개요: "최근 7일 무료 신청" · "최근 7일 유료 구매" 카드, "최근 신청·구매" 목록. ### 2.6 파일 @@ -127,61 +127,83 @@ imweb/imweb-members.html · imweb/README.md ## 3. 배포 순서 (아직 안 함) -1. `feat/purchase-history` 머지 → 운영 서버에서 `docker compose --env-file .env.production up -d --build` - (마이그레이션 자동 실행, 에러 코드 변경 없음) -2. **바로 이어서** `imweb/imweb-members.html` 을 아임웹 관리자 페이지 코드에 다시 붙여 넣기 - (예전 조회 경로를 지웠으므로 한쪽만 바뀌면 RES_001 "찾을 수 없음") +`feat/purchase-history`(main 머지 완료)와 4절 작업을 **한 번에** 배포한다고 보고 적었다. + +1. 4절 브랜치 머지 → 운영 서버에서 `docker compose --env-file .env.production up -d --build` + (마이그레이션 `AddPurchases` · `AddOrderInflows` 자동 실행, 에러 코드 변경 없음) +2. **바로 이어서** 아임웹에 두 파일을 다시 붙여 넣는다 + - `imweb/imweb-members.html` → 관리자 페이지 코드 (예전 조회 경로를 지웠으므로 한쪽만 바뀌면 RES_001 "찾을 수 없음") + - `imweb/imweb-header-top.html` → Header Code (업체 링크 우선 v1.2 · 결제창 리퍼러 제외 v1.3 · 구매 때 유입 전송) 3. 업체 링크 메뉴의 **구매 집계 새로고침** → 1년치 주문 동기화 → 신청·구매 화면에 구매가 보이는지 확인 4. 비회원 구매 한 건을 열어 **주문자 이름·연락처가 실제로 채워지는지** 확인 (5절 첫 항목) +5. 테스트 주문 한 건 → 주문완료 화면 → 다음 동기화(또는 새로고침) 후 그 구매의 상세 패널에 **구매 때 유입**이 보이는지 확인 + (브라우저 개발자 도구 네트워크 탭에서 `order-inflows` 가 204 인지도 볼 수 있다) --- -## 4. 다음 작업 — 주문완료 화면에서 구매 때 유입·업체 잡기 +## 4. 구매 때 유입·비회원 업체 실적 (`feat/purchase-inflow`, 푸시·머지 전) -### 4.1 목표 - -- 구매 때 유입(UTM)을 남겨 신청 때 유입처럼 집계한다. -- **비회원 구매도 업체 실적으로 잡는다** — 회원 대신 주문번호로 잇는다. - -### 4.2 방식 (추천안) - -무료 신청 완료 위젯과 같은 방식이다. +### 4.1 흐름 ``` -주문완료 화면 ── 스크립트가 { 주문번호, MG_UTM.peek().value, MG_PARTNER.refs() } 를 보낸다 - │ POST /api/order-inflows (공개 · 엄격한 rate limit · 이름은 api-design 규칙에 맞춰 확정) +주문완료 화면 (/shop_payment_complete?order_no=…) + │ Header Code '구매 때 유입 전송' → { orderNo, inflow: MG_UTM.peek().value, partnerRefs: MG_PARTNER.refs() } + │ POST /api/order-inflows (공개 · 1분 10회 · 항상 204 · 같은 주문번호는 처음 값만) ▼ -order_inflows (가칭) order_no 유일, inflow raw/파싱값, partner refs, received_at - │ 주문 동기화가 같은 order_no 의 구매를 가져올 때 매칭 - ▼ -purchases 에 구매 때 유입 컬럼(가칭 inflow_source 등) 채움 -partner_conversions: 회원·비회원 모두 refs 로 귀속 (지금은 회원 touch 로만) +order_inflows order_no PK, inflow raw/파싱값, partner_refs varchar(16)[], received_at + │ 주문 동기화(PartnerOrderSyncService)가 페이지마다 + ├─▶ PurchasesService.recordOrders → UPDATE purchases … FROM order_inflows (inflow_source 가 빈 구매에만) + └─▶ PartnerAttributionService.attributeOrder(order, linked, refs) + 후보 = 회원 클릭 연결(partner_touches) ∪ refs 의 실제 클릭(사용 중인 그 상품 링크) → 30일 안 마지막 클릭 + → partner_conversions (비회원이면 member_code null) + 동기화가 끝까지 성공하면 90일 지난 order_inflows 를 지운다 ``` -- 스크립트 위치: Header Code(`imweb-header-top.html`)가 주문완료 페이지를 감지하거나, 주문완료 페이지 전용 코드 위젯. - UTM·업체 클릭 ID 는 이미 Header Code 가 보관하므로 읽기만 하면 된다. -- 위조 대응: 공개 API 라 막을 수는 없다. **아임웹에 실제로 있는 주문번호에만** 붙인다(동기화 시점 매칭이라 자연히 걸러짐). - 같은 주문번호에 두 번 오면 첫 값만, 오래 매칭되지 않은 행은 정리한다. -- 무통장입금: 주문완료 시점에 받아두고, 입금 확인 후 구매로 잡힐 때 붙는다. -- 귀속 규칙 변경 검토: 주문완료에서 온 refs 를 회원 touch 보다 우선할지, 30일 기준을 그대로 쓸지. -- 화면: `inflow-stats` 의 `basis=apply` 를 "신청·구매 때 유입"으로 넓히고, 목록의 "신청 때 유입" 칸에 구매도 표시. +- 주문완료 주소의 `order_no` 는 아임웹 API `orderNo` 와 같다 (2026-10-06 관리자 화면에서 확인). +- 유입 기준은 무료 신청과 같다 — 첫 경로(2일 보관), 업체 링크로 오면 그 업체가 우선 (Header Code v1.2). +- 결제창(카카오페이·네이버페이·카드사)에서 돌아올 때의 리퍼러는 유입으로 치지 않는다 — `AUTH_PATH` 에 `shop_payment` 추가 (v1.3). + 이전에는 `pay.kakao.com` 이 '카카오 소셜', `pay.naver.com` 이 '네이버 검색' 유입으로 잡힐 수 있었다. +- 관리자 화면: 유입 기준 "신청 때 유입" → **"신청·구매 때 유입"**, 구매 행·상세 패널에 구매 때 유입 표시, + 업체 링크 실적 상세에 비회원 구매는 주문자 이름 + "비회원 구매". +- 0원 주문은 지금처럼 둔다 (2026-10-06 결정). -### 4.3 시작 전에 확인할 것 +### 4.2 파일 -- [ ] **주문완료 페이지 주소와 주문번호 위치** — 주소창 파라미터인지 화면 DOM 인지. 테스트 주문 한 번으로 확인. - (아임웹 API 의 `orderNo` 와 같은 값인지도 확인) -- [ ] UTM 보관 기간 — 지금 `TTL_DAYS: 2` (`imweb-header-top.html` 49행). 광고 후 며칠 뒤 사는 경우가 많으면 늘릴지 결정. - 늘리면 무료 신청의 신청 때 유입에도 같이 영향 -- [ ] 비회원 구매 비중 — 많을수록 이 작업의 효과가 크다 (2절 배포 후 화면에서 확인 가능) +``` +backend/src/modules/purchases/order-inflow.entity.ts order_inflows +backend/src/modules/purchases/order-inflows.{controller,service}.ts (+spec) POST /api/order-inflows · 보관·정리 +backend/src/modules/purchases/purchases.service.ts (+spec) 구매 때 유입 채우기 · 주문자 이름 조회 +backend/src/modules/purchases/purchase.entity.ts inflow_* 칸 +backend/src/modules/partners/partner-attribution.service.ts (+spec) 비회원 귀속 (refs) +backend/src/modules/partners/partner-order-sync.service.ts (+spec) refs 전달 · 정리 +backend/src/modules/partners/entities/partner-conversion.entity.ts member_code nullable +backend/src/modules/partners/partner-links.service.ts · dto 비회원 실적에 주문자 이름 +backend/src/modules/activities/ 구매도 신청·구매 때 유입으로 조회·집계 +backend/src/migrations/1791258525922-AddOrderInflows.ts +imweb/imweb-header-top.html · imweb/imweb-members.html · imweb/README.md +``` -### 4.4 작업 체크리스트 +### 4.3 검증한 것 -- [ ] 엔티티·마이그레이션 (`order_inflows`, `purchases` 유입 컬럼) — 생성된 SQL 검토 -- [ ] 공개 엔드포인트 DTO 검증 + `@Throttle` (신청 기록처럼) -- [ ] 동기화 매칭 + 비회원 업체 귀속 + 단위 테스트 -- [ ] `activities` 유입 집계·목록 확장 -- [ ] 아임웹 스크립트 + `imweb/README.md` -- [ ] 필요하면 에러 코드 등록 → `npm run sync:error-codes` +- 백엔드 테스트 201개 통과 (새 테스트 12개), lint·build 통과. +- 로컬 Postgres: 공개 API(첫 값만 저장·형식 오류 VAL_001) → 구매 저장 시 유입 채움 → 비회원 주문이 클릭 ID 로 + 업체에 귀속 → 목록·유입 필터·집계·업체 실적 상세(주문자 이름)까지 확인. 넣은 데이터는 지웠다. +- Header Code 를 Node 로 흉내 내 확인: 결제창 리퍼러 무시, 업체 링크 클릭 ID 전송, 새로고침 시 재전송 없음, + 주문완료가 아닌 페이지·잘못된 주문번호면 보내지 않음. +- **실제 아임웹 주문완료 화면에서는 아직 돌려보지 않았다** (3절 5번). + +### 4.4 남은 확인 + +- [ ] UTM 보관 기간 — 지금 `TTL_DAYS: 2`. 광고 후 며칠 뒤 사는 경우가 많으면 늘릴지 결정 (무료 신청에도 같이 영향) +- [ ] 비회원 구매 비중 — 배포 후 화면에서 확인 +- [ ] 예전 신청 기록 보정 — v1.2 이전 신청은 업체 링크로 왔어도 첫 경로가 광고일 수 있다 + (`inflow_last_medium='partner'` 인데 첫 유입이 다른 행). 보정할지 결정 + +### 4.5 업체 링크 우선 (같은 브랜치) + +업체 링크(`utm_medium=partner`)로 들어오면 보관 중인 첫 경로를 그 업체로 바꾼다 (Header Code v1.2). +광고로 가입 → 업체 링크로 신청·구매하면 가입 경로는 광고, 신청·구매 때 유입은 업체로 남는다. +여러 업체를 거치면 마지막 업체 — 업체 실적의 마지막 클릭 규칙과 같다. --- @@ -193,4 +215,6 @@ partner_conversions: 회원·비회원 모두 refs 로 귀속 (지금은 회원 결제 수단 `FREE` 주문을 뺄지 결정 (업체 실적 판정 `evaluateOrder` 도 같이 바꿔야 수가 맞는다). - 60일보다 오래된 주문의 환불은 반영되지 않는다 (서버 재시작 직후 1년치 실행 때만 다시 본다). - 휴대폰에서 링크·광고를 보고 PC 에서 사면 유입·업체가 이어지지 않는다 (무료 신청도 같다). +- 구매 때 유입은 공개 API 로 받으므로, 주문번호를 아는 사람이 먼저 가짜 값을 보내면 그 값이 남는다 + (실제 주문에만 붙고, 업체 실적은 실제로 있는 클릭만 인정한다). - 구매자의 가입 경로는 "이번 구매 경로"가 아니다 — 화면 문구에서 혼동하지 않게 유지.