Conjoint Analysis: il Simulatore di Mercato nel Tuo Laptop
Nel 1985, Green e Srinivasan — i due ricercatori di Wharton che hanno praticamente inventato la conjoint analysis moderna — hanno pubblicato un caso che avrebbe cambiato il modo in cui le aziende di beni di consumo prendono decisioni di prodotto. Procter & Gamble aveva investito milioni di dollari nello sviluppo di un detersivo con formula antimacchia avanzata. Tutti i focus group interni dicevano che era ottimo. Il test di mercato fu un disastro. Perche’? Perche’ i consumatori nelle sessioni di focus group dicevano di voler pagare di piu’ per una formula migliore — ma quando si trovavano davanti allo scaffale del supermercato, prendevano il piu’ economico.
La conjoint analysis risolve esattamente questo problema: invece di chiedere alle persone cosa vogliono (le risposte sono quasi sempre distorte verso cio’ che suona bene o cio’ che l’intervistatore sembra aspettarsi), le metti nella situazione di dover scegliere tra opzioni realistiche con trade-off espliciti. Le scelte rivelano le preferenze reali, non quelle dichiarate.
E’ un metodo robusto, usato da Apple per testare varianti di iPhone prima del lancio, da Airbnb per ottimizzare la struttura dei prezzi degli host, da Spotify per decidere quali feature includere nei piani premium. E’ anche un metodo accessibile: con un foglio di calcolo e Python, puoi eseguire uno studio conjoint serio con un budget di ricerca ragionevole. In questo articolo, scoprirai i tipi di conjoint analysis, come implementarli e come usarli per decisioni concrete di pricing e feature.
L’Intuizione Fondamentale: Trade-Off, non Valutazioni Astratte
Il problema con le domande di ricerca di mercato classiche e’ che non costringono le persone a fare trade-off. Se chiedi “quanto e’ importante per te avere un’ottima fotocamera sullo smartphone?” risponderanno “molto importante”. Se chiedi anche “quanto e’ importante il prezzo?” risponderanno “molto importante”. Se chiedi “quanto e’ importante la batteria?” risponderanno “molto importante”. Tutto e’ importante. La risposta e’ inutile perche’ non riflette nessuna scelta reale.
Nella vita reale, ogni scelta d’acquisto e’ un trade-off: accetti un prezzo piu’ alto in cambio di una feature migliore, o preferisci risparmiare e accontentarti. La conjoint analysis mima questo processo. Mostri ai rispondenti serie di opzioni con combinazioni diverse di attributi e chiedi di scegliere. Le scelte aggregate rivelano quanta importanza le persone danno realmente a ciascun attributo — implicitamente, attraverso le loro preferenze, non esplicitamente attraverso le loro dichiarazioni.
Immagina di dover scegliere un nuovo smartphone tra queste tre opzioni:
| Opzione | Marca | Batteria | Fotocamera | Prezzo |
|---|---|---|---|---|
| A | Samsung | 24 ore | 108 MP | 899 euro |
| B | Apple | 18 ore | 48 MP | 1.199 euro |
| C | Xiaomi | 36 ore | 200 MP | 499 euro |
Se scegli C, stai implicitamente dicendo che la batteria da 36 ore e il risparmio di 400-700 euro valgono piu’ del brand Apple o dell’ecosistema Samsung. Se scegli B, stai dicendo che il brand e l’ecosistema Apple valgono un premium significativo rispetto a specifiche tecniche superiori. La tua scelta e’ informativa — comunica le tue vere preferenze ordinali senza che tu debba articolarle verbalmente.
I Tipi di Conjoint Analysis: quale Scegliere
Choice-Based Conjoint (CBC): lo Standard de Facto
Il CBC e’ la metodologia piu’ diffusa e la piu’ vicina alla realta’. Ogni schermata mostra 2-4 “profili” (configurazioni di prodotto) e il rispondente sceglie quella preferita. Si ripete per 8-12 schermate con combinazioni diverse. A volte si include un’opzione “nessuna delle precedenti” per simulare la possibilita’ di non acquistare.
Il CBC e’ lo standard de facto per due ragioni. Prima: simula la decisione d’acquisto reale, dove confronti alternative e scegli — non valuti ogni opzione in isolamento. Seconda: i dati prodotti si prestano a modelli di scelta discreta (Multinomial Logit, Mixed Logit) che permettono di stimare le preferenze a livello individuale e costruire simulatori di mercato.
Apple usa una variante del CBC per testare configurazioni di prodotto. Prima di lanciare l’iPhone 15, hanno condotto studi su migliaia di consumatori in diversi paesi per capire il valore attribuito a ogni combinazione di storage, colore, specifiche camera, e prezzo. Non per sapere cosa “piace” ai consumatori — ma per simulare il mix di modelli che massimizzerebbe il revenue totale del lancio.
MaxDiff (Best-Worst Scaling): Ideale per Tanti Attributi
Quando devi testare molti attributi (10-20 feature di un prodotto), il CBC diventa impraticabile — troppe combinazioni, troppo sovraccarico cognitivo. Il MaxDiff semplifica: ad ogni schermata, il rispondente vede 4-5 item e sceglie solo “il piu’ importante” e “il meno importante”. Si genera una scala ordinale molto piu’ affidabile del classico rating 1-10.
Qualtrics ha usato il MaxDiff per prioritizzare le feature della sua roadmap di prodotto. Con oltre 30 potenziali funzionalita’ da testare, un CBC tradizionale sarebbe stato ingestibile. Il MaxDiff su un campione di 400 clienti ha prodotto una graduatoria di importanza delle feature che ha guidato la pianificazione del prodotto per due anni.
Adaptive Conjoint (ACA): Personalizzato per Ogni Rispondente
L’ACA si adatta alle risposte di ogni individuo. Inizia con domande “grossolane” e poi si affina progressivamente basandosi sulle risposte precedenti. Produce utility stimate a livello individuale, molto utile quando hai segmenti di clienti con preferenze molto diverse. Il trade-off: servono meno task (10-15 invece di 15-20) ma la logica e’ piu’ complessa da spiegare.
Rating-Based Conjoint (Traditional): Meno Realistico, piu’ Semplice
Il metodo piu’ vecchio: il rispondente valuta ogni profilo singolarmente su una scala numerica. E’ meno realistico (nella realta’ confrontiamo, non valutiamo in isolamento) ma piu’ facile da spiegare e da implementare. Utile per studi esplorativi preliminari.
Come Progettare uno Studio Conjoint: dal Brief al Questionario
Step 1: Definisci gli Attributi e i Livelli
La scelta degli attributi e’ la decisione piu’ critica. Includi attributi troppo simili tra loro e il modello non li distinguera’. Includi troppi attributi e il rispondente andra’ in sovraccarico cognitivo e rispondera’ a caso.
Regole pratiche consolidate dalla letteratura (Green e Rao, 1971; Louviere e Woodworth, 1983):
- Massimo 5-6 attributi per study CBC standard
- 2-4 livelli per attributo (l’algoritmo di design sperimentale ne ha bisogno)
- I livelli devono essere credibili: non mettere “prezzo: 0 euro” — nessuno ci credera’
- Includi sempre il prezzo come attributo — e’ la variabile che produce le utility monetarie che servono per la willingness-to-pay
Esempio per un servizio SaaS di project management:
| Attributo | Livello 1 | Livello 2 | Livello 3 |
|---|---|---|---|
| Prezzo | 19 euro/mese | 49 euro/mese | 89 euro/mese |
| Numero utenti | 1-5 utenti | 6-25 utenti | Illimitati |
| Integrazioni | 5 app | 25 app | Illimitate |
| Supporto | Solo documentazione | Email entro 24h | Chat dedicata |
| Storage | 10 GB | 100 GB | Illimitato |
Step 2: il Design Sperimentale
Con 5 attributi x 3 livelli = 243 combinazioni possibili. Non puoi testarle tutte — sarebbe un questionario di ore. Usi un design ortogonale (o D-optimal) per selezionare un sottoinsieme di 12-20 profili che siano statisticamente rappresentativi dello spazio totale delle combinazioni.
Il principio dell’orthogonalita’: i livelli di ogni attributo sono distribuiti in modo che non ci siano correlazioni sistematiche tra attributi nel set di profili. Se prezzo e storage fossero sempre correlati (prezzo alto = storage alto), non potresti distinguere il contributo di ciascuno alle scelte.
from pyDOE2 import fullfact, fracfactimport pandas as pdimport numpy as np
# ---- Design sperimentale per studio CBC ----# 5 attributi, ognuno con 3 livelli (codificati 0, 1, 2)
# Design fattoriale completo: 3^5 = 243 combinazionidesign_completo = fullfact([3, 3, 3, 3, 3])print(f"Design completo: {len(design_completo)} profili")
# Per uno studio realistico, usiamo un sottoinsieme D-optimal# pyDOE2 non ha D-optimal nativamente, usiamo un approccio alternativo:# selezioniamo una frazione ortogonale
# Mappa dei livelli reali per ogni attributoattributi = { 'Prezzo': ['19 euro/mese', '49 euro/mese', '89 euro/mese'], 'Utenti': ['1-5', '6-25', 'Illimitati'], 'Integrazioni': ['5 app', '25 app', 'Illimitate'], 'Supporto': ['Docs', 'Email', 'Chat dedicata'], 'Storage': ['10 GB', '100 GB', 'Illimitato']}
# Selezione manuale di 18 profili ortogonali (esempio semplificato)# In produzione si usa software specializzato (Sawtooth, Lighthouse Studio)# o algoritmi D-optimal come in R (AlgDesign) o Python (pyOptimalDesign)indici_selezionati = np.random.choice(len(design_completo), size=18, replace=False)design_ridotto = design_completo[indici_selezionati]
# Converte indici numerici in livelli leggibilinomi_attributi = list(attributi.keys())df_profili = pd.DataFrame(design_ridotto, columns=nomi_attributi, dtype=int)
for attr, livelli in attributi.items(): df_profili[attr] = df_profili[attr].map({i: v for i, v in enumerate(livelli)})
print(f"\nDesign ridotto: {len(df_profili)} profili")print("\nPrimi 5 profili del questionario:")print(df_profili.head())Step 3: Raccolta delle Risposte
Ogni rispondente vede 8-12 “task” (schermate), ognuna con 3-4 profili da confrontare. Il campione minimo per un CBC affidabile e’ 200 rispondenti per risultati aggregati, 400+ se vuoi segmentare per sottogruppi. La qualita’ del campione importa piu’ della dimensione — devi intervistare le persone che effettivamente comprano nella tua categoria, non un campione random della popolazione.
Una cosa che molti trascurano: la selezione del campione e’ critica quanto il design dello studio. Se stai sviluppando un nuovo piano premium, non ha senso intervistare solo i clienti attuali del piano base — stai ottimizzando per chi gia’ compra da te, non per chi potresti acquisire. Includi nel campione anche i non-clienti che comprano da competitor.
Step 4: Analisi con Modello di Scelta
Il modello standard per il CBC e’ il Multinomial Logit (MNL), o la sua versione piu’ sofisticata, il Mixed Logit (che considera l’eterogeneita’ delle preferenze tra individui).
import pandas as pdimport numpy as npfrom sklearn.linear_model import LogisticRegressionfrom scipy.special import softmax
# ---- Simulazione dati CBC e stima delle part-worth utilities ----# In un dataset CBC reale, ogni riga e' un'osservazione:# - respondent_id: chi ha risposto# - task_id: quale schermata (task) del questionario# - profile_id: quale opzione nella schermata# - scelto: 1 se e' l'opzione scelta dal rispondente, 0 altrimenti# - dummy per ogni livello di ogni attributo
np.random.seed(42)
# Simuliamo le "vere" utilita' di ogni livello# (quello che vogliamo stimare con il modello)true_utilities = { 'prezzo_19': 2.1, # prezzo basso = alta utilita' 'prezzo_49': 0.4, 'prezzo_89': -2.5, # prezzo alto = bassa utilita' 'utenti_5': -0.8, 'utenti_25': 0.3, 'utenti_illim': 0.5, 'integr_5': -0.5, 'integr_25': 0.2, 'integr_illim': 0.3, 'supporto_docs': -0.3, 'supporto_email': 0.1, 'supporto_chat': 0.2, 'storage_10': -0.6, 'storage_100': 0.2, 'storage_illim': 0.4,}
feature_names = list(true_utilities.keys())true_coef = np.array(list(true_utilities.values()))
# Generiamo 300 rispondenti x 10 task x 3 opzioni = 9000 osservazionin_respondents = 300n_tasks = 10n_alternatives = 3
rows = []for r in range(n_respondents): for t in range(n_tasks): # Genera 3 profili casuali per questo task profili = [] for a in range(n_alternatives): # Ogni profilo e' una combinazione casuale di livelli prezzo_idx = np.random.choice(3) utenti_idx = np.random.choice(3) integr_idx = np.random.choice(3) supporto_idx = np.random.choice(3) storage_idx = np.random.choice(3)
# Vettore dummy (1-of-K encoding per ogni attributo) dummy = np.zeros(15) dummy[prezzo_idx] = 1 # prezzo: posizioni 0-2 dummy[3 + utenti_idx] = 1 # utenti: posizioni 3-5 dummy[6 + integr_idx] = 1 # integr: posizioni 6-8 dummy[9 + supporto_idx] = 1 # supporto: posizioni 9-11 dummy[12 + storage_idx] = 1 # storage: posizioni 12-14
# Utilita' vera + rumore individuale utilita = np.dot(dummy, true_coef) + np.random.gumbel(0, 0.5) profili.append((dummy, utilita))
# Il rispondente sceglie il profilo con utilita' piu' alta utilita_values = [p[1] for p in profili] scelta = np.argmax(utilita_values)
for a, (dummy, _) in enumerate(profili): rows.append({ 'respondent': r, 'task': t, 'alternative': a, 'scelto': int(a == scelta), **{feature_names[i]: dummy[i] for i in range(len(feature_names))} })
df_cbc = pd.DataFrame(rows)
# Stima del modello LogitX = df_cbc[feature_names].valuesy = df_cbc['scelto'].values
model = LogisticRegression(C=1e5, max_iter=500, random_state=42)model.fit(X, y)
# ---- Risultati: Part-Worth Utilities ----part_worths = pd.DataFrame({ 'Attributo_Livello': feature_names, 'Utility_Stimata': model.coef_[0], 'Utility_Vera': true_coef}).sort_values('Utility_Stimata', ascending=False)
print("=== Part-Worth Utilities (prime 5 per valore) ===")print(part_worths.head(8).to_string(index=False))
# ---- Importanza Relativa degli Attributi ----# Range della utility per ogni attributo (max - min dei livelli)attributi_gruppi = { 'Prezzo': ['prezzo_19', 'prezzo_49', 'prezzo_89'], 'Utenti': ['utenti_5', 'utenti_25', 'utenti_illim'], 'Integrazioni': ['integr_5', 'integr_25', 'integr_illim'], 'Supporto': ['supporto_docs', 'supporto_email', 'supporto_chat'], 'Storage': ['storage_10', 'storage_100', 'storage_illim'],}
ranges = {}coef_dict = dict(zip(feature_names, model.coef_[0]))for attr, livelli in attributi_gruppi.items(): utilities = [coef_dict[l] for l in livelli] ranges[attr] = max(utilities) - min(utilities)
totale_range = sum(ranges.values())importanza = {attr: r / totale_range * 100 for attr, r in ranges.items()}
print("\n=== Importanza Relativa degli Attributi ===")for attr, imp in sorted(importanza.items(), key=lambda x: -x[1]): print(f" {attr}: {imp:.1f}%")Interpretare i Risultati: Part-Worth Utilities e Importanza Relativa
Il risultato principale della conjoint analysis sono le part-worth utilities: un numero che rappresenta il contributo di ogni livello di ogni attributo all’utilita’ totale percepita del prodotto. Numeri piu’ alti significano che quel livello e’ preferito; numeri piu’ bassi significano che riduce l’attrattivita’.
Esempio di output interpretato per il nostro SaaS:
| Attributo | Livello | Utility | Importanza attributo |
|---|---|---|---|
| Prezzo | 19 euro/mese | +2.1 | 68% |
| 49 euro/mese | +0.4 | ||
| 89 euro/mese | -2.5 | ||
| Storage | 10 GB | -0.6 | 15% |
| 100 GB | +0.2 | ||
| Illimitato | +0.4 | ||
| Utenti | 1-5 | -0.8 | 9% |
| 6-25 | +0.3 | ||
| Illimitati | +0.5 | ||
| Integrazioni | 5 app | -0.5 | 5% |
| 25 app | +0.2 | ||
| Illimitate | +0.3 | ||
| Supporto | Solo docs | -0.3 | 3% |
| +0.1 | |||
| Chat dedicata | +0.2 |
L’importanza relativa si calcola come il range (max - min) delle utilities di ogni attributo, diviso la somma di tutti i range. In questo caso, il prezzo pesa il 68% della decisione d’acquisto. Il supporto dedicato — su cui magari stavi pensando di investire come differenziatore — pesa il 3%.
Questa e’ l’informazione devastante che solo la conjoint analysis puo’ darti con questa precisione: non solo “il prezzo e’ importante”, ma “il prezzo e’ 23 volte piu’ importante del supporto nella decisione d’acquisto del tuo segmento target”.
il Simulatore di Mercato: la Vera Potenza
Una volta calcolate le utilities, puoi costruire un simulatore di mercato: un modello che prevede la quota di preferenza (proxy della market share) per qualsiasi configurazione di prodotto.
Il meccanismo e’ semplice. Per ogni configurazione ipotetica, sommi le utilities dei livelli che la compongono. La quota di preferenza si calcola con la formula softmax sulle utilities di tutte le opzioni disponibili (inclusi i competitor simulati).
Scenario reale: “Abbiamo 28% di quota nel nostro segmento target. Se portiamo il prezzo da 49 a 39 euro (interpolando tra i livelli testati) e passiamo da chat dedicata a solo email, guadagniamo o perdiamo?”
Il simulatore puo’ rispondere in secondi, dopo aver assorbito mesi di ricerca in fase di campo.
graph LR
A["Configurazione attuale<br/>49 euro + Chat<br/>Market Share simulata: 28%"] --> B[Simulatore di Mercato]
B --> C["Scenario A<br/>39 euro + Solo Email<br/>Market Share: 34%"]
B --> D["Scenario B<br/>49 euro + Storage Illimitato<br/>Market Share: 31%"]
B --> E["Scenario C<br/>69 euro + Chat + Storage Illim<br/>Market Share: 19%"]
style C fill:#ccffcc,stroke:#333
style D fill:#ffffcc,stroke:#333
style E fill:#ffcccc,stroke:#333
Il risultato in questo caso e’ controintuitivo: abbassare il prezzo di 10 euro e togliere il supporto chat produce un guadagno netto di 6 punti di quota. La feature del supporto chat “costa” in termini di pricing power molto di piu’ di quanto “compra” in preferenza degli utenti.
Conjoint vs Metodi Alternativi: quando Usare Cosa
La conjoint analysis non e’ l’unico modo per misurare la willingness-to-pay o le preferenze dei consumatori. Ecco un confronto con altri metodi:
| Metodo | Miglior caso d’uso | Vantaggi | Svantaggi |
|---|---|---|---|
| Conjoint Analysis (CBC) | Pricing, feature prioritization, product mix | Realistica, fornisce utility discrete | Richiede 200+ rispondenti, complessa da analizzare |
| Van Westendorp Price Sensitivity | Analisi rapida del prezzo | Semplicissima, veloce | Non misura preferenze di feature, solo prezzo |
| Gabor-Granger | Stima elasticita’ prezzo | Dati realistici sequenziali | Sensibile all’ordine delle domande, effetto ancora |
| Discrete Choice Modeling | Simulazione comportamentale | Molto flessibile | Richiede competenza statistica avanzata |
| Focus Group | Esplorazione iniziale | Insight qualitativo ricco | Non quantificabile, non rappresentativo |
Errori Comuni che Invalidano lo Studio
Troppi attributi: Con piu’ di 6-7 attributi nel CBC, i rispondenti entrano in sovraccarico cognitivo e iniziano a rispondere alla cieca, guardando solo uno o due attributi (tipicamente il prezzo). Le utility stimate diventano inaffidabili. Se hai molti attributi, usa il MaxDiff per una prioritizzazione preliminare, poi approfondisci con un CBC su un sottoinsieme ristretto.
Livelli irrealistici o non confrontabili: Se metti “prezzo: 0 euro” o “supporto: risposta in 30 secondi”, i rispondenti non ci credono e distorcono le risposte. I livelli devono cadere all’interno del range di mercato credibile per il target.
Campione sbagliato: Se stai lanciando un prodotto per le PMI e intervisti solo le grandi aziende (perche’ sono piu’ facili da contattare attraverso la tua rete), le utilities che stimi non saranno applicabili al tuo vero target.
Ignorare la segmentazione: Le utilities aggregate nascondono eterogeneita’ importanti. I clienti “price-sensitive” e i clienti “feature-driven” hanno profili di utilita’ completamente diversi. Analizzare solo i dati aggregati potrebbe portarti a una configurazione di prodotto che non e’ ottimale per nessun segmento. Usa il Mixed Logit o la Latent Class Analysis per identificare segmenti con preferenze distinte.
Design sperimentale scarso: Se i profili non sono stati creati con un design ortogonale, le correlazioni tra attributi non saranno indipendenti e le utility stimate porteranno confondimento. Non affidarti agli istinti — usa software di design statistico o librerie Python dedicate.
Quando Usare la Conjoint e Quando no
| Situazione | Adatta? | Perche’ |
|---|---|---|
| Lancio nuovo prodotto: quale configurazione? | Si | Trova la combinazione ottimale prima di investire nel MVP |
| Redesign del pricing: quale piano? | Si | Misura l’elasticita’ di ogni feature e il willingness-to-pay |
| Confronto con competitor: dove siamo vulnerabili? | Si | Simula scenari in cui il competitor lancia features nuove |
| Ottimizzazione UI/UX: quale flusso? | No | Meglio A/B test su dati comportamentali reali |
| Posizionamento del brand | No | Meglio mappe percettive e brand equity research |
| Feature prioritization in backlog | Parzialmente | MaxDiff e’ piu’ efficiente del CBC per lunghi elenchi |
Caso Studio: Pricing di un Piano SaaS
Un’azienda SaaS di analytics aveva tre piani (Basic, Pro, Enterprise) e voleva capire se il pricing era ottimale. Con una conjoint analysis su 300 decision maker di target, hanno scoperto che:
- Il piano Pro era posizionato malissimo: i clienti erano disposti a pagare il 40% di piu’ per feature che l’azienda stava offrendo nel piano Enterprise. Il gap di prezzo tra Pro e Enterprise era insufficiente.
- Il numero di utenti era piu’ importante del supporto: i clienti era disposti a pagare premium sostanziali per aumentare i limiti di utenti, ma quasi niente per support dedicato.
- La segmentazione per settore era fondamentale: le aziende tech avevano una willingness-to-pay per integrazioni API che le aziende non-tech non aveva.
Resultado: hanno riprezzo i piani passando da 3 a 5 tiers (aggiungendo uno intermedio), aumentato significativamente il prezzo del Pro, e creato varianti dedicate per il settore tech. L’ARR (Annual Recurring Revenue) e’ aumentato del 34% senza perdere clienti — e’ aumentato il numero di upgrade da Basic a Pro.
Conclusione: Smettila di Chiedere, Osserva le Scelte
Il contributo fondamentale della conjoint analysis e’ epistemologico prima che metodologico: ci insegna che le preferenze dichiarate e le preferenze rivelate sono spesso molto diverse, e che le seconde sono quelle che contano. Per approfondire i concetti di misurazione delle preferenze nei dati, vedi il nostro modulo su metriche fondamentali.
Paul Green, il padre della conjoint moderna, amava dire che “le persone non sanno cosa vogliono finche’ non si trovano a dover scegliere”. La conjoint forza quella scelta in un contesto controllato e misurabile. Il risultato e’ una mappa delle priorita’ del consumatore che ha la precisione quantitativa necessaria per guidare decisioni di prodotto e pricing basate su dati, non su intuizioni.
Se stai lanciando un prodotto senza averla fatta, stai essenzialmente chiedendo ai consumatori “cosa volete?” e fidandoti della risposta. La conjoint ti dice cosa scelgono davvero quando devono scegliere — che e’ l’unica informazione che conta. Approfondisci le tecniche di miglioramento del modello nel nostro modulo analisi marketing.