Marketing e crescita guidati dalle metriche di prodotto

1. Perché il marketing di ChatGPT App è analytics di prodotto, non “rumore”

Nel web classico puoi installare Google Analytics, aggiungere tag UTM a tutti i link, mettere un paio di pixel di retargeting — e cavartela. Nell’ecosistema ChatGPT è diverso. L’utente sta nell’interfaccia di ChatGPT e la tua App è un “ospite” in quel dialogo. Cookie, iframe e Facebook Pixel qui non sono i benvenuti.

Questo rende automaticamente gli eventi di prodotto la fonte principale (e spesso unica) di verità sulla crescita. Con quale frequenza aprono l’App? Arrivano allo scenario chiave? Ritornano? Come si collega tutto ciò al ricavo? A tutte queste domande rispondono non contatori esterni, ma i tuoi eventi MCP e l’analitica server‑side.

Qui emerge in modo molto logico il termine product‑led growth (PLG): la crescita non deriva da quanti banner hai comprato, ma da quanto bene il prodotto risolve lo scenario dell’utente e da come lo evolvi basandoti sui dati.

Perciò il protagonista di questa lezione è il funnel di eventi dentro GiftGenius, non il canale di marketing esterno. I canali ci saranno, ma solo come ipotesi che influenzano questi eventi.

AARRR per GiftGenius: il nostro funnel “pirata”

Il modello AARRR (Acquisition, Activation, Retention, Revenue, Referral) si adatta perfettamente a una ChatGPT App: bisogna solo tradurlo nel linguaggio degli eventi della nostra applicazione.

Per GiftGenius lo possiamo descrivere così:

app_opened

workflow_completed (first time)

repeated workflow_completed / app_opened

checkout_started, checkout_success

referral_sent, referral_activated (opzionale)

È importante che questo funnel sia descritto non da “click di frontend”, ma da veri eventi di utilizzo a livello MCP/App: l’utente ha aperto, ha completato lo scenario, ha acquistato, è tornato. A differenza del web, dove a volte tracci “ogni movimento del mouse”, qui l’analitica deve essere compatta e significativa: meno “dove ha cliccato”, più “che cosa ha fatto nello scenario”.

Per la versione base di GiftGenius ci focalizziamo principalmente sui primi quattro livelli (Acquisition, Activation, Retention, Revenue). Il Referral resta importante, ma come fase successiva, da abilitare quando il core del prodotto e dei pagamenti sarà stabilizzato.

2. Progettare il modello di eventi: dai log all’analitica

Nel modulo sull’observability abbiamo già concordato di scrivere log JSON strutturati, non “romanzi di log” in forma libera. Ora costruiamo sopra di essi un modello di eventi di prodotto.

Idea minima: ogni passo importante nell’App genera un oggetto evento. Lato MCP lo puoi sia loggare sia inviare a un sistema analitico esterno (BI, ClickHouse, BigQuery — ciò che preferisci).

Una definizione semplicissima degli eventi per GiftGenius può essere così:

// Forma generale dell'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;          // dall'auth, se presente
  sessionId: string;        // UUID della sessione in ChatGPT
  timestamp: string;        // stringa ISO
  properties?: Record<string, unknown>;
}

Separatamente è comodo avere un piccolo helper per inviare eventi dalla parte Next.js dell’applicazione:

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

Sul server /api/analytics puoi già decidere cosa farne: salvare in un database, inviare a un logger o fare streaming in un data‑pipeline. La cosa principale è che tutti gli eventi siano in un formato unico. In pratica avrai lo stesso set di eventi di prodotto, ma più punti di generazione: alcune fasi è più comodo fissarle direttamente sul server MCP tramite logger.info, altre inviarle dal widget come AnalyticsEvent a /api/analytics. Non conta quante “tubazioni” tecniche hai, ma che i tipi di eventi ("app_opened", "workflow_completed" ecc.) e i loro campi restino univoci e coerenti.

3. Acquisition: come capire da dove arrivano gli utenti

Il primo compito del marketing è rispondere a chi arriva e quanti sono. Nella ChatGPT App questo “arrivo” è l’avvio dell’App in chat. Ciò che vogliamo loggare si chiama "app_opened".

Per GiftGenius lo si può fare sia lato widget (reagendo al mount del componente), sia lato server (per esempio alla prima callTool nella sessione). È più affidabile lato server, per non dipendere dalle particolarità del rendering, ma per semplicità vediamo il front.

Esempio di componente widget GiftGenius con chiamata a trackEvent al primo 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 principale del widget... */}
    </main>
  );
}

In pratica vorrai ottenere sessionId e userId dal contesto esistente (per esempio da _meta o dal token di autorizzazione), non generarli sul client. Ma il punto è che ogni avvio di GiftGenius deve generare tale evento.

Il problema delle sorgenti di traffico è più ostico che sul web: referrer e tag UTM sono limitati. Di solito si usano due strategie. La prima: considerare lo Store come fonte principale di traffico e analizzare solo "app_opened" nel tempo; se pubblichi un nuovo listing nello Store, guarda il picco di "app_opened" e i livelli successivi del funnel. La seconda: usare parametri espliciti; se offri all’utente un link del tipo https://chat.openai.com/...&utm_source=blog2025, al primo "app_opened" puoi prendere questo tag dal contesto e salvarlo nel campo referral_source.

Quindi le metriche di acquisition sono più o meno: “numero di "app_opened" al giorno”, “numero di userId unici che hanno avviato l’App nella settimana”, “distribuzione per referral_source, se presente”.

4. Activation: trovare l’“aha‑moment” dentro GiftGenius

L’acquisition da sola non significa nulla se le persone chiudono subito l’App. Il secondo livello chiave è l’Activation. È il momento in cui l’utente sente per la prima volta che l’App fa qualcosa di realmente utile.

Per GiftGenius ha senso legarlo al completamento del workflow: l’utente inserisce le informazioni sul destinatario, imposta i filtri e l’App gli mostra, poniamo, 10 idee pertinenti. È lì che l’utente vede per la prima volta il valore.

Conviene fissarlo con l’evento "workflow_completed". Meglio loggare questo passo sul server MCP, quando hai già raccolto i regali e invii il risultato al widget:

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

Qui logger è il tuo logger strutturato, che hai già aggiunto per SLO e strumentazione dei costi. Abbiamo semplicemente aggiunto un evento di prodotto.

Proprio su "workflow_completed" calcolerai la activation‑rate: activation_rate = (numero di userId unici con almeno un "workflow_completed") / (numero di userId unici con "app_opened" nel periodo).

Puoi anche guardare in modo più grezzo: “quota di sessioni sessionId in cui si è verificato "workflow_completed"”. È importante che sia una metrica a te familiare: più alta è l’activation, migliore è la partenza dell’App.

5. Retention: gli utenti tornano alla tua App?

La retention per una ChatGPT App è un po’ più complessa che per un prodotto web classico. Da un lato, ChatGPT è un posto dove l’utente torna comunque. Dall’altro, può tornare a molte altre App, non alla tua. A noi interessa capire se torna a GiftGenius.

Con autenticazione (modulo 10) hai uno userId o un tenantId stabile. In tal caso, la definizione classica è semplice: un utente è considerato “retained” se, per esempio, dopo 7 giorni dal primo "workflow_completed" ha un nuovo "workflow_completed" o almeno un "app_opened".

Se non c’è auth, puoi usare una metrica più debole basata su sessionId e userKey euristici (per esempio un hash dell’account OpenAI, se disponibile in _meta), ma in questa lezione supponiamo di avere lo userId.

In forma di logica simile a SQL si presenta così (pseudo‑codice):

-- prima attivazione
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;

Non è necessario scrivere “bellezze” SQL così in produzione, ma è importante capire l’idea: la retention riguarda il fatto che le persone tornano a usare l’App, non solo se sono arrivate una volta al pagamento.

6. Revenue: collegare il funnel al denaro

Lo strato Revenue per GiftGenius ribadisce perché facciamo tutto questo. Nel modulo sul commerce abbiamo già aggiunto gli eventi attorno al pagamento: "checkout_started", "checkout_success", "checkout_failed". Gli stessi eventi diventano la chiave per le metriche di ricavo di prodotto: conversione e scontrino medio.

Nel momento in cui l’utente preme “Compra regalo” e crei una sessione di checkout (tramite ACP/Stripe), lato MCP conviene loggare l’evento:

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

Quando arriva il webhook di successo dal PSP:

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

Ora puoi facilmente calcolare la conversione:

• “da "workflow_completed" a "checkout_started"” — quanto spesso le persone vanno effettivamente al pagamento;
• “da "checkout_started" a "checkout_success"” — quanto bene funziona il tuo flusso di commerce (errori carta, frode, UX del pagamento).

E contemporaneamente questi stessi eventi si uniscono ai log dei costi della lezione precedente su controllo dei costi e strumentazione: tramite requestId o sessionId sai quali chiamate agli strumenti e quanti token/denaro sono costati fino a quell’acquisto. Questo fornisce metriche come “cost_per_paid_workflow medio” e “ricavo meno costo unitario per un ordine riuscito”.

7. Referral: quando gli utenti portano altri utenti

Lo strato Referral in una ChatGPT App è un po’ insolito. Non hai push o newsletter tuoi, ma gli utenti possono condividere chat, link e semplicemente dirsi a vicenda “cerca GiftGenius nello Store”.

Tecnicamente puoi introdurre gli eventi "referral_sent" e "referral_activated", se:

• fornisci agli utenti un codice referral o un parametro nel link all’App (?ref=friend123),
• oppure gestisci referral_source/campaign nel contesto di "app_opened".

Nella versione MVP di base di GiftGenius, il Referral può essere lasciato per il futuro: prima è importante costruire Acquisition/Activation/Revenue e assicurarsi che il core del funnel funzioni. È comunque importante capire dove “agganciarlo”: agli stessi log di eventi e metriche, non a un Excel separato con codici promo.

Funnel visivo di GiftGenius

Per mantenere chiara la visione d’insieme, è utile disegnare un piccolo diagramma:

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

Ogni arco qui è una conversione misurabile. Marketing, cambi UX, esperimenti con i modelli — tutto alla fine dovrebbe aumentare uno o più di questi tassi di conversione. Se fai qualcosa e non sai dire quale arco dovrebbe migliorare, c’è da insospettirsi.

Dashboard di crescita: quali report servono per iniziare

Immaginiamo una dashboard minima di crescita per GiftGenius. Non costruiamo un sistema BI spaziale, ma vogliamo almeno una tabella da guardare ogni settimana.

Esempio di report aggregato per giorno:

Si vede subito che il giorno 3 abbiamo spinto l’acquisition (sono cresciuti gli "app_opened"), ma activation e conversione sono calate — forse è arrivato traffico non in target o hai rotto qualcosa nell’UX. Proprio tabelle così aiutano a distinguere un buon marketing da uno solo “rumoroso”.

Oltre all’analisi nel tempo, è utile guardare le coorti: utenti arrivati in una certa settimana e la loro retention dopo 7/30 giorni. Ma per iniziare basta saper costruire semplici viste per giorni e settimane.

8. Marketing come serie di esperimenti sugli eventi

Ora passiamo al momento più “di marketing”: come collegare le attività esterne (articoli, listing nello Store, partnership) a ciò che vediamo negli eventi dell’App.

Principio chiave: qualunque idea di marketing si formula come ipotesi su quali metriche di prodotto debbano cambiare.

Per esempio, per GiftGenius:

• “Se miglioriamo il listing nello Store (icone, descrizione, video demo), dovrebbe crescere il numero di "app_opened" dai nuovi utenti e, idealmente, anche l’activation‑rate tra loro”.
• “Se scriviamo un articolo sulla scelta dei regali per Capodanno e ci mettiamo il link a GiftGenius, nei 3 giorni successivi dovrebbero crescere gli "app_opened" con referral_source = "blog_ny2025" e poi i "workflow_completed" in quella coorte”.

Tecnicamente spesso si implementa con un campo aggiuntivo campaign o referral_source nell’evento "app_opened". Per esempio, se all’inizializzazione dell’App ricevi dal contesto di ChatGPT un certo tag:

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

Ora puoi costruire report “per campagna”: quanti "app_opened" e "workflow_completed" tra coloro che sono arrivati con referral_source = "blog_ny2025", e come differiscono dall’organico.

È importante che non consideriamo il marketing di successo solo per gli “impressions” mostrati altrove. Se un creator dice che il suo video ha avuto un milione di visualizzazioni, ottimo, ma per GiftGenius il successo è “crescita di "app_opened" e "workflow_completed" da noi, dentro l’App”.

9. Esempio: esperimento di marketing per GiftGenius

Mettiamo tutto insieme in uno scenario concreto e colleghiamo con cura una campagna esterna agli eventi di prodotto dentro GiftGenius.

Immagina di voler testare l’ipotesi: un articolo in un blog popolare sui regali porterà utenti “giusti”. Nell’articolo dai un link non direttamente a ChatGPT, ma al tuo landing, per esempio:

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

L’utente arriva su un breve landing con descrizione di GiftGenius e un bottone “Apri in ChatGPT”. Sul backend del landing leggi utm_source e lo salvi nel profilo utente (o in una tabella separata), ad esempio come acquisitionSource = "giftblog2025". Il bottone sul landing porta al tuo ChatGPT App nello Store; poi l’utente collega l’App e inizia a usarla.

Quando questo utente avvia GiftGenius in ChatGPT e il tuo backend riceve la prima chiamata da Apps SDK / MCP, recuperi il acquisitionSource salvato e lo aggiungi agli eventi di prodotto. Per "app_opened" può essere così:

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

Allo stesso modo etichetti gli eventi "workflow_completed", "checkout_started", "checkout_success". Poi l’esperimento si riduce al confronto tra coorti: utenti con referral_source = "giftblog2025" contro organico. Se la coorte “blog” ha una quota più alta di scenari completati e pagamenti, con ricavo per utente comparabile o migliore, la campagna si può considerare riuscita; se crescono solo gli avvii dell’applicazione ma la conversione in "workflow_completed" e "checkout_success" cala, l’articolo porta soprattutto curiosi, non acquirenti.

Questo approccio è valido perché traduci una volta con cura il parametro UTM dal mondo web nel tuo campo interno referral_source e poi lavori solo con l’analitica di prodotto dell’App — senza magie e senza cercare di far passare parametri URL direttamente dentro ChatGPT.

Nel frattempo puoi guardare anche al costo unitario, se da qualche parte fissi il CAC (quanto è costato il placement) e il cost_per_task. Allora l’ipotesi diventa un esperimento più “finanziario”: “Questo canale si ripaga?”.

10. Analitica privacy‑first: non violare policy e buon senso

Un punto importante a parte — come non diventare un po’ come Facebook. A differenza del web classico, OpenAI è piuttosto rigida sulla privacy nelle ChatGPT Apps: non si possono tracciare dati personali, raccogliere PII superflua e inviare il testo completo dei dialoghi in giro.

Le buone pratiche per l’analitica di GiftGenius sono:

1. Non memorizzare negli eventi il testo grezzo dei messaggi dell’utente. Loggare invece solo “fatti dello scenario”: tipo di scenario, numero di idee mostrate, esito positivo del pagamento.
2. Se serve distinguere gli utenti, usare identificatori pseudonimizzati (userId, tenantId), non email/nome. Qualsiasi PII si conserva nel database con autenticazione; l’analitica opera con chiavi anonimizzate.
3. Evitare nei log e negli eventi campi che possano identificare direttamente una persona se non servono al funzionamento (per esempio, l’indirizzo completo di spedizione non serve in un evento; il suo posto è nel database protetto del commerce).
4. Usare il più possibile analitica aggregata: ti interessano activation‑rate e retention su centinaia di utenti, non i singoli per nome e cognome.

E non dimentichiamo che abbiamo già avuto un modulo su audit & lifecycle: se un utente chiede di cancellare i suoi dati, la logica di retention deve tenerne conto. Ma questo è più materia del modulo 15; qui è sufficiente ricordare che l’analitica non dà un’“indulgenza” per raccogliere qualsiasi cosa.

11. Connessione con strumentazione dei costi e SLO: un marketing che misura tutto

Dal punto di vista tecnico, il quadro ideale è questo: hai un flusso unico di eventi strutturati, in cui a ogni sessione utente sono associati:

• eventi di prodotto ("app_opened", "workflow_completed", "checkout_success");
• dati di costo (token, cost_estimate, duration_ms per gli strumenti);
• metriche SLO (latenza ed errori di MCP/strumenti, disponibilità).

Così qualsiasi decisione di marketing e prodotto diventa realmente data‑driven quasi automaticamente. Puoi chiederti:

• “Qual è l’activation_rate degli utenti della campagna X e quanto costa in media il loro workflow riuscito?”
• “Non sta crescendo l’error_rate o la p95 latency man mano che aumenta il traffico dallo Store?”
• “Se abbiamo reso più economico il modello nell’esperimento ‘costo ↔ qualità’ della lezione precedente, la conversione in "checkout_success" è calata? Il revenue per utente è diminuito?”

E tutto questo senza inventare nuovi sistemi — usi gli stessi log e la stessa strumentazione dei costi che hai già introdotto.

In sintesi, il marketing di una ChatGPT App non riguarda il traffico in sé, ma il miglioramento di metriche di prodotto concrete dentro la tua applicazione. Logga i passi chiave dello scenario ("app_opened", "workflow_completed", "checkout_success"), collegali alla strumentazione dei costi e agli SLO e formula le attività di marketing come ipotesi su quale anello del funnel vuoi migliorare. Se tieni a mente questo funnel e i vincoli di privacy, le decisioni di prodotto e di crescita diventano quasi automaticamente più sensate e sostenibili.

12. Errori tipici nel lavoro con metriche di prodotto e marketing

Errore n. 1: marketing per il traffico, non per l’attivazione.
Spesso i team si rallegrano per una crescita improvvisa degli "app_opened" dopo un articolo o un tweet e considerano l’esperimento riuscito senza guardare activation e conversione. Finiscono per ottenere un sacco di “turisti” che aumentano il carico e i costi, ma non portano denaro e non diventano utenti reali. L’approccio giusto è guardare sempre oltre il primo passo del funnel: quanti arrivati sono giunti a "workflow_completed" e "checkout_success".

Errore n. 2: assenza di un identificatore utente univoco.
A volte l’App inizia a loggare eventi senza uno userId stabile o almeno un tenantId. In questa modalità puoi calcolare solo qualcosa come “conteggio degli eventi al giorno”, ma non la retention e nemmeno il cost_per_user. Aggiungere in seguito un tracciamento utente corretto può essere difficile, soprattutto con vincoli stringenti di privacy. È meglio progettare lo schema di identificazione già in fase di autenticazione (modulo 10) e usarlo in tutti gli eventi.

Errore n. 3: tracciare “ogni starnuto” invece degli eventi chiave.
La prima reazione all’analytics degli eventi è loggare tutto: hover del mouse, ogni focus su un input, ogni rerender. Nel contesto ChatGPT è particolarmente dannoso: tali eventi si adattano male al modello d’uso, creano tonnellate di rumore e aumentano i rischi di privacy. È molto più utile limitarsi a pochi eventi chiave dello scenario e analizzarli bene.

Errore n. 4: campagne di marketing senza attribuzione.
Schema comune: il team lancia una campagna (articolo, video, partnership) ma non etichetta il traffico in ingresso e poi si chiede “ha funzionato o no?”. Di conseguenza, tutte le variazioni nelle metriche si confondono. È molto meglio usare campi espliciti referral_source o campaign negli eventi "app_opened", anche tramite semplici parametri in stile UTM, e quindi confrontare queste coorti con l’organico.

Errore n. 5: ignorare i vincoli di privacy per una “analitica completa”.
Talvolta, inseguendo i dettagli, si inizia a scrivere negli eventi il testo delle richieste, i dati personali del destinatario del regalo, indirizzi e altra PII. È pericoloso su due piani: per le policy di OpenAI/Store e per il rischio legale reale (GDPR, CCPA, ecc.). L’analitica corretta si basa su segnali aggregati dello scenario e identificatori anonimi, non sulla conservazione dell’intera conversazione “per ogni evenienza”.

Errore n. 6: ottimizzare solo per i costi, senza considerare qualità e crescita.
Dopo il modulo sui costi è facile scivolare in una modalità “risparmio estremo”, cercando di ridurre i token a ogni costo. Se nel frattempo calano activation‑rate, retention e "checkout_success", il risparmio è illusorio: stai semplicemente uccidendo il valore del prodotto. Tieni sempre a mente il triangolo “costo ↔ qualità ↔ crescita”: qualunque cambiamento in prompt, modelli e UX va valutato sia in termini di costo sia in termini di metriche di prodotto.