Marketing e crescimento baseados em métricas de produto

1. Por que o marketing de um ChatGPT App é analytics de produto, não “ruído”

Na web clássica dá para plugar Google Analytics, colocar parâmetros UTM em todos os links, instalar alguns pixels de retargeting — e tocar a vida. No ecossistema do ChatGPT é diferente. O usuário está na interface do ChatGPT, e o seu App é um “hóspede” nesse diálogo. Cookies, iframe e Facebook Pixel não têm vez aqui.

Isso automaticamente torna os eventos de produto a principal (e muitas vezes única) fonte de verdade sobre crescimento. Com que frequência abrem o App? Chegam ao cenário-chave? Voltam? Como isso se relaciona à receita? A essas perguntas responde não um contador externo, mas seus eventos MCP e a analytics no servidor.

Aqui surge de forma muito lógica o termo product‑led growth (PLG): o crescimento vem não de quantos banners você comprou, mas de quão bem o produto resolve o cenário do usuário e de como você o evolui com base em dados.

Por isso, o personagem principal desta aula é o funil de eventos dentro do GiftGenius, e não o canal de marketing externo. Canais existirão, mas apenas como hipóteses que impactam esses eventos.

AARRR para o GiftGenius: seu funil pirata

O modelo AARRR (Acquisition, Activation, Retention, Revenue, Referral) se encaixa muito bem em um ChatGPT App — só precisamos traduzi-lo para a linguagem de eventos do nosso aplicativo.

Para o GiftGenius, podemos descrevê-lo assim:

app_opened

workflow_completed (pervyy raz)

povtornye workflow_completed / app_opened

checkout_started, checkout_success

referral_sent, referral_activated (opcional)

Importante: este funil é descrito não por cliques de frontend, mas por “eventos de uso” no nível MCP/App: o usuário abriu, seguiu o fluxo, comprou, voltou. Diferente da web, onde às vezes você rastreia “cada movimento do mouse”, aqui a analytics deve ser compacta e significativa: menos “onde clicou”, mais “o que fez no cenário”.

Para a versão básica do GiftGenius, focamos primeiro nos quatro primeiros níveis (Acquisition, Activation, Retention, Revenue). Referral continua importante, mas como um próximo passo a ser ligado quando o núcleo do produto e dos pagamentos já estiver estabilizado.

2. Projetando o modelo de eventos: dos logs à analytics

No módulo sobre observability, já combinamos escrever logs JSON estruturados, e não “romances de log” em forma livre. Agora, sobre eles, construímos o modelo de eventos do produto.

Ideia mínima: cada etapa importante no App gera um objeto de evento. No lado MCP, você pode tanto logá-lo quanto enviá-lo para um sistema externo de analytics (BI, ClickHouse, BigQuery — o que preferir).

Uma definição bem simples de eventos para o GiftGenius pode ser assim:

// Forma geral do evento
type GiftGeniusEventType =
  | 'app_opened'
  | 'workflow_started'
  | 'workflow_completed'
  | 'ideas_shown'
  | 'idea_clicked'
  | 'checkout_started'
  | 'checkout_success'
  | 'checkout_failed';

interface AnalyticsEvent {
  type: GiftGeniusEventType;
  userId?: string;          // do auth, se houver
  sessionId: string;        // UUID da sessão no ChatGPT
  timestamp: string;        // string ISO
  properties?: Record<string, unknown>;
}

É útil criar um pequeno helper para enviar eventos a partir da parte Next.js do aplicativo:

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

No servidor /api/analytics você já pode decidir o que fazer com isso: guardar no banco, enviar para o logger ou transmitir para um data‑pipeline. O principal é que todos os eventos estejam em um formato único. Na prática, você terá o mesmo conjunto de eventos de produto, mas vários pontos de nascimento: alguns passos é mais conveniente fixar direto no servidor MCP via logger.info, outros — enviar do widget como AnalyticsEvent para /api/analytics. Importa menos quantos “canos” técnicos você tem e mais que os tipos de eventos ("app_opened", "workflow_completed" etc.) e seus campos permaneçam únicos e consistentes.

3. Acquisition: como entender de onde vêm os usuários

A primeira tarefa do marketing é responder quem chega e quantos são. Em um ChatGPT App, essa “chegada” é fixada pela abertura do App no chat. O que queremos logar chama-se "app_opened".

Para o GiftGenius, isso pode ser feito tanto no lado do widget (reagindo ao mount do componente) quanto no servidor (por exemplo, na primeira callTool da sessão). É mais confiável no servidor, para não depender de particularidades de render, mas, por simplicidade, vamos considerar o front.

Exemplo de componente de widget do GiftGenius com chamada a trackEvent no primeiro render:

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 principal do widget... */}
    </main>
  );
}

Na prática, você vai querer obter sessionId e userId de um contexto já existente (por exemplo, de _meta ou do token de autorização), e não gerá-los no cliente. Mas a essência é que cada inicialização do GiftGenius deve gerar esse evento.

O problema das fontes de tráfego é mais difícil do que na web: referrers e parâmetros UTM são limitados. Normalmente se usa uma de duas estratégias. A primeira é assumir que a principal fonte de tráfego é a Store e analisar apenas "app_opened" no tempo: se você publicou uma nova listagem na Store, observe o pico de "app_opened" e os níveis seguintes do funil. A segunda é usar parâmetros explícitos: se você dá ao usuário um link como https://chat.openai.com/...&utm_source=blog2025, então no primeiro "app_opened" pode pegar essa tag do contexto e colocá-la no campo referral_source.

Ou seja, as métricas de acquisition ficam mais ou menos assim: “número de "app_opened" por dia”, “número de userId únicos que iniciaram o App por semana”, “distribuição por referral_source, se existir”.

4. Activation: encontrando o “momento aha” dentro do GiftGenius

Acquisition por si só não significa nada se as pessoas fecham o App logo em seguida. Por isso, a segunda camada-chave é Activation. É o momento em que o usuário percebe pela primeira vez que o App faz algo realmente útil.

Para o GiftGenius, esse momento faz sentido ser ligado à conclusão do workflow: o usuário informou dados sobre o presenteado, ajustou filtros, e o App mostrou, digamos, 10 ideias relevantes. É aí que o usuário vê valor pela primeira vez.

É conveniente fixar isso por meio do evento "workflow_completed". Esse passo é melhor ser logado no servidor MCP, quando você já reuniu todos os presentes e envia o resultado ao widget:

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

Aqui, logger é seu logger estruturado, que você já adicionou para SLO e instrumentação de custos. Nós apenas acrescentamos nele um evento de produto.

É exatamente por "workflow_completed" que você vai calcular a taxa de ativação (activation‑rate): activation_rate = (número de userId únicos com pelo menos um "workflow_completed") / (número de userId únicos com "app_opened" no período).

Você também pode olhar de forma mais grosseira: “a parcela de sessões sessionId nas quais houve "workflow_completed"”. O importante é que seja uma métrica familiar: quanto maior a activation, melhor o arranque do App.

5. Retention: os usuários retornam ao seu App?

Retention para um ChatGPT App é um pouco mais complexo do que para um produto web tradicional. Por um lado, o próprio ChatGPT é um lugar ao qual a pessoa já retorna. Por outro, ela pode voltar a vários outros Apps, e não ao seu. Precisamos entender se ela volta ao GiftGenius.

Com autenticação (módulo 10), você tem um userId ou tenantId estável. Nesse caso, a definição clássica é simples: o usuário é considerado “retido” (retained) se, por exemplo, 7 dias após o primeiro "workflow_completed" ele tiver um novo "workflow_completed" ou ao menos um "app_opened".

Se não houver auth, você pode usar uma métrica mais fraca com base em sessionId e chaves heurísticas userKey (por exemplo, um hash da conta OpenAI, se estiver disponível em _meta), mas nesta aula vamos assumir que temos userId.

Em lógica parecida com SQL, isso é algo assim (pseudo‑código):

-- primeira ativação
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;

Você não precisa escrever esse SQL “bonito” em produção, mas é importante entender a ideia: retention é sobre se as pessoas voltam a usar o App, e não apenas se chegaram ao pagamento uma vez.

6. Revenue: conectando o funil ao dinheiro

A camada de Revenue para o GiftGenius reforça por que estamos fazendo tudo isso. No módulo de commerce, já adicionamos eventos em torno do pagamento: "checkout_started", "checkout_success", "checkout_failed". Esses mesmos eventos se tornam a chave para métricas de receita do produto: conversões e ticket médio.

No momento em que o usuário clica em “Comprar presente” e você cria a sessão de checkout (via ACP/Stripe), no lado MCP vale logar o evento:

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

Quando chega o webhook de sucesso do PSP:

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

Agora você pode calcular facilmente a conversão:

• “de "workflow_completed" para "checkout_started"” — com que frequência as pessoas de fato vão ao pagamento;
• “de "checkout_started" para "checkout_success"” — quão bem funciona seu fluxo de commerce (erros de cartão, fraude, UX do pagamento).

E, ao mesmo tempo, esses mesmos eventos se unem aos logs de custo da aula anterior sobre controle de gastos e instrumentação de custos: por requestId ou sessionId você sabe quais chamadas de ferramentas e quantos tokens/dinheiro custaram o caminho até essa compra. Isso dá métricas como “médio cost_per_paid_workflow” e “receita menos custo por um pedido bem-sucedido”.

7. Referral: quando usuários trazem outros

A camada de Referral em um ChatGPT App é um pouco incomum. Você não tem seus próprios push nem mailings, mas os usuários podem compartilhar chats, links e simplesmente dizer uns aos outros “procura GiftGenius na Store”.

Tecnicamente, você pode introduzir eventos "referral_sent" e "referral_activated" se:

• der aos usuários um código de indicação ou parâmetro no link do App (?ref=friend123),
• ou processar referral_source/campaign no contexto de "app_opened".

No MVP básico do GiftGenius, você pode deixar Referral para depois — primeiro é importante estruturar Acquisition/Activation/Revenue e garantir que o núcleo do funil funcione. Mas é importante entender onde “acoplar”: nos mesmos logs de eventos e métricas, e não em um Excel separado com cupons.

Funil visual do GiftGenius

Para manter a visão clara, é útil desenhar um pequeno diagrama:

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

Cada aresta aqui é uma conversão que pode ser medida. Marketing, mudanças de UX, experimentos com modelos — tudo no fim deve elevar uma ou mais dessas conversões. Se você faz algo e não consegue dizer qual aresta exatamente deve melhorar, isso é suspeito.

Dashboards de crescimento: relatórios que você precisa primeiro

Vamos imaginar um dashboard mínimo de crescimento para o GiftGenius. Não vamos construir aqui um sistema de BI espacial — queremos pelo menos uma tabela para olhar toda semana.

Exemplo de relatório agregado por dia:

Dá para ver na hora que no dia 3 “turbinamos” acquisition (subiu "app_opened"), mas activation e a conversão caíram — talvez tenha vindo o tráfego errado ou você quebrou algo no UX. Tabelas assim ajudam a separar marketing bom de apenas barulhento.

Além da série temporal, é útil olhar para coortes: usuários que chegaram em uma semana específica e sua retention em 7/30 dias. Mas, para começar, basta aprender a construir cortes simples por dias e semanas.

8. Marketing como uma série de experimentos sobre eventos

Agora vamos ao ponto mais “de marketing”: como ligar atividades externas (artigos, listagem na Store, parcerias) ao que vemos nos eventos do App.

Princípio-chave: qualquer ideia de marketing se formula como uma hipótese sobre quais métricas de produto devem mudar.

Por exemplo, para o GiftGenius:

• “Se melhorarmos a listagem na Store (ícones, descrição, vídeo demo), deve crescer a quantidade de "app_opened" de novos usuários e, de preferência, a taxa de ativação entre eles.”
• “Se escrevermos um artigo sobre escolher presentes para o Ano‑Novo e colocarmos um link para o GiftGenius, nos próximos 3 dias devem crescer "app_opened" com referral_source = "blog_ny2025" e depois "workflow_completed" nessa coorte.”

Tecnicamente, isso costuma ser implementado via um campo adicional campaign ou referral_source no evento "app_opened". Por exemplo, se na inicialização do App você obteve do contexto do ChatGPT alguma tag:

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

Agora você pode construir relatórios “por campanha”: quantos "app_opened" e "workflow_completed" para quem veio com referral_source = "blog_ny2025", e como isso difere do orgânico.

Importante: não consideramos marketing bem-sucedido apenas por “alcances” que alguém desenhou em outro lugar. Se o influenciador diz que o vídeo teve um milhão de views, ótimo — mas para o GiftGenius sucesso é “crescer "app_opened" e "workflow_completed" dentro do nosso App”.

9. Exemplo: experimento de marketing para o GiftGenius

Vamos juntar tudo em um cenário concreto e, ao mesmo tempo, amarrar com cuidado a campanha externa aos eventos de produto dentro do GiftGenius.

Suponha que você queira testar a hipótese: um artigo em um blog popular de presentes trará usuários “certos”. No artigo, você dá um link não diretamente para o ChatGPT, mas para sua landing page, por exemplo:

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

O usuário cai em uma landing page curta com a descrição do GiftGenius e um botão “Abrir no ChatGPT”. No backend da landing, você lê utm_source e salva no perfil do usuário (ou em uma tabela separada), por exemplo, como acquisitionSource = "giftblog2025". O botão na landing então leva ao seu ChatGPT App na Store; o usuário conecta o App e começa a usá-lo.

Quando esse usuário inicia o GiftGenius no ChatGPT e seu backend recebe a primeira chamada do Apps SDK / MCP, você recupera o acquisitionSource salvo e o adiciona aos eventos de produto. Para "app_opened", isso pode ficar assim:

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

Da mesma forma, você marca os eventos "workflow_completed", "checkout_started", "checkout_success". Depois, o experimento se resume a comparar coortes: usuários com referral_source = "giftblog2025" contra orgânico. Se a coorte “do blog” tiver maior parcela de cenários concluídos e pagamentos com receita por usuário comparável ou melhor, a campanha pode ser considerada bem-sucedida; se só crescem as aberturas do app e a conversão em "workflow_completed" e "checkout_success" cai, então o artigo traz principalmente curiosos, não compradores.

Esse approach é bom porque você traduz com cuidado, uma única vez, o parâmetro UTM do mundo da web para seu campo interno referral_source e depois trabalha apenas com a analytics de produto do App — sem mágica e sem tentar empurrar parâmetros de URL diretamente para dentro do ChatGPT.

Ao mesmo tempo, você pode olhar o custo, se em algum lugar registra o CAC (quanto custou a ação) e o cost_per_task. A hipótese vira um experimento mais “financeiro”: “Esse canal se paga?”.

10. Analytics privacy‑first: sem quebrar a política nem o bom senso

Um ponto especialmente importante é como não virar um pouco o Facebook. Diferente da web clássica, a OpenAI leva a sério a privacidade em ChatGPT Apps: não se pode rastrear dados pessoais, coletar PII desnecessária nem enviar o texto completo dos diálogos para qualquer lugar.

Boas práticas para a analytics do GiftGenius:

1. Não armazenar o texto “cru” das mensagens do usuário nos eventos. Em vez disso, logar apenas “fatos do cenário”: tipo de cenário, quantidade de ideias mostradas, fato de pagamento bem-sucedido.
2. Se for preciso diferenciar usuários, usar identificadores pseudonimizados (userId, tenantId), e não email/nome. Qualquer PII fica no banco com autenticação; a analytics opera com chaves anonimizadas.
3. Em logs e eventos, evitar campos que possam identificar diretamente a pessoa, se não forem necessários para o funcionamento (por exemplo, endereço completo de entrega no evento claramente não é necessário; o lugar dele é no banco protegido de commerce).
4. Usar ao máximo analytics agregada: interessam a taxa de ativação e a retenção por centenas de usuários, não os indivíduos nominalmente.

E não esqueça que já tivemos um módulo sobre audit & lifecycle: se o usuário pedir para apagar seus dados, a lógica de retenção deve levar isso em conta. Mas isso é mais assunto do módulo 15; aqui, o importante é lembrar que analytics não dá carta branca para coletar qualquer lixo.

11. Conexão com instrumentação de custos e SLO: marketing que mede tudo

Tecnicamente, o cenário ideal é: você tem um fluxo único de eventos estruturados, em que a cada sessão de usuário estão associados:

• eventos de produto ("app_opened", "workflow_completed", "checkout_success");
• dados de custo (tokens, cost_estimate, duration_ms por ferramenta);
• métricas de SLO (latência e erros de MCP/ferramentas, disponibilidade).

Assim, quaisquer decisões de marketing e produto se tornam verdadeiramente orientadas por dados quase automaticamente. Você pode perguntar:

• “Qual é o activation_rate dos usuários da campanha X e quanto custa, em média, o workflow bem-sucedido deles?”
• “O error_rate ou a latência p95 não está subindo com o aumento do tráfego vindo da Store?”
• “Se barateamos o modelo no experimento ‘custo ↔ qualidade’ da aula anterior, a conversão em "checkout_success" não caiu e a revenue por usuário não diminuiu?”

E tudo isso sem inventar novos sistemas — você apenas usa os mesmos logs e instrumentos de custo que implementou antes.

No fim, marketing de ChatGPT App não é sobre tráfego por si só, e sim sobre melhorar métricas concretas de produto dentro do seu aplicativo. Logue as etapas-chave do cenário ("app_opened", "workflow_completed", "checkout_success"), conecte-as à instrumentação de custos e SLO e formule atividades de marketing como hipóteses sobre qual elo do funil você quer melhorar. Mantendo esse funil e as restrições de privacidade em mente, as decisões de produto e crescimento quase automaticamente se tornam mais sólidas e sustentáveis.

12. Erros comuns ao trabalhar com métricas de produto e marketing

Erro nº 1: marketing por tráfego, não por ativação.
Com frequência, as equipes comemoram um pico de "app_opened" após algum artigo ou tweet e consideram o experimento bem-sucedido sem olhar activation e conversão. No fim, recebem um monte de “turistas”, que aumentam carga e custo, mas não trazem dinheiro nem viram usuários reais. A abordagem correta é sempre olhar o funil além do primeiro passo: quantos dos que chegaram chegaram a "workflow_completed" e "checkout_success".

Erro nº 2: ausência de um identificador único de usuário.
Às vezes o App começa a logar eventos, mas sem um userId estável ou ao menos tenantId. Nesse modo, você só consegue contar algo como “quantidade de eventos por dia”, mas não retention nem cost_per_user. Adicionar depois um tracking de usuário correto pode ser difícil, especialmente se já houver fortes restrições de privacidade. É melhor pensar no esquema de identificação ainda na etapa de autenticação (módulo 10) e usá-lo em todos os eventos.

Erro nº 3: rastrear “cada espirro” em vez de eventos-chave.
A primeira reação à analytics de eventos é começar a logar absolutamente tudo: hover do mouse, cada foco de input, cada rerender. No contexto do ChatGPT, isso é especialmente ruim: tais eventos não se encaixam bem no modelo de uso, criam toneladas de ruído e aumentam riscos de privacidade. Muito mais útil é limitar-se a alguns eventos-chave do cenário e analisá-los com qualidade.

Erro nº 4: campanhas de marketing sem atribuição.
Um padrão comum: a equipe lança uma campanha (artigo, vídeo, parceria), mas não marca o tráfego de entrada e depois fica na dúvida “funcionou ou não”. Como resultado, todas as mudanças nas métricas ficam diluídas. Muito melhor é usar campos explícitos referral_source ou campaign nos eventos "app_opened", mesmo que via parâmetros simples do tipo UTM, e então comparar essas coortes com o orgânico.

Erro nº 5: ignorar as restrições de privacidade em nome da “analytics completa”.
Às vezes, na ânsia por detalhes, começam a escrever nos eventos o texto das solicitações, dados pessoais do presenteado, endereços e outras PII. Isso é perigoso em duas frentes: do ponto de vista das políticas da OpenAI/Store e do risco jurídico real (GDPR, CCPA etc.). A analytics correta se baseia em sinais agregados do cenário e identificadores anônimos, e não em guardar a conversa toda “por via das dúvidas”.

Erro nº 6: otimizar só por custo, ignorando qualidade e crescimento.
Depois do módulo sobre custos, é fácil cair no “modo economia”, tentando reduzir tokens a qualquer preço. Se, com isso, caem a taxa de ativação, a retenção e "checkout_success", a economia é ilusória: você está matando o valor do produto. Tenha sempre em mente o triângulo “custo ↔ qualidade ↔ crescimento”: quaisquer mudanças em prompts, modelos e UX devem ser vistas sob a ótica tanto do custo quanto das métricas de produto.

1

Tarefa

ChatGPT Apps, nível 19, lição 2

Bloqueado

Analytics de produto mínima: /api/analytics + página de demonstração

Analytics de produto mínima: /api/analytics + página de demonstração

Abrir