Publisher per giochi mobile: scelta e contratto

I dati su mercato, conferenze e benchmark contrattuali servono a valutare scala e rischi, non a prevedere il fatturato di un singolo gioco. La decisione finale dipende da genere, metriche, budget, team e condizioni dell'accordo.

Scelta rapida: publisher o self-publishing

Il publishing di giochi mobile non è una scorciatoia automatica verso il mercato. È la scelta tra due modelli: lo sviluppatore del gioco porta il progetto sul mercato da solo, oppure affida parte del lavoro a un publisher in cambio di revenue share, diritti di controllo o recupero dell'investimento. Il supporto del publisher va sempre tradotto in clausole concrete: chi paga il lancio, chi decide, chi possiede i dati e che cosa succede al gioco dopo il rilascio.

Le tre risorse che decidono il modello

Per scegliere il modello, partite da tre risorse del team. La prima è il budget marketing: potete pagare ASO, creatività, acquisizione utenti, analisi dei dati e test della pagina dell'app? La seconda è la competenza nello scaling: sapete leggere CPI, retention, LTV, payback window e performance delle creatività? La terza è il supporto operativo: avete persone per localizzazione, supporto, aggiornamenti, eventi, recensioni e analisi dei dati? Se manca almeno una di queste risorse, il valore portato dal publisher può superare la quota ceduta.

Nel 2025 i giochi mobile restavano un mercato da decine di miliardi: Sensor Tower stimava ricavi annui dei mobile games intorno a 82 miliardi di dollari e 52 miliardi di download. Per uno sviluppatore significa una cosa semplice: il gioco non compete solo con altri indie, ma con un flusso enorme di uscite in cui l'attenzione dell'utente viene acquistata, testata e trattenuta in modo sistematico.

La stima di circa 82 miliardi di dollari di ricavi e 52 miliardi di download nel 2025 mostra la scala della competizione negli store mobile.

Numeri di mercato e benchmark servono come orientamento, non come previsione dei ricavi di un singolo gioco. Il risultato dipende da genere, retention, CPI, LTV, qualità delle creatività e condizioni contrattuali.

Quando il self-publishing è più razionale

Il self-publishing è più razionale quando il team sa già calcolare l'economia del progetto, ha accesso a un pubblico e può gestire la promozione del gioco mobile. Questo percorso lascia pieno controllo su IP, roadmap, port, sequel e monetizzazione. Il costo è altrettanto diretto: ogni errore in marketing, prodotto, analisi dei dati e finanza ricade sul team.

Quando un publishing deal colma il vuoto

Un publisher serve soprattutto quando il progetto è già valutabile, ma mancano denaro, marketing o capacità operativa per il lancio. Prima del primo contatto conviene verificare il potenziale del gioco: pubblico, analoghi di mercato, modello di monetizzazione, rientro del costo di acquisizione e punti deboli visibili nella demo. Le domande da fare al publisher vanno preparate prima: budget UA, ASO, report, accesso ai dati, localizzazione, live ops, net revenue e diritto di audit. L'accordo di pubblicazione si legge prima dell'anticipo, non dopo: diritti, esclusività e ripartizione dei ricavi decidono chi controlla il gioco dopo il rilascio.

In cosa un publisher è diverso da un fornitore

La collaborazione con un publisher non coincide con l'incarico a un'agenzia marketing. Un fornitore esegue un lavoro pagato e di norma non entra nei diritti sul gioco. Il publisher valuta pitch, demo, budget, pubblico e monetizzazione, poi entra come parte della trattativa. La domanda non è solo se trovare un publisher per il gioco, ma quale quota di rischio prende davvero e quale quota di controllo chiedete in cambio.

Che cosa fa davvero un publisher

Nel mobile publishing il lavoro del publisher copre di solito sei aree: finanziamento, UA e creatività, ASO, analisi dei dati e attribution, localizzazione o soft launch, live ops dopo il rilascio. Il piano di pubblicazione deve spiegare come il gioco arriva sul mercato: Paesi del primo lancio, ipotesi sui segmenti di pubblico, set di creatività, pagine su App Store e Google Play, metriche per fermare i test e soglie per scalare.

UA, creatività e ASO

L'ASO è l'ottimizzazione della pagina dell'app nello store: titolo, sottotitolo, parole chiave, icona, screenshot, video, localizzazioni, rating e recensioni. Nel marketing del publisher l'ASO lavora sulla conversione da visita della pagina a installazione. Per questo la promozione ASO non si separa dalle creatività pubblicitarie: se il video promette combattimenti rapidi e il primo screenshot mostra un menu di progressione, il traffico pagato perde conversione prima ancora dell'installazione.

AppsFlyer, nel report State of Gaming for Marketers 2026, ha analizzato 9.600 app di gioco, 24,8 miliardi di installazioni e 14,1 miliardi di installazioni a pagamento relative al 2025. Una base dati di questa scala spiega perché il publishing mobile dipende da attribution, analisi per coorte e acquisizione a pagamento, non solo da PR e pubblicazione nello store.

Il report ha analizzato 9.600 app di gioco, 24,8 miliardi di installazioni e 14,1 miliardi di installazioni a pagamento nel 2025.

Nel marketing mobile una verifica seria non si basa su un solo video: si testano hook, icone, screenshot dello store, playable ads e video ads. Il CPI può cambiare più per una creatività che per una piccola modifica al gameplay. Per un gioco mobile è decisivo: prima della meccanica di combattimento, l'utente vede icona, video pubblicitario e primi screenshot.

Valuto un publisher dalla capacità di lavorare in modo misurabile sulla pagina dell'app. Apple consente di creare fino a 70 Custom Product Pages aggiuntive per una singola app; secondo Apple, i tap verso queste pagine hanno generato in media +2,5 punti percentuali di conversione, pari a +156% rispetto alla conversione media dell'1,6% delle pagine default. Se il publisher non collega creatività, segmento di pubblico e pagina App Store, non sta davvero coprendo il lavoro ASO.

Finanziamento e recoup

Il finanziamento dello sviluppo è una parte distinta, non un sinonimo di publishing. Il publisher può pagare milestone di sviluppo, localizzazione, QA, server, trailer, doppiaggio, store asset e una quota del budget pubblicitario. Ma il denaro quasi mai è un regalo: nell'accordo compare il recoup, cioè l'ordine con cui l'investimento viene recuperato dai ricavi futuri. Un anticipo alto sembra attraente finché non si vede quali costi il publisher deduce prima di calcolare la vostra quota.

Analisi dei dati, localizzazione e soft launch

L'analisi dei dati serve a decidere: fermare un test, cambiare creatività, correggere la pagina dell'app, lavorare sulla retention o scalare la spesa. Il soft launch permette di verificare questa combinazione su Paesi e pubblici limitati prima del rilascio ampio. Se il publisher non spiega quali eventi raccoglie, quali coorti analizza e quali soglie considera valide, la sua esperienza non è verificabile dal team.

Live ops, distribuzione e crescita dopo il rilascio

Un publisher strutturato può aiutare non solo con la pubblicità, ma anche con distribuzione, pagamenti, geografie, analisi dei dati e sviluppo del prodotto dopo il lancio. Il punto da verificare è se queste aree sono descritte come processo, con metriche e responsabilità, o solo come promessa commerciale.

Il potenziale del gioco si dimostra con i numeri

Il publisher valuta pitch, demo, budget, pubblico e monetizzazione. L'idea da sola non basta: non permette di stimare il costo del lancio né il rischio legato allo scaling. Prima delle trattative servono analoghi di mercato, genere, pubblico target, modello di monetizzazione, budget, milestone plan e almeno primi dati di retention o engagement, se disponibili.

Steam e VG Insights possono essere utili anche per un gioco mobile, se usati con cautela. La valutazione del potenziale di mercato del gioco tramite VG Insights offre riferimenti sugli analoghi Steam: gross revenue estimates, owners estimates, price, review count, median playtime, tag e andamento di giochi simili. Non è una verità sui ricavi futuri, ma una base per costruire un intervallo di stima. Al publisher è meglio presentare tre scenari, prudente, realistico e aggressivo, invece di una previsione puntuale destinata a saltare al primo test CPI.

VG Insights è utile come riferimento sugli analoghi Steam: gross revenue estimates, owners estimates, price, review count, median playtime, tag e andamento dei giochi simili.

Pubblico e analoghi di genere

Partite da una domanda semplice: chi giocherà e perché sceglierà il vostro titolo tra le uscite vicine? Per un casual puzzle può contare una sessione breve e un gancio visivo immediato. Per un midcore RPG contano progressione, eventi, collezionismo, retention lunga e acquisti in-app. Per un premium puzzle pesano fiducia nella qualità, recensioni, trailer e prezzo chiaro.

Prima del pitch non basta mostrare idea e direzione artistica. Servono competitor, target, modello di monetizzazione, budget, milestone plan e almeno primi dati di retention o engagement. Anche una tabella grezza con 8-12 giochi simili è più credibile della frase secondo cui non esistono analoghi.

Monetizzazione e payback window

La monetizzazione di un gioco mobile deve reggere anche nei numeri. LTV = ARPDAU × durata media della vita dell'utente. ARPDAU è il ricavo medio giornaliero per utente attivo; la durata indica per quanti giorni l'utente genera ricavi. La payback window è il numero di giorni in cui il LTV cumulato della coorte copre il CPI. Se il CPI supera il LTV atteso, lo scaling a pagamento non regge economicamente.

Microtransazioni, monetizzazione pubblicitaria, contenuti scaricabili, battle pass ed event economy cambiano il confronto con il publisher. Nelle nostre analisi ASO e UA consideriamo un segnale forte non la semplice presenza di acquisti in-app, ma la chiarezza del valore percepito prima del primo pagamento: progressione, personalizzazione, accelerazione, collezione o status sociale. Senza questa lettura, il publisher testerà il mercato alla cieca.

Primi test su store e creatività

Apple Product Page Optimization valuta le varianti della pagina in base al conversion rate; i risultati appaiono dopo almeno 5 first-time download e una variante può essere indicata come Performing Better o Performing Worse quando ci sono impression sufficienti per il 90% di confidence. Portate questa logica in trattativa: chiedete quali ipotesi su icona, screenshot e app preview verranno testate, non solo quanto budget andrà in pubblicità.

Nel case study Supersonic su Draw the Line, il CPI è sceso da 0,80 a 0,21 dollari; il gioco ha raggiunto la top 5 iOS negli Stati Uniti e la top 10 Android tra le free app worldwide, con D1 retention al 51%, D7 retention al 13% e playtime di 700 secondi. Nei nostri confronti usiamo questi casi come modello di conversazione: un publisher deve discutere CPI, retention e playtime, non fermarsi a dire che il progetto è promettente.

Pitch, demo e piano di sviluppo per il publisher

Si può contattare un publisher prima del rilascio se il progetto è già valutabile. Per il primo contatto bastano spesso un pitch deck di 10-15 slide, un video di gameplay entro 2 minuti e una demo giocabile o vertical slice. Il pitch del gioco deve mostrare essenza del progetto, potenziale di mercato e punti di forza. La demo del gioco conferma qualità del gameplay e maturità del progetto per una valutazione più seria.

Un pitch senza teatro inutile

Il pitch deve rispondere rapidamente alle domande del publisher: che gioco è, a chi parla, che cosa rende diverso il core loop, quali piattaforme punta, a che fase si trova, come monetizza, quanto denaro serve, quando può andare in soft launch e quali rischi avete già individuato. Le slide curate aiutano, ma funziona di più una struttura chiara. Se in 5 minuti il publisher non capisce genere, sessione, pubblico e richiesta, la presentazione è sovraccarica.

Il game design document completa il pitch, ma non lo sostituisce. Il GDD spiega che gioco è e come funziona, la roadmap mostra tempi e fasi, il budget breakdown chiarisce quanto denaro serve e per quali voci. Lo sviluppatore prepara il pitch per la trattativa, mostra la demo per far valutare il progetto e porta documenti che aiutano il publisher a misurare il rischio.

Vertical slice e demo

Il vertical slice deve dimostrare core loop, qualità dei controlli, ritmo della sessione, livello visivo e ipotesi di monetizzazione; non deve contenere tutto il contenuto finale. Per il publisher conta di più vedere che il ciclo principale del gioco funziona, rispetto a ricevere decine di livelli senza una risposta sul perché l'utente dovrebbe tornare il giorno dopo.

La demo non deve nascondere le debolezze. Se i controlli sono ancora grezzi ma il core loop prende, ditelo. Se la resa visiva è vicina alla versione finale e il bilanciamento è provvisorio, definite il confine. Il publisher troverà comunque la distanza tra promessa e build; è meglio che sia il team a mostrare di conoscere lo stato del progetto.

Budget, NDA e materiali non pubblici

La ripartizione del budget aiuta a discutere finanziamento e rischi produttivi. Separate sviluppo, art, audio, localizzazione, QA, server, strumenti, trailer, store asset, PR e test UA. Se chiedete una somma unica senza struttura, il publisher non capisce dove possono nascere extra costi e quale milestone finanzia ogni pagamento.

Un accordo di riservatezza protegge materiali concreti come build, pitch deck, GDD, calcoli finanziari, pipeline artistica, sorgenti e metriche non pubbliche; l'idea astratta del gioco è di solito più debole da proteggere rispetto a codice, art, testi e documenti. L'NDA ha senso quando condividete qualcosa che non può essere pubblico: sorgenti, metriche interne, economia, asset unici o una build chiusa.

Dove cercare un publisher per il proprio gioco

Per cercare un publisher potete partire da aree B2B delle conferenze, pagine Steam di giochi simili e relativi publisher tag, LinkedIn e siti dei publisher, community Reddit e Discord, IndieDB, liste partecipanti e sistemi meeting degli eventi, contatti diretti da altri sviluppatori. Il canale funziona solo se filtrate i publisher per genere, piattaforma, dimensione del progetto e modello di monetizzazione. Scrivere a tutti è il modo più rapido per non ricevere risposte.

Gamescom 2025 ha riunito 357.000 visitatori, 34.000 visitatori professionali e 1.568 espositori da 72 Paesi; per cercare publisher contano soprattutto business area e appuntamenti professionali, non solo gli stand aperti al pubblico. Una conferenza per sviluppatori aiuta a trovare contatti, ma l'incontro funziona solo con pitch, demo e una spiegazione breve del perché quel publisher dovrebbe guardare il progetto.

Gamescom 2025 ha riunito 357.000 visitatori, 34.000 visitatori professionali e 1.568 espositori da 72 Paesi.

Nel cold outreach la pipeline parte da decine di contatti pertinenti, non da 2-3 email. Il messaggio deve includere hook, link al trailer o al gameplay, piattaforma, genere, fase, budget richiesto e pitch deck. Scrivere a un publisher mobile midcore per un piccolo premium puzzle senza live ops non dice che il gioco sia debole: dice che il destinatario non è quello giusto.

Steam serve anche per capire il mercato. Guardate le pagine dei giochi simili, chi li ha pubblicati, come sono costruiti tag, trailer, capsule, screenshot e aggiornamenti. IndieDB e Reddit danno visibilità, feedback e a volte contatti diretti, ma lì il progetto non va presentato con tono da comunicato stampa. Meglio mostrare progresso, build, video breve e una richiesta chiara: publisher, feedback o intro.

Confrontate i publisher in base al processo

La valutazione del publisher parte dal portfolio, ma non finisce lì. I publisher vanno confrontati per uscite rilevanti nel genere, budget UA, team creativo, analisi dei dati, condizioni di recoup, controllo dell'IP, trasparenza dei report, localizzazione e live ops. Il piano di pubblicazione fissa l'approccio del publisher a promozione e lancio; senza piano, l'offerta resta un insieme di promesse non verificabili.

Secondo l'analisi di Voyer Law su oltre 100 publishing agreements tra 2017 e 2025, negli accordi con advance payment la quota media di ricavi per lo sviluppatore era del 58,2%, con mediana al 50%. Se la quota proposta è molto più bassa, il publisher dovrebbe compensare con più rischio assunto: denaro, marketing, produzione o accesso al mercato.

Negli accordi con advance payment, la quota media di ricavi per lo sviluppatore era del 58,2%, con mediana al 50%, secondo un'analisi di oltre 100 publishing agreements tra 2017 e 2025.

Un advance alto non è sempre migliore: se è interamente recoupable e il publisher recupera prima i costi, lo sviluppatore può restare a lungo senza pagamenti oltre l'anticipo. Calcolate la waterfall: gross revenue, commissioni store, imposte, rimborsi, payment fees, chargeback, spese marketing o operative concordate, recoup e poi revenue share. La stessa percentuale nell'accordo può produrre pagamenti reali molto diversi.

Valuterei un publisher dalle aree di rischio che riesce davvero a coprire: budget UA, creatività, ASO, analisi della retention, monetizzazione e live ops. Nel 2024 i giochi mobile hanno generato circa 80,9 miliardi di dollari di ricavi IAP e 49,6 miliardi di download su App Store e Google Play; in un mercato così, il logo del publisher non sostituisce l'economia della crescita.

Lo specialista ASO del publisher deve parlare in modo concreto: quali keyword si testano, quali screenshot cambiano, chi risponde alle recensioni, chi controlla App Store Connect e Google Play Console, con quale frequenza si aggiornano le localizzazioni. Nelle nostre valutazioni è debole una proposta in cui il publisher chiede accesso agli store senza spiegare come deciderà su icona, app preview, rating e store listing experiment.

Voodoo dichiara pubblicamente 8 miliardi di download, lo status di #1 publisher yearly since 2018 e 150 milioni di MAU; nel processo di publishing cita le fasi Prototype, Iterate, Launch e Scale, con A/B testing, player progression, economy tracking e live ops. Un publisher mobile solido ha un processo che si può scomporre in fasi, metriche e persone responsabili.

Confrontate non la dimensione dell'anticipo, ma la quota di rischio che il publisher prende davvero: denaro, creatività, ASO, analisi dei dati, live ops, report e limiti contrattuali.

Domande da fare al publisher prima della firma

Le domande prima della firma devono trasformare promesse generiche in obblighi verificabili. Sul marketing chiedete Paesi del soft launch, budget UA iniziale, responsabile delle creatività, numero di iterazioni testate e soglie CPI, retention e ROAS per scalare. Se il publisher non indica soglie, si lascia la possibilità di attribuire ogni insuccesso al mercato.

Sulla produzione chiedete quali milestone sono finanziate, quali criteri rendono una milestone accettata, chi approva gli scope change e chi paga porting, localizzazione, QA, server e fornitori esterni. Il piano di sviluppo è legato al bisogno di finanziamento: se la milestone è vaga, il team rischia di discutere non della qualità del gioco, ma di quanto sia pronto un passaggio.

Sui report contano frequenza, accesso ai dati grezzi e non aggregati di store e UA, costi dedotti dalla net revenue, audit right e chi paga l'audit in caso di discrepanze. Lo sviluppatore deve vedere non solo il pagamento finale, ma il flusso dei ricavi: ricavi, commissioni, rimborsi, costi, recoup, quota delle parti.

Se il gioco include microtransazioni, bisogna discutere pricing matrix, bundle, battle pass, event economy, probabilità degli oggetti casuali e responsabilità di compliance negli store. È un tema di prodotto, finanza e accordo insieme. Lo scenario peggiore è che il publisher gestisca la monetizzazione e lo sviluppatore scopra i problemi con le regole dello store solo dopo il rifiuto di un aggiornamento.

• Chiedete un piano di pubblicazione con canali, Paesi del soft launch, creatività e ipotesi ASO.
• Definite chi paga localizzazione, QA, server, trailer, doppiaggio e store asset.
• Chiarite quali costi il publisher può dedurre dalla net revenue.
• Richiedete accesso ai dati di App Store, Google Play, account pubblicitari e analisi.
• Stabilite chi decide su monetizzazione, icona, screenshot, recensioni e aggiornamenti.
• Controllate se esiste un diritto di audit sui report finanziari e che cosa succede in caso di discrepanze.

Un publisher impreparato si irrita già alla domanda su quali costi verranno dedotti: anche questo è un segnale diagnostico sull'offerta.

L'accordo decide il futuro del gioco

L'accordo di pubblicazione definisce diritti, obblighi e condizioni di collaborazione. Contano soprattutto diritti di proprietà intellettuale, esclusività, comproprietà, ripartizione dei ricavi, recupero degli investimenti, obblighi delle parti, durata, territori e uscita dall'accordo. L'accordo con il publisher non è una formalità dopo l'anticipo: mostra chi controllerà il gioco dopo il lancio.

Per lo sviluppatore, territorio, durata e ambito dei diritti devono essere scritti in modo concreto, non nascosti in formule troppo ampie. L'accordo va letto partendo da controllo dell'IP, territorio, durata, esclusività, recoup e diritto di uscita. Se questi punti sono troppo estesi o ambigui, il rischio commerciale supera il valore delle promesse di supporto.

Diritti di proprietà intellettuale

I diritti di proprietà intellettuale incidono sul controllo dello sviluppatore dopo l'accordo. Il rischio principale di una clausola IP non riguarda solo il gioco attuale, ma anche sequel, prequel, spin-off, port, merchandising, asset marketing e materiali sorgente dopo la cessazione del contratto. Se il publisher ottiene un controllo troppo ampio sui prodotti futuri, non entra solo in un rilascio: entra nel valore dell'intera linea IP.

Esclusività su quattro assi

L'esclusiva di piattaforma può limitare la distribuzione futura del gioco. L'esclusiva va divisa almeno per piattaforma, territorio, durata e tipo di diritti; un'esclusiva su tutte le piattaforme e per tutta la durata dell'IP è molto più pesante di un'esclusiva limitata a uno store o a un'area per 12-24 mesi.

Comproprietà e transfer-on-breach

La comproprietà dei diritti può sembrare equa, ma complica port, sequel, vendita dell'IP e raccolta di investimenti se l'accordo non disciplina l'uso commerciale da parte di ciascun titolare. Una transfer-on-breach clause è un segnale di rischio: in caso di inadempimento dello sviluppatore, i diritti sul gioco possono passare al publisher; senza limiti chiari può significare perdere di fatto il progetto.

Un accordo con il publisher è solido solo quando definisce con precisione IP, territorio, durata, esclusività, recoup, net revenue, accesso ai dati e uscita dall'accordo.

Segnali di una proposta da evitare

Una proposta rischiosa spesso si presenta bene: anticipo alto, promessa di promozione completa, rilascio rapido e l'idea che il publisher gestisca tutto. Il segnale d'allarme arriva quando non vengono fissati budget marketing minimo, canali, KPI del soft launch, responsabilità sulle creatività e frequenza dei report. Un piano forte si può verificare; un piano debole resta fondato sulla fiducia nella presentazione.

Il rischio economico spesso si nasconde nella definizione di net revenue. Se l'accordo permette al publisher di dedurre marketing expenses, overhead, admin fees o internal costs indefiniti, senza limite e senza approvazione dello sviluppatore, la ripartizione dei ricavi diventa nominale. Si può avere una quota interessante nell'accordo e non vedere incassi, perché la base di calcolo continua a ridursi.

Un altro segnale di stop è un'esclusività estesa su giochi futuri, sequel, port o progetti simili, pur finanziando solo il gioco mobile attuale. Una clausola del genere limita la crescita dello studio più di quanto aiuti un singolo lancio. Se il publisher vuole diritti sul futuro, deve spiegare la ragione commerciale e assumere obblighi corrispondenti, non limitarsi ad allargare il testo dell'accordo.

• L'accordo non prevede un budget marketing minimo o un piano di lancio chiaro.
• Le deduzioni dalla net revenue sono vaghe e non hanno un limite approvato.
• L'esclusività copre giochi futuri, sequel, port o progetti simili.
• Lo sviluppatore non ha accesso ai dati grezzi degli store, agli account pubblicitari e alle analisi.
• Le condizioni di uscita non spiegano che cosa succede a build, IP, account e costi non ancora recuperati.

Un rischio ricorrente è trasferire il progetto sull'account del publisher senza un impegno reale di marketing. Prima della firma serve un piano di lancio concreto, non solo accesso all'account e promessa di cross-promo.

Per app con loot box o meccaniche che offrono oggetti virtuali casuali, Apple richiede di comunicare ai clienti le probabilità di ricevere ciascun tipo di oggetto prima dell'acquisto. Se il publisher gestisce la monetizzazione, va chiarito chi prepara l'informativa, chi controlla i testi e chi risponde agli aggiornamenti quando lo store cambia requisiti.

Non partite dal publisher più famoso, ma da una diagnosi onesta del gioco: demo giocabile, pubblico chiaro, calcolo della monetizzazione, piano di sviluppo, budget, ipotesi ASO e lista dei rischi. Un publisher per giochi mobile serve quando copre un vuoto concreto e assume responsabilità misurabili; una proposta va scartata quando dietro l'anticipo ci sono costi vaghi, esclusività estesa e perdita di controllo sui diritti del gioco.