제품 지표에 기반한 마케팅과 성장

1. 왜 ChatGPT App의 마케팅은 제품 분석이지 “소음”이 아닌가

클래식 웹에서는 Google Analytics를 꽂고, 모든 링크에 UTM 태그를 달고, 리타기팅 픽셀 몇 개를 붙여서 그럭저럭 운영할 수 있습니다. 하지만 ChatGPT 생태계는 다릅니다. 사용자는 ChatGPT 인터페이스 안에 있고, 여러분의 App은 그 대화의 “손님”일 뿐입니다. 쿠키, iframe, Facebook Pixel은 여기서 통하지 않습니다.

이렇듯 제품 이벤트가 성장에 대한 주요(그리고 종종 유일한) source of truth가 됩니다. App을 얼마나 자주 여나요? 핵심 시나리오에 도달하나요? 돌아오나요? 수익과는 어떻게 연결되나요? 이런 질문에 답하는 것은 외부 카운터가 아니라 여러분의 MCP 이벤트와 서버 사이드 분석입니다.

여기서 product‑led growth (PLG)라는 용어가 자연스럽게 떠오릅니다. 성장은 여러분이 배너를 얼마나 샀느냐가 아니라, 제품이 사용자의 시나리오를 얼마나 잘 해결하고 데이터를 바탕으로 이를 어떻게 발전시키느냐에 달려 있습니다.

그래서 이 강의의 주인공은 외부 마케팅 채널이 아니라 GiftGenius 내부의 이벤트 퍼널입니다. 채널도 다루지만, 이 이벤트에 영향을 주는 가설로서만 다룹니다.

GiftGenius의 AARRR: 우리만의 해적 퍼널

AARRR 모델(Acquisition, Activation, Retention, Revenue, Referral)은 ChatGPT App에 잘 들어맞으며, 단지 우리 앱의 이벤트 언어로 옮기면 됩니다.

GiftGenius에서는 다음처럼 정의할 수 있습니다:

app_opened

workflow_completed (first time)

repeated workflow_completed / app_opened

checkout_started, checkout_success

referral_sent, referral_activated (optional)

중요한 점은 이 퍼널이 프런트엔드 클릭이 아니라 MCP/App 수준의 “사용 이벤트”로 표현된다는 것입니다. 사용자가 열었다, 시나리오를 완료했다, 구매했다, 돌아왔다. 웹에서처럼 때로 “마우스의 모든 움직임”을 추적하는 대신, 여기서는 분석이 간결하고 의미 있어야 합니다. “어디를 클릭했나”보다 “시나리오에서 무엇을 했나”에 더 집중하세요.

GiftGenius의 기본 버전에서는 우선 네 가지 레벨(Acquisition, Activation, Retention, Revenue)에 집중합니다. Referral은 중요하지만, 제품과 결제의 코어가 안정화된 다음 단계로 미룹니다.

2. 이벤트 모델 설계: 로그에서 분석까지

observability 모듈에서 이미 자유 형식의 “장문 로그”가 아니라 구조화된 JSON 로그를 쓰기로 했습니다. 이제 그 위에 제품 이벤트 모델을 구축합니다.

최소 아이디어: App의 중요한 단계마다 이벤트 객체를 생성합니다. MCP 쪽에서는 이를 로깅도 하고, 외부 분석 시스템(BI, ClickHouse, BigQuery 등)으로 전송할 수도 있습니다.

GiftGenius를 위한 가장 단순한 이벤트 정의는 다음과 같습니다:

// 이벤트의 공통 형식
type GiftGeniusEventType =
  | 'app_opened'
  | 'workflow_started'
  | 'workflow_completed'
  | 'ideas_shown'
  | 'idea_clicked'
  | 'checkout_started'
  | 'checkout_success'
  | 'checkout_failed';

interface AnalyticsEvent {
  type: GiftGeniusEventType;
  userId?: string;          // auth에서(있다면)
  sessionId: string;        // ChatGPT 세션 UUID
  timestamp: string;        // ISO 문자열
  properties?: Record<string, unknown>;
}

Next.js 쪽에서 이벤트를 보내기 위한 작은 helper를 따로 두면 편리합니다:

async function trackEvent(event: AnalyticsEvent) {
  await fetch('/api/analytics', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(event),
  });
}

서버의 /api/analytics에서는 이것을 어떻게 처리할지 결정할 수 있습니다. DB에 저장하거나, 로거로 보내거나, 데이터 파이프라인으로 스트리밍하는 식으로요. 핵심은 모든 이벤트가 하나의 통일된 포맷을 따르는 것입니다. 실무에서는 같은 제품 이벤트 집합을 가지되, 이벤트가 발생하는 지점은 여러 곳일 수 있습니다. 어떤 단계는 MCP 서버에서 logger.info로 찍는 것이 편하고, 어떤 단계는 위젯에서 AnalyticsEvent로 /api/analytics에 보내는 것이 낫습니다. 중요한 것은 “파이프”의 수가 아니라 이벤트 타입("app_opened", "workflow_completed" 등)과 필드가 일관되고 합의되어 있다는 점입니다.

3. Acquisition: 사용자 유입을 어떻게 파악할까

마케팅의 첫 과제는 누가 얼마나 오는지에 답하는 것입니다. ChatGPT App에서는 이 “유입”이 앱 실행으로 고정됩니다. 우리가 로깅하려는 것은 "app_opened"입니다.

GiftGenius에서는 위젯 측(컴포넌트 마운트에 반응)과 서버 측(예: 세션에서 첫 callTool 시) 모두에서 할 수 있습니다. 렌더링 특성에 덜 의존하는 서버 쪽이 더 안정적이지만, 여기서는 단순화를 위해 프런트를 살펴보겠습니다.

trackEvent를 첫 렌더에 호출하는 GiftGenius 위젯 컴포넌트 예시:

import { useEffect, useRef } from 'react';
import { trackEvent } from '../lib/analytics';

export default function GiftGeniusWidget() {
  const reported = useRef(false);

  useEffect(() => {
    if (reported.current) return;
    reported.current = true;

    trackEvent({
      type: 'app_opened',
      sessionId: crypto.randomUUID(),
      timestamp: new Date().toISOString(),
      properties: { source: 'chatgpt_app' },
    });
  }, []);

  return (
    <main>
      {/* ...위젯의 주요 UI... */}
    </main>
  );
}

실무에서는 sessionId와 userId를 클라이언트에서 생성하지 않고(예: _meta나 인증 토큰에서) 기존 컨텍스트에서 가져오고 싶을 것입니다. 핵심은 GiftGenius가 실행될 때마다 이런 이벤트가 반드시 발생해야 한다는 점입니다.

트래픽 소스 문제는 웹보다 까다롭습니다. referrer와 UTM 태그가 제한적이니까요. 보통 두 가지 전략 중 하나를 씁니다. 첫째, 주요 트래픽 소스를 Store로 보고 "app_opened"의 시간 분포만 분석합니다. 새로운 Store 리스팅을 배포했다면 "app_opened" 급증과 그 이후 퍼널 레벨을 봅니다. 둘째, 명시적 파라미터를 이용합니다. 예를 들어 https://chat.openai.com/...&utm_source=blog2025 같은 링크를 주면, 첫 "app_opened"에서 이 태그를 컨텍스트에서 가져와 referral_source 필드에 넣을 수 있습니다.

즉 acquisition 지표는 대략 이렇게 보입니다. “하루 "app_opened" 수”, “일주일 동안 App을 실행한 고유 userId 수”, “가능하다면 referral_source 분포”.

4. Activation: GiftGenius 안에서 “aha 모먼트” 찾기

사람들이 곧바로 App을 닫아버린다면 acquisition만으로는 의미가 없습니다. 두 번째 핵심 레이어는 Activation입니다. 사용자가 App이 실제로 유용하다고 처음 느끼는 순간이죠.

GiftGenius에서는 이 순간을 workflow 완료와 연결하는 것이 타당합니다. 사용자가 수신자 정보를 입력하고 필터를 설정하면 App이 예를 들어 10개의 관련 아이디어를 보여줍니다. 바로 그때 사용자에게 가치가 처음 보입니다.

이를 "workflow_completed" 이벤트로 고정하는 게 편합니다. 이 단계는 위젯에 결과를 보내기 직전, 선물 후보를 모두 모아둔 MCP 서버에서 로깅하는 것이 좋습니다:

logger.info('event.workflow_completed', {
  type: 'workflow_completed',
  userId,
  sessionId,
  requestId,
  ideasCount: giftIdeas.length,
  timestamp: new Date().toISOString(),
});

여기서 logger는 이미 SLO와 cost 계측을 위해 추가했던 구조화 로거입니다. 거기에 제품 이벤트를 하나 더한 것입니다.

"workflow_completed"를 기준으로 activation‑rate를 계산합니다: activation_rate = (최소 한 번의 "workflow_completed"가 있는 고유 userId 수) / (해당 기간 "app_opened"가 있는 고유 userId 수).

더 거칠게도 볼 수 있습니다. “sessionId 세션 중 "workflow_completed"가 있었던 세션 비율.” 중요한 것은 팀에 익숙한 지표로 삼는 것입니다. activation이 높을수록 App의 출발이 좋습니다.

5. Retention: 사용자가 App으로 돌아오는가

ChatGPT App의 retention은 일반 웹 제품보다 조금 더 어렵습니다. 한편으로 ChatGPT 자체는 사람들이 원래 자주 돌아오는 공간입니다. 다른 한편으로 사람들은 여러분의 App이 아닌 다른 수많은 App으로 돌아올 수도 있습니다. 우리는 사용자가 다시 GiftGenius로 돌아오는지를 알고 싶습니다.

인증(모듈 10)이 있다면 안정적인 userId 또는 tenantId가 있습니다. 그 경우 정의는 단순합니다. 예컨대 첫 "workflow_completed" 이후 7일이 지나 새 "workflow_completed"나 최소한 "app_opened"가 있다면 사용자를 “유지(retained)”된 것으로 간주합니다.

auth가 없으면 sessionId와 휴리스틱 userKey(예: _meta에 접근 가능하다면 OpenAI 계정의 hash)를 이용한 더 약한 지표를 쓸 수 있지만, 이 강의에서는 userId가 있다고 가정하겠습니다.

SQL 유사 논리로는 대략 다음과 같습니다(의사 코드):

-- 첫 번째 활성화
WITH first_activation AS (
  SELECT user_id, MIN(timestamp) AS first_ts
  FROM events
  WHERE type = 'workflow_completed'
  GROUP BY user_id
),
retained_d7 AS (
  SELECT fa.user_id
  FROM first_activation fa
  JOIN events e
    ON e.user_id = fa.user_id
   AND e.timestamp >= fa.first_ts + INTERVAL '7 day'
   AND e.timestamp <  fa.first_ts + INTERVAL '14 day'
   AND e.type IN ('app_opened', 'workflow_completed')
)
SELECT COUNT(*) / (SELECT COUNT(*) FROM first_activation) AS d7_retention
FROM retained_d7;

프로덕션에서 이렇게 “예쁜 SQL”을 반드시 쓸 필요는 없지만, 핵심 아이디어는 이해해야 합니다. retention은 사람들이 App을 다시 사용하러 오는지를 보는 것이지, 한 번 결제까지 갔는지만 보는 것이 아닙니다.

6. Revenue: 퍼널을 매출과 연결

GiftGenius의 Revenue 레이어는 우리가 왜 이 모든 것을 하는지를 상기시킵니다. 커머스 모듈에서 이미 결제 주변 이벤트 "checkout_started", "checkout_success", "checkout_failed"를 추가했습니다. 이 이벤트는 수익 지표(전환과 평균 객단가)의 핵심이 됩니다.

사용자가 “선물 구매”를 누르고 ACP/Stripe로 checkout 세션을 생성할 때, MCP 측에서 다음 이벤트를 로깅합니다:

logger.info('event.checkout_started', {
  type: 'checkout_started',
  userId,
  sessionId,
  requestId,
  amount: checkout.amount,
  currency: checkout.currency,
  timestamp: new Date().toISOString(),
});

PSP에서 성공 webhook이 오면:

logger.info('event.checkout_success', {
  type: 'checkout_success',
  userId,
  sessionId,
  orderId,
  amount: payment.amount,
  currency: payment.currency,
  timestamp: new Date().toISOString(),
});

이제 전환을 쉽게 계산할 수 있습니다:

• "workflow_completed" → "checkout_started": 사람들이 결제로 얼마나 자주 이동하는가
• "checkout_started" → "checkout_success": 결제 흐름의 성능(카드 오류, 프로드, 결제 UX)은 어떤가

동시에 동일한 이벤트를 지난 시간 강의의 비용 통제와 cost 계측 로그와도 연결합니다. requestId나 sessionId를 통해, 이 구매에 이르기까지 어떤 tool 호출이 있었고 토큰/비용이 얼마였는지 알 수 있습니다. 이렇게 “평균 cost_per_paid_workflow”와 “성공 주문당 매출‑원가” 같은 지표를 얻습니다.

7. Referral: 사용자가 다른 사용자를 데려올 때

ChatGPT App의 Referral 레이어는 약간 특이합니다. 자체 푸시나 뉴스레터는 없지만, 사용자들은 채팅을 공유하고 링크를 공유하며 “Store에서 GiftGenius를 찾아봐”라고 서로에게 말할 수 있습니다.

다음 조건이라면 "referral_sent"와 "referral_activated" 이벤트를 도입할 수 있습니다:

• App 링크에 추천 코드나 파라미터를 제공하는 경우(?ref=friend123)
• "app_opened" 컨텍스트에서 referral_source/campaign을 처리하는 경우

GiftGenius의 기본 MVP에서는 Referral을 나중으로 미뤄도 됩니다. 먼저 Acquisition/Activation/Revenue를 정비하고 퍼널 코어가 작동함을 확인하세요. 다만, 이를 어디에 “연결”해야 하는지는 기억합시다. 별도의 프로모코드 Excel이 아니라 동일한 이벤트 로그와 지표에 연결해야 합니다.

GiftGenius의 시각적 퍼널

머릿속에 그림을 그리기 쉽게 작은 다이어그램을 그려봅시다:

flowchart LR
  A[app_opened] --> B[workflow_started]
  B --> C[workflow_completed]
  C --> D[checkout_started]
  D --> E[checkout_success]

각 간선은 측정 가능한 전환입니다. 마케팅, UX 변경, 모델 실험은 결국 이 전환 중 하나 이상을 끌어올려야 합니다. 무언가를 하면서 어느 간선이 개선될지 말할 수 없다면, 그건 수상합니다.

성장 대시보드: 우선 필요한 리포트

GiftGenius의 최소 성장 대시보드를 상상해 봅시다. 거대한 BI 시스템을 만들려는 게 아니라, 최소한 매주 확인할 수 있는 표를 원합니다.

일자별 집계 보고서 예시:

3일에는 acquisition을 “부었습니다”("app_opened"가 증가). 하지만 activation과 전환이 떨어졌습니다. 엉뚱한 트래픽이 들어왔거나 UX를 망가뜨렸을 수 있습니다. 바로 이런 표가 좋은 마케팅과 단지 “시끄러운” 마케팅을 구분하는 데 도움이 됩니다.

시간 시계열 위에 코호트도 유용합니다. 특정 주에 온 사용자들의 7/30일 retention. 하지만 우선은 일/주 단위의 간단한 슬라이스를 만들 수 있으면 충분합니다.

8. 이벤트를 대상으로 한 일련의 마케팅 실험

이제 가장 “마케팅다운” 지점으로 갑니다. 외부 활동(글, Store 리스팅, 파트너십)을 App 내부 이벤트와 어떻게 연결할까요?

핵심 원칙: 모든 마케팅 아이디어는 어떤 제품 지표가 어떻게 변해야 하는지에 대한 가설로 정식화됩니다.

GiftGenius 예:

• “Store 리스팅(아이콘, 설명, 데모 영상)을 개선하면 신규 사용자 "app_opened"가 증가하고, 가능하면 그들 중 activation‑rate도 올라야 한다.”
• “연말 선물 고르는 법에 관한 글을 쓰고 그 안에 GiftGenius 링크를 넣으면, 향후 3일 동안 referral_source가 "blog_ny2025"인 "app_opened"가 증가하고, 이어 해당 코호트의 "workflow_completed"도 증가해야 한다.”

기술적으로는 "app_opened" 이벤트에 campaign 또는 referral_source 같은 필드를 추가하는 경우가 많습니다. 예를 들어 App 초기화 시 ChatGPT 컨텍스트에서 어떤 태그를 받았다면:

trackEvent({
  type: 'app_opened',
  sessionId,
  timestamp: new Date().toISOString(),
  properties: {
    referral_source: openaiContext.referralSource ?? 'organic',
    app_version: '1.3.0',
  },
});

이제 “캠페인별” 리포트를 만들 수 있습니다. referral_source가 "blog_ny2025"인 사람들의 "app_opened"와 "workflow_completed"가 얼마나 되는지, 그리고 이것이 오가닉과 어떻게 다른지 비교합니다.

중요한 점은 외부에서 그려주는 “리치(노출)”만으로 마케팅 성공을 판단하지 않는 것입니다. 어떤 블로거의 영상이 백만 뷰를 기록했다면 멋집니다. 하지만 GiftGenius에선 “우리 내부의 "app_opened"와 "workflow_completed"가 증가했는가”가 성공입니다.

9. 예시: GiftGenius를 위한 마케팅 실험

이제 하나의 구체적인 시나리오로 모든 것을 묶어 보며, 외부 캠페인을 GiftGenius 내부의 제품 이벤트에 깔끔히 연결해 봅시다.

가설: 인기 선물 블로그의 글이 “알맞은” 사용자를 데려온다. 글에서는 ChatGPT로 바로 보내지 않고, 다음과 같은 우리 랜딩 페이지 링크를 제공합니다:

https://giftgenius.app/landing?utm_source=giftblog2025

사용자는 GiftGenius 설명과 “ChatGPT에서 열기” 버튼이 있는 짧은 랜딩으로 옵니다. 랜딩 백엔드에서는 utm_source를 읽어 사용자 프로필(또는 별도 테이블)에 저장합니다. 예: acquisitionSource = "giftblog2025". 랜딩의 버튼은 Store의 ChatGPT App으로 연결되고, 사용자는 App을 연결한 뒤 사용을 시작합니다.

이 사용자가 ChatGPT에서 GiftGenius를 실행하고 여러분의 백엔드가 Apps SDK / MCP로부터 첫 호출을 받을 때, 저장해 둔 acquisitionSource를 불러와 제품 이벤트에 추가합니다. "app_opened"는 다음처럼 보일 수 있습니다:

logger.info('event.app_opened', {
  type: 'app_opened',
  userId,
  sessionId,
  referral_source: user.acquisitionSource ?? 'organic',
  timestamp: new Date().toISOString(),
});

같은 방식으로 "workflow_completed", "checkout_started", "checkout_success" 이벤트도 태깅합니다. 이후 실험은 코호트 비교로 귀결됩니다. referral_source가 "giftblog2025"인 사용자 대 오가닉. “블로그” 코호트에서 완료 시나리오와 결제 비율이 더 높고 사용자당 매출이 같거나 더 좋다면 캠페인은 성공입니다. 반대로 App 실행만 늘고 "workflow_completed"와 "checkout_success" 전환이 하락한다면, 글이 주로 ‘구경꾼’을 데려온 것입니다.

이 접근의 장점은, 한 번만 UTM을 웹 세계에서 내부의 referral_source로 “번역”하면 그다음부터는 App의 제품 분석만으로 일합니다. 요술도 없고 URL 파라미터를 ChatGPT 안으로 직접 밀어 넣으려는 시도도 없습니다.

동시에 CAC(집행 비용)과 cost_per_task 등을 어딘가에 기록하고 있다면, 수익성 관점에서도 볼 수 있습니다. “이 채널은 수지가 맞는가?”라는 더 재무적인 실험이 됩니다.

10. Privacy‑first 분석: 정책과 상식을 지키자

또 하나의 중요한 포인트는 “Facebook처럼” 되지 않는 방법입니다. 클래식 웹과 달리 OpenAI는 ChatGPT Apps에서 프라이버시에 매우 엄격합니다. 개인 데이터를 추적하거나, 불필요한 PII를 수집하거나, 대화 전체 텍스트를 아무 데나 보내면 안 됩니다.

GiftGenius의 바람직한 분석 관행:

1. 이벤트에 사용자의 원문 메시지를 저장하지 않는다. 대신 “시나리오의 사실”만 기록한다. 시나리오 유형, 노출한 아이디어 개수, 결제 성공 여부 등.
2. 사용자를 구분해야 하면 이메일/이름이 아니라 userId, tenantId 같은 가명화 식별자를 사용한다. PII는 인증된 DB에 보관하고, 분석은 익명 키로 운영한다.
3. 작동에 필요하지 않다면 사람을 직접 식별할 수 있는 필드를 로그/이벤트에서 피한다. 예: 배송지 전체 주소는 이벤트에 필요 없다. 그 자리는 커머스의 보호된 DB다.
4. 가능한 한 집계 분석을 사용한다. 여러분이 관심 있는 것은 수백 명 단위의 activation‑rate와 retention이지 개개인의 실명 리스트가 아니다.

또한 audit & lifecycle 모듈을 이미 다뤘다는 점을 잊지 맙시다. 사용자가 데이터 삭제를 요청하면 retention 로직이 이를 반영해야 합니다. 이는 모듈 15의 주제에 가깝지만, 여기서는 분석이 무분별한 수집에 대한 면죄부가 아니라는 점만 기억하면 됩니다.

11. cost 계측과 SLO의 연결: 모든 것을 계산하는 마케팅

기술적으로 이상적인 그림은 다음과 같습니다. 구조화된 단일 이벤트 스트림이 있고, 각 user 세션에는 다음이 매핑됩니다:

• 제품 이벤트("app_opened", "workflow_completed", "checkout_success")
• cost 데이터(토큰, cost_estimate, 도구별 duration_ms)
• SLO 지표(MCP/도구의 지연과 오류, 가용성)

그러면 모든 마케팅/제품 의사결정이 거의 자동으로 데이터 기반이 됩니다. 예를 들어 이렇게 물을 수 있습니다:

• “캠페인 X 사용자들의 activation_rate는 얼마이며, 그들의 성공 workflow 평균 비용은?”
• “Store 트래픽이 증가함에 따라 error_rate 또는 p95 latency가 오르지는 않는가?”
• “지난 강의의 ‘비용 ↔ 품질’ 실험에서 모델을 저렴하게 바꿨을 때, "checkout_success" 전환이나 사용자당 revenue가 떨어지지는 않았는가?”

이 모든 것은 새 시스템을 꾸려낼 필요 없이, 이미 도입한 로그와 cost 도구를 재사용하면 됩니다.

결국 ChatGPT App의 마케팅은 그 자체의 트래픽이 아니라, 앱 내부의 구체적인 제품 지표 개선에 관한 일입니다. 핵심 시나리오 단계를 로깅하고("app_opened", "workflow_completed", "checkout_success"), 이를 cost 계측과 SLO에 연결하며, 마케팅 활동을 “퍼널의 어떤 고리를 어떻게 개선할지”에 대한 가설로 공식화하세요. 퍼널과 프라이버시 제약을 머리에 넣고 있으면, 제품과 성장에 대한 결정이 자동으로 더 합리적이고 지속 가능해집니다.

12. 제품 지표와 마케팅에서 자주 하는 실수

실수 #1: 트래픽만을 위한 마케팅, 활성화를 위한 마케팅이 아님.
종종 팀은 어떤 글이나 트윗 이후 "app_opened"가 급증하면 활성화와 전환을 보지 않은 채 실험이 성공했다고 생각합니다. 결과는 “관광객”이 잔뜩 늘어나 부하와 cost만 올리고, 돈은 못 벌고 실제 사용자가 되지도 않습니다. 올바른 접근은 퍼널의 다음 단계를 항상 보는 것입니다. 들어온 사람 중 얼마나 "workflow_completed"와 "checkout_success"까지 갔는가.

실수 #2: 통일된 user 식별자 부재.
가끔 App이 이벤트를 로깅하기 시작하지만, 안정적인 userId나 최소한 tenantId 없이 진행합니다. 이런 상태에서는 “하루 이벤트 수” 같은 것만 계산할 수 있고, retention이나 cost_per_user는 계산할 수 없습니다. 나중에 올바른 user tracking을 추가하는 것은, 특히 프라이버시 제약이 강해지면 매우 어려워집니다. 인증 단계(모듈 10)에서 식별 스키마를 설계하고 모든 이벤트에서 사용하세요.

실수 #3: 핵심 이벤트 대신 “모든 사소한 것”을 추적.
event 분석에 처음 반응은 모든 것을 로깅하는 것입니다. 마우스 오버, 인풋 포커스, 모든 리렌더 등. ChatGPT 컨텍스트에선 특히 해롭습니다. 이런 이벤트는 사용 모델과 잘 맞지 않고, 노이즈를 양산하며, 프라이버시 리스크를 높입니다. 소수의 핵심 시나리오 이벤트로 제한하고, 그것을 깊이 분석하는 편이 훨씬 유익합니다.

실수 #4: 어트리뷰션 없는 마케팅 캠페인.
흔한 패턴: 팀이 캠페인(글, 영상, 파트너십)을 시작하지만, 유입 트래픽을 전혀 태깅하지 않아 “효과가 있었나?”를 추측만 합니다. 그 결과 지표 변화가 희석됩니다. 간단한 UTM 유사 파라미터라도 사용해 "app_opened" 이벤트의 referral_source나 campaign을 명시적으로 기록하고, 이후 오가닉과 코호트를 비교하는 것이 훨씬 낫습니다.

실수 #5: “완전한 분석”을 명분으로 privacy 제약을 무시.
세부사항에 집착하다 보면 이벤트에 사용자 요청의 원문, 선물 수신자의 개인 정보, 주소 등 PII를 쓰기 시작합니다. 이는 OpenAI/Store 정책과 법적 리스크(GDPR, CCPA 등) 양쪽에서 모두 위험합니다. 올바른 분석은 시나리오의 집계 특징과 익명 식별자에 기반해야 하며, “혹시 몰라서” 대화를 통째로 저장하는 것이 아닙니다.

실수 #6: 품질과 성장을 무시한 채 cost만 최적화.
cost 모듈 이후 “절약 모드”에 과하게 빠지기 쉽습니다. 토큰을 어떻게든 줄이려다 activation_rate, retention, "checkout_success"가 하락하면, 그 절약은 겉보기만 이득입니다. 제품 가치를 깎아먹는 것이니까요. 항상 “cost ↔ 품질 ↔ 성장”의 삼각형을 염두에 두고, 프롬프트/모델/UX 변경은 원가와 제품 지표 모두의 관점에서 보세요.